Trenton D. Adams wrote:
> I have a very odd problem. I would appreciate it if someone was able to
> help me. If I do a tcpdump of packets on my local network here at home with
> my laptop, it works fine. But on the other hand, if I do a tcpdump of
> packets on the local network at school with my laptop, it doesn't always
> work. Sometimes it works if I wait awhile for the packets, but not always.
> For example. If I go "tcpdump -x -i eth0", it should do a dump of any
> packets on the network, right? If I do a ping to any machine at school it
> doesn't work all the time. It does work sometimes if I wait a really long
> time. What is going on, anyone have any clues?
There are two switches which can reduce the latency of tcpdump's
output:
-l make stdout line buffered instead of fully buffered
-n don't convert IP addresses to hostnames
Without -l, tcpdump's stdout will be fully buffered, so you will only
see output once there are BUFSIZ (8192 on Linux/glibc-2) bytes of
output.
Without -n, IP addresses are translated into hostnames, so the output
is delayed while the DNS lookup is performed. Given that reverse DNS
is frequently misconfigured, this may result in long delays (AFAICT,
the default timeout for a DNS query on Linux is 189 seconds).
> As far as I know, there is no way the IS guys can stop me from doing a dump
> of packets to and from my machine!!! Am I mistaken?
It depends upon whether your box is connected to a hub or a switch. If
it's a switch, your box should only see its own traffic, not that of
other boxes.
--
Glynn Clements <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
