fff-network/fff-hoods: Calculate fdff IPs based on uci

If the mac is read from /sys/class/net/${iface}/address, some
devices (WA860RE, Picostation) will not set the fdff addresses.

This can be fixed by using the uci value instead of the br-mesh
device, as uci is available instantly.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>

Tested-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>

---

I don't believe it myself, but it seems to be this tiny change
making the difference.
---
 src/packages/fff/fff-hoods/files/usr/sbin/configurehood      | 4 ++--
 src/packages/fff/fff-network/files/lib/functions/fff/network | 4 ++--
 src/packages/fff/fff-network/files/usr/sbin/configurenetwork | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

Tested on WA860RE.

Also fixes the missing fdff addresses there in 2 of 2 test cases.

> -----Original Message-----
> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf
> Of Adrian Schmutzler
> Sent: Donnerstag, 23. November 2017 21:26
> To: franken-dev@freifunk.net
> Subject: [PATCH] fff-network/fff-hoods: Calculate fdff IPs based on uci
> 
> If the mac is read from /sys/class/net/${iface}/address, some devices
> (WA860RE, Picostation) will not set the fdff addresses.
> 
> This can be fixed by using the uci value instead of the br-mesh device, as
uci
> is available instantly.
> 
> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
> 
> Tested-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
> 
> ---
> 
> I don't believe it myself, but it seems to be this tiny change making the
> difference.
> ---
>  src/packages/fff/fff-hoods/files/usr/sbin/configurehood      | 4 ++--
>  src/packages/fff/fff-network/files/lib/functions/fff/network | 4 ++--
> src/packages/fff/fff-network/files/usr/sbin/configurenetwork | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
> b/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
> index 822e5fc..7d86247 100755
> --- a/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
> +++ b/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
> @@ -251,9 +251,9 @@ if [ -s "$hoodfile" ]; then
>  	# Set $prefix::MAC as IP
>  	if [ -n "$prefix" ] ; then
>  		prefix="$(echo "$prefix" | sed -e 's,\\,,')"
> -		addr="$(ipMacAssemble "$prefix" "br-mesh")"
> +		addr="$(ipMacAssemble "$prefix" "mesh")"
>  		addr="$(ipTidyColon "$addr")"
> -		addr_eui="$(ipEUIAssemble "$prefix" "br-mesh")"
> +		addr_eui="$(ipEUIAssemble "$prefix" "mesh")"
>  		addr_eui="$(ipTidyColon "$addr_eui")"
>  		for ip in $(ip -6 addr show dev br-mesh | grep inet6 | grep
-v -
> e " $addr" -e " $addr_eui" -e " fe80::" -e " fdff::" | cut -f6 -d " "); do
>  			ip -6 addr del "$ip" dev br-mesh
> diff --git a/src/packages/fff/fff-network/files/lib/functions/fff/network
> b/src/packages/fff/fff-network/files/lib/functions/fff/network
> index dc26938..e76351b 100644
> --- a/src/packages/fff/fff-network/files/lib/functions/fff/network
> +++ b/src/packages/fff/fff-network/files/lib/functions/fff/network
> @@ -12,7 +12,7 @@ ipMacSuffix() {
> 
>  	local iface=$1
> 
> -	awk -F: '{ print "0:"$1$2":"$3$4":"$5$6 }'
> "/sys/class/net/${iface}/address"
> +	uci -q get "network.${iface}.macaddr" | awk -F: '{ print
> "0:"$1$2":"$3$4":"$5$6 }'
>  	return 0
>  }
> 
> @@ -26,7 +26,7 @@ ipEUISuffix() {
> 
>  	local iface=$1
> 
> -	awk -F: '{ printf("%02x%s:%sff:fe%s:%s%s\n", xor(("0x"$1),2), $2,
> $3, $4, $5, $6) }' "/sys/class/net/${iface}/address"
> +	uci -q get "network.${iface}.macaddr" | awk -F: '{
> printf("%02x%s:%sff:fe%s:%s%s\n", xor(("0x"$1),2), $2, $3, $4, $5, $6) }'
>  	return 0
>  }
> 
> diff --git a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork
> b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork
> index 30787b2..8ff91b4 100755
> --- a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork
> +++ b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork
> @@ -218,7 +218,7 @@ else
> 
>      prefix="fdff:0::/64"
>      # Set $prefix::MAC as IP
> -    addr="$(ipMacAssemble "$prefix" "br-mesh")"
> +    addr="$(ipMacAssemble "$prefix" "mesh")"
>      ip -6 addr add $addr dev br-mesh
> 
>      uci -q del network.globals
> @@ -233,7 +233,7 @@ else
>      uci -q add_list network.mesh.ip6addr=$addr
> 
>      # Set $prefix::link-local as IP
> -    addr="$(ipEUIAssemble "$prefix" "br-mesh")"
> +    addr="$(ipEUIAssemble "$prefix" "mesh")"
>      ip -6 addr add $addr dev br-mesh
>      uci -q add_list network.mesh.ip6addr=$addr
> 
> --
> 2.7.4
> 
> --
> franken-dev mailing list
> franken-dev@freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net

Irgendwie gefällt mir diese Änderung nicht so richtig. Das Auslesen aus UCI funktioniert nur, wenn die ROUTERMAC gesetzt wurde. Das ist zwar aktuell der Fall, besonders hübsch finde ich das aber nicht, davon abzuhängen. In /sys/class/… sollte genau die gleiche MAC stehen. Tut sie das nicht, sollte das Problem vielleicht erstmal dort gesucht werden, denn dann scheint irgendwas kaputt zu sein.

Was mir schon eher gefallen würde: Die Mac aus ROUTERMAC verwenden, falls gesetzt, andernfalls mit br-mesh aus /sys/class/... versuchen.

Fabian

Hallo Fabian,

zunächst folgendes:

Fakt ist, dass die alte Lösung mit /sys/class/ auf den ONE_PORT Geräten NICHT funktioniert, während die uci-Lösung in 100% der Testfälle funktioniert.

Der Grund dafür könnte sein, dass die ONE_PORT-Geräte langsamer sind und daher einfach einen längeren Sleep brauchen, um die Datei lesen zu können. Vll. macht auch der ETH0MAC-Block, der nur bei den ONE-PORTS ausgeführt wird, irgendetwas böses.

Wenn im uci nichts steht, ist vorher ohnehin etwas schief gegangen. Im Moment ist dies aber aufgrund der Tests die robustere Variante.

Die Idee mit der ROUTERMAC ist grundsätzlich äquivalent, allerdings würden wir so wieder eine Lösung bauen, die von einer von uns erfundenen Variable abhängt. Im Hinblick auf die Zukunft gefällt mir also die uci-Lösung eigtl am besten.

Randnotiz:
Ich habe auch schon bei der alten Firmware Probleme auf bestimmten one-port Geräten beobachtet. Ist evtl. derselbe Grund gewesen:
https://mantis.freifunk-franken.de/view.php?id=49

Grüße

Adrian

> -----Original Message-----
> From: Fabian Bläse [mailto:fabian@blaese.de]
> Sent: Freitag, 1. Dezember 2017 10:43
> To: Adrian Schmutzler <mail@adrianschmutzler.de>; franken-
> dev@freifunk.net
> Subject: Re: [PATCH] fff-network/fff-hoods: Calculate fdff IPs based on uci
> 
> Irgendwie gefällt mir diese Änderung nicht so richtig. Das Auslesen aus UCI
> funktioniert nur, wenn die ROUTERMAC gesetzt wurde. Das ist zwar aktuell
> der Fall, besonders hübsch finde ich das aber nicht, davon abzuhängen. In
> /sys/class/… sollte genau die gleiche MAC stehen. Tut sie das nicht, sollte das
> Problem vielleicht erstmal dort gesucht werden, denn dann scheint
> irgendwas kaputt zu sein.
> 
> Was mir schon eher gefallen würde: Die Mac aus ROUTERMAC verwenden,
> falls gesetzt, andernfalls mit br-mesh aus /sys/class/... versuchen.
> 
> Fabian

Hi

Am Freitag, den 01.12.2017, 10:43 +0100 schrieb Fabian Bläse:
> Irgendwie gefällt mir diese Änderung nicht so richtig. Das Auslesen
> aus UCI funktioniert nur, wenn die ROUTERMAC gesetzt wurde. Das ist
> zwar aktuell der Fall, besonders hübsch finde ich das aber nicht, 
Das ist aktuell zufällig der Fall. Zwingend ist das Setzen 
bisher nicht.

Tim

> davon abzuhängen. In /sys/class/… sollte genau die gleiche MAC
> stehen. Tut sie das nicht, sollte das Problem vielleicht erstmal dort
> gesucht werden, denn dann scheint irgendwas kaputt zu sein.
> 
> Was mir schon eher gefallen würde: Die Mac aus ROUTERMAC verwenden,
> falls gesetzt, andernfalls mit br-mesh aus /sys/class/... versuchen.
> 
> Fabian

Habe nun in meiner aktuellen Firmware den uci Patch wieder herausgenommen und prompt zwei Picostation M2 ohne fdff-Adressen bekommen.

Die Geräte bekommen dann anstelle der korrekten fdff::MAC/64 und fdff::EUI/64 einfach fdff::/64 eingetragen, also funktioniert der Code an sich, nur das Auslesen aus der Datei klappt nicht. Da uci scheinbar sofort (aus dem Speicher?) verfügbar ist, geht es hier immer.

Entsprechend folgende Schlüsse:
1. Die uci-Variante klappt bei mir immer.
2. Direkt vor dem Setzen der MAC-Adressen steht ein network restart. Evtl lockt das die Dateien irgendwie und eine längere Wartezeit als 5 sec. würde reichen.
3. Gegen 2. spricht, dass der Fehler nur bei ONE-Port Geräten auftritt (WA850, WA860, Picostation), dort zu 100 %, bei anderen Geräten zu 0 %. Der Block vor dem Setzen der fdff-Adressen ist aber für beide identisch (Setzen der Router-MAC). Wenn das ein Trägheitsphänomen wäre, müsste es sich anders zwischen den Geräten verteilen.
4. Auf der AC-Mesh, die auch ein One-Port-Gerät ist, konnte ich den Fehler hingegen nicht beobachten.
5. Das Problem tritt erst seit der V2 Firmware auf.

Sicher liegt hier etwas im Argen, wo wir einfach nicht drauf kommen. Ich werde für meine Firmware jetzt erst mal wieder den uci-Patch verwenden, da er das Problem zuverlässig behebt.

Da ich z.Zt. kein entsprechendes Gerät zu Hause habe, kann ich auch nur begrenzt testen. Über Remote bin ich lieber vorsichtig...

Grüße

Adrian

> -----Original Message-----
> From: Tim Niemeyer [mailto:tim@tn-x.org]
> Sent: Samstag, 23. Dezember 2017 14:46
> To: Fabian Bläse <fabian@blaese.de>; franken-dev@freifunk.net; Adrian
> Schmutzler <mail@adrianschmutzler.de>
> Subject: Re: [PATCH] fff-network/fff-hoods: Calculate fdff IPs based on uci
> 
> Hi
> 
> Am Freitag, den 01.12.2017, 10:43 +0100 schrieb Fabian Bläse:
> > Irgendwie gefällt mir diese Änderung nicht so richtig. Das Auslesen
> > aus UCI funktioniert nur, wenn die ROUTERMAC gesetzt wurde. Das ist
> > zwar aktuell der Fall, besonders hübsch finde ich das aber nicht,
> Das ist aktuell zufällig der Fall. Zwingend ist das Setzen bisher nicht.
> 
> Tim
> 
> > davon abzuhängen. In /sys/class/… sollte genau die gleiche MAC stehen.
> > Tut sie das nicht, sollte das Problem vielleicht erstmal dort gesucht
> > werden, denn dann scheint irgendwas kaputt zu sein.
> >
> > Was mir schon eher gefallen würde: Die Mac aus ROUTERMAC verwenden,
> > falls gesetzt, andernfalls mit br-mesh aus /sys/class/... versuchen.
> >
> > Fabian

Ich habe gerade nochmal darüber nachgedacht:

Kann es sein, dass das Problem ähnlich dem mit alfred ist? Dadurch, dass ich in meiner Version die Dummy-Netzwerke (w2mesh/w2ap am Anfang) bereits deaktiviert sind, kommt br-mesh beim first-boot noch nicht hoch (br-mesh is down) und daher kann der File mit der MAC nicht gelesen werden. Das würde auch erklären, warum es "danach", also beim Testen über Konsole, geht?

Grüße

Adrian 

> -----Original Message-----
> From: mail@adrianschmutzler.de [mailto:mail@adrianschmutzler.de]
> Sent: Dienstag, 2. Januar 2018 00:44
> To: 'Tim Niemeyer' <tim@tn-x.org>; 'franken-dev@freifunk.net' <franken-
> dev@freifunk.net>
> Subject: RE: [PATCH] fff-network/fff-hoods: Calculate fdff IPs based on uci
> 
> Habe nun in meiner aktuellen Firmware den uci Patch wieder
> herausgenommen und prompt zwei Picostation M2 ohne fdff-Adressen
> bekommen.
> 
> Die Geräte bekommen dann anstelle der korrekten fdff::MAC/64 und
> fdff::EUI/64 einfach fdff::/64 eingetragen, also funktioniert der Code an sich,
> nur das Auslesen aus der Datei klappt nicht. Da uci scheinbar sofort (aus dem
> Speicher?) verfügbar ist, geht es hier immer.
> 
> Entsprechend folgende Schlüsse:
> 1. Die uci-Variante klappt bei mir immer.
> 2. Direkt vor dem Setzen der MAC-Adressen steht ein network restart. Evtl
> lockt das die Dateien irgendwie und eine längere Wartezeit als 5 sec. würde
> reichen.
> 3. Gegen 2. spricht, dass der Fehler nur bei ONE-Port Geräten auftritt
> (WA850, WA860, Picostation), dort zu 100 %, bei anderen Geräten zu 0 %. Der
> Block vor dem Setzen der fdff-Adressen ist aber für beide identisch (Setzen
> der Router-MAC). Wenn das ein Trägheitsphänomen wäre, müsste es sich
> anders zwischen den Geräten verteilen.
> 4. Auf der AC-Mesh, die auch ein One-Port-Gerät ist, konnte ich den Fehler
> hingegen nicht beobachten.
> 5. Das Problem tritt erst seit der V2 Firmware auf.
> 
> Sicher liegt hier etwas im Argen, wo wir einfach nicht drauf kommen. Ich
> werde für meine Firmware jetzt erst mal wieder den uci-Patch verwenden,
> da er das Problem zuverlässig behebt.
> 
> Da ich z.Zt. kein entsprechendes Gerät zu Hause habe, kann ich auch nur
> begrenzt testen. Über Remote bin ich lieber vorsichtig...
> 
> Grüße
> 
> Adrian
> 
> > -----Original Message-----
> > From: Tim Niemeyer [mailto:tim@tn-x.org]
> > Sent: Samstag, 23. Dezember 2017 14:46
> > To: Fabian Bläse <fabian@blaese.de>; franken-dev@freifunk.net; Adrian
> > Schmutzler <mail@adrianschmutzler.de>
> > Subject: Re: [PATCH] fff-network/fff-hoods: Calculate fdff IPs based
> > on uci
> >
> > Hi
> >
> > Am Freitag, den 01.12.2017, 10:43 +0100 schrieb Fabian Bläse:
> > > Irgendwie gefällt mir diese Änderung nicht so richtig. Das Auslesen
> > > aus UCI funktioniert nur, wenn die ROUTERMAC gesetzt wurde. Das ist
> > > zwar aktuell der Fall, besonders hübsch finde ich das aber nicht,
> > Das ist aktuell zufällig der Fall. Zwingend ist das Setzen bisher nicht.
> >
> > Tim
> >
> > > davon abzuhängen. In /sys/class/… sollte genau die gleiche MAC stehen.
> > > Tut sie das nicht, sollte das Problem vielleicht erstmal dort
> > > gesucht werden, denn dann scheint irgendwas kaputt zu sein.
> > >
> > > Was mir schon eher gefallen würde: Die Mac aus ROUTERMAC
> verwenden,
> > > falls gesetzt, andernfalls mit br-mesh aus /sys/class/... versuchen.
> > >
> > > Fabian