Moin,
zusammen mit Stefan habe ich eine Lösung entwickelt, mit der wir im Meshviewer schnell sehen können welche Router in welcher Hood ist.
Dieses wird durch den siteCode in der site.conf gesteuert.
Die site.conf ist auch auf dem Router abgesichert und wird von respondd ausgelesen. respondd sammelt die Daten zusammen und sendete sie an Alfred bzw im neuen Setup an den Nachfolger.
Demnach müsste die site.conf bei setzten eine Hood durch den Hoodselector angepasst werden. Ich habe dieses auch schon erfolgreich testen können.
https://git.nordwest.freifunk.net/ffnw-firmware/packages/blob/feature/SiteCo...
Was haltet ihr davon? Meinungen?
Gruß
Johannes
Hi,
zusammen mit Stefan habe ich eine Lösung entwickelt, mit der wir im Meshviewer schnell sehen können welche Router in welcher Hood ist.
Dieses wird durch den siteCode in der site.conf gesteuert.
Die site.conf ist auch auf dem Router abgesichert und wird von respondd ausgelesen. respondd sammelt die Daten zusammen und sendete sie an Alfred bzw im neuen Setup an den Nachfolger.
Demnach müsste die site.conf bei setzten eine Hood durch den Hoodselector angepasst werden. Ich habe dieses auch schon erfolgreich testen können.
https://git.nordwest.freifunk.net/ffnw-firmware/packages/blob/feature/SiteCo...
Was haltet ihr davon? Meinungen?
Ich finde das ist eine unschöne Lösung. Weil der hoodselector in die site.conf hinein schreibt die durch viele andere Programme gelesen wird.
Die site.conf sollte am besten im Betrieb verändert werden sondern als reine read only behandelt werden. Es können unglaublich unschöne Anomalien auftreten. z.B. das Dienste abstürzten die rein garnichts mit dem hoodselector zutun haben.
Eine Ermittelung auf Server Seite würde ich eher empfehlen. Den Routern ist eine Eindeutige BSSID zu gewiesen sowie ein eindeutiger Batman-adv Gateway über diese beiden Parameter + das hoodfile sollten sich relativ leicht auf Server Seite eine Zuordnung zu einzelnen hoods realisieren lassen.
vg Tarek
Das Problem ist ja, dass der Site Parameter wohl direkt aus der siteconf geholt wird. Wenn wir die Site dynamisch anpassen, muss folglich die siteconf umgeschrieben werden. Am 10.04.2016 18:52 schrieb "Jan-Tarek Butt via Dev" dev@lists.ffnw.de:
Hi,
zusammen mit Stefan habe ich eine Lösung entwickelt, mit der wir im
Meshviewer schnell sehen können welche Router in welcher Hood ist.
Dieses wird durch den siteCode in der site.conf gesteuert.
Die site.conf ist auch auf dem Router abgesichert und wird von respondd
ausgelesen.
respondd sammelt die Daten zusammen und sendete sie an Alfred bzw im
neuen Setup an den Nachfolger.
Demnach müsste die site.conf bei setzten eine Hood durch den
Hoodselector angepasst werden. Ich habe dieses auch schon erfolgreich testen können.
https://git.nordwest.freifunk.net/ffnw-firmware/packages/blob/feature/SiteCo...
Was haltet ihr davon? Meinungen?
Ich finde das ist eine unschöne Lösung. Weil der hoodselector in die site.conf hinein schreibt die durch viele andere Programme gelesen wird.
Die site.conf sollte am besten im Betrieb verändert werden sondern als reine read only behandelt werden. Es können unglaublich unschöne Anomalien auftreten. z.B. das Dienste abstürzten die rein garnichts mit dem hoodselector zutun haben.
Eine Ermittelung auf Server Seite würde ich eher empfehlen. Den Routern ist eine Eindeutige BSSID zu gewiesen sowie ein eindeutiger Batman-adv Gateway über diese beiden Parameter + das hoodfile sollten sich relativ leicht auf Server Seite eine Zuordnung zu einzelnen hoods realisieren lassen.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hey,
wie willst du das Serverseitig denn lösen? Batman kennt bei den Hoods so oder so nur ein Gateway.
Am 10. April 2016 17:53:59 MESZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
zusammen mit Stefan habe ich eine Lösung entwickelt, mit der wir im
Meshviewer schnell sehen können welche Router in welcher Hood ist.
Dieses wird durch den siteCode in der site.conf gesteuert.
Die site.conf ist auch auf dem Router abgesichert und wird von
respondd ausgelesen.
respondd sammelt die Daten zusammen und sendete sie an Alfred bzw im
neuen Setup an den Nachfolger.
Demnach müsste die site.conf bei setzten eine Hood durch den
Hoodselector angepasst werden. Ich habe dieses auch schon erfolgreich testen können.
https://git.nordwest.freifunk.net/ffnw-firmware/packages/blob/feature/SiteCo...
Was haltet ihr davon? Meinungen?
Ich finde das ist eine unschöne Lösung. Weil der hoodselector in die site.conf hinein schreibt die durch viele andere Programme gelesen wird.
Die site.conf sollte am besten im Betrieb verändert werden sondern als reine read only behandelt werden. Es können unglaublich unschöne Anomalien auftreten. z.B. das Dienste abstürzten die rein garnichts mit dem hoodselector zutun haben.
Eine Ermittelung auf Server Seite würde ich eher empfehlen. Den Routern ist eine Eindeutige BSSID zu gewiesen sowie ein eindeutiger Batman-adv Gateway über diese beiden Parameter + das hoodfile sollten sich relativ leicht auf Server Seite eine Zuordnung zu einzelnen hoods realisieren lassen.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
Das Problem ist ja, dass der Site Parameter wohl direkt aus der siteconf geholt wird. Wenn wir die Site dynamisch anpassen, muss folglich die siteconf umgeschrieben werden.
Deswegen würde ich vorschlagen es Server seitig zu lösen. Oder das respondd package in unser repo rein klonen und dort direkt den hood namen aus den hoodfile auslesen.
vg Tarek
Moin
Deswegen würde ich vorschlagen es Server seitig zu lösen.
Wie willst du das denn machen die Daten werden vom Router erzeugt?!
Oder das respondd package in unser repo rein klonen und dort direkt den hood namen aus den hoodfile auslesen.
Respondd klonen und modifizieren finde ich unschön da wir dann parallel das Paket komplett mitpflegen müssen, wenn sich da mal was tut
Gruß Johannes
Gleiches unschönes Szenario haben wir, wenn wir es serverseitig im Meshviewer lösen. Am 10.04.2016 19:08 schrieb "Johannes Rudolph | Freifunk Nordwest via Dev" < dev@lists.ffnw.de>:
Moin
Deswegen würde ich vorschlagen es Server seitig zu lösen.
Wie willst du das denn machen die Daten werden vom Router erzeugt?!
Oder das respondd package in unser repo rein klonen und dort direkt den hood namen aus den hoodfile auslesen.
Respondd klonen und modifizieren finde ich unschön da wir dann parallel das Paket komplett mitpflegen müssen, wenn sich da mal was tut
Gruß Johannes _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Sorry, dass war missverständlich.
Ich möchte damit nicht sagen, dass wir respondd anpassen sollten, sondern nur das alle drei Möglichkeiten (siteconf / respondd / meshviewer anpassen) unschön sind.
Evtl. ist siteconf umschreiben das geringste Übel? Am 10.04.2016 19:25 schrieb "Simon Kurka" dev@simon.kurka.cc:
Gleiches unschönes Szenario haben wir, wenn wir es serverseitig im Meshviewer lösen. Am 10.04.2016 19:08 schrieb "Johannes Rudolph | Freifunk Nordwest via Dev" dev@lists.ffnw.de:
Moin
Deswegen würde ich vorschlagen es Server seitig zu lösen.
Wie willst du das denn machen die Daten werden vom Router erzeugt?!
Oder das respondd package in unser repo rein klonen und dort direkt den hood namen aus den hoodfile auslesen.
Respondd klonen und modifizieren finde ich unschön da wir dann parallel das Paket komplett mitpflegen müssen, wenn sich da mal was tut
Gruß Johannes _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Was man noch machen könnte, wäre über die Gateways das zu filtern. Die Gateways könnten so heißen wie die Hood. Im Endeffekt wäre es dann ohne den Sitecode möglich.
Blöd das ich da vorher nicht drauf gekommen bin
Am 10. April 2016 19:25:20 MESZ, schrieb Simon Kurka via Dev dev@lists.ffnw.de:
Gleiches unschönes Szenario haben wir, wenn wir es serverseitig im Meshviewer lösen. Am 10.04.2016 19:08 schrieb "Johannes Rudolph | Freifunk Nordwest via Dev" < dev@lists.ffnw.de>:
Moin
Deswegen würde ich vorschlagen es Server seitig zu lösen.
Wie willst du das denn machen die Daten werden vom Router erzeugt?!
Oder das respondd package in unser repo rein klonen und dort direkt den hood namen aus den hoodfile auslesen.
Respondd klonen und modifizieren finde ich unschön da wir dann
parallel
das Paket komplett mitpflegen müssen, wenn sich da mal was tut
Gruß Johannes _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
Deswegen würde ich vorschlagen es Server seitig zu lösen.
Wie willst du das denn machen die Daten werden vom Router erzeugt?!
Korrekt und serverseitig zusammen geführt durch alfred oder gluon collect. Dort kann anhand der BSSID die hoodzugehörigkeit ermittelt werden.
Es könnte auch wie auf dem Router ein Zugehörigkeit via position ermittelt werden.
Oder eben durch die batman GWs.
Oder das respondd package in unser repo rein klonen und dort direkt den hood namen aus den hoodfile auslesen.
Respondd klonen und modifizieren finde ich unschön da wir dann parallel das Paket komplett mitpflegen müssen, wenn sich da mal was tut
Das klone wäre sogar der schönste weg. Da man dadurch einen definierte Änderung hat. Siehe die Packages:
ffnw-config-mode-contact-info ffnw-config-mode-geo-location ffnw-node-info
vg Tarek
Was man noch machen könnte, wäre über die Gateways das zu filtern. Die Gateways könnten so heißen wie die Hood. Im Endeffekt wäre es dann ohne den Sitecode möglich.
Genau das meinte ich. Im Grunde sind die Gateways ja schon durch die hoods definiert. :)
Es gäbe auch ein python script welchen leicht angepasst werden müsste. https://github.com/dgoersch/ff-communityfilter
vg Tarek
On 04/10/16 19:25, Simon Kurka wrote:
Gleiches unschönes Szenario haben wir, wenn wir es serverseitig im Meshviewer lösen.
Das es unschön ist stimme ich dir zu aber es ist eine wesentlich bessere lösung als Router seitig. Server seitig kann schlimstenfalls die mat ausfallen die man ganz leicht via ssh auf den server erreichen und fixen kann. Routerseitig kann eine veränderung der site.conf daemon abstürtze auf mehreren tausend routern zurfolge haben. oder sogar schlimmeres.
vg Tarek
Hey,
nachdem ich die Sache auch noch mal durchdacht habe, können wir es tatsächlich über den Meshviewer machen. Hierbei ist keinerlei Anpassung des Sourcecodes notwendig.
Das Ganze kann in der config File umgestellt werden
Am 10. April 2016 19:37:43 MESZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
On 04/10/16 19:25, Simon Kurka wrote:
Gleiches unschönes Szenario haben wir, wenn wir es serverseitig im Meshviewer lösen.
Das es unschön ist stimme ich dir zu aber es ist eine wesentlich bessere lösung als Router seitig. Server seitig kann schlimstenfalls die mat ausfallen die man ganz leicht via ssh auf den server erreichen und fixen kann. Routerseitig kann eine veränderung der site.conf daemon abstürtze auf mehreren tausend routern zurfolge haben. oder sogar schlimmeres.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-
Jan-Tarek Butt -
Johannes Rudolph -
Johannes Rudolph | Freifunk Nordwest
-
Simon Kurka -
Stefan