Disabling "Reassemble Fragmented IPv4 datagrams" preference in IPv4 protocol for tshark?

asked 2023-05-15 09:10:54 +0000

merveyil
1 ●13 ●3

updated 2023-05-15 09:12:42 +0000

Hi, i am using tshark on Linux and i wrote a script that finds number of SIP packets over SIP ports and IPs. My script capture tshark for 10 seconds then count the number of SIP packets according to some filters. I checked the pcap file that created by my script on wireshark. According to filter in the script i saw there is 0 packet on wireshark. The filter i use in the script is below:

sip && !sip.CSeq.method == OPTIONS && ip.src == "[SOURCE_IP]" && udp.srcport == 5060

But when we analyze the same pcap from another wireshark we saw that there is 10 packets according to above filter. After some research we realized that difference is in the preferences of IPv4 protocol. When we disabled the "Reassemble Fragmented IPv4 datagrams" preference in IPv4 protocol in my wireshark we saw that there is 10 packets. So i need the disable this feature on tshark Linux. However i can not find a way to do it. Do you know if there is a way to disable "Reassemble Fragmented IPv4 datagrams" option for tshark?

edit retag flag offensive close merge delete

Comments

You can access the pcap file that i use from below link: pcap_file

I also prepared a README file please also read this so you can see which ip i use for my filter:

README file for test

merveyil ( 2023-05-16 07:14:59 +0000 )edit

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2023-05-16 06:02:22 +0000

SYN-bit

18528 ●9 ●338 ●255 https://SYN-b.it

updated 2023-05-16 06:02:59 +0000

Are you sure you need to disable IP fragment reassembly to make your filter work? I expect you will need to enable it to make the filter work correctly.

Can you try:

/usr/sbin/tshark -o ip.defragment:TRUE -r /tmp/temp.pcap -R "sip && !sip.CSeq.method == OPTIONS && ip.src == [SOURCE_IP] && udp.srcport == 5060" | wc -l

If that does not work, maybe sharing your file is an option, even with enough karma, you can't share pcap files directly on here, but @Jasper wrote a good article on how to share pcap files. Have a look at: https://blog.packet-foo.com/2016/11/t...

edit flag offensive delete link

Comments

I tried both setting the option to TRUE and FALSE but it does not work. I will share my pcap file according to article that you shared. Thanks.

merveyil ( 2023-05-16 06:13:54 +0000 )edit

Why tracewrangler tool change protocols for packets? It changed protocols SIP to UDP so my pcap file became useless since i cannot use my below filter: "sip && !sip.CSeq.method == OPTIONS && ip.src == [SOURCE_IP] && udp.srcport == 5060"

merveyil ( 2023-05-16 06:57:59 +0000 )edit

I shared my pcap file.

merveyil ( 2023-05-16 07:16:38 +0000 )edit

Thank you for sharing your pcap-file, I ran some tests myself and agree you should disable the ip defragmentation because you only captured the first fragments of fragmented traffic. This is because the BPF filter uses a port filter, which is only available in the first fragment. If you change your filter to include (all) IP fragments, you will probably not have this problem, but of course you might be capturing too many IP fragments to other ports. You can try the following capture filter:

udp and (port 5065 or port 5060 or ip[6:2] & 0x1fff > 0)

As for why it does not work as expected with the current pcap file, can you share the output of the following commands:

tshark -v 
tshark -G currentprefs | egrep "^#?(ip|udp|sip)\."
tshark -o ip.defragment:FALSE -r temp.pcap.pcapng -Y 'ip.src == 192.168.199.154'

Here is ...(more)

SYN-bit ( 2023-05-16 11:13:55 +0000 )edit

Thank you for all information.

You can see the outputs of commands:

tshark-v
TShark 1.10.14 (Git Rev Unknown from unknown)

Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GLib 2.56.1, with libpcap, with libz 1.2.7, with POSIX
capabilities (Linux), without libnl, with SMI 0.4.8, with c-ares 1.10.0, with
Lua 5.1, without Python, with GnuTLS 3.3.29, with Gcrypt 1.5.3, with MIT
Kerberos, without GeoIP.

Running on Linux 3.10.0-1160.88.1.el7.x86_64, with locale en_US.UTF-8, with
libpcap version 1.5.3, with libz 1.2.7.
Intel(R) Xeon(R) CPU E5-2658 0 @ 2.10GHz

Built using gcc 4.8.5 20150623 (Red Hat 4 ...

(more)

merveyil ( 2023-05-16 11:30:48 +0000 )edit

see more comments

answered 2023-05-16 10:16:07 +0000

Chuckc
3023 ●6 ●608 ●20

p$ tshark -v
TShark (Wireshark) 4.0.4 (v4.0.4-0-gea14d468d9ca).

p$ tshark  -r temp.pcap.pcapng -R "sip and not sip.CSeq.method == OPTIONS and ip.src== 192.168.199.154 and udp.srcport == 5060"
tshark: -R without -2 is deprecated. For single-pass filtering use -Y.

p$ tshark  -r temp.pcap.pcapng -2 -R "sip and not sip.CSeq.method == OPTIONS and ip.src== 192.168.199.
154 and udp.srcport == 5060"
    1 0.001140326 192.168.199.154 47.168.116.58 SIP/SDP sll:ethertype:ip:udp:sip:sdp  any    Request:
INVITE sip:[email protected];lr;transport=UDP |
    2 0.834240658 192.168.199.154 47.168.116.58 SIP/SDP sll:ethertype:ip:udp:sip:sdp  any    Request:
INVITE sip:[email protected];lr;transport=UDP |
    3 1.543213586 192.168.199.154 47.168.116.58 SIP/SDP sll:ethertype:ip:udp:sip:sdp  any    Request:
INVITE sip:[email protected];lr;transport=UDP |
    4 2.132210386 192.168.199.154 47.168.116.58 SIP/SDP sll:ethertype:ip:udp:sip:sdp  any    Request:
INVITE sip:[email protected];lr;transport=UDP |
    5 2.996731915 192.168.199.154 47.168.116.58 SIP/SDP sll:ethertype:ip:udp:sip:sdp  any    Request:
INVITE sip:[email protected];lr;transport=UDP |
    6 3.771985149 192.168.199.154 47.168.116.58 SIP/SDP sll:ethertype:ip:udp:sip:sdp  any    Request:
INVITE sip:[email protected];lr;transport=UDP |
    7 4.420978089 192.168.199.154 47.168.116.58 SIP/SDP sll:ethertype:ip:udp:sip:sdp  any    Request:
INVITE sip:[email protected];lr;transport=UDP |
    8 5.119037680 192.168.199.154 47.168.116.58 SIP/SDP sll:ethertype:ip:udp:sip:sdp  any    Request:
INVITE sip:[email protected];lr;transport=UDP |
    9 5.777726936 192.168.199.154 47.168.116.58 SIP/SDP sll:ethertype:ip:udp:sip:sdp  any    Request:
INVITE sip:[email protected];lr;transport=UDP |
   10 9.288839447 192.168.199.154 47.168.116.58 SIP/SDP sll:ethertype:ip:udp:sip:sdp  any    Request:
INVITE sip:[email protected];lr;transport=UDP |

edit flag offensive delete link

add a comment

answered 2023-05-15 09:47:31 +0000

grahamb

flag of United Kingdom of Great Britain and Northern Ireland

23835 ●4 ●973 ●227 https://www.wireshark.org

All Wireshark preference settings can also be set via tshark options using the -o <setting name>:<value> flag.

To find the setting name use tshark -G defaultprefs

In your case the setting is ip.defragment so use -o ip.defragment:FALSE

edit flag offensive delete link

Comments

Thank you so much. I have one more question. I don't want to change general settings of tshark so can i change this option only for my script? So it will be like below in my script:

/usr/sbin/tshark -r -o ip.defragment:FALSE /tmp/test.pcap -R "sip && !sip.CSeq.method == OPTIONS && ip.dst == $INTERNAL_IF_IP && udp.dstport == $INTERNAL_PORT" |wc -l`

I think when above command runs it will change general settings of tshark? Is there a way to do it only for my script?

merveyil ( 2023-05-15 10:06:51 +0000 )edit

A -o flag only changes the settings for that script run, not your saved preferences. You can check this by looking at the output of tshark -G currentprefs before and after running the script.

grahamb ( 2023-05-15 10:24:45 +0000 )edit

I tried this option in my script but it does not work. My script still finds 0 packets. This is how i add the configuration:

/usr/sbin/tshark -o ip.defragment:FALSE -r /tmp/temp.pcap -R "sip && !sip.CSeq.method == OPTIONS && ip.src == [SOURCE_IP] && udp.srcport == 5060" | wc -l

merveyil ( 2023-05-15 11:02:36 +0000 )edit

Works for me, although I'm not able to test with your capture file unless you share it.

I used the capture file attached to bug 2651 with the commands:

tshark -r sas.cap ip.reassembled.length

which showed plenty of reassembled packets and

tshark -r sas.pcap -o ip.defragment:FALSE ip.reassembled.length

which showed no reassembled packets.

I'm not entirely what you're doing as disabling IP reassembly may mean that no packets of the required protocol will be displayed as they aren't reassembled and thus may not fall into the protocol filter, i.e. SIP.

grahamb ( 2023-05-15 11:32:02 +0000 )edit

I cannot share my capture file because i don't have enough point to do it.

merveyil ( 2023-05-15 11:51:24 +0000 )edit

see more comments