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
<2015>
2016
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
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|