[nSLUG] Re: April Tech Talk
mspencer at tallships.ca
Wed Apr 22 15:41:09 ADT 2015
> Tee is a lot of fun. I've often used it while running tcpdump, to
> keep an eye on it, while it goes to a file.
Well! Isn't that nice?
See, years ago when I first knew about tcpdump, I tried that. And it
didn't work somehow -- no recollection of how or why. Meant to look
into it some day, figure out what might have been different from what
I expected. Never got a round tuit.
And now you say that I *should* be as I expected. So let's see
Doesn't work as expected.
If I run tcpdump with stdout to a shell buffer in Emacs, I get
realtime display of all packets not excluded by the "expressions" in
the tcpdump invocation. (Realtime == correlated with modem
If I pipe tcpdump through " | tee logfile", output from tcpdump gets
buffered up somewhere. Both the stdout and the logfile get updated in
spurts that may break the tcpdump output in the middle of a line.
E.g. I'm looking at this in the stdout:
15:15:02.327926 IP 220.127.116.11.119 > 18.104.22.168.32770:. 4679:5203(524
and the same thing is the last line in the logfile.
After a couple of hits on the news server (port 119, above, right?)
with no output in either logfile or stdout, suddenly 103 lines get
dumped to stdout at once, again stopping in the middle of a line of
This must have something to do with kernel scheduling of the tcpdump
and tee processes as well as of the parent shell and possibly other
processes. But it's not "as expected". And for this particular
application (tcpdump running as I work) it's a fail because the point
is to see intrusion or other anomalous packets when they happen.
MS-DOS had pipes (or at least the Norton shell that I used did) but
they were fake: output was written to a HD file, then fed into proc-2
after proc-1 had completed. That's not happening here but the
buffering and scheduling means you can't do what you might *think* you
Michael Spencer Nova Scotia, Canada .~.
mspencer at tallships.ca /( )\
More information about the nSLUG