EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  <2025 Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  <2025
<== Date ==> <== Thread ==>

Subject: RE: Issues with drvAsynIPServerPort for UDP
From: Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Cc: Brands Helge <helge.brands at psi.ch>
Date: Sun, 29 Jun 2025 17:43:05 +0000

Folks,

 

The code to allow drvAsynIPServerPort to receive UDP messages on a user-specified port was added in asyn R4-23 (June 2014).

 

In asyn R4-24 (October 2014) the ability to specify a local port number was added to drvAsynIPPort, the normal asyn IP driver.

 

I just realized being able to specify a local port number allows drvAsynIPPort to have the capability to receive UDP messages on a user-specified port, which is exactly what the addition to drvAsynIPServerPort was designed to do.

 

I just tested that my Ketek driver works fine using the normal drvAsynIPPort driver configured like this:

 

drvAsynIPPortConfigure(“KETEK_SYNC_UDP”, “10.54.160.174:3141:3142 UDP”, 0, 0, 0)

 

Port 3141 is the port on the Ketek that the driver will send messages to.  In the case of the Ketek driver this is not used, because this driver does not send any messages on this port.

Port 3142 is the port on the IOC machine to which the Ketek will stream UDP data.

 

The drvAsynIPPort driver does not have any of the issues that the UDP implementation in drvAsynIPServerPort does.

 

  • It returns maxchars bytes, not maxchars-1.
  • It does not return until the specified timeout has expired if data is not available, and it returns asynTimeout when this happens.
  • It does not have the buffer overflow potential.
  • It correctly protects shared data with a mutex.

 

The drvAsynIPPort implementation also allows for sending data to the remote device, which the drvAsynIPServerPort implementation does not.

 

For these reasons I propose to remove the UDP implementation in drvAsynIPServerPort in the next release of asyn.

 

Can anyone think of a reason not to do that, or is there something that the drvAsynIPServerPort driver can do that the drvAsynIPPort driver cannot do for reading UDP data?

 

Thanks,

Mark

 

 

 

From: Mark Rivers
Sent: Saturday, June 28, 2025 5:03 PM
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Cc: Zimoch Dirk (PSI) <dirk.zimoch at psi.ch>; Brands Helge <helge.brands at psi.ch>
Subject: Issues with drvAsynIPServerPort for UDP

 

Folks,

 

Back in 2014 Dirk and Helge added support for receiving messages sent from a UDP device to drvAsynIPServerPort.  I am trying to use that now to receive data sent from a Ketek detector.  In one mode it streams data using UDP to a user-specified IP address and port.

 

It have this basically working in my EPICS driver using drvAsynIPServerPort.

 

However, I have identified 4 issues with drvAsynIPServerPort.  I have documented them here:

 

This is the text of that issue:

  1. It is using maxchars-1 rather than maxchars, so it returns 1 fewer bytes than it should. https://github.com/epics-modules/asyn/blob/e417caf2c4a4332e682635c67bd32a0c4d964fc3/asyn/drvAsynSerial/drvAsynIPServerPort.c#L196
  2. If there is no data available when readIt is called then it simply sleeps for 1 ms and sets thisRead=0 https://github.com/epics-modules/asyn/blob/e417caf2c4a4332e682635c67bd32a0c4d964fc3/asyn/drvAsynSerial/drvAsynIPServerPort.c#L192 and returns asynSuccess and *nbytesTransfered=0. It seems to me that it should loop for the specified timeout waiting for the connectionListener to fill the buffer before returning nRead=0 if there is no data to read. If the data does not arrive then it should return asynTimeout, not asynSuccess.
  3. It is not checking the number of characters actually in the buffer, but rather always copies maxchars characters which can lead to reading beyond the end of the internal buffer, which can lead to an access violation. https://github.com/epics-modules/asyn/blob/e417caf2c4a4332e682635c67bd32a0c4d964fc3/asyn/drvAsynSerial/drvAsynIPServerPort.c#L196
  4. The buffer is being filled in the connectionListener thread, which uses the tty->UDPbufferPos variable and modifies the tty->UDPbufferSize variables here: https://github.com/epics-modules/asyn/blob/e417caf2c4a4332e682635c67bd32a0c4d964fc3/asyn/drvAsynSerial/drvAsynIPServerPort.c#L311 The buffer is being read in the readIt() method which runs in the port driver thread, and which modifes tty->UDPbufferPos and tty->UDPbufferSize variables here: https://github.com/epics-modules/asyn/blob/e417caf2c4a4332e682635c67bd32a0c4d964fc3/asyn/drvAsynSerial/drvAsynIPServerPort.c#L200 However, there is no mutex to protect the tty->UDPbufferPos and tty->UDPbufferSize variables. This seems like a serious issue, which is likely to cause corruption?

Thanks,

Mark

 

 

 


References:
Issues with drvAsynIPServerPort for UDP Mark Rivers via Tech-talk

Navigate by Date:
Prev: Issues with drvAsynIPServerPort for UDP Mark Rivers via Tech-talk
Next: RE: Issues in MCA module with XFlash detector Abdalla Ahmad via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  <2025
Navigate by Thread:
Prev: Issues with drvAsynIPServerPort for UDP Mark Rivers via Tech-talk
Next: Fix buffer overflow issue in Epics 3.15 Soltani Farani, Bushra via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  <2025