For the open_interface function of pcapd.c, should pcap_close be executed after falling back to cooked socket?

[pic4xiu]

Hello, in the open_interface function of papd.c, if a specific arptype is encountered, it will fall back to cooked socket. However, at this time, the program will close pd and then try to open it as a file. If pd is not closed in this case, but the cooked socket is kept, what impact will it have on the program? Please advise😄

    if((pcap_set_timeout(pd, 1) != 0) ||
       (pcap_set_snaplen(pd, PCAPD_SNAPLEN) != 0) ||
       (pcap_set_immediate_mode(pd, 0) != 0) ||
       (pcap_activate(pd) != 0)) {
//      fprintf(stderr, "Error activating pcap: %s\n", pcap_geterr(pd));
      pcap_close(pd);
      pd = NULL;
    }

output:

[I] 14/Feb/2025 10:35:01 - Internet interface changed [-1 -> 21], (re)starting capture
Error activating pcap: arptype 519 not supported by libpcap - falling back to cooked socket
[E] 14/Feb/2025 10:35:01 - pcap_open(rmnet_data4) failed: rmnet_data4: No such file or directory

Is this rewrite logically correct?

  if (pd) {
    // NOTE: setting immediate mode greatly increases the chance to resolve UIDs of short-lived
    // connections. But it has a big performance impact due to the increased context switches.
    // The performance cost is not acceptable.
    if ((pcap_set_timeout(pd, 1) != 0) ||
        (pcap_set_snaplen(pd, PCAPD_SNAPLEN) != 0) ||
        (pcap_set_immediate_mode(pd, 0) != 0)) {
      pcap_close(pd);
      pd = NULL;
    } else {
      int activate_status = pcap_activate(pd);
      if (activate_status < 0) {
        pcap_close(pd);
        pd = NULL;
      } else if (activate_status > 0) {
        fprintf(stderr, "Warning: %s\n", pcap_statustostr(activate_status));
      }
    }
  }

[emanuele-f]

Hello, libpcap is reporting that the network interface you are trying to capture from has an unknown "arptype" 519. Arptype 519 is not declared in https://dox.ipxe.org/if__arp_8h_source.html so probably this is an invalid arptype that somehow your Android OS is reporting.

Anyway, the log message shows that libpcap can probably still work by falling back to the cooked capture. Looking at the libpcap source, you can see that a PCAP_WARNING is being returned. So it's better to just ignore the PCAP_WARNING return code of pcap_activate, the other codes (e.g. PCAP_WARNING_TSTAMP_TYPE_NOTSUP) should still be considered as errors for now (unless we have a reason to assume otherwise).

If pd is not closed in this case, but the cooked socket is kept, what impact will it have on the program

It's unclear if libpcap will be able to actually capture in cooked mode, please try and see if it works on your device

So in your snippet:

• change the logic to only consider PCAP_WARNING as a valid error code; in other cases still return error
• use log_w instead of fprintf to report the warning message