We have three computers connecting to a digi portserver TS4.
Two computers are Windows boxes (Server2003, WinXPsp3) and the other computer is a linux Red Hat Enterprise Server.
They are connecting to the remote digi through TCP/IP drivers and simply listening for serial data on that port and dumping it to a file.
Sometimes, it may take 2 hours or 20 minutes, but something comes across the feed and the windows machines will stop receiving any information, but the Linux box still continues processing the data just fine. No problems.
You can reboot the Windows machines and they will not reconnect. (Note the Linux machine is still processing data during all this.) You can restart the services on the Windows machine without re-establishing the signal.
The only thing that works is restarting the digi server. As soon as the digi server is rebooted all the connections on the windows machine automatically fire up again. You don’t even have to disconnect and reconnect them, they just start up again by themselves.
Has anyone experienced or heard of this happening? Is there a solution? I called Digi and the person on the phone … well… they were confused and perplexed and suggested I run wireshark or portmon on it looking for ???
Did run wireshark/portmon nothing weird jumps out. Besides the linux machine doesn’t have a problem so it has to be something with the digi driver itself? But if that were the case wouldn’t rebooting the windows machines reset the driver and re-establish the connection.
We’re stuck. Any insights or suggestions are most appreciated.
Thank you.
Sterling
When you say “connecting to the remote digi through TCP/IP drivers”, are you referring to our Realport driver? If yes, what is the version of Realport driver on Windows? On Linux? What port profiles are the TS4 serial ports configured as? What version of EOS firmware is running on the TS4?
Are the two Windows servers and lone Linux server trying to share the serial ports of your TS4, or do each of these servers have a serial port of the TS4 dedicated to them?
All the computers are sharing a single port. I have the port configured to “Allow multiple systesm to simultaneously connect” Connections 3, Control Exclusive (It use to be shared but that didn’t work either so I changed it to Exclusive, which also doesn’t seem to make a difference.)
Please let me know if there are any further details required.
Thank you again and I look forward to any insights or suggestions.
-Sterling
This may seem like an odd question but can you send commands to the digi box that would change its configuration by connecting to its serial ports?
I’m wondering if something (some data) is coming across that somehow may alter the digi device’s settings and this would close the connection for the windows realport drivers.
I say this because when it’s working IFC is grey in the monitor web browser. I just saw it a few minutes ago and the IFC is green.
I restarted the digi device and was able to connect. I’m now watching the port and when it goes down I’ll confirm whether IFC changes.
IFC stands for input flow control. If this psuedo-signal is coming on, it means your port is in a flow-controlled state. If the device connected to it has no way to signal that it can accept more data (i.e. it uses no flow control or a type not configured for), your port will appear to be locked-up.
Flow control is a very intentional thing which is used to prevent data loss. In order to get this working, ensure the flow control set on the serial device connected to your Portserver matches how you have that Portserver’s serial port configured.
If all the ports recieving data are set to this and the digi device is set to this is there something else that could be setting this IFC flag?
Is there a way to force the digi device to ignore this option?
I’m not a serial person so apologies if these questions are unintelligable or make little sense for what’s happening.
I’m just looking to resolve this very bizzare behavior.
Are there any settings on the realport drivers I could set?