Re: Capture serial port output to a file
On Tuesday 28 October 2008, Marc Balmer wrote: * Bruce Bauer wrote: Problem: OpenBSD 4.2 on i386 Serial port /dev/cua00 connected to the console port on a firewall. I need to catch all text output from the serial port to a file. The process doing this must survive a loss of network. The box is running headless. I could suggest you run cu in a screen session. I have used cu ... | tee logfile in the past, but there are possibly more elegant solutions I've never tried using tee(1) but it is more elegant than using the default solution provided by tip/cu/remote. As is often the case, wanted the feature is in base, and has been there long enough for most people to both forget about it, and to some degree, most people no longer understand the language used to describe the features in the man page. The language used in man tip(1) and man remote(5) is accurate, but the problem is you'd need to be ancient to know what the language means. The problematic term in the man pages is script since it basically means log file In remote(5) you'll see an option for re which is a string to define to a path/filename, and an option for sc boolean which tells tip to turn on scripting The boolean options are turned on by just listing them (without the =1 =on =true nonsense). Here's the default entry for tty00 in /etc/remote tty00|For hp300,i386,mac68k,macppc,mvmeppc,vax:\ :dv=/dev/tty00:tc=direct:tc=unixhost: Here's the entry for my tty00 in /etc/remote tty00|For hp300,i386,mac68k,macppc,mvmeppc,vax:\ :dv=/dev/tty00:tc=direct:sc:re=/home/jcr/tip.txt:tc=unixhost: If I do a simple # tip tty00 And boot the serial connected host, everything shows up on screen just like always *BUT* all of the output is also written to the given file. You might might also want to look over the beautify (be), line ending and escape sequence stuff in man remote(5) to tweak the text file output to your liking. -- jcr
Re: Capture serial port output to a file -Solved
Combining suggestions from several people. I installed screen This gives me an interactive screen that doesn't die when I disconnect the session. Then in the screen session: cu -l /dev/cua00 -t | tee /var/log/log.console I can then kill my ssh connction, connect again and see that the screen and cu processes are still running. I can tail -f /var/log/log.console to see new output from the console Bonus: I can reconnect to the screen session to issue interactive commands to get more debugging info out of the device. Thanks all --- [EMAIL PROTECTED] wrote: From: Nick Holland [EMAIL PROTECTED] To: misc misc@openbsd.org Subject: Re: Capture serial port output to a file Date: Tue, 28 Oct 2008 22:03:58 -0400 Marc Balmer wrote: * Bruce Bauer wrote: Problem: OpenBSD 4.2 on i386 Serial port /dev/cua00 connected to the console port on a firewall. I need to catch all text output from the serial port to a file. The process doing this must survive a loss of network. The box is running headless. I could suggest you run cu in a screen session. I have used cu ... | tee logfile in the past, but there are possibly more elegant solutions Not sure it is more elegant, but I mention it just because I was happy to find out about it: script(1). It's in base. Nick.
Re: Capture serial port output to a file
On Oct 29, 2008, at 2:13 AM, J.C. Roberts wrote: On Tuesday 28 October 2008, Marc Balmer wrote: * Bruce Bauer wrote: Problem: OpenBSD 4.2 on i386 Serial port /dev/cua00 connected to the console port on a firewall. I need to catch all text output from the serial port to a file. The process doing this must survive a loss of network. The box is running headless. I could suggest you run cu in a screen session. I have used cu ... | tee logfile in the past, but there are possibly more elegant solutions I've never tried using tee(1) but it is more elegant than using the default solution provided by tip/cu/remote. I use 'script'. It gets EVERYTHING. You have to do a little post- processing, but it works very well. However, if you're saying that you want to capture all output on the firewall coming in to /dev/cua00, why not just open the device and read from it? 'tail -f /dev/cua00 logfile' would do this. Assuming that you have the line dedicated to this and don't need to provide any input. If you want to use 'cu', you could also investigate the 'record' variable. (~s record /path/to/logfile) Sean
Capture serial port output to a file
Problem: OpenBSD 4.2 on i386 Serial port /dev/cua00 connected to the console port on a firewall. I need to catch all text output from the serial port to a file. The process doing this must survive a loss of network. The box is running headless. I have tried simple things like cat and buffer, but these processes exit after one or two lines of output. I need a process that will run until interrupted, and that doesn't need a controlling session. Google searches on this yield a lot of noise about redirecting console output to a serial port. _ OpenBSD is the _only_ operating system that takes security as seriously as it should be taken. Consider the why of OpenBSD's accomplishments. Remove the why and you remove what they accomplished. Use OpenBSD and think like Windows and get Windows security.
Re: Capture serial port output to a file
echo '@reboot screen -d -m -L /dev/cua00 9600' | crontab - but mind your existing crontab.
Re: Capture serial port output to a file
On Tue, Oct 28, 2008 at 02:45:07PM +0100, Marc Balmer wrote: I could suggest you run cu in a screen session. I have used cu ... | tee logfile in the past, but there are possibly more elegant solutions Screen can do logging and open windows to serial ports directly by itself (as I mentioned in my other mail). It's been working very reliably for me; some my servers are daisy chained together, and whenever I've had one fail, the one before it has had a log of its output, even after unattended reboots. screen is a gem. A soekris and a serial card and openbsd is an incredible console server for server administration, especially compared to the dedicated hardware ones.
Re: Capture serial port output to a file
On 2008-10-28, Bruce Bauer [EMAIL PROTECTED] wrote: Problem: OpenBSD 4.2 on i386 Serial port /dev/cua00 connected to the console port on a firewall. I need to catch all text output from the serial port to a file. The process doing this must survive a loss of network. The box is running headless. I have tried simple things like cat and buffer, but these processes exit after one or two lines of output. I need a process that will run until interrupted, and that doesn't need a controlling session. try conserver, it's ideal for this. in ports/packages.
Re: Capture serial port output to a file
screen looks like it will work. I must have missed the other mail. I'm building the port now and will report later. Thanks --- [EMAIL PROTECTED] wrote: From: Jussi Peltola [EMAIL PROTECTED] To: misc@openbsd.org Subject: Re: Capture serial port output to a file Date: Tue, 28 Oct 2008 17:22:54 +0200 On Tue, Oct 28, 2008 at 02:45:07PM +0100, Marc Balmer wrote: I could suggest you run cu in a screen session. I have used cu ... | tee logfile in the past, but there are possibly more elegant solutions Screen can do logging and open windows to serial ports directly by itself (as I mentioned in my other mail). It's been working very reliably for me; some my servers are daisy chained together, and whenever I've had one fail, the one before it has had a log of its output, even after unattended reboots. screen is a gem. A soekris and a serial card and openbsd is an incredible console server for server administration, especially compared to the dedicated hardware ones.
Re: Capture serial port output to a file
Marc Balmer wrote: * Bruce Bauer wrote: Problem: OpenBSD 4.2 on i386 Serial port /dev/cua00 connected to the console port on a firewall. I need to catch all text output from the serial port to a file. The process doing this must survive a loss of network. The box is running headless. I could suggest you run cu in a screen session. I have used cu ... | tee logfile in the past, but there are possibly more elegant solutions Not sure it is more elegant, but I mention it just because I was happy to find out about it: script(1). It's in base. Nick.
