Subject: Re: driver for Lucent WaveLan/IEEE 802.11 committed
To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
From: Jeff Rizzo <riz@boogers.sf.ca.us>
List: port-i386
Date: 07/17/1999 15:54:31
On Fri, Jul 16, 1999 at 12:48:04PM -0700, Jeff Rizzo wrote:
> Woo hoo!  I will give this a try this weekend against a 'real' base
> station from a Thinkpad, and if I can dig up my ISA PCMCIA card that came 
> with my Alphastation 200, I'll give it a shot there, too.
> 
> >From the bottom of my heart, THANK YOU!!!
> 
> :)
> 
> +j

Well, here's my results so far... I can get it to "work" on my ThinkPad 600,
by using wiconfig to set the card in BSS mode (as opposed to ad-hoc), but
it relatively quickly locks the machine up solid... can't even drop into
DDB.  If you've got any suggestions as to how to troubleshoot this,
I'm more than happy to help...

Note that the card locks the machine up regardless of whether I switch
it out of ad-hoc mode or not;  but unless I take it out, it doesn't
see the base station.

Still, it's quite promising!

+j

> 
> On Thu, Jul 15, 1999 at 10:58:06AM +0200, Bill Sommerfeld wrote:
> > With some prompting by Christian Hopps, I ported Bill Paul's FreeBSD
> > `wi' driver for the Lucent WaveLan/IEEE 802.11 wireless networking
> > PCMCIA card to NetBSD-current.
> > 
> > It's been (very) minimally tested in the bar at the IETF hotel in
> > "ad-hoc" mode, and has not been tested against base stations.
> > 
> > There's also a "wiconfig" program in /usr/sbin which lets you tweak
> > the card settings; however, that did not appear to be necessary to get
> > two of the cards to talk to each other.
> > 
> > The card I did the port with was on very short-term loan from
> > Christian, so I won't really be able to do continued development on my
> > port of the driver..
> > 
> > I'd be interested in hearing about:
> > 	- success using it to talk to "real" 802.11 base stations
> > 	- successful use on non-x86 platforms.
> > 
> > There are a couple issues:
> > 	- it uses SIOCGIFGENERIC/SIOCSIFGENERIC; Jason thinks it
> > should use SIOCSDRVSPEC instead, but there isn't a SIOCGDRVSPEC.
> > Given the multiple dozen configuration parameters, it would be easier
> > to just go with two ioctls rather than adding a get/set direction bit
> > to the DRVSPEC sub-opcode, but something can be arranged..
> > 
> > 	- the transmit side does an extra data copy into a buffer in
> > the softc.  This really should be cleaned up since it makes the softc
> > about five times larger than it otherwise needs to be....
> > 
> > 				- Bill
> 
> -- 
> Jeff Rizzo                                         http://boogers.sf.ca.us/~riz

-- 
Jeff Rizzo                                         http://boogers.sf.ca.us/~riz