[Cerowrt-devel] stuff that can be dropped from rc8 #113

[Cerowrt-devel] stuff that can be dropped from rc8 #113

[Dave Taht]

What I am going to try to do here is outline the packages we can
easily drop from rc8
in order to meet the main goals of cerowrt - first and foremost -
creating a test tool to
help fix bufferbloat. We can always add this stuff back in later, with
funding, or with
people (other than me) doing the development, build, integration, and test work.

This involves making some hard choices about reducing things on the roadmap
down to a sane level on the amount of resources we will have next quarter.

http://www.bufferbloat.net/projects/cerowrt/roadmap

1) bind9.

I'm glad we got it working. It's a great proof of concept. Seeing
DNSSEC work was awesome

A) However, bind-latest doesn't build anymore for some reason, and I
don't know why.
B) until bug #113 is fixed - and it sure as hell doesn't need to be
fixed on a embedded system -
    there's no point in DNSSEC. Nobody has fixed it, we simply don't
have the resources to
    do it ourselves.
C) even with 'proof of concept' of the dhcp-dns automagic naming
scheme, we have no
    working version of that now that can be applied for general usage.
This too, does
    not need to be developed on an embeddded system.

D) dnsmasq is better integrated with the gui and 'just works

2) ISC-ntp

A) It's big, complex, and ALSO isn't building at the moment.
B) busybox-ntp is integrated with the gui and just works.

I note we can make a step forward towards getting dnssec to work right
by hacking up
that version of ntp to do pre and post 'I got time' scripts.

As for bug #113

I have poked deeply into the uclibc library and discovered it's
getaddrinfo routine
is a cheap hack on top of gethostbyname. Poking into ntp itself did not show
a decent concept of 'get dns, fail, try something else, then validate'...

But:

I'm not expert at any of these subsystems, and me spending any more time on it
than I already have this year does not seem productive.

Eliminating these two packages from the build knocks out bugs #113, #205,
#239, #238, #233, #280, #281. It would be good to throw all these over the
wall to isc's bug system and have tracking numbers to deal with there.

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

Re: [Cerowrt-devel] stuff that can be dropped from rc8 #113

[david]

neither of these tools are relavent to bufferbloat, so I don't see any 
reason to use them in cerowrt.

be very leery of including stuff because its 'good' or it's the 'right 
way to do things'

if it's not commonly deployed today, there are probably reasons for that. 
pick your battles. Cerowrt is not designed to make a 'next gen frouter', 
it's to research fixes for bufferbloat, If a tool doesn't directly affect 
bufferbloat, use the default instead.

David Lang

On Tue, 6 Dec 2011, Dave Taht wrote:

> What I am going to try to do here is outline the packages we can
> easily drop from rc8
> in order to meet the main goals of cerowrt - first and foremost -
> creating a test tool to
> help fix bufferbloat. We can always add this stuff back in later, with
> funding, or with
> people (other than me) doing the development, build, integration, and test work.
>
> This involves making some hard choices about reducing things on the roadmap
> down to a sane level on the amount of resources we will have next quarter.
>
> http://www.bufferbloat.net/projects/cerowrt/roadmap
>
> 1) bind9.
>
> I'm glad we got it working. It's a great proof of concept. Seeing
> DNSSEC work was awesome
>
> A) However, bind-latest doesn't build anymore for some reason, and I
> don't know why.
> B) until bug #113 is fixed - and it sure as hell doesn't need to be
> fixed on a embedded system -
>    there's no point in DNSSEC. Nobody has fixed it, we simply don't
> have the resources to
>    do it ourselves.
> C) even with 'proof of concept' of the dhcp-dns automagic naming
> scheme, we have no
>    working version of that now that can be applied for general usage.
> This too, does
>    not need to be developed on an embeddded system.
>
> D) dnsmasq is better integrated with the gui and 'just works
>
> 2) ISC-ntp
>
> A) It's big, complex, and ALSO isn't building at the moment.
> B) busybox-ntp is integrated with the gui and just works.
>
> I note we can make a step forward towards getting dnssec to work right
> by hacking up
> that version of ntp to do pre and post 'I got time' scripts.
>
> As for bug #113
>
> I have poked deeply into the uclibc library and discovered it's
> getaddrinfo routine
> is a cheap hack on top of gethostbyname. Poking into ntp itself did not show
> a decent concept of 'get dns, fail, try something else, then validate'...
>
> But:
>
> I'm not expert at any of these subsystems, and me spending any more time on it
> than I already have this year does not seem productive.
>
> Eliminating these two packages from the build knocks out bugs #113, #205,
> #239, #238, #233, #280, #281. It would be good to throw all these over the
> wall to isc's bug system and have tracking numbers to deal with there.
>
>