2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Fwd: Wrong beacon source IP address |
From: | Ralph Lange <[email protected]> |
To: | EPICS Core-Talk <[email protected]> |
Date: | Fri, 18 Dec 2015 09:13:23 +0100 |
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? |
Attachment:
wireshark.png
Description: PNG image