[Babel-users] ANNOUNCE: babeld-1.6.0

Sat Apr 18 05:47:04 UTC 2015

On Fri, Apr 17, 2015 at 10:27 PM, Gabriel Kerneis <gabriel at kerneis.info> wrote:
> Le 2015-04-18 05:26, Dave Taht a écrit :
>>
>> On Fri, Apr 17, 2015 at 8:04 PM, Dave Taht <dave.taht at gmail.com> wrote:
>>>
>>> While I am happy to see this switchover...
>>>
>>> A) it would have be nice if you did not break the build, and had
>
>
> Note that I did *not* push to the for-14.07 branch, only to master (in case
> it make any difference).

Not for those trying to test chaos calmer, which is freezing shortly.

>>> checked for dependencies on babels and fixed those too. there was only
>>> one... but it happened to be on code (hnetd) I am testing tomorrow
>>> morning at 10AM PDT. A find . -type f -name Makefile | xargs grep
>>> babels revealed that only hnetd depended on it.
>
>
> Sorry about that, I reverted the deletion of babels.

THANK YOU! Hopefully tonights build will land in time.

>
>>> B) It is not clear what else broke with hnetd with this change to
>>> babels from babeld. The two sets of init and config scripts had grown
>>> to differ quite a bit.
>
>
> Mostly, in my understanding, because babels never picked up the clean-up by
> Baptiste.

Well, there were also dependencies within hnetd.

>
>>> C) You missed adding ipv6-subtrees support to the init script, and as
>>> all of openwrt has ipv6_subtrees support in the kernel, the default
>>> should be true for this os, not the default in babel, which is false.
>
>
> This wasn't in babels as far as I can tell. Does it matter for people not
> doing source-specific stuff? Can't we assume that those who do will set it

Babels hard-compiled in IPV6_SUBTREES support, which landed in all
the barrier breaker kernels.

It is the only version of the subtrees support (and the most efficient
version) that has been extensively tested, to my knowledge.

While I would argue in favor of someone testing the non-ipv6 subtrees
code path, I dont think that should be done in openwrt at this point.
IPV6_SUBTREES "just works" on that. Stick with it.

And it is sort of my expectation that everybody will be using the source
specific stuff in the near term. It truly is the hot new feature.

> up? I'm a bit nervous to add this change by default right now, especially
> knowing how some openwrt users sometimes cherry-pick packages from snapshots
> while still running a kernel from an old release (they shouldn't, but they
> do).

I would not be nervous.

Furthermore I personally would like the "new" rtt timestamp option to
always be on
in openwrt also, the cost is not much, and it is the simplest way to distinguish
on the wire that this is the new babel. I would like the new VERSION
related stuff in the ss_tables branch to also land in the next version.

As near as I can tell the rtt_timestamp does not break anything I have
deployed (something like 11 different versions of babel), and it will be
useful (to me) in actually measuring what actually happens in wifi and
ethernet under load.

After all the patches land in the tcpdump that openwrt uses. (sigh)

>
>> D) you did not incorporate any of the source specific openwrt
>> babels init and config mods like
>>
>>         append_parm "$cfg" 'src_ip' 'src-ip'
>>         append_parm "$cfg" 'src_eq' 'src-eq'
>>         append_parm "$cfg" 'src_le' 'src-le'
>>         append_parm "$cfg" 'src_ge' 'src-ge'
>
>
> Ah, I had warned people on this very list about changes to filter rules, and
> then I managed to miss them because they weren't in the release notes. My
> mistake, will fix.

OK. I am totally ok with, like distributing patches that people can test for
robustness. If you want to take that on, I will gladly test. If not, I
can attempt
to merge the rules myself.

> Speaking of which, would you prefer to have free-form filter rules in the
> config instead (while keeping backwards-compatibility of course)?

Honestly what I would prefer would be a version of babel that could be
compiled to
interface over the ubus or just use the uci style config file. Less
chance for error that way.

I actually tried to produce that but the available documentation on
that portion of openwrt is pretty sparse, and the examples, less than
complete.

>> E) And there was a longstanding patch in babels that I hope made babeld,
>> or was solved some other way...
>>
>> 0001-Allow-routes-with-source-128-for-SAS-on-Linux.patch
>
>
> I'm not applying patches I don't understand, but I'm happy to include it if
> Juliusz approves it.

So far as I know it is required to have ipv6 work right at all on
local applications on an otherwise default gateway as nobody has yet
come up with a way to standardize source address selection when they
would specify IN_ADDR_ANY. I can certainly see apps and/or the kernel
being modified to do more of the right thing, but this patch did
little harm, so far as I know.

That patch was important if for example, you want ipv6 dns to "just
work", and numerous other local apps probably fail without it.

but I am a little unclear on the exact need for it today. It was, as
is, extensively tested and I had assumed til now it was in 1.6.

>> It would be best if someone could revert commit:
>>
>> 23e20773d8b5c90dad99702e030ce86ccf3344f3
>
>
> Done.

Thanks again. I return now to trying to figure out how the heck hnetd
works in the first place.

>
> --
> Gabriel Kerneis

-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67