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 #1818 (new defect)

Opened 14 years ago

Last modified 14 years ago

Fragmentation bug in adhoc/ahdemo mode when using WEP encryption

Reported by: cc@embeddedwireless.de Assigned to:
Priority: major Milestone:
Component: madwifi: driver Version: v0.9.3.3
Keywords: fragmentation adhoc WEP Cc:
Patch is attached: 0 Pending:

Description (Last modified by mrenzmann)

Very simple scenario and very easy to reproduce the bug:

2 PCs with MadWifi ( I tried 0.9.3.2 & 0.9.3.3 ) are in adhoc mode and using WEP encryption (keylength doesn't matter). One of the PC is pinging the other one, with a defined packetsize S ({{{ping -s <packetsize> <IPaddr>).

If I put the fragmentation threshold to 300 bytes (for example), I will not get a ping reply for the following packet sizes:

S = 509, 510, 511, 512 & S = 781, 782, 783, 784 & every S = S + 272, ... !

I sniffed in the air and saw what's wrong:

Let's take S = 508, in the air you will see 2 WLAN-ragments, both with the length of 300 bytes and both are complete.

When S = 509, in the air you will see again 2 WLAN-fragments, both with the length of 300 bytes! So the last fragment lost the last byte (509 - 508) of the initial packet.

When S = 510 the last fragment is truncated by the 2 last bytes and so on till S = 513, when a third fragment takes the last 5 bytes of the initial packet and puts it on the air, so everything works again fine!

The general rule for the bug can be defined like this:

When a packet (in the air) is 1 to 4 bytes longer then the multiple of the fragmentation threshold, the driver does NOT generate a new necessary fragment for this last 1 to 4 bytes! The packet is delivered by MadWifi truncated by this last 1 to 4 bytes!!!

It begins to generate a new fragment, only with at least 5 bytes length!

I hope that somebody can solve this problem, after this detailed explanation ;-)

CC

Attachments

fragmentation.patch (1.7 kB) - added by fh@embeddedwireless.de on 03/11/08 11:27:04.
patch against v0.9.3.2, seems to be working with 0.9.3.3 and 0.9.4.

Change History

02/29/08 06:23:45 changed by mrenzmann

  • priority changed from critical to major.
  • description changed.

Please test to see if the issue still exists in trunk.

02/29/08 10:44:01 changed by cc@embeddedwireless.de

Hi Mike

It was a good idea to test the trunk (latest snapshot r3365 26Feb) !

The situation is much worst !!!

At Fragmentation threshold F=300Bytes, any ping longer then S=240 does NOT get a reply anymore !!! In the air it looks like the last fragment is NEVER generated, if the last fragment is smaller then F !

So, for S = 241 till 508, in the air you will see always only one packet with constant length = F. For S =509 till 708 you will always see two fragments both with constant length = F. And so on for more fragments.

Unfortunately, Release 0.9.4 didn't started on my Ubuntu 7.04 PC, so I couldn't test it, but it looks like this bug got even worst with newer revisions !

I see this bug as critical, especially in the trunk, so it would be great to get it assigned to a "specialist", what do you think Mike ?

03/11/08 11:27:04 changed by fh@embeddedwireless.de

  • attachment fragmentation.patch added.

patch against v0.9.3.2, seems to be working with 0.9.3.3 and 0.9.4.

(follow-up: ↓ 4 ) 03/12/08 06:26:07 changed by mrenzmann

Thanks for the patch. Please sign it off so that we can possibly include it in MadWifi.

(in reply to: ↑ 3 ) 03/12/08 11:29:55 changed by fh@embeddedwireless.de

Signed-off-by: Florian Hercher <fh@embeddedwireless.de>