Unrecognized UDP Packets

[kwebster]

I have 4 FieldPoint controllers (cFP-2120, cFP-2020, FP-2010 & FP-2015) on a private network.  On the cFP-2120 I have an application with a loop waiting on UDP packets on port 10040.   About once an hour this application receives an unexpected UDP packet from each of the other 3 FieldPoint controllers.  The remote port for these unexpected packets is 1026.  The host application from which the controller expects to receive UDP packets is not running.  Does anyone know what generates these packets?  Also, if port 10040 is not available, what range of ports is safe to use?

[rolfk]

---

@kwebster wrote:
I have 4 FieldPoint controllers (cFP-2120, cFP-2020, FP-2010 & FP-2015) on a private network.  On the cFP-2120 I have an application with a loop waiting on UDP packets on port 10040.   About once an hour this application receives an unexpected UDP packet from each of the other 3 FieldPoint controllers.  The remote port for these unexpected packets is 1026.  The host application from which the controller expects to receive UDP packets is not running.  Does anyone know what generates these packets?  Also, if port 10040 is not available, what range of ports is safe to use?

---

Well, UDP is tricky and the port numbers just as much. In UDP you can also broadcast messages by sending them to the adress 255.255.255.255 and this is often used to discover devices on a subnet. I suspect the Fieldpoint devices to periodically send out such broadcast messages to do some resynchronization such as requesting for time servers or something along these lines in the whole range of Logos protocols that are integral part of the Fieldpoint/Lookout/LabVIEW DSC scheme.

As to the originating port this is usually not very indicative. An application is free to choose whatever port it finds available to send out UTP packets and this can in fact be used dynamically. The port number being close to 1024 indicates that the sender application might just start above the reserved port limit of 1024 and trying to open a port until it succeeds.
Only the listener (or server) is supposed to use a well known port so that it can be contacted by clients. It also seems that your port 10040 is used by Fieldpoint for some sort of service here.

Especially with UDP I think it is a good idea to make your servers forgiving about unkown packages arriving. Otherwise your software can easily be dwarted into DOS or similar situations by simply broadcasting some dummy data to the port used.

Rolf Kalbermatter

Message Edited by rolfk on 05-09-2006 11:01 PM

[kwebster]

It turns out that the unexpected UDP packets are data packets that my applications on the other controllers are broadcasting at 2 Hz. However, they are broadcasting to different ports (10028, 10030 & 10039),  not 10040. The unexpected packets show up about 3 per hour, not 2 Hz and in groups of 3.  I am running a test where I am reading UDP packets on port 10040 on a Windows XP host at the same time that the controller is reading UDP packets on the same port to see if both drivers see the same unexpected packets.  If they do, then the problem is probably on the send side. Otherwise, the problem is on the receive side.  This assumes the problem is not duplicated on both the Windows XP host and the FieldPoint controller.

The code that broadcasts the packets is straight-forward with the port number specified as a constant.  I don't see how it can be broadcasting 1 packet per hour (1 out of 7200) to a different port.  In fact, I changed the receive side port to 63040 and it still sees the unexpected packets.  At the same time, I don't see how the receive side can occaisonally read on a different port.  The port number on the UDP read is also specified as a constant.

[kwebster]

It appears that the problem is on the receive side.  The test application reading UDP packets on a Window XP pc did not see any unexpected packets over a 18 hour period, while the FieldPoint controller application saw unexpected broadcast packets 28 times over the same period of time.  It appears that the FieldPoint driver has a bug which occasionally allows broadcast packets addressed to another port to be passed to the application.

[kwebster]

I added diagnostic code to my FieldPoint application so that it logs all unexpected UDP packets.  The packet source is completely random (among the 3 other FieldPoint controllers), and the packets do not come in groups of 3.  Sometimes 2 or 3 packets in a row will come from the same source.

At this point I began to seriously consider that the FieldPoint driver has a bug.  Also, the FieldPoint controller application was originally coded to close and reopen the UDP socket when an error was detected.   Also, the timeout value was set to 6000 ms.  So the socket was being closed and reopened every 6 seconds when not receiving UDP packets.  Assuming that the problem was in the driver, the most likely time for the problem to occur is when the socket is being reopened, so I added code to test for this condition.   Also, the frequency of the unexpected packets should increase with the frequency of broadcast packets being sent, so I wrote a small LabVIEW application to broadcast packets from a Windows host at a rate of 1 kHz.  The results indicate that the 9 times out of 10 the unexpected packet is received right after reopening the socket and the frequency of unexpected packets increased from 28 per 18 hours to 100 per 15 minutes.  This confirms that there is a bug in the driver.

The work-around is to test for the timeout condition and not close and re-open the socket.  This should reduce the probability of recieving an unexpected packet by 90%.  The other 10% can be handled by adding a signature to the packet and throw away the unexpected packets.