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

Tobias Klaus tk+ff at meskal.net
Fr Jun 2 09:03:16 CEST 2017


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 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...?

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_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"




Mehr Informationen über die Mailingliste franken-dev