From owner-freebsd-mobile Sat May 19 0:52:21 2001 Delivered-To: freebsd-mobile@freebsd.org Received: from baboon.aciri.org (adsl-64-166-241-35.dsl.snfc21.pacbell.net [64.166.241.35]) by hub.freebsd.org (Postfix) with ESMTP id 0FA7037B422 for ; Sat, 19 May 2001 00:52:18 -0700 (PDT) (envelope-from bkarp@baboon.aciri.org) Received: from baboon.aciri.org (localhost [127.0.0.1]) by baboon.aciri.org (8.11.3/8.11.1) with ESMTP id f4J7qUL56702; Sat, 19 May 2001 00:52:30 -0700 (PDT) (envelope-from bkarp@baboon.aciri.org) Message-Id: <200105190752.f4J7qUL56702@baboon.aciri.org> From: Brad Karp To: freebsd-mobile@freebsd.org Cc: rooneg@electricjellyfish.net Subject: fix for Linksys access point Date: Sat, 19 May 2001 00:52:29 -0700 Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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. -Brad, bkarp@icsi.berkeley.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message