Experimental Physics and
Industrial Control System

"Johnson, Andrew N." <[email protected]> · Sat, 19 Dec 2015 16:24:56 +0000

Hi Ralph,

Please bear in mind that the code that you posted comes from the CA client, not the CA Repeater, and it's the repeater that sees the UDP packets — C++ clients get their beacons over TCP from the repeater. Inside ca_repeater() there is a statement that copies the beacon source IP address into a field of the beacon message before redistributing it, provided that address was zero in the incoming UDP message. The comments immediately above your code snippet describe this, although they call the repeater something like a fan-out server. I was reading through this yesterday and the code I looked at matched up with the comments, but I didn't check the code that actually generates the beacons.

 I don't know whether the Java library relies on the repeater so it might do things differently. Presumably Anze is using 3.15.3, could you also check against a 3.14.12 IOC in case the multi-interface changes in 3.15 broke the beacon generation code.

- Andrew

-- 
Sent from my iPad

> On Dec 19, 2015, at 3:20 AM, Ralph Lange <[email protected]> wrote:
> 
>> On December 18, 2015 11:39:30 PM GMT+01:00, Andrew Johnson <[email protected]> wrote:
>> I mis-read Anze's original description, and it now sounds to me like
>> there may be a bug in his network stack. Is it really possible to send
>> out a broadcast UDP message that has a different IP source address than
>> the address of the network interface you're sending it out from? I
>> would
>> expect something like that to only be possible if you're running as
>> root.
>> 
>> Could this me something to do with the configuration of his virtual
>> network ports, or with his Wireshark setup? I would like to see this
>> experiment repeated on a machine that has multiple real interfaces,
>> because it doesn't make sense to me.
>> 
>> - Andrew
> 
> Hi Andrew,
> 
> While you point out an interesting issue, I don't think it is really relevant for the CA problem Anze sees.
> 
> The UDP sender address gets overwritten with the address inside the payload, and that payload address (explicitly set by the IOC, root not required) seems to be always the same, independent from the network the beacon message is sent to.
> 
> The client (at least the Java one) possibly can't match the beacon sender to any of its connections, and wrongly classifies the beacon as not being relevant.
> This probably has the effect that the IOC going down is not detected properly by the client. It should not affect reconnection for a (re)appearing IOC, as reconnection attempts should always happen on all networks the client uses.
> 
> @Anze: a properly detected missing beacon is signaled by the client after ~35 seconds (twice the beacon period plus 5 seconds timeout for a TCP ping). Sending SIGSTOP/SIGCONT to the IOC is a good way to simulate a network-down and recover situation. Can you check this in your setup, for both network interfaces (matching the beacon content and not) and using the Java and C++ implementations?
> 
> Cheers,
> ~Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System