#843: four extra bytes between 802.11 and LLC headers in frames recv'd by
AR5006EXS
-----------------------------------+----------------------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: madwifi: 802.11 stack | Version: v0.9.2
Keywords: AR5006EXS PCI Express | Patch_attached: 0
-----------------------------------+----------------------------------------
This may be a manifestation of the problem reported in ticket #784.
I have a Dell Latitude D620 laptop with a mini-PCI Express card:
PCDGlobal's implementation of the XB62 reference design for the AR5006EXS
aka AR5424.
The node comes up and associates. When I try to ping another node, using
Ethereal on a separate monitor machine I can see the XB62 going through
the proper steps get
a MAC address via ARP. I can see the ARP replies on Ethereal, but the XB62
never transmits the ping request, instead it tries ARPing two more times
then the ping
command times out. When I run Ethereal on the XB62 node in parallel with
the STA, or use "athdebug +recv" to dump the incoming packets, I see there
are an extra four
bytes between the 802.11 header and the LLC header. Ethereal cannot decode
these bytes. Here is a hex dump of an ARP request and the reply. I edited
and interleaved
the lines of the two hex dumps for easy comparison. The top line of each
pair is the incoming frame as reported by "athdebug +recv" in dmesg. The
second line is what
Ethereal reports on the other machine. The other machine uses a Atheros-
based Senao NMP-8602+ and works fine. FWIW, the access point is a Linksys
WAP54GP.
{{{
This is an echo of my arp request relayed by the AP to all, I get to see
it also
FRDS 00:16:e3:36:17:eb->ff:ff:ff:ff:ff:ff(00:14:bf:7e:3e:3c) data 1M +68
08 02 3a 01 ff ff ff ff ff ff 00 14 bf 7e 3e 3c <-- "athdebug +recv" in
dmesg
08 02 3a 01 ff ff ff ff ff ff 00 14 bf 7e 3e 3c <-- Ethereal on other
machine
00 16 e3 36 17 eb 40 37 00 40 70 00 aa aa 03 00 <-- dmesg reports extra
4 bytes
00 16 e3 36 17 eb 40 37 aa aa 03 00 <-- not seen by other
machine
00 00 08 06 00 01 08 00 06 04 00 01 00 16 e3 36
00 00 08 06 00 01 08 00 06 04 00 01 00 16 e3 36
17 eb c0 a8 01 06 00 00 00 00 00 00 c0 a8 01 03
17 eb c0 a8 01 06 00 00 00 00 00 00 c0 a8 01 03
This is the ARP response forwarded by the AP to me
FRDS 00:02:6f:40:77:1c->00:16:e3:36:17:eb(00:14:bf:7e:3e:3c) data 54M +65
08 02 2c 00 00 16 e3 36 17 eb 00 14 bf 7e 3e 3c
08 02 2c 00 00 16 e3 36 17 eb 00 14 bf 7e 3e 3c
00 02 6f 40 77 1c 50 37 84 40 70 00 aa aa 03 00
00 02 6f 40 77 1c 50 37 aa aa 03 00
00 00 08 06 00 01 08 00 06 04 00 02 00 02 6f 40
00 00 08 06 00 01 08 00 06 04 00 02 00 02 6f 40
77 1c c0 a8 01 03 00 16 e3 36 17 eb c0 a8 01 06
77 1c c0 a8 01 03 00 16 e3 36 17 eb c0 a8 01 06
}}}
As Codestrom reported, Windows XP also fails to communicate on this
hardware platform until Super A/G mode is disabled via the ACU utility,
after which it works as well as Windows ever works.
I tried "iwpriv ath0 turbo 0" but that did not help.
I rather bludgeonly added a "+4" to ieee80211_input.c to skip over the
four bytes:
{{{
static struct sk_buff *
ieee80211_decap(struct ieee80211vap *vap, struct sk_buff *skb, int hdrlen)
{
struct ieee80211_qosframe_addr4 wh; /* Max size address frames
*/
struct ether_header *eh;
struct llc *llc;
u_short ether_type = 0;
memcpy(&wh, skb->data, hdrlen); /* Only copy hdrlen over */
printk("ieee80211-decap: skipping extra four bytes\n"); //
complain
llc = (struct llc *) skb_pull(skb, hdrlen+4); // skip LLC plus
extra bytes
if (skb->len >= LLC_SNAPFRAMELEN &&
llc->llc_dsap == LLC_SNAP_LSAP && llc->llc_ssap ==
LLC_SNAP_LSAP &&
llc->llc_control == LLC_UI && llc->llc_snap.org_code[0] == 0
&&
llc->llc_snap.org_code[1] == 0 && llc->llc_snap.org_code[2] ==
0) {
ether_type = llc->llc_un.type_snap.ether_type;
skb_pull(skb, LLC_SNAPFRAMELEN);
llc = NULL;
}
}}}
Compiled and installed it, and ran the following test script:
{{{
dmesg -c >/dev/null
athdebug +recv
ping -c1 192.168.1.245
athdebug -recv
dmesg
}}}
The ARP and ping now work. Here are the results:
{{{
#sh -v ./test
dmesg -c >/dev/null
athdebug +recv
dev.wifi0.debug: 0x00000000 => 0x00000004<recv>
ping -c1 192.168.1.245
PING 192.168.1.245 (192.168.1.245) 56(84) bytes of data.
64 bytes from 192.168.1.245: icmp_seq=1 ttl=64 time=4.60 ms
--- 192.168.1.245 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.605/4.605/4.605/0.000 ms
athdebug -recv
dev.wifi0.debug: 0x00000004 => 0x00000000
dmesg
FRDS 00:16:e3:36:17:eb->ff:ff:ff:ff:ff:ff(00:14:bf:7e:3e:3c) data 1M +67
08 02 3a 01 ff ff ff ff ff ff 00 14 bf 7e 3e 3c <-- downlink echo of my
ARP request
00 16 e3 36 17 eb 20 3b 00 40 70 00 aa aa 03 00
00 00 08 06 00 01 08 00 06 04 00 01 00 16 e3 36
17 eb c0 a8 01 06 00 00 00 00 00 00 c0 a8 01 f5
FRDS 00:14:bf:7e:3e:3d->00:16:e3:36:17:eb(00:14:bf:7e:3e:3c) data 54M +63
08 02 2c 00 00 16 e3 36 17 eb 00 14 bf 7e 3e 3c <-- ARP reply
00 14 bf 7e 3e 3d 30 3b 84 40 70 00 aa aa 03 00
00 00 08 06 00 01 08 00 06 04 00 02 00 14 bf 7e
3e 3d c0 a8 01 f5 00 16 e3 36 17 eb c0 a8 01 06
ieee80211-decap: skipping extra four bytes
FRDS 00:14:bf:7e:3e:3d->00:16:e3:36:17:eb(00:14:bf:7e:3e:3c) data 54M +62
08 02 2c 00 00 16 e3 36 17 eb 00 14 bf 7e 3e 3c <-- ping reply
00 14 bf 7e 3e 3d 40 3b 84 78 70 00 aa aa 03 00
00 00 08 00 45 00 00 54 33 41 00 00 40 01 c3 1c
c0 a8 01 f5 c0 a8 01 06 00 00 46 69 8b 0b 00 01
89 93 ef 44 be ae 0c 00 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30 31 32 33 34 35 36 37
ieee80211-decap: skipping extra four bytes
}}}
My klutzy "fix" seems to sort of work -- I can now bring up the access
point's web page.
My conclusion is that on inbound data frames the AR5006EXS inserts some
extra header between the IEE802.11 header and the LLC header. It evidently
has something to do with Super A/G.
I stuck in a "printk" to dump out the extra bytes every time I skipped
over them.
{{{
0: always 0x84
1: takes various values: 00 c4 58 60 ac 16 8e ...
2: takes values between 0x70 and 0x76
3: always 0x00
}}}
BTW -- I freely admit that I do not know what I am doing. I'm just coming
up to speed on 802.11 and Linux. My recent comms experience is
implementing the ControlNet MAC layer.
--
Ticket URL: <http://madwifi.org/ticket/843>
MadWifi <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Madwifi-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/madwifi-tickets
