Is there a way to automate serial port connection and collect output to a file from some commands?

[Ryan1]

Using a Linux bash script, is there a way to log into an Extreme switch through the com port, run a command and collect the output to a file where the bash script was executed from? I need to automate collecting some data from around 100 switches that are not connected to a network where I can use ssh. I need to access them physically using the serial console only.



Manually it would be something like:
screen /dev/ttyUSB0 9600
admin

show version
exit

where I would then dump the version information to a file.

[Ryan1]

You were both right; I had better luck with cu. It’s not perfect, but it will work. In order to parse the redirected file, I had to:

1. Use sed to remove a line that that always contained a non-ascii string
2. Use sed to do some find and replaces to clean up a couple lines that I need to parse and couldn't just delete.
3. I am also using dos2unix on the file before I parse it. This might not be needed now, but it was helping when I was using screen, so I left that in.

Sometimes accessing the switch fails, and looking at the dump file, it looks like the expect and send are out of sync with the switch, but I can add a retry to work with it. Anyways, its definitely a workable solution and super helpful! Thank you guys! One more question, when I access the switch manually using cu or screen, after I am done, I type “exit”, but you are not fully out of the terminal session. It’s more like I just logged out. I am sitting at a “login” prompt. In a situation where my Linux OS has Xwindows, I can just close the terminal, but in an OS where there is no Xwindows, I have to switch to another terminal, and kill the PID to end the session. What’s the right way to fully exit from a cu terminal session under CLI?

[James_A]

The correct way is to send "\r~." to cu. cu will terminate when, at the start of a new line (which \r sends), it see ~. (tilde followed by period).

[Erik_Auerswald]

Hi Ryan,

That could be a result of screen trying to control the terminal. Screen is terminal oriented and controls the output visible on the terminal, including scrolling the currently displayed up one line to display the next line. That does not work well together with expect.

A line oriented program like cu (Debian/Ubuntu package cu) might work better with expect, but I haven't used it for many years.

I am using expect together with SSH or telnet (in a lab) to a console server connecting the switch consoles and cannot test with a direct serial connection at this time.

Hope to help,
Erik

[James_A]

I was going to suggest using cu too. The [8C could be an ANSI code for cursor control, so it might be generated by the switch and show up regardless.