Re: [Babel-users] Should I use wifi mesh routing in crisis situations?
Hi! I would also be surprised if 802.11s works better than ad-hoc. I think it is just a question of configuration in both cases. It is really primarily limitation of one-channel communication. Maybe through years ad-hoc implementations got bugs, but few years ago ad-hoc mesh worked OK with wlan slovenia firmware. (With OK I mean 1 Mbit/s speeds. One YouTube video and this is it.) Maybe we just got used to N and AC speeds and this is now not enough. I would guess that all MIMO and package pipelining done with N and AC protocols do not work well in ad-hoc mode. One thing with one-channel mesh networks one has to consider is how much noise each node is making to other nodes. You probably want to sometimes even make TX power smaller to make less noise to other nodes. But ad-hoc mode was never really meant for performance but for independence to me. That the mesh network operates even without uplinks and tunnels. And then speed one gets with backbone links. So maybe think about setup where you use multiple radios per device. Using ad-hoc, 802.11s, or 802.11s with one hop (nice trick, btw), I do not think it matters so much. But test it. Test it also with different TX powers. I think you should understand that 802.11s will not scale. So really use it just for small parts of the network, you then combine with L3 routing protocol together. Mitar On Thu, Jun 22, 2017 at 3:19 PM, Valent Turkovic <val...@otvorenamreza.org> wrote: > On Thu, Jun 22, 2017 at 6:20 PM, Juliusz Chroboczek <j...@irif.fr> wrote: >>>> 1. ad-hoc mode doesn't work as well as infrastructure mode; >> >>> Has anyone tries using 802.11s configured interface? >> >> Interesting idea. I'd be surprised if it worked much better than plain >> ad-hoc mode, but I'd love to be proved wrong. >> > > I had really bad experience with adhoc mode, so I'm willing to try > 802.11s and my feeling is that nothing can be as bad as adhoc. > > Friend just shared this great discussion from 2014: > http://lists.alioth.debian.org/pipermail/babel-users/2014-November/001786.html > > This gives quite a nice background explanation, so thank you Juliusz > from the past :) > > What I'm trying to find from this mailing list? Just not to repeat > tests that others have done, and of others have some best practices to > share them. > > But if nobody has compared babel on adhoc and 802.11s routers then my > team and I'll do this test and report back. > >>>> If you're using diversity routing (Babel-Z), be >>>> aware that current versions of babeld are unable to automatically >>>> determine the channel number of interfaces in AP mode -- you'll need to >>>> set them manually. >> >>> We are using wlan-slovenia firmware, and AFAIK this is regular babel. >>> I'll read up on babel-z. >> >> It's included in the babeld binary. Just add "diversity true" to the >> config file. >> >> The protocol is described here: >> >> https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing > > Thanks, I'll look into this. > > ___ > Babel-users mailing list > Babel-users@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] latency in WLAN-SI
Hi! On Tue, Dec 15, 2015 at 4:13 PM, Dave Taht <dave.t...@gmail.com> wrote: > In pouring through the astonishing *wealth* of data available via > nodewatcher, I finally scrolled down to the chart next to the very > bottom to find rtt measurements. Oh, there is even more, but we do not display all charts and not for all data we know how to draw it. You can see all types of data recorded for a node by doing something like: https://nodes.wlan-si.net/api/v1/stream/?tags__node=e6668d55-5e8d-4e32-94e3-ea8e9c23e5f5=1000=json > so are you really seeing real-world peaks in the 7 second range or is > that an artifact of something else? I do not know. Maybe it is an artifact of flapping route? Valent? Also, ping is from a central location, so this is accumulative over multiple hops. Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] latency in WLAN-SI
Hi! On Tue, Dec 15, 2015 at 2:16 AM, Dave Taht <dave.t...@gmail.com> wrote: >> Or we have a very short buffer. ;-) > > You certainly know how to tweak me! In fact, we do not yet have anything like that configured, I was just teasing. ;-) But maybe upstream ISPs have. > Do you have something like smokeping configured? I would love to see > data on not just the vpn issues but on the latencies across the mesh. Valent is running Smokeping from Croatia towards our server just for this reason (after we discovered the issues). He might be able to give you access to the VPS he runs there if you want to do more active testing. http://95.85.26.162:81/smokeping/smokeping.cgi?target=Wlan-si.node2 We do measure latencies from the central server (which is running nodewatcher monitoring system) to all nodes for different packet sizes every 5 minutes. > In lui of deploying smokeping everywhere I've been thinking of adding > a lightweight latency test to flent, where we just test lightweight > udp and icmp continuously with, say, a 1sec or even 60 sec period, to > dozens or hundreds of hosts, for hours at a time, all the time > Smokeping's basic plot is good, but flent can do a better job of > aggregating data across more variables. Another approach would be > embed timestamps in the needed overhead traffic (be that babel or > other) and get everything synced up via ntp... Currently we use fping. Feel free to propose other stuff we should be measuring. > As best as I recall your vpn was pure udp, no crypto, no retries I > see in your (nice!) web interface that you track if a node is > reachable, but not an observed rtt. We also measure RTT. > Could you clarify the behavior of your vpn? vpn's over tcp will never > lose packets. vpns that do crypto tend to bottleneck on the crypto > step and drop packets in the read side of the socket. nearly anything > using the tun/tap interfaces tends to be slow, the recent Foo over UDP > stuff corrects some of that: > https://www.netdev01.org/docs/herbert-UDP-Encapsulation-Linux.pdf We use L2TPv3 UDP pseudowire Linux kernel tunnels (so Ethernet/L2 over UDP). Our VPN is just a broker for those. So no crypto, UDP, and in-kernel tunneling for no context switches. The latter was require to get anything more than 5 Mbit/s of VPN throughput on Foneras. When you have a lot of fiber you tend to like using it all, if you can. :-) Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel instability in WLAN-SI
Hi! On Mon, Dec 14, 2015 at 11:39 AM, Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> wrote: > I'd like more evidence that this is needed. Estimating packet loss is > very slow (since we're computing a metric from what is just a discrete, > one-bit signal), so it slows down convergence. Hopefully we can get away > without it. Hm, isn't computation on WiFi links exactly the same? > Does your RTT increase at the same time as packet loss? If so, we could > probably do without packet loss. Not really. At least on the fiber links (which are most of our VPN links) it does not. > (Recall that the goal is not to have an accurate model of the real > world -- the goal is to have traffic flow according to optimal paths. If > the traffic is going where you want it to go, there's no need to add more > complexity to babeld.) Currently it seems that the routes over VPN are dropped while we would prefer them to stay up, even if there is a slight packet loss. >> Why have you disabled packet-loss metric on VPN links? > > Because it's an experimental feature, that hasn't had enough real-world > deployment. It works beautifully in our tests, it works beautifully in > Nexedi's network, and if it works as well in your network, I'll enable it > by default. Hm, are we talking here about packet-loss or delay-based routing (RTT)? I understand that RTT metric is experimental, but I was talking about packet-loss, why is that not enabled. Or am I missing something? > First, it slows down reaction to link failures. If you're on an Ethernet, > and you lose two packets in a row, you can be pretty sure the link is > down Or we have a very short buffer. ;-) But yes, maybe our recent instability in VPN links is more to the problems with routing we have, then really link instability. But we do have VPN links which go between countries. We have observed really crazy stuff on for example links between Croatia and Slovenia. Sometimes extra 100 ms appears on the link, because they have some issues at Internet exchanges, for example (so delay is added at the Internet exchange). I do not think that VPN links should be seen as Ethernet. For Ethernet I agree that if you loose two packets you have probably issues. But for VPN you have stuff in between, from bad ISPs, to MTU issues which make some packets get lost (especially while PMTU is in progress). > Second, the link quality estimator uses ETX, which is optimised for > multicast Hellos over WiFi links (it's quadratic in loss rate). > A different formula should be used for lossy wired links and for unicast > wireless tunnels. (But then, perhaps ETX works well enough on tunnels -- > I have no idea.) We have been using ETX with OLSRv1 on tunnels without visible issues. What do you use for ETX? ETX = 1 / (d_f x d_r) is for unicast (as described in the A High-Throughput Path Metric for Multi-Hop Wireless Routing paper). To my knowledge for multicast you should use ETX = 1 / d_f (as described in the High-Throughput Multicast Routing Metrics in Wireless Mesh Networks paper). So we know ETX equations for both unicast and multicast. Maybe Babel should support both? Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel instability in WLAN-SI
Hi! So luckily we do know which links are wireless and which are VPN, so we could configure that in the Babel configuration. About VPN, I think ideally, we would want a metric for VPN links which: - take RTT into the account - take packet loss into the account - take available bandwidth vs. used bandwidth into the account - makes it clear that the link does not interfere with other links (so no wireless interference) Also, at some installations maintainers prefer to use WiFi links if available, instead of VPN (because VPN can go over links where you pay by usage). Not sure how we could mark those links? Maybe we should have multiple links available? Wired, VPN, VPN-per-use, wireless? (Also, some VPN links go over wireless - like 4G wireless. So packet loss and RTT and stuff still very applies.) The last point is something I am unclear what happens if we mark VPN link as wireless and we use BabelZ? Why have you disabled packet-loss metric on VPN links? Just to lower the overhead of sending packets over? We would prefer to have it on, we do not care so much about that low overhead (fiber to homes in Slovenia). > Obviously, this is not recommended, since doing link quality estimation on > wired links is sub-optimal. What do you mean here? That quality is not computed optimally, or that it is sub-optimal from the perspective of link use (because it consumes the bandwidth to measure the link quality)? I do not see why computation of link quality would not work on the wired links as well as on WiFi? Mitar On Mon, Dec 14, 2015 at 10:53 AM, Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> wrote: >> BTW, how should VPN links be handled in this case? They are currently >> marked as wired, but they can also experience packet loss. Does this >> mean that bad VPN links can also cause huge amounts of control traffic? > > It depends. How likely are they to lose two Hellos in a row? > > Babeld marks a wired link as down whenever it loses two out of three > successive Hellos. If this only happens occasionally (loss probability is > below 2% or so), then it's fine. If this happens often, then you should > enable link quality estimation on them. > > In case of doubt, I suggest enabling link quality -- the really bad case > is not having link quality estimation on lossy links, the opposite case > (lq on lossless links) is inefficient but not too bad. If you want > a quick fix, just change your firmware to run link quality everywhere (-w). > > If very lossy tunnels are a common occurrence in your network, I'll > implement a metric specifically for them. But let's get your network > running stably first. (Nexedi are using babeld over a lot of tunnels, but > their tunnels are lossless, which is why we implemented RTT-based routing > for them.) > > -- Juliusz -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Bucket full, dropping packet
Hi! But it will be more complicated with upgrades, and more complicated assuring that things are really the same (same patched version of Babel, same kernel version, TCP/IP stack, sysctl settings, etc.). Mitar On Sun, Dec 13, 2015 at 1:00 PM, Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> wrote: >>> Ok, I'll see on Monday if I can get an extra VM before Christmas. >> >> Which VM system are you using? We might be able to generate you a >> ready-made image. > > Please don't -- I'll let our system administrators clone their usual > VMWare image, it's better for everyone if I use what they're familiar > with. > > -- Juliusz -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] wanted to map the babel network
Hi! On Sun, Jun 14, 2015 at 1:34 AM, Jernej Kos <jer...@kos.mx> wrote: >>> Yeah, link-local addresses of the current node are not reported by Babel >> >> Do you want me to add that? > > The reason why this would be nice is that it would limit the link-local > addresses to only those which are actually used by babeld. Because > currently I just have to report them all (I could cross-reference that > with interfaces in babeld configuration, but I think this would be too > much added complexity, so I just report all of them). Was this addressed? Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Bucket full, dropping packet
Hi! Hm, I thought that Babel was tested on large networks and that it was tested on simulated large networks? Or are we now the largest network using it and this is why we are getting in all this trouble? So this is just another academic project which looks good on the paper but in practice it is not really production grade? We had to turn of Babel in the network and go back to OLSRv1. So much for smooth transition. Mitar On Fri, Dec 11, 2015 at 10:29 AM, Jernej Kos <jer...@kos.mx> wrote: > Hello! > > On 11. 12. 2015 18:47, Matthieu Boutier wrote: >> Did you know where does this version comes from? Is there a packet's >> version, or whatever? > > I will add some code that dumps the whole packet. > >> It's really strange that an "Update" message could fail. After a >> quick look at the code, I think it should fail at line 513. Could >> you see if changing > > I will try. > > > Jernej > > > ___ > Babel-users mailing list > Babel-users@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] ANNOUNCE: babeld-1.6.3
Hi! https://github.com/jech/babeld/blob/master/CHANGES is not updated? Is default route in a special routing table patch in? Mitar On Thu, Oct 1, 2015 at 9:52 AM, Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> wrote: > Dear all, > > Babeld-1.6.3 is available from > > http://www.pps.univ-paris-diderot.fr/~jch/software/files/babeld-1.6.3.tar.gz > > http://www.pps.univ-paris-diderot.fr/~jch/software/files/babeld-1.6.3.tar.gz.asc > > For more information about babeld and the Babel routing protocol, please see > > http://www.pps.univ-paris-diderot.fr/~jch/software/babel/ > > Only minor changes this time -- specifying router ids is now done from the > config file, as requested by the Homenet folks, and minor changes to the > low-level kernel interfaces to behave better within containers. The other > changes recently requested (32-bit kernel priorities, using a distinct > routing table for the default route) should hit the repository soon. > > Enjoy, > > -- Juliusz > > 1 October 2015: babeld-1.6.3 > > * Changed the handling of kernel configuration and added the > skip-kernel-setup option. Thanks to Toke Høiland-Jørgensen. > * Added the option "router-id" and removed the flag "-R". This is an > incompatible change. > > ___ > Babel-users mailing list > Babel-users@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Specifying the routing table of exported routes
Hi! Any progress on this? I know that not yet many days have passed, but it is pretty urgent for us, because the network grew to the stage where OLSR routing is unstable so we would need to switch to Babel as soon as possible. Mitar On Thu, Aug 27, 2015 at 9:03 AM, Jernej Kos <jer...@kos.mx> wrote: > Hello! > > On 27. 08. 2015 15:16, Juliusz Chroboczek wrote: >> I think it's much cleaner to add filtering at the export stage. Something >> like >> >> export ip :: le 0 table 42 > > Yes, this would be great. > > > Jernej > > > ___ > Babel-users mailing list > Babel-users@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Specifying the routing table of exported routes
Hi! I think that putting routes of both routing protocols in the same table gets really messy and hard to debug. And prevents any policy routing rules we might want to apply. Mitar On Wed, Aug 26, 2015 at 3:49 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Then we can have the following order of routing tables on routers: babel olsr babel_default olsr_default Mitar, I'll be glad to implement the hack that you require, but let's please think whether we can manage to avoid it. What's wrong with putting both OLSR and Babel routes into a single table, and using a higher kernel priority for OLSR routes? If you do that, the most-specific rule will cause host routes to be preferred to default routes, and the kernel priority will be used to prefer routes from one routing protocol to the ones from the other when they have equal specificity. Babeld's kernel priority can be tuned using the kernel-priority config file directive. I have no idea whether something similar can be done with olsrd. Henning? -- Juliusz -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Specifying the routing table of exported routes
Hi! Just to give a bit of background, we need this to be able to run multiple routing protocols at the same time. This allows us to gradually transition to a new routing protocol (Babel). Then we can have the following order of routing tables on routers: babel olsr babel_default olsr_default Mitar On Wed, Aug 26, 2015 at 2:00 PM, Jernej Kos jer...@kos.mx wrote: Hello! Is it possible to specify the routing table of exported routes in babeld? So for example that the default route would be put into a separate routing table from the other exported routes? Jernej ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Roaming at layer 3
Hi! On Sun, Aug 9, 2015 at 2:16 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: So how you keep the mesh nature of your network while still providing this multi-channel roaming-enabled pockets of the network? The way I understand it, you have two (possibly virtual) interfaces on your nodes: - the mesh interface, on which the routing protocol is running; - the client interface, on which a DHCPv4 server is running. You only bridge the client interfaces -- the mesh interfaces are still a pure mesh, with no bridging nonsense. Yea, but what about channels. :-( For mesh interface you want to run on the same channel, and for client interface you want to run on different channels. Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Fwd: Why we switched to Babel
Hi! In the future we may implement roaming support which will let people keep their IP as they move around the city, but it will still switch after e.g. 10 minutes, so tracking people becomes much harder. What are ideas to implement roaming on L3? Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Roaming at layer 3
Hi! On Sun, Aug 9, 2015 at 1:43 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: If I understood correctly, they're not trying to support wide-scale roaming -- the roaming domains will be small and well-defined. Yes. But there is also another issue I have which is related to this topic but not completely. And that is that at such big venue locations with multiple nodes, where you want roaming, you also want nodes to be on different channels, because otherwise they are interfering with each other too much. So how you keep the mesh nature of your network while still providing this multi-channel roaming-enabled pockets of the network? Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Roaming at layer 3
Hi! Of course it can be solved with multiple radios, but that costs more. Also, even having two radios (2 and 5 GHz) for example is in fact not enough this days because you want AP to be on two bands as well, again on separate 5 GHz channels to not interfere with each other. Many clients can now use 5 GHz and to offload the 2.4 GHz spectrum we should be using that fact. I am trying to explain that we have a problem that we have competing needs: - for end-users we have a need that they should roam in houses/spaces and not have interference between APs, so the best would be to have each AP on a separate channels to other devices, using wired connections, ideally if there they are on the same switch, they should just connect directly, otherwise over the VPN tunnel via servers - for mesh operation you would need nodes to be on the same channel so that they can communicate to each other, so those who do not have Internet uplink, can still connect to the rest of the network Now, the issue is that these two things are conflicting. But I think we should try to find a solution. So one option I see is that we have all nodes using different channels, to maximize the use of the spectrum, on both 2.4 and 5 GHz. They create both AP and ad-hoc networks, but they do not care that ad-hoc links are not established because they have an uplink. In the case that a node does not have an uplink, then it scans the surroundings and if it finds our mesh ad-hoc network, it chooses the same channel and connects with ad-hoc network to that one AP. Now, the question is to what if there are multiple nodes around, which channel this uplink-less node should pick and when it should switch it to another channel. (The same problem in fact have the APs with uplinks as well, but they could at least communicate with each other and decide which channel one should pick.) One more problem is what happens if multiple nodes lose uplinks. Then it could happen that half of them pick one channel and another the other channel and then you have a split. The other option I see is to have a centralized node planing system. When a user registers a new node they tell if the node will have an uplink or not. If it will have, then the system allocates to the node a channel which interferes the least. If it will not have, then user can pick which closest neighboor the node should connect to and central system selects the channel so that the link is possible. This second approach has a benefit that also backbone connections could be done through the same system. Mitar On Sun, Aug 9, 2015 at 8:25 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Your understanding is correct. And, as you said, I also think that the issue can only be solved by having multiple radios on a node. I see now. And agreed about multiple radios. -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Fwd: Why we switched to Babel
Hi! On Sat, Aug 8, 2015 at 10:47 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: 1. BATMAN adds 32 octets of overhead to every frame; 2. BATMAN requires the same MTU on all segments. Are you sure about 2.? To my understanding, Batman simply fragments packets in that case? So it still works, but a bit slower. But that slow down is mostly visible only on higher-latency links. If you have tunnels, you might not see much issues because of the fragmentation. And for mesh (ad-hoc) connections you can still increase MTU on WiFi interfaces. Only on AP WiFi interface you would keep 1500 MTU. No? Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babeld merged with GPL headers against copyright holders' wishes
Hi! On Tue, Mar 27, 2012 at 5:34 PM, Outback Dingo outbackdi...@gmail.com wrote: and its not only about commercial gain, its more about security of a software stack and the reasonable additions that can be protected when added under MIT/BSD and not under GPL in certain arenas where it benefits society, in the monitoring of various infrastructures in a secure fashion within reason. Am I smelling security through obscurity here? Securing the code should never be the way for securing the system. If you are doing this, then you just add a false *sense* of security. Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babeld merged with GPL headers against copyright holders' wishes
Hi! On Tue, Mar 27, 2012 at 4:26 PM, Juliusz Chroboczek j...@pps.jussieu.fr wrote: without asking us for permission. I find that rude. This is the whole point of free software and culture movement: that you can do things with the work without having to ask the author for permission. That author states the rules and you can then do whatever you want without asking for permission if you play by that rules. This is *the main idea*. If you find this rude, then, sorry, you do not get the philosophy. Then you still live in the world of copyright where everything should be allowed by the copyright holder. And as far as I understood, they have contacted you. So they are doing even more then required. Required in the legal sense and also moral sense: because it cold be also morally implied that you accept GPLing your code because you licensed it initially in the way you did. For me this is a bit funny, very similar happened at our university, when professor gave his code under GPL, he didn't want to be bothered with this earthly things like licensing, just wanted code there. And then once somebody used this commercially he discovered that he does not like somebody benefiting from the code without he getting anything from that. He really found that rude. Not paying him? How they dare! Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Question about Babel
Hi! We are considering to finally move to Babel with our network in Slovenia, but have two questions: Does Babel support client roaming? At Battlemesh v5 Batman team presented really cool implementation of that which really supports seamless client roaming. Is there anything like that in Babel? The issue is that for really good seamless roaming some inter-layer information has to be leaked (the best way is to hook onto the WiFi driver and immediately when client associates you adapt the routes for him to point to this new node). Is this something Babel supports or is there a possibility it will support? Or do you see this as something some other part of the stack should take care? Does Babel support dynamic (run-time) configuration of interfaces it operates on, without the need of restarting the daemon? We are planing to use many many L2TP tunnels to connect nodes together, which will be created dynamically, so we will have to setup Babel to work on top of that as tunnels are created and removed. Can Babel handle this? Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Question about Babel
Hi! On Thu, Apr 12, 2012 at 3:46 PM, Outback Dingo outbackdi...@gmail.com wrote: Yupp im well aware of this, was just trying to clarify what the original poster was referring to Yes. You explained it well. So if I have APs connected together with Babel, can Babel help in some way when one AP (A) client migrates to another AP (B)? I would like that client keeps the same IP and all connections stay open. What it would be the way to setup this in a mesh using Babel to mesh APs together. its more of an AP / DHCP routing issue for mobile clients then anything babel related OK, but Babel can help. For example, when client moves from A to B, with adding a temporary route from A to B for that client's IP address. So that all traffic going for client to A can be rerouted to B. Does Babel even support moving /32 announcements from node to node dynamically? So when client gets IP, this IP is also announced on node A with /32 announce and once it moves to B, B starts announcing it. Sorry if my terminology is not correct. I am not a network guy. But I hope you will still understand what I asking. Or educate me what is proper terminology. Thanks. Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Question about Babel
Hi! Juliusz thank you for your explanations. Now I think I understand a bit more. OK, so such daemon which would allow roaming in combination with Babel in the sense I am hoping for does not yet exist. Do you maybe know if there is already some project hoping to implement that? Mitar On Thu, Apr 12, 2012 at 8:47 PM, Juliusz Chroboczek j...@pps.jussieu.fr wrote: So if I have APs connected together with Babel, can Babel help in some way when one AP (A) client migrates to another AP (B)? I would like that client keeps the same IP and all connections stay open. What it would be the way to setup this in a mesh using Babel to mesh APs together. [...] Does Babel even support moving /32 announcements from node to node dynamically? Of course, Mitar. Babel uses a very general mechanism known as redistribution. Redistribution is a very old idea, dating at least as far as the first Cisco multiprotocol routers; you'll find it described in detail in any networking book written in the last 20 years. Redistribution can be used to implement OLSR's HNA mechanism, BATMAN's client roaming, and a lot of other routing policies. The idea behind redistribution is that you don't statically setup routes that are being announced into the routing domain; instead, you specify which kernel routes (FIB routes) are going to be reannounced into the routing domain. A route that is so being reannounced is said to be redistributed. As you perhaps know, there are two implementations of Babel: the standalone babeld daemon, and the version integrated into Quagga. The twa do redistribution differently, and the following only applies to the standalone daemon. Redistribution is controlled by redistribute statements in babeld.conf. For example, an IPv4 Internet gateway has a default route that points to the Internet; you can ask babeld to redistribute it into the Babel routing domain by saying something like redistribute ip 0.0.0.0/0 le 0 which asks to redistribute any route that is within 0.0.0.0/0 (i.e. an IPv4 route) that has a prefix length less or equal to 0 (i.e. a default route). Similarly, if your node is maintaining a bunch of /32 routes, you can ask babeld to announce them into the Babel routing domain by saying redistribute ip 0.0.0.0/0 ge 32 There's a lot more you can say in babeld's filtering language, I'll let you check the babeld manual page[1] for more information. Unlike the techniques used in BATMAN, redistribution is modular: babeld is a routing daemon, it's not babeld's job to be monitoring whether there is a route to the Internet or whether a given client is associated to the current router. Hence, you need a different daemon that monitors the external routes and installs or uninstalls routes in the kernel. Here are a few examples: - a proper Internet gateway speaks BGP to your ISP. Hence, the BGP daemon is responsible for installing/uninstalling the default route that's being redistributed by babeld. - a lot of people cannot speak BGP to their ISP. In such circumstances, you may either simply redistribute the route installed by DHCP, or use babel-pinger[2] to monitor an Internet connection and install/uninstall a default route that babeld can redistribute. - you could write a daemon that monitors the set of associated clients and installs/uninstalls /32 routes to them. This daemon could be monitoring DHCP leases (if the DHCP lease time is short enough), or it could be monitoring ARP/ND messages, or it could be monitoring all IP packets. It's up to you. You'll find a few real-life examples of redistribution on http://mid.gmane.org/7ive3ry9r7@lanthane.pps.jussieu.fr (Note that this mail is very slightly obsolete, since recent babeld accepts to redistribute proto 3 routes, but only if the protocol number is specified explicitly in the redistribute statement.) Mitar, please realise that Babel might not be what you are looking for. BATMAN is a commercial project, and the BATMAN people try to solve their customers' problems in a timely manner. Babel is a research project, and as such it tries to do things right, which often takes more time than implementing a quick hack to solve a customer's issue. Hence, unless you're interested in spending the time needed to design the right thing to do, you might be more happy with BATMAN, which I'm sure is a fine routing protocol. -- Juliusz [1] http://www.pps.jussieu.fr/~jch/software/babel/babeld.html#sect6 [2] http://www.pps.jussieu.fr/~jch/software/babel/babel-pinger.html http://www.pps.jussieu.fr/~jch/software/files/babel-pinger-0.1.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-pinger-0.1.tar.gz.asc ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Question about Babel
Hi! On Thu, Apr 12, 2012 at 11:58 PM, Juliusz Chroboczek j...@pps.jussieu.fr wrote: (The people who asked me to write babel-pinger never actually used it, so I'm a little reluctant to spend time writing code unless somebody promises to at least test it.) Understandable. So, please, don't write it immediately. We are still evaluating possibilities. :-) Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [Battlemesh] Battlemesh-like experiment in Washington, DC
Hi! The Byzantium control panel is an application which allows the user to (de)configure network interfaces, add or remove them from a mesh, and enable or disable services and web applications running on a node. It runs on a node (listening only on the loopback interface) and is accessed with any web browser. Technically, it is a web application, but seeing as how Byzantium will package a couple of web applications for public use on a mesh anyway (Etherpad-lite, crypto.cat, status.net, and a few others) it made more sense to call it a control panel. Interesting. Just as an information, in our network (wlan slovenia) we have taken directly the opposite approach and made a centralized system for deploying nodes (centralized in the sense it is one of the services of the network, but the network itself still runs operates if this service is removed from operation, this server/system/service only streamlines node deployment (and prevents IP collisions so that it maintains ). The point we have seen is that web interface on the node takes simply too much time to maintain once you have many nodes which you want to configure the same (and update configuration and so on). It takes time to click all those things. And that it is still too technical for common people to use. So we have taken completely other approach: nodes without any web interface, where you have a service in the network which issues pregenerated firmware images with all configuration already in there. So you just select what hardware you have, where the node will be and everything else is done by the system (for power users you can also select additional OpenWrt packets and mangle with configuration, but it is not necessary). You flash the image, power it up and this is it. Now, the next step is to make this service distributed (like every node can be it) and we have best of both worlds. ;-) But currently we are making it modular, so that different networks can adapt it to their needs: http://dev.wlan-si.net/wiki/Nodewatcher IPv4. We considered IPv6, and in fact we get it for free with the Linux kernel, but not all applications are aware of or play nicely with it. Yes, but if everybody just waits for applications to be ready ... ;-) I think it is crucial especially for decentralized networks to start using it. Maybe instead of random IP allocation you could try some distributed IP allocation system where you would take some temporary IP and request what is free (using distributed hash storage or something). But yes, there were already so many other ideas for this problem discussed and yes, there is a problem of mixing layers. This is an interesting problem to us, and one of the things we have in mind once Byzantium is stable is correcting problems with interoperability. I would invite you to take part here: http://interop.wlan-si.net/ It is an initiative by many networks to find some common ground. As I see it is a bit more centralized that your approach (we are mostly using centralized node databases), but probably we could also find some common ground with you. For example, currently we are defining a common database schema to be able to describe our nodes in a common way so that we can then have common applications working over that. You could probably use the same schema internally in your control panel in a distributed way so that maybe some centralized system in your network could still fetch this data and use it (for example to draw a map or something). Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [Battlemesh] Battlemesh-like experiment in Washington, DC
Hi! and our control panel application What do you use for your control panel application? can pseudo-randomly choose RFC-1918 IP addresses for mesh interfaces if the user selects it. You do know birthday paradox? ;-) https://secure.wikimedia.org/wikipedia/en/wiki/Birthday_problem Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [Battlemesh] Battlemesh-like experiment in Washington, DC
Hi! We're writing a custom control panel in Python, using CherryPy for the web server and Mako for the templating system. What exactly is this control panel? What do you understand under this term? It is something running on the node? Or on the server? Is there some webpage with more about that? However, it is my hope that by providing a large enough address space (17,891,328) we can minimize the number of IP address collisions in a given mesh. If need be, we can always try a different approach. You are talking about IPv6 or IPv4 here?In IPv4 some MAC address + IPv6 prefix could be enough. In IPv4 is problem, that if you will take big address space you will have problems peering with other mesh networks. If this will be one day interesting to you. (At least in Europe we are slowly trying to connect all networks together.) Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] RFC 6126: The Babel Routing Protocol
Hi! Port 6697. Looks like IRC. ;-) Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Questions
Hi! But is this really Bellman-Ford algorithm? Because Bellman-Ford is a single-source algorithm and Babel in fact computes (distributed) all-source algorithm? Or you see Babel as an Bellman-Ford run multiple times, for each source ones? Because it is not really that as it reuses data it has about paths to other nodes. Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Questions
Hi! On Sun, Apr 3, 2011 at 8:29 PM, Juliusz Chroboczek j...@pps.jussieu.fr wrote: Because it is not really that as it reuses data it has about paths to other nodes. No, it doesn't. How not? If you have such topology: A -- B -- C When B runs its run then it learns the shortest path towards C. And when A runs its run and the shortest path between B and C is already found/calculated and it is not recalculated again (what would be if you would say that runs are independent). No? Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Questions
Hi! On Wed, Mar 30, 2011 at 6:15 PM, Juliusz Chroboczek j...@pps.jussieu.fr wrote: If you get me in touch with people who are actually interested in putting Babel on such a network, I'll be glad to work on the issue. I'm willing to generalise from a single example, but I'm not going to try to generalise from 0 examples ;-) I am just brainstorming now so that if/when we will talk with them that I will know pros/cons. Because mostly for HAM links IP will be overlayed over some their protocol anyway. So maybe from Babel's perspective it will be seen as one normal bi-directional link. Thanks for all the answers. Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Questions
Hi! I admit I have still not read the whole Babel's draft but I am skipping from sections to sections as I find them interesting. Does Babel require bidirectional reachability? In draft I read that Babel tries to determine bidirectional reachability, but I was not sure if this means only such links are taken into consideration for routing? In Cost Computation section it is written that if the txcost is infinite, then the cost is infinite so probably this means such links are seen as non-existent (worst cost). This is of course reasonable, as all packets require ACKs on link-level so at least something should be coming back. But does bidirectional reachability than imply also symmetric routing? Or can Babel decide on an asymmetric route? As I understand it can. But then why this artificial (?) requirement of bidirectional reachability? Shouldn't this be just left out and if packets get to the other side (probably with ACKs on link-level) then this is it, this is all we want to know for routing? There is probably a spelling error here: How a the txcost and rxcost are combined I must say that I have problems understanding the symbols in explanation of the Bellman-Ford algorithm, but probably this is because I am expecting something else. If I understand now the description correctly (and my test implementation of it in Haskell works correctly), then all nodes are computing shortest paths how they are reachable from other nodes. Not what can they reach? How/when do then nodes exchange this information? (I am not reimplementing Babel, just trying to port shortest path algorithm into my framework so that I can maybe play with other approaches than shortest path later on.) So what I am doing is that each node (name one B) sends packets to all its neighboring nodes about all its known shortest paths to know nodes. After each node (name one A) receives such packet it checks if the path over this node (B) is better than currently known path (taking into the account the cost of the edge from B to A). So what I am getting at the end is that each node (like A) has information about how is best for other nodes to send it packets. But this is not really useful. I would need information in other direction. Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] mv from darcs to git
Hi! On Tue, Mar 1, 2011 at 8:52 AM, Juliusz Chroboczek j...@pps.jussieu.fr wrote: Independently of the OpenWRT issues (which I'm confident Gabriel will solve), do people want the babeld, babelz and ahcpd repositories to move to Git? Git sucks, but it sucks less than it used to, and I'm okay with moving. To stir things even more: why not Mercurial? ;-) Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Last change to edit the Babel draft
Hi! On Sun, Feb 27, 2011 at 6:04 PM, err404 err...@free.fr wrote: for people live near from /tmp/lab (paris) may be we can come in /tmp/lab next 03 mars to speak and prepare WBMv4. with your ideas and may be more? I don' know if is good idea to come in /tmp/lab but why not ? If I understand correctly you are inviting me to /tmp/lab? Uh, I am from Slovenia, so this would require some traveling I do not believe by budget allows me. Sadly. I would be glad to visit you. Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Babel Multicast routing
Hi! On Mon, Feb 28, 2011 at 1:01 AM, Gioacchino Mazzurco gmazzurc...@gmail.com wrote: there is some plan to implement multicast routing on babel in short terms? +1 Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] How to cite Babel?
Hi! On Thu, Feb 24, 2011 at 11:22 AM, Juliusz Chroboczek j...@pps.jussieu.fr wrote: Juliusz Chroboczek. /The Babel routing protocol/. To appear as RFC 6126. 2011. Hm, will try to convert that into bibtex. Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] How to cite Babel?
Hi! How can I cite Babel in my thesis? Is there an article or at least (published) whitepaper I could cite? Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Wireless Battle Mesh v4 - Call for papers
Hi! The original announce by Juliusz says the event is from Wed 16th till Sun 20th. Your mail implies that it would start Mon 14th. Could anybody shed some light on this, please? Space is reserved from 14th on, but event itself will be from 16th on. But you are welcome to come before and help with preparing things, meet and talk and so on. Please read the web page: http://battlemesh.org/BattleMeshV4 The space is reserved for the whole week (14-20th) so people will start gathering during the previous weekend. So if time is not a problem, we recommend you to travel some days ahead. Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel vs. PWRP
Hi! Do you know how does Babel compare to Predictive Wireless Routing Protocol (PWRP)? http://www.tropos.com/technology/scalability.html Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] AHCP thoughts
Hi! On Tue, Jul 20, 2010 at 12:35 AM, Juliusz Chroboczek juliusz.chroboc...@pps.jussieu.fr wrote: (I'm actually wondering if Delay-Tolerant Networking, as opposed to Mesh Networking, is what you want to be working on.) I do not think so. DTN use store and forward so that data eventually reaches destination. I think more about organic structure where it is normal that some information is available at the moment and some not. Similar to how people interact. When you meet somebody you can get information form her and give some information to her. And with moving around (the city for example) you access different people and different information and give different information. You rarely store some information for somebody else and when you see her give her this information. It happens (like say cheers to this and this person when you see her) but it is not main characteristics and I see it is as a higher level (service level for example, some kind of relay messaging) in the network. Yes, I like social interactions and networks more. Especially trust networks. And this is why I see mesh networks as useful in such context. (By the way, If somebody knows a PhD study concentrated around trust networks I would be more then interested to hear about it.) But you gave me an interesting idea. Based on small world hypothesis it would be interesting to use such temporary mesh networks for relay messaging from a friend to a friend over friends (using a trust network). Could be an interesting social routing approach. Useful for some 1 April RFC. ;-) Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] [WLANware] [Olsr-dev] Announcing MeshApp, A Mobile Application for Wireless Mesh Networking
Hi! (Please reply to our talk mailing list and not news as the later is just for announcements. I have forwarded your previous replies there but please check any further followups to go there.) On Sat, Jun 12, 2010 at 1:29 PM, L. Aaron Kaplan aa...@lo-res.org wrote: On Jun 12, 2010, at 6:24 AM, Juliusz Chroboczek wrote: I believe the dot(1) format is usually sufficient as an abstract layer to describe the networks (for visualization purposes). Not really as we do not have graphviz available on all platforms. and of course you can visualize it via Java on the phone itself You can? You know of a decent visualization library in Java for a dot format? Then this could really be a good intermediate format. But I thought we would just use some lib and feed it with whatever (do not know which one for Java, though). This is really not protocol specific - once you have a topology graph at hand it does not really matter if you use dot or not. Oh, and happy learning Slovenian ;-) Well, french would be just as hard to learn ;-) But there is probably a little more benefit from learning French than Slovenian which is (badly) spoken by only 2 million people. It is like learning a Parisian dialect. ;-) Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] AHCP and IPv4 support
Hi! On Tue, Jun 8, 2010 at 9:17 PM, Henning Rogge hro...@googlemail.com wrote: Because there are not enough of them to generate them from MAC. With only 2^16 IPs it's a lot easier to get a collision. Why? You need only two? All nodes which already have a real IP could use the same link-local IP to listen for requests (it is not important which node respond) and all connecting nodes would have another link-local IP. OK, because multiple new nodes could try to connect to the mesh at the same time it would be useful to spread that IP over some broader range, like 2^16. But chance that a good hash function based on MAC which would produce this temporary IP address would have a collision in this short time-span (while two nodes are trying to get their IP) is slim, isn't it? Once it gets a real IP it would just start using the same link-local IP address as others. Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] AHCP and IPv4 support
Hi! On Tue, Jun 8, 2010 at 8:18 PM, Juliusz Chroboczek juliusz.chroboc...@pps.jussieu.fr wrote: Since AHCP's task is assigning IP addresses, AHCP needs to be able to communicate before it has assigned IP addresses (duh). In IPv6 this is easy -- just use link-local addresses. Why not use link-local addresses in IPv4? The we-all-know-and-love 169.254.* addresses? Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] AHCP and IPv4 support
Hi! On Mon, Jun 7, 2010 at 11:23 PM, Gabriel Kerneis kern...@pps.jussieu.fr wrote: You only need working link-local IPv6 communication, AFAIK. Which should work with Android = 2.0 if I understand correctly the above link (IPv6 over wifi works, IPv6 over mobile doesn't). So everything should be fine. But we would also like to support 2.0 versions. So is there no way it would work on just IPv4 or was this just something nobody cared for so there is no implementation for it? Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Ahcpd update in OpenWrt (quick HOWTO)
Hi! On Tue, Jun 1, 2010 at 2:32 PM, Gabriel Kerneis kern...@pps.jussieu.fr wrote: So that it can get an IP and be reachable via ssh for administration purposes Then all your nodes have the same SSH password/key? Or how do you know which one is on which IP? And how do you know when first connecting that the node you are connecting is really yours and not MiM node trying to get your password? Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Ahcpd update in OpenWrt (quick HOWTO)
Hi! On Mon, May 31, 2010 at 2:46 PM, Gabriel Kerneis kern...@pps.jussieu.fr wrote: Choose one of your stations to act as an ahcpd server. What happens if there is a network split? Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Ahcpd update in OpenWrt (quick HOWTO)
Hi! On Mon, May 31, 2010 at 8:52 PM, Gabriel Kerneis kern...@pps.jussieu.fr wrote: More seriously, you can have as many servers as you like, but be aware that: 1° the client will pick ONE server (the closest) and get every information from it. Consequence: you cannot use one server to distribute ip addresses and another one to distribute the dns and ntp servers. 2° the client will try to stick with one server as much as possible. If this server is unavailable when the lease expires, it will look for another one. 3° as a consequence, if you want to have several servers, you should: - duplicate the ipv6, dns and ntp fields on every server, - split your ipv4 address range in n (where n = your number of servers) and make each one distribute leases for (1/n)th of the range. This is due to the lack of synchronisation between the ahcp servers (necessary to survive a network split). OK. But what is then difference with running a dnsmasq on every node with DHCP where every node has its own IPv4 pool for clients? dnsmasq does not yet support IPv6 but is this then the only difference? Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] ETX metric for bandwidth limited links
Hi! On Tue, May 11, 2010 at 5:06 PM, Juliusz Chroboczek juliusz.chroboc...@pps.jussieu.fr wrote: Does it support asymmetric links? Yes. Maybe I have not asked the question correctly: does it selects (by default) in both directions the best path (even if they are different) or does it selects only one path which is the best for both directions. Is there some reason why would be prefer in our networks paths which are the same for both directions? Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel Android Maemo GUI
Hi! This year we got an Google Summer of Code entry for OLSR Android Maemo GUI: http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/freifunk/t127230758933 There was also an entry for Babel GUI (from Anthony Quillerou) but sadly there was not enough slots also for this. As I am a mentor for this project I would like also to at least try to make this GUI in a way that it would be possible to attach other routing protocol later on, for example Babel. But as I do not have any experience with Babel I would like to know if anybody would be willing to help with this? Maybe just checking and comment what we are doing or even better in parallel work on Babel version (so our student would do the GUI and OLSR part and this great volunteer would do just the Babel part). Anybody? My dream is to have one application which you install and when you connect to the mesh it detects the routing protocol and auto-configure itself and starts using it. Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ETX metric for bandwidth limited links
Hi! We are using OLSR in our wlan ljubljana open wireless network (http://wlan-lj.net/) so please forgive me that I am not really accustomed with Babel but I am researching a little how different protocols calculate ETX and how they make a routing decision based on it. Somehow I see that protocols tend to differ how they measure packet loss of links and how to determine network topology itself, how (and how fast) they react to changes, but analysis of this data, models they are using to predict future link behavior (what routing protocol in fact is - a predictor which try to predict best route), are quite simple and very often just a search for shortest path in a graph. From my experience I find this quite unsatisfactory as in a network with different kind of links (WiFi, ethernet, tunnels) packet loss itself is far from only factor influencing path performance. And even packet loss is used in a strange way. If packets loss is 1 minus a probability of packet being successfully transferred over a link then probability of a packet being successfully transferred over a path is a product of this probabilities. But in both OLSR and Babel ETX are summed together. Which does not have really a theoretical reason/model behind it (except of a similarity to (historical) routing protocols which are minimizing hops)? Or it does? I find it that it mostly works because we are using WiFi links where there is a hidden cost added to using a given link: that neighboring nodes have to stay quiet. It is in some way a half-duplex link. And this is why every hop costs (except for latency it also introduces). But it is a broken model to start with. I think that a better model should include: - packet loss (and packet loss along a given path) - half-duplex/full-duplex nature of a link (or a hidden cost on using the link on neighboring nodes) - bandwidth limits on a link - links where packet loss is a function of bandwidth use Also using all this data should not be simple calculation of a ETX and then searching for a shortest/less costly path but some combination of direct values. For example, routing protocol should be able to make asymmetric routes. Even more, it should probably be able to distribute packets over multiple links (which often exists in mesh networks) using information from bandwidth available on links. So I would like to know if there are any plans/ideas (or maybe there is already this) for such ETX metrics in Babel? As I understand Babel specially treats ethernet links but this is not something which would be just a special case of determining link quality/nature? How does it determine if a link is an ethernet link? Babel does not do load balancing routes? Does it support asymmetric links? As I understand currently it is possible to define your own ETX metrics but I do not see a clear way of adding bandwidth information to ETX without also changing the way (not just shortest path) routes are calculated. Mitar ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
