Project

General

Profile

Actions

Bug #5367

closed

gsmtap_log not taking into account MTU size and ip fragmentation occurring.

Added by pespin over 2 years ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
12/21/2021
Due date:
% Done:

0%

Spec Reference:

Description

When printing a huge line using gsmtap_log, using something like osmo_hexdup(data, 999):

    LOGP(DLLSK, LOGL_DEBUG, "llsk_rx_cb() SAP=%u (%u bytes): %s\n", oph->sap,
         msgb_length(oph->msg), osmo_hexdump(msgb_data(oph->msg), msgb_length(oph->msg)));

It can be seen in wireshark how it is sent in 3 packets because the MTU size of 1520 is not enough. As a result, one sees a gsmtap_log message followed by 2 "fragmented IP protocol" packets.

148    15:54:25.323044    Dec 21, 2021 16:54:25.323044000 CET    172.18.33.20    49279    172.18.33.203    4729    GSMTAP    1520    llsk_rx_cb() SAP=3 (991 bytes): 1e 00 00 00 28 23 00 01 ac 12 21 cb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 03 03 51 00 67 00 3c 00 00 00 00 00 00 00 00 00 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
149    15:54:25.323046    Dec 21, 2021 16:54:25.323046000 CET    172.18.33.20        172.18.33.203        IPv4    1520    Fragmented IP protocol (proto=UDP 17, off=1480, ID=9f09)
150    15:54:25.323046    Dec 21, 2021 16:54:25.323046000 CET    172.18.33.20        172.18.33.203        IPv4    194    Fragmented IP protocol (proto=UDP 17, off=2960, ID=9f09)

I attach a pcap with the related 3 packets.

Ideally, gsmtap_log should take into account (at least the local) MTU and split the log line into UDP messages, each one with a gsmtap_log header.


Files

gsmtap_ip_frag.pcap.gz gsmtap_ip_frag.pcap.gz 283 Bytes pespin, 12/21/2021 04:15 PM

Related issues

Related to OsmoPCU - Bug #4869: wireshark: Support dissecting LLC frames on top of RLCMAC (E)GPRS data blocks New11/26/2020

Actions
Actions #1

Updated by laforge over 1 year ago

  • Status changed from New to Feedback
  • Assignee set to pespin

why would application-level splint in several UDP packets be preferable to using IP fragmentation?

In the end, you need to transmit multiple packets if you exceed the MTU. Wether you do it in the application or in the kernel.

Why implement the segmentation in libosmocore and not simply make use of the IP level fragmentation?

Actions #2

Updated by pespin over 1 year ago

  • Assignee changed from pespin to laforge

laforge you mean why not leave it as it is now? Because then the log lines don't show up properly in wireshark, you cannot read the text in the usual column. Open the attached pcap and you will see the issue easily.
Maybe instead we can simply improve the gsmtap_log dissector to keep state between UDP packets?

Actions #3

Updated by laforge over 1 year ago

  • Assignee changed from laforge to pespin

Actually, I think this may be a wireshark bug. Wireshark does have the capability of IP fragment reassembly. The box "Reassemble fragmented IP datagrams" is checked/enabled in my protocol preferences for IP. But still I can observe the problem you are describing.

So either IP fragment reassembly in wireshark is not working, or the udp and/or gsmtap dissector do something wrong to not use that reassembled data? Maybe best to bring this up on the wireshark mailign list?

Actions #4

Updated by laforge over 1 year ago

See also https://wiki.wireshark.org/IP_Reassembly - but for some reason it doesn't appear to work in the pcap file you attached. This is despite the IP header checksum being correct, the packets not being short and all fragments appear to be in the pcap file. So all conditions listed on above wiki page are true.

Actions #5

Updated by pespin 9 months ago

I created ticket https://gitlab.com/wireshark/wireshark/-/issues/19171 to follow up the issue upstream.

Actions #6

Updated by pespin 9 months ago

  • Related to Bug #4869: wireshark: Support dissecting LLC frames on top of RLCMAC (E)GPRS data blocks added
Actions #7

Updated by pespin 9 months ago

  • Status changed from Feedback to Closed

Closing as upstream reported the reason for ip fragmentation not working is because the snaplen from the recording was somehow 1500 vs 1520 bytes of the packet.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)