Experimental Physics and
Industrial Control System

Jörn Dreyer via Tech-talk <tech-talk at aps.anl.gov> · Wed, 18 Oct 2023 09:02:25 +0200

Hi Kay,

thanks for the explanation. My problem comes from the local firewall that most Linux distros install and that helps to keep load from the system as it blocks most of the broadcast traffic. One does not want to switch it off, especially on laptops.
To get the UDP connection from the IOC to my host working, I had to add a complex rule to my firewall configuration:

rich rules: 
        rule family="ipv4" source address="A.B.C.D/X" destination address="A.B.C.E/X" protocol value="udp" accept

Unfortunately you have to do this for each machine that runs an IOC with PVA protocol. Depending on X one could probably set C,D and E to 0 to access a whole set of a subnet. I tested that with D and E set to 0.

Hope this helps others.

Regards

Jörn

Am Dienstag, 17. Oktober 2023, 16:37:36 CEST schrieb Kasemir, Kay:
> > course port XXX is not covered by the firewall rules and is random
> 
> Yes, that’s a known issue with the original PVA server implementation, https://github.com/epics-base/pvAccessCPP/issues/159 .
> You simply can’t use the original PVA server via firewalls unless you allow all UDP traffic, which isn’t practical.
> 
> With the newer PVXS implementation of the PVA server, that’s been fixed.
> A firewall usually involves a gateway, and when you use the PVXS-based PVA gateway, https://mdavidsaver.github.io/p4p/gw.html, you can place that behind a firewall just fine. The IOCs handled by that PVA gateway may still use the original PVA server with random UDP ports, but that’s not a problem inside your controls network. The gateway that you reach via the firewall will stick to the known UDP port for searches and replies. Or you might actually use TCP-only name lookup and avoid UDP altogether for the gateway & firewall.
> 
> 
> 
> From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Jörn Dreyer via Tech-talk <tech-talk at aps.anl.gov>
> Date: Tuesday, October 17, 2023 at 10:30 AM
> To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
> Subject: [EXTERNAL] Re: PVA connection problem
> Hello
> 
> Sorry for not citing the old messages. I just found the topic on tech-talk as I was looking for a strange behavior I observed when playing around with NDPluginPVA.
> I was able to do a "pvget some_pv" on the machine where the IOC is running, but not on another machine. I had exactly the same ideas as commented here (adding ports 5075/5076 to the firewall) but without luck.
> Then I started up wireshark and tested with and without firewall and figured out whats going on.
> 
> Without firewall:
> 
> Clients sends from port XXX to 5076
> Server replies from port YYY to XXX
> Client can read data!
> 
> With firewall:
> 
> Clients sends from port XXX to 5076
> Server replies from port YYY to XXX
> Client replies with ICMP message
> Server gives up, no data transfered!
> 
> Of course port XXX is not covered by the firewall rules and is random (> 50000 in my case). One can get around this if you open your firewall for all UDP traffic.
> But that is not what you really want to do in a bigger network with lots of broadcast traffic. So opening ports 5075/5076 is not necessary.
> 
> So my hope is that one can force pvget/pvput to use a dedicated port that can be added to the firewall rules.
> 
> Regards,
> 
> Jörn
> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System