tcpdump mailing list archives

Re: libpcap: patches required for OpenSolaris/SXCE


From: Sebastien Roy <Sebastien.Roy () Sun COM>
Date: Tue, 01 Dec 2009 09:37:12 -0500

On Tue, 2009-12-01 at 00:47 -0800, Guy Harris wrote:
On Nov 30, 2009, at 5:30 AM, Darren Reed wrote:
# 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.

Yes, it is different.  On Solaris, ifconfig reports IP interface status
(where down and up are administrative settings of the IP interface), and
dladm reports the running state of the datalink, which is a dynamic
state that depends on external factors (akin to the RUNNING flag at the
IP layer).

I would argue that it's a bug on Solaris that libpcap depends on
IP-layer information to choose a capture interface (if that is in fact
what it does), as capturing at the link-layer is orthogonal to whether
IP is used at all over the datalink.  On Solaris, datalinks can exist
without IP interfaces at all, so the interface selection logic should
not use IP-layer APIs, but link-layer APIs.

E.g.: I can have a physical link dedicated for observability without IP
plumbed on it (tcpdump appears to be surprised by this, but this is
without Darren's modifications to tcpdump and libpcap...):

bash-3.2# dladm show-link
LINK        CLASS     MTU    STATE    BRIDGE     OVER
bge0        phys      1500   up       --         --
bge1        phys      1500   unknown  --         --
bash-3.2# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
        inet6 ::1/128 
bash-3.2# tcpdump -i bge0
tcpdump: WARNING: SIOCGIFADDR: bge0: No such device or address
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bge0, link-type EN10MB (Ethernet), capture size 68 bytes
14:21:38.213682 STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.00:03:ba:69:69:12.8002, length 
36
14:21:40.213726 STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.00:03:ba:69:69:12.8002, length 
36
14:21:42.213808 STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.00:03:ba:69:69:12.8002, length 
36
14:21:42.865283 00:03:ba:94:2f:56 (oui Unknown) > 33:33:00:00:00:01 (oui Unknown), ethertype IPv6 (0x86dd), length 86: 
        0x0000:  6000 0000 0020 3aff fe80 0000 0000 0000  `.....:.........
        0x0010:  0203 baff fe94 2f56 ff02 0000 0000 0000  ....../V........
        0x0020:  0000 0000 0000 0001 8800 99d4 2000 0000  ................
        0x0030:  fe80 0000 0000                           ......
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

The WARNING there seems spurious, and the use of SIOCGIFADDR
questionable.  Why should tcpdump care about the IP addresses assigned
to bge0 when observing at the link-layer?  FWIW, it appears to select a
default interface just fine, so it would appear to not use the SIOCG*
socket ioctls for interface selection:

bash-3.2# ./tcpdump
tcpdump: WARNING: SIOCGIFADDR: bge0: No such device or address
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bge0, link-type EN10MB (Ethernet), capture size 68 bytes
14:25:56.224284 STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.00:03:ba:69:69:12.8002, length 
36
14:25:57.348423 00:03:ba:44:41:b4 (oui Unknown) > 33:33:00:00:00:01 (oui Unknown), ethertype IPv6 (0x86dd), length 86: 
        0x0000:  6000 0000 0020 3aff 2002 0a08 39f0 0003  `.....:.....9...
        0x0010:  0203 baff fe44 41b4 ff02 0000 0000 0000  .....DA.........
        0x0020:  0000 0000 0000 0001 8800 98b1 2000 0000  ................
        0x0030:  2002 0a08 39f0                           ....9.
14:25:57.482308 arp who-has 10.8.48.221 (Broadcast) tell 10.8.48.221
14:25:58.224391 STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.00:03:ba:69:69:12.8002, length 
36
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

Maybe Darren has fixed these uses of SIOCGIFADDR and fixed the WARNING,
but if not, I'd argue that it's a bug.

What does "ifconfig tun0" report when "dladm show-link" reports tun0  
as down?  What does "tcpdump -D" report?

-Seb


-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.


Current thread: