status update

Dave Taht dave.taht at gmail.com
Wed Apr 18 14:13:43 UTC 2012


On Wed, Apr 18, 2012 at 1:17 AM, Francis Dupont <fdupont at isc.org> wrote:
> I don't know what happened exactly for the demos (note the plural)
> yesterday. We had a problem because the WNDRs have no ISC DHCPv4
> servers but there are some ways to fix this (other than adding the
> missing (big) binary, for instance using a CRA service for the whole
> "WAN" link).

6+MB of binary is rather untenable, and I would prefer we expend the
time resources to make these tools use shared libs to get that back
under 2MB, and if at all possible, make it use the existing bind 9.9.0
version of these libs, which would get us under 500k or so.

As for switching b4 dhcp servers, that costs an existing, very fully
featured gui interface to dnsmasq, the local ip database, etc.

> On my side on a Linux (vs. xxxWRT) based SD-B4 (aka CPE laptop)
> the setup is controlled by a rc script with start/stop commands
> so ready for the next step, i.e., the reconfiguration handling
> (soft way vs rebbot).

In the last few minutes of the demo attempt, I gained some insight as
to what was going wrong. I managed to get the xxxWrt b4 to finally get
through the aftr. It turns out that inserting a route with a metric
seems to be required.

we need better logging by default (no -q option, anymore, PLEASE!).

On top of these other issues, last month I'd reported a huge
performance slowdown doing an ipv6 tunnel, and crashes, in the lab.
Robert and I I have been able to isolate and fix most of that, the
gory details are here:

http://www.bufferbloat.net/issues/360

(short summary, ipv6 packets were being sent through core routines
like checksums, unaligned, causing 100,000s of traps)

There are other problems we may be encountering:

http://www.bufferbloat.net/issues/349

and #356, 353, 367, and 364

Most of these are fixed in my current tree, but 360 is a can of worms
that is going to take a few iterations to get right.

> Note there is nothing yet about multicast: no idea of what should
> be done, in particular at the AFTR side.

I'd requested the hardware to test SSM (single source multicast)
several weeks ago. It arrived sunday, and I've been too busy to even
think about it. In my chat with alain he seems to think that the code
we got from that intern was enough to do the job he wanted...

... but it was obvious he hadn't looked at it. I'm preparing to take a
look at it again, but I think I'll need a dose of strong coffee.

>
> Regards
>
> Francis Dupont <fdupont at isc.org>
> _______________________________________________
> sdcpe-devel mailing list
> sdcpe-devel at lists.isc.org
> https://lists.isc.org/mailman/listinfo/sdcpe-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net


More information about the sdcpe-devel mailing list