Signed-off-by: Stefan Weil <sw@weilnetz.de>

"GPL-2.0+" with its successor "GPL-2.0-or-later"

Declare the clock variable as extern in the header file.

Fixes compilation of gluon-ebtables-limit-arp with OpenWrt master:

multiple definition of `clock'; /gluon/openwrt/tmp/ccuynR0G.o:(.bss+0x230): first defined here

Signed-off-by: David Bauer <mail@david-bauer.net>

This removes PKG_VERSION and PKG_RELEASE from most Makefiles, as the
value was never useful for Gluon packages; instead, PKG_VERSION is set
to 1 in gluon.mk.

It also removes two other weird definitions:

- gluon-iptables-clamp-mss-to-pmtu replicating the old PKG_VERSION logic
  from gluon-core, but without the fixed PKG_BUILD_DIR to prevent
  unnessary rebuilds
- gluon-hoodselector set GLUON_VERSION=3

With the removal of ramips-rt305x, the last user of
GLUON_SPECIALIZE_KERNEL is gone.

[Matthias Schiffer: fix up start/stop order and file permissions]

With the batman-adv multicast support compiled back in again we end up
with multicast addresses in the batman-adv translation table.

Currently we wrongly interpret multicast addresses returned by TT as a
unique host, too, which adds them with a source address filter to
ebtables as well. However, the source address of an ethernet frames is
never supposed to be a multicat one.

This leads to unnecessary entries in ebtables. Fixing this by ignoring
those MAC addreses returned by TT which have the multicast bit set.

Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>

This package adds filters to limit the amount of ARP Requests
devices are allowed to send into the mesh. The limits are 6 packets
per minute per client device, by MAC address, and 1 per second per
node in total.

A burst of up to 50 ARP Requests is allowed until the rate-limiting
takes effect (see --limit-burst in the ebtables manpage).

Furthermore, ARP Requests with a target IP already present in the
batman-adv DAT Cache are excluded from the rate-limiting,
both regarding counting and filtering, as batman-adv will respond
locally with no burden for the mesh. Therefore, this limiter
should not affect popular target IPs, like gateways.

However it should mitigate the problem of curious people or
smart devices scanning the whole IP range. Which could create
a significant amount of overhead for all participants so far.

Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>