Re: [Babel-users] Why we are discussing ARM [was: Cross-compiling to armhf]
Juliusz Chroboczek writes: > Nothing we have found is as nice as the old WNDR3700/3800. The CHIP is > marvelously cheap (cheap enough to give out to students!) and has flexible > power requirements, but it doesn't have wired Ethernet, and its wifi is > connected over SDIO, with everything that entails. The Turris Omnia is > badly overspecced, with a price to match. The Snickerdoodle is promising, > but it's currently vapourware, its WiFi sucks, and when combined with the > dual-Ethernet daughterboard it becomes fairly expensive. > > Things that we haven't been considering, Dave's enthusiasm notwithstanding: > > Raspberry Pi: doesn't run armhf userspace, no wifi, eth connected by USB; > Raspberry Pi v2/v3: requires binary blobs, wifi and eth connected over USB; > Beagleboard variants: look nice, but no wifi; > MeshSR: they did almost everything wrong. > > So, folks, if anyone has good experiences with cheap ARM boards that have > wifi and Ethernet and work well with a stock Debian userspace, I'm interested. I'd suggest to look into the Familiy of Olinuxino boards produced by Olimex: https://www.olimex.com/Products/OLinuXino/open-source-hardware or one of their system-on-module boards. They are in the same price range as the Pis but much more useful hardware. Also the company is very dedicated to free software and all boards are open hardware, which is a very useful thing for a research project - or actually most projects ... ;) I don't know how good they do wifi though - only use them as ridiculously powerful microcontrollers so far. Ethernet and SATA seem to perform well. HTH, Harald -- If you want to support my work: see http://friends.ccbib.org/harald/supporting/ or donate via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w or bitcoin 1FUtd8T9jRN1rFz63vZz7s2fDtB6d6A7aS ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Openwrt support for later versions of babeld
Hi Dave! I have been prototyping a new community wireless network down in Nicaragua. The terrain is hilly and well suited for meshy solutions... Nice. About a year ago I did some experiments with babel at funkfeuer.at in Vienna (which otherwise runs olsrd). I think I reported most issues back on this ML, but generally babel worked well and I consider it a serious alternative to olsrd... Perhaps we can share experience. I would be very much interessted once you have any results. I'm willing to build openwrt from scratch (and I think I have to, because most of my existing routers only have 4MB of flash and things like dnsmasq and udhcp can go in this configuration) ... but I do find the prospect somewhat scary. I have a server co-located with isc that I could host it on if anyone was interested. I recommend that you don't build the whole firmware from scratch but that you install the SDK for your openwrt version and your hardware and just compile the newest release of babel but don't touch the rest of the system unless you have to. What I did for my experiments was to take the openwrt-stable Makefile of babel, merge in the changes from openwrt-trunk, tweak it to my own needs and change the name of the package to something like 0xff-babel. This made deploying and maintaining much easier. Given that I can't easily run current babel right now (will it work with a 2.4.37 kernel?) My experiments are limited so far. I did try babel on some linksys routers with 2.4 series of kernels and it worked but there was some strange bug about corrupted IP addresses. The archive of this list should have the details ... 3) Is radvd still necessary in a babel/ahcp environment? Depends on what you are doing. If every node runs babel/ahcp then you don't need radvd, but if you announce whole /64 prefixes with babel and want to provide connectivity to hosts not running babel then you will need radvd (or some static setup). HTH, Harald ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] IPv4+6 routing in Babel
Henning Rogge hro...@googlemail.com: Am Donnerstag 03 September 2009 21:30:05 schrieb Gabriel Kerneis: On Thu, Sep 03, 2009 at 08:32:52PM +0200, Henning Rogge wrote: How do IPv4 nodes forward IPv6 traffic ? Via link-local address. The problem is that link-local do not always work in manets because manet broadcast domains are not 'closed'. Can you be more explicit on that problem? I can't think of a situation where we want to select a node as gateway but can't reach it via it's link local address... Note that as babel is not a link state protocol and doesn't have a global topology it need not care much about nodes outside it's broadcast domain. Harald ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] wired linked mesh, need to understand something on a simple topology
And on A: A/128 metric 0 (exported) B/128 metric 65535 refmetric 0 id 02:a0:24:ff:fe:cf:7c:47 seqno 51665 age 72 via tun0 neigh fe80::8c7:3280:8ae3:6882 (installed) metric 65535 has the special meaning unreachable which in the case of wired interfaces means that two consecutive hellos were missed. This seems like a problem in link sensing - either in babel or (more likely) in your setup. Since it is a link sensing problem you should be able to reproduce it with to nodes only. Can you confirm this? To find out more: Try to get some debug output from babel to see when hellos/ihus are sent/received. Once you have this info it should be pretty obvious what's wrong. In case it is just package loss on the tunnel: Setup babel.conf to force an ETX metric on the tunnel interface. Harald Harald ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] link costs
I have solved this special problem by configuring the device as a brouter (bridging olsr related traffic, routing babel related traffic) and installing babel on this device too. Interesting -- how do you do that? arptables? Could you show your setup? The brouter setup is pretty much straight forward: | r...@fonerabridge:/tmp# ebtables -t broute -L | Bridge table: broute | | Bridge chain: BROUTING, entries: 1, policy: ACCEPT | -p IPv6 -j DROP (Luckily we decided to use babel together with v6 - that makes this kind of stuff rather easy.) But the tricky part is setting a bridge up that works in ad-hoc mode. I started out with some recent kamikaze, recompiled the kernel with the bridge-netfilter patch enabled (so that bridged frames go through arptables) and installed some mac rewriting and arp rewriting rules, because the ad-hoc mode needs proper source mac addresses to correctly ACK the frames. We use this setup on foneras (routers as cheap as 6 EUR), the details can be found at http://texas.funkfeuer.at/~harald/firmware-0.3/ In case you have some spare fonera and want to try it yourself, you will need the following files: fonerabridge-vmlinux.lzma openwrt-atheros-root.squashfs bridge-minimal.tgz 0xff-config-bridge_0.3.tgz I have put quite some effort to make sure that this setup behaves well in all cases for IPv4, but I never tried to get IPv6 work. For IPv6 I think the brouter setup is all we need. I'm currently thinking of something like interface eth* wireless no cost 128 Would this make babel listen on all interfaces eth*, that it can find or would babel only listen on those interfaces given on the command line. I'm thinking of the latter. In the latter case it might be a cause of user errors that the interface configuration is split in two parts, one on the command line, the other one in the config file... The way I see it -- /etc/babel.conf is the source of configuration data, while the command line is the source of information about actions to be taken. In other words, I'm making a distinction between what needs to be done (given on the command line), and how to do it (given in /etc/babel.conf) . I see. But I fear that people will rename some interface, for example because the tunnel endpoint has changed, change it on the command line but forget about the config file. I babel handles this gracefully, then nobody might notice for quite some while ... But I agree that the distinction might be tenuous -- it might make more sense to unconditionally add all interfaces listed in /etc/babel.conf (and hence disallow wildcards). Opinions? Yes, I think I would prefer this over splitting the configuration in two parts. An other possibility would be to have the entire interface configuration on the command line (similiar to how is now). This would need a rewrite of the command line parser to allow mixing options and interfaces: Both would be read from left to right, later options overriding earlier ones. Example: babel -c 1 vlan0 -c 256 eth1 -w vlan1 would mean: vlan0 wireless no (autodetected) cost 1 vlan1 wireless yes (forced) cost 256 eth1 wireless yes (autodeteced) cost 256 I'm not sure if I'd prefer the command line or the config file for interface configuration: I think route filtering is mostly a matter of site policy and pretty static while interface configuration might often be changed. So it might make sense the have it on the command line. But on the other hand as you add more features to babel, the command line might become clumsy... Harald ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] link costs
(If you don't pay attention to user-interface issues, you end up with Xkb. Or Git. If you do pay attention, you end up with xkeycaps. Or Darcs. I'd much rather Babel were in the latter camp.) :) I agree, though I happily use git in cases where its features can be put to good use. I'm not quite decided yet (I need to sleep over it), but right now I'm tempted to take the union of the interfaces listed on the command line with those listed in the config file. Ok, that might be useful too ... But two questions come to my mind: For interfaces specified on the command line, there will always be used some default values? If an interface is specified both on the command line and in the config file: Which one takes precedency? Harald ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
