[PATCH] fff-hoods: Use alfred for hood file redistribution
Adrian Schmutzler
mail at adrianschmutzler.de
Do Nov 2 10:20:04 CET 2017
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)?
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 HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20171102/7d768ca8/attachment.html>
Mehr Informationen über die Mailingliste franken-dev