[PATCH] fff-hoods: Use alfred for hood file redistribution
Christian Dresel
fff at chrisi01.de
Do Nov 2 10:23:12 CET 2017
hi
On 02.11.2017 10:20, Adrian Schmutzler wrote:
> Hallo,
>
> was passiert denn im falle einer hoodteilung? Reicht das switchen des
> uplinks, dass die mesh-router dann im neuen layer2 der neuen hood sind
> (und so die neuen files downloaden)?
im Falle der Hoodteilung würde sich der Uplinkrouter komplett neu
konfigurieren (neue BSSID) und die Meshrouter würden ihr GW verlieren
und komplett von vorne (w2sta) anfangen.
Folgender fall könnte aber interessant sein:
Meshrouter A sieht Uplinkrouter B und Uplinkrouter C
Uplinkrouter B bleibt in Hood 1, Uplinkrouter C wird durch Hoodtrennung
in Hood 2 geschoben.
Aber selbst da ändert Router C seine BSSID config und wird nicht mehr
mit Meshrouter A meshen und somit wird Meshrouter A niemals die config
der neuen Hood sehen.
mfg
Christian
>
> Und alle Router die beide Hoods sehen, bleiben bei der alten...?
>
> Grüße
>
> Adrian
>
> On November 2, 2017 9:35:14 AM GMT+01:00, Christian Dresel
> <fff at chrisi01.de> wrote:
>
> hi
>
> On 02.11.2017 09:27, Adrian Schmutzler wrote:
>
> Hallo,
>
> 1. Man könnte die Infrastruktur so bauen, dass nur die Gateways
> hoodfiles per Alfred verschicken. Dies könnte der zielrouter
> überprüfen,
> indem man die macadressen der Gateways in die hoodfile schreibt. Der
> zielrouter nimmt dann nur die Einträge mit der richtigen
> sendermac. Für
> den dezentralen exchange könnte man das dann leicht auf den jetzigen
> stand umbauen.
>
>
> gefällt mir irgendwie nicht so recht. Ich hab aktuell 2 Ideen im Kopf:
>
> 1) Wir ignorieren es einfach, Möglichkeiten das L2 Netz kaputt zu machen
> gibt es sehr viele, das wäre dann nur eine davon.
>
> 2) Der Keyxchange signiert die Hoodfile mit ecdsautils und gibt die
> Signatur mit an die Uplinkrouter, welche sie wiederrum mit ins Alfred
> stecken. Die Meshrouter können die Signatur prüfen und die File für
> gültig erachten. Dann wäre der Umstieg auf den dezentralen Keyxchange
> noch leichter, da dies dort sowieso geplant war. Nur das es da nicht die
> Masterkeyxchange Signatur gibt sondern noch ein WebOfTrust und
> Usersignaturen so das sie irgendwo in die Hood als neue File
> reingesteckt werden kann.
>
> mfg
>
> Christian
>
>
> 2. Was mich im Moment noch stört ist dass wir so einen haufen
> Daten im
> ganzen layer2 rumschicken. Die hoodfiles sind ja nicht so klein
> und ich
> weiß nicht, wie oft das Netz die hin und her schickt.
>
> Grüße
>
> Adrian
>
> On November 2, 2017 9:13:21 AM GMT+01:00, Christian Dresel
> <fff at chrisi01.de> wrote:
>
> Morgen Robert
>
> später für den dezentralen Keyxchange wäre das ein absolut
> gewünschtes
> verhalten (da wären die Files signiert und es müssen auch genug
> Signaturen dran sein, damit sie gültig ist). Daher fände ich es
> toll,
> wenn wir es jetzt beim keyxchangev2 so hinbekommen das es zum
> aktuellen
> Zeitpunkt "relativ sicher" ist dann wäre der Umstieg später auf den
> dezentralen Keyxchange recht leicht.
>
> Uplinkrouter holen sich die File ja sowieso nicht aus der json
> sondern
> aus dem keyxchangev2. Vielleicht kann man da ansetzen das irgendwie
> abzusichern, eine richtige Idee habe ich aber gerade nicht.
>
> mfg
>
> Christian
>
> On 02.11.2017 08:58, robert wrote:
>
> Hallo,
>
> Mir ist da gerade ein Gedanke gekommen.
>
> Wenn wir das hoodfile über alfred verteilen, dann zieht die
> gesamte Hood
> nach, sobald irgendwo, aus welchem Grund auch immer ein neues
> Hoodfile
> auftaucht. Das bedeutet, jeder der einen Router in der Hood hat,
> kann
> diese umkonfigurieren. Nicht so gut.
>
> Robert
>
>
> Am 01.11.2017 um 23:44 schrieb Adrian Schmutzler:
>
> Please read inline comments. UNTESTED.
>
> Signed-off-by: Adrian Schmutzler <freifunk at adrianschmutzler.de>
> ---
> .../fff-hoods/files/lib/functions/fff/keyxchange | 28
> ++++++++++++++++++
> .../fff/fff-hoods/files/usr/sbin/configurehood | 34
> ++++++++++++++++++++--
> 2 files changed, 60 insertions(+), 2 deletions(-)
>
> diff --git
> a/src/packages/fff/fff-hoods/files/lib/functions/fff/keyxchange
> b/src/packages/fff/fff-hoods/files/lib/functions/fff/keyxchange
> index 9aeb434..2d645d0 100644
> ---
> a/src/packages/fff/fff-hoods/files/lib/functions/fff/keyxchange
> +++
> b/src/packages/fff/fff-hoods/files/lib/functions/fff/keyxchange
> @@ -31,3 +31,31 @@ getUpgradePath() {
> fi
> return 0
> }
> +
> +getJsonTimestamp() {
> + json=$1
> +
> + ts=0
> + if [ -n "$json" ] && json_load "$json" &>/dev/null ; then
> + json_select "hood" &>/dev/null && json_get_var ts timestamp
> + fi
> + echo "$ts"
> +}
> +
> +getJsonFromAlfred() {
> + datafile=$1
> +
> + tsold=0
> + jsonused=""
> +
> + while read -r line
> + do
> + json="$(echo "$line" | sed 's/[^,]*,\s*"//' | sed
> 's/"\s*},\s*$//' | sed 's/\\"/"/g')"
> + ts="$(getJsonTimestamp "$json")"
> + if [ "$ts" -gt "$tsold" ] ; then
> + jsonused="$json"
> + tsold="$ts"
> + fi
> + done < "$datafile"
> + echo "$jsonused"
> +}
> diff --git
> a/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
> b/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
> index 8ffaced..981f7aa 100755
> --- a/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
> +++ b/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
> @@ -9,6 +9,9 @@ sectorlocal=/etc/sectorfile
> sectortmp=/tmp/sectorfile
> sectorcopy=/www/hood/sectorfile
>
> +alfredfile=/tmp/alfredhood
> +alfrednum="65"
> +
> rm -f "$hoodfile"
>
> # Gatewaycheck function
> @@ -65,6 +68,29 @@ long=$(uci -q get
> system. at system[0].longitude)
> # if we have Internet, we download the Hoodfile from the
> keyxchangev2
> if hasInternet ; then
> wget -T15 -t5
> "http://keyserver.freifunk-franken.de/v2/?lat=$lat&long=$long"
> -O "$hoodfile"
> +
> + # Alfred will always have only one "entry" per sender
> address. Thus, old data will be overwritten by new one.
> + # If the commented lines are enabled, the behavior will be
> altered: The router will only send data if no up-to-date
> information is already present.
> +
> + #hoodread="$(cat "$hoodfile")"
> + #alfred -r "$alfrednum" > "$alfredfile"
> + #alfrednewest="$(getJsonFromAlfred "$alfredfile")"
> + #rm -f "$alfredfile"
> + #tsinet="$(getJsonTimestamp "$hoodread")"
> + #tsalfred="$(getJsonTimestamp "$alfrednewest")"
> + #if [ "$tsinet" -gt "$tsalfred" ] ; then
> + cat "$hoodfile" | alfred -s "$alfrednum"
> + #fi
> +
> + # Note that data sent this way has a lifetime. The
> following case would be possible:
> + # 1. The first uplink router will send data via alfred
> + # 2. All routers won't send any data, since the data from
> the first is already present and up-to-date
> + # 3. The alfred data send by the first router expires ->
> No alfred data present
> + # 4. A random router will find no data and paste its own,
> restarting the cycle
> + # Note that between 3. and 4. there is a gap where no data
> is present.
> + # -> Advantage: The alfred information will be much
> smaller, leading to smaller files and less CPU for parsing
> (json = about 1 kB per Sender)
> + # -> Disadvantage: There will be frequent gaps with no
> data available
> +
> rm -f "$sectortmp"
> [ -s "$sectorlocal" ] || rm -f "$sectorcopy" # If internet
> present, no custom config should be distributed, except when
> local file is present
> #UPLINK: No uplink download if internet present
> @@ -115,8 +141,12 @@ else
> wget -T15 -t5 "http://[fe80::1%w2sta]:2342/sectorfile" -O
> "$sectortmp" || wget -T15 -t5
> "http://[fe80::1%w5sta]:2342/sectorfile" -O "$sectortmp"
> fi
> else
> - echo "We have a Gateway in Range, we load the
> keyxchangev2data from fe80::1"
> - wget -T15 -t5
> "http://[fe80::1%br-mesh]:2342/keyxchangev2data" -O "$hoodfile"
> + echo "We have a Gateway in Range, we collect files from
> the neighborhood"
> + alfred -r "$alfrednum" > "$alfredfile"
> + alfrednewest="$(getJsonFromAlfred "$alfredfile")"
> + rm -f "$alfredfile"
> + [ -n "$alfrednewest" ] && echo "$alfrednewest" > "$hoodfile"
> +
> #UPLINK: Do nothing
> fi
> fi
>
>
>
>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 833 bytes
Beschreibung: OpenPGP digital signature
URL : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20171102/a4b609fd/attachment.sig>
Mehr Informationen über die Mailingliste franken-dev