This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

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:

$ tshark -r 218423_1.cap00 -c 10 1 0.000000 10.0.226.129 -> 10.0.226.133 SIP 1251 Request: OPTIONS sip:10.0.226.133;transport=tcp 2 0.000835 10.0.226.133 -> 10.0.226.129 SIP 1337 Status: 200 OK 3 5.091195 10.0.226.133 -> 10.0.226.129 SIP/SDP 1025 Request: INVITE sip:[email protected];user=phone, with session description 4 5.094097 10.0.226.129 -> 10.0.226.133 SIP 359 Status: 100 Trying 5 5.122237 10.0.226.129 -> 10.0.226.133 IPv4 132 Fragmented IP protocol (proto=UDP 17, off=1480, ID=d618) 6 5.169126 10.0.226.129 -> 10.0.226.133 IPv4 825 Fragmented IP protocol (proto=UDP 17, off=1480, ID=d619) 7 5.171658 10.0.226.133 -> 10.0.226.129 SIP 840 Status: 100 Trying 8 5.176699 10.0.226.129 -> 10.0.226.134 RTP 218 PT=ITU-T G.711 PCMA, SSRC=0x33B61227, Seq=1, Time=0 9 5.177610 10.0.226.129 -> 10.0.226.134 RTCP 134 Receiver Report Source description
10 5.196590 10.0.226.129 -> 10.0.226.134 RTP 218 PT=ITU-T G.711 PCMA, SSRC=0x33B61227, Seq=2, Time=160

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.

$ tshark -r 218423_1.cap00 sip -c 10 1 0.000000 10.0.226.129 -> 10.0.226.133 SIP 1251 Request: OPTIONS sip:10.0.226.133;transport=tcp 2 0.000835 10.0.226.133 -> 10.0.226.129 SIP 1337 Status: 200 OK 3 5.091195 10.0.226.133 -> 10.0.226.129 SIP/SDP 1025 Request: INVITE sip:[email protected];user=phone, with session description 4 5.094097 10.0.226.129 -> 10.0.226.133 SIP 359 Status: 100 Trying 7 5.171658 10.0.226.133 -> 10.0.226.129 SIP 840 Status: 100 Trying 12 5.216181 10.0.226.129 -> 10.0.226.133 SIP 1026 Request: PRACK sip:[email protected]:5060 14 5.219458 10.0.226.133 -> 10.0.226.129 SIP 1385 Status: 200 OK 483 8.250769 10.0.226.133 -> 10.0.226.129 SIP 1498 Status: 180 Ringing 487 8.267270 10.0.226.129 -> 10.0.226.133 SIP 1028 Request: PRACK sip:[email protected]:5060 488 8.270899 10.0.226.133 -> 10.0.226.129 SIP 1387 Status: 200 OK

As can be seen packets 5 and 6 (which in this I know form an INVITE) dont get shown. I have also tried the -o ip.defragment:TRUE and also writing the output to file but it still doesnt change anything.

For reference I am capturing them with tcpdump using the following BPF: ( vlan and (port 5060 or ip[6:2] & 0x1fff != 0 ))

Any Advice would be much appreciated

asked 08 Feb '13, 02:12

Marv's gravatar image

Marv
31226
accept rate: 0%

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

(12 Feb '13, 01:10) 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.

(12 Feb '13, 01:59) grahamb ♦

You're missing the first part of your IP fragmented packets. That's because you drop them with your capture filter.

That filter says:

vlan

oke, your on a vlan, make sure there's a tag and compensate for it,

and (port 5060

oke, you want UDP (and TCP) port 5060, the SIP signaling port,

or ip[6:2] & 0x1fff != 0 )

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 port 5060 filter.

permanent link

answered 08 Feb '13, 02:57

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

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

  1. either the first fragments of packets 5 and 6 are not in the capture file. What is the output of tshark -r 218423_1.cap00 -R "ip.id==0xd618 or ip.id==0xd619"? Do you see only the two fragments or also the first parts of these IP packets? I expect to see only two fragments, as there were no frames with len=1500 (20 bytes IP header and 1480 bytes IP payload) before packet 5.)

  2. or IP reassembly is not enabled in the profile that tshark uses in which case you might want to try tshark -o ip.defragment:TRUE -nlr 218423_1.cap00 -R sip

permanent link

answered 08 Feb '13, 13:08

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

My expectaion is tshark will re-assemble the fragmented IP packets before it passes them to the higher layer dissectors.

Yes, it should/will do that.

But this doesnt appear to happen. If I open the same file with the Wireshark GUI application it does this fine.

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
Kurt

permanent link

answered 08 Feb '13, 12:27

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 08 Feb '13, 12:29

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×832
×109
×78
×30
×27

question asked: 08 Feb '13, 02:12

question was seen: 7,652 times

last updated: 12 Feb '13, 01:59

p​o​w​e​r​e​d by O​S​Q​A