Message ID | 1496175103-1031-1-git-send-email-freifunk@adrianschmutzler.de |
---|---|
State | Accepted |
Headers | show |
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 # 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</openwrt_core_revision>" SYSTEM_DATA=$SYSTEM_DATA"<openwrt_feeds_packages_revision>$OPENWRT_FEEDS_PACKAGES_REVISION</openwrt_feeds_packages_revision>" + SYSTEM_DATA=$SYSTEM_DATA"$vpn_active" err "$(date): Collecting information from network interfaces"
Hallo On 30.05.2017 22:11, Adrian Schmutzler wrote: > Fixes #30 > > Signed-off-by: Adrian Schmutzler <freifunk@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</openwrt_core_revision>" > SYSTEM_DATA=$SYSTEM_DATA"<openwrt_feeds_packages_revision>$OPENWRT_FEEDS_PACKAGES_REVISION</openwrt_feeds_packages_revision>" > + SYSTEM_DATA=$SYSTEM_DATA"$vpn_active" > > err "$(date): Collecting information from network interfaces" > >
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@chrisi01.de] Sent: Donnerstag, 1. Juni 2017 16:34 To: Adrian Schmutzler <freifunk@adrianschmutzler.de>; franken-dev@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@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" > >
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. 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@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...? 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@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_rev > > ision>" > > SYSTEM_DATA=$SYSTEM_DATA"<openwrt_core_revision>$OPENWRT_CORE_REVISI > > 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"
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@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@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_rev >>> ision>" >>> SYSTEM_DATA=$SYSTEM_DATA"<openwrt_core_revision>$OPENWRT_CORE_REVISI >>> 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" > >
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@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@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"
Fixes #30 Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> --- src/packages/fff/fff-nodewatcher/files/usr/sbin/nodewatcher | 8 ++++++++ 1 file changed, 8 insertions(+)