Ask Your Question
0

How to let tshark reassemble the fragments on GRE?

asked 2023-05-17 06:42:51 +0000

mzhan017 gravatar image

updated 2023-05-17 21:42:19 +0000

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

edit retag flag offensive close merge delete

Comments

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

mzhan017 gravatar imagemzhan017 ( 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 gravatar imagecmaynard ( 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 gravatar imageGuy Harris ( 2023-05-18 07:38:05 +0000 )edit

1 Answer

Sort by » oldest newest most voted
0

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

grahamb gravatar image

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.

edit flag offensive delete link more

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 gravatar imagecmaynard ( 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 gravatar imagemzhan017 ( 2023-05-17 21:40:29 +0000 )edit

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

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

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

grahamb gravatar imagegrahamb ( 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 gravatar imagegrahamb ( 2023-05-18 07:38:20 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2023-05-17 06:42:51 +0000

Seen: 634 times

Last updated: May 17 '23