[Freifunk-Bonn] kbu gluon 2017.1.3 beta firmwares

Simon Müller simon.f.mueller at gmail.com
So Okt 15 10:55:34 CEST 2017 

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
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.kbu.freifunk.net/pipermail/freifunk-bonn/attachments/20171015/fb08d455/attachment.htm>

Mehr Informationen über die Mailingliste Freifunk-Bonn