open a non-existent interface should always return 'no such interface'

[afshin-deriv]

• Attempts to open a non-existent interface should always return "no such interface" even if you don't have capture permissions #1538
• Different behavior with zero-padded interface numbers tcpdump#1334

Fix interface existence check on Linux before privileged operations

When attempting to open a non-existent network interface on Linux,
libpcap would return PCAP_ERROR_PERM_DENIED instead of the correct
PCAP_ERROR_NO_SUCH_DEVICE. This occurred because the privileged
socket(PF_PACKET, SOCK_RAW, 0) call in setup_socket() would fail
with permission errors before interface validation could occur.

This fix adds an interface existence check using an unprivileged
AF_INET socket and SIOCGIFINDEX ioctl before attempting to create
the privileged packet socket. Non-existent interfaces now correctly
return PCAP_ERROR_NO_SUCH_DEVICE.

This resolves the issue where applications like tcpdump would report
"Permission denied" instead of "No such device exists" for non-existent
interfaces, breaking their fallback logic from interface names to indices.

Note: BSD/macOS platforms have the same underlying issue where BPF device
access fails with permission errors before interface validation. This
should be addressed in a separate commit.

Fixes: libpcap issue #1538
Related: tcpdump issue #1334

./tcpdump -i nonexistent
tcpdump: nonexistent: No such device exists
(No such device exists)

./tcpdump -i eth999
tcpdump: eth999: No such device exists
(No such device exists)

// The zero-padded interface numbers like 000000000000008 are being interpreted as interface index 8, which actually exists, so the permission error is correct behavior

./tcpdump -i 000000000000008
tcpdump: vethad16f6a: You don't have permission to perform this capture on that device
(Attempt to create packet socket failed - CAP_NET_RAW may be required)

./tcpdump -i 00000000000000073
tcpdump: Invalid adapter index 73: only 72 interfaces found

[infrastation]

Thank you for preparing this change. The comments that clarify the problem and the solution should be in the commit message.

[infrastation]

Why tstamp_type_list no longer needs to be set here?

[afshin-deriv]

Thank you for reviewing these changes
because current code ignoring the ENODEV error and treating it as a success case, assumes the user will discover the real problem later during activation

  case ENODEV:
      ..
      handle->tstamp_type_list = NULL;
      return 0;  // SUCCESS, continue execution

This is problematic because it allows execution to continue with a non existent interface, leading to confusing error messages later

The new code immediately fails when it detects ENODEV:

  case ENODEV:
      ...
      ebuf[0] = '\0';
      return PCAP_ERROR_NO_SUCH_DEVICE;  // MMEDIATE FAILURE

after returning PCAP_ERROR_NO_SUCH_DEVICE, the calling function (pcapint_create_interface) do:

  if (iface_get_ts_types(device, handle, ebuf) == -1) {
      pcap_close(handle);  // Cleans up the handle
      return NULL;         // Function exits immediately
  }

Since the function exits immediately and calls pcap_close(handle), there's no point in setting tstamp_type_list

[infrastation]

On Linux the only proposed change is to iface_get_ts_types(), thus the "check for existence before trying a privileged operation" logic does not apply to Linux:

$ ./testprogs/activatetest 
Trying to use capture device "nosuchdevice"...
FAIL: Permission denied from pcap_activate(), retry with higher privileges.

It looks like the two proposed changes are not related and should be two different commits, each stating and solving a separate problem. Also, since pcap-linux.c already implements helper functions such as iface_get_id(), it would be easy to implement the same logic for Linux. That said, the logic increases the race condition window, which would require some attention.

This requires a bit more work before it is ready.