Benutzer:Leo/Blog:2016 August 26 23:22:23 CEST - Versionsgeschichte

MathiasMahnke: /* LEDE */

2016-08-27T05:54:19Z

LEDE

← Nächstältere Version		Version vom 27. August 2016, 05:54 Uhr
Zeile 15:		Zeile 15:

	==== LEDE ====		==== LEDE ====
	Wir haben eine Prozedur gefunden, um mit unserer Build-Umgebung von OpenWrt auf LEDE zu wechseln. Sobald wir die stabile Opennet Firmware veröffentlcht haben, beginnen wir mit dem Umstieg auf LEDE. Dann kommt eine spannende Zeit auf uns zu. Unklar bleibt vor allem, wann es ein stabiles Release geben wird. In Anbetracht der Tatsachen, dass der LEDE trunk ohne Fehler heute kompiliert sind wir ganz zuversichtlich.		Wir haben eine Prozedur gefunden, um mit unserer Build-Umgebung von OpenWrt auf LEDE zu wechseln. Sobald wir die stabile Opennet Firmware veröffentlcht haben beginnen wir mit dem Umstieg auf LEDE. Dann kommt eine spannende Zeit auf uns zu. Unklar bleibt vor allem, wann es ein stabiles Release geben wird. In Anbetracht der Tatsachen, dass der LEDE trunk ohne Fehler heute kompiliert sind wir ganz zuversichtlich.

MathiasMahnke: /* LEDE */

2016-08-27T05:54:09Z

LEDE

← Nächstältere Version		Version vom 27. August 2016, 05:54 Uhr
Zeile 15:		Zeile 15:

	==== LEDE ====		==== LEDE ====
	Wir haben eine Prozedur gefunden, um mit unserer Build-Umgebung von ~~OpenWRT~~ auf LEDE zu wechseln. Sobald wir die stabile Opennet Firmware veröffentlcht haben, beginnen wir mit dem Umstieg auf LEDE. Dann kommt eine spannende Zeit auf uns zu. Unklar bleibt vor allem, wann es ein ~~stable~~ Release geben wird. In Anbetracht der Tatsachen, dass der LEDE trunk ohne Fehler heute kompiliert, sind wir ganz zuversichtlich.		Wir haben eine Prozedur gefunden, um mit unserer Build-Umgebung von OpenWrt auf LEDE zu wechseln. Sobald wir die stabile Opennet Firmware veröffentlcht haben, beginnen wir mit dem Umstieg auf LEDE. Dann kommt eine spannende Zeit auf uns zu. Unklar bleibt vor allem, wann es ein stabiles Release geben wird. In Anbetracht der Tatsachen, dass der LEDE trunk ohne Fehler heute kompiliert sind wir ganz zuversichtlich.

MathiasMahnke: /* Neue stabile Opennet Firmware v0.5.3 */

2016-08-27T05:53:35Z

Neue stabile Opennet Firmware v0.5.3

← Nächstältere Version		Version vom 27. August 2016, 05:53 Uhr
Zeile 8:		Zeile 8:

	==== Neue stabile Opennet Firmware v0.5.3 ====		==== Neue stabile Opennet Firmware v0.5.3 ====
	Wir arbeiten an der Fertigstellung der nächsten stabilen Firmware. Es wurden noch kleinere Änderungen gemacht. Diese müssen noch getestet werden. Danach steht dem Release nichts mehr im Weg.		Wir arbeiten an der Fertigstellung der nächsten stabilen Firmware. Es wurden noch kleinere Änderungen gemacht. Diese müssen noch getestet werden. Danach steht dem Release nichts mehr im Weg. Sehr erfreuliche Anpassungen haben sich noch ergeben:
			* Fehler bei on-monitoring ist identifiziert
			* Pakete werden zukünftig nach einem Firmwareupdate automatisch wieder installiert
			* in Sachen Analyse der Radar-Erkennung gibt es Fortschritte
			* OLSRv2 kommt weiter voran

	==== LEDE ====		==== LEDE ====

MathiasMahnke: /* Sipgate API */

2016-08-27T05:51:16Z

Sipgate API

← Nächstältere Version		Version vom 27. August 2016, 05:51 Uhr
Zeile 5:		Zeile 5:

	==== Sipgate API ====		==== Sipgate API ====
	Im Rahmen des Telefonausfalls, gab es die Idee ein Monitoring einzurichten. Ziel ist, bei einem Nichterreichen des Telefons benachrichtigt zu werden. Sipgate bietet drei APIs an. Die Restful-API scheint sehr passend und einfach zu sein. Dort gibt es auch ein "GET /devices" (https://api.sipgate.com/doc/#!/devices/getDevices). Hier bekommt man alle angemeldeten Geräte zurück. Leider wird mit jedem GET nicht nur der Status der Geräte zurückgegeben, sondern auch ~~username/password~~ ~~credentials~~. Dies hat uns überrascht und ist von uns nicht gewollt. Bisher konnten wir keinerlei Weg finden den Status eines Gerätes abzufragen, ohne dass Passwörter immer mitgesendet werden.		Im Rahmen des Telefonausfalls, gab es die Idee ein Monitoring einzurichten. Ziel ist, bei einem Nichterreichen des Telefons benachrichtigt zu werden. Sipgate bietet drei APIs an. Die Restful-API scheint sehr passend und einfach zu sein. Dort gibt es auch ein "GET /devices" (https://api.sipgate.com/doc/#!/devices/getDevices). Hier bekommt man alle angemeldeten Geräte zurück. Leider wird mit jedem GET nicht nur der Status der Geräte zurückgegeben sondern auch die Zugangsdaten samt Passwort. Dies hat uns überrascht und ist von uns nicht gewollt. Bisher konnten wir keinerlei Weg finden den Status eines Gerätes abzufragen, ohne dass Passwörter immer mitgesendet werden.

	==== Neue stabile Opennet Firmware v0.5.3 ====		==== Neue stabile Opennet Firmware v0.5.3 ====

MathiasMahnke: /* Sipgate API */

2016-08-27T05:50:35Z

Sipgate API

← Nächstältere Version		Version vom 27. August 2016, 05:50 Uhr
Zeile 5:		Zeile 5:

	==== Sipgate API ====		==== Sipgate API ====
	Im Rahmen des Telefonausfalls, gab es die Idee, ein Monitoring einzurichten. Ziel ist, bei einem Nichterreichen des Telefons benachrichtigt zu werden. Sipgate bietet drei APIs an. Die Restful-API scheint sehr passend und einfach zu sein. Dort gibt es auch ein "GET /devices" (https://api.sipgate.com/doc/#!/devices/getDevices). Hier bekommt man alle angemeldeten Geräte zurück. Leider wird mit jedem GET nicht nur der Status der Geräte zurückgegeben, sondern auch username/password credentials. Dies hat uns überrascht und ist von uns nicht gewollt. Bisher konnten wir keinerlei Weg finden den Status eines Gerätes abzufragen, ohne dass Passwörter immer mitgesendet werden.		Im Rahmen des Telefonausfalls, gab es die Idee ein Monitoring einzurichten. Ziel ist, bei einem Nichterreichen des Telefons benachrichtigt zu werden. Sipgate bietet drei APIs an. Die Restful-API scheint sehr passend und einfach zu sein. Dort gibt es auch ein "GET /devices" (https://api.sipgate.com/doc/#!/devices/getDevices). Hier bekommt man alle angemeldeten Geräte zurück. Leider wird mit jedem GET nicht nur der Status der Geräte zurückgegeben, sondern auch username/password credentials. Dies hat uns überrascht und ist von uns nicht gewollt. Bisher konnten wir keinerlei Weg finden den Status eines Gerätes abzufragen, ohne dass Passwörter immer mitgesendet werden.

	==== Neue stabile Opennet Firmware v0.5.3 ====		==== Neue stabile Opennet Firmware v0.5.3 ====

MathiasMahnke: /* SIP Telefon im Vereinsraum */

2016-08-27T05:50:17Z

SIP Telefon im Vereinsraum

← Nächstältere Version		Version vom 27. August 2016, 05:50 Uhr
Zeile 2:		Zeile 2:

	==== SIP Telefon im Vereinsraum ====		==== SIP Telefon im Vereinsraum ====
	Das SIP Telefon im Vereinsraum war offline. Eine Fehleranalyse ergab, dass es DHCP Probleme gab. Nach einem Sichten der Verkabelung und logischen Netze, stellt sich AP1.23 als Problem heraus. Hier wurde als Maßnahme DHCP auf ~~bestimmten~~ ~~Interfaces~~ deaktiviert. Der AP hat eine etwas komplexere Konfiguration und einige Besonderheiten, welche Fehleranalysen sehr in die Länge zieht. Hier sollten wir den AP mit seinen Funktionen vereinfachen. Doku ist auf der AP Wiki Seite.		Das SIP Telefon im Vereinsraum war offline. Eine Fehleranalyse ergab, dass es DHCP Probleme gab. Nach einem Sichten der Verkabelung und logischen Netze, stellt sich [[AP1.23]] als Problem heraus. Hier wurde als Maßnahme DHCP auf dem Mesh-Interface deaktiviert. Der AP hat eine etwas komplexere Konfiguration und einige Besonderheiten, welche Fehleranalysen sehr in die Länge zieht. Hier sollten wir den AP sowie die Switchanbindung zum Hausnetz mit seinen Funktionen vereinfachen. Doku ist auf der AP Wiki Seite. Weitere Details folgen.

	==== Sipgate API ====		==== Sipgate API ====

Leo: Opennet Techniktreffen (26.08.2016)

2016-08-26T21:23:22Z

Opennet Techniktreffen (26.08.2016)

Neue Seite

=== Opennet Techniktreffen (26.08.2016) ===

==== SIP Telefon im Vereinsraum ====
Das SIP Telefon im Vereinsraum war offline. Eine Fehleranalyse ergab, dass es DHCP Probleme gab. Nach einem Sichten der Verkabelung und logischen Netze, stellt sich AP1.23 als Problem heraus. Hier wurde als Maßnahme DHCP auf bestimmten Interfaces deaktiviert. Der AP hat eine etwas komplexere Konfiguration und einige Besonderheiten, welche Fehleranalysen sehr in die Länge zieht. Hier sollten wir den AP mit seinen Funktionen vereinfachen. Doku ist auf der AP Wiki Seite.

==== Sipgate API ====
Im Rahmen des Telefonausfalls, gab es die Idee, ein Monitoring einzurichten. Ziel ist, bei einem Nichterreichen des Telefons benachrichtigt zu werden. Sipgate bietet drei APIs an. Die Restful-API scheint sehr passend und einfach zu sein. Dort gibt es auch ein "GET /devices" (https://api.sipgate.com/doc/#!/devices/getDevices). Hier bekommt man alle angemeldeten Geräte zurück. Leider wird mit jedem GET nicht nur der Status der Geräte zurückgegeben, sondern auch username/password credentials. Dies hat uns überrascht und ist von uns nicht gewollt. Bisher konnten wir keinerlei Weg finden den Status eines Gerätes abzufragen, ohne dass Passwörter immer mitgesendet werden.

==== Neue stabile Opennet Firmware v0.5.3 ====
Wir arbeiten an der Fertigstellung der nächsten stabilen Firmware. Es wurden noch kleinere Änderungen gemacht. Diese müssen noch getestet werden. Danach steht dem Release nichts mehr im Weg.

==== LEDE ====
Wir haben eine Prozedur gefunden, um mit unserer Build-Umgebung von OpenWRT auf LEDE zu wechseln. Sobald wir die stabile Opennet Firmware veröffentlcht haben, beginnen wir mit dem Umstieg auf LEDE. Dann kommt eine spannende Zeit auf uns zu. Unklar bleibt vor allem, wann es ein stable Release geben wird. In Anbetracht der Tatsachen, dass der LEDE trunk ohne Fehler heute kompiliert, sind wir ganz zuversichtlich.