Q: A tcpdump command that's been running for a long time seems to be leaking memory; its address space size seems to be increasing steadily over time. Why is this happening, and how can I keep it from leaking memory?
A: Run it with -S. Otherwise, tcpdump keeps track of all the connections it has seen so it can generate relative sequence numbers rather than absolute sequence numbers. This looks like a leak, but is in fact just state accumulation.
Q: When I use tcpdump to capture packets, why do I see only packets to or from my machine, or why do I not see all the traffic I'm expecting to see from or to the machine I'm trying to monitor?
This might be because the interface on which you're capturing is plugged into a switch; on a switched network, unicast traffic between two ports will not necessarily appear on other ports - only broadcast and multicast traffic will be sent to all ports.
Note that even if your machine is plugged into a hub, the "hub" may be a switched hub, in which case you're still on a switched network.
Note also that on the Linksys Web site, they say that their auto-sensing hubs "broadcast the 10Mb packets to the port that operate at 10Mb only and broadcast the 100Mb packets to the ports that operate at 100Mb only", which would indicate that if you sniff on a 10Mb port, you will not see traffic coming sent to a 100Mb port, and vice versa. This problem has also been reported for Netgear dual-speed hubs, and may exist for other "auto-sensing" or "dual-speed" hubs.
Some switches have the ability to replicate all traffic on all ports to a single port so that you can plug your analyzer into that single port to sniff all traffic. You would have to check the documentation for the switch to see if this is possible and, if so, to see how to do this. See the switch reference page on the Ethereal Wiki for information on some switches. (Note that it's a Wiki, so you can update or fix that information, or add additional information on those switches or information on new switches, yourself.)
Note also that many firewall/NAT boxes have a switch built into them; this includes many of the "cable/DSL router" boxes. If you have a box of that sort, that has a switch with some number of Ethernet ports into which you plug machines on your network, and another Ethernet port used to connect to a cable or DSL modem, you can, at least, sniff traffic between the machines on your network and the Internet by plugging the Ethernet port on the router going to the modem, the Ethernet port on the modem, and the machine on which you're running tcpdump into a hub (make sure it's not a switching hub, and that, if it's a dual-speed hub, all three of those ports are running at the same speed.
If your machine is not plugged into a switched network or a dual-speed hub, or it is plugged into a switched network but the port is set up to have all traffic replicated to it, the problem might be that the network interface on which you're capturing doesn't support "promiscuous" mode, or because your OS can't put the interface into promiscuous mode. Normally, network interfaces supply to the host only:
If the interface is not running in promiscuous mode, it won't see any traffic that isn't intended to be seen by your machine. It will see broadcast packets, and multicast packets sent to a multicast MAC address the interface is set up to receive.
You should ask the vendor of your network interface whether it supports promiscuous mode. If it does, you should ask whoever supplied the driver for the interface (the vendor, or the supplier of the OS you're running on your machine) whether it supports promiscuous mode with that network interface.
In the case of token ring interfaces, the drivers for some of them, on Windows, may require you to enable promiscuous mode in order to capture in promiscuous mode. Ask the vendor of the card how to do this, or see, for example, this information on promiscuous mode on some Madge token ring adapters (note that those cards can have promiscuous mode disabled permanently, in which case you can't enable it).
In the case of wireless LAN interfaces, it appears that, when those
interfaces are promiscuously sniffing, they're running in a
significantly different mode from the mode that they run in when they're
just acting as network interfaces (to the extent that it would be a
significant effor for those drivers to support for promiscuously
sniffing and acting as regular network interfaces at the same
time), so it may be that Windows drivers for those interfaces don't
support promiscuous mode.
Why don't I see TCP traffic other than traffic to and
from my machine?
Q: Why can't I see any TCP packets other than packets to or from my machine, even though another sniffer on the network sees those packets?
You're probably not seeing any packets other than unicast packets to or from your machine, and broadcast and multicast packets; a switch will normally send to a port only unicast traffic sent to the MAC address for the interface on that port, and broadcast and multicast traffic - it won't send to that port unicast traffic sent to a MAC address for some other interface - and a network interface not in promiscuous mode will receive only unicast traffic sent to the MAC address for that interface, broadcast traffic, and multicast traffic sent to a multicast MAC address the interface is set up to receive.
TCP doesn't use broadcast or multicast, so you will only see your own TCP traffic, but UDP services may use broadcast or multicast so you'll see some UDP traffic - however, this is not a problem with TCP traffic, it's a problem with unicast traffic, as you also won't see all UDP traffic between other machines.
I.e., this is probably the same question
as this earlier one; see the response to that question.
Why do I only see ARP packets when I try to capture
traffic?
Q: I'm trying to capture traffic on my network; why am I only seeing ARP packets?
You're probably on a switched network, and running tcpdump on a machine that's not sending traffic to the switch and not being sent any traffic from other machines on the switch. ARP packets are often broadcast packets, which are sent to all switch ports.
I.e., this is probably the same question
as this earlier one; see the response to that question.
How do I put an interface into promiscuous mode?
Q: I'm trying to capture all the traffic on my network; how do I put my interface into promiscuous mode?
By not disabling promiscuous mode when running tcpdump.
Note, however, that:
I.e., this is probably the same question
as this earlier one; see the response to that question.
When is a packet time-stamped? How accurate are the
time stamps?
,
Q: When is a packet time-stamped? How accurate are the time stamps?
Tcpdump gets time stamps from libpcap, and libpcap gets them from the OS kernel, so tcpdump - and any other program using libpcap, such as Ethereal or snoop - is at the mercy of the time stamping code in the OS for time stamps.
In most OSes on which tcpdump and libpcap run, the packet is time stamped as part of the process of the network interface's device driver, or the networking stack, handling it. This means that the packet is not time stamped at the instant that it arrives at the network interface; after the packet arrives at the network interface, there will be a delay until an interrupt is delivered or the network interface is polled (i.e., the network interface might not interrupt the host immediately - the driver may be set up to poll the interface if network traffic is heavy, to reduce the number of interrupts and process more packets per interrupt), and there will be a further delay between the point at which the interrupt starts being processed and the time stamp is generated.
On some OSes, such as HP-UX, the OS kernel does not time stamp the packet at all; instead, it's time stamped by libpcap at the time it reads the packet from the OS kernel, which means that there will be an even greater delay between the time the packet arrives and the time that it's time-stamped.
Thus, the packet time stamp is not necessarily a very accurate
indication of the time it arrived at the machine that captured the
packet.
Why do my time stamps on Linux have only 100ms
resolution?
Q: I'm running tcpdump on Linux; why do my time stamps have only 100ms resolution, rather than 1us resolution?
At least on x86-based machines, Linux can get high-resolution time stamps on newer processors with the Time Stamp Counter (TSC) register; for example, Intel x86 processors, starting with the Pentium Pro, and including all x86 processors since then, have had a TSC, and other vendors probably added the TSC at some point to their families of x86 processors.
The Linux kernel must be configured with the CONFIG_X86_TSC option enabled in order to use the TSC. Make sure this option is enabled in your kernel.
In addition, some Linux distributions may have bugs in their versions of
the kernel that cause packets not to be given high-resolution time
stamps even if the TSC is enabled. See, for example, bug 61111 for Red
Hat Linux 7.2. If your distribution has a bug such as this, you may
have to run a standard kernel from kernel.org in order to get
high-resolution time stamps.
Why are my time stamps on Windows 95/98/Me wrong?
Q: I'm capturing packets on {Windows 95, Windows 98, Windows Me}; why are the time stamps on packets wrong?
This is due to a bug in WinPcap. The bug should be fixed in the WinPcap 3.0 beta release - note that it's an beta release, so it may be buggier than the current production release of WinPcap; please report those bugs to the WinPcap developers, and help them try to track down the problem, so that they can fix it for the final release.