How to let tshark reassemble the fragments on GRE?

gre
reassemble
retag add tags

I have captured on pcap with gre traffic. and could filter out the gre traffic by:

[root@vmtca-2101 mzhan017]# tshark -r ims_merged_bad.pcap  "ip.proto == 47"
Running as user "root" and group "root". This could be dangerous.
42037 144.861194     10.0.0.7 → 55.0.0.5     IPv4 1512 Fragmented IP protocol (proto=UDP 17, off=0, ID=079a)
42039 144.861213     10.0.0.7 → 55.0.0.5     IPv4 69 Fragmented IP protocol (proto=UDP 17, off=1448, ID=079a)

These two fragments are one SIP INVITE message.

So I tried to filter the SIP with following command.

tshark -2 -r ims_merged_bad.pcap -R "ip.proto == 47"   "sip.CSeq.method==\"INVITE\""

But couldn't get the INVITE message out.

Does tshark support this kind of re-assemble? Any suggestion for this demand?

Thanks, Mark

mzhan017

asked 2023-05-17 06:42:51 +0000, updated 2023-05-17 21:42:19 +0000

edit flag offensive 0 remove flag close merge delete

Comments

By the way, the fragments happened on IP over GRE.

mzhan017 (2023-05-17 06:47:26 +0000) edit

What do you get if you try this?

tshark -2 -r ims_merged_bad.pcap -o ip.defragment:TRUE -Y "sip.CSeq.method == \"INVITE\""

cmaynard (2023-05-17 15:05:19 +0000) edit

These two fragments are one SIP INVITE message.

So presumably the first fragment is 1448 bytes long, as the second fragment has a fragment offset of 1448 bytes. If not, then either not all fragments are present or there's something wrong with the fragmentation.

Guy Harris (2023-05-18 07:38:05 +0000) edit

add a comment see more comments

1 Answer

Sort by

oldest

newest

most voted

Seems to be very similar to this question.

As the IP reassembly doesn't appear to have completed there will be no attempt to call the SIP dissector, instead the IP fragments will be displayed.

If you disable IP reassembly (using -o ip.defragment:FALSE), the fragment in packet 42037 might be dissected as SIP as it should have the SIP header.

23.8k

grahamb

answered 2023-05-17 08:55:04 +0000

edit flag offensive 0 remove flag delete link

Comments

As the IP reassembly doesn't appear to have completed

Perhaps it was, but @mzhan017 hasn't shown the packets from the second tshark -2 ... command, although that command as shown contains a syntax error, which results in:

tshark: Display filters were specified both with "-Y" and with additional command-line arguments.

cmaynard (2023-05-17 15:04:24 +0000) edit

Hello Grahamb, Thanks for your support. Yes, with -o option, the SIP INVITE could be showed.

Does this mean, tshark has no such functionality to re-assemble the fragements on GRE, with two-pass analysis?

Thanks, Mark

mzhan017 (2023-05-17 21:40:29 +0000) edit

hello cmaynard, sorry for misleading. I pasted wrong command. It should be -R.

mzhan017 (2023-05-17 21:43:12 +0000) edit

If the IP fragments had been reassembled then wouldn't they show up as SIP?

grahamb (2023-05-18 07:34:17 +0000) edit

Wireshark will happily reassemble fragmented IP packets, but it MUST see ALL the fragments to complete reassembly.

Using the o ip.defragment:FALSE option allows at least the SIP header to be dissected in the first packet but for subsequent fragments, that may be only part of the SIP message, the SIP dissector won't be able to dissect them.

grahamb (2023-05-18 07:38:20 +0000) edit

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer

How to let tshark reassemble the fragments on GRE? edit

Comments

1 Answer

Comments