Diskussion:Opennet Firmware Projekt Gatewaywahl

• 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. 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