Date: Thu, 21 Sep 2000 12:24:17 -0700 From: Ross Finlayson <finlayson@live.com> To: freebsd-mobile@FreeBSD.ORG Subject: Re: Problems getting WaveLAN device (wi0) working Message-ID: <4.3.1.1.20000921115348.00b59470@localhost> In-Reply-To: <20000920193714.A21934@pir.net> References: <3.0.6.32.20000920162544.01141570@pop.quiknet.com> <3.0.6.32.20000920133438.0110c740@pop.quiknet.com> <4.3.1.1.20000920122431.00c45b90@localhost> <4.3.1.1.20000920122431.00c45b90@localhost> <20000920131158.D61974@gblx.net> <3.0.6.32.20000920133438.0110c740@pop.quiknet.com> <20000920160635.E10774@nitrous.net> <3.0.6.32.20000920162544.01141570@pop.quiknet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 04:37 PM 9/20/00, Peter Radcliffe wrote:
>FreeBSD cannot do the BSS base station mode - the code doesn't work.
>
>The advantages to BSS are you can use powersaving (doubles my laptop
>battery life) and I believe it is more efficient.
The reason BSS (aka. "infrastructure") mode doesn't work for a 802.11
interface attached a 'vanilla' FreeBSD (or Linux, etc.) router is that - in
this mode - a client node needs to be "authenticated" and "associated" with
an access point (AP) before it can send or receive data packets. This
requires a couple of low-level packet exchanges that don't happen
automatically - instead, they need to be implemented by the AP software.
I plan shortly to try implementing an AP 'daemon' for FreeBSD that does
this. At first, this would just do the basic (null) authentication and
association, but later on it could - I hope - be extended to implement the
packet buffering required to support "power saving" operation. Of course,
this will be Open Source (probably GPL), and - I hope - will be portable to
other Unixes as well.
If anyone else has already taken this on, please let me know, so we can
coordinate efforts.
"Ad hoc" mode, on the other hand, doesn't require the authentication and
association steps, which is why - in this mode - data delivery works with a
vanilla router.
So, why don't we all just use "ad hoc" mode? Well, one reason - that Peter
noted - is that 802.11's power saving option works only with
"infrastructure" mode. Another reason is that "ad hoc" mode is apparently
not part of the official 802.11 standard. Instead, the standard supports
something called "IBSS mode", which is supposedly similar to "ad hoc" mode,
but not quite the same. (I don't know what the difference is, though; if
anyone does, please let me know.) The newest versions of Lucent's drivers
and/or firmware supports "IBSS" mode rather than "ad hoc" mode, and I've
found that a client using this driver/firmware is *not* able to communicate
with a FreeBSD 'base station' with a card set to "ad hoc" mode. Again, I'm
not sure what the incompatibility is, but it suggests that we're going to
have problems with future clients unless we bite the bullet and support
"infrastructure" mode in our base stations.
BTW, I was finally able to figure out why the "wi0" interface was not
working properly in my FreeBSD box - it was an I/O port address
problem. Apparently, for my PC box, the I/O port range (0x240-0x360) given
in /etc/defaults/pccard.conf had some unknown conflict: The "wi0" device
would get brought up OK, but it wasn't communcating properly with the
kernel. Using a different I/O port range (0x200-0x23F) caused "wi0" to
work properly on my box.
<RANT>
The PC hardware architecture is such a fucking piece of crap! Just think
about how many man-hours around the word have been lost due to chasing down
IRQ and/or I/O port address conflicts. It's pathetic that - in the year
2000 - we still have to deal with garbage like this.
</RANT>
Ross.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.3.1.1.20000921115348.00b59470>