This commit adds support to send and receive multicast on the loopback
netif by enabling IGMP via NETIF_FLAG_IGMP
This commit also introduces an LwIP configuration option,
LWIP_LOOPIF_MCAST, to control the behavior and it defaults to off
the netif_add_ip6_address function was declared err_t in
src/include/lwip/netif.h, but defined as s8_t (the default value of
err_t) in its implementation in src/core/netif.c.
this causes "conflicting types for 'netif_add_ip6_address'" errors if
err_t is defined differently in cc.h (as for example recommended in
[1]).
as it only returns error constants, it is changed to use err_t
throughout.
[1] http://lwip.wikia.com/wiki/Porting_For_Bare_Metal
When LWIP_HAVE_LOOPIF is enabled, a separate loopback interface is added
as a netif. A netif need to have its link state set to up to be able to be
selected as a route in ip4_route or ip6_route.
The regression appears to be when bug #43904 (ip_route() and ip6_route()
must detect linkup status) was fixed.
Furthermore, there is no point of having the loopif down by default.
ip_addr_t is used for all generic IP addresses for the API, ip(4/6)_addr_t are only used internally or when initializing netifs or when calling version-related functions
lwip/src/core/netif.c: In function ‘netif_set_ipaddr’:
lwip/src/core/netif.c:403:5: warning: implicit declaration of function ‘udp_netif_ipv4_addr_changed’ [-Wimplicit-function-declaration]
udp_netif_ipv4_addr_changed(&netif->ip_addr, ipaddr);
^
this changes the callback signatures of the ip_output and the
{udp,raw}_recv functions.
changes were made by going through all header files, searching for
occurrences of ip_addr_t, qualifying them as const and if required
modifying the corresponding c files, looking for other uses of ip_addr_t
that would be required.
the following header files were not treated as i'm not using them and
wouldn't see them compiled: api.h api_msg.h dhcp.h dns.h igmp.h
netifapi.h pppapi.h snmp.h snmp_msg.h snmp_structs.h ppp.h pppol2tp.h
test/*
no modifications were done on ip6_addr_t.
Using the pbuf_clen() function to calculate the number of pbufs
for the first packet in the queue is not correct here, as pbuf_clen()
will return the total number of pbufs in the loopback I/F queue.