This fixes a bug where some callers of netif_issue_reports were not
checking that both link and admin states were up, leading to extraneous
reports when calling one of the following
1) netif_set_ipaddr
2) netif_ip6_addr_set_parts
3) netif_ip6_addr_set_state
The bug has been fixed by placing link and admin state checks in
netif_issue_reports and not requiring the callers to perform this
checking
Fix below build error if LWIP_IPV4 == 0.
cc -g -Wall -DLWIP_DEBUG -pedantic -Werror -Wparentheses -Wsequence-point -Wswitch-default -Wextra -Wundef -Wshadow -Wpointer-arith -Wcast-qual -Wc++-compat -Wwrite-strings -Wold-style-definition -Wcast-align -Wmissing-prototypes -Wredundant-decls -Wnested-externs -Wno-address -Wunreachable-code -Wuninitialized -Wlogical-op -I. -I../../.. -I../../../../lwip/src/include -I../../../ports/unix/port/include -I../../../../mbedtls/include -Wno-redundant-decls -DLWIP_HAVE_MBEDTLS=1 -c ../../../../lwip/src/core/netif.c
../../../../lwip/src/core/netif.c: In function ‘netif_add’:
../../../../lwip/src/core/netif.c:284:7: error: ‘ipaddr’ undeclared (first use in this function)
if (ipaddr == NULL) {
^~~~~~
../../../../lwip/src/core/netif.c:284:7: note: each undeclared identifier is reported only once for each function it appears in
../../../../lwip/src/core/netif.c:285:14: error: implicit declaration of function ‘ip_2_ip4’ [-Werror=implicit-function-declaration]
ipaddr = ip_2_ip4(IP4_ADDR_ANY);
^~~~~~~~
../../../../lwip/src/core/netif.c:285:5: error: nested extern declaration of ‘ip_2_ip4’ [-Werror=nested-externs]
ipaddr = ip_2_ip4(IP4_ADDR_ANY);
^~~~~~
../../../../lwip/src/core/netif.c:285:23: error: ‘IP4_ADDR_ANY’ undeclared (first use in this function)
ipaddr = ip_2_ip4(IP4_ADDR_ANY);
^~~~~~~~~~~~
../../../../lwip/src/core/netif.c:287:7: error: ‘netmask’ undeclared (first use in this function)
if (netmask == NULL) {
^~~~~~~
../../../../lwip/src/core/netif.c:290:7: error: ‘gw’ undeclared (first use in this function)
if (gw == NULL) {
^~
cc1: all warnings being treated as errors
../../Common.allports.mk:94: recipe for target 'netif.o' failed
make: *** [netif.o] Error 1
Fixes: 5967380c20 ("netif_add: avoid passing NULL pointers to subsequent functions")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Dirk Ziegelmeier <dirk@ziegelmeier.net>
This sets the pbuf's if_idx during the loopif poll function (the
equivalent netif input function). This was found during IP_PKTINFO
development where p->if_idx is read and was uninitialized
Couple of more cleanups for task #14314 involving includes:
1) if.h name should match if_api.c due to LwIP convention and history.
Standard if.h include can be used with compatibility header in
posix/net/if.h
2) API header (if.h) should not be included in core code. This include
has been eliminated by moving the definition of IF_NAMESIZE to
netif.h as NETIF_NAMESIZE. This is now the canonical definition
and IF_NAMESIZE just maps to it to provide the standard type
This patch adds full support for IPv6 address scopes, thereby aiming
to be compliant with IPv6 standards in general and RFC 4007 in
particular. The high-level summary is that link-local addresses are
now meaningful only in the context of their own link, guaranteeing
full isolation between links (and their addresses) in this respect.
This isolation even allows multiple interfaces to have the same
link-local addresses locally assigned.
The implementation achieves this by extending the lwIP IPv6 address
structure with a zone field that, for addresses that have a scope,
carries the scope's zone in which that address has meaning. The zone
maps to one or more interfaces. By default, lwIP uses a policy that
provides a 1:1 mapping between links and interfaces, and considers
all other addresses unscoped, corresponding to the default policy
sketched in RFC 4007 Sec. 6. The implementation allows for replacing
the default policy with a custom policy if desired, though.
The lwIP core implementation has been changed to provide somewhat of
a balance between correctness and efficiency on on side, and backward
compatibility on the other. In particular, while the application would
ideally always provide a zone for a scoped address, putting this in as
a requirement would likely break many applications. Instead, the API
accepts both "properly zoned" IPv6 addresses and addresses that, while
scoped, "lack" a zone. lwIP will try to add a zone as soon as possible
for efficiency reasons, in particular from TCP/UDP/RAW PCB bind and
connect calls, but this may fail, and sendto calls may bypass that
anyway. Ultimately, a zone is always added when an IP packet is sent
when needed, because the link-layer lwIP code (and ND6 in particualar)
requires that all addresses be properly zoned for correctness: for
example, to provide isolation between links in the ND6 destination
cache. All this applies to packet output only, because on packet
input, all scoped addresses will be given a zone automatically.
It is also worth remarking that on output, no attempt is made to stop
outgoing packets with addresses for a zone not matching the outgoing
interface. However, unless the application explicitly provides
addresses that will result in such zone violations, the core API
implementation (and the IPv6 routing algorithm in particular) itself
will never take decisions that result in zone violations itself.
This patch adds a new header file, ip6_zone.h, which contains comments
that explain several implementation aspects in a bit more detail.
For now, it is possible to disable scope support by changing the new
LWIP_IPV6_SCOPES configuration option. For users of the core API, it
is important to note that scoped addresses that are locally assigned
to a netif must always have a zone set; the standard netif address
assignment functions always do this on behalf of the caller, though.
Also, core API users will want to enable LWIP_IPV6_SCOPES_DEBUG at
least initially when upgrading, to ensure that all addresses are
properly initialized.
This commit cleans up the remaining instance of global variable
"index" shadowing caused by using local variables and function
parameters named "index"
These were introduced in the recent interface index API commits
Adjusts assert logic from 9c80a66253
to allow for a netif driver's init callback to manually override
the number. When the init function is taking care of the unique
assignment, the assert simply checks that a valid number was provided
This commit adds an LWIP_ASSERT to detect when netif_num overflows and
we no longer have unique numbers per netif. Unique netif numbers are
needed to support interface indexes (task #14314)
The only cases where this could occur are with a deployment that attempts
to use the maximum 256 netifs at the same time or where netifs are being
constantly adding and removed. Neither of these use cases fit the
lightweight goals of LwIP
See discussion in task #14314 for more details
For applications that use NETIF_STATUS_CALLBACK to help keep track of
extra per-address shadow state of IPv6 addresses, even in the light of
autogenerated addresses (which may "spontaneously" appear/disappear),
state transitions between tentative, duplicated, and invalid are
important as well. Therefore, invoke the status callback for all such
state transitions. Continue to filter out state changes between
various levels of progress of the tentative state, though.
In summary, this patch aims to resolve bugs #47923 and #48162, by
decoupling address autoconfiguration from the on-link prefix list,
since those are not related. Important necessary changes are needed
to meet this goal, ultimately bringing the lwIP ND6 implementation
closer to compliance with RFC 4862. The main changes are:
1. support for address lifetimes, and,
2. addition of a new DUPLICATED address state.
The decoupling implies that the prefix list can no longer be used to
maintain state for address autoconfiguration. Most importantly, the
lifetime of each address, which was previously derived from the
prefix slot's lifetime, must now be associated with the address
itself. This patch implements address lifetime tracking, maintaining
both a valid and a preferred lifetime for each address, along with
the corresponding address state changes (e.g., between PREFERRED and
DEPRECATED), all as required by RFC 4862.
The support for address lifetimes can be enabled with a new
LWIP_IPV6_ADDRESS_LIFETIMES setting in lwipopts.h. It is required for
autoconfiguration and enabled by default if autoconfiguration is
enabled as well, but it may also be enabled separately, so as to allow
application-controlled lifetime management (e.g., if autoconfiguration
is implemented in a separate application). A special valid-lifetime of
zero is used to denote a static address--that is, an address that was
configured manually, that does not have lifetimes, and that should be
left alone by the autoconfiguration functionality. Addresses assigned
without setting a lifetime are deemed static, thus preserving
compatibility with existing lwIP-based applications in this respect.
Similarly, the decoupling implies that the prefix list can no longer
be used to remember cases of address duplication. Previously, the
detection of a duplicated address would simply result in removal of
the address altogether. Instead, this patch introduces a new state
"DUPLICATED", indicating that the address, while technically still
present, has been found to conflict with other node addresses, and no
attempt should be made to produce an autoconfiguration address for
that prefix.
Manually added addresses, including the link-local address, once set
to DUPLICATED, will remain in that state until manual intervention.
Autoconfigured DUPLICATED addresses will expire according to their
valid-lifetime, essentially preserving the current behavior but
without the use of the prefix list. As a first attempt to approach
compliance with RFC 4862 Sec. 5.4.5, if the link-local address is
detected to be duplicated, all derived addresses are marked duplicated
as well, and no new addresses will be autoconfigured. More work is to
be done for full compliance with that section, however.
Together, those two main changes indeed do fully decouple address
autoconfiguration from the on-link prefix list. Changes to the latter
thus no longer affect the former, resolving bug #47923. Moreover, as a
result, autoconfiguration can, and does, now also take place on
advertised prefixes that do not have the on-link flag set, resolving
bug #48162. The routing changes mentioned in the discussion of that
bug are left to a separate patch, though.
If MLD support is enabled, each locally assigned IPv6 address in the
appropriate state must be a member of the solicited-node multicast
group corresponding to that address. Ensure that this is always the
case by (re-)deciding on the membership upon every address state
change. By doing so, this patch enforces that user-initiated state
changes to addresses (e.g., deletion) never cause a desynchronization
with the corresponding solicited-node multicast group membership,
thereby making such user-initiated state changes simpler and safer.
