[Berlin-wireless] inkompatibilität von olsr versionen und oder freifunk firmware versus kamikaze / war: ND-Cube routing faulty
Axel
axel
Do Mai 14 10:16:49 CEST 2009
Hi,
Im Anhang ist ein einfacher kamikaze patch der dafür sorgt, dass das main
interface immer auch das erste interface in der liste aller IPs eines
physikalischen interfaces ist (von ip Kommando vor den alias interfaces
aufgelistet wird).
Finde ich persöhnlich etwas übersichtlicher und vorallem umgeht es erstmal den
bug von olsr nicht die richtige IP zu benutzen. (Mit 8.09 rv14899 blieb die
olsr Routingliste leider immer noch lehr aber mit trunk 15572 läufts so).
lg.
axel
On Montag 04 Mai 2009, Axel wrote:
> Hallo,
>
> Habe gerade festgestellt, dass der olsrd im aktuellen openwrt trunk, aber
> auch der im kamikaze 8.09 release, nicht die IP des Interfaces benutzt für
> das er konfiguriert wurde !!!
>
> Es sieht so aus, als ob er die IP des ersten Interfaces benutzt was mir
> iproute2 für das physikalisches Interface ausspuckt. Auch wenn das ein
> aliasinterface ist mit einem ganz anderen label.
>
> Außerdem sendet er immer an die full broadcast addresse. Auch wenn die
> interface broadcast addresse anders konfiguriert ist.
>
>
> Im Anhang ein Beispiel:
>
> lg.
> axel
>
> _______ ________ __
>
> | |.-----.-----.-----.| | | |.----.| |_
> |
> | - || _ | -__| || | | || _|| _|
> |_______|| __|_____|__|__||________||__| |____|
> |
> |__| W I R E L E S S F R E E D O M
>
> KAMIKAZE (8.09, r14537) ----------------------------
> * 10 oz Vodka Shake well with ice and strain
> * 10 oz Triple sec mixture into 10 shot glasses.
> * 10 oz lime juice Salute!
> ---------------------------------------------------
> root at dirschauer:~# ip a show dev ath0
> 7: ath0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
> UNKNOWN
> link/ether 00:80:48:58:3f:1d brd ff:ff:ff:ff:ff:ff
> inet 103.130.30.200/8 brd 103.255.255.255 scope global ath0:1
> inet 10.0.30.200/24 brd 10.0.30.255 scope global ath0:2
> inet 104.130.30.200/8 brd 104.255.255.255 scope global ath0
> root at dirschauer:~# ps aux | grep olsr
> 1752 root 948 S olsrd -f /var/etc/olsrd.conf -nofork
> root at dirschauer:~# cat /var/etc/olsrd.conf
>
> DebugLevel 0
> IpVersion 4
> AllowNoInt yes
> Pollrate 0.025
> TcRedundancy 2
> MprCoverage 3
> LinkQualityFishEye 1
> LinkQualityWinSize 100
> LinkQualityDijkstraLimit 0 9.0
> LinkQualityLevel 2
> UseHysteresis no
> FIBMetric "flat"
> ClearScreen yes
> Willingness 3
> LinkQualityAging 0.1
> LinkQualityAlgorithm "etx_fpm"
>
> Interface "ath0" "ath1" "eth0"
> {
> Ip4Broadcast 255.255.255.255
> HelloInterval 2.0
> HelloValidityTime 40.0
> TcInterval 5.0
> TcValidityTime 100.0
> MidInterval 18.0
> MidValidityTime 324.0
> HnaInterval 18.0
> HnaValidityTime 108.0
> }
>
> root at dirschauer:~# tcpdump -i ath0 -n port 698
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes
> 12:51:03.838907 IP 103.130.30.200.698 > 255.255.255.255.698: OLSR, seq
> 0x0afc, length 80
> 12:51:04.467646 IP 104.130.30.246.698 > 255.255.255.255.698: OLSR, seq
> 0xc2e0, length 1432
> ^C
> 2 packets captured
> 2 packets received by filter
> 0 packets dropped by kernel
>
> root at dirschauer:~# ifconfig ath0
> ath0 Link encap:Ethernet HWaddr 00:80:48:58:3F:1D
> inet addr:104.130.30.200 Bcast:104.255.255.255 Mask:255.0.0.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:151218 errors:0 dropped:0 overruns:0 frame:0
> TX packets:120507 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:81219126 (77.4 MiB) TX bytes:13315842 (12.6 MiB)
>
>
> root at dirschauer:~# tcpdump -i ath0 -ne port 698
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes
> 12:51:31.276634 00:02:6f:4a:31:f6 > ff:ff:ff:ff:ff:ff, ethertype IPv4
> (0x0800), length 1142: 104.130.30.246.698 > 255.255.255.255.698: OLSR, seq
> 0xc305, length 1100
> 12:51:32.118098 00:02:6f:4a:31:f6 > ff:ff:ff:ff:ff:ff, ethertype IPv4
> (0x0800), length 1510: 104.130.30.246.698 > 255.255.255.255.698: OLSR, seq
> 0xc306, length 1468
> 12:51:32.356023 00:02:6f:4a:31:f6 > ff:ff:ff:ff:ff:ff, ethertype IPv4
> (0x0800), length 202: 104.130.30.246.698 > 255.255.255.255.698: OLSR, seq
> 0xc307, length 160
> 12:51:32.446003 00:02:6f:4a:31:f6 > ff:ff:ff:ff:ff:ff, ethertype IPv4
> (0x0800), length 122: 104.130.30.246.698 > 255.255.255.255.698: OLSR, seq
> 0xc308, length 80
> 12:51:32.548899 00:80:48:58:3f:1d > ff:ff:ff:ff:ff:ff, ethertype IPv4
> (0x0800), length 122: 103.130.30.200.698 > 255.255.255.255.698: OLSR, seq
> 0x0b0c, length 80
> ^C
> 5 packets captured
> 5 packets received by filter
> 0 packets dropped by kernel
>
> On Samstag 02 Mai 2009, Henning Rogge wrote:
> > On Samstag 02 Mai 2009 19:55:45 ulf kypke wrote:
> > > hi,
> > > immer noch ode immer wieder gibt es einen furchtbaren
> > > inkompatibilitäts fuckup zwischen den klassischen freifunk firmware
> > > wrt kisten (und ein paar alte cubes) und neueren kamikaze systemen,
> > > meisst atheros und oder alix (x86). es hat nix mit dem wifi ansich zu
> > > tun sondern mit dem routing und ich bin der meinung, dass es primär
> > > immer noch um das gleiche problem geht, welches ich vor mehr als
> > > einem jahr schon einmal angesprochen habe und seither mehrfach
> > > diskutiert wurde, auch hier auf der liste.
> > > für mich stellt sich einfach nur die frage, wie gehen wir mir den
> > > ganzen freifunkfirmware basierten kisten um, die überall in der
> > > landschaft hängen?
> > > was macht leipzig warum taucht das da nicht so gravierend auf? hat es
> > > mehr was mit iptables zu tun, als mit olsr?
> > > das ganze wurde ja erst wirklich bemerkt, als mehr und mehr das "nat"
> > > ausgeschaltet wurde weil eben nicht mehr einfach ein 192.168.1.0/24 am
> > > lan existiert sondern ein kleines 104rer netz "geroutet" wurde. es
> > > ging letztens das thema autoupdate rum.... mal ehrlich white russian
> > > ist eol, für kamikaze gibt es "freifunk skins" und warum kann man
> > > nicht endlich mal den "alten scheiss" klar schiff machen und schaun ob
> > > ein solches sw update was bingt.
> > > defacto ist es so, dass wir immer mal wieder setups haben, die >3 hops
> > > bei einer mischung zwischen white russian kamikaze auf der strecke
> > > einfach routen verschlucken.
> > > vor ein paar tagen endete eine solche route irgenwo am alex auf einem
> > > wrt mit version 1.6.0. diese kisten sind es die uns einfach nur
> > > instabilität ins netz bringen scharze löcher erzeugen und dann dau
> > > kommt und (mit recht) nachfragt was dieser ganze qutasch soll wenns eh
> > > nicht mit deinem nachbarn funkt.
> >
> > Wäre auch eine gute Gelegenheit mal die TC-Timings in Berlin in Ordnung
> > zu bringen...
> >
> > Henning
>
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20090514/6bf15544/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : maintainPrimaryInterfaceOnTop.patch
Dateityp : text/x-patch
Dateigröße : 474 bytes
Beschreibung: nicht verfügbar
URL : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20090514/6bf15544/attachment.bin>
Mehr Informationen über die Mailingliste Berlin