Previously, ethip6 and lowpan6 each had their own copy of code that
used internal nd6 data structures to decide whether to send a packet
on the local link right away, or queue it while nd6 performed local
address resolution. This patch moves that code into nd6, thereby
eliminating all remaining cases of external access to internal nd6
data structures, as well as the need to expose two specific nd6
functions.
As a side effect, the patch effectively fixes two bugs in the lowpan6
code that were already fixed in the ethip6 code.
This patch rearranges the code division between nd6.c and ip6.c such
that the latter does not need to access ND6-internal data structures
(specifically, "default_router_list") directly anymore.
The new function, while currently not used internally, allows external
code to clear the ND destination cache in the case that it may have
become inconsistent with the current situation, for example as the
result of a change of locally assigned addresses, or a change in
routing tables implemented through the LWIP_HOOK_ND6_GET_GW hook.
On failure, nd6_get_next_hop_entry() returns an ERR_ type negative
error code. ethip6_output() erroneously assumed that that error would
always be ERR_MEM, even though it may also be ERR_RTE in practice.
With this patch, ethip6_output() simply forwards the returned error.
Generally speaking, packets with a loopback destination address -
127.0.0.1 for IPv4 and ::1 for IPv6 - should not be accepted on
non-loopback interfaces. For IPv4, this is implied by RFC 1122
Sec. 3.2.1.3. For IPv6, it is mandated by RFC 4291 Sec. 2.5.3.
Failure to perform this filtering may have security implications, as
applications that bind sockets to loopback addresses may not expect
that nodes on the local external network be able to produce traffic
that will arrive at such sockets.
With this patch, lwIP drops packets that are sent to a loopback
address but do not originate from the interface that has the loopback
address assigned to it. This approach works regardless of whether it
is lwIP or the system using it that implements a loopback netif. The
only exception that must be made is for configurations that enable
netif packet loopback but disable the lwIP loopback netif: in that
case, loopback packets are routed across non-loopback netifs and would
thus be lost by the new filter as well.
For IPv6, loopback-destined packets are also no longer forwarded; the
IPv4 forwarding code already had a check for that.
As a small performance improvement, the IPv6 link-local/loopback
address check is now performed only once per packet rather than
repeatedly for every candidate netif.
In general, netif_default may be NULL, and various places in the code
already check for this case before attempting to dereference the
netif_default pointer. Some places do not perform this check though,
and may cause null pointer dereferences if netif_default is not set.
This patch adds NULL checks to those places as well.
The mld_group structure no longer has a 'netif' field, as such
structures are now linked from the corresponding netif structure.
For conditional checksumming, use the calling function's netif
reference instead.
Let lwip use functions/macros prefixed by lwip_ internally to avoid naming clashes with external #includes.
Remove over-complicated #define handling in def.h
Make functions easier to override in cc.h. The following is sufficient now (no more LWIP_PLATFORM_BYTESWAP):
#define lwip_htons(x) <your_htons>
#define lwip_htonl(x) <your_htonl>
delay_time and stale_time are ticks now.
reachable_time and invalidation_timer are untouched since they may originate from telegram values -> not converting them to ticks avoids an integer division
Reasoning:
- Makes code in single-netif case perform better and smaller
- IGMP / MLD6 code is a little bit easier to read and understand
- Easier to get multicast groups per netif when implementing drivers
Downside: In multi-netif mode, there are two more pointers on each netif, even if IGMP/MLD6 is not used on it. But these systems should not be so memory-constrained that this will matter.
When leaving a multicast group, remove the group from the list
before invoking the MAC filter callback. This avoids the need
for the callee to skip over the group that is about to be deleted.
In the BSD socket API world, IP_HDRINCL is a socket option for "raw"
sockets that indicates whether sent packets already include an IP
header. Within lwIP, "IP_HDRINCL" is redefined as a special value
that indicates to lwIP-internal functions that an IP header is already
included. While somewhat related, the two meanings are different and,
on platforms that define the IP_HDRINCL socket option, this results in
a conflict. This patch renames the lwIP one to "LWIP_IP_HDRINCL",
thus resolving the conflict.
