Freeze on terminal in TS port

Realport
1

Hi.

I have been using PortServer TS 16 Rack for quite some time for automation purposes.

In one of the automation tests I ran, I noticed that the Digi stop showing the output on the terminal & nothing can be sent as well (sort of a freeze).

The device I try to configure through the Digi port is still reachable via network cable connected to it, but there is a timeframe (a couple of minutes) in which I have no response from it & looks dead.

I tried another product named Cyclades & had no issues there.

I have to say that it happened in a very long test where the device is rebooted quite frequently & the boot process is shown in the terminal.

Does the Digi become choked ?
Is it a known issue ?

I already tried to connect the device to another port - same issue.

I hope u can give me some info, since I really have nothing to do.

TIA,
Issac.

2

What is being rebooted the Portserver or attached serial device?

Is this something that had been working and recently started locking up?

How are you connecting to the serial ports (TCP socket, RealPort, connect, etc…)?

What type of device is attached to the serial port?

Are you able to communicate with the PortServer over the network when it is in this state? If so, telnet or ssh to the unit, login as root and post the results from the following commands:

who
display port ra=*
set ports ra=*
set flow ra=*

3

10x a lot for the prompt response.

This has been recently discovered since I got to handle some more comprehensive automation tests.

What I meant in reboot is that during these comprehensive tests, there are multiple reboots of the device attached to the TS & the output is all the boot sequence till the software loads.

I’m using a straight RJ45 cable from the Digi & a connector that converts from RJ45 to RS232 on the device.

The device is a L4/L7 load-balancer.

Other ports are not affected & the Digi’s management console is reachable (via network - telnet).

I once monitored the CPU utilization & saw it was not high (almost 0%).

BTW, I’m using the shared port option, i.e. I can view the console from multiple stations (all can see the commands entered & can actively enter commands to the device).

I will try the commands u gave me next week.

I hope that the information I provided will give u some insight.
Do u have any idea ?

4

Port sharing can lead to this behavior, what settings are applied?

set sharing

Additionally, the following knowledge base article should be reviewed in regards to port sharing behavior:

http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=962

5

First, please note that all ports are configured to shared (max - 10) & we did not encounter any issue when using the Digi on a regular basis.

I will read the article & get back to u with more information.

I will try to run the test without Sharing the port.

Also, the Cyclades is also configured to “Shared”.

6

I tried 2 methods:

  • untick the “Allow Multiple Connections” checkbox & run the test.
  • select “Exclusive” in the Control drop-down list & re-ran the test.

I noticed that when I change the Control, the Digi itself loses connection (management).

The test passed in both modes, but I think it is not the real case I had, since the Digi was not overloaded & did not have many connections to its ports.

The article u sent me refers to sharing the port (i.e. either Control option) or only to “Shared” ?

The options of disabling port sharing might be risky to me, since I don’t want a test to fail due to a connection that is open in one of our many stations.

7

At this point, you may want to consider opening a case with Tech. Support as more details will need to be gathered, such as a network trace, application and device details.