Header Only - DO NOT REMOVE - Extreme Networks

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


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
[b]
show version
exit

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

8 replies

Userlevel 6
Ryan

I think in screen you can use -L as a CLI switch, this outputs to screenlog.x which you could then grep for version.

Inside screen you can also do CTRL a + H (without the +) to toggle output on/off

I don't know if you can specifically capture only the version output in screen.

HTH

-Gareth
Userlevel 3
Hi Ryan.
One of the simplest ways would be to utilize Linux "expect" scripts. There is a lot of information about how to use them available in the Internet but here is a quick example on how you can use it in your case:

Create a text file named script.sh with following contents:
#!/usr/bin/expect -f
spawn screen /dev/ttyUSB0 9600
expect "login:"
send "admin\r"
expect "password:"
send "\r"
expect " # "
send "show version\r"
expect " # "
send "exit\r"[/code]Change access permissions of this file:
# chmod 755 script.sh
[/code]Run it and send output to some text file:
# ./script.sh > file.txt[/code]I hope it will help.

--
Konstantin
Konstantin,

Thanks for the detailed response! This works to create a file, but the file also including what non-ascii characters like: [!p [?3;4l [4l > [?1049

I also added the command: show port 1-48 information detail | include "Port:|Link State"

This stops outputting at around 32 ports.
Userlevel 7
Hi Ryan,

the non-ASCII characters are terminal control codes, used e.g. by the pager. If you are gathering output automatically, you should issue the command "disable clipaging" before your show commands.

Erik
Userlevel 7
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
Erik Auerswald wrote:

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

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.
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?
Ryan wrote:

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?

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).

Reply