i use
Senao SUB-8301 USB WLAN module (AL7230B_RF rf chip)
Firmware: V1.1 (same V1.3)
Kernel: 2.6.18-rc2
zd1211rw git:   83c15ac14de7a01633c07e1c68226c73f9c92421 (old but works)

While sniffing the WLAN communication between the USB WLAN module and an
Access Point we found an extraordinary behaviour in handling the WLAN

According to the standard retried frames should preserve the WLAN
sequence number and only set the retry bit.

Tests with SUB-8301 USB module and a WLAN traffic analyser show that the
retried frames increment the WLAN sequence number, which is in
contradiction to the standard.

Attached below is a snapshot of such a log:

Frame   WLAN Sequence=n    Retry bit=0
Retry 1 WLAN Sequence=n    Retry bit=1
Retry 2 WLAN Sequence=n    Retry bit=1
Retry 3 WLAN Sequence=n    Retry bit=1
Retry 4 WLAN Sequence=n+1  Retry bit=0 (Fault)
Retry 5 WLAN Sequence=n+1  Retry bit=1
Retry 6 WLAN Sequence=n+2  Retry bit=0 (Fault)
Retry 7 WLAN Sequence=n+2  Retry bit=1
Retry 8 WLAN Sequence=n+3  Retry bit=0 (Fault)
Retry 9 WLAN Sequence=n+3  Retry bit=1

This behaviour violates the afore mentioned standard.
We found the same behaviour under Linux and Windows OS.

The faulty condition can easily be reproduced with the following

1) Generate UDP traffic to an arbitrary peer by sending packets
containing unique UDP packet numbers so they can be easily identified.
2) Sniff the traffic (we used kismet).
3) Switch off the access point while transmission runs.
4) Analyze kismet logs with ethereal/wireshark. You observe
above behaviour at time of switching the access point off.


Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Reply via email to