From (spam-protected) Thu Dec 4 20:32:11 2008 From: (spam-protected) (Markus Kittenberger) Date: Thu, 4 Dec 2008 20:32:11 +0100 Subject: [Dump] gleiche ips auf mehreren interfaces und parallel links Message-ID: <4095b6c00812041132g145e509t350295c4e7eaae3c@mail.gmail.com> während das recyclen von ips ja bisher kaum probleme macht, bin ich nun erstmals real an die grenzen davon geststossen,.. (theoretisch hab ich schon mal drüber nachdgedacht, und es auch kurz getestet, und war zufrieden als ich dann zweimal die gleiche ip als nachbar im olsr sah,..) hat man z.B.: zwei router mit 2 interfaces mit jeweil der gleichen ip (z.B.: funk und osbridge am wan) und besteht 2 olsr links, dann wird der lq zwar auf allen interfaces noch interface spezifisch ermittelt, aber die nlq werte (aus den tcs) enthalten keinen interface info, und werden somit willkürlich verwendet was zu willkürlich schwankenden nlq und somit auch etx werten führt (sofern die beden strekcen nicht gleich gut sind) . ist nix überraschendes, und es wird auch nicht allzuoft auftreten, aber bei nem 5ghz link zwischen 2 gorssen knoten auf denen jeweils alle router am wan zusammen und die 5G-bridge an nem switch stecken, eingeltich gar nciht so schwer zu erreichen,.. weiss jetzt nciht ob ich davor warnen soll (am WAN die gleiche ip wie funkseitig zu verwenden, wenn einen osbridge am knoten vorhanden ist,..), denn würden die bridges nicht sogern auch noch zusammengeswitched, sondern ordentlich geroutet wäre es eh kaum ein problem, ... lg Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Sun Dec 7 19:28:51 2008 From: (spam-protected) (Markus Kittenberger) Date: Sun, 7 Dec 2008 19:28:51 +0100 Subject: [Dump] routing proto Message-ID: <4095b6c00812071028i5604df53t308cdd9c6adcaca8@mail.gmail.com> fyi hi hab heut nen olsr patch gemacht, mit dem dieser seine routen tagged,.. (sowie zebra, etc) (incl config file option dafür) mal schauen ob ich ihn in olsr 0.5.6r4 und auch fff 1.6.35 reinkrieg, dies in kürze geben wird er sollte auch nur noch getaggte routen wieder löschen,.. btw. mit unpatched olsr kansnt du auch so verhindern das er deine routen löscht indem eben du sie taggest ip route add ... proto 123 nichts anzugeben enstpricht proto = 3 = boot auch der olsrd schreibt momentan solche boot-routen,.. und diese routen dürfen/sollen von routing daemons eigentlich gelöscht werden, weil sie laut commetns in kernel sourcen, und mapages nur fürs booten gedacht sind,.. dies tut der oslrd aber auch nicht so wirklich er überschreibt nur mit der zeit versehentlich hostrouten, bzw routen die das gleiche announcen wie er auch... lg Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Sat Dec 13 18:44:16 2008 From: (spam-protected) (Harald Geyer) Date: Sat, 13 Dec 2008 18:44:16 +0100 Subject: [Dump] A Babel experiment at funkfeuer.at Message-ID: Hi Juliusz! Unfortunately your talk last summer didn't lead to any practical experimentation that I'm aware of. This is an attempt to get the ball rolling again... I want to build an as big as possible babel network quite soon and I'd like to get your input and perhaps also your help. After discussing babel with other people from funkfeuer I belive our main concern is if babel will scale to big networks with jumpy metric values - especially if the metric values are distributed over a wide range. So that's basically the setup I'm heading for ... Of course I also want to learn which tests would be useful to you for further work on babel and mesh routing. Unfortunately we can't deploy babel on enough routers in our network to have one big connected mesh, therefore I plan to connect several small babel blobs via tunnels. I think you have a babel network at your site too. I suggest that you participate in the experiment by setting up some tunnels between your network and funkfeuer. Thus you would have direct access to the experiment while making the network even bigger. Perhaps you know of some other networks that could participate in the experiment too? There are some other constraints that we have to meet: Most of our devices lack any support for IPv6 so for the purpose of the experiment we are restricted to some subnet of 10.0.0.0/8 or some similiar setup. I would setup babel to write to it's own routing table and have some policy rules to select this table for the ip range we select but nothing else. The babel network would be used for monitoring traffic but not for any real traffic of funkfeuer. So what needs to be done? * Get some input on the goals and the setup of the experiement * Finalize the above * Make some packages at least for openwrt kamikaze and freifunkfirmware (used on most of our devices) which implement the above * deploy these packages on as many devices as possible * setup enough tunnels to make for an interessting topology Perhaps we should take this discussion to some public place... Harald From (spam-protected) Sun Dec 14 09:40:26 2008 From: (spam-protected) (Juliusz Chroboczek) Date: Sun, 14 Dec 2008 09:40:26 +0100 Subject: [Dump] A Babel experiment at funkfeuer.at In-Reply-To: (Harald Geyer's message of "Sat\, 13 Dec 2008 18\:44\:16 +0100") References: Message-ID: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> > Unfortunately your talk last summer didn't lead to any practical > experimentation that I'm aware of. Let's hope I have an excuse to go to Vienna again, I really enjoyed the city last time. > I want to build an as big as possible babel network quite soon and > I'd like to get your input and perhaps also your help. That'd be great. > After discussing babel with other people from funkfeuer I belive > our main concern is if babel will scale to big networks with > jumpy metric values - especially if the metric values are distributed > over a wide range. If it doesn't, we'll fix it. > Unfortunately we can't deploy babel on enough routers in our network > to have one big connected mesh, therefore I plan to connect several > small babel blobs via tunnels. I think you have a babel network at > your site too. I suggest that you participate in the experiment by > setting up some tunnels between your network and funkfeuer. Agreed. > There are some other constraints that we have to meet: Most of our > devices lack any support for IPv6 so for the purpose of the > experiment we are restricted to some subnet of 10.0.0.0/8 or some > similiar setup. Hmm... the current implementation of Babel requires IPv6 in the kernel. (It does not require global IPv6 addresses, but IPv6 must be compiled into the kernel.) > * Make some packages at least for openwrt kamikaze and freifunkfirmware > (used on most of our devices) which implement the above I finally got commit rights into OpenWRT, so expect a fixed Babel package really soon. > Perhaps we should take this discussion to some public place... You're very much welcome on babel-users at lists.alioth.debian.org. Juliusz From (spam-protected) Sun Dec 14 11:35:38 2008 From: (spam-protected) (Juliusz Chroboczek) Date: Sun, 14 Dec 2008 11:35:38 +0100 Subject: [Dump] A Babel experiment at funkfeuer.at In-Reply-To: (Harald Geyer's message of "Sat\, 13 Dec 2008 18\:44\:16 +0100") References: Message-ID: <7i1vwb9h8l.fsf@lanthane.pps.jussieu.fr> A few more comments. My experimental net uses the 192.168.4.0/24 range, so please don't use that. > would setup babel to write to it's own routing table and have some > policy rules to select this table for the ip range we select but nothing > else. What about simply making sure that Babel only installs route in this range? Assuming your prefix is 10.10.0.0/16, ust put something like this in /etc/babel.conf: in ip 10.10.0.0/16 allow in deny Juliusz From (spam-protected) Sun Dec 14 12:23:27 2008 From: (spam-protected) (Markus Kittenberger) Date: Sun, 14 Dec 2008 12:23:27 +0100 Subject: [Dump] A Babel experiment at funkfeuer.at In-Reply-To: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> References: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> Message-ID: <4095b6c00812140323m233e0fe9i2d99702f521642ab@mail.gmail.com> > Unfortunately we can't deploy babel on enough routers in our network > to have one big connected mesh, therefore I plan to connect several > small babel blobs via tunnels. I think you have a babel network at > your site too. I suggest that you participate in the experiment by > setting up some tunnels between your network and funkfeuer. ich denk ich kriegt z.B. mal alle "martin" router, wenn ich ihn danach frag, und babel die router nicht zum crashen bringen wird,.. problemetischer ist es wohl ipv6 in die fff zu kriegen, oder eben ein babel ohne ipv6 requirement p.s. die tunnel kosten natürlich wieder ein eck ram und cpu, aber wird sich schon ausgehen da ja wenig traffic über sie drübergehen wird,.. und wenn die ersten babel-netzchen gut laufen, denk ich danns recht schnell basieren, das babel auf 2/3++ der router in wien läuft,.. denn olsr performt mom ja recht weak,.. lg Markus Agreed. > > > There are some other constraints that we have to meet: Most of our > > devices lack any support for IPv6 so for the purpose of the > > experiment we are restricted to some subnet of 10.0.0.0/8 or some > > similiar setup. > > Hmm... the current implementation of Babel requires IPv6 in the kernel. > (It does not require global IPv6 addresses, but IPv6 must be compiled into > the kernel.) > > > * Make some packages at least for openwrt kamikaze and freifunkfirmware > > (used on most of our devices) which implement the above > > I finally got commit rights into OpenWRT, so expect a fixed Babel package > really soon. > > > Perhaps we should take this discussion to some public place... > > You're very much welcome on babel-users at lists.alioth.debian.org. > > Juliusz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Sun Dec 14 18:31:05 2008 From: (spam-protected) (Harald Geyer) Date: Sun, 14 Dec 2008 18:31:05 +0100 Subject: [Dump] A Babel experiment at funkfeuer.at In-Reply-To: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> References: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> Message-ID: > > Perhaps we should take this discussion to some public place... > > You're very much welcome on babel-users at lists.alioth.debian.org. Ok, Ccing that list ... > > I want to build an as big as possible babel network quite soon and > > I'd like to get your input and perhaps also your help. > > That'd be great. > > > After discussing babel with other people from funkfeuer I belive > > our main concern is if babel will scale to big networks with > > jumpy metric values - especially if the metric values are distributed > > over a wide range. > > If it doesn't, we'll fix it. :) > > Unfortunately we can't deploy babel on enough routers in our network > > to have one big connected mesh, therefore I plan to connect several > > small babel blobs via tunnels. I think you have a babel network at > > your site too. I suggest that you participate in the experiment by > > setting up some tunnels between your network and funkfeuer. > > Agreed. > > > There are some other constraints that we have to meet: Most of our > > devices lack any support for IPv6 so for the purpose of the > > experiment we are restricted to some subnet of 10.0.0.0/8 or some > > similiar setup. > > Hmm... the current implementation of Babel requires IPv6 in the kernel. > (It does not require global IPv6 addresses, but IPv6 must be compiled into > the kernel.) So on an openwrt router you need kmod_ipv6 installed ... we have such a setup (using 6to4 and radvd) on some experimental nodes and it works very well - even on freifunkfirmware based nodes, but of course it takes some RAM. With olsrd and ipv6 and babel and openvpn or vtun and $monitor_tool running on the same mesh node we will most likely hit the RAM limit. It sure can be done, but it might take some extra work to save the RAM elsewhere... OTOH if we need IPv6 support in the kernel anyway, then I don't see a reason not to do the whole experiment in IPv6 space - but perhaps I miss something. > > * Make some packages at least for openwrt kamikaze and freifunkfirmware > > (used on most of our devices) which implement the above > > I finally got commit rights into OpenWRT, so expect a fixed Babel package > really soon. That would be nice. Anyway I guess I'll compile a custom babel-0xff package with everything setup specifically for the experiment to make it easier for $random_node_admin to participate. > My experimental net uses the 192.168.4.0/24 range, so please don't use that. At Funkfeuer we consider anything in 192.168.0.0/16 to be reserved for whatever the local admin wants to do in the network behind his node so that shouldn't be a problem. And if we really can/must use IPv6 space then there won't a problem anyway ... > > would setup babel to write to it's own routing table and have some > > policy rules to select this table for the ip range we select but nothing > > else. > > What about simply making sure that Babel only installs route in this range? > Assuming your prefix is 10.10.0.0/16, ust put something like this in > /etc/babel.conf: > > in ip 10.10.0.0/16 allow > in deny That's a possibility too and as long as babel uses a different proto tag than olsrd its routes should be save but still there would be strange effects if somebody announced some 10.10.0.0/16 ip in olsr - which we can't prohibit. AFAICS babel already provides everything required so I guess it is easier to set up some policy rules than to debug the cartesian product of the bugs of two routing daemons. Harald From (spam-protected) Sun Dec 14 22:04:45 2008 From: (spam-protected) (Juliusz Chroboczek) Date: Sun, 14 Dec 2008 22:04:45 +0100 Subject: [Dump] A Babel experiment at funkfeuer.at In-Reply-To: (Harald Geyer's message of "Sun\, 14 Dec 2008 18\:31\:05 +0100") References: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> Message-ID: <87vdtmo4cy.fsf@trurl.pps.jussieu.fr> >> Hmm... the current implementation of Babel requires IPv6 in the kernel. Let me explain a little more. Babel is a hybrid protocol: Babel messages can be transported over IPv4 or over IPv6, and whatever protocol it runs over, it can transport both IPv4 and IPv6 routes. This is similar to the way BGP works, and somewhat analoguous to IS-IS. (BGP routes all network-layer protocols over IPv4 or IPv6, just like Babel, while IS-IS runs directly over Ethernet.) However, the current implementation only works over IPv6: while Babel will route IPv4, IPv6 or both, the Babel messages will only be transported over IPv6. (There are very good reasons to prefer IPv6 for transporting protocol messages, most notably the fact that it makes it easier to implement routing over unnumbered interfaces -- i.e. a router is able to forward packets even before it's been assigned an address, or when only some interfaces have an address. Additionally, the IPv6 multicast APIs are somewhat more portable than the IPv4 ones.) I'd like to be clear that you don't need global IPv6 addresses, you don't need router advertisements, you don't need global IPv6 connectivity. You only need kernel support for IPv6, which is all that's needed to do link-local multicast. > So on an openwrt router you need kmod_ipv6 installed ... we have such > a setup (using 6to4 and radvd) Once again -- you don't need 6to4, you don't need radvd, you only need the IPv6 kernel module. > With olsrd and ipv6 and babel and openvpn or vtun and $monitor_tool > running on the same mesh node we will most likely hit the RAM limit. FWIW, I'm happily running Babel + ahcpd + ntpd on 16MB OpenWRT machines (MIPS). Ntpd is the largest of the three ;-) I don't know about vtun, but I know that Babel happily runs over SIT tunnels, IP-IP tunnels, GRE tunnels and OpenVPN. For IP-IP, GRE and OpenVPN, a small hack is needed. For IP-IP, a recent kernel is needed. I have no idea about vtun. I'm using OpenVPN and GRE in my network. Since vtun is insecure anyway, I don't see any reason to prefer it to GRE. > OTOH if we need IPv6 support in the kernel anyway, then I don't see > a reason not to do the whole experiment in IPv6 space - but perhaps > I miss something. Don't worry about that -- it's a hybrid protocol. You can do both, or either, or have some nodes doing IPv6 and other doing IPv4. By default, Babel will route IPv6 on all interfaces, and route IPv4 on all interfaces that have an IPv4 address. So as long as you get Babel running, you don't need to choose between IPv4 and IPv6 -- you get whatever protocol you have configured addresses for. Juliusz From (spam-protected) Mon Dec 15 01:46:11 2008 From: (spam-protected) (Harald Geyer) Date: Mon, 15 Dec 2008 01:46:11 +0100 Subject: [Dump] A Babel experiment at funkfeuer.at In-Reply-To: <87vdtmo4cy.fsf@trurl.pps.jussieu.fr> References: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> <87vdtmo4cy.fsf@trurl.pps.jussieu.fr> Message-ID: > >> Hmm... the current implementation of Babel requires IPv6 in the kernel. > > Let me explain a little more. [...] > However, the current implementation only works over IPv6: while Babel will > route IPv4, IPv6 or both, the Babel messages will only be transported over > IPv6. (There are very good reasons to prefer IPv6 for transporting > protocol messages, most notably the fact that it makes it easier to > implement routing over unnumbered interfaces -- i.e. a router is able to > forward packets even before it's been assigned an address, or when only > some interfaces have an address. Additionally, the IPv6 multicast APIs are > somewhat more portable than the IPv4 ones.) > > I'd like to be clear that you don't need global IPv6 addresses, you don't > need router advertisements, you don't need global IPv6 connectivity. You > only need kernel support for IPv6, which is all that's needed to do > link-local multicast. Yes, that was my assumption. My point is: loading IPv6 support into the kernel is expensive - configuring some global IPv6 addresses is not. > > So on an openwrt router you need kmod_ipv6 installed ... we have such > > a setup (using 6to4 and radvd) > > Once again -- you don't need 6to4, you don't need radvd, you only need the > IPv6 kernel module. Sure, it's just the only way I have been able to verify that IPv6 support works in freifunkfirmware ... > > With olsrd and ipv6 and babel and openvpn or vtun and $monitor_tool > > running on the same mesh node we will most likely hit the RAM limit. > > FWIW, I'm happily running Babel + ahcpd + ntpd on 16MB OpenWRT machines > (MIPS). Ntpd is the largest of the three ;-) Once I have some proof of concept setup for freifunkfirmware I will be able to say more about that. > I don't know about vtun, but I know that Babel happily runs over SIT > tunnels, IP-IP tunnels, GRE tunnels and OpenVPN. For IP-IP, GRE and > OpenVPN, a small hack is needed. For IP-IP, a recent kernel is needed. > I have no idea about vtun. Ok. I was under the wrong assumption, that babel would need some ethernet type network interface. If we don't need OpenVPN then this should save quite some RAM... > I'm using OpenVPN and GRE in my network. Since vtun is insecure anyway, > I don't see any reason to prefer it to GRE. > > > OTOH if we need IPv6 support in the kernel anyway, then I don't see > > a reason not to do the whole experiment in IPv6 space - but perhaps > > I miss something. > > Don't worry about that -- it's a hybrid protocol. You can do both, or > either, or have some nodes doing IPv6 and other doing IPv4. By default, > Babel will route IPv6 on all interfaces, and route IPv4 on all interfaces > that have an IPv4 address. > > So as long as you get Babel running, you don't need to choose between IPv4 > and IPv6 -- you get whatever protocol you have configured addresses for. Sure, but since in Vienna olsr manages IPv4 and only IPv4 why not use babel together with IPv6? That way I don't need to worry about how to claim some IPv4 subnet for babel and I don't need to configure addresses on all nodes participating in the experiment: Just install babel + some special config file and it will route via IPv6 link local addresses by default. Just install some gobal addresses on nodes used for monitoring. Is that too simple? Harald From (spam-protected) Mon Dec 15 20:28:38 2008 From: (spam-protected) (Juliusz Chroboczek) Date: Mon, 15 Dec 2008 20:28:38 +0100 Subject: [Dump] A Babel experiment at funkfeuer.at In-Reply-To: (Harald Geyer's message of "Mon\, 15 Dec 2008 01\:46\:11 +0100") References: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> <87vdtmo4cy.fsf@trurl.pps.jussieu.fr> Message-ID: <87zlixfdax.fsf@trurl.pps.jussieu.fr> > Sure, but since in Vienna olsr manages IPv4 and only IPv4 why not use > babel together with IPv6? That way I don't need to worry about how to > claim some IPv4 subnet for babel Now I come to think about it -- yes, it's a good idea. > and I don't need to configure addresses on all nodes participating in the > experiment: Just install babel + some special config file and it will > route via IPv6 link local addresses by default. Just install some gobal > addresses on nodes used for monitoring. Is that too simple? Just a little bit. If your nodes don't have global IPv6 addresses, they will be completely invisible in the routing tables (recall that Babel is not a link state protocol). Hence, in order to put some load on the Babel network, you will want to give some of your nodes a global IPv6 address. You will want to use the following babel.conf: redistribute local ip ::/0 redistribute local deny This will prevent the local node from redistributing its local addresses, but will allow routing of IPv4 if other nodes redistribute their IPv4 address, so it makes switching to a hybrid network at a later date easier. If you want to prevent Babel from routing IPv4, even for other nodes, you need to additionally say in ip 0.0.0.0 deny Now the small hack I mentioned: on GRE and OpenVPN interfaces, the kernel does not automatically generate an IPv6 address, so you will need to add such an address yourself. I'm attaching a script that fixes that. You will need to install the ahcp-generate-address utility, which you will find as part of ahcpd. Have fun, Juliusz From (spam-protected) Mon Dec 22 18:07:35 2008 From: (spam-protected) (Harald Geyer) Date: Mon, 22 Dec 2008 18:07:35 +0100 Subject: [Dump] A Babel experiment at funkfeuer.at In-Reply-To: <87zlixfdax.fsf@trurl.pps.jussieu.fr> References: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> <87vdtmo4cy.fsf@trurl.pps.jussieu.fr> <87zlixfdax.fsf@trurl.pps.jussieu.fr> Message-ID: Hi! Some small updates: I compiled and tested babel with the freifunkfirmware and it seems to worki (without any special configuration included yet). The package is available at: http://texas.funkfeuer.at/~harald/babel/fff/babel_0.91-1_mipsel.ipk I use something like "babel -g 2222 eth1 sit1" to start babel and monitor it via "telnet ::1 2222" - do you recommend something else then telnet? One thing that's also pretty annoying is that the telnet of freifunkfirmware doesn't support IPv6, so I guess that's my first feature request: It would be nice if babel would accept connections on some routable addresses or on 127.0.0.1. When babel is running on a small router, then it prints messages "netlink_read: recvmsg(): No buffer space available" every now and then. It doesn't do that on my work station. After looking it up in the source I think it is harmless, but just to let you know ... > Just a little bit. If your nodes don't have global IPv6 addresses, they > will be completely invisible in the routing tables (recall that Babel is > not a link state protocol). Hence, in order to put some load on the Babel > network, you will want to give some of your nodes a global IPv6 address. > > You will want to use the following babel.conf: > > redistribute local ip ::/0 > redistribute local deny > > This will prevent the local node from redistributing its local addresses, > but will allow routing of IPv4 if other nodes redistribute their IPv4 > address, so it makes switching to a hybrid network at a later date easier. > If you want to prevent Babel from routing IPv4, even for other nodes, you > need to additionally say > > in ip 0.0.0.0 deny Ok, I used this as a start. Next I'll play with non default metrics. Especially tunnels should be expensive instead of having the same link cost as a cable ... > Now the small hack I mentioned: on GRE and OpenVPN interfaces, the kernel > does not automatically generate an IPv6 address, so you will need to add > such an address yourself. I'm attaching a script that fixes that. You > will need to install the ahcp-generate-address utility, which you will find > as part of ahcpd. So far I have only played with sit tunnels, which works fine. I suggest that we start with two tunnels between your site and Vienna. The IPs on our side will be 193.238.158.32 and 193.238.158.139. Just tell me what IPs you choose on your side and I'll activate the tunnels. Harald From (spam-protected) Tue Dec 23 14:04:48 2008 From: (spam-protected) (Juliusz Chroboczek) Date: Tue, 23 Dec 2008 14:04:48 +0100 Subject: [Dump] A Babel experiment at funkfeuer.at In-Reply-To: (Harald Geyer's message of "Mon\, 22 Dec 2008 18\:07\:35 +0100") References: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> <87vdtmo4cy.fsf@trurl.pps.jussieu.fr> <87zlixfdax.fsf@trurl.pps.jussieu.fr> Message-ID: <7i63lbkpov.fsf@lanthane.pps.jussieu.fr> > I use something like "babel -g 2222 eth1 sit1" to start babel We use babel -D -g 33123 -k 20 I suggest you use port 33123 for the local interface, just like we do, so that our tools (see below) can interoperate. > monitor it via "telnet ::1 2222" - do you recommend something else > then telnet? Yes. Log into your OpenWRT box using ssh -L 33123:ip6-localhost:33123 ... Then, you can telnet ::1 33123 on the machine from which you logged in, which means you can use the nice local telnet rather than the limited version included in OpenWRT. The interface is actually not designed for human beings, it's designed for a GUI. Two students of mine have been working on the GUI for the last six months, their current version is available by doing darcs get http://www.pps.jussieu.fr/~jch/software/repos/BabelTool Yes, the code is a mess, but the algorithms are pretty sweet. (We'll try to clean the codebase up over the next months.) The port is hard-wired to 33123. > It would be nice if babel would accept connections on some routable > addresses or on 127.0.0.1. Noted. > When babel is running on a small router, then it prints messages > "netlink_read: recvmsg(): No buffer space available" every now and > then. Yep, I don't know why. Babel will recover cleanly, but I'd like to understand what's going on. > Ok, I used this as a start. Next I'll play with non default > metrics. Especially tunnels should be expensive instead of having the > same link cost as a cable ... Yep. I'm thinking of measuring RTT times and doing that automatically, but it's pretty low on my TODO list. > So far I have only played with sit tunnels, which works fine. That's a bad idea, since SIT cannot carry IPv4, so it means that all the infrastructure will need changing if you ever decide to switch to hybrid routing. I strongly recommend GRE, which is portable and able to carry multiple protocols. > I suggest that we start with two tunnels between your site and Vienna. No can do -- we're using OpenVPN (negotiated with our sysadmin), and I really don't feel like going through the negotiations again. I'll get in touch with you through private mail. Juliusz From (spam-protected) Tue Dec 23 15:19:07 2008 From: (spam-protected) (Harald Geyer) Date: Tue, 23 Dec 2008 15:19:07 +0100 Subject: [Dump] A Babel experiment at funkfeuer.at In-Reply-To: <7i63lbkpov.fsf@lanthane.pps.jussieu.fr> References: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> <87vdtmo4cy.fsf@trurl.pps.jussieu.fr> <87zlixfdax.fsf@trurl.pps.jussieu.fr> <7i63lbkpov.fsf@lanthane.pps.jussieu.fr> Message-ID: > babel -D -g 33123 -k 20 > > I suggest you use port 33123 for the local interface, just like we do, so > that our tools (see below) can interoperate. Ok. Perhaps this port should be recommended in the man page also ... > > monitor it via "telnet ::1 2222" - do you recommend something else > > then telnet? > > Yes. Log into your OpenWRT box using > > ssh -L 33123:ip6-localhost:33123 ... > > Then, you can telnet ::1 33123 on the machine from which you logged in, > which means you can use the nice local telnet rather than the limited > version included in OpenWRT. Hmm, I should have thought about this myself... Anyway: It doesn't work either. On the router I get messages "channel 3: open failed: connect failed:" whenever I try to start telnet and telnet says: | Connected to ip6-localhost. | Escape character is '^]'. | Connection closed by foreign host. This is the same whether I connect to the routers v4 or v6 Address. (General ssh over v6 works in both directions.) > The interface is actually not designed for human beings, it's designed for > a GUI. Two students of mine have been working on the GUI for the last six > months, their current version is available by doing > > darcs get http://www.pps.jussieu.fr/~jch/software/repos/BabelTool > > Yes, the code is a mess, but the algorithms are pretty sweet. (We'll try > to clean the codebase up over the next months.) Hm, does it work with free java? (ie packages included in lenny-main) > The port is hard-wired to 33123. Hm, makes it difficult to connect to several routers at the same time... > > Ok, I used this as a start. Next I'll play with non default > > metrics. Especially tunnels should be expensive instead of having the > > same link cost as a cable ... > > Yep. I'm thinking of measuring RTT times and doing that automatically, but > it's pretty low on my TODO list. Hm, that might be a nice idea. But typically you don't want to use tunnels, so I'll just give them link costs high enough that they don't get used unless there is no other alternative... > > So far I have only played with sit tunnels, which works fine. > > That's a bad idea, since SIT cannot carry IPv4, so it means that all the > infrastructure will need changing if you ever decide to switch to hybrid > routing. I strongly recommend GRE, which is portable and able to carry > multiple protocols. I'll keep that in mind. But if we ever use babel to route real traffic (ideas which already brought some heated mails into my inbox) then the tunnels need to go away: routing babel over tunnel over olsr would make a complete mess - there is no way to get compatible link costs for the tunnels. Building tunnels within one mesh to build an other mesh is a hack not infratructure. > > I suggest that we start with two tunnels between your site and Vienna. > > No can do -- we're using OpenVPN (negotiated with our sysadmin), and > I really don't feel like going through the negotiations again. I'll get in > touch with you through private mail. I see. openvpn should be ok. Perhaps keep the people that are on personal CC now involved in our tunnel negotiation ... Thanks for your help, Harald From (spam-protected) Tue Dec 23 16:22:23 2008 From: (spam-protected) (Juliusz Chroboczek) Date: Tue, 23 Dec 2008 16:22:23 +0100 Subject: [Dump] [Babel-users] A Babel experiment at funkfeuer.at In-Reply-To: (Harald Geyer's message of "Tue\, 23 Dec 2008 15\:19\:07 +0100") References: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> <87vdtmo4cy.fsf@trurl.pps.jussieu.fr> <87zlixfdax.fsf@trurl.pps.jussieu.fr> <7i63lbkpov.fsf@lanthane.pps.jussieu.fr> Message-ID: <7iprji532o.fsf@lanthane.pps.jussieu.fr> > Ok. Perhaps this port should be recommended in the man page also ... Yep. >> ssh -L 33123:ip6-localhost:33123 ... > Anyway: It doesn't work either. On the router I get messages > "channel 3: open failed: connect failed:" whenever I try to start telnet > and telnet says: Weird. Works for me. Are you sure you switched to 33123? >> darcs get http://www.pps.jussieu.fr/~jch/software/repos/BabelTool > Hm, does it work with free java? (ie packages included in lenny-main) I haven't tried. I see no reason why it shouldn't work with openjdk, I'd be surprised if it worked with gjc. >> The port is hard-wired to 33123. > Hm, makes it difficult to connect to several routers at the same time... Alex, PJ, any comments? Or are you too busy with your compilers project ;-) >> [...] since SIT cannot carry IPv4, so it means that all the >> infrastructure will need changing if you ever decide to switch to hybrid >> routing. I strongly recommend GRE > I'll keep that in mind. But if we ever use babel to route real traffic > (ideas which already brought some heated mails into my inbox) then the > tunnels need to go away: While I fully agree, I'd still recommend you go for GRE. Transitions are always more messy than expected, let's make it as easy as reasonable. Juliusz From (spam-protected) Tue Dec 23 16:29:51 2008 From: (spam-protected) (Juliusz Chroboczek) Date: Tue, 23 Dec 2008 16:29:51 +0100 Subject: [Dump] [Babel-users] A Babel experiment at funkfeuer.at References: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> <87vdtmo4cy.fsf@trurl.pps.jussieu.fr> <87zlixfdax.fsf@trurl.pps.jussieu.fr> <7i63lbkpov.fsf@lanthane.pps.jussieu.fr> Message-ID: <87lju6c3kf.fsf@trurl.pps.jussieu.fr> Here's the script that adds a link-local address to an arbitrary interface. You'll need the ``ahcp-compute-address'' utility, which you'll find in the ahcpd distribution. Juliusz -------------- next part -------------- A non-text attachment was scrubbed... Name: add-link-local-address.sh Type: text/x-sh Size: 517 bytes Desc: not available URL: From (spam-protected) Tue Dec 23 16:35:30 2008 From: (spam-protected) (Harald Geyer) Date: Tue, 23 Dec 2008 16:35:30 +0100 Subject: [Dump] [Babel-users] A Babel experiment at funkfeuer.at In-Reply-To: <7iprji532o.fsf@lanthane.pps.jussieu.fr> References: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> <87vdtmo4cy.fsf@trurl.pps.jussieu.fr> <87zlixfdax.fsf@trurl.pps.jussieu.fr> <7i63lbkpov.fsf@lanthane.pps.jussieu.fr> <7iprji532o.fsf@lanthane.pps.jussieu.fr> Message-ID: > >> ssh -L 33123:ip6-localhost:33123 ... > > > Anyway: It doesn't work either. On the router I get messages > > "channel 3: open failed: connect failed:" whenever I try to start telnet > > and telnet says: > > Weird. Works for me. I guess you don't use freifunkfirmware but openwrt. Actually with recent openwrt even telnet works, but freifunkfirmware will be around for quite some time ... > Are you sure you switched to 33123? No, but I'm quite sure I got the port numbers right. > >> darcs get http://www.pps.jussieu.fr/~jch/software/repos/BabelTool > > > Hm, does it work with free java? (ie packages included in lenny-main) > > I haven't tried. I see no reason why it shouldn't work with openjdk, I'd > be surprised if it worked with gjc. Ok. Eventually I'll look into it. > >> The port is hard-wired to 33123. > > > Hm, makes it difficult to connect to several routers at the same time... > > Alex, PJ, any comments? Or are you too busy with your compilers project ;-) It's not important. Harald From (spam-protected) Tue Dec 23 18:03:24 2008 From: (spam-protected) (Juliusz Chroboczek) Date: Tue, 23 Dec 2008 18:03:24 +0100 Subject: [Dump] [Babel-users] A Babel experiment at funkfeuer.at In-Reply-To: (Harald Geyer's message of "Tue\, 23 Dec 2008 16\:35\:30 +0100") References: <7iljujkv45.fsf@lanthane.pps.jussieu.fr> <87vdtmo4cy.fsf@trurl.pps.jussieu.fr> <87zlixfdax.fsf@trurl.pps.jussieu.fr> <7i63lbkpov.fsf@lanthane.pps.jussieu.fr> <7iprji532o.fsf@lanthane.pps.jussieu.fr> Message-ID: <7itz8uvn6r.fsf@lanthane.pps.jussieu.fr> >> >> ssh -L 33123:ip6-localhost:33123 ... >> > Anyway: It doesn't work either. On the router I get messages >> > "channel 3: open failed: connect failed:" whenever I try to start telnet >> > and telnet says: >> >> Weird. Works for me. Ah, I got it. Try instead ssh -L33123:[::1]:33123 ... (That's because there's no ``ip6-localhost'' in the /etc/hosts of your routers...) Juliusz From (spam-protected) Wed Dec 24 03:02:15 2008 From: (spam-protected) (Markus Kittenberger) Date: Wed, 24 Dec 2008 03:02:15 +0100 Subject: [Dump] =?iso-8859-1?q?Vorank=FCndigung_OLSR-MESH_Test?= Message-ID: <4095b6c00812231802g64886234vea4c1ca7d3c27ae2@mail.gmail.com> Unabhängig von der unsäglichen Ausuferung des babel tests threads,.. Hatte ich schon länger was "dazupassendes" vor nämlich ein parallells-olsr-testnetz ob evt. für manche sachen simulationen nicht besser wären, ist ne andere gschichte, aber damit haben sich eh schon andere beschäftigt (und verwenden es afaik in gewissen ausmass ja eh) und da mich am meisten metrik/routing probleme in realen meshes intressieren, und da z.B fragen wie: warum kann ein route change solange dauern,.. (nämlich minuten nicht sekunden) warum sind nur 85% der router in unserem netz erreichbar, .. evt. sind die erklärungen einfach nur: weil manche router eben nur schlechte links haben, und weil ein paar alte olsr mit alten bugs ... aber evt sind es eben keine bugs sondern (auch) metrik und protokoll-unzulänglichkeiten,.. mehr details spätermal lg Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Wed Dec 24 03:37:49 2008 From: (spam-protected) (Markus Kittenberger) Date: Wed, 24 Dec 2008 03:37:49 +0100 Subject: [Dump] parallelle meshes Message-ID: <4095b6c00812231837i27c50eaduc7b4ad1ed463f8a7@mail.gmail.com> das ich ja auch ähnliches vorhab,.. (wir dann also schon bei 3 routing daemons pro Router wären) (allerdings k.a. ob ich zuerst einen olsr-fork mit paar intressanten mods # mach, und dann erst mit parallel setup anfang oder umgekehrt) und die ressourcen eines routers irgendwannmal zu neige gehen,.. wir wärs mit folgendem (auch als vertrauensfördendes für argwöhnihsche, oder kompromissvorschlag fürn aaron) die einzelnen parallel-netze kriegen timeslots,.. d.h. evt anfangs nur nachts, jedenfalls halt nicht primetime,.. und halt nie mehr als 2 daemons gleichzeitig whatever,.. könnt vertrauenfördernd sein, oder das gegnteil bewirken, doer aber auch im endeffekt uns auch ärger machen,.. denn wer stellt dann die timeslots ein (ich würde das eher nicht dem node-owner (alleinig) in die hand geben wollen) lg MArkus ne andere frage, wie hast du vor babel im ipkg zu konfigurieren auf allen interfaces, oder nur auf wan/funk, oder auf denen wo auch olsr läuft,.. # zurzeit angedachte mods (und mit kaum rücksicht auf RFC kompatibilität (vorallem punkt D)) A: lq-metrik mit sehr wenigen werten, und adaptiver validity time -> nur sehr wenige metrikänderungen und auch sehr wenige tcs -> wenig traffic, und darum kein fisheye mehr nötig B: evt. latenzmessungen der links, evt. unicast packetloss messungen C: evt. non-wlandriver based linkspeed messungen (keineswegs genau) und das eher nur bei links mit wenig packetloss denn ich will nicht das ein link mit nennswert (d.h unicat packetloss erwartbar) packetloss nen besserer metrik kriegen kann, als ein langsamer ohn packetloss D: gewisse zeitliche synchonisierung (d.h. neue metrikwerte (wenn sie nicht exrteme verschlechterungen sind)) werden announct, aber erst z.b. 10 sekunden später (abhängig von meshgrösse und der dringlichkeit) (überall möglichst gleichzeitg) umgesetzt wird,.. d.h. ziel ist jedenfalls deutlich gleichzeitiger als jetzt vermutlich werd ichs aber doch nicht probieren das ganze mesh zu synchronisieren (-; sondern einfach in den oslr paketen mit nem zusätzlichen timetovalidity (ttv) feld, immer abziehen wie lange das paket warten musste (und auch die bekannte durchschnitts-latenz des incoming links) (da ich fisheye eh auch weglassen will, ersetzte ich evt ttl durch ttv, allerdings bezweifle ich ob ich mit 8bit auskomm) E: sofortiges weitersenden von katastrophen-tcs (d.h. kein zamsammeln von messages auf ein grosses paket) und tcs mit niedriger ttv d.h. wenn einer seiner links plötzlich irre schlecht wird schickt der olsr tcs mit niedriger ttv, und erwartet das schnellstmöglich jeder davon erfährt,.. gleichzeitg werd ich irgendwas einbauen müssen, dass evt. auf jeden knoten ein ratelimit (pro orinigator) gibt wieoft er solche tcs schicken darf und diese auch wirkich sofort weitergeleitet werden,.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Wed Dec 24 04:33:17 2008 From: (spam-protected) (Harald Geyer) Date: Wed, 24 Dec 2008 04:33:17 +0100 Subject: [Dump] parallelle meshes In-Reply-To: <4095b6c00812231837i27c50eaduc7b4ad1ed463f8a7@mail.gmail.com> References: <4095b6c00812231837i27c50eaduc7b4ad1ed463f8a7@mail.gmail.com> Message-ID: > das ich ja auch ähnliches vorhab,.. (wir dann also schon bei 3 routing > daemons pro Router wären) > > (allerdings k.a. ob ich zuerst einen olsr-fork mit paar intressanten mods # > mach, und dann erst mit parallel setup anfang oder umgekehrt) > > und die ressourcen eines routers irgendwannmal zu neige gehen,.. Also was bei babel am meisten Ressourcen verbraucht ist eigentlich das kmod-ipv6... Allerdings ist babel in Hinsicht Parallelbetrieb ohne sich einzumischen extrem dankbar: Es muss nichts außer den link local Adressen announcen und man kann in der /etc/babel.conf genau spezifizieren welche Routen es announcen soll und welche nicht. Damit kann man alle Arten von Interferenzen recht gut in den Griff kriegen, braucht keine eigenen Addressspaces etc... Bei einem Shadow-OLSR-Netz hast du viel mehr Arbeit vor dir. Und was Ressourcen betrifft, musst du dann noch irgendein Monitoringtool auch mit einplanen, oder wie willst du an Daten kommen? > könnt vertrauenfördernd sein, oder das gegnteil bewirken, doer aber auc > h im > endeffekt uns auch ärger machen,.. Letzteres am allermeisten. > denn wer stellt dann die timeslots ein (ich würde das eher nicht dem > node-owner (alleinig) in die hand geben wollen) Nein, timeslots sind schlecht, weil viel zu fehleranfällig und die Daten schwer auszuwerten. Und wenn du regelmäßig neue mods testen willst, dann geht das ohne automatisches deploymentsystem sowieso nicht - speziell wenn du immer wieder andere mods testen willst. Bei einem automatischen System machen sicher eine Menge Leute nicht mit (andere dafür umso mehr) - zum Beispiel auf meinen Knoten laufen jetzt schon zu viele extras. Da kann nicht so einfach wer anderer als ich darauf herumfuhrwerken... und schon gar kein Skript. Allerdings das automatische Deploymentsystem könnte für babel auch interessant werden - immerhin ist da noch immer jederzeit mit inkompatiblen Protokolländerungen zu rechnen. Also wenn du wirklich olsr-mods testen willst, dann stell' ich wohl am besten die sit-tunnel auf gre um, wie von Juliusz vorgeschlagen und dein erster mod ist, den olsrd gre tauglich zu machen. > ne andere frage, wie hast du vor babel im ipkg zu konfigurieren > > auf allen interfaces, oder nur auf wan/funk, oder auf denen wo auch olsr > läuft,.. Noch nicht ganz klar. Derzeit bin ich gerade dabei babel kennenzulernen, wofür die 4-5 aktuell aktiven Nodes ausreichen. Beim ipk hängt vieles davon ab, ob ich so viele airtunnel brauche, dass ich die tunnel vom ipk machen lass' oder ob ich nur ein einfaches babel-ipk mach' und tunnel-knoten immer ein Spezialfall sind. Für den Fall, dass ich die Tunnel manuell grabe, würd' ich als Interfaceliste im ipk einfach "eth1 vlan0 vlan1" nehmen. Wenn ich viele Tunnel brauche, dann muss ich Interfaceliste und Tunnelkonfig im nvram ablegen, weil sonst ist das nach jedem update weg... Deine Mods klingen interessant: Wie wär's du schreibst einfach OLSRv3 d'rauf und lässt andere die Arbeit machen? SCRN > # zurzeit angedachte mods (und mit kaum rücksicht auf RFC kompatibilit > ät > (vorallem punkt D)) > > A: lq-metrik mit sehr wenigen werten, > und adaptiver validity time -> nur sehr wenige metrikänderungen und auch > sehr wenige tcs > -> wenig traffic, und darum kein fisheye mehr nötig > B: evt. latenzmessungen der links, evt. unicast packetloss messungen > C: evt. non-wlandriver based linkspeed messungen (keineswegs genau) > und das eher nur bei links mit wenig packetloss > denn ich will nicht das ein link mit nennswert (d.h unicat packetloss > erwartbar) packetloss nen besserer metrik kriegen kann, als ein langsamer > ohn packetloss > D: gewisse zeitliche synchonisierung (d.h. neue metrikwerte (wenn sie nicht > exrteme verschlechterungen sind)) werden announct, aber erst z.b. 10 > sekunden später (abhängig von meshgrösse und der dringlichkeit) (ü > berall > möglichst gleichzeitg) umgesetzt wird,.. > d.h. ziel ist jedenfalls deutlich gleichzeitiger als jetzt > vermutlich werd ichs aber doch nicht probieren das ganze mesh zu > synchronisieren (-; > sondern einfach in den oslr paketen mit nem zusätzlichen timetovalidity > (ttv) feld, immer abziehen wie lange das paket warten musste (und auch die > bekannte durchschnitts-latenz des incoming links) (da ich fisheye eh auch > weglassen will, ersetzte ich evt ttl durch ttv, allerdings bezweifle ich ob > ich mit 8bit auskomm) > E: sofortiges weitersenden von katastrophen-tcs (d.h. kein zamsammeln von > messages auf ein grosses paket) und tcs mit niedriger ttv > d.h. wenn einer seiner links plötzlich irre schlecht wird schickt der ols > r > tcs mit niedriger ttv, und erwartet das schnellstmöglich jeder davon > erfährt,.. > gleichzeitg werd ich irgendwas einbauen müssen, dass evt. auf jeden knote > n > ein ratelimit (pro orinigator) gibt wieoft er solche tcs schicken darf und > diese auch wirkich sofort weitergeleitet werden,.. From (spam-protected) Wed Dec 24 11:41:49 2008 From: (spam-protected) (Markus Kittenberger) Date: Wed, 24 Dec 2008 11:41:49 +0100 Subject: [Dump] parallelle meshes In-Reply-To: References: <4095b6c00812231837i27c50eaduc7b4ad1ed463f8a7@mail.gmail.com> Message-ID: <4095b6c00812240241w2f3b6628r44e5a6c6d12464d0@mail.gmail.com> 2008/12/24 Harald Geyer > > > das ich ja auch ähnliches vorhab,.. (wir dann also schon bei 3 routing > > daemons pro Router wären) > > > > (allerdings k.a. ob ich zuerst einen olsr-fork mit paar intressanten mods > # > > mach, und dann erst mit parallel setup anfang oder umgekehrt) > > > > und die ressourcen eines routers irgendwannmal zu neige gehen,.. > > Also was bei babel am meisten Ressourcen verbraucht ist eigentlich > das kmod-ipv6... wieviel? (-; und wieviel braucht babel dann bei mehr nachbarn,. denn das ist beim olsrd der grössere anteil (#) > > > Bei einem Shadow-OLSR-Netz hast du viel mehr Arbeit vor dir. > Und was Ressourcen betrifft, musst du dann noch irgendein Monitoringtool > auch mit einplanen, oder wie willst du an Daten kommen? vermutlich, ... dummerweise steht ja der noch freie ram nirgends im webgui, afaik, kann also net mal vorab danach spidern > > > willst, dann geht das ohne automatisches deploymentsystem sowieso > nicht - speziell wenn du immer wieder andere mods testen willst. das hatte ich soweiso vor jedoch ein bißchen abschreckend könnt das schon sein,.. allerdings einzige automatisierten änderungen,.. kleine configfileanpassungen, und austauschen der olsrd-test binaries und dabei halt vorher auch überprüfen wieviel platz noch im flash ist,.. policyrouting, und ipconfig, und sicherungsmassnahmen (kill on > 10% average cpu, and > 1MB RAM oder so) bleiben recht statisch aber klar, das ist nur ne freiwillige selbstbeschränkung, denn wenn ich automatisiert binaries tauschen und diese ausführen kann,.. (-; > Also wenn du wirklich olsr-mods testen willst, dann stell' ich wohl > am besten die sit-tunnel auf gre um, wie von Juliusz > vorgeschlagen und dein erster mod ist, den olsrd gre tauglich zu > machen. am liebsten wär mir eigentlich ohne tunnel auzukommen, aber wird wohl unrealistisch GRE geht afaik eh mit olsr, glaub wir hatten schon nen GRE tunnel zwischen roofnode und tunnelserver, bevor wir ein vlan dafür kriegten,.. > > > > ne andere frage, wie hast du vor babel im ipkg zu konfigurieren > > > > auf allen interfaces, oder nur auf wan/funk, oder auf denen wo auch olsr > > läuft,.. > > Noch nicht ganz klar. Derzeit bin ich gerade dabei babel kennenzulernen, > wofür die 4-5 aktuell aktiven Nodes ausreichen. > > Beim ipk hängt vieles davon ab, ob ich so viele airtunnel brauche, dass > ich die tunnel vom ipk machen lass' oder ob ich nur ein einfaches > babel-ipk mach' und tunnel-knoten immer ein Spezialfall sind. > > Für den Fall, dass ich die Tunnel manuell grabe, würd' ich > als Interfaceliste im ipk einfach "eth1 vlan0 vlan1" nehmen. > > Wenn ich viele Tunnel brauche, dann muss ich Interfaceliste und > Tunnelkonfig im nvram ablegen, weil sonst ist das nach jedem > update weg... nunja babel ist dann eh auch mal weg,.. am liebsten wär mir (fast) ohne tunnel,.. weil genügend testrouter (-; > > > Deine Mods klingen interessant: Wie wär's du schreibst einfach > OLSRv3 d'rauf und lässt andere die Arbeit machen? SCRN hmm, was da dann aber dabei rauskommt,.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Fri Dec 26 01:24:51 2008 From: (spam-protected) (Markus Kittenberger) Date: Fri, 26 Dec 2008 01:24:51 +0100 Subject: [Dump] NOTRACK Message-ID: <4095b6c00812251624p34cb9948jfcc95d559435a6bb@mail.gmail.com> Hi hab heute ab 19:58h ein problem mit dem linksys am liechtwicht gehabt,.. http://193.238.157.78/~markus/connstat/view.php?host=193.238.158.154&nojs=&date=20081225 es gingen wohl zuviele connections drüber (und nafangs auch 20% des netzes durch seinen tunnel (welcher allein schon 30% cpu brauchte)) und nachdem anfangs garnix mehr ging war die latenz gewaltig hoch oben, und erst al ich eine ip die für merh als die hälfte aller connections veantwortlich blockte, gings wieder,. btw. mein conntrack machte auch nen teil der connections am liechtwicht aus, d.h. man kann an den connections zum texas genau abzählen wieviele router über einen routen, sehr praktisch (-; jedenfalls ist mir dabei eingefallen das wir ja überall conntrack für alles haben,.. obwohl es nur für den genateten traffic vom LAN es überhaupt gebraucht wird,.. und so ein kleiner roouter ist da schnell an die wand gefahren, wenn er rausfinden muss welche ftp pakete zamgehören usw,.. jedenfalls gibts dafür iptables -t raw -J NOTRACK womit man konfigurieren köntne das es kein conntrack für den transit-traffic braucht,.. allerdings erst in neuen 2.6ern vonalleine mitdabei,.. somit empfehlenswert für kamikaze konfigs/firmwares,.. und evt. doch noch als kmod.ipkg für whiterussian (gibt ja nen NOTRACK patch ja schon seit 2001, und für 2.4 kernel) lg Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Fri Dec 26 01:50:13 2008 From: (spam-protected) (Markus Kittenberger) Date: Fri, 26 Dec 2008 01:50:13 +0100 Subject: [Dump] userspace latency Message-ID: <4095b6c00812251650p290b0accof67e23371c0ab283@mail.gmail.com> da ja seit akku nach ping-artigen metriken lechszt,.. (-; gerne von verschiednen seiten: das geht nicht verkündet wurde,. mit derartigen begründungen: ping macht zuviel nichtnutzbaren traffic und leider solche messungen angeblich nur mit ping und dessen im-kernel-space reply überhaupt gut möglich wären,.. ersters stimmt natürlich, und auch die zwingend symmetrische antwortgrösse vom icmp echo/reply ist nich das allerfeinste,.. aber 2.tens hab ich seit jeher in zweifel gezogen,.. und da man c kenntnisse inzwischen ausreichend sind um über udp sockets messages zu schicken/empfangen,.. (-; obowhl ich im endeffekt dann eh ein fastfertiges sample im internet dafür gfunden hab.. *g (source und whiterussian binaries siehe http://texas.funkfeuer.at/~markus/udp_latency) nunja jedenfalls kann man setsockopt(sock,SO_TIMEOUT) machen, und kriegt dann den kernel timestamp zu jeden paket, d.h. man kann ruhig nonblocking mit "riesigen" pollinterval auf pakete warten, und trotzdem die zeit messen wann es ankam,.. somit ists egal ob das relpy erst sekunden später weggeschickt wird, (wenn sowieso z.b. ein anderes hello paket retour ginge) man muss nur das zeitdelta seit zum empfangstimestamp zrückschicken und gut ists jedenfalls hab ich auf normalen servern gleiche latenzzeiten wie mit pinf gemessen, und auf linksys und buffalo um .5 msec niedrigere,.. allerdings sind sie imho richitg, d.h. 0,5msec via lan zum nächsten anstatt 1msec ping, aber eben auch 5.5msecs über 6 hops wo ping im langzeitdurchschnitt 6 msecs hatte,.. da ich nebenbei auch die latenz des netzwerk stacks + schedulers damit messen konnte (zeitdifferenz zwischen kernel timestamp und empfangen mit einem blocking recvmsg(sock,) welche meistens ca. 0,5 msec betrug bin ich auch ziemlich sicher woher dieser unterschied herrührte, das ping utility selber rennt ja ganauso im userspace, nur das reply beim gegenüber wird "blitzschnell" von dessen kernel gemacht, aber beim empfangen nutzt das nix,.. und darum ist mein test der sowhl beim gegenüber als auch lokal die kerneltimestamps verwendet, eben quasi "schneller",. nunja im grunde nix weltbewegendes, nona macht der kernel brauchbare timestamps, tcpdump zeigt sie ja auch an,.. aber ein schöner proof, denn meine olsr-erweiterungen brauchen gut-messbare latenzen,.. lg Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Wed Dec 31 03:50:58 2008 From: (spam-protected) (Markus Kittenberger) Date: Wed, 31 Dec 2008 03:50:58 +0100 Subject: [Dump] conntrack nun als modul in der fff Message-ID: <4095b6c00812301850j5b42849bse63d92b94f9cd3b5@mail.gmail.com> Die nächste version der fff, wird übrigens conntrack und nat als module (und nicht fix im kernel) haben,.. schaltet man NAT dann im webif aus, wird conntrack dann auch wirklich nicht mehr geladen,.. damit kann man dann immerhin schon auf knoten die eh kein NAT brauchen, ausprobieren wieviel performance-gewinn davon zu erwarten ist,.. weiters lässt sich dieses modul dann auch leicht (per ipkg) gegen ein gepatchtes tauschen, ohne komplett neu flashen zu müssen,.. und an nem mini conntrack_patch bastl ich nun doch, zwar hab ich fürs erste nicht vor ein komplettes NOTRACK target einzubauen, aber eben nur traffic zu tracken der überhaupt von/ins lan=br0 geht, im grunde eh nur ne weitere built-in ausnahme im netfilter, der ja zum beispiel die packete von nem raw-socket auch jetzt schon nicht tracked/nated,.. lg Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: