#1818: Fragmentation bug in adhoc/ahdemo mode when using WEP encryption
-----------------------------------------+----------------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: madwifi: driver | Version: v0.9.3.3
Resolution: | Keywords: fragmentation adhoc WEP
Patch_attached: 0 |
-----------------------------------------+----------------------------------
Changes (by mrenzmann):
* priority: critical => major
Old description:
> 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 packetsizes:
> 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-Fragments,
> both with the length of 300Bytes and both are complete.
>
> when S = 509, in the air you will see again 2 WLAN-Fragmets, both with
> the
> length of 300Bytes ! 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
New description:
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
Comment:
Please test to see if the issue still exists in trunk.
--
Ticket URL: <https://madwifi.org/ticket/1818#comment:1>
madwifi.org <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Madwifi-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/madwifi-tickets
