status update

[Dave Taht]

another big issue is that the usb based ethernet devices on the
laptops keep changing their names out from under us.

It is sane to fix that via udev somehow, but also sane to make the
configuration scripts more robust, so that for example it would search
for the right mac or ipv6 addr on the interface, then do the right
thing.

On Wed, Apr 18, 2012 at 7:13 AM, Dave Taht <dave.taht at gmail.com> wrote:
> 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



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