[Cerowrt-devel] cerowrt 3.3.8-17: nice latency improvements, some issues with bind

[Török Edwin]

On 08/17/2012 09:05 PM, Dave Taht wrote:
> I'm widening the distribution of this email a little bit in light of
> the benchmark results (somewhat too far) below, and some of the other
> issues raised.

[ok, will write a separate reply for the benchmark numbers]

> 
> On Fri, Aug 17, 2012 at 1:52 AM, Török Edwin
> <edwin+ml-cerowrt at etorok.net> wrote:
>> However I've encountered some issues with bind. After powering on the router this morning DNS wasn't working,
>> and logread showed a lot of errors from bind about a broken trust chain on every domain name.
>> Any idea what could've caused this behaviour?
> 
> This is http://www.bufferbloat.net/issues/113 (relevant bugs have also
> been filed in the dnssec and ntp databases)
> 
> a long standing circular problem between getting accurate time via ntp
> and dns, so that dnssec can be enabled.

I was using unbound on openwrt for dnssec before and I haven't noticed this problem.
However I had some .ro time servers configured, and apparently they use quite a wide range
for their RRSIG, so maybe I was just lucky not to hit a situation where both .ro and .org would fail to validate.
RRSIG   NS 5 2 7200 20120819122953 20120720122953....
RRSIG   NSEC 8 1 86400 20120824000000 20120816230000 ...

While the .org RRSIG has quite a recent timestamp:
org.                    900     IN      RRSIG   SOA 7 1 900 20120907184119 20120817174119

Added the .ro timeservers to cerowrt now, and will see if the problem occurs again.

>> Another minor issue is that p910nd and luci-app-p910nd were not available via opkg install, but I found them on openwrt.org, so that works now.
> 
> I don't know what they are but I can enable them in the next build.

Thanks, they are a simple way to share your USB printer across the network without running CUPS on the router itself.

> 
>> DHCPv6-PD had to be configured manually of course, same as with openwrt, the difference is that I only get IPv6 on wired interfaces now,
>> and not on wireless.
>> That seems to be by design because the interfaces are not bridged anymore and I get only a /64 from my ISP (slan_len 0), so can't really create
>> more sub-networks from it.
> 
> As multiple providers seem to think that a single /64 "is all you
> need", despite the prevalence of guest and other sorts of secondary
> networks on ipv4. This is a HUGE problem on the current native ipv6
> deployments.
> 
> Note that it's not exactly fair to blame the providers, most of the
> home CPE gear they are dealing with can barely handle ipv6 in the
> first place, being based on ancient kernels and specifications. That
> gear is improving, all too slowly, with things like openwrt/cerowrt in
> the lead.... (apple seems to be doing fairly well, too)
> 
> Having only a single /64 delegated makes ipv6 unusable IMHO.

Still usable on my main machine, a pain to make it work with VMs though.
(only way I could make it work was to bridge them to host's ethernet).

> 
> I (or rather juliusz) solved the single /64-only problem years ago by
> switching to using babel and ahcp, which pushes out ipv6 /128 ips.
> This method has the added benefit of making switching between multiple
> wired and wireless APs utterly transparent, even for long held TCP
> connections.

Thanks, will have to try that out.

> 
> I run my own networks this way whenever possible, as it's *really
> nice* to be able to unplug and not lose 20 ssh connections, and plug
> back in, to get bandwidth, and have babel figure out the right way to
> go automagically.
> 
> However fixing both the APs and the hosts (via adding ahcp and babel)
> is kind of fixing a global infrastructure issue that is hard to get
> the rest of the world to agree to, and things like network manager
> don't think this way, either... But I'm glad to see progress being
> made in homenet towards having a flooding prefix distribution protocol
> based on something like ahcp, this will cut down on NAT usage in ipv4
> and lead to a more flexible network in the future. - and I'm sure more
> and more native deployments will delegate /60s or better in the
> future.
> 
> Using dhcpv6 it is also possible to do allocations of /80s but this
> breaks the 95% of all devices that only can do SLAAC.
> 
> It is best to get at least a /60 delegation from the ISP.

They probably won't listen. For the amount I pay them I'm happy I get IPv6 at all :)

> 
> My way of coping with the half-arsed single /64 delegation ipv6 native
> deployments I've dealt with thus far has been 6to4 and 6in4, which do
> /48s.

I get slightly higher throughput in IPv6 though (75 Mbps vs 45 Mbps).
Apparenly ISP forgot to shape my IPv6 traffic the same way it does with my IPv4.

Although... if I have QoS enabled in cerowrt and I set download speed limit to 47000 kbit/s
I'm still able to do 62000kbit/s with wget.
If I set the limit to 27000 then wget -4 speed drops to 24000 kbit/s, but -6 speed stays the same.

Doesn't QoS apply to IPv6 as well?

> IF you'd like to have more bandwidth back, you can jiggle the qlen_*
> variables in the debloat script up, but remember that tcp's reaction
> time is quadratic as to the amount of buffering. I'd be interested in
> you repeating your benchmark after doing that? The difference between
> 3 buffers and 8 is pretty dramatic...

Will do, and report back (to both ML).

Thanks for the detailed reply.

--Edwin