[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