I have a problem reading pcap files that have fragmented packets with tshark. My expectaion is tshark will re-assemble the fragmented IP packets before it passes them to the higher layer dissectors. But this doesnt appear to happen. If I open the same file with the Wireshark GUI application it does this fine. Should I be able to do this with tshark on the command line? I have tried various tshark versions and get the same result. 1.4x, 1.6.7 and 1.8.2. I have also tried overriding the default sip.defragment option. As an example I am searching pcap files (dumped with tcpump) for SIP calls. But the SIP dissector doesnt recognise the packets because they are still fragmented. So if I look at the first 10 packets in the file is see:
As you can see #5 and 6 show as fragmented. If I try to pass this through a sip filter it wont find those packets so it doesnt appear to be re-assembling them in the same way wireshark application does.
As can be seen packets 5 and 6 (which in this I know form an INVITE) dont get shown. I have also tried the For reference I am capturing them with tcpdump using the following BPF: Any Advice would be much appreciated asked 08 Feb '13, 02:12  Marv |
3 Answers:
You're missing the first part of your IP fragmented packets. That's because you drop them with your capture filter. That filter says:
oke, your on a vlan, make sure there's a tag and compensate for it,
oke, you want UDP (and TCP) port 5060, the SIP signaling port,
not oke, you don't want to have IP fragments with offsets multiple of 8.191. This includes offset 0, the start of the fragmented packets you are missing. Mind you, without reassembled IP packets, there is no UDP datagram that can be dissected to match the answered 08 Feb '13, 02:57  Jaap ♦ |
It looks like your filter is OK, it captures all frames with TCP and UDP port 5060 and all frames that have an IP fragment offset of non-zero. But this means your filter will also catch IP fragments that were not for port 5060. So the fragments that you are referring too might not be SIP at all. Then again, you say wireshark shows the packets fine. From the output of the packet it looks like
answered 08 Feb '13, 13:08  SYN-bit ♦♦ |
Yes, it should/will do that.
O.K. you are saying, that for the identical file (captured with the BPF you mentioned) de-fragmentation works in Wireshark and it does not work in tshark? If so, can you please upload the file somewhere (google docs, cloudshark.org, one-click file hoster. BEWARE the privacy issues in doing so!), so we can check ourselves? BTW: Did you capture the whole frame (option -s0)? If you did not, you will get problems during de-fragmentation. Regards answered 08 Feb '13, 12:27  Kurt Knochner ♦ edited 08 Feb '13, 12:29 |
Thanks Guys,
I have narrowed down the issue and it appears I have made a mistake in the way the files have been captured. On closer inspection Tshark is working fine but something is causing packets with the fragmented flag set to be dropped. This may be an aggregation switch before the capture box or the box itself so will need further investigation. When supplied with a valid file tshark will re-assemble them as expected. I do still have issues with extracting SIP when fragmented packets are present but I will get the capture issues sorted first.
Thanks all for you help an comments. They have helped a great deal in improving the BPF and tracking down the issue.
Cheers Marv
Your answer has been converted to a comment as that's how this site works. Please read the FAQ for more information.
If an answer has solved your issue, please accept the answer for the benefit of other users by clicking the checkmark icon next to the answer. Please read the FAQ for more information.