0

We have an application doing udp broadcast. The packet size is mostly higher than the mtu so they will be fragmented.

tcpdump says the packets are all being received but the application doesn't get them all.

The whole stuff isn't happening at all if the mtu is set larger so there isn't fragmentation. (this is our workaround right now - but Germans don't like workarounds)

So it looks like fragmentation is the problem.

But I am not able to understand why and where the packets get lost.

The app developers say they can see the loss of the packets right at the socket they are picking them up. So their application isn't losing the packets.

My questions are:

Where is tcpdump monitoring on linux the device?

Are the packets there already reassembled or is this done later?

How can I debug this issue further?

DrNO
  • 1
  • 1
  • 1
  • The percentage of fragmented udp packets not received is getting more if there is more udp broadcast traffic on the network (as well fragmented packets) - even if these broadcast packages are not received by the system where the other packets are lost. – DrNO Jan 13 '18 at 20:24
  • If you are seeing all of the pieces arrive in tcpdump, your problem is somewhere else. – David Hoelzer Jan 14 '18 at 13:04
  • What is tcpdump reporting? Is it just saying that 0 packets dropped by kernel? I don't think tcpdump would reassemble fragmented IP fragments (Wireshark would though). I could be wrong about this last part though. – crchurchey Feb 06 '18 at 04:22

1 Answers1

0

tcpdump uses libpcap which gets copies of packets very early in the Linux network stack. IP fragment reassembly in the Linux network stack would happen after libpcap (and therefore after tcpdump). Save the pcap and view with Wireshark; it will have better analysis features and will help you find any missing IP fragments (if there are any).

crchurchey
  • 188
  • 6