On Nov 30, 2009, at 5:30 AM, Darren Reed wrote:
... I think the output of "tcpdump -L" could do with mentioning the
link name.
OK, I've checked in a change to do that - and, when built with libpcap
1.0.0 or later, to, for devices that support monitor mode with the
libpcap APIs, report whether the list of link-layer header types is
the list available in monitor mode or the list available outside of
monitor mode, as the lists are different on some platforms:
$ tcpdump -L
Data link types for en0 (use option -y to set):
DOCSIS (DOCSIS) (printing not supported)
EN10MB (Ethernet)
$ tcpdump -L -i en1
Data link types for en1 when not in monitor mode (use option -y to
set):
EN10MB (Ethernet)
$ tcpdump -L -I -i en1
Data link types for en1 when in monitor mode (use option -y to set):
IEEE802_11_RADIO (802.11 plus radiotap header)
(as you might guess, this is on a Mac OS X machine, with en0 being the
Ethernet adapter and en1 being the AirPort adapter).
That *still* doesn't answer the question of why tcpdump defaulted to
tun0 on your machine when dladm claimed that device was "down":
# dladm show-link
LINK CLASS MTU STATE BRIDGE OVER
igb0 phys 1500 up -- --
e1000g0 phys 1500 up -- --
e1000g1 phys 1500 up -- --
igb1 phys 1500 up -- --
vnic0 vnic 1500 up -- e1000g0
tun0 iptun 65515 down -- --
unless dladm's notion of "down" is different from ifconfig's notion of
"down", the latter probably being what libpcap sees when it decides
whether to report devices as available or not.
What does "ifconfig tun0" report when "dladm show-link" reports tun0
as down? What does "tcpdump -D" report?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.