[Berlin-wireless] inkompatibilität von olsr versionen und oder freifunk firmware versus kamikaze / war: ND-Cube routing faulty
Axel
axel
Fr Mai 15 14:49:07 CEST 2009
Hi,
On Donnerstag 14 Mai 2009, mickey wrote:
> Hallo,
>
> might-be-stoopid-comment: sollte olsrd nicht das erste in der Konfiguration
> enthaltene Device als primäres nehmen?
Ja das schon! Aber wenn olsrd für eth0 konfiguriert ist und das Interface eth0
die addresse 104.1.1.1 hat, dann sollte olsrd auf eth0 pakete versenden die
104.1.1.1 als source adresse haben.
Unabhängig davon ob es ein interface eth0:dhcp gibt mit der addresse
192.168.1.1 und dieses zufällig von dem iproute2 Kommando vor eth0 aufgelistet
wird.
grüße,
axel
>
> 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
>
> _______________________________________________
> 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/20090515/2195791e/attachment.html>
Mehr Informationen über die Mailingliste Berlin