Re: Fwd: Wrong beacon source IP address

[Ralph Lange <ralph.lange@gmx.de>]

Update:
Here's what I think describes the situation.

-----snip-----
While this indeed looks strange, I do not think it is relevant.

Looking at the code in udpiiu.cpp, in the function udpiiu::beaconAction() that is called for an incoming beacon message
    ina.sin_addr.s_addr = htonl ( msg.m_available );
    if ( msg.m_count != 0 ) {
        ina.sin_port = htons ( msg.m_count );
    }
the sender address of the UDP package is being overwritten with the address and the port number that is in the content of the beacon message.

Background:
CA has to make sure that beacons are counted properly. As any detected irregularity of beacons would cause the unresolved names to be broadcast again, measures have to be taken to avoid false positives.
If a client is connected to a server via multiple networks, the "same" beacon ping will be received multiple times. The client has to make sure that these beacons are recognized as originating from the same IOC, and that they are in fact only one beacon ping, not multiple pings in a short time.
Both are achieved by putting the complete CA address (IP address and CA data port number) as well as a beacon counter into the contents of the beacon message. The complete address is used to correctly identify the IOC, and the counter is used to suppress "echos" of the same beacon ping.
-----snip-----

On 18/12/2015 09:13, Ralph Lange wrote:

Dear colleagues,

I think Anze's got a point here.
What are the consequences? Are there any?

Cheers,
~Ralph


-------- Forwarded Message --------

Subject:	Wrong beacon source IP address
From:	Anze Zagar <anze.zagar@cosylab.com>

I was playing around with CA beacons a little bit, and observed some
surprising behaviour.

On my system I have three network interfaces:

eth0
  inet addr:10.5.4.190  Bcast:10.5.7.255  Mask:255.255.248.0

vmnet1
  inet addr:192.168.103.1  Bcast:192.168.103.255  Mask:255.255.255.0

vmnet8
  inet addr:172.16.209.1  Bcast:172.16.209.255  Mask:255.255.255.0


Now if I run EPICS IOC, it will send beacons to all three broadcast
addresses, however the source address (in the IP frame of the beacon UDP
packet) will in all three cases correspond to the IP address of the
first interface. Thus with EPICS_CA_AUTO_ADDR_LIST=yes, source IP is
always 10.5.4.190.

And if I configure, e.g.:

export EPICS_CA_AUTO_ADDR_LIST=no
export EPICS_CA_ADDR_LIST="192.168.103.255 172.16.209.255 10.5.7.255"

source IP is 192.168.103.1 for all three subnets (see also the attached
wireshark screenshot).

I noticed that this may impact some CA client implementations, because
they expect beacon to have the source address corresponding to existing
CA connections (which will obviously not be the case for second and
third subnet). Effectively, it will ignore all beacons and check for the
IOC availability by pinging them instead. Additionally, it will also not
reuse CA connections for multiple PVs hosted on the same server.

I observed this on EPICS 3.14.12.5. Do you know, if this is something
known or expected?