User manual

90
Most network interfaces can also be put in "promiscuous" mode, in which they supply to the host all network
packets they see. Ethereal will try to put the interface on which it's capturing into promiscuous mode unless the
"Capture packets in promiscuous mode" option is turned off in the "Capture Options" dialog box, and Tethereal
will try to put the interface on which it's capturing into promiscuous mode unless the -p option was specified.
However, some network interfaces don't support promiscuous mode, and some OSes might not allow interfaces
to be put into promiscuous mode.
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. See
the Ethereal Wiki item on Token Ring
capturing for details.
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.
Q 7.2: When I capture with Ethereal, why can't I see any TCP packets other than packets to and from my
machine, even though another analyzer on the network sees those packets?
A: 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.
Q 7.3: Why am I only seeing ARP packets when I try to capture traffic?
A: You're probably on a switched network, and running Ethereal 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.
Q 7.4: Individual tickets are printed in one to two seconds, but I occasionally have delays of up to ten
seconds between tickets. What’s happening?
A: You're probably sending flash commands on every ticket. Try eliminating all flash commands from the ticket
data.
Q 7.5: When sending many LPR print jobs the printer seems to hang after the 11th job.
According to RFC 1179 the LPR spooling service may use only source ports of 721 to 731. This normally is no
problem, but when a computer tries to send many print jobs after each other – which is often the case on a
printer server – there is a certain time out after the 11 th job. This limits the performance because per RFC 1122,
each port must not be re-used for four minutes (2 * “Maximum Segment Lifetime” as defined in RFC 1122).
Windows NT up to Windows NT 3.51 with Service Pack 4 implemented this strict behavior. Starting with
Windows NT 3.51 Service Pack 5 and up to Windows NT 4 Service Pack 2 this limitation was raised because
the LPR-port was able to use the ports 512 to 1023.
Please refer to http://www.cyrtech.de/articles/Windows%20LPR.pdf
for additional information on this topic.