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

Christian Dresel fff at chrisi01.de
Fr Jun 2 12:48:16 CEST 2017


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

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20170602/b616dcfa/attachment.sig>


Mehr Informationen über die Mailingliste franken-dev