Hi all,
First time I write in the list, nice to meet you all. Here’s my question:
In a series of ftp data (over a wireless link and using the huawei e220 device) I see the following Fragmented IP packet (details are below) that I can’t understand.
Many things are wrong with this one:
First of all it shouldn’t be in this sequence, its source/destination addresses are unknown, all its fields are messed up e.g. protocol unknown, IPv12???, IP header 60bytes???, diffserv is true, all the checksums are bad and the list goes on…
Could it be that I captured something that wasn’t meant for me due to bad radio conditions? Why are its fields so messed up? Any help on what happened here would be really appreciated!
Thanks Velissarios
No. Time Source Destination Protocol Info 5860 09:43:43.517578 10.32.8.127 195.5.122.37 FTP-DATA FTP Data: 1460 bytes 5861 09:43:43.689453 204.123.41.219 65.31.115.189 IP Fragmented IP protocol (proto=Unknown 0xfc, off=920) 5862 09:43:43.798828 10.32.8.127 195.5.122.37 FTP-DATA FTP Data: 1460 bytes
Frame 5861 (78 bytes on wire, 78 bytes captured) Arrival Time: Apr 4, 2008 09:43:43.689453000 [Time delta from previous packet: 0.171875000 seconds] [Time since reference or first frame: 200.359375000 seconds] Frame Number: 5861 Packet Length: 78 bytes Capture Length: 78 bytes [Frame is marked: False] [Protocols in frame: eth:ip:data] [Coloring Rule Name: Checksum Errors] [Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1] Ethernet II, Src: b6:de:20:00:0a:00 (b6:de:20:00:0a:00), Dst: 0a:00:0a:00:00:00 (0a:00:0a:00:00:00) Destination: 0a:00:0a:00:00:00 (0a:00:0a:00:00:00) Address: 0a:00:0a:00:00:00 (0a:00:0a:00:00:00) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) Source: b6:de:20:00:0a:00 (b6:de:20:00:0a:00) Address: b6:de:20:00:0a:00 (b6:de:20:00:0a:00) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) Type: IP (0x0800) Internet Protocol, Src: 204.123.41.219 (204.123.41.219), Dst: 65.31.115.189 (65.31.115.189) Version: 12 Header length: 60 bytes Differentiated Services Field: 0x69 (DSCP 0x1a: Assured Forwarding 31; ECN: 0x01) 0110 10.. = Differentiated Services Codepoint: Assured Forwarding 31 (0x1a) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...1 = ECN-CE: 1 Total Length: 59586 Identification: 0xdf43 (57155) Flags: 0x0e (Don't Fragment) (More Fragments) 1... = Reserved bit: Set .1.. = Don't fragment: Set ..1. = More fragments: Set Fragment offset: 920 Time to live: 243 Protocol: Unknown (0xfc) Header checksum: 0x70d0 [incorrect, should be 0x60b5] [Good: False] [Bad : True] Source: 204.123.41.219 (204.123.41.219) Destination: 65.31.115.189 (65.31.115.189) Options: (40 bytes) Unknown (0x49) (option length = 155 bytes says option goes past end of options) Data (4 bytes) Company Registered Number: 02382161 Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, AL10 9BW Registered in England and Wales NOTICE AND DISCLAIMER This email (including attachments) is confidential. If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. |
- Follow-Ups:
- Re: [Wireshark-users] "strange" Fragmented ip packet
- From: Guy Harris
- Re: [Wireshark-users] "strange" Fragmented ip packet
- Prev by Date: Re: [Wireshark-users] RTP decoded as DPLAY in V1.0.0
- Next by Date: Re: [Wireshark-users] RTP decoded as DPLAY in V1.0.0
- Previous by thread: Re: [Wireshark-users] packet id 0 ???
- Next by thread: Re: [Wireshark-users] "strange" Fragmented ip packet
- Index(es):