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

[Tobias Klaus]

Hallo,

dann sind wir uns über die kurzfristige(und auch mittelfristige) Lösung ja 
einig!
Der Patch ist daher jetzt im master.

Das anpassen der Commit-Nachricht von WAN->VPN hab ich allerdings vergessen. 
Ich hoffe das ist auch so ok. In der xml Datei steht ja vpn.

Viele Grüße
Tobias

Am Freitag, 2. Juni 2017, 12:48:16 CEST schrieb Christian Dresel:
> hi
> 
> On 02.06.2017 09:03, Tobias Klaus wrote:
> > Hallo Christian,
> > 
> > ich finde deine Überlegungen gut und eine generische Lösung ist hier einer
> > speziellen auch vorzuziehen. Dennoch sehe ich gerade keinen Grund diesen
> > Patch _nicht_ einzuspielen. Er löst ein aktuelles Problem, das für viele
> > Nutzer, die das monitoring für die Überwachung ihrer Knoten nutzen, recht
> > unschön wirkt.
> ja ok ich kann schon mit leben aber man sollte im Hinterkopf behalten
> (evtl. ein neuer Mantis Eintrag?) das man das noch "verschönern" sollte.
> 
> > So bald du eine generische Lösung hast sind die paar Zeilen ja auch
> > schnell
> > geändert. Solange ich keinen Patch sehe, der gre, wireguard oder sonst was
> > in die Firmware bringt würde ich wegen solchen Eventualitäten ungern die
> > "Bug"- Fixes zurück halten.
> > 
> > Da fällt mir gerade auch auf, dass ich mein
> > Reviewed-by: Tobias Klaus <tk+ff at meskal.net>
> > 
> > übersehen habe.
> > 
> > Kleine Anmerkung zum Patch: Eventuell sollte die Commit-Nachricht lieber
> > von VPN sprechen, so heißt ja auch das xml-Feld...?
> 
> das würde dann zumindest meine Frage, wann sprechen wir von WAN Uplink
> klären. Wenn man das auf "VPN aktiv" definiert fallen Hardhöhe und
> StPaul eindeutig nicht darunter, L3 Gateways die per VPN angebunden
> (RedDog, Neunhof, Unterfürberg, FabLab) sind allerdings schon.
> 
> mfg
> 
> Christian
> 
> > Viele Grüße
> > Tobias
> > 
> > Am Donnerstag, 1. Juni 2017, 16:33:55 CEST schrieb Christian Dresel:
> >> 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_r
> >>>      ev
> >>>      ision>"
> >>>      SYSTEM_DATA=$SYSTEM_DATA"<openwrt_core_revision>$OPENWRT_CORE_REVIS
> >>>      I
> >>>      ON</openwrt_core_revision>"
> >>>      SYSTEM_DATA=$SYSTEM_DATA"<openwrt_feeds_packages_revision>$OPENWRT_
> >>>      F
> >>>      EEDS_PACKAGES_REVISION</openwrt_feeds_packages_revision>">
> >>> 
> >>> +    SYSTEM_DATA=$SYSTEM_DATA"$vpn_active"
> >>> 
> >>>      err "$(date): Collecting information from network interfaces"