[Freifunk-Bonn] kbu gluon 2017.1.3 beta firmwares
Marcus Schultheiss
marcus.schultheiss at onsite4u.de
So Okt 15 12:49:29 CEST 2017
Hallo Simon,
danke für die Erklärungen, bei den DNS Namen dachte ich dass bereits jetzt
ein A Record auf die IP des .kbu.freifunk.net
<http://vpn3.kbu.freifunk.net/> Eintrages gewünscht wäre um nicht auch noch
von der TTL (aktuell wohl 1h) der Einträge unter
vpn1.ffkbu.de. 3600 IN A 134.255.253.71
...
vpn8.ffkbu.de. 3600 IN A 134.255.253.71
abhängig zu sein, im Falle des genannten Falles müsste ja erst das Update
im DNS erfolgen und dann noch die Cachezeit der Einträge in den DNS Servern
der FF Nodes abgelaufen sein bevor die dann aktualisierten Einträge der
ffkbu.de Domain benutzt werden können.
Allerdings kann es in diesem sehr speziellen Fall natürlich sein, dass 1-2h
mehr auch schon nicht mehr ins Gewicht fallen.
Insgesamt ein sehr guter Ansatz das ohne Update auf den FF Nodes "zentral"
aktualisierbar zu halten, weil Änderungen in den Nodes sicher noch viel
länger brauchen würden, wenn man sieht welche Firmware Versionen noch immer
im Einsatz sind.
Ja die Limit 1 Geschichte, ist sicher gut das bei 1 zu belassen der
zusätzlich Traffic steht wohl in keinem Verhältnis und wenn einzelne
wirklich andere Anforderungen haben wird man das ganze voraussichtlich
lokal (nicht updatefest) auch auf den Nodes konfiguriert bekommen, falls es
Gründe geben sollte dass das sinnvoll ist in Ihrem Umfeld.
Das SSID/BSSID Thema, ja da habe ich dem ede wohl mit meinem Patch mesh =>
ibss seiner site.conf diese MAC im 5G Bereich untergeschoben
(versehentlich!). Ist mir wohl bei zuviel copy&paste durchgegangen, hätte
mir damals schon auffallen dürfen, leider gabs auch kein git repo / branch
gegen den ich das nochmal diffen konnte. Ärgert mich etwas dass mir das
durchgegangen ist und jetzt drin ist in beta3.
- Marcus
Am 15. Oktober 2017 um 10:55 schrieb Simon Müller <simon.f.mueller at gmail.com
>:
> Hi Marcus,
>
> Die Alternativen DNS Einträge in der site.conf sind für den Fall gedacht,
> dass freifunk.net, aus welchem Grund auch immer, nicht mehr auf unsere
> supernodes verweist. Wäre das der Fall könnte kein Node mehr via VPN zu
> unserem Freifunk Netz connecten. In dem Fall könnten wir die IP Adresse
> unserer Server auf der anderen Domain eintragen werden und alles würde
> weiterlaufen, ohne dass Änderungen an den Nodes nötig wären.
>
> Auf limit = 1 wollten wir umstellen, weil zwei gleichzeitige VPN
> Connections, die Grundlast im Netz erhöhen.
> limit = 2 hätte den Vorteil, dass im Falle eines Supernode Ausfalls etwa
> eine Sekunde schneller auf einen anderen umgeschaltet werden kann. Das
> kommt aber selten vor und eine Sekunde ist nicht so der große Vorteil.
>
> SSID/BSSID: wenn man kompatibel bleiben will, müssen die IDs mit dem alten
> Netz übereinstimmen, sonst "mesht" et nit.
>
> LG, Simon
>
>
> Am 14.10.2017 18:04 schrieb "Marcus Schultheiss" <
> marcus.schultheiss at onsite4u.de>:
>
> Hallo ede,
> Hallo Kevin,
>
> ich habe über die
>
> http://jamoke.net/kbu/gluon-2017.1.3.beta3/koeln/site/site.conf
>
> sowie die für mich bisher relevante:
> https://github.com/ff-kbu/site-ffkbuk/blob/v2016.2/site.conf
>
> auch nochmal drübergeschaut, als ich meine FF Router mit dem
> 2017.1.3.beta3 aktualisiert habe.
>
>
> Folgende Punkte sind mir noch aufgefallen:
>
> wifi24 = {
> ...
> ibss = {
> ssid = '02:d2:22:01:fc:22', -- ESSID used for mesh
> bssid = '02:d2:22:01:fc:22', -- BSSID used for mesh
> ...
> },
> },
>
> wifi5 = {
> ...
>
> ibss = {
> ssid = '02:d2:22:01:fc:22', -- ESSID used for mesh
> bssid = '02:d2:22:01:fc:22', -- BSSID used for mesh
> ...
>
> },
> },
>
>
> die beta3 site.conf enthält aktuell für 2.4 und 5Ghz die gleiche
> SSID/BSSID, das war zumind in v2016.2.x unterschiedlich, keine Ahnung ob
> das bei der Trennung der Frequenzen einen Unterschied macht, aber ggf
> finden ältere 5Ghz Router dann keine Verbindung mehr zu Routern mit
> 2017.1.3-beta3
> vgl: https://github.com/ff-kbu/site-ffkbuk/blob/v2016.2/site.conf
>
>
> Anzahl von Hostnames bei den VPN Peers:
>
> in beta3 werden die FF VPN Peers mit 1 Hostname angegeben
>
> peer1 = {
> ...
> remotes = {'"vpn1.kbu.freifunk.net" port 10010'},
> },
>
> in v2016.2.x waren es jeweils Pärchen:
>
> peer1 = {
> ...
> 'ipv4 "vpn1.kbu.freifunk.net" port 10010',
> 'ipv4 "vpn1.ffkbu.de" port 10010'
> },
>
> das ganze kommt wohl daher
> https://github.com/ff-kbu/site-ffkbuk/pull/3/commits/d3ba4cc
> 5ab83a390060f95d71199c9a7df8179e9
> > Jeden VPN Peer über zwei Domaineinträge erreichbar gemacht:
>
> fehlt aber aktuell in beta3
>
>
>
> Anzahl von connected VPN Peers:
>
> aktuell ist in beta3:
> groups = {
> backbone = {
> -- Limit number of connected peers to reduce bandwidth.
> limit = 2,
>
> gesetzt aber in v2016.2.x
> https://github.com/ff-kbu/site-ffkbuk/pull/3/commits/4caeb1c
> 4fc6555be6f69f6360f8a46ebf095b2c6
>
> wurde wohl ein
>
> limit = 1,
>
>
> eingeführt.
>
>
>
>
> Was mir etwas komisch vorkommt, aber ggf gewollt ist, in 2016.2.x sind die
> Peers wie folgt:
> ~$ for i in vpn1.kbu.freifunk.net vpn1.ffkbu.de vpn2.kbu.freifunk.net
> vpn2.ffkbu.de vpn3.kbu.freifunk.net vpn3.ffkbu.de vpn4.kbu.freifunk.net
> vpn4.ffkbu.de vpn5.kbu.freifunk.net vpn5.ffkbu.de vpn6.kbu.freifunk.net
> vpn6.ffkbu.de vpn7.kbu.freifunk.net vpn7.ffkbu.de; do echo -en "$i: ";
> dig +short $i ; done| sort -k2
>
> vpn1.ffkbu.de: 134.255.253.71
> vpn2.ffkbu.de: 134.255.253.71
> vpn3.ffkbu.de: 134.255.253.71
> vpn4.ffkbu.de: 134.255.253.71
> vpn5.ffkbu.de: 134.255.253.71
> vpn6.ffkbu.de: 134.255.253.71
> vpn7.ffkbu.de: 134.255.253.71
> vpn3.kbu.freifunk.net: 163.172.42.239
> vpn2.kbu.freifunk.net: 188.68.50.81
> vpn6.kbu.freifunk.net: 5.9.134.236
> vpn1.kbu.freifunk.net: 62.210.108.23
> vpn7.kbu.freifunk.net: 89.163.210.181
> vpn4.kbu.freifunk.net: gw01.ffeu.de.
> vpn5.kbu.freifunk.net: gw02.ffeu.de.
>
> über DNS mit Servern gemapped. Jetzt kenn ich natürlich nicht die Hardware
> von 134.255.253.71, allerdings verwundert es dann doch dass jeweils ein
> anderer Name aber dann doch die gleiche IP in jeder Peer Definition
> auftaucht.
>
>
> Hier in der fastv18 Doku wird beschrieben dass der public key des peers
> unique sein soll, zumind wenn ich es richtig verstehe:
>
> http://fastd.readthedocs.io/en/v18/manual/config.html
> > Starting with fastd v9, multiple remotes may be given for a single peer.
> If this is the case, they will be tried one after another. Starting with
> fastd v11, all addresses a given > hostname resolves to are taken into
> account, not only the first one. This can be use to specify alternative
> hostname, addresses and/or ports for the same host; all
> > remotes must still refer to the same peer as the public key must be
> unique.
>
> das wird mit o.g. vpn[1234567].ffkbu.de des v2016.2 nicht erfüllt oder?
> https://github.com/ff-kbu/site-ffkbuk/blob/v2016.2/site.conf
>
>
>
> Macht es ggf Sinn in GitHub einen Branch für 2017.1.3 einzurichten und
> dort mit Merge Requests / Pull Requests sich auszutauschen. Mail erscheint
> nicht so das passende Medium.
>
>
> - Marcus
>
>
> Am 13. Oktober 2017 um 22:45 schrieb <edgar.soldin at web.de>:
>
>> On 10/13/2017 22:18, Kevin wrote:
>> > Hi Edgar,
>> >
>> > ich verwalte die Imageserver.
>> >
>> > Ich habe gesehen, in deiner Config fehlt der Autoupdate Part.
>>
>> ja, nein, er ist deaktiviert, in a way ;)
>>
>> > Wir bauen per Jenkins auf einem unserer Buildserver der auch
>> automatisch an Update und Imageserver überträgt.
>>
>> wenn das funktioniert stell ich die site configs gerne zur verfügung
>>
>> >
>> > Hättest du eventuell sogar Lust, die Firmware zu Maintainen?
>>
>> ich tu was ich kann. was ich nicht kann isset ordentlich zu beta testen,
>> da müssen andere ran. macht ja keinen sinn bugy firmwares auszurollen.
>>
>> in diesem sinne. wer testet die neue 2017er mal auf seinen nodes? ohne
>> rückmeldungen sollten wir das nicht auf einen autoupdate kanal schieben.
>>
>> bei mir laufen sie soweit auf locoM2's und wr841. bis auf ein paar
>> lastspitzen soweit unauffällig.
>>
>> ..ede
>>
>> >
>> > Grüße
>> > Kevin
>> >
>> >
>> > Am 12.10.2017 um 15:36 schrieb edgar.soldin at web.de:
>> >> moin moin,
>> >>
>> >> jetzt sind auch gluon2017 builds für umland und bonn fertig. zumindest
>> auf nem bastel wr841 laufen beide an und es netzt auch.
>> >>
>> >> wer verwaltet denn
>> >> https://images.ffkbu.de/
>> >> ? wollen wir die vlt. da in die beta ordner schieben und denn im wiki
>> verlinken?
>> >>
>> >> ganz eilige können die images wie gehabt hier finden
>> >> http://jamoke.net/kbu/gluon-2017.1.3.beta3/
>> >>
>> >> ..ede
>> >
>>
>> --
>> _______________________________________________
>> Freifunk-Bonn mailing list
>> Freifunk-Bonn at lists.kbu.freifunk.net
>> https://lists.kbu.freifunk.net/cgi-bin/mailman/listinfo/freifunk-bonn
>>
>
>
>
> --
> --
> Marcus Schultheiss | Geschäftsführung | marcus.schultheiss at onsite4u.de
> Einzelunternehmung SteuerNr 219/5305/3168 bei Finanzamt Köln-Süd
> USt.-IdNr. DE233911805 Inhaber: Marcus Schultheiss
> onsite4u ist eine Produktbezeichnung
> Tel: 02236 3189971 | Fax: 02236 3189979 | Mobil: 0172 7063324
> Internet: http://www.onsite4u.de/
> mailto:marcus.schultheiss at onsite4u.de
>
> --
> _______________________________________________
> Freifunk-Bonn mailing list
> Freifunk-Bonn at lists.kbu.freifunk.net
> https://lists.kbu.freifunk.net/cgi-bin/mailman/listinfo/freifunk-bonn
>
>
>
> --
> _______________________________________________
> Freifunk-Bonn mailing list
> Freifunk-Bonn at lists.kbu.freifunk.net
> https://lists.kbu.freifunk.net/cgi-bin/mailman/listinfo/freifunk-bonn
>
>
--
--
Marcus Schultheiss | Geschäftsführung | marcus.schultheiss at onsite4u.de
Einzelunternehmung SteuerNr 219/5305/3168 bei Finanzamt Köln-Süd
USt.-IdNr. DE233911805 Inhaber: Marcus Schultheiss
onsite4u ist eine Produktbezeichnung
Tel: 02236 3189971 | Fax: 02236 3189979 | Mobil: 0172 7063324
Internet: http://www.onsite4u.de/
mailto:marcus.schultheiss at onsite4u.de
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.kbu.freifunk.net/pipermail/freifunk-bonn/attachments/20171015/d3267137/attachment.htm>
Mehr Informationen über die Mailingliste Freifunk-Bonn