Mail1
Die Default-Route in Table 254 (Iproute2-speak: Table main) wird ja wie
immer mit "route -n" bzw. "ip r" angezeigt. Diese Tabelle ist fuer alle.
Kann mit den alten "iffonfig" und "route" Befehlen verwaltet werden . Da
irgendwie jeder die Befehlsfolge fuer "route add default gw a.b.c.d" bzw.
"ip r add default via a.b.c.d" kennt und die Default-Route eine
"Gemeinschafts-Ressource" ist, hab' ich das dyngwplain und das
Policy-Routing eingefuehrt.
Folgende Aussagen gelten fuer die Freifunk-Firmware, was Selberbastler alles
so treiben steht auf einem anderem Blatt - manche koennen's - manche eben
nicht.
* Das dyngwplain announced HNA 0/0, sobald eine Default-Route in Tablle 254
mit Metrik 0 vorhanden ist. Genau dieser Zusammenhang. Sonst kein anderer.
Darum "plain"..
* Nebenbei gibt's einen Cron-Job /usr/sbin/cron.minutely, der prueft mit
"traceroute", ob die manuell gesetzte Default-Route ueberhaupt funktioniert.
Falls nicht -> Default-Route weg -> kein HNA 0/0 -> anderes Gateway -> alle
Gluecklich. Der Test dauert Minuten. Dafuer kann man Traceroute nicht so
einfach "besch**ssen".
* Damit ein Node mit traceroute selber weiter testen kann, ob die vormals
kaputte Default-Route evnt. wieder hochkommt, wird diese im Fehlerfall in
eine Hintergrund-Default-Route gewandelt, die *nur fuer das Geraet selbst*
gilt. Guckt man mit "ip rule ls" nach Regeln. Die Routen kann man uebrigens
mit "ip ro ls table 252" anzeigen.
* Jetzt gab's oefter den Fall "Mein Gateway nur fuer mich, will aber
trotzdem Freifunken aber die anderen nicht nerven". Darum hab' ich an die
Deaktivierung des dyngwplain ein erweitertes Policy-Routing geklemmt. Kein
dyngwplain -> alle OLSR-Routen (inkl. der OLSR-Default-Route gueltig fuer
alle anderen) in Tabelle 111. Das dyngwplain wieder aktivieren -> alles wie
vorher in Tabelle 254 ("main").
* Die Tabellen-Nummern stehen in /etc/iproute2/rt_tables. 111 == olsr, 254
== main, 252 == dyngw.
* Das kann man alles auskommenterien. Beliebt bei Leuten, die als
Internet-Zugang einen "UDP-ist-bei-mir-nicht" Firewall haben und/oder
einfach die Konfig nicht im Griff. Aber im Regelfall hilft es, schwarze
Loecher (aka nicht-funktionierende Internet-Zugaenge) zu vermeiden. Ein
Gateway ohne UDP ist eine Krankheit IMO - kann man gleich einen Zwangsproxy
machen.
* Ach und wer schon immer neugierig war: "ip ro ls table local" ist noch
interessant. Das sind die durch IP/Netzmaske direkt den Interfaces
zugeordneten "internen Routing-Eintraege" mit absoluter Prio.
Weiter gehts unter "LARTC" (-> google).
HTH,
// Sven-Ola
Mail3
Hi Bastian,
yep. Hab' ich gelesen. Wuerde da ein Ack senden. Achso: ab sofort gibts FFF 1.5.22 (Stunde warten bis Sync). Da gibts kein ff_dyngw mehr. Das nennt sich jetzt "ff_policyrt" und ist per default=OFF. Das dyngw-Plugin ist irgendwie unbeliebt aber notwendig <ggg>
Falls es doch jemand einschaltet (also Pol ein == Dyngw aus, z.B. um ein
Zebra zum fliegen zu bringen oder so), dann klappts jetzt auch ohne
statische Default-Route. Dann wird naemlich einfach wieder die
Freifunk-Defroute genommen -> gespiegelt in Table "default". Gibt halt 3
Default-Routen (eine in table olsr, eine in table main und noch eine in
default) aber Linux stoert das ja nicht weiter. Die notwendigen
"throw"-Routen werden jetzt auch unter Status/Routen angezeigt - dann sollte
es klar sein.
Yep, und es funzt wirklich. Ich lade naemlich gerade die Version genau ueber
sowat hoch. Bin also recht sicher. Bugs + Reports wie immer willkommen...
// Sven-Ola
""Bastian Bittorf"" <bittorf@bluebottle.com> schrieb im Newsbeitrag news:op.tvn0wptrzjqwbn@box...
- Schon immer konnte man auch _ohne_ OLSR ueber ein Gateway surfen, bei
dem man direkt dranhaengt (just-one-hop-does-not-require-OLSR). Bin mir
noch nicht sicher ob ich das (per default?) wirklich verhindern sollte.
besser nicht verhindern per default.
- Und noch 'ne kleine Gemeinheit evnt. Mit einem gefakten
Ping-me-Back-Paket (Ziel-MAC == Nachbar, aber Ziel IP == Selbst) gucken,
ob Firewalling = Aus und Forwarding = Ein ist. Falls nicht -> ignoriere
OLSR-Pakete von solchen Nachbarn generell. Fuer unsere
GUI-Makes-it-all-easy-Freunde. Bin auch noch nicht sicher.
faende ich sinnvoll. Die frage ist nur: wie oft pruefen? cron.minutely?
- Und weil's so schoen war: Wie waer's mit einem "Received OLSR
Broadcast automatically refreshes MAC/Arp Entries"? Dann gibts nicht
wichtig. fehlt absolut.
bye,Bastian.
_______________________________________________
WLANware mailing list
WLANware@freifunk.net
Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlanware
Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung unter http://freifunk.net/mailinglisten
Mail2
a. Das soll so sein. Ich soillte es wirklich in den OLSR einbauen - dann muss man selbst kompileren um es auszuschalten. Aber ich werde besser den Schalter umbenennen. "ff_dyngw" -> "ff_policyrt" oder so. Dann ist es evnt einfacher.
Du verlaesst dich auf die Antzeige von "ip ls" - die zeigt aber nur die "Main" table. Guck' mal in die Web-UI unter "Status". Da sind alle Routen angezeigt. Und es funktoniert, mach doch mal Traceroute oder ping google.de
Noch'n Nachsatz. Was tatsaechlich noch fehlt ist eine zusaetzliche Default-Route in der Tabelle "Default". Die ist im Moment noch leer. Warum? Wenn man Policy Ruoting aktiviert, und eben *keine* manuelle Route setzt. Dann soll's ja sicher wieder ueber Freifunk gehen. Funktion waere etwa so:
Anderer Freifunk-Benutzer :
Genrell Inet via table olsr (111)
Selber
Inet via table main falls manuelle defaultroute
Falls keine manuelle defaultroute, dann Inet via table default
Die Table "default" ist im Moment leer. Wird per default *nach* main abgearbeitet. Wenn eine Table keine Default-Route hat gibt es eine implizte "Throw-Route" --> naechste Rule -> naechste Table.