Bugzilla – Bug 385
Invalid interpretation of fragmentation/RTS threshold
Last modified: 2005-10-03 15:21:42
You need to log in before you can comment on or make changes to this bug.
- associate device with AP - run 'iwconfig eth1 frag 500' - send PING request from serwer to device: 'ping 10.72.2.102 -s 464' (frame size=528) -> fragmentation does not occur - send PING request from serwer to device: 'ping 10.72.2.102 -s 465' (frame size=529) -> fragmentation occurs at 504B level The above both cases are invalid, but they show that driver behaves differently at different packet sizes. Device should start fragmenting packets at frame size equal to fragmentation threshold.
Note that analogous issue applies to RTS threshold.
Log from bug scrub: <rustyl> I'm not sure I am reading this correct <rustyl> the bug is about how the ap is fragmenting, right? <rawsock> no <rawsock> there's nothing to do with ap <ALex__> ping replies are fragmented by the card <rustyl> why is it talking about pings that are from the server to the device? <rustyl> ok, this is just talking about our replies <rawsock> to distinct that this is not from the testing machine <rustyl> so it can be any other machine in the network <rawsock> sure <rawsock> actually i suppose there would be tha same effect on ping reqs leaving the testing machine <rustyl> do we have a bug for that <rawsock> for what? <rustyl> because it doen't make any difference to the driver.... it's just an out going packet <rustyl> for pings going out... not ping replies.... that are fragmenting wrong <rawsock> i know, that's why we have only #385 <rawsock> :) <rustyl> ok <rustyl> p2/minor? <rawsock> is the code the same for rts threshold? <ALex__> rustyl, do you know how to fix it? <ALex__> it is not so obvious <ALex__> 802.11 standard is not so precise here <rustyl> ALex__, I would need to look and see..... IIRC we just send a host command to the device with our parameters <rustyl> for the fragmentation threshold <ALex__> yes <rustyl> so, I'm not sure how we would be off like this, but it is possible that we are sending down a slightly wrong number down <rustyl> rts is a different command <rustyl> I haven't looked into what we are doing on rts <ALex__> rts is a different command <ALex__> calculate whole packet length against threshold - not high data length <ALex__> and remember about FCS length <rustyl> currently, we just pass the number down that WX sends us <rustyl> same for rts and frag <rawsock> if the code is the same than we can leave fts and rts in one bug <ALex__> but some fixes were done already in fragmentation because it behaved different once <rustyl> it's not the same code, it's just uses the same logic
try with 1.0.1. It did fragmenting in both cases. please try again. looking through the code it is doing the following * setting frag to 500 this lead to bytes_per_frag to 476, it is not 500 to make space for wirless header. this is differant if encryption is used. * sending 464 of data will set total size not including wireless header to 500, this due to ip and protocol headers. at the end data size 500 > bytes_per_frag 476. frag will happen.
Currently (1.0.1), fragmentation does not work. With FTS set to 500 I'm able to send packets up to 504B (instead of up to 500B). Larger packets are not sent at all.
With my test I got the following, when I get FTS to 500, the actual size of data that cause fradmentation is 240, 240 data + 24 wireless header + 36 protocol header. So if I ping xxxxxx -s 441 will have two fragment first with 500 data and second with 1 byte. the only issue I have any size between 441 and 480 I never get any responce for the ping but it work < 441 and > 480, I am currently looking at this. In your last comment you mention you can send 504?. Please send me the data you have and what type of card and system.
There are two problems: 1. With FTS=500, I cannot send pings of size from 441 to 464. There's no reply. 2. With FTS=500 and ping size = 440, my sniffer shows that the outgoing frames are 504 bytes long. You are just counting this in a wrong way. Wireless part does NOT have 24 bytes. It has 24 bytes + 4 bytes of FCS at the end of each frame. 802.11 standard says that _whole_ frames must not be larger than FTS. Tested on 2915abg card, Fedora 2.
Created an attachment (id=276) [details] fix for ping with fragmentation set please use this patch with ipw2200-1.0.1
now ping works with framentation using the patch attached. It worked with all ping sizes but it has one abnormal behaviour. if you set fragmentation to 500 the ping -s 441 to 465, the firmware will merge the two fragments into one so ping 441 will send one packet of size 501. The firmware will not send the second packet of size one byte with overhead 24 bytes for the 802.11 header address, it will merge the two fragments into one, this only for 441-465 ping sizes but it will work normal for the rest of sizes.
I tested your patch (id=276) against ipw2200-1.0.1 driver. My test steps and results are posted below: iwconfig eth2 frag 500 echo 0x00200000 >/sys/bus/pci/drivers/ipw2200/debug_level dmesg -c ping -c 2 -s 800 192.168.1.1 dmesg -c Nothing echoed by dmesg here..... ping -c 2 -s 2000 192.168.1.1 dmesg -c Nothing echoed by dmesg here..... iwconfig eth1 frag 256 dmesg -c ping -c 2 -s 500 192.168.1.1 dmesg -c ping -c 2 -s 500 192.168.1.1 dmesg -c we could see info below echoed by dmesg: Trying to reallocate for 108 bytes Adding frag 4 108... Trying to reallocate for 108 bytes Adding frag 4 108... So I don't think it's fixed.
sorry , not eth2 , it should be eth1 . The results are the same
Created an attachment (id=292) [details] Adds additional debug messages at IPW_DL_FRAG debug level Please apply this patch and provide the debug output for IPW_DL_FRAG.
*** Bug 615 has been marked as a duplicate of this bug. ***
We captured the packet by Ethernet Analysis on an ipw2100 laptop which in monitor mode, when an ipw2200 laptop sending ICMP packets. The following data is a ping request whose size 1000 Bytes, and laptop frag size is 300 B. % iwconfig eth1 frag 300 % ping 192.168.1.1 -I eth1 -c 3 -s 1000 You can see fragment in IEEE 802.11 section. The packet we got is based on Ethernet Analysis which works above MAC, so we can’t direct get the fragmented ICMP/IP datagram. Fortunately, we can still judge the frag action from IEEE 802.11 MAC head section. ======================================================================== No. Time Source Destination Protocol Info 242 9.352118 192.168.1.101 192.168.1.1 ICMP Echo (ping) request Frame 242 (232 bytes on wire, 232 bytes captured) Arrival Time: Mar 29, 2005 03:55:49.867816000 Time delta from previous packet: 0.001169000 seconds Time since reference or first frame: 9.352118000 seconds Frame Number: 242 Packet Length: 232 bytes Capture Length: 232 bytes IEEE 802.11 Type/Subtype: Data (32) Frame Control: 0x0108 (Normal) Version: 0 Type: Data frame (2) Subtype: 0 Flags: 0x1 DS status: Frame is entering DS (To DS: 1 From DS: 0) (0x01) .... .0.. = More Fragments: This is the last fragment .... 0... = Retry: Frame is not being retransmitted ...0 .... = PWR MGT: STA will stay up ..0. .... = More Data: No data buffered .0.. .... = WEP flag: WEP is disabled 0... .... = Order flag: Not strictly ordered Duration: 258 BSS Id: 00:0c:41:18:a7:6d (LinksysG_18:a7:6d) Source address: 00:0e:35:00:6d:a8 (192.168.1.101) Destination address: 00:0c:41:0b:dc:26 (192.168.1.1) Fragment number: 3 Sequence number: 39 802.11 Fragments Frame: 236, payload: 0-275 (276 bytes) Frame: 238, payload: 276-551 (276 bytes) Frame: 240, payload: 552-827 (276 bytes) Frame: 242, payload: 828-1035 (208 bytes) Logical-Link Control DSAP: SNAP (0xaa) IG Bit: Individual SSAP: SNAP (0xaa) CR Bit: Command Control field: U, func=UI (0x03) Organization Code: Encapsulated Ethernet (0x000000) Type: IP (0x0800) Internet Protocol, Src Addr: 192.168.1.101 (192.168.1.101), Dst Addr: 192.168.1.1 (192.168.1.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 1028 Identification: 0x0003 (3) Flags: 0x04 (Don't Fragment) Fragment offset: 0 Time to live: 64 Protocol: ICMP (0x01) Header checksum: 0xb33f (correct) Source: 192.168.1.101 (192.168.1.101) Destination: 192.168.1.1 (192.168.1.1) Internet Control Message Protocol
ipw2200-1.0.2 still have ping frag problem. #iwconfig eth1 frag 500 #ping 192.168.1.1 -I eth1 -s 460 no response but after patched "fix for ping with fragmentation set", it work fine.
looking at the log you provided below frags seemed to work fine the 1000 will be send in for fragments Frame: 236, payload: 0-275 (276 bytes) Frame: 238, payload: 276-551 (276 bytes) Frame: 240, payload: 552-827 (276 bytes) Frame: 242, payload: 828-1035 (208 bytes) payload + mac = 276 + 24 = 300 except for the last one was less than 300 because we had the left over. Yan We know it wont work without the patch, Now do you see any other problems if not marked as solved.
Mohamed, seems the patch is not in 1.0.2? From the CHANGES of 1.0.2, it should be integrated into it. The bug is resolved and the resolution is TESTED_PATCH_EXITS.
The bug will be fixed in ipw2200 1.0.3.
Verified in ipw2200 1.0.3.