most of these are like, eg
void foo(int[2]);
with either of these
void foo(int*) { ... }
void foo(int[]) { ... }
in some cases (such as stat or utimes* calls found in our header files),
we now match standard definition from opengroup.
found by GCC 12.
- remove encap_attach() which is no longer used
- remove USE_RADIX code in ip_encap.c, which is used for
encap_attach() only
- remove mask members in encaptab
The tunnels attached by encap_attach() can process receiving packets
fastly as the softc is searched by radix-tree. However, the tunnels
cannot use priority function which decides tunnel's softc by not only
source and destination but also other informations.
On the other hand, the tunnels attached by encap_attach_func() can
use priority function. However, the tunnels can be slow receiving
processing as the softc is searched by linear search (and uses each
priority function).
encap_attach_addr() can be used for tunnels which is fixed tunnel
source address and tunnel destination address. The tunnels attached
by encap_attach_addr() is searched by thmap(9), so the receiving processing
can be fast. Moreover, the tunnels can use priority function.
Currently, NetBSD supports implicit unnumbered interface by setting
the same IP address to two interfaces. However, such interface is not
treated as unnumbered when one of the interfaces is being changed and
has been changed IP address. That behavior can be harmful for some
routing daemons.
A route with rt_ifa of AF_LINK can be set by some routing daemons when
it adds a route that has a gateway of AF_LINK. If there is no address on
a target interface, the kernel sets an AF_LINK address of the interface to
rt_ifa of the route. In that case, a variable of a local address in
ip_output (ia) can be NULL and we need more NULL-checks of it.
Here is mininum reproduction operation.
====================
# ifconfig ixg0 172.16.0.1/29
# route monitor &
# ifconfig pppoe0 172.16.0.1/32 0.0.0.1
====================
The broken RTM_DELADDR is the following.
====================
got message of size 72 on Thu Nov 17 12:50:42 2022
#13: len 72, got message of size 80 on Thu Nov 17 12:50:42 2022
RTM_DELADDR: address being removed from iface: len 80, pid 3552, metric 0, addrflags: 0
sockaddrs: 0xb4<NETMASK,IFP,IFA,BRD>
Q00.00.ff.ff.ff.ff.00.00.00.00.00.00.00.00 pppoe0 default default
====================
This problem is related to the following two commit.
(1) b021021468
that is, sys/netinet/in.c:r1.183
(2) 61bad33c44
that is, sys/netinet/in.c:r1.185
(1) adds in_scrubaddr() for old addresses to in_ifinit() without checking
IFA_ROUTE.
And then, (2) removes in_ifscrub() for POINTTOPOINT interface in in_control0.
The removed in_ifscrub() is called with checking IFA_ROUTE.
It seems these modifications about checking IFA_ROUTE logic causes this
problem, however the real reason is calling in_ifscrub() for the interface
which does not have IPv4 address. So, scrubbing old address processing
should be done only if the interface already has IPv4 address.
RFC 5227 section 1.1 states that for a DaD ARP probe the sender hardware
address must match the hardware address of the interface sending the
packet.
We can now verify this by checking the mbuf tag PACKET_TAG_ETHERNET_SRC.
This fixes an obsure issue where an old router was sending out bogus
ARP probes.
Thanks to Ryo Shimizu <ryo@nerv.org> for the re-implementation.
RFC 5227 section 1.1 states that for a DaD ARP probe the sender hardware
address must match the hardware address of the interface sending the
packet.
We can now verify this by checking the mbuf packet header.
This fixes an obsure issue where an old router was sending out bogus
ARP probes.
andvar