Moin,
ich habe gerstern noche eine Änderung im Hoodslector vorgenommen, damit wir auch mehre Peers pro Server haben können. War ein Problem mit dem String, habe ich behoben.
https://git.nordwest.freifunk.net/ffnw-firmware/packages/commit/d899d364cf3c...
Desweiteren habe ich festgestellt, dass nach einenm Hood wechsel irgednwas nicht ganz rund läuft. Das was ich bisher testen konnte hat ergeben: Router neustarten dann läuft nach Hoodweschsel alles soweit. Ich denke das kann an irgendwelchen IP Settings liegen aber ich habe keine ahnung, habe mir das nicht in die Tiefe angeschaut.
Gruß
Johannes
Hi,
ich habe gerstern noche eine Änderung im Hoodslector vorgenommen, damit wir auch mehre Peers pro Server haben können. War ein Problem mit dem String, habe ich behoben.
Wofür ist das sinnvoll? ein peer zwischen Router und Server ist doch vollkommen ausreichend. Es bringt ja nix wenn der Router zum selben server zweimal die identischen Verbindung aufbaut ?
https://git.nordwest.freifunk.net/ffnw-firmware/packages/commit/d899d364cf3c...
Die Einrückungen sind dem commit kaputt gegangen. Hast du die Änderung getestet. Ich glaube das wird so nicht Funktionieren. Da in der übergeordneten Sektion pro peer auf ein Port geprüft wird wo aber nie einer Stehen wird.
Desweiteren habe ich festgestellt, dass nach einenm Hood wechsel irgednwas nicht ganz rund läuft. Das was ich bisher testen konnte hat ergeben: Router neustarten dann läuft nach Hoodweschsel alles soweit. Ich denke das kann an irgendwelchen IP Settings liegen aber ich habe keine ahnung, habe mir das nicht in die Tiefe angeschaut.
Ich schaue mir das mal genauer an.
vg Tarek
Moin
Am 23.04.2016 um 18:20 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
ich habe gerstern noche eine Änderung im Hoodslector vorgenommen, damit wir auch mehre Peers pro Server haben können. War ein Problem mit dem String, habe ich behoben.
Wofür ist das sinnvoll? ein peer zwischen Router und Server ist doch vollkommen ausreichend. Es bringt ja nix wenn der Router zum selben server zweimal die identischen Verbindung aufbaut ?
Im neuen Setup laufen auf den Servern mehrere fastd Instanzen. Daher ist das notwendig.
Läuft in der testfirmware sehr gut gerade auf über 10 Routern
Gruß Johannes
https://git.nordwest.freifunk.net/ffnw-firmware/packages/commit/d899d364cf3c...
Die Einrückungen sind dem commit kaputt gegangen. Hast du die Änderung getestet. Ich glaube das wird so nicht Funktionieren. Da in der übergeordneten Sektion pro peer auf ein Port geprüft wird wo aber nie einer Stehen wird.
Desweiteren habe ich festgestellt, dass nach einenm Hood wechsel irgednwas nicht ganz rund läuft. Das was ich bisher testen konnte hat ergeben: Router neustarten dann läuft nach Hoodweschsel alles soweit. Ich denke das kann an irgendwelchen IP Settings liegen aber ich habe keine ahnung, habe mir das nicht in die Tiefe angeschaut.
Ich schaue mir das mal genauer an.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
Am 23.04.2016 um 18:20 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
ich habe gerstern noche eine Änderung im Hoodslector vorgenommen, damit wir auch mehre Peers pro Server haben können. War ein Problem mit dem String, habe ich behoben.
Wofür ist das sinnvoll? ein peer zwischen Router und Server ist doch vollkommen ausreichend. Es bringt ja nix wenn der Router zum selben server zweimal die identischen Verbindung aufbaut ?
Im neuen Setup laufen auf den Servern mehrere fastd Instanzen. Daher ist das notwendig.
Läuft in der testfirmware sehr gut gerade auf über 10 Routern
Was ist da wo notwändig? Kann das mal bitte hier auf der Liste komuniziert werden ?
vg Tarek
On 23.04.2016 18:55, Jan-Tarek Butt via Dev wrote:
Was ist da wo notwändig?
Da bin ich mir gerade nicht sicher.
Es gibt ja zwei Möglichkeiten: 1. Es werden mehrere Verbindungen zur gleichen Hood auf diversten fastd-Instanzen aufgebaut. 2. Es werden mehrere fastd-Instanzen der gleichen Hood zur Verfügung gestellt, aber nur zu einer eine Verbindung aufgebaut.
Johannes, was trifft zu?
Zwei ist wichtig. Eins ist sinnlos.
Hi,
Variante 2. Diese minimiert drastisch den CPU Load.
Am 23. April 2016 19:17:29 MESZ, schrieb Simon Kurka via Dev dev@lists.ffnw.de:
On 23.04.2016 18:55, Jan-Tarek Butt via Dev wrote:
Was ist da wo notwändig?
Da bin ich mir gerade nicht sicher.
Es gibt ja zwei Möglichkeiten:
- Es werden mehrere Verbindungen zur gleichen Hood auf diversten
fastd-Instanzen aufgebaut. 2. Es werden mehrere fastd-Instanzen der gleichen Hood zur Verfügung gestellt, aber nur zu einer eine Verbindung aufgebaut.
Johannes, was trifft zu?
Zwei ist wichtig. Eins ist sinnlos.
-- Viele Grüße, Simon
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hey,
wir hatten beim vorletzten Treffen und auch schon früher über die ML darüber gesprochen, dass es mehrere fastD Instanzen gibt, damit der CPU Load nicht nur auf einem Kern ist. Damals hattest du gesagt, dass dies doch sinnvoll sei.
Am 23. April 2016 18:55:15 MESZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
Am 23.04.2016 um 18:20 schrieb Jan-Tarek Butt via Dev
Hi,
ich habe gerstern noche eine Änderung im Hoodslector vorgenommen,
damit
wir auch mehre Peers pro Server haben können. War ein Problem mit
dem
String, habe ich behoben.
Wofür ist das sinnvoll? ein peer zwischen Router und Server ist doch vollkommen ausreichend. Es bringt ja nix wenn der Router zum selben server zweimal die identischen Verbindung aufbaut ?
Im neuen Setup laufen auf den Servern mehrere fastd Instanzen. Daher
ist das notwendig.
Läuft in der testfirmware sehr gut gerade auf über 10 Routern
Was ist da wo notwändig? Kann das mal bitte hier auf der Liste komuniziert werden ?
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
ich habe gerstern noche eine Änderung im Hoodslector vorgenommen, damit wir auch mehre Peers pro Server haben können. War ein Problem mit dem String, habe ich behoben.
Wofür ist das sinnvoll? ein peer zwischen Router und Server ist doch vollkommen ausreichend. Es bringt ja nix wenn der Router zum selben server zweimal die identischen Verbindung aufbaut ?
Im neuen Setup laufen auf den Servern mehrere fastd Instanzen. Daher ist das notwendig.
Läuft in der testfirmware sehr gut gerade auf über 10 Routern
Gruß Johannes
https://git.nordwest.freifunk.net/ffnw-firmware/packages/commit/d899d364cf3c...
Ich hab die Änderung in meinen branch wieder rückgängig gemacht da diese im Konflikt mit gluon steht. Der namens präfix ist durch die siteconf und einigen gluon upstream packages vorgegeben.
P.S. da sind noch ein paar offene Branches bin mir unsicher ob die noch aktiv sind bugfix/location, feature/SiteCodes und feature/Sidecodes ?
Hi Tarek,
die Sitecodes können wieder raus, dies lösen wir über den Meshviewer anders :)
Am 24. April 2016 10:24:57 MESZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
ich habe gerstern noche eine Änderung im Hoodslector vorgenommen,
damit
wir auch mehre Peers pro Server haben können. War ein Problem mit
dem
String, habe ich behoben.
Wofür ist das sinnvoll? ein peer zwischen Router und Server ist doch vollkommen ausreichend. Es bringt ja nix wenn der Router zum selben server zweimal die identischen Verbindung aufbaut ?
Im neuen Setup laufen auf den Servern mehrere fastd Instanzen. Daher
ist das notwendig.
Läuft in der testfirmware sehr gut gerade auf über 10 Routern
Gruß Johannes
https://git.nordwest.freifunk.net/ffnw-firmware/packages/commit/d899d364cf3c...
Ich hab die Änderung in meinen branch wieder rückgängig gemacht da diese im Konflikt mit gluon steht. Der namens präfix ist durch die siteconf und einigen gluon upstream packages vorgegeben.
P.S. da sind noch ein paar offene Branches bin mir unsicher ob die noch aktiv sind bugfix/location, feature/SiteCodes und feature/Sidecodes ?
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am Sonntag, 24. April 2016, 10:24:57 CEST schrieb Jan-Tarek Butt via Dev:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/commit/d899d364 cf3c132352d500900a709a01908f98a2
Ich hab die Änderung in meinen branch wieder rückgängig gemacht da diese im Konflikt mit gluon steht. Der namens präfix ist durch die siteconf und einigen gluon upstream packages vorgegeben.
Hi,
das Problem lässt sich alternativ lösen, indem jede VPN-Instanz einen eigenen DNS bekommt. Dann braucht man den Port nicht mit an den Namen hängen.
Dass ein Eintrag nach dem Schema "mesh_vpn_backbone_peer_<name>_<port>" inkompatibel zu anderen Paketen sein soll wundert mich allerdings. Dieses Schema sollte ja grundsätzlich erlaubt sein oder?
Viele Grüße Clemens
On 04/24/16 11:31, Clemens John via Dev wrote:
Am Sonntag, 24. April 2016, 10:24:57 CEST schrieb Jan-Tarek Butt via Dev:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/commit/d899d364 cf3c132352d500900a709a01908f98a2
Ich hab die Änderung in meinen branch wieder rückgängig gemacht da diese im Konflikt mit gluon steht. Der namens präfix ist durch die siteconf und einigen gluon upstream packages vorgegeben.
Hi,
das Problem lässt sich alternativ lösen, indem jede VPN-Instanz einen eigenen DNS bekommt. Dann braucht man den Port nicht mit an den Namen hängen.
Dass ein Eintrag nach dem Schema "mesh_vpn_backbone_peer_<name>_<port>" inkompatibel zu anderen Paketen sein soll wundert mich allerdings. Dieses Schema sollte ja grundsätzlich erlaubt sein oder?
Dass kann problematisch werden mit der peer benennung aus der siteconf
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/blob/master/site.co...
evtl. sollte man dem hoodfile eine weitere kategorie hunzufügen? Ähnlich dem schema aus o.g. link?
vg Tarek
Hi,
meinst du damit eine neue Gruppe für die fastd Peers ala "hood"?
Am 24. April 2016 12:44:19 MESZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
On 04/24/16 11:31, Clemens John via Dev wrote:
Am Sonntag, 24. April 2016, 10:24:57 CEST schrieb Jan-Tarek Butt via
Dev:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/commit/d899d364
cf3c132352d500900a709a01908f98a2
Ich hab die Änderung in meinen branch wieder rückgängig gemacht da
diese
im Konflikt mit gluon steht. Der namens präfix ist durch die
siteconf
und einigen gluon upstream packages vorgegeben.
Hi,
das Problem lässt sich alternativ lösen, indem jede VPN-Instanz einen
eigenen
DNS bekommt. Dann braucht man den Port nicht mit an den Namen hängen.
Dass ein Eintrag nach dem Schema
"mesh_vpn_backbone_peer_<name>_<port>"
inkompatibel zu anderen Paketen sein soll wundert mich allerdings.
Dieses
Schema sollte ja grundsätzlich erlaubt sein oder?
Dass kann problematisch werden mit der peer benennung aus der siteconf
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/blob/master/site.co...
evtl. sollte man dem hoodfile eine weitere kategorie hunzufügen? Ähnlich dem schema aus o.g. link?
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Das wäre doch eine gute Idee, was spricht dagegen das so einzubauen?
Am 24. April 2016 12:51:34 MESZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
On 04/24/16 12:49, Stefan wrote:
Hi,
meinst du damit eine neue Gruppe für die fastd Peers ala "hood"?
Ja
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
ich verstehe die ganze Diskussion nicht ^^
das ganze ist doc nur ein name, welcher eindeutig sein muss
und auf dem router sieht es nachher so aus:
root@whv-rheinstrasse140-6:~# cat /etc/config/fastd
config fastd 'sample_config' option enabled '0' option syslog_level 'info' list method 'salsa2012+umac' option mode 'tap' option interface 'tap0' option mtu '1426' option forward '0' option secure_handshakes '1'
config peer 'sample_peer' option enabled '0' option net 'sample_config' option key '0000000000000000000000000000000000000000000000000000000000000000'
config peer_group 'sample_group' option enabled '0' option net 'sample_config'
config fastd 'mesh_vpn' option enabled '1' option mtu '1312' option group 'gluon-fastd' option status_socket '/var/run/fastd.mesh_vpn.socket' option packet_mark '1' option syslog_level 'verbose' option mode 'tap' option secure_handshakes '1' option interface 'mesh-vpn' option secret '80d304778268215e35363ef94f4659c3b3af5c98ec017134f875c957d4c44f53' list method 'salsa2012+umac'
config peer_group 'mesh_vpn_backbone' option enabled '1' option peer_limit '1' option net 'mesh_vpn'
config peer 'mesh_vpn_backbone_peer_srv08_10001' option enabled '1' option key '613ffbc8a5a2b1a8602866c0bd44afddecee79c49cde52ee4dd5df73c88d0437' option net 'mesh_vpn' list remote '"srv08.ffnw.de" port 10001' option group 'mesh_vpn_backbone'
config peer 'mesh_vpn_backbone_peer_srv08_10002' option enabled '1' option key '14f33c20c3487904e6d1420e9105cfb62b66bc3216d5cdb8a055461b6ed0415d' option net 'mesh_vpn' list remote '"srv08.ffnw.de" port 10002' option group ‚mesh_vpn_backbone'
Am 24.04.2016 um 12:53 schrieb Stefan via Dev dev@lists.ffnw.de:
Das wäre doch eine gute Idee, was spricht dagegen das so einzubauen?
Am 24. April 2016 12:51:34 MESZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
On 04/24/16 12:49, Stefan wrote: Hi,
meinst du damit eine neue Gruppe für die fastd Peers ala "hood"?
Ja
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-- vg Stefan _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 04/24/16 13:04, Johannes Rudolph via Dev wrote:
ich verstehe die ganze Diskussion nicht ^^
das ganze ist doc nur ein name, welcher eindeutig sein muss
Das kann sich hier mit beißen also bei jedem sysupgrade.
https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-mesh-vpn-f...
und auf dem router sieht es nachher so aus:
root@whv-rheinstrasse140-6:~# cat /etc/config/fastd
config fastd 'sample_config' option enabled '0' option syslog_level 'info' list method 'salsa2012+umac' option mode 'tap' option interface 'tap0' option mtu '1426' option forward '0' option secure_handshakes '1'
config peer 'sample_peer' option enabled '0' option net 'sample_config' option key '0000000000000000000000000000000000000000000000000000000000000000'
config peer_group 'sample_group' option enabled '0' option net 'sample_config'
config fastd 'mesh_vpn' option enabled '1' option mtu '1312' option group 'gluon-fastd' option status_socket '/var/run/fastd.mesh_vpn.socket' option packet_mark '1' option syslog_level 'verbose' option mode 'tap' option secure_handshakes '1' option interface 'mesh-vpn' option secret '80d304778268215e35363ef94f4659c3b3af5c98ec017134f875c957d4c44f53' list method 'salsa2012+umac'
config peer_group 'mesh_vpn_backbone' option enabled '1' option peer_limit '1' option net 'mesh_vpn'
config peer 'mesh_vpn_backbone_peer_srv08_10001' option enabled '1' option key '613ffbc8a5a2b1a8602866c0bd44afddecee79c49cde52ee4dd5df73c88d0437' option net 'mesh_vpn' list remote '"srv08.ffnw.de" port 10001' option group 'mesh_vpn_backbone'
config peer 'mesh_vpn_backbone_peer_srv08_10002' option enabled '1' option key '14f33c20c3487904e6d1420e9105cfb62b66bc3216d5cdb8a055461b6ed0415d' option net 'mesh_vpn' list remote '"srv08.ffnw.de" port 10002' option group ‚mesh_vpn_backbone'
Hm theoretisch könnte das evtl. doch klappen also auch upgrade übergreifend.
vg Tarek
Am Sonntag, 24. April 2016, 12:53:29 CEST schrieb Stefan via Dev:
Das wäre doch eine gute Idee, was spricht dagegen das so einzubauen?
Ich würde dafür keine extra Kategorie einführen den dafür müsste man gleich zwei Programme anfassen (hoodselector und hoodgenerator). Einfach ein eindeutiger DNS pro Fastd-Instanz und fertig. Das ist auch flexibler wenn man die Instanz mal schnell einen anderen Server schieben will.
Für die Server der default hood kann das z.B. so aussehen: "servers": [ { "host": "default01.sn.ffnw.de", "port": "10000", "publickey": "blaaaaa" }, { "host": "default02.sn.ffnw.de", "port": "10001", "publickey": "blub" } ]
Viele Grüße Clemens
On 04/24/16 13:20, Clemens John via Dev wrote:
Am Sonntag, 24. April 2016, 12:53:29 CEST schrieb Stefan via Dev:
Das wäre doch eine gute Idee, was spricht dagegen das so einzubauen?
Ich würde dafür keine extra Kategorie einführen den dafür müsste man gleich zwei Programme anfassen (hoodselector und hoodgenerator). Einfach ein eindeutiger DNS pro Fastd-Instanz und fertig. Das ist auch flexibler wenn man die Instanz mal schnell einen anderen Server schieben will.
Stimme zu Bezüglich des DNS. Ich denke aber wir sollten das in einer zukünftigen variante aufjedenfall noch mal anpacken, denn die einzelnen peers könnten auch eine liste besitzen:
config peer 'mesh_vpn_backbone_peer_srv08_10001' ... option net 'mesh_vpn' list remote '"srv08.ffnw.de" port 10001' option group 'mesh_vpn_backbone'
Das wäre konformer zur siteconf
vg Tarek
Hi zusammen,
Ich fasse die Diskutierten Lösungen noch mal zusammenso das wir uns für eine Variante entscheiden können.
Die 1. Variante ist, den Port Namen in den peer Gruppennamen mit einzubauen. Vorteil der variante ist, das sich dieses schnell durch ein paar code zielen realisieren lässt. Nachteil das fastd config file kann schnell sehr groß werden, und entspricht auch nicht den Gluon Schemata der siteconf.
Die 2. Variante ist, ein DNS Eintrag pro fastd Instanz. Vorteil man sieht via readlog auf den Routern sofort an welcher Instanz der Router genau hängt(debug vorteil). Der code muss nicht weiter angepackt werden. Nachteil das fastd config file kann schnell sehr groß werden, und entspricht auch nicht den Gluon Schemata der siteconf.
Und die 3. Variante ist, hoodselector und hood Generator den json Standard der siteconf anzupassen und einen Parameter peer group einbauen. Vorteil das fastd config file bleibt schlank, da die peers pro Gruppe in einer liste zusammen gefasst sind. und entspricht auch nicht den Gluon Schemata der siteconf. Nachteil: Der Hoodselector code muss nochmal angepackt werden. Der Hoodgenerator code muss nochmal angepackt werden.
vg :) Tarek
Hi,
Ich fasse die Diskutierten Lösungen noch mal zusammenso das wir uns für eine Variante entscheiden können.
Die 1. Variante ist, den Port Namen in den peer Gruppennamen mit einzubauen. Vorteil der variante ist, das sich dieses schnell durch ein paar code zielen realisieren lässt. Nachteil das fastd config file kann schnell sehr groß werden, und entspricht auch nicht den Gluon Schemata der siteconf.
Die 2. Variante ist, ein DNS Eintrag pro fastd Instanz. Vorteil man sieht via logread auf den Routern sofort an welcher Instanz der Router genau hängt(debug vorteil). Der code muss nicht weiter angepackt werden. Nachteil das fastd config file kann schnell sehr groß werden, und entspricht auch nicht den Gluon Schemata der siteconf.
Ich wäre für die Variante allerdings nur als überganslösung da diese aktuell keinen Aufwand erzeugt.
(Muss hier nochmal ergänzen: der debug vorteil ist quatsch da hab ich mich geirrt der ist bei der 1. Variante genauso gegeben da nicht die url angezeigt wird sonder die peergroup)
Und die 3. Variante ist, hoodselector und hood Generator den json Standard der siteconf anzupassen und einen Parameter peer group einbauen. Vorteil das fastd config file bleibt schlank, da die peers pro Gruppe in einer liste zusammen gefasst sind. und entspricht auch nicht den Gluon Schemata der siteconf. Nachteil: Der Hoodselector code muss nochmal angepackt werden. Der Hoodgenerator code muss nochmal angepackt werden.
Langfristig sollten wir das aufjedenfall so lösen, Da es die schönere Variante ist. Mehere peers wären einer peergroup zugewiesen und es verringert das Risiko potentieller Konflikte mit upstream programmen.
vg Tarek
Hi,
sehe ich genauso wie du - wir könnten das mit unterschiedlichen DNS Namen einfach lösen, da wir hier keinen Source großartig anfassen brauchen.
Im nachhinein können wir das Ganze ja sauber umsetzen ;)
Stefan
Am 26.04.2016 um 12:59 schrieb Jan-Tarek Butt via Dev:
Hi zusammen,
Ich fasse die Diskutierten Lösungen noch mal zusammenso das wir uns für eine Variante entscheiden können.
Die 1. Variante ist, den Port Namen in den peer Gruppennamen mit einzubauen. Vorteil der variante ist, das sich dieses schnell durch ein paar code zielen realisieren lässt. Nachteil das fastd config file kann schnell sehr groß werden, und entspricht auch nicht den Gluon Schemata der siteconf.
Die 2. Variante ist, ein DNS Eintrag pro fastd Instanz. Vorteil man sieht via readlog auf den Routern sofort an welcher Instanz der Router genau hängt(debug vorteil). Der code muss nicht weiter angepackt werden. Nachteil das fastd config file kann schnell sehr groß werden, und entspricht auch nicht den Gluon Schemata der siteconf.
Und die 3. Variante ist, hoodselector und hood Generator den json Standard der siteconf anzupassen und einen Parameter peer group einbauen. Vorteil das fastd config file bleibt schlank, da die peers pro Gruppe in einer liste zusammen gefasst sind. und entspricht auch nicht den Gluon Schemata der siteconf. Nachteil: Der Hoodselector code muss nochmal angepackt werden. Der Hoodgenerator code muss nochmal angepackt werden.
vg :) Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Moin zusammen,
Ich hab heute den Tag über den hoodselector umgeschrieben.
https://git.nordwest.freifunk.net/ffnw-firmware/packages/blob/0a593f4eb2a837...
Er verhält sich jetzt folgender maßen: Sei eine Anzahl von n Mesh-Routern auf einer Fläche, mit jeweils unterschiedlichen BSSIDs und keiner Erreichbarkeit von Supernodes verteilt. So sollen diese Router versuchen möglichs eine meshwolke mit zu bilden. Bekommt ein Mesh-Router nun eine Internetverbindung und somit eine Verbindung zu einen Supernode Wechselt dieser Router automatisch in seine gehörige Hood mit entsprechender BSSID. Lokale Mesh Router Würden die geänderte bssid sehe und diese übernehmen. Besitzt einer der Router nicht die zugehörige hood zur bssid so schaltet dieser den fastd ab. der Router holt sich über den Nachbar Router nach einiger zeit selbständig die neuen hoodinformationen und schaltet den fastd wieder ein sobald dieser die passenden hoodinformationen besitzt.
dazu existiert auch ein mergeRequest zugewiesen an Clemens da er ebenfalls in einen separaten Branch an einer Variante arbeitet.
https://git.nordwest.freifunk.net/ffnw-firmware/packages/merge_requests/9
vg Tarek
On 24.04.2016 01:52, Jan-Tarek Butt via Dev wrote:
Besitzt einer der Router nicht die zugehörige hood zur bssid so schaltet dieser den fastd ab. der Router holt sich über den Nachbar Router nach einiger zeit selbständig die neuen hoodinformationen und schaltet den fastd wieder ein sobald dieser die passenden hoodinformationen besitzt.
Und ich tue nochmal kund, wie bescheuert ich es finde, den eigenen Tunnel abzuschalten und sich auf die Verbindung eines Nachbarrouters zu verlassen. Das ist ein Unsicherheitsfaktor ^5.
Vor diesem Hintergrund finde ich es sogar angebracht nochmal zu diskutieren, ob eine Live-Abfrage über br-wan sinnvoll wäre!
On 04/24/16 23:44, Simon Kurka via Dev wrote:
On 24.04.2016 01:52, Jan-Tarek Butt via Dev wrote:
Besitzt einer der Router nicht die zugehörige hood zur bssid so schaltet dieser den fastd ab. der Router holt sich über den Nachbar Router nach einiger zeit selbständig die neuen hoodinformationen und schaltet den fastd wieder ein sobald dieser die passenden hoodinformationen besitzt.
Und ich tue nochmal kund, wie bescheuert ich es finde, den eigenen Tunnel abzuschalten und sich auf die Verbindung eines Nachbarrouters zu verlassen. Das ist ein Unsicherheitsfaktor ^5.
Dieser fall tritt nur ein wenn der Router keine Koordinaten hat oder zur laufzeit ein Lan kabel angeschlossen hat. Wenn der Router normal startet baut dieser eine VPN verbindung auf und setzt seine position via Geo position. Bitte auch genau im merge request lesen.
Klartext schaltet der Router den von nur ab wenn dieser am WAN port kein kabel angeschlossen hat und versucht über die Nachbarn in netz zu kommen.
vg Tarek
On 04/25/16 01:00, Jan-Tarek Butt via Dev wrote:
On 04/24/16 23:44, Simon Kurka via Dev wrote:
On 24.04.2016 01:52, Jan-Tarek Butt via Dev wrote:
Besitzt einer der Router nicht die zugehörige hood zur bssid so schaltet dieser den fastd ab. der Router holt sich über den Nachbar Router nach einiger zeit selbständig die neuen hoodinformationen und schaltet den fastd wieder ein sobald dieser die passenden hoodinformationen besitzt.
Und ich tue nochmal kund, wie bescheuert ich es finde, den eigenen Tunnel abzuschalten und sich auf die Verbindung eines Nachbarrouters zu verlassen. Das ist ein Unsicherheitsfaktor ^5.
Dieser fall tritt nur ein wenn der Router keine Koordinaten hat oder zur laufzeit ein Lan kabel angeschlossen hat. Wenn der Router normal startet baut dieser eine VPN verbindung auf und setzt seine position via Geo position. Bitte auch genau im merge request lesen.
Klartext schaltet der Router den von nur ab wenn dieser am WAN port kein kabel angeschlossen hat und versucht über die Nachbarn in netz zu kommen.
Und keine hood (somit keine peers) zur bestehenden bssid hat. Sobald der Router also das neue hoodfile über den nachbar router bekommen hat wo die informationen zur bssid im hoodfile enthalten sind schaltet der router den VPN wieder ein. Das verhindern potentielle kurtzschlüsse von hoods
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-
Bjoern Franke -
Clemens John -
Jan-Tarek Butt -
Johannes Rudolph -
Johannes Rudolph | Freifunk Nordwest
-
Simon Kurka -
Stefan