Bug #5367
closedgsmtap_log not taking into account MTU size and ip fragmentation occurring.
0%
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
Related issues
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?
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?
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?
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.
Updated by pespin about 1 year ago
I created ticket https://gitlab.com/wireshark/wireshark/-/issues/19171 to follow up the issue upstream.
Updated by pespin about 1 year ago
- Related to Bug #4869: wireshark: Support dissecting LLC frames on top of RLCMAC (E)GPRS data blocks added
Updated by pespin about 1 year 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.