test programs do not work well when the only capture devices are non-network

[infrastation]

These results are from the 20230608 snapshot of Debian 12 GNU/Hurd. The original problem manifested in libpcap build matrix, which runs testprogs/findalldevstest. Upon a closer look it became clear that other test programs also do not work as expected:

• capturetest and nonblocktest default to a non-network device and fail:

  capturetest: WARNING: SIOCGIFADDR: dbus-system: No such device
  capturetest: pcap_setnonblock failed: Non-blocking mode isn't supported for capturing on D-Bus
  

• findalldevstest fails with

  dbus-system
          Description: D-Bus system bus
          Flags: 
  
  dbus-session
          Description: D-Bus session bus
          Flags: 
  
  Error in pcap_lookupnet: SIOCGIFADDR: dbus-system: No such device
  

• selpolltest and threadsignaltest generate a warning:

  selpolltest: WARNING: SIOCGIFADDR: dbus-system: No such device
  Listening on dbus-system, using pcap_dispatch()
  1 packets seen, 1 packets counted after pcap_dispatch returns
  ^C
  

All of the above was attempted as a non-root user. The network interfaces are as follows:

$ ifconfig
/dev/eth0 (2):
  inet address  192.168.0.24
  netmask       255.255.255.0
  broadcast     192.168.0.255
  flags         UP BROADCAST RUNNING ALLMULTI MULTICAST
  mtu           1500
  link encap    Ethernet
  hardware addr 08:00:27:72:46:74

lo (1):
  inet address  127.0.0.1
  netmask       255.0.0.0
  flags         UP LOOPBACK RUNNING
  mtu           3924
  link encap    Local Loopback

However, tcpdump does not see any network interfaces (whether run as root or not):

$ ./tcpdump -D
1.dbus-system (D-Bus system bus) [none]
2.dbus-session (D-Bus session bus) [none]

To reproduce these results, libdbus-1-dev must be installed before compiling libpcap. If it is not installed, the list of capture devices is empty.

[infrastation]

Although this behaviour is consistent with the no-op pcapint_platform_finddevs() in pcap-hurd.c, arguably this is not the expected behaviour from a user's point of view.

[sthibaul]

FI to anybody wanting to contribute support, getifaddrs is working fine, so the code from fad-getad.c should be working fine.

[infrastation]

Thank you for the hint, I have tried that and managed to get my working copy to capture Ethernet packets almost normally. It is not perfect, but is better than nothing, so I hope to commit this soon.

[infrastation]

Besides that, to resolve this issue well, it would be necessary to define the expected behaviour for the test programs when the host genuinely lacks any network interfaces: should they fail with a more useful error message, or should they just skip the network-specific code paths?

[guyharris]

FI to anybody wanting to contribute support, getifaddrs is working fine, so the code from fad-getad.c should be working fine.

Do the configure script and CMakeList.txt not find getifaddrs() on GNU/Hurd and thus not configure fad-getad.c in?

[guyharris]

Besides that, to resolve this issue well, it would be necessary to define the expected behaviour for the test programs when the host genuinely lacks any network interfaces

The problem is that libpcap doesn't distinguish between network and non-network interfaces, so the test programs don't have an easy way to avoid trying to get the address and net mask for non-network interfaces.

[infrastation]

fad-getad.c is correctly selected and would work if pcap-hurd.c used it. After addressing that problem I was able to see a few other bugs and fixed them. Let me clean my working copy up for a pull request.