lwip-devel
[Top][All Lists]
Advanced

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

Re: [lwip-devel] Adding a static route table in LwIP


From: Ivan Delamer
Subject: Re: [lwip-devel] Adding a static route table in LwIP
Date: Mon, 25 May 2015 12:25:51 -0600

Hi,

A hook is the way to go. Check master branch, you can define LWIP_HOOK_IP6_ROUTE for this purpose.

This will allow you to choose the proper netif based on your own static routing. The stack will then select the correct source address. In your netif->output_ip6 function you would then resolve your router MAC address, either through ND6 or through the static table (or a mixed approach, however you implement it).

Cheers
Ivan


Date: Fri, 22 May 2015 16:14:27 -0300
From: Daniel Gutson <address@hidden>
To: lwip-devel <address@hidden>
Subject: Re: [lwip-devel] Adding a static route table in LwIP
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

El 22/5/2015 16:07, "Russ Dill" <address@hidden> escribi?:

On Fri, May 22, 2015 at 9:52 AM, Daniel Gutson
<address@hidden> wrote:
On Thu, May 21, 2015 at 12:59 PM, Ivan Delamer <address@hidden>
wrote:
Hi Pradip,

I think a static IPv6 route table is a nice feature to have. I think
some
people have implemented something similar for IPv4. Also someone has
implemented a NAT.

Hi all.

Sorry if my question/suggestion is completely out of place. Please
note that I'm not a telecommunications expert,
but a user (of real time and embedded systems which use LwIP).

Would adding this as a plug-in be a good idea?
Or more specifically: would an extension mechanism where features like
this one could be added
aside of the core library? Of course I don't mean dynamic loading, but
just to provide a set of hooks
placed in the right places so extensions could register callbacks.

Could that make sense? The first step would be to add the appropriate
hooks (then refactor this feature
and possible other features such as NAT as well, so they can be
written as opt-in extensions?).
The main purpose would be neat maintainability.

Please let me know. If this happens to make sense, we could see how to
collaborate.


Both solutions are possible, but keep in mind that lwIP is "a
light-weight implementation of the TCP/IP protocol suite", and "The
focus of the lwIP TCP/IP implementation is to reduce the RAM usage".
So any patch to lwIP has to take into account bloat. Adding a feature
that can be compiled in or out does not effect the size of lwIP for
users that do not enable that feature. Adding hooks that can call into external or compiled in modules increases the code size even for users
that don't enable that extra module.

Agree and I'm fully aware of that fact since I'm specially interested about
it: we put LWIP on RTEMS on a 32k RAM board :)

The hooks could be preprocessor-conditionally enabled or disabled by macros
associated to functionality families, such as

#ifdef ENABLE_XXXX_HOOKS
    call_xxx_callbacks();
#endif


_______________________________________________
lwip-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.nongnu.org/archive/html/lwip-devel/attachments/20150522/f3c4d14e/attachment.html>

------------------------------

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


End of lwip-devel Digest, Vol 131, Issue 17
*******************************************



reply via email to

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