Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #607 (new defect)

Opened 16 years ago

Last modified 15 years ago

madwifi corrupts frames

Reported by: madwifi-ticket@atrox.at Assigned to:
Priority: major Milestone:
Component: madwifi: driver Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:

Description (Last modified by mentor)

most received frames get corrupted, sent frames are passed correctly; short frames seem to have better chances to pass uncorrupted.

tcpdump reports bad crc on most received ip packets, while sent frames arrive untouched in the wired network (verified with a tcpdump on the wired machine)

ping screenshot 

# ping 192.168.0.50
PING 192.168.0.50 (192.168.0.50) 56(84) bytes of data.
From 192.168.0.22 icmp_seq=2 Destination Host Unreachable
From 192.168.0.22 icmp_seq=3 Destination Host Unreachable
From 192.168.0.22 icmp_seq=4 Destination Host Unreachable
From 192.168.0.22 icmp_seq=6 Destination Host Unreachable
From 192.168.0.22 icmp_seq=7 Destination Host Unreachable
From 192.168.0.22 icmp_seq=8 Destination Host Unreachable
64 bytes from 192.168.0.50: icmp_seq=11 ttl=127 time=2.03 ms
64 bytes from 192.168.0.50: icmp_seq=12 ttl=127 time=1.23 ms
64 bytes from 192.168.0.50: icmp_seq=16 ttl=127 time=1.64 ms
64 bytes from 192.168.0.50: icmp_seq=17 ttl=127 time=1.80 ms
wrong data byte #44 should be 0x2c but was 0xff
#8      8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
#40     28 29 2a 2b ff ff ff ff 30 31 32 33 34 35 36 37
64 bytes from 192.168.0.50: icmp_seq=19 ttl=127 time=1.24 ms
wrong data byte #44 should be 0x2c but was 0x0
#8      8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
#40     28 29 2a 2b 0 0 0 0 30 31 32 33 34 35 36 37
64 bytes from 192.168.0.50: icmp_seq=26 ttl=127 time=1.24 ms
wrong data byte #44 should be 0x2c but was 0x0
#8      8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
#40     28 29 2a 2b 0 0 ff ff 30 31 32 33 34 35 36 37
64 bytes from 192.168.0.50: icmp_seq=27 ttl=127 time=1.24 ms
64 bytes from 192.168.0.50: icmp_seq=32 ttl=127 time=1.24 ms
wrong data byte #12 should be 0xc but was 0x3f
#8      8 9 a b 3f 6b 60 1 10 11 12 13 14 15 16 17 18 19 1a 1b 98 1a 7 0 20 21 22 23 24 25 26 27
#40     28 29 2a 2b 0 0 ff ff 30 31 32 33 34 35 36 37
64 bytes from 192.168.0.50: icmp_seq=33 ttl=127 time=1.23 ms
wrong data byte #44 should be 0x2c but was 0x70
#8      8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
#40     28 29 2a 2b 70 6b 74 63 30 31 32 33 34 35 36 37
64 bytes from 192.168.0.50: icmp_seq=35 ttl=127 time=1.24 ms
64 bytes from 192.168.0.50: icmp_seq=36 ttl=127 time=1.25 ms
64 bytes from 192.168.0.50: icmp_seq=45 ttl=127 time=1.26 ms
wrong data byte #44 should be 0x2c but was 0x0
#8      8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
#40     28 29 2a 2b 0 0 0 0 30 31 32 33 34 35 36 37
64 bytes from 192.168.0.50: icmp_seq=46 ttl=127 time=1.23 ms
wrong data byte #28 should be 0x1c but was 0x98
#8      8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 98 1a 7 0 20 21 22 23 24 25 26 27
#40     28 29 2a 2b 0 0 ff ff 30 31 32 33 34 35 36 37
64 bytes from 192.168.0.50: icmp_seq=47 ttl=127 time=1.25 ms

--- 192.168.0.50 ping statistics ---
47 packets transmitted, 14 received, +6 errors, 70% packet loss, time 46007ms
rtt min/avg/max/mdev = 1.232/1.369/2.030/0.250 ms, pipe 3

(the first unreachable pings are due to corrupted/dropped arp frames)

interestingly enough, some frames seem to get dropped at lower levels, some make it to the ip layer and are discarded there. when the packet is bigger, multiple corruptions can occour: 

# ping 192.168.0.50 -s 200 -p 77
PATTERN: 0x77
PING 192.168.0.50 (192.168.0.50) 200(228) bytes of data.
208 bytes from 192.168.0.50: icmp_seq=1 ttl=127 time=1.61 ms
wrong data byte #44 should be 0x77 but was 0x0
#8      77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77
#40     77 77 77 77 0 0 ff ff 77 77 77 77 77 77 77 77 77 77 77 77 3 0 17 0 77 77 77 77 77 77 77 77
#72     77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77
#104    77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77
#136    77 77 77 77 51 56 11 1 77 77 77 77 77 77 77 77 77 77 77 77 fe db 60 1 77 77 77 77 77 77 77 77
#168    77 77 77 77 5 0 8 0 77 77 77 77 77 77 77 77 77 77 77 77 2 1 2 0 77 77 77 77 77 77 77 77

OS: ubuntu 5.10; linux-2.6.12-10-686

madwifi: madwifi-ng-r1538-20060502 compiled using gcc-3.4

the card (netgear wg-511t) has been tested to work correctly on another computer with exactly the same madwifi version, the pcmcia slot has been tested with other 16 and 32 bit cards same situation with or without WEP encryption 

ATHSTATS

319 tx management frames
1 long on-chip tx retries
288 tx frames with no ack marked
464 rx failed due to bad CRC
149125 PHY errors
    2406 OFDM timing
    146720 CCK timing
3425 periodic calibrations
rssi of last ack: 66
rssi of last rcv: 63
19 switched default/rx antenna
Antenna profile:
[1] tx      199 rx    33090
[2] tx      138 rx      519

DMESG

[119584.380866] wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
[119584.380898] wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
[119584.380929] wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
[119584.380950] wifi0: H/W encryption support: WEP AES AES_CCM TKIP
[119584.380964] wifi0: mac 7.9 phy 4.5 radio 5.6
[119584.380999] wifi0: Use hw queue 1 for WME_AC_BE traffic
[119584.381007] wifi0: Use hw queue 0 for WME_AC_BK traffic
[119584.381015] wifi0: Use hw queue 2 for WME_AC_VI traffic
[119584.381024] wifi0: Use hw queue 3 for WME_AC_VO traffic
[119584.381031] wifi0: Use hw queue 8 for CAB traffic
[119584.381070] wifi0: Use hw queue 9 for beacons
[119584.420438] wifi0: Atheros 5212: mem=0x21000000, irq=11

Change History

05/10/06 01:35:12 changed by mentor

Could you add the console output again as follows: 

{{{
Output
}}}

05/10/06 02:12:57 changed by madwifi-ticket@atrox.at

sorry, for the unreadable screen output

PING 

# ping 192.168.0.50
PING 192.168.0.50 (192.168.0.50) 56(84) bytes of data.
From 192.168.0.22 icmp_seq=2 Destination Host Unreachable
From 192.168.0.22 icmp_seq=3 Destination Host Unreachable
From 192.168.0.22 icmp_seq=4 Destination Host Unreachable
From 192.168.0.22 icmp_seq=6 Destination Host Unreachable
From 192.168.0.22 icmp_seq=7 Destination Host Unreachable
From 192.168.0.22 icmp_seq=8 Destination Host Unreachable
64 bytes from 192.168.0.50: icmp_seq=10 ttl=127 time=1.23 ms
64 bytes from 192.168.0.50: icmp_seq=11 ttl=127 time=1.23 ms
64 bytes from 192.168.0.50: icmp_seq=13 ttl=127 time=1.25 ms
64 bytes from 192.168.0.50: icmp_seq=14 ttl=127 time=1.24 ms
64 bytes from 192.168.0.50: icmp_seq=15 ttl=127 time=1.23 ms
64 bytes from 192.168.0.50: icmp_seq=16 ttl=127 time=2.14 ms
wrong data byte #44 should be 0x2c but was 0x0
#8      8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
#40     28 29 2a 2b 0 0 ff ff 30 31 32 33 34 35 36 37
64 bytes from 192.168.0.50: icmp_seq=17 ttl=127 time=1.84 ms
wrong data byte #12 should be 0xc but was 0x4c
#8      8 9 a b 4c 97 61 38 10 11 12 13 14 15 16 17 18 19 1a 1b b6 40 af af 20 21 22 23 24 25 26 27
#40     28 29 2a 2b 0 0 ff ff 30 31 32 33 34 35 36 37
64 bytes from 192.168.0.50: icmp_seq=19 ttl=127 time=1.22 ms
64 bytes from 192.168.0.50: icmp_seq=27 ttl=127 time=1.23 ms
wrong data byte #28 should be 0x1c but was 0x98
#8      8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 98 1a 7 0 20 21 22 23 24 25 26 27
#40     28 29 2a 2b 0 0 ff ff 30 31 32 33 34 35 36 37
64 bytes from 192.168.0.50: icmp_seq=28 ttl=127 time=1.24 ms
wrong data byte #28 should be 0x1c but was 0x98
#8      8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 98 1a 7 0 20 21 22 23 24 25 26 27
#40     28 29 2a 2b 0 0 ff ff 30 31 32 33 34 35 36 37
64 bytes from 192.168.0.50: icmp_seq=29 ttl=127 time=1.23 ms
64 bytes from 192.168.0.50: icmp_seq=30 ttl=127 time=1.22 ms
64 bytes from 192.168.0.50: icmp_seq=31 ttl=127 time=1.23 ms
64 bytes from 192.168.0.50: icmp_seq=33 ttl=127 time=1.24 ms
wrong data byte #44 should be 0x2c but was 0x0
#8      8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
#40     28 29 2a 2b 0 0 ff ff 30 31 32 33 34 35 36 37
64 bytes from 192.168.0.50: icmp_seq=35 ttl=127 time=1.23 ms
64 bytes from 192.168.0.50: icmp_seq=36 ttl=127 time=1.24 ms

--- 192.168.0.50 ping statistics ---
37 packets transmitted, 16 received, +6 errors, 56% packet loss, time 36012ms
rtt min/avg/max/mdev = 1.227/1.332/2.144/0.258 ms, pipe 3

LARGE PING 

# ping 192.168.0.50 -s 200 -p 77
PATTERN: 0x77
PING 192.168.0.50 (192.168.0.50) 200(228) bytes of data.
208 bytes from 192.168.0.50: icmp_seq=1 ttl=127 time=1.61 ms
wrong data byte #44 should be 0x77 but was 0x0
#8      77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77
#40     77 77 77 77 0 0 ff ff 77 77 77 77 77 77 77 77 77 77 77 77 3 0 17 0 7 7 77 77 77 77 77 77 77
#72     77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77
#104    77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77
#136    77 77 77 77 51 56 11 1 77 77 77 77 77 77 77 77 77 77 77 77 fe db 601 77 77 77 77 77 77 77 77
#168    77 77 77 77 5 0 8 0 77 77 77 77 77 77 77 77 77 77 77 77 2 1 2 0 77 7 7 77 77 77 77 77 77
--- 192.168.0.50 ping statistics ---
4 packets transmitted, 1 received, 75% packet loss, time 3001ms
rtt min/avg/max/mdev = 1.617/1.617/1.617/0.000 ms

ATHSTAT 

319 tx management frames
1 long on-chip tx retries
288 tx frames with no ack marked
464 rx failed due to bad CRC
149125 PHY errors
    2406 OFDM timing
    146720 CCK timing
3425 periodic calibrations
rssi of last ack: 66
rssi of last rcv: 63
19 switched default/rx antenna
Antenna profile:
[1] tx      199 rx    33090
[2] tx      138 rx      519

DMESG 

[119584.380866] wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
[119584.380898] wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
[119584.380929] wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
[119584.380950] wifi0: H/W encryption support: WEP AES AES_CCM TKIP
[119584.380964] wifi0: mac 7.9 phy 4.5 radio 5.6
[119584.380999] wifi0: Use hw queue 1 for WME_AC_BE traffic
[119584.381007] wifi0: Use hw queue 0 for WME_AC_BK traffic
[119584.381015] wifi0: Use hw queue 2 for WME_AC_VI traffic
[119584.381024] wifi0: Use hw queue 3 for WME_AC_VO traffic
[119584.381031] wifi0: Use hw queue 8 for CAB traffic
[119584.381070] wifi0: Use hw queue 9 for beacons
[119584.420438] wifi0: Atheros 5212: mem=0x21000000, irq=11

05/10/06 10:29:38 changed by mentor

What network topology do you have? What access point are you using? Do you have any encryption enabled? Have you got other wireless clients?

05/10/06 10:54:08 changed by madwifi-ticket@atrox.at

the ap is connected to a switch; Tests are done, without other clients connected to the AP, but there are other wired machines online.

i get the same results of crippled frames with a Dlink AP (unencrypted) and an Acer AP (104/128bit WEP). I can ping the AP or ping a machine on my LAN - it doesn't change the problem. <

Tests with an orinoco in the same notebook reveals no problem. Tests with the same WG511T in another notebook (but with kernel 2.6.12-5) works too. (This machine has 2.6.12-10-686) To exclude faulty pcmcia-slots, I also tested other 16 and 32 bit ethernet cards in the same slot, without troubles.

05/10/06 23:20:29 changed by mentor

weird. That kinda isolates it to the particular driver binaries, or to a strange interaction between the PCMCIA bridge and madwifi driver.

Have you tried a different Linux kernel version on the faulty machine?

Could you tell me what values of CONFIG_PREEMPT and CONFIG_SMP your kernels are compiled with?

05/11/06 02:33:18 changed by madwifi-ticket@atrox.at

CONFIG_PREEMPT and CONFIG_SMP are both not set.

i will try another kernel too, but it would be best, when it works with the ubuntu (more-or-less) default kernel, since ubuntu often tend to overwrite a lot of things (incl kernel) when doing normal update.

05/28/06 18:02:03 changed by yachor@gmail.com

I've got the same problem. It mostly affects DHCP traffic (probably because dhclient sends query packets in small quantities): Dest addresses are broken (216.255.255.255 instead of 255.255.255.255 are most common ones). I suppose it's not a problem with encryption because I've run open ap and WEP encrypted with the same result. I've got a lot of packets dropped: 34727 PHY errors, 69661 rx crc. Card is running only in AP mode.

Hardware: Esmax PCI card (pci id: 168c:0013), External Anthena, Pentium III

OS: Linux kernel 2.6.3-7mdk (Mandrake 10.0) 

One of packets: (dest: 216.255.255.255 instead of 255.255.255.255, bad CRC)
0000  ff ff ff ff ff ff 00 14  85 cd bc 10 08 00 45 10   ........ ......E.
0010  01 48 00 00 00 00 10 11  a9 96 00 00 00 00 d8 ff   .H...... ........
0020  ff ff 00 44 00 43 01 34  73 02 01 01 06 00 12 25   ...D.C.4 s......%
0030  10 16 00 15 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0040  00 00 00 00 00 00 00 14  85 cd bc 10 00 00 00 00   ........ ........
0050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
00a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
00b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
00c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
00d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
00e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
00f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0110  00 00 00 00 00 00 63 82  53 63 35 01 03 36 04 0a   ......c. Sc5..6..
0120  00 00 01 32 04 0a 00 00  fb 37 07 01 1c 02 03 0f   ...2.... .7......
0130  06 0c ff 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
0150  00 00 00 00 00 00                                  ......

12/15/06 01:24:32 changed by asornat@gmail.com

Is there a solution to this problem, yet?

12/15/06 12:02:21 changed by mrenzmann

From what I know, it has not yet obviously been addressed. However, chances are that the issue got solved due to other commits. It would be helpful to get feedback from users who suffer from this issue, telling whether current trunk is still showing the same behaviour or not. Thanks in advance.

12/16/06 18:17:03 changed by krzyzowiec@yahoo.com

Destination Host Unreachable

Is there a solution to this problem, yet?

05/20/07 04:01:39 changed by mentor

  • description changed.

05/20/07 15:55:03 changed by strasak@bubakov.net

I have recently seen lot of phyerrors and crc errors in athstats -i wifiX 1 output on boxes, around which recently another APs started broadcasting => interference. That alone does not explain why it worked ok for you in another notebook with another kernel, so there has to be other problem too. For example, doesn't your first notebook - where frames are corrupted - have running/broken bluetooth device ? Or, have ya tested the other notebook - which worked - in same time as your frames corrupting one? Because your neighbour could have something really weird running in particular times of the day ... also this : 

19 switched default/rx antenna
Antenna profile:
[1] tx      199 rx    33090
[2] tx      138 rx      519

is a bit interesting, how it comes there are that much received frames? Try to run athstats -i wifi0 1 and see, what is going on. I have recently had about 600 phyerrors and 400 crcs on one device in one box here, althrought there has been almost no input and output frames. We found, that channel, where that device has been set, is terribly filled by unknown source of interference, we switched channel and voila, now it is almost clean - few phyeeros per second even in case it is under load, no bad ips no other problems. So, according to my experience, behavior like this is usually caused by HW + conditions combination - bad antennas, bad devices, misbehaving device nearby, just plain high level of noise around, bad cables etc. etc. .