Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Tue, 30 Jan 2018 10:10:24 -0800

Andrew,

As this wiki page was mentioned again today on tech-talk it occurs to me to ask.
Should the outcome of your issue be noted in the wiki?

https://wiki-ext.aps.anl.gov/epics/index.php/How_to_Make_Channel_Access_Reach_Multiple_Soft_IOCs_on_a_Linux_Host

On 05/08/2017 04:15 PM, Andrew Johnson wrote:
> On 05/05/2017 06:41 PM, Michael Davidsaver wrote:
>> My first reaction is that you have a good situation in which to test the
>> as yet untested multicast name lookup feature added to CA.
> 
> Unfortunately I don't have much control over the Base version the CA
> clients are running (and when I did experiment with using multicast
> addresses some time back they didn't work for me; our network guy
> doesn't have a particularly deep knowledge in this area, so I didn't
> push it).
> 
>> I'm not surprised that the source port is being changed as I know in
>> other situations (full NAT) that this is done, I believe, to make a
>> unique entry in a mapping lookup table.
>>
>> You might get some additional information from:
>>
>> http://conntrack-tools.netfilter.org/conntrack.html
> 
> Useful tool, thanks — RHEL provides an RPM so I installed it, although
> the documentation is somewhat lacking.
> 
>> See the '--dst-nat' filter.
> 
> Actually the --any-nat filter is more revealing:
> 
>> [root@tux sudo]# conntrack -E -p udp --any-nat
>>     [NEW] udp      17 30 src=164.54.8.164 dst=164.54.9.24 sport=58193 dport=5064 [UNREPLIED] src=164.54.11.255 dst=164.54.8.164 sport=5064 dport=58193
>>     [NEW] udp      17 30 src=164.54.9.24 dst=164.54.8.164 sport=5064 dport=58193 [UNREPLIED] src=164.54.8.164 dst=164.54.9.24 sport=58193 dport=1025
>> [DESTROY] udp      17 src=164.54.8.164 dst=164.54.9.24 sport=58193 dport=5064 [UNREPLIED] src=164.54.11.255 dst=164.54.8.164 sport=5064 dport=58193
>> [DESTROY] udp      17 src=164.54.9.24 dst=164.54.8.164 sport=5064 dport=58193 [UNREPLIED] src=164.54.8.164 dst=164.54.9.24 sport=58193 dport=1025
>> ^Cconntrack v1.4.3 (conntrack-tools): 4 flow events have been shown.
> 
> The second line there is it setting up the translation of the reply
> source port number, which I want it to *not* do. Unfortunately after
> lots of reading I get the impression that this isn't going to be
> possible using the NAT mechanism; the kernel's Connection Tracking code
> seems to have some mirroring functionality which requires some kind of
> backwards translation to occur.
> 
> 
>> You might get some mileage by modifying the rule to match when the
>> source IP is on the local subnet by adding something like
>>
>>> ! -s 192.168.1.0/24
> 
> Not sure how that might help, I still need the iptables rule to work for
> clients from both local and remote subnets (local clients might be
> configured with an explicit IP address in their ADDR_LIST instead of
> using the broadcast address).
> 
> 
> Looking at the netfilter.org documentation for NAT at
> http://netfilter.org/documentation/HOWTO//NAT-HOWTO-6.html#ss6.3
> I see this text, which I think explains what's going on:
> 
>> Implicit Source Port Mapping
>>
>> Even when no NAT is requested for a connection, source port translation
>> may occur implicitly, if another connection has been mapped over the
>> new one. Consider the case of masquerading, which is rather common:
>>
>> 1. A web connection is established by a box 192.1.1.1 from port 1024
>>    to www.netscape.com port 80.
>> 2. This is masqueraded by the masquerading box to use its source IP
>>    address (1.2.3.4).
>> 3. The masquerading box tries to make a web connection to
>>    www.netscape.com port 80 from 1.2.3.4 (its external interface address)
>>    port 1024.
>> 4. The NAT code will alter the source port of the second connection to
>>    1025, so that the two don't clash.
> 
> It's that last point which seems to be unalterable.
> 
> We developed a workaround, which was to run a PV Name Server on another
> workstation in the same subnet as the IOC, configured for learning and
> only searching for PVs from the IOC's IP address. We point our
> firewalled clients to that nameserver, which points them to the IOC and
> everything seems to work. Not ideal, but it's sufficient for now.
> 
> - Andrew
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System