Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 20170502 * Gluon-Version: v2016.2.x * Commit ID: 97f44c208b4dd23a63a0069963ca04fad899bf05 * Download: https://firmware.ffnw.de/20170530
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/242e63...97f44c
Folgende Gluon spezifischen Änderungen gab es unter anderen:
* backport support for TP-Link TL-WR841ND v12
* x86: backport more sysupgrade
Folgende Comunnity spezifischen Änderungen gab es: package repo:
* hoodselector: Die Fehler werden jetzt in /tmp/hoodselector_error geloggt.
* hoodselectorctl: Die uci Steuerung für den hoodselector ist in ein eigenes Paket namens hoodselectorctl ausgelagert worden.
* hoodselector: Enthält nun den Support um mit IEEE802.11s umzugehen. #86
* hoodselector: Das scannen nach benachbarten Freifunk Routern ist nun beschleunigt und kostet keine extra Airtime mehr.
* hoodselector: Das filtern des eigenen WLANs wurde verbessert. #101
* hoodselector: Die wifi Test Funktion wurde überarbeitet. Es werden nun alle STA Netze vor dem testen der umliegenden Freifunk WLANSs entfernt. #103
* hoodselector: Im MOLWM wird nun sichergestellt das der Router-eigenen Eintrag entfernt wird.
* hoodselector: Ein Fehler zur Position abfrage wurde behoben. Wenn keine uci config zu der Router Position zur Verfügung stand, hat die tonumber func nil anstatt 0 returnd so das eine folge Prüfung fehlschlug. #100
* hoodselector: Im scanmode wird bei keinem erfolgreichen scan Ergebnis wieder die defaulthood gesetzt. #99
* hoodselector: das suchen nach hoods aus dem hoodfile durch umliegende WLANs ist nicht mehr von groß, klein Notation abhängig. #102
* geolocator: Der geolocator wurde so angepasst das die pkgs libwlocate und lwtrace nicht mehr notwendig sind, damit konnten ~ 14kbyte speicher eingespart werden.
* hoods: Die default hood wurde um einen vpn peer erweitert. Die hood suedwest ist in landkreis-emsland umbenannt worden. Eine neue hood landkreis-cloppenburg ist hinzu gekommen. Eine neue hood grafschaft-bentheim ist hinzu gekommen. Eine neue hood bad-iburg ist hinzu gekommen.
siteconf repo:
* IEEE802.11s kann jetzt optional im configMode eingeschaltet werden.
* iw: package wurde erweitert um den Umgang mit IEEE802.11s zu ermöglichen.
* libwlocate: package wurde entfernt.
* lwtrace: package wurde entfernt.
* netmon-node-client: ist in die Firmware aufgenommen worden. Das package soll das neue Administrations- und Monitorring-Portal Netmon-gn mit Daten versorgen.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170410......
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170410......
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Entwicklung/Firmware_releaseprozess#Firmw...
Schöne Grüße Tarek
Hi,
- hoods: Die default hood wurde um einen vpn peer erweitert.
Warum brauchen wir einen weiteren Peer in der Defaulthood, die gehört doch inzwischen eher zu den kleineren?
Das könnte mehrere Gründe haben, z.b. das fastd auf zwei cores laufen soll. Fastd ist leider nur Single core fähig, daher kann man mit einer zweiten Instanz die Nutzung eines weiteren cores ermöglichen.
vg Tarek
Hi,
genau, so ist es
Von meinem iPhone gesendet
Am 31.05.2017 um 08:35 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
- hoods: Die default hood wurde um einen vpn peer erweitert.
Warum brauchen wir einen weiteren Peer in der Defaulthood, die gehört doch inzwischen eher zu den kleineren?
Das könnte mehrere Gründe haben, z.b. das fastd auf zwei cores laufen soll. Fastd ist leider nur Single core fähig, daher kann man mit einer zweiten Instanz die Nutzung eines weiteren cores ermöglichen.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
ich würde gerne nochmal zur Diskussion stellen, warum wir extra Code für die Datenversorgung eines Administrationstools aufnehmen.
Welche Daten können über respondd nicht bezogen werden?
Wie gehen wir mit potentiell anderen Administrationsoberflächen um? Nach dem jetzigen Vorgehen sollten wir jedes Tool in Entwicklung einen eigenen Client in die Firmware einbauen.
Zwei offenbar unnötig gewordene packages (libwlocate, lwtrace) zu entfernen, um Speicher zu sparen und gleichzeitig ein neues (scheinbar, bitte widerlegen!) unnötiges Paket hinzuzufügen, scheint mir widersprüchlich zu sein.
Viele Grüße, Simon
On 31.05.2017 02:45, Jan-Tarek Butt via Dev wrote:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20170502
- Gluon-Version: v2016.2.x
- Commit ID: 97f44c208b4dd23a63a0069963ca04fad899bf05
- Download: https://firmware.ffnw.de/20170530
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/242e63...97f44c
Folgende Gluon spezifischen Änderungen gab es unter anderen:
backport support for TP-Link TL-WR841ND v12
x86: backport more sysupgrade
Folgende Comunnity spezifischen Änderungen gab es: package repo:
hoodselector: Die Fehler werden jetzt in /tmp/hoodselector_error geloggt.
hoodselectorctl: Die uci Steuerung für den hoodselector ist in ein eigenes Paket namens hoodselectorctl ausgelagert worden.
hoodselector: Enthält nun den Support um mit IEEE802.11s umzugehen. #86
hoodselector: Das scannen nach benachbarten Freifunk Routern ist nun beschleunigt und kostet keine extra Airtime mehr.
hoodselector: Das filtern des eigenen WLANs wurde verbessert. #101
hoodselector: Die wifi Test Funktion wurde überarbeitet. Es werden nun alle STA Netze vor dem testen der umliegenden Freifunk WLANSs entfernt. #103
hoodselector: Im MOLWM wird nun sichergestellt das der Router-eigenen Eintrag entfernt wird.
hoodselector: Ein Fehler zur Position abfrage wurde behoben. Wenn keine uci config zu der Router Position zur Verfügung stand, hat die tonumber func nil anstatt 0 returnd so das eine folge Prüfung fehlschlug. #100
hoodselector: Im scanmode wird bei keinem erfolgreichen scan Ergebnis wieder die defaulthood gesetzt. #99
hoodselector: das suchen nach hoods aus dem hoodfile durch umliegende WLANs ist nicht mehr von groß, klein Notation abhängig. #102
geolocator: Der geolocator wurde so angepasst das die pkgs libwlocate und lwtrace nicht mehr notwendig sind, damit konnten ~ 14kbyte speicher eingespart werden.
hoods: Die default hood wurde um einen vpn peer erweitert. Die hood suedwest ist in landkreis-emsland umbenannt worden. Eine neue hood landkreis-cloppenburg ist hinzu gekommen. Eine neue hood grafschaft-bentheim ist hinzu gekommen. Eine neue hood bad-iburg ist hinzu gekommen.
siteconf repo:
IEEE802.11s kann jetzt optional im configMode eingeschaltet werden.
iw: package wurde erweitert um den Umgang mit IEEE802.11s zu ermöglichen.
libwlocate: package wurde entfernt.
lwtrace: package wurde entfernt.
netmon-node-client: ist in die Firmware aufgenommen worden. Das package soll das neue Administrations- und Monitorring-Portal Netmon-gn mit Daten versorgen.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170410......
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170410......
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Entwicklung/Firmware_releaseprozess#Firmw...
Schöne Grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Moin
Ein paar bedenken teile ich auch mit Simon
Am 31.05.2017 um 11:09 schrieb Simon Kurka via Dev dev@lists.ffnw.de:
Hi,
ich würde gerne nochmal zur Diskussion stellen, warum wir extra Code für die Datenversorgung eines Administrationstools aufnehmen.
Welche Daten können über respondd nicht bezogen werden?
Wie gehen wir mit potentiell anderen Administrationsoberflächen um? Nach dem jetzigen Vorgehen sollten wir jedes Tool in Entwicklung einen eigenen Client in die Firmware einbauen.
Im Sinne der Denzentralität würde ich da Sauce echt ungern integrieren in dieser Form. Netmon kann doch auch die respondd Daten nutzten die sowieso schon durch das Netzwerkgeschickt werden. Ich würde es auch besser finden eventl fehlende sachen bei respondd zu erweitern
Zwei offenbar unnötig gewordene packages (libwlocate, lwtrace) zu entfernen, um Speicher zu sparen und gleichzeitig ein neues (scheinbar, bitte widerlegen!) unnötiges Paket hinzuzufügen, scheint mir widersprüchlich zu sein. Viele Grüße, Simon
On 31.05.2017 02:45, Jan-Tarek Butt via Dev wrote: Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20170502
- Gluon-Version: v2016.2.x
- Commit ID: 97f44c208b4dd23a63a0069963ca04fad899bf05
- Download: https://firmware.ffnw.de/20170530
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/242e63...97f44c
Folgende Gluon spezifischen Änderungen gab es unter anderen:
backport support for TP-Link TL-WR841ND v12
x86: backport more sysupgrade
Folgende Comunnity spezifischen Änderungen gab es: package repo:
hoodselector: Die Fehler werden jetzt in /tmp/hoodselector_error geloggt.
hoodselectorctl: Die uci Steuerung für den hoodselector ist in ein eigenes Paket namens hoodselectorctl ausgelagert worden.
hoodselector: Enthält nun den Support um mit IEEE802.11s umzugehen. #86
hoodselector: Das scannen nach benachbarten Freifunk Routern ist nun beschleunigt und kostet keine extra Airtime mehr.
hoodselector: Das filtern des eigenen WLANs wurde verbessert. #101
hoodselector: Die wifi Test Funktion wurde überarbeitet. Es werden nun alle STA Netze vor dem testen der umliegenden Freifunk WLANSs entfernt. #103
hoodselector: Im MOLWM wird nun sichergestellt das der Router-eigenen Eintrag entfernt wird.
hoodselector: Ein Fehler zur Position abfrage wurde behoben. Wenn keine uci config zu der Router Position zur Verfügung stand, hat die tonumber func nil anstatt 0 returnd so das eine folge Prüfung fehlschlug. #100
hoodselector: Im scanmode wird bei keinem erfolgreichen scan Ergebnis wieder die defaulthood gesetzt. #99
hoodselector: das suchen nach hoods aus dem hoodfile durch umliegende WLANs ist nicht mehr von groß, klein Notation abhängig. #102
geolocator: Der geolocator wurde so angepasst das die pkgs libwlocate und lwtrace nicht mehr notwendig sind, damit konnten ~ 14kbyte speicher eingespart werden.
hoods: Die default hood wurde um einen vpn peer erweitert. Die hood suedwest ist in landkreis-emsland umbenannt worden. Eine neue hood landkreis-cloppenburg ist hinzu gekommen. Eine neue hood grafschaft-bentheim ist hinzu gekommen. Eine neue hood bad-iburg ist hinzu gekommen.
siteconf repo:
IEEE802.11s kann jetzt optional im configMode eingeschaltet werden.
iw: package wurde erweitert um den Umgang mit IEEE802.11s zu ermöglichen.
libwlocate: package wurde entfernt.
lwtrace: package wurde entfernt.
netmon-node-client: ist in die Firmware aufgenommen worden. Das package soll das neue Administrations- und Monitorring-Portal Netmon-gn mit Daten versorgen.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170410......
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170410......
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Entwicklung/Firmware_releaseprozess#Firmw...
Schöne Grüße Tarek
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,
ich würde gerne nochmal zur Diskussion stellen, warum wir extra Code für die Datenversorgung eines Administrationstools aufnehmen.
Welche Daten können über respondd nicht bezogen werden?
Respondd arbeitet auf einem ganz anderen Layer als der Netmon-node-client.
Wie gehen wir mit potentiell anderen Administrationsoberflächen um? Nach dem jetzigen Vorgehen sollten wir jedes Tool in Entwicklung einen eigenen Client in die Firmware einbauen.
Hier verstehe ich nicht ganz was du aussagen möchtest.
Zwei offenbar unnötig gewordene packages (libwlocate, lwtrace) zu entfernen, um Speicher zu sparen und gleichzeitig ein neues (scheinbar, bitte widerlegen!) unnötiges Paket hinzuzufügen, scheint mir widersprüchlich zu sein.
Das ist nicht ganz richtig, die Funktionalität der packages libwlocate, lwtrace konnten um eine kleine Erweiterung des bash codes des geolocator abgedegt werden. Somit sind die packages libwlocate, lwtrace obsolet geworden.
Im falle von netmon-node-client geht es darum die Entwicklung des Netmon-ng zu unterstützen.
Ich denke Clemenz wird dazu aber auch nochmal Stellung beziehen.
vg Tarek
Am Mittwoch, 31. Mai 2017, 12:28:32 CEST schrieb Jan-Tarek Butt via Dev:
Im falle von netmon-node-client geht es darum die Entwicklung des Netmon-ng zu unterstützen.
Ich denke Clemenz wird dazu aber auch nochmal Stellung beziehen.
Moin!
Die Kommunikation mit Netmon läuft über eine authentifizierte REST API im json:api Format. Zur Kommunikation mit der API wird ein Client benötigt, der die Daten des Geräts mit Netmon synchronisieren kann. Der Client den ich anbiete ist ein Proof-of-Concept und mit Sicherheit nicht der Weisheit letzter Schluss.
Ich habe den von mir entwickelten Client in die Firmware integriert um Interessierten leichteres Testen zu ermöglichen. Der Client ist aktuell standardmäßig deaktiviert und muss von Interessenten, die am Test teilnehmen wollen manuell aktiviert werden. Von meiner Seite aus bleibt das solange, bis wir der Meinung sind dass das ganze produktiv gehen kann.
Dass der Kern der Software nach dem Client-Server Prinzip arbeitet, darf in diesem Zusammenhang gerne als Aufforderung verstanden werden alternative Clients zu Entwickeln, die genau an die eigenen Bedürfnisse angepasst sind. Ein solcher alternativer Client kann gerne auch den von mir entwickelten Client in unserer Firmware ersetzen. Wenn jemand aus der Runde einen solchen Client sogar auf Basis bereits integrierter Tools umsetzen kann würde ich das sehr begrüßen. Bis dahin würde ich vorschlagen den aktuellen Stand aufzunehmen.
Viele Grüße Clemens
Moin
Am 31.05.2017 um 13:12 schrieb Clemens John via Dev dev@lists.ffnw.de:
Am Mittwoch, 31. Mai 2017, 12:28:32 CEST schrieb Jan-Tarek Butt via Dev:
Im falle von netmon-node-client geht es darum die Entwicklung des Netmon-ng zu unterstützen.
Ich denke Clemenz wird dazu aber auch nochmal Stellung beziehen.
Moin!
Die Kommunikation mit Netmon läuft über eine authentifizierte REST API im json:api Format. Zur Kommunikation mit der API wird ein Client benötigt, der die Daten des Geräts mit Netmon synchronisieren kann. Der Client den ich anbiete ist ein Proof-of-Concept und mit Sicherheit nicht der Weisheit letzter Schluss.
Hast du eine API Beschreibung mit den Daten die du für Netmon benötigst?
Ich habe den von mir entwickelten Client in die Firmware integriert um Interessierten leichteres Testen zu ermöglichen. Der Client ist aktuell standardmäßig deaktiviert und muss von Interessenten, die am Test teilnehmen wollen manuell aktiviert werden. Von meiner Seite aus bleibt das solange, bis wir der Meinung sind dass das ganze produktiv gehen kann.
Dass der Kern der Software nach dem Client-Server Prinzip arbeitet, darf in diesem Zusammenhang gerne als Aufforderung verstanden werden alternative Clients zu Entwickeln, die genau an die eigenen Bedürfnisse angepasst sind. Ein solcher alternativer Client kann gerne auch den von mir entwickelten Client in unserer Firmware ersetzen. Wenn jemand aus der Runde einen solchen Client sogar auf Basis bereits integrierter Tools umsetzen kann würde ich das sehr begrüßen. Bis dahin würde ich vorschlagen den aktuellen Stand aufzunehmen.
Viele Grüße Clemens _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am Mittwoch, 31. Mai 2017, 13:20:59 CEST schrieb Johannes Rudolph via Dev:
Hast du eine API Beschreibung mit den Daten die du für Netmon benötigst?
Hi,
bisher leider noch nicht. Das ist zwar ein sehr wichtiger Punkt allerdings auch ein sehr aufwändiger für den die API stabil sein muss. Ich bin da noch nicht mit allen Punkten zu 100% zufrieden darum bisher keine Doku. Der Proof- of-Concept Node-Client dient dazu alle relevanten Punkte einmal exemplarisch zu testen, Schwachstellen auszumachen und dann zu überarbeiten.
Wenn sich das jetzt sofort jemand ansehen will dann werft bitte einen Blick auf die Kommunikation des Web-Clients unter https://netmon.ffnw.de
Relevant für einen ersten Einstieg sind folgende Prozesse: * Signup * Login * Create Device * Create Device-Status (hierfür bitte in den Code des Node-Client schauen)
Im Firefox strg+shift+k und dann unter Network. Die Authentifizierung läuft jeweils über auth tokens auf JWT Basis.
Viele Grüße Clemens
Ich wäre dafür ein openwrt / lede package zu bauen, dass man bei Bedarf per opkg installieren kann. Das kann der Einfachheit in unserem Mirror hinterlegt sein.
Jetzt Entwicklerversionen einzubauen, die nicht für den Netzbetrieb wichtig sind, finde ich falsch.
Am 31.05.2017 14:44 schrieb "Clemens John via Dev" dev@lists.ffnw.de:
Am Mittwoch, 31. Mai 2017, 13:20:59 CEST schrieb Johannes Rudolph via Dev:
Hast du eine API Beschreibung mit den Daten die du für Netmon benötigst?
Hi,
bisher leider noch nicht. Das ist zwar ein sehr wichtiger Punkt allerdings auch ein sehr aufwändiger für den die API stabil sein muss. Ich bin da noch nicht mit allen Punkten zu 100% zufrieden darum bisher keine Doku. Der Proof- of-Concept Node-Client dient dazu alle relevanten Punkte einmal exemplarisch zu testen, Schwachstellen auszumachen und dann zu überarbeiten.
Wenn sich das jetzt sofort jemand ansehen will dann werft bitte einen Blick auf die Kommunikation des Web-Clients unter https://netmon.ffnw.de
Relevant für einen ersten Einstieg sind folgende Prozesse:
- Signup
- Login
- Create Device
- Create Device-Status (hierfür bitte in den Code des Node-Client schauen)
Im Firefox strg+shift+k und dann unter Network. Die Authentifizierung läuft jeweils über auth tokens auf JWT Basis.
Viele Grüße Clemens _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 05/31/17 15:03, Simon Kurka via Dev wrote:
Ich wäre dafür ein openwrt / lede package zu bauen, dass man bei Bedarf per opkg installieren kann. Das kann der Einfachheit in unserem Mirror hinterlegt sein.
Jetzt Entwicklerversionen einzubauen, die nicht für den Netzbetrieb wichtig sind, finde ich falsch.
Jo Damit, wäre ich auch einverstanden.
dann kann man sich den netmon-client bei bedarf nach installieren.
vg Tarek
On 05/31/17 16:14, Jan-Tarek Butt via Dev wrote:
On 05/31/17 15:03, Simon Kurka via Dev wrote:
Ich wäre dafür ein openwrt / lede package zu bauen, dass man bei Bedarf per opkg installieren kann. Das kann der Einfachheit in unserem Mirror hinterlegt sein.
Jetzt Entwicklerversionen einzubauen, die nicht für den Netzbetrieb wichtig sind, finde ich falsch.
Jo Damit, wäre ich auch einverstanden.
dann kann man sich den netmon-client bei bedarf nach installieren.
Ich habe gerade mal versucht zu realiesieren das man den netmon client nur in die opkg list packt. Das ist leider nicht ohne weiteres möglich...
Daher fällt die Option somit erst mal raus.
vg Tarek
Am Mittwoch, 31. Mai 2017, 15:03:41 CEST schrieb Simon Kurka:
Ich wäre dafür ein openwrt / lede package zu bauen, dass man bei Bedarf per opkg installieren kann. Das kann der Einfachheit in unserem Mirror hinterlegt sein.
Jetzt Entwicklerversionen einzubauen, die nicht für den Netzbetrieb wichtig sind, finde ich falsch.
Das Testen als Paket ist schon seit ein paar Monaten möglich und zumindest Stefan und ich haben das auch bereits fleißig getan sodass die Software dem Stadium als reine Entwicklerversion entwachsen ist.
Ich bin großer Fan kleiner Schritte. Insbesondere wenn die Software an sich zwar einen gewissen Stabilitätsgrad erreicht hat, aber bestimmte Begleitanforderungen (wie z.B. Dokumentation oder die Entwicklung von Visualisierungstools) noch nicht erfüllt sind.
Das ist meiner Meinung nach der Punkt an dem es Sinnvoll ist eine Software einem bestimmten Publikum ohne die negativen Begleiterscheinungen einer manuellen Paket-Installation zugänglich zu machen ohne sie direkt per Default der Allgemeinheit aufzudrücken. Es gibt da verschiedene populäre Beispiele, die das so handhaben.
Normalerweise läuft das über getrennte Update-Channel, allerdings ist mein letzter Stand, dass unser Testing-Channel für diesen Zweck auch nicht der richtige Ort ist, weil da wohl teilweise relativ unstabile Dinge abgehen. Ich habe hier einfach nur eine stabile Software, die ich zwar ausliefern aber noch nicht per Default einschalten will.
Also wenn es mit der Software ein Problem gibt, dann stellt die gerne für das nächste Release zurück, macht mir einen Bugreport auf und ich behebe das Problem.
Viele Grüße Clemens
Das Testen als Paket ist schon seit ein paar Monaten möglich und zumindest Stefan und ich haben das auch bereits fleißig getan sodass die Software dem Stadium als reine Entwicklerversion entwachsen ist.
Ich bin großer Fan kleiner Schritte. Insbesondere wenn die Software an sich zwar einen gewissen Stabilitätsgrad erreicht hat, aber bestimmte Begleitanforderungen (wie z.B. Dokumentation oder die Entwicklung von Visualisierungstools) noch nicht erfüllt sind.
Das ist meiner Meinung nach der Punkt an dem es Sinnvoll ist eine Software einem bestimmten Publikum ohne die negativen Begleiterscheinungen einer manuellen Paket-Installation zugänglich zu machen ohne sie direkt per Default der Allgemeinheit aufzudrücken. Es gibt da verschiedene populäre Beispiele, die das so handhaben.
Normalerweise läuft das über getrennte Update-Channel, allerdings ist mein letzter Stand, dass unser Testing-Channel für diesen Zweck auch nicht der richtige Ort ist, weil da wohl teilweise relativ unstabile Dinge abgehen. Ich habe hier einfach nur eine stabile Software, die ich zwar ausliefern aber noch nicht per Default einschalten will.
Also wenn es mit der Software ein Problem gibt, dann stellt die gerne für das nächste Release zurück, macht mir einen Bugreport auf und ich behebe das Problem.
Also, ich war mir bei mergen auch nicht sicher in wie fern es sinnvoll die Software vorinstalliert auf den Router zu packen und das ganze dann auch noch deaktiviert...
Die Idee von Simon finde ich persönlich am besten, dann kann man ganz einfach mit:
opkg install netmon-node-client
den client installieren bei bedarf.
währst du damit einverstanden Clemens?
vg Tarek
Am Mittwoch, 31. Mai 2017, 17:06:28 CEST schrieb Jan-Tarek Butt via Dev:
opkg install netmon-node-client
den client installieren bei bedarf.
währst du damit einverstanden Clemens?
Das ist das Verfahren, das wir seit fünf Monaten nutzen. Insofern ist das weder etwas neues, noch gehen wir damit einen Schritt vorwärts. Das Problem mit diesem Ansatz ist zudem, dass er nicht Updatefest ist, was mir nach einem halben Jahr so langsam auf die Nerven geht.
Damit wir an dieser Stelle vorwärts kommen folgender Alternativvorschlag: Das Paket bleibt drin und fliegt wieder raus, wenn mit dem Paket Probleme auftreten, die das korrekte funktionieren der Firmware beeinträchtigen.
Der Client ist per Default abgeschaltet somit kann das Paket jederzeit problemlos wieder aus der Firmware entfernt werden. Und das Speicherplatz- Argument ist ein Argument, dass man gegen jede neue Software bringen kann ;)
Viele Grüße Clemens
Moin
Am 31.05.2017 um 19:14 schrieb Clemens John via Dev dev@lists.ffnw.de:
Am Mittwoch, 31. Mai 2017, 17:06:28 CEST schrieb Jan-Tarek Butt via Dev:
opkg install netmon-node-client
den client installieren bei bedarf.
währst du damit einverstanden Clemens?
Das ist das Verfahren, das wir seit fünf Monaten nutzen. Insofern ist das weder etwas neues, noch gehen wir damit einen Schritt vorwärts. Das Problem mit diesem Ansatz ist zudem, dass er nicht Updatefest ist, was mir nach einem halben Jahr so langsam auf die Nerven geht.
Das kann man ja ändern ;) Zum Beispiel Sachen in /etc/config/ speichern das wird beim normalen sysupgrade nicht gelöscht
Damit wir an dieser Stelle vorwärts kommen folgender Alternativvorschlag: Das Paket bleibt drin und fliegt wieder raus, wenn mit dem Paket Probleme auftreten, die das korrekte funktionieren der Firmware beeinträchtigen.
Der Client ist per Default abgeschaltet somit kann das Paket jederzeit problemlos wieder aus der Firmware entfernt werden. Und das Speicherplatz- Argument ist ein Argument, dass man gegen jede neue Software bringen kann ;)
Viele Grüße Clemens _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am 31.05.2017 um 20:09 schrieb Clemens John via Dev dev@lists.ffnw.de:
Am Mittwoch, 31. Mai 2017, 19:19:18 CEST schrieb Johannes Rudolph via Dev:
Das kann man ja ändern ;) Zum Beispiel Sachen in /etc/config/ speichern das wird beim normalen sysupgrade nicht gelöscht
Und der Rest des Pakets?
Ja ok der ist weg^^
Viele Grüße Clemens _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 05/31/17 19:14, Clemens John via Dev wrote:
Am Mittwoch, 31. Mai 2017, 17:06:28 CEST schrieb Jan-Tarek Butt via Dev:
opkg install netmon-node-client
den client installieren bei bedarf.
währst du damit einverstanden Clemens?
Das ist das Verfahren, das wir seit fünf Monaten nutzen. Insofern ist das weder etwas neues, noch gehen wir damit einen Schritt vorwärts. Das Problem
Das kann nicht sein, denn das pkg hab ich nie in unsere openwrt repos aufgenommen. Du meinst warscheinlich man kopire die .ipk auf den router z.b. via scp und arbeite dann über opkg install. bei der variante wie ich sie meine ist nurnoch opkg install nötig da, es somit in unserem packages source repo ist.
mit diesem Ansatz ist zudem, dass er nicht Updatefest ist, was mir nach einem halben Jahr so langsam auf die Nerven geht.
Ah, jo das stimmt natürlich. S.o.
Damit wir an dieser Stelle vorwärts kommen folgender Alternativvorschlag: Das Paket bleibt drin und fliegt wieder raus, wenn mit dem Paket Probleme auftreten, die das korrekte funktionieren der Firmware beeinträchtigen.
Der Client ist per Default abgeschaltet somit kann das Paket jederzeit problemlos wieder aus der Firmware entfernt werden. Und das Speicherplatz- Argument ist ein Argument, dass man gegen jede neue Software bringen kann ;)
Damit wäre ich auch einverstanden.
schöne grüße Tarek
Den Rest des Paketes kann man auch schützen.
Bisher wurde kein Mehrnutzen genannt (respondd kann alle Daten liefern), daher bin ich dagegen.
Alternativ kann man sich Patch basiert eigene Firmwares bauen, sogar automatisiert. In die offizielle Firmware muss es nicht, denke ich.
Am 31.05.2017 21:02 schrieb "Jan-Tarek Butt via Dev" dev@lists.ffnw.de:
On 05/31/17 19:14, Clemens John via Dev wrote:
Am Mittwoch, 31. Mai 2017, 17:06:28 CEST schrieb Jan-Tarek Butt via Dev:
opkg install netmon-node-client
den client installieren bei bedarf.
währst du damit einverstanden Clemens?
Das ist das Verfahren, das wir seit fünf Monaten nutzen. Insofern ist das weder etwas neues, noch gehen wir damit einen Schritt vorwärts. Das
Problem
Das kann nicht sein, denn das pkg hab ich nie in unsere openwrt repos aufgenommen. Du meinst warscheinlich man kopire die .ipk auf den router z.b. via scp und arbeite dann über opkg install. bei der variante wie ich sie meine ist nurnoch opkg install nötig da, es somit in unserem packages source repo ist.
mit diesem Ansatz ist zudem, dass er nicht Updatefest ist, was mir nach
einem
halben Jahr so langsam auf die Nerven geht.
Ah, jo das stimmt natürlich. S.o.
Damit wir an dieser Stelle vorwärts kommen folgender
Alternativvorschlag: Das
Paket bleibt drin und fliegt wieder raus, wenn mit dem Paket Probleme auftreten, die das korrekte funktionieren der Firmware beeinträchtigen.
Der Client ist per Default abgeschaltet somit kann das Paket jederzeit problemlos wieder aus der Firmware entfernt werden. Und das
Speicherplatz-
Argument ist ein Argument, dass man gegen jede neue Software bringen
kann ;)
Damit wäre ich auch einverstanden.
schöne grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 05/31/17 22:11, Simon Kurka wrote:
Den Rest des Paketes kann man auch schützen.
Bisher wurde kein Mehrnutzen genannt (respondd kann alle Daten liefern), daher bin ich dagegen
Es stellt aktuell ja auch nur eine bessere Basis zur Entwicklung von Netmon. Ich kann Clemens da schon nach vollziehen.
Alternativ kann man sich Patch basiert eigene Firmwares bauen, sogar automatisiert. In die offizielle Firmware muss es nicht, denke ich.
@Clemens: Was spricht denn dagegen den o.G. vorschlagt umzusetzen?
Ich hab nix dagegen die Software in die Allgemeine Firmware aufzunehmen wenn sie bsp. per default an ist, aber so würde ich auch eher versuchen eine andere Lösung zu suchen.
vg Tarek
Am Mittwoch, 31. Mai 2017, 22:11:24 CEST schrieb Simon Kurka via Dev:
Den Rest des Paketes kann man auch schützen.
Kannst du kurz beschreiben was man dazu machen muss oder mir nen Hinweis auf Doku geben?
Bisher wurde kein Mehrnutzen genannt (respondd kann alle Daten liefern), daher bin ich dagegen.
Ich wiederhole mich: wer das Know-How und die Zeit hat einen Client zu schreiben, der sich zwischen Respondd und die API setzt um die Daten zu Syncen, quasi ein Crawler, der möge das bitte unbedingt tun! Ich bin da über die Umsetzung alternativer Ansätze jederzeit Dankbar. Wenn das so einfach und vorteilhaft ist und das jemand evaluieren, umsetzen und Maintainen will, warum diskutieren wir dann noch?
Insgesamt kann ich der Diskussion nicht mehr folgen. Als ich die Entwicklung vor zwei Jahren gestartet habe war Grundlage, dass wir einen Verbesserungsbedarf bei der Verwaltung und Visualisierung unseres Netzes sehen. Außerdem bestand bisher der dringende Bedarf bestimmte Prozesse bei Aufbau und Betrieb des Netzes (Abwicklung von Förderprogrammen, regelmäßige Wartung und Information im Fehlerfall) zu unterstützen sowie das Verknüpfen der Netz-Daten mit weiteren Informationen bspw. zum Standort zu ermöglichen.
Jetzt wo die Entwicklung zu einem brauchbaren Stand gekommen ist, fangen einige hier an zu mauern wo es nur geht und ziehen mich Stundenlang in eine Diskussion um einen Punkt der allen Testern hilft, stabil ist und jederzeit schadlos rückgängig gemacht werden kann?
Ich bin an zwei Dingen interessiert: * Wie kann man Pakete über Firmware-Upgrade preserven (ganz unabhängig von der Diskussion fände ich das Feature sehr praktisch) * Entwickler die Bock haben einen Respondd2Netmon-Client zu evaluieren, zu entwickeln und zu maintainen
Von meiner Seite aus steht der Integration des Node-Clients nichts im Weg. Zum Rest der Diskussion ist alles gesagt sodass ich mich darauf konzentriere den Rest zu testen und zu signieren.
Viele Grüße Clemens
Hi,
dann muss ich hier auch mal meinen Senf dazu geben.
Clemens und ich haben vor einigen Monaten auf Testroutern eine FW eingesetzt, die den Netmon-Node-Client enthält.
Ich verstehe aktuell auch nicht, warum es ein Problem ist, diesen in eine stable FW einzubauen, wo dieser von Grund eh deaktiviert ist. Die paar kb an Speicher zählen da nicht.
Wir sollten einfach mal Dinge umsetzen und nicht tagelang darüber diskutieren - hier geht einfach viel zu viel Zeit für unnötiges Gerede drauf.
Ziel für uns alle soll es ja sein, die Entwicklung des Netmons vorran zu bringen - nur ihr hintert grade sowohl Clemens als auch mich daran - ich warte seit vielen Versionen der FW auf die Integration damit wir hier weiter vorran kommen.
VG
Stefan
Am 01.06.2017 um 11:26 schrieb Clemens John via Dev:
Am Mittwoch, 31. Mai 2017, 22:11:24 CEST schrieb Simon Kurka via Dev:
Den Rest des Paketes kann man auch schützen.
Kannst du kurz beschreiben was man dazu machen muss oder mir nen Hinweis auf Doku geben?
Bisher wurde kein Mehrnutzen genannt (respondd kann alle Daten liefern), daher bin ich dagegen.
Ich wiederhole mich: wer das Know-How und die Zeit hat einen Client zu schreiben, der sich zwischen Respondd und die API setzt um die Daten zu Syncen, quasi ein Crawler, der möge das bitte unbedingt tun! Ich bin da über die Umsetzung alternativer Ansätze jederzeit Dankbar. Wenn das so einfach und vorteilhaft ist und das jemand evaluieren, umsetzen und Maintainen will, warum diskutieren wir dann noch?
Insgesamt kann ich der Diskussion nicht mehr folgen. Als ich die Entwicklung vor zwei Jahren gestartet habe war Grundlage, dass wir einen Verbesserungsbedarf bei der Verwaltung und Visualisierung unseres Netzes sehen. Außerdem bestand bisher der dringende Bedarf bestimmte Prozesse bei Aufbau und Betrieb des Netzes (Abwicklung von Förderprogrammen, regelmäßige Wartung und Information im Fehlerfall) zu unterstützen sowie das Verknüpfen der Netz-Daten mit weiteren Informationen bspw. zum Standort zu ermöglichen.
Jetzt wo die Entwicklung zu einem brauchbaren Stand gekommen ist, fangen einige hier an zu mauern wo es nur geht und ziehen mich Stundenlang in eine Diskussion um einen Punkt der allen Testern hilft, stabil ist und jederzeit schadlos rückgängig gemacht werden kann?
Ich bin an zwei Dingen interessiert:
- Wie kann man Pakete über Firmware-Upgrade preserven (ganz unabhängig von
der Diskussion fände ich das Feature sehr praktisch)
- Entwickler die Bock haben einen Respondd2Netmon-Client zu evaluieren, zu
entwickeln und zu maintainen
Von meiner Seite aus steht der Integration des Node-Clients nichts im Weg. Zum Rest der Diskussion ist alles gesagt sodass ich mich darauf konzentriere den Rest zu testen und zu signieren.
Viele Grüße Clemens
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 06/01/17 11:30, Stefan via Dev wrote:
Hi,
dann muss ich hier auch mal meinen Senf dazu geben.
Clemens und ich haben vor einigen Monaten auf Testroutern eine FW eingesetzt, die den Netmon-Node-Client enthält.
Ich verstehe aktuell auch nicht, warum es ein Problem ist, diesen in eine stable FW einzubauen, wo dieser von Grund eh deaktiviert ist. Die paar kb an Speicher zählen da nicht.
Wir sollten einfach mal Dinge umsetzen und nicht tagelang darüber diskutieren - hier geht einfach viel zu viel Zeit für unnötiges Gerede drauf.
Ziel für uns alle soll es ja sein, die Entwicklung des Netmons vorran zu bringen - nur ihr hintert grade sowohl Clemens als auch mich daran - ich warte seit vielen Versionen der FW auf die Integration damit wir hier weiter vorran kommen.
Du musst letztlich nur testen und signieren wenn du der Meinung bist. Das diese Firmware für dich in Ordnung ist.
Ich hab ja schon signiert. Für mich wäre ich einverstanden mit dem jetztigen signrequest. Da es imoh nicht weh tut und letztlich die Entwicklung eines Projektes fördert. Rausschmeißen kann man es dann immer noch bei speicher Knappheit.
vg Tarek
Moin
Am 01.06.2017 um 11:26 schrieb Clemens John via Dev dev@lists.ffnw.de:
Am Mittwoch, 31. Mai 2017, 22:11:24 CEST schrieb Simon Kurka via Dev:
Den Rest des Paketes kann man auch schützen.
Kannst du kurz beschreiben was man dazu machen muss oder mir nen Hinweis auf Doku geben?
Bisher wurde kein Mehrnutzen genannt (respondd kann alle Daten liefern), daher bin ich dagegen.
Ich wiederhole mich: wer das Know-How und die Zeit hat einen Client zu schreiben, der sich zwischen Respondd und die API setzt um die Daten zu Syncen, quasi ein Crawler, der möge das bitte unbedingt tun! Ich bin da über die Umsetzung alternativer Ansätze jederzeit Dankbar. Wenn das so einfach und vorteilhaft ist und das jemand evaluieren, umsetzen und Maintainen will, warum diskutieren wir dann noch?
Naja für die die Evaluierung brauchen wir ja nur ne Auflistung aller Daten die Netmon brauch. Da du den bisherigen Client geschrieben hast wäre es ja vom Vorteil wenn du das einmal aufführst was gebraucht wird. Ich war jetzt davon ausgegangen das so eine Doku bereits besteht.
Insgesamt kann ich der Diskussion nicht mehr folgen. Als ich die Entwicklung vor zwei Jahren gestartet habe war Grundlage, dass wir einen Verbesserungsbedarf bei der Verwaltung und Visualisierung unseres Netzes sehen. Außerdem bestand bisher der dringende Bedarf bestimmte Prozesse bei Aufbau und Betrieb des Netzes (Abwicklung von Förderprogrammen, regelmäßige Wartung und Information im Fehlerfall) zu unterstützen sowie das Verknüpfen der Netz-Daten mit weiteren Informationen bspw. zum Standort zu ermöglichen.
Jetzt wo die Entwicklung zu einem brauchbaren Stand gekommen ist, fangen einige hier an zu mauern wo es nur geht und ziehen mich Stundenlang in eine Diskussion um einen Punkt der allen Testern hilft, stabil ist und jederzeit schadlos rückgängig gemacht werden kann?
Ich würde das nun nicht als Mauern bezeichnen sondern als gesunde Diskussion. Ich habe ja nie gesagt das ich die Firmware so nicht signieren würden sondern lediglich, dass ich das Lösung nicht Ideal finde.
Gruß
Johannes
Ich bin an zwei Dingen interessiert:
- Wie kann man Pakete über Firmware-Upgrade preserven (ganz unabhängig von
der Diskussion fände ich das Feature sehr praktisch)
- Entwickler die Bock haben einen Respondd2Netmon-Client zu evaluieren, zu
entwickeln und zu maintainen
Von meiner Seite aus steht der Integration des Node-Clients nichts im Weg. Zum Rest der Diskussion ist alles gesagt sodass ich mich darauf konzentriere den Rest zu testen und zu signieren.
Viele Grüße Clemens _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Signed
Von meinem iPhone gesendet
Am 31.05.2017 um 02:45 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20170502
- Gluon-Version: v2016.2.x
- Commit ID: 97f44c208b4dd23a63a0069963ca04fad899bf05
- Download: https://firmware.ffnw.de/20170530
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/242e63...97f44c
Folgende Gluon spezifischen Änderungen gab es unter anderen:
backport support for TP-Link TL-WR841ND v12
x86: backport more sysupgrade
Folgende Comunnity spezifischen Änderungen gab es: package repo:
hoodselector: Die Fehler werden jetzt in /tmp/hoodselector_error geloggt.
hoodselectorctl: Die uci Steuerung für den hoodselector ist in ein eigenes
Paket namens hoodselectorctl ausgelagert worden.
hoodselector: Enthält nun den Support um mit IEEE802.11s umzugehen. #86
hoodselector: Das scannen nach benachbarten Freifunk Routern ist nun beschleunigt
und kostet keine extra Airtime mehr.
hoodselector: Das filtern des eigenen WLANs wurde verbessert. #101
hoodselector: Die wifi Test Funktion wurde überarbeitet. Es werden nun alle
STA Netze vor dem testen der umliegenden Freifunk WLANSs entfernt. #103
- hoodselector: Im MOLWM wird nun sichergestellt das der Router-eigenen Eintrag
entfernt wird.
- hoodselector: Ein Fehler zur Position abfrage wurde behoben. Wenn keine uci
config zu der Router Position zur Verfügung stand, hat die tonumber func nil anstatt 0 returnd so das eine folge Prüfung fehlschlug. #100
- hoodselector: Im scanmode wird bei keinem erfolgreichen scan Ergebnis wieder
die defaulthood gesetzt. #99
- hoodselector: das suchen nach hoods aus dem hoodfile durch umliegende WLANs ist nicht
mehr von groß, klein Notation abhängig. #102
- geolocator: Der geolocator wurde so angepasst das die pkgs libwlocate und lwtrace
nicht mehr notwendig sind, damit konnten ~ 14kbyte speicher eingespart werden.
- hoods: Die default hood wurde um einen vpn peer erweitert. Die hood suedwest ist in landkreis-emsland umbenannt worden. Eine neue hood landkreis-cloppenburg ist hinzu gekommen. Eine neue hood grafschaft-bentheim ist hinzu gekommen. Eine neue hood bad-iburg ist hinzu gekommen.
siteconf repo:
IEEE802.11s kann jetzt optional im configMode eingeschaltet werden.
iw: package wurde erweitert um den Umgang mit IEEE802.11s zu ermöglichen.
libwlocate: package wurde entfernt.
lwtrace: package wurde entfernt.
netmon-node-client: ist in die Firmware aufgenommen worden. Das package soll
das neue Administrations- und Monitorring-Portal Netmon-gn mit Daten versorgen.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170410......
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170410......
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Entwicklung/Firmware_releaseprozess#Firmw...
Schöne Grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
signed. getestet auf 1043 v2 und cpe210 v1.0
Am 31.05.2017 um 02:45 schrieb Jan-Tarek Butt via Dev:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20170502
- Gluon-Version: v2016.2.x
- Commit ID: 97f44c208b4dd23a63a0069963ca04fad899bf05
- Download: https://firmware.ffnw.de/20170530
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/242e63...97f44c
Folgende Gluon spezifischen Änderungen gab es unter anderen:
backport support for TP-Link TL-WR841ND v12
x86: backport more sysupgrade
Folgende Comunnity spezifischen Änderungen gab es: package repo:
hoodselector: Die Fehler werden jetzt in /tmp/hoodselector_error geloggt.
hoodselectorctl: Die uci Steuerung für den hoodselector ist in ein eigenes Paket namens hoodselectorctl ausgelagert worden.
hoodselector: Enthält nun den Support um mit IEEE802.11s umzugehen. #86
hoodselector: Das scannen nach benachbarten Freifunk Routern ist nun beschleunigt und kostet keine extra Airtime mehr.
hoodselector: Das filtern des eigenen WLANs wurde verbessert. #101
hoodselector: Die wifi Test Funktion wurde überarbeitet. Es werden nun alle STA Netze vor dem testen der umliegenden Freifunk WLANSs entfernt. #103
hoodselector: Im MOLWM wird nun sichergestellt das der Router-eigenen Eintrag entfernt wird.
hoodselector: Ein Fehler zur Position abfrage wurde behoben. Wenn keine uci config zu der Router Position zur Verfügung stand, hat die tonumber func nil anstatt 0 returnd so das eine folge Prüfung fehlschlug. #100
hoodselector: Im scanmode wird bei keinem erfolgreichen scan Ergebnis wieder die defaulthood gesetzt. #99
hoodselector: das suchen nach hoods aus dem hoodfile durch umliegende WLANs ist nicht mehr von groß, klein Notation abhängig. #102
geolocator: Der geolocator wurde so angepasst das die pkgs libwlocate und lwtrace nicht mehr notwendig sind, damit konnten ~ 14kbyte speicher eingespart werden.
hoods: Die default hood wurde um einen vpn peer erweitert. Die hood suedwest ist in landkreis-emsland umbenannt worden. Eine neue hood landkreis-cloppenburg ist hinzu gekommen. Eine neue hood grafschaft-bentheim ist hinzu gekommen. Eine neue hood bad-iburg ist hinzu gekommen.
siteconf repo:
IEEE802.11s kann jetzt optional im configMode eingeschaltet werden.
iw: package wurde erweitert um den Umgang mit IEEE802.11s zu ermöglichen.
libwlocate: package wurde entfernt.
lwtrace: package wurde entfernt.
netmon-node-client: ist in die Firmware aufgenommen worden. Das package soll das neue Administrations- und Monitorring-Portal Netmon-gn mit Daten versorgen.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170410......
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170410......
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Entwicklung/Firmware_releaseprozess#Firmw...
Schöne Grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-
Clemens John -
Jan-Tarek Butt -
Johannes Rudolph -
lrnzo -
Malte Modler -
Simon Kurka -
Stefan -
Stefan Dunkel