Ap46rene: weitere Anmerkungen ...

2005-12-09T18:56:15Z

weitere Anmerkungen ...

Sh01: some comments

2005-12-02T13:48:33Z

some comments

Neue Seite

*Andere Gateways sind von Nutzern zur Verfügung gestelt (N-GWs)und werden ohne OpenVPN betrieben.
** Warum die Allaussage? Ich halte es durchaus für sinnvoll, auch auf diesen gateways openvpn anzubieten. Das ist dann natürlich eine Entscheidung der jeweiligen Betreiber.

*Eine Auswahl 'nicht-optimaler' GWs ist imho. nicht RFC-konform (vgl. [http://ietf.org/rfc/rfc3626.txt rfc3626.txt], bes. Abschnitt 12). Daher sollte die 'whitelist' auf O-GWs beschränkt werden. Eine Blacklist halte ich daher auch bedenklich, die Option keine N-GWs zu nutzen sollte ausreichen.
** Welcher Teil von Abschnitt 12 genau? Es geht nicht um Änderungen am eigentlichten layer-3 routing, sondern darum die Informationen zur Konfiguration eines bestimmten userspace-programms (openvpn) zu nutzen. RFC-konformität ist darauf afaik nicht anwendbar. Des Weiteren stellt die Nutzung der linkquality-modifications afaik bereits eine direkte Verletzung des angesprochenen RFCs dar.
** border-gateway wechsel zerlegen aufgrund unserer Nutzung von NAT zuverlässig bestehende Verbindungen des überwiegenden Teils üblicher Protokolle - u.a. von allen, die auf TCP basieren. Nutzer sollten imho grundsätzlich die Option haben, derartie Vorfälle zu vermeiden.
** [Color]lists von HNA-using gateways sind aus den angesprochenen Gründen schwierig technisch zu realisieren. Ich halte es auch nicht für notwendig, zu versuchen, dafür trotzdem detaillierte Filtermöglichkeiten anzubieten.
** Die zu nutzenden Openvpn-gateways, welcher Art auch immer, sollten zumindest optionell vollständig manuell konfigurierbar sein. Es wäre auch kein grosser Aufwand, diesen Teil zu implementieren. Filter für die automatische Auswahl wären auch nett, sind aber imho eher weniger kritisch.
* einfach und hässlich: parsen von httpinfo-plugin-output
**Html-output zu parsen um an die route infos zu kommen wäre wirklich ungünstig. Wenn es nur um die Topologie-infos aus Sicht von olsrd geht, wäre der Output von der von mir zu graphing-zwecken angepassten Version des dotdraw olsrd-plugins (svn://svn.opennet-initiative.de/on_networkstatus/trunk/olsrd_dd_ti/) wahrscheinlich einfacher zu parsen. Es wird für die zusätzliche Funktionalität aber wahrscheinlich ohnehin günstiger, ein neues plugin zu schreiben.
--sh01, 2005-12-02 14:48 CET

← Nächstältere Version		Version vom 9. Dezember 2005, 18:56 Uhr
Zeile 1:		Zeile 1:
	*Andere Gateways sind von Nutzern zur Verfügung gestelt (N-GWs)und werden ohne OpenVPN betrieben.		*Andere Gateways sind von Nutzern zur Verfügung gestelt (N-GWs)und werden ohne OpenVPN betrieben.
	** Warum die Allaussage? Ich halte es durchaus für sinnvoll, auch auf diesen gateways openvpn anzubieten. Das ist dann natürlich eine Entscheidung der jeweiligen Betreiber.		** Warum die Allaussage? Ich halte es durchaus für sinnvoll, auch auf diesen gateways openvpn anzubieten. Das ist dann natürlich eine Entscheidung der jeweiligen Betreiber.
			*** Ok, war eher als begriffliche Definition gedacht, i.S.v. N-GWs weren mit OpenVPN zu O-GWs. Aber ist durch die aktuellen Vereinsdiskussionen hinfällig, es soll keine N-GWs geben ;(

	*Eine Auswahl 'nicht-optimaler' GWs ist imho. nicht RFC-konform (vgl. [http://ietf.org/rfc/rfc3626.txt rfc3626.txt], bes. Abschnitt 12). Daher sollte die 'whitelist' auf O-GWs beschränkt werden. Eine Blacklist halte ich daher auch bedenklich, die Option keine N-GWs zu nutzen sollte ausreichen.		*Eine Auswahl 'nicht-optimaler' GWs ist imho. nicht RFC-konform (vgl. [http://ietf.org/rfc/rfc3626.txt rfc3626.txt], bes. Abschnitt 12). Daher sollte die 'whitelist' auf O-GWs beschränkt werden. Eine Blacklist halte ich daher auch bedenklich, die Option keine N-GWs zu nutzen sollte ausreichen.
	** Welcher Teil von Abschnitt 12 genau? Es geht nicht um Änderungen am eigentlichten layer-3 routing, sondern darum die Informationen zur Konfiguration eines bestimmten userspace-programms (openvpn) zu nutzen. RFC-konformität ist darauf afaik nicht anwendbar. Des Weiteren stellt die Nutzung der linkquality-modifications afaik bereits eine direkte Verletzung des angesprochenen RFCs dar.		** Welcher Teil von Abschnitt 12 genau? Es geht nicht um Änderungen am eigentlichten layer-3 routing, sondern darum die Informationen zur Konfiguration eines bestimmten userspace-programms (openvpn) zu nutzen. RFC-konformität ist darauf afaik nicht anwendbar. Des Weiteren stellt die Nutzung der linkquality-modifications afaik bereits eine direkte Verletzung des angesprochenen RFCs dar.
			*** Ich hatte Bedenken wegen der Auswahl nicht-optimaler Gateways als Default Gateways, da Nachbar-APs dann ja mit einer anderen Einstellung durchaus loops Erzeugen könnten. Die Unterscheidung OpenVPN-Tunnel vs. DefaultGateway ist mir erst später bewusst geworden, dadurch kein Problem.

	** border-gateway wechsel zerlegen aufgrund unserer Nutzung von NAT zuverlässig bestehende Verbindungen des überwiegenden Teils üblicher Protokolle - u.a. von allen, die auf TCP basieren. Nutzer sollten imho grundsätzlich die Option haben, derartie Vorfälle zu vermeiden.		** border-gateway wechsel zerlegen aufgrund unserer Nutzung von NAT zuverlässig bestehende Verbindungen des überwiegenden Teils üblicher Protokolle - u.a. von allen, die auf TCP basieren. Nutzer sollten imho grundsätzlich die Option haben, derartie Vorfälle zu vermeiden.
			*** ack.
	** [Color]lists von HNA-using gateways sind aus den angesprochenen Gründen schwierig technisch zu realisieren. Ich halte es auch nicht für notwendig, zu versuchen, dafür trotzdem detaillierte Filtermöglichkeiten anzubieten.		** [Color]lists von HNA-using gateways sind aus den angesprochenen Gründen schwierig technisch zu realisieren. Ich halte es auch nicht für notwendig, zu versuchen, dafür trotzdem detaillierte Filtermöglichkeiten anzubieten.
	** Die zu nutzenden Openvpn-gateways, welcher Art auch immer, sollten zumindest optionell vollständig manuell konfigurierbar sein. Es wäre auch kein grosser Aufwand, diesen Teil zu implementieren. Filter für die automatische Auswahl wären auch nett, sind aber imho eher weniger kritisch.		** Die zu nutzenden Openvpn-gateways, welcher Art auch immer, sollten zumindest optionell vollständig manuell konfigurierbar sein. Es wäre auch kein grosser Aufwand, diesen Teil zu implementieren. Filter für die automatische Auswahl wären auch nett, sind aber imho eher weniger kritisch.
			*** Ist wohl die einfachste Lösung, ne Liste von Adressen, die per Hand eingegeben werden kann
	* einfach und hässlich: parsen von httpinfo-plugin-output		* einfach und hässlich: parsen von httpinfo-plugin-output
	**Html-output zu parsen um an die route infos zu kommen wäre wirklich ungünstig. Wenn es nur um die Topologie-infos aus Sicht von olsrd geht, wäre der Output von der von mir zu graphing-zwecken angepassten Version des dotdraw olsrd-plugins (svn://svn.opennet-initiative.de/on_networkstatus/trunk/olsrd_dd_ti/) wahrscheinlich einfacher zu parsen. Es wird für die zusätzliche Funktionalität aber wahrscheinlich ohnehin günstiger, ein neues plugin zu schreiben.		**Html-output zu parsen um an die route infos zu kommen wäre wirklich ungünstig. Wenn es nur um die Topologie-infos aus Sicht von olsrd geht, wäre der Output von der von mir zu graphing-zwecken angepassten Version des dotdraw olsrd-plugins (svn://svn.opennet-initiative.de/on_networkstatus/trunk/olsrd_dd_ti/) wahrscheinlich einfacher zu parsen. Es wird für die zusätzliche Funktionalität aber wahrscheinlich ohnehin günstiger, ein neues plugin zu schreiben.

Diskussion:Opennet Firmware Projekt Gatewaywahl - Versionsgeschichte

Ap46rene: weitere Anmerkungen ...

Sh01: some comments