[Berlin-wireless] inkompatibilität von olsr versionen und oder freifunk firmware versus kamikaze / war: ND-Cube routing faulty
mickey
mickey
Do Mai 14 10:51:13 CEST 2009
Hallo,
might-be-stoopid-comment: sollte olsrd nicht das erste in der Konfiguration
enthaltene Device als primäres nehmen?
Gruß,
M.
On Thu, 14 May 2009 10:16:49 +0200, Axel <axel at notmail.org> wrote:
> 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
Mehr Informationen über die Mailingliste Berlin