Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Mon, 8 Aug 2016 13:44:27 +0200

On 05.08.2016 19:38, Michael Davidsaver wrote:
> On 08/05/2016 11:23 AM, Benjamin Franksen wrote:
>> Now, if we change the IP address on the windows PC to another free
>> address in the network, channel access first works. Everything is fine
>> but only for 3 to 5 minutes. Then connections to the vxWorks IOC fail
>> again. Setting the IP address to a third variant has the same effect.
>> Everything works but only for a few minutes. Setting the IP address back
>> to the original one still doesn't work. Deactivating and  re-activating
>> the network interface doesn't help. After a while, maybe  15 to 30
>> minutes, an IP address that didn't work and wasn't used for that time,
>> can be used again, but still, only for 2 to 3 minutes.
> 
> What is the network topology like?  This behavior sounds like some
> security system is blocking IPs based on "suspicious" traffic.

The strange thing is that it works if we use EPICS_CA_ADDR_LIST to ask a
CA gateway in /another/ network, but not if we connect to the VxWorks
IOC (in the same network) directly. We can also conect to channels from
soft IOCs runing on a linux host in the same network. Finally, replacing
the Windows machine with a linux host with the same IP and connected to
the same port of the same switch works flawless. I may be wrong but I
think this rules out interference from any of the network components.

The VxWorks version on the IOC is ancient (5.4.2) but we have used it
for 20 years and never seen it behave like that before.

Which leaves the Windows OS and the slightly outdated EPICS base
(installed with CALab). We will try with another Windows machine, a
newer CALab version, and also try RTEMS for the IOC.

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." ― Scott Adams

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System