Fragmented UDP packet problems

[dacoast]

I am developing an application using Netburner Mod-5272s for a private vehicle network. The network uses a custom message protocol built on UDP protocol.
During initial connection with the Network (and subsequent vehicle configuration changes) a custom server provides DHCP info and a vehicle directory service (extended DNS basically).

To get the initial directory service, the Netburner application makes a request, then processes the response. The response is typically a fragmented UDP packet on the order of 1500-4500 bytes.

To get this scheme working in simulation, I needed to enable UDP packet fragmentation and rebuild the system files. Everything seems to work as expected in a simulated environment.

Unfortunately, once on the vehicle, the Netburner modules don't want to accept the fragmented UDP packets. A wireshark trace shows that
they are getting to the Netburner. Checking message counts on the Netburner module shows an increase in the "fragment" count, but they
are never received by the task processing UDP messages.

This works in a simulated environment with the same messages, and it also works if the UDP packet is small enough not to be fragmented.

I am using NDK 2.3RC3 (did not work withh NDK 2.3RC2 either).

Any help or guidance would be appreciated.

Thanks,
Doug

[rnixon]

Maybe a device in the truck has the same IP address, or another type of conflict? I don't think your wireshark trace can prove they are getting to the netburner, but only that they are getting to the pc. Whats between the pc and the netburner device?

[thomastaranowski]

Some addition details of the network topology would be useful. Given the information so far, I suspect the following scenarios:

* Multiple senders are broadcasting fragmented packets. By default, the netburner only allows a limited number of fragments(4 or so) to be in flight at the same time. I have not looked at the implementation, but it could be that your fragmented payloads are being dropped because they are arriving interleaved with other fragments, then dropped.

* The packets could be arriving at the netburner, but then dropped for any variety of reasons. It could be that the destination IP address is incorrect, or udp/ip checksum is invalid, destination port not bound, etc.

[dacoast]

Problem Solved! Thanks for the suggestions.

I had inserted a network hub in series between the Netburner module and the switch of the vehicle network to verify that the fragmented packets were reaching the Netburner.
The suggestion that the packets were being dropped by the Netburner proved correct!

I discovered that fragmented UDP packets could not be received by my
Netburner module if the TOS field of the IP header was non-zero.
The TOS field of structures within Netburner code are apparently used to store "status" info while accumulating packet fragments.
Further investigation showed what I believe to be mistakes in the coding of UDP.cpp from the Nburn/system directory (I submitted a support ticket reporting the problem).

The problem (and my suggested correction) is in the function:

void ProcessUdpFragment(Poolptr pp)

The statement "if (pIp->bTos==FSTATE_BUFFREE) freepacket=pb;"
should be "if (pIpBuf->bTos==FSTATE_BUFFREE) freepacket=bb;"

The pIp->bTos is referencing the TOS field of the incoming packet when
it should reference the packet stored in the fragment buffer.

Likewise, later in the code, the statement
"if (pIp->bTos==FSTATE_BUFINCOMPLETE)"
should be replaced with
"if (pIpBuf->bTos==FSTATE_BUFINCOMPLETE)"

With these changes, I am now able to receive fragmented UDP packets regardless of the
value of the TOS field in the IP header.

[Chris Ruff]

OK dacoast

You got me. Where is bb declared? heck if I can find it, but the compiler knows all about it.

Chris