comment #2:

> This is standard IP stack behaviour. Keep in mind the same happens for all outgoing packets.

I realize now I should have read RFC 1122 before stating that this was a "faulty behaviour" - it is as you say standard for "weak host model" stacks. It was me that expected the "strong host model", and it is rather a feature request to support this model.

Perhaps the best way forward here is to add a setting LWIP_STRONG_HOST_MODEL (defaulting to 0) and put that around parts of the code netif search code in ip4_input as well as for the routing (which would now be src aware routing if I understand correctly).

If your patchset would be available, that would obviously help - otherwise I can volunteer creating a patch for review.

This is standard IP stack behaviour. Keep in mind the same happens for all outgoing packets.

The below code is "fixed" by adding an #if or #ifdef just after netif = NULL;.

At my work we use multiple interfaces for (physical) network redundancy and we need hard separation between networks, both for incoming as well as outgoing packets (in case peers are behind routers in different subnets and standard routing may choose the wrong interface). We changed both incoming as outgoing code paths to guarantee strict network separation.

If there is enough interest I can ask permission to release the full patchset for merging with upstream lwIP.

When multiple netifs are used, IP traffic that is passed (via tcpip_input) to lwIP on one netif can be received on a different netif.

The "problematic" part of the code is in ip4_input where ip4_input_accept is called for the netif on which the ethernet frame was received. If that is not accepting the input, e.g. due to not having received an IP address from DHCP yet, all other netifs are searched to see if any of those netifs would accept the input. E.g. a broadcast packet received on one physical netif could be perceived as received on a completely different netif which could obviously lead to very strange issues (corresponding code also exists in ip6_input):


    /* start trying with inp. if that's not acceptable, start walking the
       list of configured netifs. */
    if (ip4_input_accept(inp)) {
      netif = inp;
    } else {
      netif = NULL;
#if !LWIP_NETIF_LOOPBACK || LWIP_HAVE_LOOPIF
      /* Packets sent to the loopback address must not be accepted on an
       * interface that does not have the loopback address assigned to it,
       unless a non-loopback interface is used for loopback traffic. /
      if (!ip4_addr_isloopback(ip4_current_dest_addr()))
#endif /* !LWIP_NETIF_LOOPBACK || LWIP_HAVE_LOOPIF */
      {
#if !LWIP_SINGLE_NETIF
        NETIF_FOREACH(netif) {
          if (netif == inp) {
            /* we checked that before already */
            continue;
          }
          if (ip4_input_accept(netif)) {
            break;
          }
        }
#endif /* !LWIP_SINGLE_NETIF */
      }
    }


On a system using ethernet_input, I cannot really see any reason whatsoever why the complete list of netifs should be searched to find an interface that would accept the packet if the input netif does not. But I assume (hope!?) there is some reason for that code to exist?