The heartbeat messages, notably, should really not be lost, otherwise the
cluster will dismantle itself if some very-high trafic is filling packet
queues.
If we are a master and we don't have peers, there is no use keeping the
sessions alive, when we'll restart we will have forgotten them all.
Better gracefully close them, so they can be quickly respawn on restart,
instead of having to wait for timeouts.
The RFC indeed say that we should send them periodically. We were
previously only sending them along LCP echo replies, but echo requests
are typically sent only when there is no trafic, which RA need to be
sent even when there is trafic.
The size of the memset was just wrong, but the data has already been
zeroed in initdata so we can just remove it.
# This is the commit message #2:
# squash! initippool: fix initialization of ip_address_pool
net/if.h and linux/if.h headers conflict with each other as of linux
6.3 and glibc 2.37 headers:
In file included from /usr/include/linux/icmp.h:23,
from icmp.c:5:
/usr/include/net/if.h:44:5: error: redeclaration of enumerator ‘IFF_UP’
44 | IFF_UP = 0x1, /* Interface is up. */
| ^~~~~~
/usr/include/linux/if.h:83:9: note: previous definition of ‘IFF_UP’ with type ‘enum net_device_flags’
83 | IFF_UP = 1<<0, /* sysfs */
| ^~~~~~
icmp.c gets net/if.h from l2tpns.h, and linux/if.h from linux/icmp.h.
In our case, we do not need to use the linux headers at all here as we
are doing normal userspace things: just use glibc headers all the way.
This has been tested with kernel 3.2 / glibc 2.13 headers, so it's
probably fine. (l2tpns does not currently build with musl)
When acting as LNS, we have to answer challenges with our own secret, but
when acting as LAC, we have to answer challenges with the LNS secret, not
ours.
It seems at least some products send this:
{LCP (0xc021), length 12: LCP, Conf-Nack (0x03), id 9, length 10
encoded length 8 (=Option(s) length 4)
0x0000: c021 0309 0008
Auth-Prot Option (0x03), length 4: CHAP[|lcp]}
If we refuse to nack to CHAP, we'd stay stuck with PAP and eventually
get a reject.
if the packet is too small then reading pack + ETH_HLEN is invalid, first
check that the packet is big enough then read the header at an offset we
know is valid
Reported-by: Coverity#375305
&peer->outbuf->packet has a non-1 size, so &foo + offset would
incorrectly offset by sizeof(packet) * offset, while it is meant as a
byte offset.
Cast to char * to have a simple offset.
Reported-by: Coverity#375309
