EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Fwd: Re: Wrong beacon source IP address
From: Ralph Lange <[email protected]>
To: EPICS Core Talk <[email protected]>
Date: Fri, 18 Dec 2015 20:38:09 +0100
Here's more from Anze...


-------- Original Message --------
From: Anze Zagar <[email protected]>
Sent: December 18, 2015 5:38:46 PM GMT+01:00
Subject: Re: Wrong beacon source IP address

Hi Ralph,

I still think it's a bug. If not in CAS, then in CAJ implementation (and
probably also the C++ CA).


Here's what's happening:

IOC host has two interfaces with IPs of 192.168.4.4 and 172.16.209.1.
The CAJ client is running on a vmware machine with IP 172.16.209.130.
Now let's assume that 172.16.209.* is configured as the "second"
interface. All beacons sent from the IOC to either of the networks will
(as explained in my observations) claim they originate from 192.168.4.4.


CAJ client then sends the CA_PROTO_SEARCH request to find the IOC
hosting a given PV. Receives CA_PROTO_SEARCH response from 172.16.209.1,
establishes TCP connection [1] to it and stores the so called
CATransport object into the TransportRegistry dictionary/hashmap [2],
using the server IP as the key (i.e. "172.16.209.1").

Then it's expecting beacons to arrive (at least) every 15 seconds.
However, the only beacons arriving claim they are from "192.168.4.4" and
CAJ cannot link them to the existing connection
(context.getTransportRegistry().get() in beaconArrivalNotify of [3]
returns null). So CATransport.beaconArrivalNotify() [4] is never invoked
and the timer [5] always triggers to send the CA_PROTO_ECHO request in
order to check what's going on with the IOC server.

In other words, beacons are being completely ignored when client is
connected to IOC over "not-the-first" IOC host's network interface.


[1]
http://sourceforge.net/p/epics-jca/caj/ci/default/tree/src/com/cosylab/epics/caj/impl/CAConnector.java#l94

[2]
http://sourceforge.net/p/epics-jca/caj/ci/default/tree/src/com/cosylab/epics/caj/impl/CATransport.java#l194

[3]
http://sourceforge.net/p/epics-jca/caj/ci/default/tree/src/com/cosylab/epics/caj/impl/CABeaconHandler.java#l208

[4]
http://sourceforge.net/p/epics-jca/caj/ci/default/tree/src/com/cosylab/epics/caj/impl/CATransport.java#l970

[5]
http://sourceforge.net/p/epics-jca/caj/ci/default/tree/src/com/cosylab/epics/caj/impl/CATransport.java#l1014


Cheers,
Anze.



On Fri, 2015-12-18 at 15:11 +0000, Lange Ralph wrote:
> > -----Original Message-----
> > From: Anze Zagar [mailto:[email protected]]
> > Sent: 18 December 2015 16:03
> > To: Lange Ralph
> > Subject: Re: Wrong beacon source IP address
> > 
> > Hi Ralph,
> > 
> > I checked now also with the CA dissector and it turned out that even inside
> > the beacon message (the last 4 bytes of the payload - see the attached
> > wireshark screenshot) the primary/"first" IP address is always written
> > regardless of the interface on which it is sent.
> 
> Yes, this is intentional, so that the clients that receive beacons over multiple networks can see these beacons coming from the same IOC.
> You can see it this way: The unique tag for an IOC is the combination of its first IP address and data port number.
> 
> Name resolution is always done as broadcast and/or on the complete EPICS_CA_ADDR_LIST, so it is not relevant which IP a new IOC comes up as. The fact that it is a new IOC (and not the same IOC on a different address) is what triggers the re-broadcast of unresolved names.
> 
> Cheers,
> ~Ralph
> 




Navigate by Date:
Prev: Re: Fwd: Wrong beacon source IP address Andrew Johnson
Next: Re: Fwd: Wrong beacon source IP address Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Fwd: Wrong beacon source IP address Michael Davidsaver
Next: caget delays Benjamin Franksen
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 19 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·