search

Rup0rt / pcapfix

repair corrupted pcap files
http://f00l.de/pcapfix/
GNU General Public License v3.0
202 stars 34 forks source link

Infinite loop ? #13

Closed fxlb closed 6 years ago

fxlb commented 6 years ago

Hi, It seems that pcapfix has an infinite loop with this pcap file: mobility_opt_asan.pcap.gz with -d option

Rup0rt commented 6 years ago

Fixed, but I still have a problem with this file. The global pcap header snap length is 70 bytes, but the captured packets are 100 bytes in size. At this moment the packets are handled as broken. Is this a wanted behavior? From my point of view there are two possibilities:

1) global pcap header snap length is ignored 2) global pcap header snap length is adjusted based on the largest packet in file (false positives may occur)

What do you think?

fxlb commented 6 years ago

I'll think about it. For now: 1. (ignored).

FYI, for tcpdump or tshark the packets are not broken but truncated during capture.

$ tcpdump -#v -r tests/mobility_opt_asan.pcap
reading from file tests/mobility_opt_asan.pcap, link-type EN10MB (Ethernet)
    1  09:53:17.131862 IP6 (class 0x50, flowlabel 0x00004, hlim 0, next-header Mobile IP (old) (62) payload length: 7168) d400:7fa1:0:400::6238:2949 > 9675:86dd:7300:2c:1c7f:ffff:ffc3:b2a1: mobility: BU seq#=116 A lifetime=15872(pad1) [|mobility]
    2  16:32:13.8916227 IP6 (class 0x50, flowlabel 0x00004, hlim 0, next-header Mobile IP (old) (62) payload length: 7168) d4c3:b2a1:200:400::6238:2949 > 9675:86dd:73f0:2c:1c7f:ffff:ebc3:b291: mobility: BU seq#=116 A lifetime=15360 [|mobility]
$ tshark -r tests/mobility_opt_asan.pcap         
    1   0.000000 d400:7fa1:0:400::6238:2949 -> 9675:86dd:7300:2c:1c7f:ffff:ffc3:b2a1 MIPv6 32896 Binding Update[Packet size limited during capture]
    2 1346567936.194430 d4c3:b2a1:200:400::6238:2949 -> 9675:86dd:73f0:2c:1c7f:ffff:ebc3:b291 MIPv6 32896 Binding Update[Packet size limited during capture]
Rup0rt commented 6 years ago

Yes, I tested it as well. Tcpdump/Tshark do (also) not care about global pcap header snap length. So this might be a reason for ignoring it as well. I use this field in pcapfix for plausibility checks when scanning for valid packets but I can use the maximum snap length as an less accurate alternative.

Rup0rt commented 6 years ago

I added a soft mode (-s) to pcapfix that disables some checks that do not break the file if they occur. This way even the packets that would be broken under hard circumstances can be identified.