Experimental Physics and Industrial Control System
|
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 --------
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?
|
- References:
- Fwd: Wrong beacon source IP address Ralph Lange
- Navigate by Date:
- Prev:
Fwd: Wrong beacon source IP address Ralph Lange
- Next:
caget delays Benjamin Franksen
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Fwd: Wrong beacon source IP address Ralph Lange
- Next:
Re: Fwd: Wrong beacon source IP address Michael Davidsaver
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 18 Dec 2015 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|