[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