#731 Timeout problem while accessing attributes on a server running on Window7

[IMS ERAS]

Hi,
Whithin one of the ERAS projects we have a python server running on a Window7 machine.

While running this server we can monitor/test the corresponding device from jive on a Linux/Ubuntu machine (either the one corresponding to the TANGO_HOST or another one) and everything look fine including the plotting of some attributes.

Buth then, as soon as we try to access the attributes from another piece of python code via DeviceProxy we get the error:

File "/usr/local/lib/python2.7/dist-packages/PyTango/device_proxy.py", line 250, in DeviceProxyread_attribute
return __check_read_attribute(self._read_attribute(value, extract_as))
PyTango.CommunicationFailed: DevFailed
DevError[
desc = TRANSIENT CORBA system exception: TRANSIENT_CallTimedout
origin = DeviceProxy:read_attribute
reason = API_CorbaException
severity = ERR

DevError
desc = Timeout (3000 mS) exceeded on device c3/mac/eras-1
origin = DeviceProxy:read_attribute
reason = API_DeviceTimedOut
severity = ERR

We have repeated the test many times in different configurations and the result is always this timeout error.

The same kind of problem is there if we try to use the events and we get this time:

File "/usr/lib/python2.7/dist-packages/PyTango/device_proxy.py", line 836, in DeviceProxysubscribe_event
event_id = self.__subscribe_event(attr_name, event_type, cb, filters, stateless, extract_as)
PyTango.DevFailed: DevFailed
DevError[
desc = Can't subscribe to event for device tango://192.168.1.100:10000/c3/mac/eras-1
Check that device server is running...
origin = EventConsumer::connect_event()
reason = API_BadConfigurationProperty
severity = ERR

What we know, is that we have been able to cure the problem at its first occurrence, some months ago, by playing with the networking setup of the Window7 machine (the setting of the IPv6) but now, on our current setup, this workaround is not working anymore and we have not been able fix the problem in any other way.

Thanks a lot for your help

Regards

Franco

[Andy Gotz]

Really strange. I don't think I have ever seen this kind of behaviour. Does the monitoring in jive still work? Do you have a debug trace from the device server? Does the device server access some special hardware? Do you have the same behaviour with the TestDevice?

Andy

[IMS ERAS]

Hi Andy,
Thanks for getting back on this. Here my replies:

Does the monitoring in jive still work?
Sure, the jive monitoring is completely uneffected by this behavious and everything keep running fine

Do you have a debug trace from the device server?
No, I have the Log Viewer open, the device added and set in debug mode, but no trace is popping up when the timeout error is triggered

Does the device server access some special hardware?
I would say yes, the device access a Microsoft Kinect 360 device. But, as I said, the server is remaining always very much responsive in providing the attribute values from standard Tango GUIs.

Do you have the same behaviour with the TestDevice?
No, when using TestDevice I can run the server commands and look at the attributes values without problem.

The additional piece of information is the fact that the same python client, when running on the Window7 machine were the server is running, is working perfectly fine. The problem only occur when the client in running on a remote Ubuntu machine (I did not try yet to run on a remote Window machine). So the problem we see seems not related to the server itself, but to some network problem when we use the ProxyDevice mechanism.

Thanks again for any help you can provide

Franco

[IMS ERAS]

The other, may be relevant, piece of information, is that, on the terminal were I lauch jive, as soon as I start the "monitor device" I can see this tracing:
tcp://192.168.29.1:55555 ---> tcp://192.168.1.104:55555
tcp://192.168.29.1:55555 ---> tcp://192.168.1.104:55555
tcp://192.168.29.1:55555 ---> tcp://192.168.1.104:55555
...............
were 192.168.1.104 is the IP address of the remote Window7 machine and instead 192.168.29.1 is an IP address that I do not know to what correspond to.

[IMS ERAS]

NOW IS WORKING......
I think I solved the problem by applying the combination:
IPv6 protocol disabled on the Window7 machine ethernet connection setup
IPv6 enabled at the level of the router

With this setup, the tracing from Jive:
tcp://192.168.29.1:55555 ---> tcp://192.168.1.104:55555
disappear and also the timeout problem from a remote Ubuntu machine disappear.

Is like the Window machine was seen with an alternate address that was converted in the jive case to the correct one and this was not happening instead on the DeviceProxy case.

Some food for further investigation......., but this need to be well noted down since the non working combination (IPv6 enabled on Window) is the default on those machines.

[Tiago Coutinho]

There is a howto on the TANGO website on how to run device servers on WIndows XP/7 with IPv6

I will close the item and mark it as invalid since it is not a bug.