You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem packet was found in a malware exercise pcap; I have extracted that single packet (attached problem_packet.pcap.zip). The error is:
$ ./chaosreader.pl problem_packet.pcap
Chaosreader ver 0.95.10
Opening, problem_packet.pcap
Reading file contents,
100% (2481/2481)Invalid type '-' in unpack at ./chaosreader.pl line 1008.
This is because the packet contains a length field of 0 (uint16 in the 3rd and 4th bytes). Then the packet data length is calculated:
$ip_dlength = $ip_length - $ip_options_num - 20;
This gives an $ip_dlength of -20. Opening this packet in wireshark is instructive. It reports "Total length: 2427 (reported as 0, presumed to be because of "TCP segmentation offload (TSO))". Wireshark has a forum question on this at https://osqa-ask.wireshark.org/questions/16279. This is a configurable option in wireshark "Support packet-capture from IP TSO-enabled hardware".
The pertinent code in wireshark is in epan/dissectors/packet-ip.c:
/* Correct for zero-length TSO packets * If ip_len is zero, assume TSO and use the reported length instead. Note * that we need to use the frame/reported length instead of the * actually-available length, just in case a snaplen was used on capture. */if (ip_tso_supported&& !iph->ip_len)
iph->ip_len=tvb_reported_length(tvb);
tvbuff_t tvbuf is a "testy, virtual(-izable) buffer", see epan/tvbuff.h, and seems essentially to be the frame data. Packet length 2427 (as reported by wireshark above as the packet length) is the length of $ether_data in chaosreader.pl. So I think this is an equivalent fix:
The problem packet was found in a malware exercise pcap; I have extracted that single packet (attached problem_packet.pcap.zip). The error is:
This is because the packet contains a length field of 0 (uint16 in the 3rd and 4th bytes). Then the packet data length is calculated:
This gives an
$ip_dlength
of -20. Opening this packet in wireshark is instructive. It reports "Total length: 2427 (reported as 0, presumed to be because of "TCP segmentation offload (TSO))". Wireshark has a forum question on this at https://osqa-ask.wireshark.org/questions/16279. This is a configurable option in wireshark "Support packet-capture from IP TSO-enabled hardware".The pertinent code in wireshark is in
epan/dissectors/packet-ip.c
:tvbuff_t tvbuf
is a "testy, virtual(-izable) buffer", seeepan/tvbuff.h
, and seems essentially to be the frame data. Packet length 2427 (as reported by wireshark above as the packet length) is the length of$ether_data
inchaosreader.pl
. So I think this is an equivalent fix:At least, this appears to dissect my sample bad packet okay. That packet has
$ip_options
of 0 so this may need closer inspection.For reference,
tcpflow
has a similar issue at simsong/tcpflow#142 (open at this time).The text was updated successfully, but these errors were encountered: