Different behavior with zero-padded interface numbers

[momo-trip]

Hi, is this tcpdump behavior a bug where interface index 9 fails with tcpdump -i 000000000000009 (14 zeros) but succeeds with tcpdump -i 0000000000000009 (15 zeros), despite both referring to the same interface?

Environment

• OS: Ubuntu 22.04 LTS
• Architecture: x86_64
• tcpdump version:

$ ./tcpdump --version
tcpdump version 5.0.0-PRE-GIT
libpcap version 1.10.1 (with TPACKET_V3)
OpenSSL 3.0.2 15 Mar 2022
SMI-library: 0.4.8
64-bit build, 64-bit time_t

Issue

The same interface (index 9) produces different results based on zero-padding length. The threshold of 16 characters appears to be related to sizeof(ifr.ifr_name) (IFNAMSIZ).

Permission denied:

$ ./tcpdump -i 9                   # Permission denied
$ ./tcpdump -i 000000000000009     # Permission denied (15 characters total)

Works without sudo:

$ ./tcpdump -i 0000000000000009    # Works (16 characters total)
$ ./tcpdump -i dbus-session        # Works (interface name)

With sudo (different error):

$ sudo ./tcpdump -i 000000000000009
tcpdump: Failed to get session bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11

[guyharris]

The "first try it as an interface name and, if that fails because it's not a valid interface name, try it as an interface index" trick, to support both interfaces with a numerical name (yes, they exist, that's why the trick is done) and interface indices, depends on attempts to open an interface with a name that doesn't correspond to an interface always fails with "no such interface", even if you don't have permission to capture on any network interfaces.

That requires some way to determine whether a network interface exists by name even if you can't capture on it.

Ideally, that'd be done in libpcap, but we could have tcpdump, if it gets an error other than "no such interface", search the list of interfaces and, if it's not there, try treating it as an interface index.

[infrastation]

It would be helpful to see what tcpdump -D prints.

[fxlb]

On Debian bookworm:

+ ./tcpdump --version                  
tcpdump version 5.0.0-PRE-GIT
libpcap version 1.11.0-PRE-GIT (with TPACKET_V3)
OpenSSL 3.0.16 11 Feb 2025
64-bit build, 64-bit time_t

+ ./tcpdump -D
1.eth0 [Up, Running, Connected]
2.any (Pseudo-device that captures on all interfaces) [Up, Running]
3.lo [Up, Running, Loopback]
4.docker0 [Up, Disconnected]
5.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
6.nflog (Linux netfilter log (NFLOG) interface) [none]
7.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
8.dbus-system (D-Bus system bus) [none]
9.dbus-session (D-Bus session bus) [none]
10.eth1 [none, Disconnected]

+ ./tcpdump -i 8 -c1
tcpdump: 8: You don't have permission to perform this capture on that device
(socket: Operation not permitted)

+ ./tcpdump -i 000000000000008 -c1       # 15 chars
tcpdump: 000000000000008: You don't have permission to perform this capture on that device
(socket: Operation not permitted)

+ ./tcpdump -i 0000000000000008 -c1      # 16 chars
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on dbus-system, link-type DBUS (D-Bus), snapshot length 134217728 bytes
22:13:30.180046 UNSUPPORTED
        0x0000:  6c04 0101 0a00 0000 0200 0000 8d00 0000  l...............
        0x0010:  0101 6f00 1500 0000 2f6f 7267 2f66 7265  ..o...../org/fre
        0x0020:  6564 6573 6b74 6f70 2f44 4275 7300 0000  edesktop/DBus...
        0x0030:  0201 7300 1400 0000 6f72 672e 6672 6565  ..s.....org.free
        0x0040:  6465 736b 746f 702e 4442 7573 0000 0000  desktop.DBus....
        0x0050:  0301 7300 0c00 0000 4e61 6d65 4163 7175  ..s.....NameAcqu
        0x0060:  6972 6564 0000 0000 0601 7300 0500 0000  ired......s.....
        0x0070:  3a31 2e32 3000 0000 0801 6700 0173 0000  :1.20.....g..s..
        0x0080:  0701 7300 1400 0000 6f72 672e 6672 6565  ..s.....org.free
        0x0090:  6465 736b 746f 702e 4442 7573 0000 0000  desktop.DBus....
        0x00a0:  0500 0000 3a31 2e32 3000                 ....:1.20.
1 packet captured
1 packet received by filter
0 packets dropped by kernel

[guyharris]

On Debian bookworm:

The exact amount of zero-padding depends on the maximum length of an interface name, so it may differ between operating systems and versions of a particular operating system (in the case of Linux distributions, it's probably going to be a difference between Linux kernel versions).

This is primarily a libpcap issue; see the-tcpdump-group/libpcap#1538. However, we should try to have tcpdump work around that issue, so that if it's built with a libpcap that has that problem, it'll still do the right thing. I'll use this bug for that.