logging input from com/serial port in OpenBSD 2.9
Danathar
that outputs call data. I need to be able to log the data comming from
com port 1 on my OpenBSD 2.9 system. Can somebody tell me how I can
set up my system to do this. How do you configure the serial port to
redirect incomming data to a file?
thanks!
Frank da Cruz
Danathar <do...@attglobal.net> wrote:
: I have a telephone PBX box that has a 9 pin RS232C connector on it
Use C-Kermit:
http://www.columbia.edu/kermit/ckermit.html
Give it the following commands:
set carrier-watch off ; (only if the cable doesn't carry carrier)
set port /dev/tty00 ; or whatever
set speed 9600 ; whatever speed the PBX port uses
set parity none ; or even (etc), whatever the PBX uses
set flow rts/cts ; or Xon/Xoff, or None, whatever the PBX uses
Now you're ready to start logging. Next question: How long do you want
the logging to proceed? Let's say you want to log for one hour:
cd /some/path ; Place where logs are to be kept
log session blah ; Name for log file
input 3600 NEVER_SEEN ; Wait 3600 seconds for text that will never come
close session ; Close the session log
Of course there are lots of variations. Suppose you want to give the
log file a unique name based on the date and time:
log session pbx_\v(ndate)_\v(time).log
Suppose you want to log stuff not for a certain amount of time, but from
now until a certain time of day:
input 23:59:59 NEVER_SEEN ; Log until just before midnight.
Suppose you want timestamps to be added to each line:
set session-log timestamped-text ; do this prior to "log session"
Suppose you want to automatically cycle your logs each hour:
cd /some/path ; Place where logs are to be kept
while true { ; Loop forever
log session pbx_\v(ndate)_\v(time).log
input 3600 NEVER_SEEN ; Wait 3600 seconds for text that will never come
close session ; Close the session log
}
Lots of possibilities.
- Frank
Danathar
10 years since I messed around with that. It must of not crossed my
mind due to the extreme age of the neurons holding that info :)
Thanks much for the suggestion. That should do the trick!
f...@columbia.edu (Frank da Cruz) wrote in message news:<ahpmvm$svl$1...@watsol.cc.columbia.edu>...
Frank da Cruz
: 10 years since I messed around with that. It must of not crossed my
: mind due to the extreme age of the neurons holding that info :)
Yes, time marches on, but we've been busy all those years. Take a look
at the website to see what I mean:
http://www.columbia.edu/kermit/
- Frank
p...@icke-reklam.ipsec.nu
install kermit , it's in the ports ( or get it from Columbia University)
then create a "rc" script with the commands you need
when kermit is started , a sample that selects comport speed
and suitable "escapecharacter" comes here :
sweet% cat .kermrc
set line /dev/tty02
set speed 9600
set escape 01
sweet%
> thanks!
--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
mkhomo
Out of curiosity, are they still using kermit for space communications,
and if so how wide were the sliding windows for say the voyager/rover
transmissions to Mars, back in '98?
Frank da Cruz
: Frank da Cruz wrote:
: > In article <2f177cd8.02072...@posting.google.com>,
: > Danathar <do...@attglobal.net> wrote:
: > : Ahh Kermit, there's something I have'nt heard in a while. Must of been
: > : 10 years since I messed around with that. It must of not crossed my
: > : mind due to the extreme age of the neurons holding that info :)
: > :
: > Yes, time marches on, but we've been busy all those years. Take a look
: > at the website to see what I mean:
: >
: > http://www.columbia.edu/kermit/
: Out of curiosity, are they still using kermit for space communications,
: transmissions to Mars, back in '98?
Kermit, TCP, X.25, or any other protocol that requires signaling in both
directions is not suitable for space communications. The medium is noisy
and the penalty for retransmissions is prohibitive.
When data is sent from deep space back to earth, the transmission is one-way
and it embodies serious redundancy and error correction codes, which expand
the size of the transmission far beyond what we would tolerate for realtime
terrestrial protocols. Large volumes of data arrive from the spacecraft
mangled almost beyond recognition, and then are reconstructed after the fact
not only from the built-in redundancy of the data (which is not perfect) but
also image-processing or similar techniques.
Kermit sliding windows are fine for satellite communication, out to and
including the moon, and for this it's better than protocols like TCP that
don't support selective retransmission of damaged packets. The greater the
distance, the greater the advantage of selective retransmission.
- Frank