Date: Sat, 19 May 2001 08:57:16 -0700 From: Ron 'The InSaNe One' Rosson <insane@lunatic.oneinsane.net> To: mobile@freebsd.org Subject: Re: fix for Linksys access point Message-ID: <20010519085716.A75661@lunatic.oneinsane.net> In-Reply-To: <200105190752.f4J7qUL56702@baboon.aciri.org>; from bkarp@icsi.berkeley.edu on Sat, May 19, 2001 at 12:52:29AM -0700 References: <200105190752.f4J7qUL56702@baboon.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Does this effect when you are running a Linksys card with a Linksys AP.
TIA
Brad Karp (bkarp@icsi.berkeley.edu) wrote:
> I just spent an hour with a friend who'd bought a Linksys 802.11 access point,
> who also found that he couldn't talk to or through the access point
> successfully under FreeBSD, or Linux either, for that matter.
>
> We found the problem, and a less-than-perfect workaround.
>
> There are two framing standards used for packets in 802.11: RFC 1042 / 802.11
> encoding (with SNAP header), and 802.3 encoding.
>
> Lucent WaveLAN base stations send their IP and ARP packets as RFC 1042 /
> 802.11 frames, as do the FreeBSD, Linux, and Windows drivers.
>
> The host 802.11 interface (Hermes) hardware returns a status code with every
> received packet (rx_frame.wi_status) to indicate which type of packet the
> buffer holds. The wi driver uses this field to determine whether to process
> an incoming packet with RFC 1042 decapsulation, or as an 802.3 frame.
>
> Something (I'm not quite sure what) about the frames sent by the Linksys
> base station causes the Hermes to return a *zero* status code upon receiving
> them, rather than 0x2000, which indicates an RFC1042 packet. The way the
> wi driver is written, this causes the incoming packet to fall through to the
> 802.3 case. Zero doesn't seem to be a defined status code, in either the
> FreeBSD or Linux drivers.
>
> But the Linksys base station's packet *is* in RFC1042 format. So the
> decapsulation isn't performed on the inbound packet, and garbage (including
> the MAC addresses of the inbound packet) winds up being passed up to
> ether_input (which in turn drops the packet when it sees the dst address
> doesn't match that of the interface).
>
> My guess is that the Windows driver blindly performs RFC1042 decapsulation on
> every packet it receives, and thus receives the Linksys base station's
> questionable packets without difficulty.
>
> A quick fix if you're stuck with one of these base stations is to hack
> /sys/i386/isa/if_wi.c:wi_rxeof() so that frames *not only* with wi_status
> of WI_STAT_1042, WI_STAT_TUNNEL, or WI_STAT_WMP_MSG, *but also* with
> wi_status 0, are RFC1042 decapsulated.
>
> The equivalent hack to the Linux driver made the Linux WaveLAN driver receive
> packets from the Linksys base station just fine!
>
> The proper fix, though, is for Linksys to fix their firmware so that their
> base station generates packets that a WaveLAN card can properly identify as
> RFC1042-encapsulated.
--
------------------------------------------------------------------------------
Ron Rosson ... and a UNIX user said ...
The InSaNe One rm -rf *
insane@oneinsane.net and all was /dev/null and *void()
------------------------------------------------------------------------------
Eagles may soar, but weasels don't get sucked into jet engines.
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?20010519085716.A75661>