On Fri, Apr 17, 2015 at 10:27 PM, Gabriel Kerneis <[email protected]> wrote: > Le 2015-04-18 05:26, Dave Taht a écrit : >> >> On Fri, Apr 17, 2015 at 8:04 PM, Dave Taht <[email protected]> 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 _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
