On Fri, Jan 13, 2017 at 8:11 AM, L. D. Pinney <ldpin...@yahoo.com> wrote:
> Go back to playing the guitar and smoking dope....that's what you do best.
I look forward very much to doing more of that... after lede ships.
In the interim, I have two fairly large testbeds setup to test lede -
the ATF patch, the dnsmasq-dnssec code, the bcp38 code, the dhcpv6-pd
code, the new bridging code, and babel integration are all high on my
list, along with sch_cake and the sqm-scripts. I have 5 lede platforms
under test - the archer c7v2, wndr3800, linksys 1200ac, uap-lite, and
picostation, with two more that I plan to add after testing interop
(edgerouter and an apu2). There are also 3 different brands of
cablemodem in the loop. Test clients include a dozen hackerboards
(kernels going back to 3.10), OSX, and Linux.
I'm perpetually testing edge cases and things that seem like they
should work, but don't. While things are vague and confusing (like,
babel-1.8's behavior being confusing in some instances) - and a piece
of a puzzle lands (like not restarting it as much, thus causing less
route retractions and floods) - I do tend to dump partial state about
the rathole I may have been going down.
I've been trying to come up with tests for understanding the true
effects of the multicast-unicast bridging code, for wifi primarily,
and simplifying. At the moment I'm more trying to test 3 layers of
lede dhcp-pd (bridged and routed scenarios) across gear that needs to
... instead of dealing with how all that feeds into babel source
specific routing - which is a combination of interactions between
netifd, babeld, and multicast/bridging.
> STOP CROSS POSTING YOU FSCKin' Clown Boy
If these projects want to write "no cross posting ever" into the
rules, I will gladly comply.
I hope you get your caps-lock key fixed.
I'm going to just filter out all further postings from you into my trash folder.
> On Saturday, January 14, 2017 12:06 AM, Dave Taht <dave.t...@gmail.com>
> On Fri, Jan 13, 2017 at 4:08 AM, L. D. Pinney <ldpin...@yahoo.com> wrote:
>> DAVE :
>> WILL YOU PLEASE STOP YOUR FSCKin' CROSS POSTING ???
> I did not start the cross-post in this case.
>> This is UNRELATED to the OpenWrt / LEDE DEV mailing list...as the change
>> been merged.
> Interop with routing protocols... and networking in general... does
> exist outside of the openwrt universe. In my case I am deeply
> concerned about what happens against older, deployed versions of
> Linuxes (and other OSes) with the new multicast-unicast bridge
> conversion code in lede. Babel tends to use it, and I am also testing
> (in lede!), as per the below, the dhcpv6-pd code, interop-ing with
> several devices.
>> F O
> I'm really sorry that you hate cross posting so much. It must be
> terrible to have to elide additional responses or deal with bounce
> messages on every 20th email from me. And it must be wonderful to be
> living in a world where all you have is openwrt/lede devices on the
> network and modern kernels everywhere.
>> On Friday, January 13, 2017 5:20 AM, Dave Taht <dave.t...@gmail.com>
>> On Thu, Jan 12, 2017 at 1:01 PM, Baptiste Jonglez
>> <bapti...@bitsofnetworks.org> wrote:
>>> Here is yet another OpenWRT-related change for babeld: I just merged
>>> support for babeld , after more than two years of lingering .
>>> The only user-visible changes should be:
>>> - babeld now logs to the system log (visible with "logread") instead of a
>>> file in /var/log. This is nice for embedded devices, where you don't
>>> want to write too much to the filesystem. It is still possible to
>>> explicitly configure babeld to use a log file;
>>> - babeld is now restarted automatically whenever it crashes;
>>> - the usual procd niceties: calling "/etc/init.d/babeld reload" will
>>> restart babeld only if the configuration has changed.
>>> Please test babeld 1.8.0-2 and report any resulting breakage. I would
>>> like this change (and the other compatibility change) to make it into the
>>> upcoming LEDE release, which is due to happen quite soon.
>> lede can dynamically insert/delete routes into tables from netifd
>> babeld can pull routes from "protos" but not tables.
>> I spoke with hedecker (? can't remember his email) about somehow
>> having a field to export routes into kernel protos in the lede network
>> file, he indicated he'd look at it in a few weeks.
>> (I wanted to get away from ever having to revise the conf file
>> dynamically, but it looks like not this release. Not having to restart
>> babeld as per the above is a nice improvement though and I'll get on
>> testing it this weekend. At the moment I'm going through some mild
>> hell with dhcpv6-pd on comcast and adding "sonic" fiber (with a HE
>> ipv6 tunnel. Will hopefully have 4 source specific gateways to play
>> with here)
>> In other other news the "rabeld" backport of the gentler route switch
>> change loses kernel routes on the vyatta (3.10 based) OS in the
>> edgerouter. :(. That said, haven't tested mainline babeld there yet.
>> It seems to work on debian.
>> For those fiddling with edgerouter's default 1.9.x OS, backports of
>> cake, iproute, and rabeld are presently here:
>>>  https://github.com/openwrt-routing/packages/pull/55
>>>  https://github.com/openwrt-routing/packages/pull/250
>>> Babel-users mailing list
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> Lede-dev mailing list
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
Let's go make home routers and wifi faster! With better software!
Lede-dev mailing list