Re: caget() from C++

[Mark Rivers <rivers@cars.uchicago.edu>]

You do need to set EPICS_CA_AUTO_ADDR_LIST=NO to disable the multiple PV location warnings. If you don’t then it still uses all the default broadcast addresses, in addition to anything you specify with EPIC_CA_ADDR_LIST.

I don’t recall how to configure iptables for CA but I think Google or tech-talk search should find it.

Mark





Sent from my iPhone

> On Dec 6, 2017, at 8:42 PM, Church, Eric D <eric.church@pnnl.gov> wrote:
> 
> Hi, Mark, et al:
> 
> Today, we discovered that our shutoff of the firewall via the GUI had not in fact had any effect, and “system iptables stop” does what we’d thought  we’d achieved all along.
> 
> With the firewall off I can state that we now can do cainfo and camonitor against PVs on both of our IOCs. So, we’re happy about this; the css and archive-engine clients continue to all consistently allow reporting and monitoring too. We suddenly see your warnings that you mention below. All EPICS environment variables are unset. I quickly tried to set EPICS_CA_ADDR_LIST to my 130.20.x.y broadcast address, per your comment below, but that did not make the cainfo’s warnings disappear. I’ll try the 192.168.x.y broadcast address later. Maybe I need to set EPICS_CA_AUTO_ADDR=NO again. This is relatively unimportant at this point.
> 
> Now, the question is can you tell us how to set the firewall rule to allow the EPICS traffic, so that we may re-enable the firewall and have functional EPIC monitoring and control?
> 
> Thanks for all the help -- Eric
> 
> On 12/5/17, 8:29 PM, "Mark Rivers" <rivers@cars.uchicago.edu> wrote:
> 
>    Hi Eric,
> 
> 
>    I should mention one thing.
> 
> 
>    If you have the following configuration:
> 
> 
>    - More than 1 network interface
> 
>    - EPICS_CA_ADDR_LIST not set
> 
>    - IOC running on the machine
> 
>    - CA client (e.g. camonitor) on the same machine
> 
> 
>    then you should actually should receive warning messages each time your client connects to a PV.  The warning will be that there are duplicates of that PV because each PV appears to be located on each of the network interfaces.  The above configuration is actually what you have tried, but you were not seeing these warnings.
> 
> 
>    In order to avoid these warnings (once your current problem is solved) you need to tell the client to only search on one network interface by setting EPICS_CA_ADDR_LIST to the broadcast address of 1 (and only 1) network interface.
> 
> 
>    There is another solution in 3.15.4 and higher which is to configure the IOC with EPICS_CAS_INTF_ADDR_LIST rather than configuring the clients as above.
> 
> 
>    I would suggest that you should try this:
> 
> 
>    - Unset EPICS_CA_ADDR_LIST and EPICS_CA_AUTO_ADDR_LIST
> 
>    - Make sure all firewalls are disabled.  I believe the firewall can block even local clients, though I am not sure about that.
> 
> 
>    I guess another obvious test under those conditions is to see if you can access the PVs from another machine.  You should be able to.  If you can, but still cannot access them from the local machine that will tell us something.
> 
> 
>    Mark
> 
> 
> 
> 
>    ________________________________
>    From: Church, Eric D <eric.church@pnnl.gov>
>    Sent: Tuesday, December 5, 2017 9:33 PM
>    To: Mark Rivers; 'Kasemir, Kay'; Ralph Lange; EPICS Tech Talk
>    Cc: Mendez, Jennifer M
>    Subject: Re: caget() from C++
> 
>    So, indeed, the warnings go away when I set EPICS_CA_AUTO_ADDR_LIST=NO. However, no matter if I use my eth0 or eth1 broadcast address, I can not use camonitor on either set of IOC’s PVs.
> 
>    Along these lines, I tried to read Kay’s 2012 post (http://www.aps.anl.gov/epics/tech-talk/2012/msg02356.php), that motivated the following effort:
>    I tried firing up IOC1 with EPICS_CA_ADDR_LIST=eth0bcast:5065, EPICS_CA_ PORT=5065 and IOC2 with EPICS_CA_ADDR_LIST=eth0bcast:5066, EPICS_CA_ PORT=5066, and in the session where I run camonitor I say EPICS_CA_ADDR_LIST=” eth0bcast:5066”. I also tried it with eth0->eth1.
> 
>    camonitor fails when I do this, and CSS and archive-engine do also. Only, it seems, if I set EPICS_CA_ADDR_LIST=localhost can I use camonitor, and only then on the PVs of the second IOC that I fire up.
> 
> 
>    What is so non-standard about my network on this everything-on-one-computer setup of mine? Does a firewall even matter in this case?
> 
>    - Eric
> 
> 
>    On 12/5/17, 2:45 PM, "Mark Rivers" <rivers@cars.uchicago.edu> wrote:
> 
>        If you set the EPICS_CA_ADDR_LIST to the broadcast address then you must also set EPICS_CA_AUTO_ADDR_LIST=NO.  That is why you are getting these warnings, because these broadcast addresses were already being used because EPICS_CA_AUTO_ADDR_LIST was defaulting to YES.
> 
>        Warning: Duplicate EPICS CA Address list entry "192.168.1.255:5064" discarded
>        Warning: Duplicate EPICS CA Address list entry "130.20.49.255:5064" discarded
> 
> 
>> -----Original Message-----
>> From: Church, Eric D [mailto:eric.church@pnnl.gov]
>> Sent: Tuesday, December 05, 2017 4:06 PM
>> To: Mark Rivers; 'Kasemir, Kay'; Ralph Lange; EPICS Tech Talk
>> Cc: Mendez, Jennifer M
>> Subject: Re: caget() from C++
>> 
>> 
>> I attach a file showing my efforts at setting this variable in the xterm session in which I run
>> my caxyz commands and the record of my puzzling problems. Before trying to export these
>> values of EPICS_CA_ADDR_LIST, all was well. Whereas, after setting it, failingx2, if I
>> unset it I can not connect: I am not returning to successful camonitoring of just even one
>> IOC.
>> 
>> Note: all the relevant-looking complaints from my 2nd IOC terminal in the attached file ….
>> 
>> - Eric
>> 
>> 
>> 
>>> On 12/5/17, 1:43 PM, "Mark Rivers" <rivers@cars.uchicago.edu> wrote:
>>> 
>>> Looks like the EPICS_CA_ADDR_LIST used by camonitor is not using the broadcast
>> address of your host.
>> 
>>    It should be doing that automatically without you needing to set
>> EPICS_CA_ADDR_LIST.  Can you send the output of the following commands Linux
>> command in the shell where you are running camonitor.
>> 
>>    ifconfig
>>    printenv | grep EPICS
>> 
>>    At the IOC shell prompt on both the first and second IOCs send the output of
>> 
>>    epicsPrtEnvParams
>> 
>> 
>>    What happens if you set EPICS_CA_ADDR_LIST manually to the broadcast address of
>> your system?  For example on my system ifconfig shows:
>> 
>>    p5p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>>            inet 164.54.160.82  netmask 255.255.255.0  broadcast 164.54.160.255
>>            inet6 fe80::3efd:feff:fea3:f258  prefixlen 64  scopeid 0x20<link>
>>            ether 3c:fd:fe:a3:f2:58  txqueuelen 1000  (Ethernet)
>>            RX packets 80276465019  bytes 92598173910474 (84.2 TiB)
>>            RX errors 0  dropped 114  overruns 0  frame 0
>>            TX packets 32261858165  bytes 16671972218313 (15.1 TiB)
>>            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>> 
>>    So I would set EPICS_CA_ADDR_LIST=164.54.160.255
>> 
>>    Mark
>> 
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Kasemir, Kay [mailto:kasemirk@ornl.gov]
>>> Sent: Tuesday, December 05, 2017 3:37 PM
>>> To: Church, Eric D; Mark Rivers; Ralph Lange; EPICS Tech Talk
>>> Cc: Mendez, Jennifer M
>>> Subject: Re: caget() from C++
>>> 
>>>> Indeed camonitor can properly watch a channel on the first IOC when only it is
>> running. I
>>> can dial up and down the voltage from CSS on a particular PV on this first IOC and
>> watch
>>> it move on camonitor. >When I start the second IOC I can continue this exercise on
>> POVs
>>> on the first IOC. If I kill camonitor, per your suggestion, I can not start it again on a PV
>> on
>>> the first IOC. And if I kill the second IOC I can >once again start camonitor
>> successfully on
>>> a PV on the first IOC.
>>> 
>>>> What does it mean, do ya think?
>>> 
>>> Looks like the EPICS_CA_ADDR_LIST used by camonitor is not using the broadcast
>>> address of your host.
>> 
>> 
>> 
> 
> 
> 
> 
>