[Berlin-wireless] inkompatibilität von olsr versionen und oder freifunk firmware versus kamikaze / war: ND-Cube routing faulty

L. Aaron Kaplan aaron
Mo Mai 4 14:38:24 CEST 2009


On May 4, 2009, at 3:35 AM, 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 !!!
>
Hat da nicht Markus einen fix dafuer? Das problem klingt bekannt fuer  
mich.
Markus: hast du das nicht schon vor Monaten bemerkt und einen patch  
geschrieben?

/me fragt sich gerade, warum das im release nicht drinnen war oder ob  
wir was vergessen haben?

lg,
a.

> 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