net: Replace ifname check with IFF_LOOPBACK in Discover #29984

1. 
   laanwj commented at 9:39 am on April 28, 2024: member

   Checking the interface name is kind of brittle. In the age of network namespaces and containers, there is no reason a loopback interface can’t be called differently.

   Check for the IFF_LOOPBACK flag to detect loopback interface instead.

   Also remove a misleading comment in Discover’s doc comment.

2. net: Replace ifname check with IFF_LOOPBACK in Discover

   Checking the interface name is kind of brittle. In the age of network
   namespaces and containers, there is no reason a loopback interface can't
   be called differently.
   
   Check for the `IFF_LOOPBACK` flag to detect loopback interface instead.

   7766dd280d
3. laanwj added the label P2P on Apr 28, 2024
4. 
   DrahtBot commented at 9:39 am on April 28, 2024: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage

   For detailed information about the code coverage, see the test coverage report.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   ACK	sipa, willcl-ark, theuni

   If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

   Conflicts

   Reviewers, this pull request conflicts with the following ones:

   • #30043 (net: Replace libnatpmp with built-in PCP implementation by laanwj)

   If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

5. net: Fix misleading comment for Discover

   All network addresses are being iterated over and added, not just the first one per interface.

   a68fed111b
6. 
   sipa commented at 12:39 pm on April 28, 2024: member

   utACK a68fed111be393ddbbcd7451f78bc63601253ee0
7. willcl-ark approved
8. 
   willcl-ark commented at 8:31 am on April 30, 2024: member

   utACK a68fed111be393ddbbcd7451f78bc63601253ee0

   Agree this will be less brittle than name-checking. I don’t think it’s possible that IFF_LOOPBACK would ever be unset for a loopback device unless someone had modified their kernel.

9. theuni approved
10. 
    theuni commented at 5:24 pm on May 6, 2024: member

    utACK a68fed111be393ddbbcd7451f78bc63601253ee0. Satoshi-era brittleness :)
11. fanquake merged this on May 7, 2024
12. fanquake closed this on May 7, 2024

    ---

13. 
    theStack commented at 6:26 pm on May 7, 2024: contributor

    post-merge ACK a68fed111be393ddbbcd7451f78bc63601253ee0

    Interestingly, libpcap still implements both the “brittle” and the IFF_LOOPBACK flag way to detect loopback devices (https://github.com/the-tcpdump-group/libpcap/blob/0797ed7340f93618fd097ad870dfc1dde7cecc4f/pcap.c#L1042-L1053), but the code was seemingly introduced in 1998 (https://github.com/the-tcpdump-group/libpcap/blob/0797ed7340f93618fd097ad870dfc1dde7cecc4f/CHANGES#L1443-L1445) and I suspect that these days you won’t find any Unix-like OS anymore that does not provide IFF_LOOPBACK.

14. 
    laanwj commented at 8:14 am on May 8, 2024: member

    Thanks for checking! it’s kind of a belt-and-suspenders check: we only look for routable addresses in Discover, so unless someone assigned a routable address to the loopback interface-which would be really strange-it doesn’t actually influence the result.

Contributors
laanwj DrahtBot sipa willcl-ark theuni theStack

Labels
P2P