Re: [Babel-users] Diversity Routing for the Babel Routing Protocol
I see no good reason to merge the drafts: all current extensions are logically independant, at least at the protocol level. I agree. All the more so since the three extension drafts have different authors and are therefore written in very different styles, and it would therefore be a lot of work to combine them into a uniform document. Regarding Z3 and RTT, you're right, it's not exactly clear. The current implementation of Z3 applies the diversity factor *after* all other costs are computed, included the one induced by babel-rtt. Huh? RTT and Z3 work at completely different places -- RTT tweaks the cost computation, while Z3 changes the announced metric. In order to apply both, you just apply both, so you end up annoucing a metric that was tweaked by Z3 and was originally computed by RTT. No trouble. Now one could imagine two extensions that tweak the same part of the algorithm, in which case you'd need to think carefully about interaction, but that's not the case with the currently implemented four extensions. -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] TLV and sub-TLV space: allocation policy
01.07.2014, 17:22, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr: Dear all, In order to get the extension protocol published, I need to define a policy for allocating TLV numbers. The reviewer has suggested First-Come-First-Served with public reference, but is also willing to accept plain FCFS. IANA allocation policies are defined in RFC 5226: http://tools.ietf.org/html/rfc5226#section-4.1 I assume the reviewer means Specification Required, which sounds good to me. The only negative effect I can see is that we'll need to freeze and document a new extension before we can be assured of getting a TLV number, which should not be to onerous. I guess I should reserve 8 (or 16?) values for Experimental Use (or Private Use?). Advice? (Denis, I'm particularly interested in your opinion.) Hi all. Specification Required today seems most workable for everybody in foreseeable future, I finally understood it includes Designated Expert, which I suggested in the past. The idea of an explicit Experimental pool looks good (in the past I suggested 32 values at the end of the namespace). As far as I get it, Private would stand for permanent proprietary allocations whether Experimental would be right to support developing new code until it is ready to request its own permanent allocation(s). After browsing other protocol registries on the IANA web-site in the past it looked more convenient to have one registry for Babel with two sub-registries rather than a separate registry for TLVs and sub-TLVs. This probably still applies. For the reference below is a verbatim excerpt from that old off-list message (Re: Babel extension mechanism (IANA registry draft), dated 2013-06-27): --- Registry full name: Babel Routing Protocol Parameters Registry abbreviated name: babel-parameters Sub-registry full name: Babel TLVs Sub-registry abbreviated name: tlvs Sub-registry technical requirements: Assignments consist of a Babel TLV Type value and its associated name. The value is an integer in the range 0-255 recorded in decimal. The name is a terse ASCII string. Designated expert: Juliusz Chroboczek j...@pps.univ-paris-diderot.fr +-+---+ | Range | Registration Procedures | +-+---+ | 0-127 | Expert Review | | 128-223 | Expert Review | | 224-255 | Reserved for Experimental Use | +-+---+ Sub-registry initial assignments/reservations: ++-+--+ | Value | Name| Reference| ++-+--+ | 0 | Pad1| RFC6126 | | 1 | PadN| RFC6126 | | 2 | Acknowledgement Request | RFC6126 | | 3 | Acknowledgement | RFC6126 | | 4 | Hello | RFC6126 | | 5 | IHU | RFC6126 | | 6 | Router-Id | RFC6126 | | 7 | Next Hop| RFC6126 | | 8 | Update | RFC6126 | | 9 | Route Request | RFC6126 | | 10 | Seqno Request | RFC6126 | | 11 | TS/PC | draft-ovsienko-babel-hmac-authentication | | 12 | HMAC| draft-ovsienko-babel-hmac-authentication | | 13 | Source-specific Update | work in progress | | 14-255 | Unassigned | | ++-+--+ Sub-registry full name: Babel Sub-TLVs Sub-registry abbreviated name: sub-tlvs Sub-registry technical requirements: Assignments consist of a Babel Sub-TLV Type value and its associated name. The value is an integer in the range 0-255 recorded in decimal. The name is a terse ASCII string. Designated expert: Juliusz Chroboczek j...@pps.univ-paris-diderot.fr +-+---+ | Range | Registration Procedures | +-+---+ | 0-127 | Expert Review | | 128-223 | Expert Review | | 224-255 | Reserved for Experimental Use | +-+---+ Sub-registry initial assignments/reservations: +---+-+--+ | Value | Name| Reference|
Re: [Babel-users] TLV and sub-TLV space: allocation policy
Specification Required today seems most workable for everybody in foreseeable future, I finally understood it includes Designated Expert, which I suggested in the past. Sorry for not following up at that time, Denis, but we've got different timings -- there's very little energy I can devote to Babel during term time. After browsing other protocol registries on the IANA web-site in the past it looked more convenient to have one registry for Babel with two sub-registries rather than a separate registry for TLVs and sub-TLVs. Thanks. I'll see with the IETF reviewers. +-+---+ | Range | Registration Procedures | +-+---+ | 0-127 | Expert Review | | 128-223 | Expert Review | | 224-255 | Reserved for Experimental Use | +-+---+ I'm open to discussion, but I'm planning 0-127: Specification Required 128-144: Experimental Use 145-254: Specification Required 255: Reserved The idea about the Experimental range is that it should be easy to decode by sight in a hexdump. Hence the choice of values. -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] TLV and sub-TLV space: allocation policy
On Wed, Jul 2, 2014 at 2:32 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: I'm open to discussion, but I'm planning 0-127: Specification Required 128-144: Experimental Use 145-254: Specification Required 255: Reserved What do you think about moving Experimental Use to 240-254 ? This way experimental plus reserved would be 0xf0 - 0xff. And it would give you a continuous Specification Required range. Henning Rogge ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] fun with babeld, and tools for measuring ETX for Babel meshes
Henning Rogge hro...@gmail.com wrote: The best would be to get the RX power right from the radio. Does babel currently get any info that way? No. Contrary to pretty much everyone's intuition, RSSI is not a good predictor of packet loss. Yes... RSSI is a good indicator in mobile scenarios that something changed, but not what kind of change to expect. I'm looking at fixed wireless, not mobile. I'm moving only because I'm trying to determine where to put the repeaters. After revieweing the screenshots, I realized that we did indeed lose signal around the spot that I anticipated we would, as MTR shows packet loss by highlighting the hop where it dies, but my assistant did not know that. So we might do it again after a call I have in 5 minutes. BabelWeb seems to be node.js... is that gonna fit on an NetGear3800? Now the kernel is already measuring stuff in order to choose a rate. The current plan is to ask the gentle kernel for its conclusions, and pick a metric based on that (idea due to Dave). The data is already being exported by netlink in recent kernels (code due to Antonio Quartulli), so it should be a fairly simple thing to do. How much unicast traffic does Babel send over links to each neighbors on its own? By my random tcpdump observations, several packets per minute, but not as many as a dozen. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Fwd: New Version Notification for draft-jonglez-babel-rtt-extension-00.txt
---BeginMessage--- A new version of I-D, draft-jonglez-babel-rtt-extension-00.txt has been successfully submitted by Juliusz Chroboczek and posted to the IETF repository. Name: draft-jonglez-babel-rtt-extension Revision: 00 Title: Delay-based Metric Extension for the Babel Routing Protocol Document date: 2014-07-02 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-jonglez-babel-rtt-extension-00.txt Status: https://datatracker.ietf.org/doc/draft-jonglez-babel-rtt-extension/ Htmlized: http://tools.ietf.org/html/draft-jonglez-babel-rtt-extension-00 Abstract: This document defines an extension to the Babel routing protocol [BABEL] that uses the delay to a neighbour in metric computation and therefore makes it possible to prefer lower latency links to higher latency ones. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ---End Message--- ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] fun with babeld, and tools for measuring ETX for Babel meshes
On Wed, Jul 02, 2014 at 09:54:55AM -0400, Michael Richardson wrote: BabelWeb seems to be node.js... is that gonna fit on an NetGear3800? No. The usual approach is to have a ssh tunnel from your computer running node.js to your router (or to have a netcat forwarding). You can also just run babelweb locally on your computer and get a view of the network from this node. The README has more details: https://github.com/kerneis/babelweb/blob/develop/README.md#monitoring-remote-babel-instances Best, -- Gabriel ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] TLV and sub-TLV space: allocation policy
I'm open to discussion, but I'm planning 0-127: Specification Required 128-144: Experimental Use 145-254: Specification Required 255: Reserved The idea about the Experimental range is that it should be easy to decode by sight in a hexdump. Hence the choice of values. It would also be possible to delegate experimental range detection to protocol analyzers as soon as the registry has been settled. It could be printed like this: Experimental-0xNN, Length MM (that's similar to TCP option codes printing in tcpdump) -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Diversity Routing for the Babel Routing Protocol
On Wed, Jul 2, 2014 at 4:57 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: I see no good reason to merge the drafts: all current extensions are logically independant, at least at the protocol level. I agree. All the more so since the three extension drafts have different authors and are therefore written in very different styles, and it would ^ This is my point. therefore be a lot of work to combine them into a uniform document. for the authors, not the readers Regarding Z3 and RTT, you're right, it's not exactly clear. The current implementation of Z3 applies the diversity factor *after* all other costs are computed, included the one induced by babel-rtt. Huh? RTT and Z3 work at completely different places -- RTT tweaks the cost computation, while Z3 changes the announced metric. In order to apply both, you just apply both, so you end up annoucing a metric that was tweaked by Z3 and was originally computed by RTT. No trouble. And we've just demonstrated that it is confusing, even to the authors of the IDs. Now one could imagine two extensions that tweak the same part of the algorithm, in which case you'd need to think carefully about interaction, but that's not the case with the currently implemented four extensions. I note that I was not suggesting combining the auth draft with these. Secondly, I was also hoping for an extended example of why diversity helps on longer paths as per my first email. -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Diversity Routing for the Babel Routing Protocol
Regarding Z3 and RTT, you're right, it's not exactly clear. The current implementation of Z3 applies the diversity factor *after* all other costs are computed, included the one induced by babel-rtt. Huh? RTT and Z3 work at completely different places -- RTT tweaks the cost computation, while Z3 changes the announced metric. And we've just demonstrated that it is confusing, even to the authors of the IDs. Don't blame Baptiste, it is a difficult topic. There's good reason why we're the one of the only production-quality protocols in the world that support hybrid metrics. (There's IGRP, not sure about IS-IS.) It might be interesting to write up everything we've learnt on the subject, but that's more work than just an off-the-cuff comment on a mailing list. Secondly, I was also hoping for an extended example of why diversity helps on longer paths as per my first email. I've added a second example. Is there anything else you had in mind? -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] bug in finding the channel on ap-mode connections
CeroWrt runs babel on ad-hoc, ethernet, and ap-mode connections all at the same time by default. We name interfaces a bit weirdly to make for easier iptables rules: Ethernet is ge00 and se00 (wan, and lan in openwrt parlance), ap-mode is usually on gw00, gw10, sw00, and sw10, and ad-hoc is gw01 and gw11 (the first digit indicates the radio number, the second the interface number, the first letter [g]uest or [s]ecure, second letter [w]ireless or [e]thernet. This makes writing a rule for guests or secure one pattern match instead of 4 rules. Anyway... in ethernet, adhoc or station mode, babel figures out the channel number of the interface ok, but on the ap-mode (master) mode, it logs stuff like this at startup and periodically thereafter. Couldn't determine channel of interface gw00: Invalid argument. Couldn't determine channel of interface gw00: Invalid argument. Couldn't determine channel of interface gw10: Invalid argument. Couldn't determine channel of interface gw10: Invalid argument. Couldn't determine channel of interface sw00: Invalid argument. Couldn't determine channel of interface sw00: Invalid argument. kernel_route(ADD): File exists Couldn't determine channel of interface gw00: Invalid argument. Couldn't determine channel of interface gw10: Invalid argument. Couldn't determine channel of interface sw00: Invalid argument. Couldn't determine channel of interface gw00: Invalid argument. Couldn't determine channel of interface gw10: Invalid argument. Couldn't determine channel of interface sw00: Invalid argument. Couldn't determine channel of interface gw00: Invalid argument. Couldn't determine channel of interface gw10: Invalid argument. Couldn't determine channel of interface sw00: Invalid argument. Couldn't determine channel of interface gw00: Invalid argument. Couldn't determine channel of interface gw10: Invalid argument. Couldn't determine channel of interface sw00: Invalid argument. Couldn't determine channel of interface gw00: Invalid argument. Couldn't determine channel of interface gw10: Invalid argument. Couldn't determine channel of interface sw00: Invalid argument. I don't know what happens on bridged interfaces. I'm not even sure what it should do on a bridged interface, as most commonly what we see are ethernet bridged to both 2.4 and 5ghz radios. -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] bug in finding the channel on ap-mode connections
Anyway... in ethernet, adhoc or station mode, babel figures out the channel number of the interface ok, but on the ap-mode (master) mode, it logs stuff like this at startup and periodically thereafter. It's the kernel answering EINVAL to SIOCGIWFREQ. Is there a different API that would work better? Babeld will do the reasonable thing, which is to assume worst case behaviour for this interface -- it interferes with all other wireless interfaces. I don't know what happens on bridged interfaces. The same worst-case assumption. Only solution is to unbridge. -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] killing myself with a configuration error
I was fiddling with filtering out cero's /27s with the method described in the previous thread, using the blackhole route to the covering /24 and redistribute ip 0.0.0.0/0 le 24 allow in the conf file and a command line of babeld -D -z3 -c /etc/babeld.conf ge00 se00 gw00 gw01 gw11 sw00 sw10 sw01 That does indeed work. Elsewhere on the network instead of seeing the former /27s and /32s exported I see a single /24 and the /32s root@roof-to-office:~# ip route | grep 172.21.2 172.21.2.0/24 via 172.20.142.9 dev eth0 proto 42 onlink 172.21.2.1 via 172.20.142.9 dev eth0 proto 42 onlink 172.21.2.5 via 172.20.142.9 dev eth0 proto 42 onlink 172.21.2.12 via 172.20.142.9 dev eth0 proto 42 onlink 172.21.2.65 via 172.20.142.9 dev eth0 proto 42 onlink 172.21.2.77 via 172.20.142.9 dev eth0 proto 42 onlink 172.21.2.129 via 172.20.142.9 dev eth0 proto 42 onlink 172.21.2.161 via 172.20.142.9 dev eth0 proto 42 onlink 172.21.2.224 via 172.20.142.9 dev eth0 proto 42 onlink cutting the number of routes exported in half. I was kind of hoping to be rid of most of P2P announcements also... Interestingly, on the next hop out, I see root@archer-test:~# ip route | egrep '172.21.2|172.21.50' 172.21.2.0/24 via 172.21.18.13 dev se00 proto babel onlink 172.21.2.1 via 172.21.18.13 dev se00 proto babel onlink 172.21.2.5 via 172.21.18.13 dev se00 proto babel onlink 172.21.2.12 via 172.21.18.13 dev se00 proto babel onlink 172.21.2.65 via 172.21.3.11 dev ge00 proto babel onlink 172.21.2.77 via 172.21.18.13 dev se00 proto babel onlink 172.21.2.129 via 172.21.18.13 dev se00 proto babel onlink 172.21.2.161 via 172.21.18.13 dev se00 proto babel onlink 172.21.2.224 via 172.21.3.11 dev ge00 proto babel onlink (this is a bridged interface on the same box) 172.21.50.0/24 via 172.21.3.11 dev ge00 proto babel onlink 172.21.50.2 via 172.21.3.11 dev ge00 proto babel onlink 172.21.50.4 via 172.21.3.11 dev ge00 proto babel onlink The ge00 and se00 devices are effectively equivalent (they are both going through the same edgerouter on different ports), I assume that diversity is playing a role here, in part because .65,.129,.161 do not have a channel associated with them due to the bug noted in the previous email, but are probably listed as interfering. Call it 'mistaken cost multipath' - which is not a bad thing! And then, I goofed, combining that with the original openwrt babel conf file which has lines like: config filter option 'ignore' 'false' option 'type' 'redistribute' option 'if' 'se00' option 'action' 'metric 96' in it, with that setup. The results were interesting. Babel ran amuck, eating nearly all the cpu, flooding the network, and having the following ill effects: netlink_read: recvmsg(): No buffer space available kernel_route(ADD): File exists kernel_route(ADD): File exists netlink_read: recvmsg(): No buffer space available netlink_read: recvmsg(): No buffer space available Warning: bucket full, dropping unicast packetto fe80::221:63ff:fe2f:f2f4 if gw01. Warning: bucket full, dropping unicast packetto fe80::221:63ff:fe2f:f2f4 if gw01. Warning: bucket full, dropping unicast packetto fe80::221:63ff:fe2f:f2f4 if gw01. Warning: bucket full, dropping unicast packetto fe80::221:63ff:fe2f:f2f4 if gw01. Warning: bucket full, dropping unicast packetto fe80::221:63ff:fe2f:f2f4 if gw01. Warning: bucket full, dropping unicast packetto fe80::260a:64ff:fecc:247d if sw00. Warning: bucket full, dropping unicast packetto fe80::221:63ff:fe2f:f2f4 if gw01. Warning: bucket full, dropping packet to sw00. Warning: bucket full, dropping packet to gw01. Warning: bucket full, dropping packet to sw00. Warning: bucket full, dropping unicast packetto fe80::260a:64ff:fecc:247d if sw00. Warning: bucket full, dropping packet to gw01. Warning: bucket full, dropping packet to sw00. Warning: bucket full, dropping unicast packetto fe80::221:63ff:fe2f:f2f4 if gw01. Warning: bucket full, dropping packet to sw00. Warning: bucket full, dropping unicast packetto fe80::260a:64ff:fecc:247d if sw00. Warning: bucket full, dropping packet to gw01. Warning: bucket full, dropping packet to gw01. Warning: bucket full, dropping unicast packetto fe80::221:63ff:fe2f:f2f4 if gw01. Warning: bucket full, dropping packet to sw00. Warning: bucket full, dropping unicast packetto fe80::260a:64ff:fecc:247d if sw00. Warning: bucket full, dropping packet to gw01. Warning: bucket full, dropping unicast packetto fe80::221:63ff:fe2f:f2f4 if gw01. Warning: bucket full, dropping unicast packetto fe80::260a:64ff:fecc:247d if sw00. Warning: bucket full, dropping unicast packetto fe80::221:63ff:fe2f:f2f4 if gw01. Warning: bucket full, dropping unicast packetto fe80::260a:64ff:fecc:247d if sw00. Warning: bucket full, dropping unicast packetto fe80::221:63ff:fe2f:f2f4 if gw01. Warning: bucket full, dropping unicast packetto fe80::260a:64ff:fecc:247d if sw00. Warning: bucket full, dropping unicast packetto fe80::221:63ff:fe2f:f2f4 if gw01.
Re: [Babel-users] killing myself with a configuration error
I was kind of hoping to be rid of most of P2P announcements also... What do you mean by P2P? Everything's P2P in Babel. (We don't do centralised protocols here at Babel Towers.) If you mean the host routes (/32 and /128), you can say redistribute local deny to get rid of them. (You could also read babeld's manual page, I guess.) The results were interesting. Babel ran amuck, eating nearly all the cpu, flooding the network, and having the following ill effects: Okay, that's interesting indeed. You apparently managed to get babeld into a feedback loop, and the token bucket prevented it from flooding your network. (We care about the integrity of your network here at Babel Towers.) Could you please send the full configuration? I.e. babeld's command line in full, together with any files mentioned on the command line, including the files generated by UCI, if any. -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] killing myself with a configuration error
On Wed, Jul 02, 2014 at 06:58:59PM +0200, Juliusz Chroboczek wrote: including the files generated by UCI, if any. UCI does not generate any file, it builds a huge command-line (and yes, this is a bug: https://github.com/openwrt-routing/packages/issues/33). -- Gabriel ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] killing myself with a configuration error
On Wed, Jul 2, 2014 at 9:58 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: I was kind of hoping to be rid of most of P2P announcements also... What do you mean by P2P? Everything's P2P in Babel. (We don't do centralised protocols here at Babel Towers.) If you mean the host routes (/32 and /128), you can say redistribute local deny to get rid of them. (You could also read babeld's manual page, I guess.) Heh. Despite any outward appearances to the contrary, I have done very little to optimize babel in the past - babel's defaults are sane and just work - as they should. My fiddling now is that the network has got larger, and is about to start carrying potentially least 5x more routes than it did before, so I thought I'd try to optimize, clean up, and clarify what I was doing before deploying. If I can make cero's default configuration simpler, all the better. I like very much to hear there's a formal bug reporting system starting to come into play. A +10 to attempts to improve the conf file, and move it into procd! Another +10 if it could parse uci or ubus directly. The results were interesting. Babel ran amuck, eating nearly all the cpu, flooding the network, and having the following ill effects: Okay, that's interesting indeed. You apparently managed to get babeld into a feedback loop, and the token bucket prevented it from flooding your network. (We care about the integrity of your network here at Babel Towers.) Could you please send the full configuration? I.e. babeld's command line in full, together with any files mentioned on the command line, including the files generated by UCI, if any. The simplest thing from my perspective would be to request you fiddle with the near-final version of cerowrt on your wndr3800s and offer suggestions and improvements. http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.44-6/ I can send along the related openwrt and babeld conf files, but there are a ton of interfaces involved that would be hard to deal with. and it seems possible we ended up with a near bogus command line. -- Juliusz -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] killing myself with a configuration error
Could you please send the full configuration? I.e. babeld's command line in full, together with any files mentioned on the command line, including the files generated by UCI, if any. The simplest thing from my perspective... Please send me the command-line that caused Babel to run amock. -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] killing myself with a configuration error
The simplest thing from my perspective... Please send me the command-line that caused Babel to run amock. Sorry if that sounded dry, Dave. I do appreciate your help with that. -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] killing myself with a configuration error
On Wed, Jul 2, 2014 at 11:05 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Could you please send the full configuration? I.e. babeld's command line in full, together with any files mentioned on the command line, including the files generated by UCI, if any. The simplest thing from my perspective... Please send me the command-line that caused Babel to run amock. -- Juliusz attached is the command line generated and the babeld.conf -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article /usr/sbin/babeld -D -I /var/run/babeld.pid -z 0,128 -c /etc/babeld.conf -L /tmp/babeld.log -C 'interface ge00' -C 'interface se00' -C 'interface sw00' -C 'interface sw10' -C 'interface gw10' -C 'interface gw00' -C 'interface gw01 rxcost 384' -C 'interface gw11' -C ' redistribute if se00 metric 96' -C ' redistribute if sw00 metric 256' -C ' redistribute if sw10 metric 192' -C ' redistribute if gw00 metric 256' -C ' redistribute if gw10 metric 192' -C ' redistribute if gw01 metric 256' -C ' redistribute if gw11 metric 192' ge00 se00 sw00 sw10 gw10 gw00 gw01 gw11 babeld.conf Description: Binary data ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] killing myself with a configuration error
On Wed, Jul 2, 2014 at 11:09 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: The simplest thing from my perspective... Please send me the command-line that caused Babel to run amock. Sorry if that sounded dry, Dave. I do appreciate your help with that. np! I have implemented time based routing of my emotional states. Before 10PM ip 0.0.0.0/0 if juliusz metric 32 After 10PM ip 0.0.0.0/0 if juliusz blackhole During teaching season: ip 0.0.0.0/0 if juliusz unreachable -- Juliusz -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] killing myself with a configuration error
Nothing wrong with your config, Dave. I'd need a -d3 log of when Babel gets into the feedback loop. -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] killing myself with a configuration error
My assumption is that I will blow up a goodly portion of my network, but that the damage will be constrained to immediate hops only. ? And: I should also get a tcpdump of what happens. I am running a test series at the moment; I can do it after lunch (T+1.5 hours). I'll need some popcorn for the show, also. On Wed, Jul 2, 2014 at 11:29 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Nothing wrong with your config, Dave. I'd need a -d3 log of when Babel gets into the feedback loop. -- Juliusz -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] fun with babeld, and tools for measuring ETX for Babel meshes
Gabriel Kerneis gabr...@kerneis.info wrote: On Wed, Jul 02, 2014 at 09:54:55AM -0400, Michael Richardson wrote: BabelWeb seems to be node.js... is that gonna fit on an NetGear3800? No. The usual approach is to have a ssh tunnel from your computer running node.js to your router (or to have a netcat forwarding). You can also just run babelweb locally on your computer and get a view of the network from this node. okay, I saw that point later on when reading. The computer you see my son operating is actually an Android tablet; maybe can run node.js. Maybe not, I will try. It has a debian chroot, 4 CPUs and 1GB ram... One thing I realized while looking at my data is that I seem to have lost connectivity to the 3800 that was right there in the wagon. That shouldn't be unless when babeld lost connectivity it caused RAs to stop or something. I guess a tcpdump while roaming is in order. I'll setup the babelweb for the nodes at my house using either an ssh port forward, or perhaps just TCP with ACL; but presumably that won't tell me more than node43 no longer reachable -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] fun with babeld
The computer you see my son operating is actually an Android tablet; maybe can run node.js. Maybe not, I will try. It has a debian chroot, 4 CPUs and 1GB ram... jch@ariane:~$ ps l $(pidof babelweb) F UID PID PPID PRI NIVSZ RSS WCHAN STAT TTYTIME COMMAND 0 0 27658 1 20 0 651068 70488 ep_pol Sl ? 26:32 babelweb That's 70 megs, after not being restarted for weeks. One thing I realized while looking at my data is that I seem to have lost connectivity to the 3800 that was right there in the wagon. That shouldn't be unless when babeld lost connectivity it caused RAs to stop or something. Babeld disables RAs, just like every IPv6 routing protocol. The simplest solution is to set up a static IPv6 address on your node before starting babeld. (The IPv6 specs are very clear: RAs are sent by routers, and received by hosts. Under Linux, enabling forwarding has the side effect of disabling reception of RAs. There are very valid reasons why this needs to be done.) -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] killing myself with a configuration error
On Wed, Jul 02, 2014 at 11:14:51AM -0700, Dave Taht wrote: attached is the command line generated and the babeld.conf /usr/sbin/babeld -D -I /var/run/babeld.pid -z 0,128 -c /etc/babeld.conf -L /tmp/babeld.log -C 'interface ge00' -C 'interface se00' -C 'interface sw00' -C 'interface sw10' -C 'interface gw10' -C 'interface gw00' -C 'interface gw01 rxcost 384' -C 'interface gw11' -C ' redistribute if se00 metric 96' -C ' redistribute if sw00 metric 256' -C ' redistribute if sw10 metric 192' -C ' redistribute if gw00 metric 256' -C ' redistribute if gw10 metric 192' -C ' redistribute if gw01 metric 256' -C ' redistribute if gw11 metric 192' ge00 se00 sw00 sw10 gw10 gw00 gw01 gw11 Are you sure redistribute if X metrix Y is what you want to use? And not out if X metric Y? With the former, for each installed route pointing to interface X, you will redistribute it. If you have a high number of neighbours, interfaces and routes, this will probably generate a lot of routes (in the worst case, each router will redistribute all routes) I might be wrong, this would mean that babeld blows up because of the large number of routes. I'm not sure how many routes it would take, but probably a lot. Could you provide the output of the local interface? (nc ::1 33123 on the router when it is about to blow up) Or could it be a bad interaction with the source-specific babel you have on your network? Baptiste pgpCvr82j9aMB.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
