SvenOlaTuecke-Mail2007jul18-dyngw und cron.minutely iproute2: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
(mail) |
(→Mail1: +mail3) |
||
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
+ | ===Mail1=== | ||
<pre> | <pre> | ||
Die Default-Route in Table 254 (Iproute2-speak: Table main) wird ja wie | Die Default-Route in Table 254 (Iproute2-speak: Table main) wird ja wie | ||
Zeile 53: | Zeile 54: | ||
HTH, | HTH, | ||
// Sven-Ola | // Sven-Ola | ||
+ | </pre> | ||
+ | |||
+ | ===Mail3=== | ||
+ | <pre> | ||
+ | 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 | ||
+ | </pre> | ||
+ | |||
+ | ===Mail2=== | ||
+ | <pre> | ||
+ | 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. | ||
</pre> | </pre> |
Aktuelle Version vom 18. Juli 2007, 20:45 Uhr
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.