buglwIP - A Lightweight TCP/IP stack - Bugs: bug #34683, IPv4 routing doesn't consider...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #34683: IPv4 routing doesn't consider source IP address

Submitter:  Amir Shalem <amirshalem>
Submitted:  Sat 29 Oct 2011 10:49:13 AM UTC
   
 
Category:  IPv4 Severity:  3 - Normal
Item Group:  Change Request Status:  Wont Fix
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  CVS Head

Jump to the original submission

Fri 21 Dec 2012 06:16:45 PM UTC, comment #14: 

Posting my comment here per request from Simon Goldschmidt:

We have an embedded customer that has just adopted LWIP.  They previously had a different stack and a configuration that had two network interfaces on the same subnet.  I'd like to be able to provide them an LWIP implementation that allows them to carry their existing configuration forward.

Christopher Pow <cpow>
Fri 21 Dec 2012 04:20:04 PM UTC, comment #13: 

I'm with Kieran's comment #4: I'm happy for lwIP not to support 2 netifs in the same subnet for now.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 07 Dec 2011 10:40:52 AM UTC, comment #12: 

Yes, in this simple scenario '<----->' means the same physical network.

In my specific case IP routing based on source IP address as well as disabling slow start and congestion avoidance algorithms makes sense in case of wireless network on L2 (data link layer) and L1 (physical layer), i.e. ARP/Ethernet functionality of lwIP is not used.

I agree that most of the people would never require such type of IP routing, but I would be really happy to see some advanced routing options in the future versions. Thanks for such a good and reliable TCP/IP stack!

Max Galemin <mgalemin>
Wed 07 Dec 2011 10:13:40 AM UTC, comment #11: 

By '<----->', you mean that lwIP and PC1/2 are on the same physical network without a router (i.e. only switches)? If so, that's not supported by standard IP routing, as far as I know.

 I don't think that will work by only changing IP routing to consider the source address: etharp_output() compares the destination address with the subnet and sends to netif->gw if this check fails.

In the spirit of 'lightweight' in our name, we have decided to not support such extended routing mechanisms and network setups, in the past.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 07 Dec 2011 09:25:17 AM UTC, comment #10: 

[lwIP NI1: 10.1.1.100/24] <-----> [PC1: 192.168.1.100/24]
[lwIP NI2: 10.1.2.100/24] <-----> [PC2: 174.100.3.4/16]

Two TCP sockets are listening on both lwIP interfaces. How can I establish TCP sessions from PC1 to lwIP NI1 and from PC2 to lwIP NI2?

Max Galemin <mgalemin>
Wed 07 Dec 2011 07:53:10 AM UTC, comment #9: 


> routing based on source IP address [..] makes sense in case of
> multiple NI physically connected to the different subnets


Really? How so, could you please explain this?

> Another scenario is using RF wireless network on L1/L2 which
> requires mapping of LwIP NI to the RF air interface.


Again, please describe why routing based on source address is necessary here.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 07 Dec 2011 02:49:28 AM UTC, comment #8: 

IP routing based on source IP address of the IP packet makes sense in case of multiple NI physically connected to the different subnets. Another scenario is using RF wireless network on L1/L2 which requires mapping of LwIP NI to the RF air interface.

It would be really nice if this feature could be added to the LwIP stack. Thanks.

P.S. Additionally, it would be very useful if Slow Start and Congestion Avoidance algorithms could be switched off in LwIP configuration.

Max Galemin <mgalemin>
Sun 13 Nov 2011 04:09:34 PM UTC, comment #7: 


> I still think this falls outside of the set of things that a
> lightweight stack should include.


I agree. However, since ip6_route also uses src and dst for routing and we can easily disable passing src (through a define), I wouldn't be against this change if people really need it...

On the other hand, I'm not convinced many people would really need this, especially in embedded systems, which is still the main target of lwIP.

Simon Goldschmidt <goldsimon>
Group administrator
Thu 10 Nov 2011 04:33:28 PM UTC, comment #6: 

I still think this falls outside of the set of things that a lightweight stack should include.

Kieran Mansley <kieranm>
Group Member
Tue 08 Nov 2011 05:56:16 AM UTC, comment #5: 

Please note that "Multiple netif on the same subnet" is feature I need for unit-testing my code.
Other possible uses are being able to have few netif connected to the "Internet", and by binding to the correct source IP, I can choose the gateway (traffic shaping).

I agree with simon that this feature should be #ifdef, because that's a corner case which most lwIP users doesn't need/want.
kieran, what do you say?

P.S.
And like simon side there are many other places where we can save "opcodes", if assuming there's only one netif.

Amir Shalem <amirshalem>
Tue 01 Nov 2011 12:47:32 PM UTC, comment #4: 

Supporting multiple netifs on the same subnet is one of those things that I'm happy for lwIP not to support to keep it lightweight.

Kieran Mansley <kieranm>
Group Member
Sat 29 Oct 2011 07:59:16 PM UTC, comment #3: 

No need to change the patch, adding the define in that patch is not a big deal. I only wanted to discuss that define before actually making the change. When adding such a define, there may be other places (in the current code), which may also can be changed to smaller code for the single-netif case...

Simon Goldschmidt <goldsimon>
Group administrator
Sat 29 Oct 2011 07:49:19 PM UTC, comment #2: 

if I will change the patch to include #define, would you accept it?
same for the other bug #34684

Amir Shalem <amirshalem>
Sat 29 Oct 2011 07:43:29 PM UTC, comment #1: 

Hmm, this is really only needed in your special case, I guess. Up to now, we didn't support having 2 netifs in the same subnet.

As I said in bug #34684, I think we might need a config option for single- or multiple netif support to keep the code small on single-netif targets. I'm currently working on a port for an 8-bit AVR using slipif and passing more arguments than necessary is always a big deal there!

Simon Goldschmidt <goldsimon>
Group administrator
Sat 29 Oct 2011 10:49:13 AM UTC, original submission:  

I made ip_route() to consider the source IP address.

This includes 3 different patches:

1. 0001-make-ipv4-ip_route-choose-the-netif-by-the-source-ad.patch
2. 0002-ARP-entries-should-be-separated-not-only-by-destinat.patch
3. 0003-Support-setting-static-arp-on-different-network-inte.patch

I need this behavior change in-order to have two separate netif, having different IP addresses but on the same IP subnet. This is required for unit-testing pylwIP code base.

If application doesn't bind to a specific IP, it the algorithm is exactly as before.

Patches included.

Amir Shalem

Amir Shalem <amirshalem>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by cpow (Posted a comment)
  • -email is unavailable- added by mgalemin (Posted a comment)
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by amirshalem (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-12-21 goldsimon StatusNone Wont Fix
        Assigned toNone goldsimon
        Open/ClosedOpen Closed
    2011-10-29 amirshalem Attached File- Added 0001-make-ipv4-ip_route-choose-the-netif-by-the-source-ad.patch, #24239
        Attached File- Added 0002-ARP-entries-should-be-separated-not-only-by-destinat.patch, #24240
        Attached File- Added 0003-Support-setting-static-arp-on-different-network-inte.patch, #24241

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code