It can now be used when net.ipv4.ip_nonlocal_bind=1.

This makes the recovery daemon's local IP verification inefficient.
It can be optimised in a subsequent commit.

Fall back to bind() if unable to fetch IPs.

Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: John Mulligan <jmulligan@redhat.com>
Reviewed-by: Anoop C S <anoopcs@samba.org>

Arguably, this would have made sense back in commit
bf86562144fe4e9541bd993519aca958c2bdb794.

Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: John Mulligan <jmulligan@redhat.com>
Reviewed-by: Anoop C S <anoopcs@samba.org>

This is a wrapper around getifaddrs(2), which is in libreplace, so
should always be available.

Some users want to set net.ipv4.ip_nonlocal_bind = 1.  So, CTDB needs
a way of testing if public IPs are present, without using bind(2).

Doing all of this unconditionally in ctdb_sys_have_ip() will be
inefficient in the recovery daemon's local IP verification if there
are a lot of IP addresses.  Split it this way so the interface
information can be retrieved once and used multiple times.

This doesn't appear to need IP canonicalisation for IPv4-mapped IPv6
addresses.

Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: John Mulligan <jmulligan@redhat.com>
Reviewed-by: Anoop C S <anoopcs@samba.org>

Fix a problem where ctdb_killtcp (almost always) fails to capture
packets with --enable-pcap and libpcap ≥ 1.9.1.  The problem is due to
a gradual change in libpcap semantics when using
pcap_get_selectable_fd(3PCAP) to get a file descriptor and then using
that file descriptor in non-blocking mode.

pcap_set_immediate_mode(3PCAP) says:

  pcap_set_immediate_mode() sets whether immediate mode should be set
  on a capture handle when the handle is activated.  In immediate
  mode, packets are always delivered as soon as they arrive, with no
  buffering.

and

  On Linux, with previous releases of libpcap, capture devices are
  always in immediate mode; however, in 1.5.0 and later, they are, by
  default, not in immediate mode, so if pcap_set_immediate_mode() is
  available, it should be used.

However, it wasn't until libpcap commit
2ade7676101366983bd4f86bc039ffd25da8c126 (before libpcap 1.9.1) that
it became a requirement to use pcap_set_immediate_mode(), even with a
timeout of 0.

More explanation in this libpcap issue comment:

  https://github.com/the-tcpdump-group/libpcap/issues/860#issuecomment-541204548

Do a configure check for pcap_set_immediate_mode() even though it has
existed for 10 years.  It is easy enough.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15451

Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>

Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Tue Aug 15 10:53:52 UTC 2023 on atb-devel-224

A subsequent commit will insert an additional call before
pcap_activate().

This sequence of calls is taken from the source for pcap_open_live(),
so there should be no change in behaviour.

Given the defaults set by pcap_create_common(), it would be possible
to omit the calls to pcap_set_promisc() and pcap_set_timeout().
However, those defaults don't seem to be well documented, so continue
to explicitly set everything that was set before.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15451

Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>

Factor out a failure label, which will get more use in subsequent
commits, and only set private_data when success is certain.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15451

Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>

Add simple support for IPoIB via DLT_LINUX_SLL and DLT_LINUX_SLL2.
This seems to work, even when an IB interface is specified.

If this is later found to be insufficient, support for DLT_IPOIB can
be implemented.  See https://www.tcpdump.org/linktypes.html for a
starting point.

Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>

This uses Linux cooked capture link-layer headers.  See:

  https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html
  https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html

The header type needs to be checked to ensure the protocol
type (i.e. ether type, for the protocols we might be interested in) is
meaningful.  The size of the header needs to be known so it can be
skipped, allowing the IP header to be found and parsed.

It would be possible to define support for DLT_LINUX_SLL2 if it is
missing.  However, if a platform is missing support in the header file
then it is almost certainly missing in the run-time library too.

Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>

The current code will almost certainly generate ENOMSG for
non-ethernet packets, even for ethernet packets when the "any"
interface is used.

pcap_datalink(3PCAP) says:

  Do NOT assume that the packets for a given capture or ``savefile``
  will have any given link-layer header type, such as DLT_EN10MB for
  Ethernet.  For example, the "any" device on Linux will have a
  link-layer header type of DLT_LINUX_SLL or DLT_LINUX_SLL2 even if
  all devices on the sys‐ tem at the time the "any" device is opened
  have some other data link type, such as DLT_EN10MB for Ethernet.

So, pcap_datalink() must be used.

Detect pcap packet types that are supported (currently only ethernet)
in the open code. There is no use continuing if the read code can't
parse packets.  The pattern of using switch statements supports future
addition of other packet types.

Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>

Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>