Don't Fragment (DF) bit in real time UDP on XPC

Dear all,

Is there a way to unset the Don't Fragment (DF) bit in the header of UDP packets sent using an XPC target running the real time UDP send block?

To give you a description of my problem:

I have a device that is controlled over UDP. I'd like to control this device using a desktop running XPC target, which has a dedicated network card (Intel 82558) for real time UDP.

To test my device I made a simple Simulink model (non real time) and used it to send some UDP packets from my laptop to the device, without the XPC desktop involved. This works fine, and I can control the device.

But if I send the exact same packets from the XPC using real time UDP, nothing happens. I used Wireshark to compare the packets coming from my pc and from the XPC, and the data is exactly the same. However, I noticed that the packets coming from the XPC have the Don't Fragment (DF) bit set in their header, while this is not the case for packets coming from my laptop.

I suspect that my device needs fragmentation to handle the packets, and therefore drops packets if the DF bit is set.

Is there any way to make sure the DF bit is not set for packets coming from the XPC?

Best,

Mark

[Walter Roberson]

What is your payload size?

[Mark V]

They are relatively small packets, e.g. containing a string such as "set state enable". Payload won't exceed approx. 200 bytes, so I guess the maximum transmission unit shouldn't be exceeded.

(This made me wonder why the device I'm sending to wants to fragment the packets in the first place, but I can't make any modifications to it and have to take it as it is.)

[Walter Roberson]

If the packet fits within the MTU, then according to the standards, setting DF is not an error. Setting DF on a call is a technique used in some operating systems to force the packet to not be buffered, which connects to the fact that UDP can be used in Socket mode or in Stream mode.

It is possible that the device's stack does not handle the DF bit properly.

I do not know if the DF bit is configurable in XPC.

Answer 1

[Suneesh]

It is not possible to UN-set the DF flag for packets that are sent from a target using real-time UDP blocks. The blocks are designed this way due to the real-time UDP protocol stack in the target currently not supporting fragmented packets. So if the target is unable to send fragmented IP packets the "do not fragment" flag should always be set.

I tested using the (non real-time UDP) packets in the xPC Target library. They behave similarly, except that when run on the host they can cause fragmentation since the Windows (host OS) drivers are used. DId you not use these blocks? If you did then as long as the data is accommodated within the max MTU size (1512) of the Ethernet packets, the DF bit would still be set. Only when the pack size exceeds this, will the DF flag be unset since the data will be fragmented and sent out.

[Walter Roberson]

If the target cannot send out fragmented packets then it does not need to set the DF bit. The DF bit is paid attention to by routers, and is not paid attention to by the remote end as a hint that small-ish packets are expected in response. It is legal for networks to be asymmetric as to what MTU they support in different directions. There is nothing in IP packets themselves to negotiate MTU: it is handled by PMTUD which involves setting the DF bit on packets of various sizes and seeing the point at which you stop getting the ICMP FragNeeded response from the router.

If the target allows calls with payload sizes beyond what the network can handle as a single packet, and sets DF on the packets then it is requiring the network discard the packets and send back ICMP FragNeeded even though the network might have been perfectly capable of fragmenting the packets and delivering them to the remote device that had no limitations on fragmented packets.

Setting the DF bit on outgoing packets is not a mechanism for requesting that the remote end (and network inbetween) does not fragment packets being sent to the target.

There is no mechanism for requiring that the other end send only non-fragmented packets for the simple reason that support of packet fragmentation is mandatory in the RFCs.

[Mark V]

Update 1:

I can build a model on the XPC with a non-real time UDP block, and send packets using the Ethernet port which is also used for the host-target connection. These packets do NOT have the DF flag set, and can be used to control my device (but not in real time).

However, as soon as I use the real time UDP block to send packets from the dedicated network card, the DF flag becomes set.

If you go to the real time UDP library and look under the mask of the "Network Configuration" block, you will find 5 sub-blocks. I think the communication protocol is set up in the "IP Init" block. You can also set the packet TTL here, which is also part of the packet header. There also is a "Flag" parameter in this block, but I don't know what this does yet. In the underlying S-function this parameter is typecast as a uint32. So I think it covers more than the 3 bit DF flag in the packet header.

I will try today if I can modify something in the packet header by changing this Flag parameter.

(In one of the other blocks you can also set the MTU. I tried to change this, but this doesn't do anything with the DF flag).

Update 2:

Changing the Flag parameter in the "IP Init" block doesn't seem to do anything. I can set it to any value and nothing changes. Setting the other parameters (Type of Service, Initial Packet ID, TTL) do change their corresponding bits in the packet header.

[Mark V]

Update 3: I give up

[Walter Roberson]

Sorry, I don't have the needed toolbox here to play with.

[Mark V]

Thanks for the feedback nevertheless :)

[Suneesh]

The "Flags" parameter on the IP Init block does not have anything to do with the DF flag. It sets other flags that are used internally, such as disabling ICMP etc.