lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Sending to a non-local network without default netif se


From: Fabian Koch
Subject: Re: [lwip-users] Sending to a non-local network without default netif set
Date: Wed, 19 Nov 2014 09:04:40 +0000

Hey Joel,

 

well yes. I was talking about the scenario you describe in 1).

Although my experience with the windows stack in this world has always been: “the last connected interface wins and is used for default gateway” which always sucked when my 100Mbit cable was detected first and the wireless connection last (when transferring big files).

The solution was to unplug/replug the Ethernet cable.

 

But yeah. The other scenario in my opinion is simply a misconfiguration and can never work in real life so we shouldn’t strive to support that at all.

 

I don’t see LwIP in a routing/switching context, so VLAN is also a topic that I would not expect to be covered by us. Normal clients don’t need to be aware of VLAN tagging as this is usually done between switches.

 

IP forwarding and “real” routing is also out of scope for LwIP imho.

 

But still. We do support multiple netifs, so we should make an effort to support configurations that come to mind easily, like two or more netifs on the same subnet.

 

“Trunking” or “bonding” or “link bundling” (e.g. LACP) is also out of scope for LwIP imho.

 

Hope you guys agree.

 

Cheers,
Fabian

 

From: lwip-users-bounces+address@hidden [mailto:lwip-users-bounces+address@hidden On Behalf Of Joel Cunningham
Sent: Dienstag, 18. November 2014 15:51
To: Mailing list for lwIP users
Cc: Mailing list for lwIP users
Subject: Re: [lwip-users] Sending to a non-local network without default netif set

 

"we do have a setup with two netifs and we cannot determine what the customer will do with the device so we need to also check for „same subnet“ scenarios."

I would like to make a clear distinction between two possible "same subnet scenarios"

1) A multi-homed product is connected to the same logical network via two (or more) different links.  One example is a laptop connected to the same LAN via a wired Ethernet connection and a wireless connection.  This is a valid configuration and both links will have the same subnet of the LAN. Stacks like Windows support this and assign an interface metric to the out going interfaces.  The metric is used in picking an outgoing interface.

2) A multi-homed product is connected to two (or more) separate physical networks that have the same subnet.  The important differences is that the links are to different separate physical networks.  Since the subnets are the same, different networks can no longer be identified at the IP address abstraction level.  This can be considered an invalid network configuration since different IP networks are identified by their subnet/address range.

I'm all in favor of supporting 1) in LwIP as long as the implementation meets the "light-weight" requirements, but I'm not a fan of supporting 2).  This case is a huge pain because it permits invalid network configurations.  Not to mention, from the application layer you have to introduce some other identifier for addressing the different networks (can't use subnet). You end up having to forcing sockets onto the appropriate network with SO_BINDTODEVICE.  If we want LwIP to detect a case like 2) that would be fine, but then how to do you tell the difference between 1 & 2?

Joel


On Nov 17, 2014, at 06:34 AM, Fabian Koch <address@hidden> wrote:

Hey Simon, Hey Erik,

 

we do have a setup with two netifs and we cannot determine what the customer will do with the device so we need to also check for „same subnet“ scenarios.


I already wrote and email to this (or devel?) list about that a while ago.

 

We also attacked the problem by including the src IP into the ip_route() function and I can provide a patch, but it just doesn’t feel right.

 

The reason this is needed is actually because LwIP uses ip_route() to find a netif when the local address is INADDR_ANY.

 

In udp_connect(), udp_sendto(), tcp_eff_send_mss(), snmp_send_trap() and etharp_add_static_entry().

 

In all those cases, ip_route() is actually not really a good function to find a matching netif. If we were to replace those instances with another function that is a bit more complicated and finds a fitting netif with more aspects including gateway settings and network reachability (if that’s even a word…) then it would make the final routing a bit easier.

 

Also, the default_netif construct is just too simple to make all this work correctly.

 

If you need a quick solution, you can make ip_route include the src, but then you also have to add that parameter to tcp_eff_send_mss().

 

Our middle part of ip_route() looks like this at the moment:

 

  /* iterate through netifs */

  for (netif = netif_list; netif != NULL ; netif = netif-> next ) {

    if ( netif_is_up (netif) && netif_is_link_up (netif)) {           //only consider interfaces which are up and have a link

      if ( ip_addr_isany (src)) {    //when the source IP is INADDR_ANY, the socket is not bound to an interface => find the first match (netmask or is broadcast)

         if ( ip_addr_netcmp (dest, &(netif->ip_addr), &(netif-> netmask )) || ip_addr_cmp ( IP_ADDR_BROADCAST , dest)) {

          /* return netif on which to forward IP packet (first matching netif when socket is not bound) */

          return netif;

        }

      } else { // socket is bound to a specific IP so only match the right netif (matching IPs and either fits netmask or is broadcast)

        if ( ip_addr_cmp ((&netif-> ip_addr ), src) && ( ip_addr_netcmp (dest, &(netif->ip_addr), &(netif-> netmask )) || ip_addr_cmp ( IP_ADDR_BROADCAST , dest))) {

          /* this socket is bound to a specific interface, so look for that */

          return netif;

        }

      }

    }

  }

 

This essentially makes sending on specific interfaces possible when they are bound to the IP. Unbound sockets just send on the best matching netif they can find.

 

For this to work, you also need to netif_set_link_up(&loop_netif) in netif.c if you’re using a loopback netif. (I wonder if it can be considered a bug that the loopif never gets a link up…)

 

I would still not like this in the main lwIP source tree, since it just doesn’t feel right to include the src IP here.

 

 

Cheers,

Fabian

 

From: lwip-users-bounces+address@hidden [mailto:lwip-users-bounces+address@hidden] On Behalf Of address@hidden
Sent: Freitag, 14. November 2014 21:29
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Sending to a non-local network without default netif set

 

HaaCee2 wrote:

I beg to differ....


I've added a task for this to the tracker:

https://savannah.nongnu.org/task/index.php?13397


Simon

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users


reply via email to

[Prev in Thread] Current Thread [Next in Thread]