Opennet Firmware/Meta
Aus Opennet
Inhaltsverzeichnis |
Firmware-Paket
Bugs / Wünsche / ToDo
- DNSMasq Syslog Enhancement: Im Syslog erscheint fast jede Minute so ein Eintrag (Nach ca. 2 - 6h ist das Syslog dann voll und man kann keine wichtigen Fehlermeldungen mehr sehen Oconnor 15:00, 19. Apr 2007):
Apr 19 13:08:05 (none) kern.info dnsmasq[671]: reading /tmp/resolv.conf Apr 19 13:08:05 (none) kern.info dnsmasq[671]: using nameserver 192.168.0.251#53 Apr 19 13:08:05 (none) kern.info dnsmasq[671]: using nameserver 192.168.0.247#53 Apr 19 13:08:05 (none) kern.info dnsmasq[671]: using nameserver 192.168.0.250#53 Apr 19 13:08:05 (none) kern.info dnsmasq[671]: using nameserver 192.168.0.244#53 Apr 19 13:08:05 (none) kern.info dnsmasq[671]: using nameserver 192.168.0.254#53
- UGW Blackhole Bug: Freie Inhalte (HNA Host-/Netzrouten) nicht ueber UGWs erreichbar, vermutlich Problem im Policy Routing Table 4 --Mathias 21:38, 27. Jun 2007 (CEST)
- UGW OLSR-LAN TAP-SNAT Bug: SNAT-Regel auf tap-Interfaces wird auch gesetzt, falls LAN-Interface im OLSR Betrieb (Mesh-IP), muesste in /etc/openvpn/opennet_ugw/opennet_ugw_up.sh geloest werden; aktuell gibt es dadurch ungewollte NAT-Translations --Mathias 21:40, 27. Jun 2007 (CEST)
- RTS/Fraq Enhancement: RTS im Ad Hoc Mesh sollte generell abgeschaltet werden, dies sinnvollerweise beim Update "erzwingen"; Fraq-Schwelle ebenfalls vereinheitlichen oder User ueberlassen? Sinnvolle Werte (256, 512, >1500/aus)? --Mathias 08:59, 28. Jun 2007 (CEST)
- UGW User-Tunnel via WAN Bug: UGW ohne Wifi-Anbindung zum Opennet hat ein regelmäßiges Routingproblem unter noch unbekannten Umständen. Es baut sich ein User-Tunnel via Internet auf (z.B. zu titan), UGW-OpenVPN Tunnel sind anschliessend unerreichbar. Tritt nach ca. einem Tag Laufzeit auf. Eventuell bei einem PPPoE Reset? --Mathias 06:53, 13. Sep 2007 (CEST)
- Workaround: *Kein* User-Tunnel auf UGWs ohne Wifi-Anbindung ans Opennet Mesh einrichten. --Mathias 06:53, 13. Sep 2007 (CEST)
- use-backports Problem: Die URL fuer /etc/ipkg.conf wird aus $_version ermittelt. Die Zeichen müssen in Kleinbuchstaben umgewandelt werden, da die Pfadangaben case-sensitiv und der Repositorypfad in Kleinbuchstaben bei OpenWrt angeboten wird. --Mathias
- Rene hat v0.3 released, Problem behoben.
- WAN DHCP DNS Problem: Benutzt man am WAN Port DHCP als Internet Zugang und hat keinen User-Tunnel eingerichtet, werden die DNS Server vom DHCP Request nicht verwendet. Dabei ist es unerheblich, welche DNS Konfiguration per Webinterface für DNS eingestellt wurden. Aktuell kann nur mit statisch eingetragenen DNS Servern gearbeitet werden? Anscheinend fehlt /tmp/resolv.conf (als Link auf /tmp/resolv.conf.auto)? --Mathias 20:43, 24. Sep 2007 (CEST)
erledigt in 0.11-13
- bugfix: der Ap blockiert, wenn mehr als eine Route zu einem Gateway existiert.
- script cron.minutely_ongateway angepasst.
erledigt in 0.11-12
- Aenderung der Behandlung des Usergateway-Traffics, nun ist Wechsel der Usergateway-APs im laufenden Beitrieb möglich.
- Aufbau zweier paralleler Usergateway-Tunnel zu nagare.on-i.de und erina.on-i.de zur Erhöhung der Ausfallsicherheit.
- tcp-westwood aktiviert
- Conntrack Table Flooding unterbunden: https://dev.openwrt.org/changeset/6229
- minütliche Prüfung auf BSSID wieder integriert
- Automatische Sortierung von Gateways abhängig von AP-adresse (gerade/ungerade). Verteilung des Traffics zwischen nagare und erina.
- FORWARDING fuer pakete aus privaten Subnetzen am WAN-Port nach 192.168.0.0/16 integriert.
erledigt in 0.11-11
- Anpassung für whiterussian release 0.9
- in 0.9 wurde /usr/ipcalc in /usr/ipcalc.sh umbenannt. Symbolischer link gesetzt.
- Firewall unterbindet Zugriff auf lokale WAN-IP vom LAN aus.
- angepasst, geht nur wenn WAN-IP vor /etc/init.d/S45firewall feststeht
erledigt in 0.11-10
Änderungen
- Hinweise bei Aktivierung von LANOLSR/WANOLSR auf Statusseite integriert.
- prüfe ob WAN-Device vom Opennent benutzte Adressen per DHCP erhält, deaktiviere WAN im worst-case.
- Versionsverwaltung zentralisiert, Versionsnummer wird nun nur noch in /CONTROLS/controls gespeichert.
- einige Bezeichnungen im Userinterface ;) eingedeutscht ;)
- Webseiten html-konform gemacht (grossteils)
- Interface für An/Abschalten einiger Debug-Optionen ergänzt
- wird noch nicht übergreifend genutzt
- Vereinheitlichung des Portmappings, dadurch freie Einstellung des Tunnel-Mappings möglich
- aktiviere DijkstraLimit in OLSRD als default
- veraltete Version von olsrd in <=RC5-ON2 wird aktualisiert
- HINWEIS: trotz gleicher Versionsnummer (0.4.10-1) sind Versionen unterschiedlich
- OLSRD-Optionen von Freifunk übernommen
- on_ugw NVRAM Variable eingeführt
- ermöglicht später Wahl des UGW VPN-Servers / noch inkonsistent, 192.168.0.251 wird noch fix benutzt
- Pakete für fixedbssid-parts entsprechend Originalpaketen erstellt.
- opennet-wificonf_0.1_mipsel.ipk ersetzt wificonf*.ipk
- opennet-kmod-brcm-wl_0.1_mipsel.ipk ersetzt kmod-brcm-wl*.ipk
- opennet-kmod-wlcompat_0.1_mipsel.ipk ersetzt wlcompat*.ipk
- HINWEIS: für eine Installation von 0.11-9pre10 ist eine Aktualisierung der Paketliste notwendig.
- Status-Seite enthält nun Infos über OLSR Nachbarn
- Bessere Prüfung ob User-Tunnel an UserGateways doppelt getunnel werden. Sollte nun erledigt sein.
- Code gereinigt, hoffentlich ;)
Anpassungen für OpenWRT RC6
- Zuweisung einer IP an WAN-devices über pppoe bzw. DHCP setzt möglicherweise default IP und verbreitet diese über OLSR
- Script /usr/sbin/check_WAN.sh prüft auf WAN-default route, entfernt diese und setzt policy-routing bei Bedarf
- pppd startet nicht neu bei Unterbrechung der WAN-Verbindung
- added to /etc/ppp/options: lcp-echo-interval 3 lcp-echo-failure 5
- OpenWRT firmware upgrade page moved from /www/cgi-bin/webif/upgrade.sh to system-upgrade.sh
- OpenWRT iptables startscript moved from /etc/init.d/S45firewall to S35firewall
- hack to let RC6 work on Buffalo routers
Bugfixes
- OLSR Kopplung ueber LAN bringt VPN-Fehler
- Firewall geändert
- Tunnel-Verbindungsfreigabe bei Wireless-DHCP lässt keinen Zugang auf direkt geroutete Netze / freigegeben IP-Bereiche zu (Routing geht bekanntlich in diesem Fall nicht in den Tunnel)
- War so auch nicht gewollt. Kann nun durch nvram-variable on_wifidhcp_access_opennet (!= "") aktiviert werden
- lokale Unterverteilung (ohne olsr) wird täglich deaktiviert - sollte bei Breitbandanschluss aktiviert bleiben
- Deaktivierung kann nun durch nvram-variable on_wifidhcp_keep (!= "") abgeschaltet werden
- S60ntpclient changeonnte hängen bleiben wenn Server "Connection refused"
- script entsprechend geändert
- deaktivierung der Internetfeigabe zu 'sensibel'
- Deaktivierung abgeschalten. Tunnelpakete über nicht-WAN-ports werden gedroppt
- Passwort-Änderung über Opennet-Interface wurde durchgeführt, aber nicht bestätigt
erledigt in 0.11-9
(nur als 'testing' released) Hinweis: diese Version ist nicht im svn zu finden.
erledigt in 0.11-8fixedbssid
(Dateiname 0.11ipkg-9-fixedbssid) Hinweis: diese Version ist nicht im svn zu finden.
- Nutzung der Freifunk-Treiber für fixedbssid.
erledigt in 0.11-8
- test auf zwei tunnel schlägt fehl, startet mehrere tunnel
- was auf der console und im Test funktioniert, muss noch lange nicht im Betrieb gehen. Die Ausgabe von ps ist abhängig von der Breite der Console, eine Prüfung auf entsprechende commandozeilenparameter kann darum nur direkt über das /proc-device erfolgen.
erledigt in 0.11-7
(fehlerhaft, nicht länger released)
- WIFI-Verbindung bricht hin und wieder zusammen (AP88-Problem)
- cron.minutely prüft nun auf Existenz von device in /proc/net/wireless und startet bei Bedarf neu
- ungewollte zwei user-tunnel parallel
- zweiter Tunnel ist dann tun1, iptables-Einträge werden nicht mehr entfernt (down-script tun0 nach tun* ändern)
- generell aufbau eines zweiten User-Tunnels verhindern oder wenigstens regelmässig prüfen
- in cron.hourly wird nun darauf geprüft und 'repariert'
- Masquerade fuer LAN->WAN Traffic bei WANOLSR
- TODO: /etc/init.d/S45firewall anpassen -- bei "WANOLSR=1" hinzu "iptables -t nat -A POSTROUTING -o $WANDEV -j MASQUERADE -s $LANNET/$LANPRE", oder?
- erledigt in rev. 389
erledigt in 0.11-6
- conntrack verhinderte Übernahme der Aktualisierten Usergateway-SNAT-Rules.
- Firewall-Problem bei WAN mit OLSR - /etc/local.fw lässt nicht die Nutzung von WAN als OLSR-Device zu
- ToDo: WAN Umgebungsvariablen via netparam (nicht PPPDEV, gleich WANDEV) auslesen, dort WANOLSR prüfen; bei WANOLSR=1 alle ein- und ausgehende Pakete auf WAN erlauben
- ToDo: sinnvollen Namen fuer die Datei waehlen? Firewall ist zur Zeit auf /etc/init.d/S45firewall + /etc/firewall.user + /etc/local.fw verteilt. Mergen oder auf local.fw -> firewall.opennet anpassen?
- Portmapping 'Alle Internet-Ports an einen Zielrechner weiterleiten' ging nicht (mehr), behoben in svn rev. 367
- Infotext bei firmware-Aktualisierung verwechselt, statt "auomatische Sendeleistungsoptimierung" stand da was von "Einstellung auf 8bDi", behoben in svn rev. 368
erledigt in 0.11-5
- Namensgebung bei Usergateways unglücklich (dsl)
- Namen geändert in ugw (usergateway), dsl-sharing heisst jetzt internet-sharing in svn rev. 361
- Namensgebung bei lokaler Unterverteilung inkonsistent
- wifiaccess, localccess, on_wldhcp vereinheitlicht zu wifidhcp (nvram variablen on_wifidhcp) in svn rev. 356
- kann vom AP46 aus 192.168.1.11 über nagare-tunnel erreichen, von LAN-client an AP46 nicht, firewall prüfen.
- SNAT-rule für usergateway tunnel hat gefehlt, ergänzt in svn rev. 349
- ez-ipupdate falsch konfiguriert (?), dyndns hostname blocked for abuse
- Konfiguration wurde fehlerhaft erstellt, behoben in rev. 347
- chache-file befindet sich nun in /etc statt in /tmp, 'überlebt' daher einen Neustart
- dnsmasq wird bei Änderungen im dns neu gestartet, das ist nicht gut.
- Änderungen in den Nameservern werden nun immer in /tmp/resolv.conf durchgeführt (lan_dns, pppoe, user-gateways als dns)
- ohne /etc/init.d/S50dnsmasq ist /etc/resolv.conf ein link auf /tmp/resolv.conf
- wird dnsmasq gestartet, wird der link auf /var/etc/resolv.conf verlagert, dort ist localhost als nameserver eingetragen
- dnsmasq nutzt selbst /tmp/resolv.conf als Quelle der nameserver
- wenn dns durch pppoe-einwahl überschrieben wird, und während aktiver pppoe-Einwahl ein Wechsel der Gateways erfolgt, werden die gesicherten dns-einträge nicht angepasst. Dies kann dazu führen, dass bei Zusammenbrechen der WAN-Verbindung über opennet keine Namensauflösung mehr geht.
- Neighbour table overflow: Firmware_HowTo#Neighbour_table_overflow -- vllt. gibt es auch noch einen OpenWrt kompatiblen Weg die Werte zu setzen.
- keine spezifischer OpenWRT-Weg vorhanden, daher Lösung aus wiki in /etc/init.d/S40network übernommen (svn-revision 338)
- renice fehlt bei busybox. eigenes busybox daher notwendig.
- erledigt, nutze einzeln compiliertes renice-binary, svn-revision 336
- DSL-Verteilung geht aktuell nur bei pppoe-Einwahl, da policy-routing nur dann richtig gesetzt wird
- policy routing muss per Hand aktiviert werden, per ssh verbinden (default route über WAN existiert)
- ip_remote=$(route -n | awk '$8 == "'$WANDEV'" && $1 == "0.0.0.0" { print $2; exit }')
- ip route add throw $LANNET/$LANPRE table 4
- ip route add throw $WIFINET/$WIFIPRE table 4
- ip route add default via $ip_remote table 4
- OpenWrt-Interface für firmware-update wird nach Entfernen der Keys nicht wieder richtig hergestellt
- per ssh verbinden und link per Hand anlegen:
- ln -sf /rom/www/cgi-bin/webif/upgrade.sh /www/cgi-bin/webif/upgrade.sh
OpenWrt-Opennet-Version
Bugs / Wünsche / ToDo
- Wunsch: SSL Support für http (der lighthttpd kann das, gibts für RC5) > Sicherheit für Webadmin via WLAN JanC 23:26, 26. Sep 2006 (CEST)
- Rene meint: lighthttpd scheint (noch) nicht zu laufen auf RC6. Und wenn, warum nicht optional nachinstallieren?
- Alternative ist busybox-httpd + matrixtunnel, wird auch bereits so bei webif2 verwendet --Mathias
erledigt in 0.9on5
- integration von olsrd-cvs (benoetigt fuer UGW-Tunnel)
erledigt in 0.9on4
- Umstieg auf whiterussian release 0.9
erledigt in rc6on3
- Umstieg auf whiterussian RC6 ;)
- enthält nun komplettes firmware-paket, dadurch enorme Platzersparnis
erledigt in rc5on2
- Nameserver sinnvoll setzen
- script setzt nun nameserver anhand der nächsten Gateways
- NVRAM-Umgebung exakter prüfen: br0 auflösen, da bei Erstinstallation sonst z.T. Wifi mit LAN gebridged wird
- /proc/net/wireless bei Ausführung des Initialisierungsscriptes noch nicht gesetzt. Nutze nun 'iwconfig' zum Ermitteln des Wifi-Devices
