status update

[Dave Taht]

On Wed, Apr 18, 2012 at 8:20 AM, Francis Dupont <fdupont at isc.org> 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,
>
> => this is why I setup the laptop B4 to provide the CRA service on the
> link.  When the demo will be back in the lab, we'll use that.
>
>> and I would prefer we expend the time resources to make these tools
>> use shared libs to get that back under 2MB,
>
> => it is in the hands of the DHCP team (I just showed it is easy).
>
>> 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.
>
> => named uses library compiled with very different parameters
> so it is far less easy.

And as it uses libs with the same names as the dhcp libs, conflicts.

>> As for switching b4 dhcp servers, that costs an existing, very fully
>> featured gui interface to dnsmasq, the local ip database, etc.
>
> => another solution is to fix dnsmasq but IMHO it is not
> in the agenda...

git clone git://thekelleys.org.uk/dnsmasq.git

What I don't quite understand is the source(s)? of the conflict. Can't
SO_BINDTODEVICE be used everywhere?

commit 9380ba70d67db6b69f817d8e318de5ba1e990b12
Author: Simon Kelley <simon at thekelleys.org.uk>
Date:   Mon Apr 16 14:41:56 2012 +0100

    Set SO_BINDTODEVICE on DHCP sockets when doing DHCP on one interface
    only. Fixes OpenSTack use-case.

commit 1023dcbc9e358e42c005414b2f54b3a65daf3b8c


>> > 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.
>
> => arg! the ip command is not exactly the same than on standard Linux,
> same for ifconfig, same even for the bash (oops, ash)...
>
>> we need better logging by default (no -q option, anymore, PLEASE!).
>
> => note I *always* insisted on the flags which drop logging in
> my messages.
>
>> > 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.
>
> => good luck...
>
> Francis Dupont <fdupont at isc.org>



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