Re: Proposed change to asyn drvAsynIPPort for UDP sockets

[Henrique Almeida <hdante.lnls@gmail.com>]

2015-12-09 11:20 GMT-02:00 Mark Rivers <rivers@cars.uchicago.edu>:

Hi Henrique,

Thanks for the response.  The API does not currently allow passing the source address back to the asyn client.  It is only available for immediate use in drvAsynIPPort diagnostic output using ASYN_TRACEIO_DRIVER.

What looks incorrect to you in the call to sendto()?

 sendto() receives a socklen_t parameter, so the cast to int might be generating two conversions.

 

Mark

________________________________
From: Henrique Almeida [hdante.lnls@gmail.com]
Sent: Wednesday, December 09, 2015 6:35 AM
To: Mark Rivers
Cc: EPICS Tech Talk; EPICS Core-Talk
Subject: Re: Proposed change to asyn drvAsynIPPort for UDP sockets


+                nread = recvfrom(tty->fd, cbuf, sizeof cbuf, 0, &tty->farAddr.oa.sa<http://farAddr.oa.sa>, &addrlen);

This only seems to be correct if the messages are processed sequentially, first receiving, then consuming the message, then receiving one more message and so on. If the code allows receiving and consuming the messages out of order, then this is mixing the messages source addresses in tty->farAddr.oa.sa<http://farAddr.oa.sa>.

 If necessary, the remote address should be linked to the message, not to the socket, and consumed with it.

-                thisWrite = sendto(tty->fd, (char *)data, (int)numchars, 0, &tty->farAddr.oa.sa<http://farAddr.oa.sa>, (socklen_t)tty->farAddrSize);
+                thisWrite = sendto(tty->fd, (char *)data, (int)numchars, 0, &tty->farAddr.oa.sa<http://farAddr.oa.sa>, (int)tty->farAddrSize);

 Looks incorrect.


2015-12-08 16:35 GMT-02:00 Mark Rivers <rivers@cars.uchicago.edu<mailto:rivers@cars.uchicago.edu>>:

Folks,

I have found a problem with the handling of UDP sockets in drvAsynIPPort.  The problem arises when a broadcast socket is created using the IP protocol string “UDP*” in the call to drvAsynIPPortConfigure().  Calls to asynOctet->write() are OK, broadcast messages get sent correctly.  However, if a client attempts to reply to such a broadcast (using the ephemeral source port number that was sent in the broadcast message) then that reply is rejected by the host that sent the broadcast.

The problem is that the current version of drvAsynIPPort always calls connect() on all sockets, including UDP sockets.  It then calls send() and recv() to write and read from the socket respectively.  This does not work correctly in the case of UDP broadcast sockets.


I have created a new issue for the problem on github:

https://github.com/epics-modules/asyn/issues/11

The problem is fixed by doing the following for broadcast UDP sockets:

- Don't call connect()

- Call sendto() rather than send()

- Call recvfrom() rather than recv()



Eric Norum and I cannot think of a reason not to make the above changes for all UDP sockets, not just broadcast sockets.  I have made a new udp_fixes branch on github that implements the above changes for all drvAsynIPPort UDP ports.



https://github.com/epics-modules/asyn/tree/udp_fixes



I have tagged the current version of that branch as the R4-28beta1 release.


I would like to encourage comments and testing of these changes before I release asyn R4-28.  If you currently use UDP sockets with asyn please try to test by either checking out the udp_fixes branch or downloading the tar or zip file for R4-28beta1 release.

Thanks,
Mark