Hi Ivan,
Thanks for your input. Your suggestion of keeping the route selection
separate seems doable. I could have my routing functions in a
separate
static_route_table.c/h file and enable the LWIP_HOOK_IPV6_ROUTE macro
with
the route lookup function.
However, regarding the next-hop selection based on the gateway, I had
added the following snippet in the nd6_get_next_hop_entry(..) for
populating the next_hop within the destination cache's
*nd6_cached_destination_index* entry. After the destination cache's
nexthop entry is populated, the neighbor cache entry is also
populated
accordingly. All this happens inside this function in nd6.c.
However, if I have to do this prior to nd6_get_nest_hop_entry(..) in
ethip6_output(), could you suggest how the destination cache's cached
index
entries could be populated appropriately?
The modification that I made in nd6_get_next_hop_entry(..) in nd6.c
is
something like this:-
* }*
* else {*
*#if LWIP_IPV6_ROUTER_SUPPORT*
* /* We need to select a router. */*
* i = nd6_select_router(ip6addr, netif);*
* if (i < 0) {*
* /* No router found. */*
*
ip6_addr_set_any(&(destination_cache[nd6_cached_destination_index].destination_addr));*
* return ERR_RTE;*
* }*
* destination_cache[nd6_cached_destination_index].pmtu =
netif->mtu; /* Start with netif mtu, correct through ICMPv6 if
necessary */*
*
ip6_addr_copy(destination_cache[nd6_cached_destination_index].next_hop_addr,
default_router_list[i].neighbor_entry->next_hop_address);*
*+#if LWIP_IPV6_STATIC_ROUTES_SUPPORT*
*+ /* See if a static route is configured for the destination
address */*
*+ i = ip6_find_route_entry(ip6addr);*
*+ if (i >= 0) {*
*+ if (static_route_table[i].gateway != NULL) {*
*+
ip6_addr_copy(destination_cache[nd6_cached_destination_index].next_hop_addr,
*static_route_table[i].gateway);*
*+ }*
*+ }*
*+#endif*
*#else*
*
ip6_addr_set_any(&(destination_cache[nd6_cached_destination_index].destination_addr));*
* return ERR_RTE;*
*#endif /* LWIP_IPV6_ROUTER_SUPPORT */*
Thanks,
Pradip
On Wed, May 27, 2015 at 9:45 AM, Ivan Delamer <address@hidden>
wrote:
Date: Tue, 26 May 2015 17:06:48 -0700
From: pradip de <address@hidden>
To: address@hidden
Subject: Re: [lwip-devel] Adding a static route table in LwIP
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi Ivan,
Thanks again for the suggestion.
The LWIP_HOOK_IP6_ROUTE seems like a callback to higher level
implementation of a routing function. Sure it could be used for a
static
route check as well. However, the purpose of this hook is only to
return
an
outgoing netif, correct?
But what if the static route entry has a gateway that needs to be
picked
up
during selection of a next hop. There needs to be logic in
nd6_get_next_hop
code that looks up the static route table to fetch the gateway as
the
neighbor to send to.
For some reason it seems to me that a static route table is a basic
feature
and could be a separate part(albeit within conditional compilation
flags)
of the core IP6 routing mechanism instead of as a plugin or hook.
Plugins
or hooks are probably apt for hooking up advanced or sophisticated
routing
functions.
Thanks,
Pradip
Yes, LWIP_HOOK_IP6_ROUTE would check your static route table and
return
the suitable netif. Based on netif selection, the stack would select
a
suitable source address.
In your netif->output_ip6 function, you resolve the next hop. Take a
look
at ethip6_output(), you can use it as a template. You could insert
your
static route lookup code before the nd6_get_next_hop_entry() call.
You
don't need to use ethip6_output(), you can choose your own
implementation
when you add your netif.
Because static routing can be done in so many ways, I believe it
should
remain separate from ND6. We aim to be RFC compliant. I don't know
that we
could come up with a static route module that would satisfy
everyone.
My suggestion is that you post your work on Savannah as a patch, so
that
other people can benefit from it. If we see enough interest over
time, and
it proves stable, we can look at adding it to the master branch.
That's
actually how the IPv6 code started, as an optional patch. We may
also
create a development branch for this if we have several developers
working
on it.
Cheers
Ivan
_______________________________________________
lwip-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-devel