Well, I've now been playing with the driver on my Thinkpad 600 for the
better part of a day (thanks to Chris Hopps who pointed out that the IO
space allocated for it was overlapped an unconfigured device), and I've
noticed three things, the first two of which may or may not be related:

1.  The card never comes up correctly the first time it's ifconfig'ed up.
    No IRQ is assigned for it, and consequently any attempted accesses
    result in  "wi0: device timeout".  However, if I bring the interface
    down, then up again, it works fine.  (even in powersaving mode!)

2.  Suspend mode on the laptop doesn't seem to work correctly once wi0
    is probed;  calling apm suspend seems to put it in Standby mode
    instead.  (Which, incidentally, seems to be broken on this machine;
    it may or may not be related to PR 6279 ... I've put the patch in, 
    which seems to clear up the suspend problem, but...)  It's calling
    apm_suspend, because /etc/apm/suspend gets called, but the mode
    behaves more like standby...

3.  I've noticed that wiconfig seems not to require superuser privileges
    to perform its magic... I don't offhand see a way to configure
    access to this.


If anyone has further suggestions for troubleshooting, I'm
eager to help.  Even having it in this state is fantastic, though!

+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