This has been necessary as we needed the 1043v2 models when no stable
firmware had had been released for them, yet. In order not to
"accidentially" force its users to a testing firmware we included this
now obsolete fix.

The file can be deleted as it is not part of the overlay or is listed
in sysupgrade.conf.

With this commit, the allowed networks for ipv4 and ipv6 are
retrieved from the global config file site.conf. An additional
option was added "additional_prefix6" to hold all extra prefixes
beside the main prefix given in "prefix6".

See https://git.c3pb.de/freifunk-pb/ffpb-packages/issues/3

In 180-increase-arp-caches the same logic was called again
and again. This could be done by a function!

See https://git.c3pb.de/freifunk-pb/ffpb-packages/issues/2

gets changed. Therefore these scripts must be adjusted
to the new structure.

See: http://gluon.readthedocs.org/en/latest/dev/upgrade.html

Include IPv4/6-firewall configurations of a node in ffpb-debug report

Extends the `ffpb-debug` script to fetch the current firewall configuration of a node, such that this information can be included in a ffpb-debug report.

Stefan Laudemann authored 10 years ago and Stefan Laudemann committed 10 years ago

Using ip6tables instead of "iptables -6", as the latter is not supported.

Signed-off-by: Stefan Laudemann <thisco@zitmail.uni-paderborn.de>

Including all active iptables tables (raw, filter, net, mangle). Apparently the
table 'security' is not in use on a node, hence it is left out here.

Signed-off-by: Stefan Laudemann <thisco@webcake.de>

This is NOT a complete package NOR has the current implementation been tested.
It just reflects the state of the work as it exists on my harddrive, hence it
is committed into a feature-branch such that someone else can continue the
work ...

As '/lib/netifd/hostapd.sh' and '/lib/wifi/mac80211.sh' should never be
called directly (but only be included from other files like '/lib/netifd/
wireless/mac80211.sh', these files do not need to have an execute bit
set, which on the other hand would be ensured by using the
$(INSTALL_BIN) macro in the make file. The $(CP) macro would simply copy
the files from the package into the image and preserve their
permissions.

Signed-off-by: Stefan Laudemann <thisco@webcake.de>

For an so far unknown reason one of the nodes in the testing stream had
an additional open WLAN called 'OpenWrt' after updating from v0.5.3 to
v0.6.0~rc2. It has to be mentioned, though, that this node used a
heavily customized network configuration prior to the update to fullfil
some very specific needs.

It should however be avoided that a new network suddenly appears after
applying an update in any case. As a cause for this, the mac80211.sh
located in '/lib/wifi/' has been identified, which scans for unknown
PHYs when executed and adds them along with such an example network to
'/etc/config/wireless'. For a pure OpenWRT router this behaviour is not
that much a problem, as the radio itself gets deactivated by adding an
"option disabled '1'" that must be removed manually by a user. In comb-
ination with Gluon this becomes critical, as the gluon-mesh-batman-adv-
core package would enable the radio automatically, such that a node can
connect to other Freifunk nodes over WiFi. Generally, a network
'OpenWrt' should not exist anymore in '/etc/config/wireless' by that
time. The reason for which in the case mentioned above there was such
an entry is still unknown.

In order to exclude such a security risk, for now we provide a modified
copy of '/lib/wifi/mac802111.sh' with this packages, in which the
corresponding lines to add a default/example network 'OpenWrt' have been
removed compeletely. This modified version of the script replaces the
original script at build-time.

Signed-off-by: Stefan Laudemann <thisco@webcake.de>

Adds a bunch of Master Control Program (MCP) quotes from the movie TRON
to the console output behaviour of the script. To be honest, there is no
particular reason for this, besides the idea of "enhancing" the output
with some nerd-humor.

Signed-off-by: Stefan Laudemann <thisco@webcake.de>

As the old implementation lead to rather inconsistent notifications on the
screen due to some incorrect return value handlings of os.execute(cat ...),
which as well produced an inconsistent output (an error message of netcat
got printed to the screen for the first host without the information that
there is a second one to which the report can be send; if the transmission
to that host succeeds, one will see the irritating sequence "failure" -->
"report has been sent" on the screen).
As error handling and output-redirection via os.execute(...) would have re-
quired some refactoring anyway, the logic is now implemented using nixio
sockets, as their behaviour is easier to control from within a Lua-script,
and - additionally - enables us to keep the debug data in memory (i.e. we
don't have to temporarily write it to /tmp/debug-report.txt anymore). The
report only needs to be stored permanetely, if the transmission fails for
whatever reason. Thus, as this part of the script had to be changed as well,
we now make use of the nixio library to interact with files.

Signed-off-by: Stefan Laudemann <thisco@webcake.de>

As it turned out, the old hostapd.sh from BB does not provide all the
necessary functions needed by the mac80211.sh that got added in commit
f2d78863. The corresponding hostapd.sh
from the CC trunk [1] however has this functions and works fine in BB
already. Hence, we add the netifd.sh from [1] into the package because
of the fixes in mac80211.sh in CC that did not get backported to BB
(yet). netifd.sh gets renamed to hostapd.sh by the Makefile for the
hostapd package and copied to /lib/netifd.

[1]
https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/netifd.sh?rev=44438



Signed-off-by: Stefan Laudemann <thisco@webcake.de>

As mentioned in [1], the hwmodes "11ng" and "11na" are no longer valid
in BB and become "11g" and "11a". Enabling 802.11n modes are set via the
htmode option now.

Moreover, as the version of BB we rely on with Gluon v2014.4 comes with
a faulty setup script for mac80211 that prevents setting of htmode in
adhoc mode, we replace the default script with a newer one from [2].
Additionally, the mcast_rate value did not get applied correctly in the
BB base of v2014.4, which gets fixed by this exchange as well.

[1] https://dev.openwrt.org/ticket/17541
[2]
https://dev.openwrt.org/browser/trunk/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh?rev=43853

packages.

The file zz~-ffpb-upgrade will only be delete if its return value is 0.
For some reason we forgot to add an 'exit 0' at the end of the file if
everything is OK. This has been added.

To deal with invariant scripts that were not executed properly, we now
test the return value of do_component for these scripts as well. The
function do_component however may return early with a return code not
equal to 0, if a version for that package/script could not have been
determined. We now return the code 255 in this case and ignore that
state in "main", as we are not interested in non-ffpb packages.

The package by now was rather aimed to target on the migration of
TP-Link TL-WR1043NDv2 devices from a pseudo-stable firmware to the
officially stable version 0.6.0.

However, as it might become necessary to change other configuration
values from AA to be compliant with their corresponding values in BB
independent from the particular hardware-type, the package got renamed
to reflect this use. Moreover, as there only is the need to migrate
TP-Link TL-WR1043NDv2 devices once, with the new name the package can be
reused for the migration to Chaos Calmer by adapting the included
scripts.

Closes issue #2 by adding appropriate tests to the script as requested
by @hej, such that values that have already been set to a higher value
to not get changed.

As its name states, this packages applies some config optimizations
(like tweaking kernal knobs via sysctl) on the nodes.
For the most knobs Gluon sticks for OpenWRT defaults for good reasons,
as some values need to be set according to the environment of the
nodes (e.g. the network's size). As OpenWRT basically aims at provid-
ing a stable system for standalone WiFi access-points, the system's
default configuration may not be appropriate anymore the larger the
network grows, though.