[Berlin-wireless] inkompatibilität von olsr versionen und oder freifunk firmware versus kamikaze / war: ND-Cube routing faulty
Axel
axel
Mo Mai 4 03:35:17 CEST 2009
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
Mehr Informationen über die Mailingliste Berlin