[PATCH 8/8] fff-nodewatcher: write WAN status to XML (fastd and L2TP)

[mail at adrianschmutzler.de]

Hallo,

theoretisch bestünde doch auch die banal einfache Möglichkeit, zu
überprüfen, ob der WAN-Port eingesteckt ist. Habe allerdings keine Ahnung,
ob und wie sich das praktisch realisieren lässt. Dann wäre allerdings das
Bestehen des VPN ja quasi noch eine Zusatzinformation, oder? Ich könnte ja
auch eine WAN-IP haben und nicht per VPN durchkommen ...

Bzgl. "[5/6] WebUI: show VPN status for both fastd and l2tp individually
(adds L2TP status)" finde ich, dass dieses Update in jedem Fall eine
Verbesserung darstellt, da jetzt ja in jedem Fall mehr Informationen geboten
werden:
1. Ich sehe jetzt überhaupt, ob l2tp aktiv ist (vorher nur fastd)
2. Ich weiß im Vergleich zu früher, welche Verbindungen tatsächlich aktiv
sind und welche evtl. vergessen wurden. Gerade für Christians Szenario mit
anderen/neuen Protokollen weiß ich so zumindest, dass z.B. GRE hier nicht
berücksichtigt ist. Steht da nur "VPN aktiv", weiß ich das nicht (wie es ja
jetzt vielen Normal-Nutzern geht, die es nicht genauer wissen).

Ich würde also zumindest diesen Part [5/6] erstmal befürworten, da sich
eigtl. erstmal nur Vorteile ergeben, und wenn tatsächlich eine neuere,
allgemeinere Lösung da ist (was ich ja gut finde), dann kann man das ja
wieder ändern.

Beste Grüße

Adrian

-----Original Message-----
From: Christian Dresel [mailto:fff at chrisi01.de] 
Sent: Donnerstag, 1. Juni 2017 16:34
To: Adrian Schmutzler <freifunk at adrianschmutzler.de>;
franken-dev at freifunk.net
Subject: Re: [PATCH 8/8] fff-nodewatcher: write WAN status to XML (fastd and
L2TP)

Hallo

On 30.05.2017 22:11, Adrian Schmutzler wrote:
> Fixes #30
> 
> Signed-off-by: Adrian Schmutzler <freifunk at adrianschmutzler.de>
> ---
>  src/packages/fff/fff-nodewatcher/files/usr/sbin/nodewatcher | 8 
> ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git 
> a/src/packages/fff/fff-nodewatcher/files/usr/sbin/nodewatcher 
> b/src/packages/fff/fff-nodewatcher/files/usr/sbin/nodewatcher
> index d5e3ce5..e7acd01 100755
> --- a/src/packages/fff/fff-nodewatcher/files/usr/sbin/nodewatcher
> +++ b/src/packages/fff/fff-nodewatcher/files/usr/sbin/nodewatcher
> @@ -102,6 +102,13 @@ crawl() {
>      if [ -f "$SCRIPT_STATUS_FILE" ]; then
>          status_text="<status_text>$(cat
"$SCRIPT_STATUS_FILE")</status_text>"
>      fi
> +    
> +    #Checks whether either fastd or L2TP is connected
> +    if [ pidof fastd >/dev/null ] || [ grep -q '1'
/sys/class/net/l2tp*/carrier ] ; then
> +        vpn_active="<vpn_active>1</vpn_active>"
> +    else
> +        vpn_active="<vpn_active>0</vpn_active>"
> +    fi

mir gefällt die Lösung nicht sonderlich gut. Manche Knoten laufen mit der
Firmware auch als Gateway und nutzen z.b. GRE, denkbar ist später auch mal
wireguard oder was ganz was anderes, das jedes mal anzupassen ist recht
mühselig. Das gleiche was ich hier schreibe gilt auch ein wenig für:
[5/6] WebUI: show VPN status for both fastd and l2tp individually (adds L2TP
status)

Ich fände es besser die Erkennung "irgendwie anders" festzulegen. Wobei mir
da bisschen die Ideen fehlen. Was ist z.b. mit Gateways wie die Hardhöhe
oder StPaul? Diese haben eigentlich keinen WAN Uplink. Dennoch können sie
ins Internet pingen nämlich durchs Freifunknetz (was normale Meshknoten
nicht können). Ist das nun "WAN Uplink" oder nicht?

Ich denke der erste Schritt ist erstmal zu definieren wann genau ein WAN
Uplink vorhanden ist und wann nicht.
Dann kann man vermutlich relativ leicht festlegen wie man die Erkennung am
besten gestaltet.

mfg

Christian

>  
>      # example for /etc/openwrt_release:
>      #DISTRIB_ID="OpenWrt"
> @@ -145,6 +152,7 @@ crawl() {
>
SYSTEM_DATA=$SYSTEM_DATA"<firmware_revision>$BUILD_DATE</firmware_revision>"
>
SYSTEM_DATA=$SYSTEM_DATA"<openwrt_core_revision>$OPENWRT_CORE_REVISION</open
wrt_core_revision>"
>
SYSTEM_DATA=$SYSTEM_DATA"<openwrt_feeds_packages_revision>$OPENWRT_FEEDS_PAC
KAGES_REVISION</openwrt_feeds_packages_revision>"
> +    SYSTEM_DATA=$SYSTEM_DATA"$vpn_active"
>  
>      err "$(date): Collecting information from network interfaces"
>  
>