[Cerowrt-devel] cerowrt-3.10.36-4 released

[Cerowrt-devel] cerowrt-3.10.36-4 released

[Dave Taht]

+ dnsmasq 2.69 with dnssec enabled by default
+ possible workaround for wifi bug #442 in increased qlen_*
+ fix for ipv6 access to https://gw.home.lan:81
+ fresh merge with opewrt
+ update to 2048 bit cert generation
+ fix for openssl heartbleed (fix also in -3) bug
+ tested for an hour
+ change to sqm to basically always use "simplest.qos" on inbound

- I'm very, very, very, very, very, very, very, very, very tired.

I really hope this results in a stable cerowrt. Please beat the hell out of it.

I'm already planning a vacation.

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Dave Taht]

as usual, it can be found at:
http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.36-4/

On Wed, Apr 9, 2014 at 11:45 PM, Dave Taht <dave.taht@gmail.com> wrote:
> + dnsmasq 2.69 with dnssec enabled by default
> + possible workaround for wifi bug #442 in increased qlen_*
> + fix for ipv6 access to https://gw.home.lan:81
> + fresh merge with opewrt
> + update to 2048 bit cert generation
> + fix for openssl heartbleed (fix also in -3) bug
> + tested for an hour
> + change to sqm to basically always use "simplest.qos" on inbound
>
> - I'm very, very, very, very, very, very, very, very, very tired.
>
> I really hope this results in a stable cerowrt. Please beat the hell out of it.
>
> I'm already planning a vacation.
>
> --
> Dave Täht
>
> NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]

On Wed, 09 Apr 2014 23:45:23 -0700, Dave Taht said:
> + dnsmasq 2.69 with dnssec enabled by default
> + possible workaround for wifi bug #442 in increased qlen_*
> + fix for ipv6 access to https://gw.home.lan:81
> + fresh merge with opewrt
> + update to 2048 bit cert generation
> + fix for openssl heartbleed (fix also in -3) bug
> + tested for an hour
> + change to sqm to basically always use "simplest.qos" on inbound
> 
> - I'm very, very, very, very, very, very, very, very, very tired.
> 
> I really hope this results in a stable cerowrt. Please beat the hell out of it.

Trying to flash openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin
gets me this message at the bottom of the screen:

The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform.

Looks like something in Luci is busted, as trying to re-upload a 3.10.36-3
image blows chunks with the exact same error message, and -3 is what I'm
already running....

Any debugging guesses?  My first guess was a full filesystem, but:

root@bogon-gateway-1:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs                    7424       388      7036   5% /
/dev/root                 7424      7424         0 100% /rom
tmpfs                    63132      4368     58764   7% /tmp
/dev/mtdblock5            7424       388      7036   5% /overlay
overlayfs:/overlay        7424       388      7036   5% /
tmpfs                      512         0       512   0% /dev

there's plenty of room in /tmp to pull down an 8M image and work on it?


[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Robert Bradley]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

On 10/04/2014 14:48, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 09 Apr 2014 23:45:23 -0700, Dave Taht said:
>> + dnsmasq 2.69 with dnssec enabled by default
>> + possible workaround for wifi bug #442 in increased qlen_*
>> + fix for ipv6 access to https://gw.home.lan:81
>> + fresh merge with opewrt
>> + update to 2048 bit cert generation
>> + fix for openssl heartbleed (fix also in -3) bug
>> + tested for an hour
>> + change to sqm to basically always use "simplest.qos" on inbound
>>
>> - I'm very, very, very, very, very, very, very, very, very tired.
>>
>> I really hope this results in a stable cerowrt. Please beat the hell out of it.
> Trying to flash openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin
> gets me this message at the bottom of the screen:
>
> The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform.
>
>

Try using TFTP with the *factory.img file instead, since that worked for me.

On a separate note, this new release seems to work fine, unlike my
attempts to automate configuration changes!  The only two issues I had were:

- I had to add my cable modem configuration address to the BCP38
exception list (192.168.100.1).  This gets used for nothing except
configuration and checking the modem logs so this is understandable.  I
also end up adding a static route anyway since if Internet breaks, I
need a route to the modem...
- dnsmasq's default of dnssec-check-unsigned broke my DNS, since my ISP
servers do not support DNSSEC.  In that case, everything winds up as
failing.

Other than that it seems fine for the moment.

-- 
Robert Bradley



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

Robert Bradley <robert.bradley1@gmail.com> writes:

> - I had to add my cable modem configuration address to the BCP38
> exception list (192.168.100.1).  This gets used for nothing except
> configuration and checking the modem logs so this is understandable.  I
> also end up adding a static route anyway since if Internet breaks, I
> need a route to the modem...

If you add a 'scope link' route on the wan interface, the BCP38 code
*should* pick this up automatically and add an exception. Would be cool
if you could test this :)

> - dnsmasq's default of dnssec-check-unsigned broke my DNS, since my
> ISP servers do not support DNSSEC. In that case, everything winds up
> as failing.

That's an interesting failure mode. FWIW you can point it at
8.8.8.8/8.8.4.4 instead if you want dnssec verification :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Robert Bradley]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

On 10/04/2014 15:32, Toke Høiland-Jørgensen wrote:
> Robert Bradley <robert.bradley1@gmail.com> writes:
>
>> - I had to add my cable modem configuration address to the BCP38
>> exception list (192.168.100.1).  This gets used for nothing except
>> configuration and checking the modem logs so this is understandable.  I
>> also end up adding a static route anyway since if Internet breaks, I
>> need a route to the modem...
> If you add a 'scope link' route on the wan interface, the BCP38 code
> *should* pick this up automatically and add an exception. Would be cool
> if you could test this :)

Just tested this now and it works fine. :)

>> - dnsmasq's default of dnssec-check-unsigned broke my DNS, since my
>> ISP servers do not support DNSSEC. In that case, everything winds up
>> as failing.
> That's an interesting failure mode. FWIW you can point it at
> 8.8.8.8/8.8.4.4 instead if you want dnssec verification :)

I was tempted to leave it as-is, but tested it now with a custom
/tmp/resolv.conf.manual file and it also works well with added DNSSEC
checks.

-- 
Robert Bradley



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 134 bytes --]

Robert Bradley <robert.bradley1@gmail.com> writes:

> Just tested this now and it works fine. :)

Cool, thanks for testing! :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 322 bytes --]

On Thu, 10 Apr 2014 15:06:25 +0100, Robert Bradley said:
> Try using TFTP with the *factory.img file instead, since that worked for me.

I'd like to at least try to figure out why the sysupgrade path is busted
before I throw factory.img at it, which will probably wipe out all evidence.

Any hints where to start looking?

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

I'm up on 3.10.36-4 on a WNDR3800.  Installed via the gui, no problems with
performing the install.  I did not preserve settings.
                                      - Jim



On Thu, Apr 10, 2014 at 2:45 AM, Dave Taht <dave.taht@gmail.com> wrote:

> + dnsmasq 2.69 with dnssec enabled by default
> + possible workaround for wifi bug #442 in increased qlen_*
> + fix for ipv6 access to https://gw.home.lan:81
> + fresh merge with opewrt
> + update to 2048 bit cert generation
> + fix for openssl heartbleed (fix also in -3) bug
> + tested for an hour
> + change to sqm to basically always use "simplest.qos" on inbound
>
> - I'm very, very, very, very, very, very, very, very, very tired.
>
> I really hope this results in a stable cerowrt. Please beat the hell out
> of it.
>
> I'm already planning a vacation.
>
> --
> Dave Täht
>
> NSFW:
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 2034 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]

Valdis.Kletnieks@vt.edu writes:

> I'd like to at least try to figure out why the sysupgrade path is busted
> before I throw factory.img at it, which will probably wipe out all evidence.
>
> Any hints where to start looking?

You could try manually scp'ing the image over and running sysupgrade via
the command line?

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 220 bytes --]

On Thu, 10 Apr 2014 18:48:20 +0200, Toke Høiland-Jørgensen said:

> You could try manually scp'ing the image over and running sysupgrade via
> the command line?

OK.. Thanks for the hint.  Will try that tonight...

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

Valdis.Kletnieks@vt.edu writes:

>> You could try manually scp'ing the image over and running sysupgrade via
>> the command line?
>
> OK.. Thanks for the hint.  Will try that tonight...

This works best when you're connected via the cable LAN interface, btw. :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Dave Taht]

On Thu, Apr 10, 2014 at 8:18 AM, Robert Bradley
<robert.bradley1@gmail.com> wrote:
> On 10/04/2014 15:32, Toke Høiland-Jørgensen wrote:
>> Robert Bradley <robert.bradley1@gmail.com> writes:
>>
>>> - I had to add my cable modem configuration address to the BCP38
>>> exception list (192.168.100.1).  This gets used for nothing except
>>> configuration and checking the modem logs so this is understandable.  I
>>> also end up adding a static route anyway since if Internet breaks, I
>>> need a route to the modem...
>> If you add a 'scope link' route on the wan interface, the BCP38 code
>> *should* pick this up automatically and add an exception. Would be cool
>> if you could test this :)
>
> Just tested this now and it works fine. :)

How did you add scope link?

>
>>> - dnsmasq's default of dnssec-check-unsigned broke my DNS, since my
>>> ISP servers do not support DNSSEC. In that case, everything winds up
>>> as failing.
>> That's an interesting failure mode. FWIW you can point it at
>> 8.8.8.8/8.8.4.4 instead if you want dnssec verification :)
>
> I was tempted to leave it as-is, but tested it now with a custom
> /tmp/resolv.conf.manual file and it also works well with added DNSSEC
> checks.

As if working around the time problem was not headache enough...

I note that until now the dnssec implementation was NOT doing negative
proofs (proofs of non-existence of a signature), as I added
dnssec-check-unsigned
to /etc/dnsmasq.conf in this release.

dnssec
dnssec-check-unsigned

I do forsee this (and dnssec in general) causing massive problems in
environments
that muck with dns. I have no idea as to how prevalent this problem is.

I'd like for it to not fail silently, but fall back to non-dnssec behavior
in some way that gives the user a chance to figure out why their
network isn't working
and who to point a finger at.

Automagically falling back to 8.8.8.8 doesn't bother me much, except in places
where that is blocked too.

Anyway.

1) You can specify your dns servers in /etc/config/network, and disable fetching
your providers's addresses via adding

option 'dns' '8.8.8.8 4.4.4.4'
option 'peerdns' '0'

to the ge00 declaration. This will do the right thing to resolv.conf.auto.

Another thing the above is useful for if you have working ipv6 via
dhcppd, you will
get the ipv6 dns servers from upstream and use those only.... (otherwise dnsmasq
will choose the "best" upstream and generally chooses the ipv4 one)

2) Alternatively, you can disable dnssec by commenting it out in
/etc/dnsmasq.conf

3) Of course, I advocate pestering your provider to enable dnssec, (and ipv6)
also.

I would like to obsolete resolve.conf.auto in favor of  some of the new
options to dnsmasq -(-revaddr and another I forget), which will make resolving
multi-homed and dns through vpns saner and easier

4) I'd like to benchmark the impact of the non-existence proofs...

>
> --
> Robert Bradley
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Dave Taht]

3.10.36-4 has (the refined hacks) that were in place for you... did it
keep working until the update?

I abused my network from multiple locations last night and never got a
problem. Then again, I have always been unable to reproduce the bug
with the gear I have.

With the increased qlens, the "fq" part of fq_codel still works, but
the codel part does only rarely.

On Thu, Apr 10, 2014 at 9:46 AM, Jim Gettys <jg@freedesktop.org> wrote:
> I'm up on 3.10.36-4 on a WNDR3800.  Installed via the gui, no problems with
> performing the install.  I did not preserve settings.
>                                       - Jim
>
>
>
> On Thu, Apr 10, 2014 at 2:45 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> + dnsmasq 2.69 with dnssec enabled by default
>> + possible workaround for wifi bug #442 in increased qlen_*
>> + fix for ipv6 access to https://gw.home.lan:81
>> + fresh merge with opewrt
>> + update to 2048 bit cert generation
>> + fix for openssl heartbleed (fix also in -3) bug
>> + tested for an hour
>> + change to sqm to basically always use "simplest.qos" on inbound
>>
>> - I'm very, very, very, very, very, very, very, very, very tired.
>>
>> I really hope this results in a stable cerowrt. Please beat the hell out
>> of it.
>>
>> I'm already planning a vacation.
>>
>> --
>> Dave Täht
>>
>> NSFW:
>> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Dave Taht]

oh, yea, sqm now squashes inbound dscp values by default too. and we
need to finish the autotuning code.

On Wed, Apr 9, 2014 at 11:46 PM, Dave Taht <dave.taht@gmail.com> wrote:
> as usual, it can be found at:
> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.36-4/
>
> On Wed, Apr 9, 2014 at 11:45 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> + dnsmasq 2.69 with dnssec enabled by default
>> + possible workaround for wifi bug #442 in increased qlen_*
>> + fix for ipv6 access to https://gw.home.lan:81
>> + fresh merge with opewrt
>> + update to 2048 bit cert generation
>> + fix for openssl heartbleed (fix also in -3) bug
>> + tested for an hour
>> + change to sqm to basically always use "simplest.qos" on inbound
>>
>> - I'm very, very, very, very, very, very, very, very, very tired.
>>
>> I really hope this results in a stable cerowrt. Please beat the hell out of it.
>>
>> I'm already planning a vacation.
>>
>> --
>> Dave Täht
>>
>> NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>
>
>
> --
> Dave Täht
>
> NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

On Thu, Apr 10, 2014 at 1:31 PM, Dave Taht <dave.taht@gmail.com> wrote:

> 3.10.36-4 has (the refined hacks) that were in place for you... did it
> keep working until the update?
>

Everything was stable; no problems noted.

>
> I abused my network from multiple locations last night and never got a
> problem. Then again, I have always been unable to reproduce the bug
> with the gear I have.
>
> With the increased qlens, the "fq" part of fq_codel still works, but
> the codel part does only rarely.
>

Hopefully, Felix will figure out what's going on.
                    - Jim


>
> On Thu, Apr 10, 2014 at 9:46 AM, Jim Gettys <jg@freedesktop.org> wrote:
> > I'm up on 3.10.36-4 on a WNDR3800.  Installed via the gui, no problems
> with
> > performing the install.  I did not preserve settings.
> >                                       - Jim
> >
> >
> >
> > On Thu, Apr 10, 2014 at 2:45 AM, Dave Taht <dave.taht@gmail.com> wrote:
> >>
> >> + dnsmasq 2.69 with dnssec enabled by default
> >> + possible workaround for wifi bug #442 in increased qlen_*
> >> + fix for ipv6 access to https://gw.home.lan:81
> >> + fresh merge with opewrt
> >> + update to 2048 bit cert generation
> >> + fix for openssl heartbleed (fix also in -3) bug
> >> + tested for an hour
> >> + change to sqm to basically always use "simplest.qos" on inbound
> >>
> >> - I'm very, very, very, very, very, very, very, very, very tired.
> >>
> >> I really hope this results in a stable cerowrt. Please beat the hell out
> >> of it.
> >>
> >> I'm already planning a vacation.
> >>
> >> --
> >> Dave Täht
> >>
> >> NSFW:
> >>
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
> >> _______________________________________________
> >> Cerowrt-devel mailing list
> >> Cerowrt-devel@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
> >
>
>
>
> --
> Dave Täht
>
> NSFW:
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>

[-- Attachment #2: Type: text/html, Size: 3786 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Toke Høiland-Jørgensen]

Dave Taht <dave.taht@gmail.com> writes:

> 4) I'd like to benchmark the impact of the non-existence proofs...

Haven't done any benchmarking, but I've noticed that the first time to
resolve anything after a (complete) restart of dnsmasq is quite slow. As
in on the order of a second slow. Might be my setup that is busted
somehow, though...

-Toke

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Sebastian Moeller]

Hi Valdis,


On Apr 10, 2014, at 18:40 , Valdis.Kletnieks@vt.edu wrote:

> On Thu, 10 Apr 2014 15:06:25 +0100, Robert Bradley said:
>> Try using TFTP with the *factory.img file instead, since that worked for me.
> 
> I'd like to at least try to figure out why the sysupgrade path is busted
> before I throw factory.img at it, which will probably wipe out all evidence.
> 
> Any hints where to start looking?

	You could try the following:
scp /path/to /the/sysupgrade/image.bin root@gw.home.lan:/tmp
ssh root@gw.home.lan
cd /tmp
sysupgrade -n -d 60 -v ./image.bin

(basically adding requesting sysupgrade to be more verbose… that might give a clue why things fail)

Best Regards
	Sebstian


> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Sebastian Moeller]

Hi Dave,


On Apr 10, 2014, at 19:29 , Dave Taht <dave.taht@gmail.com> wrote:

> On Thu, Apr 10, 2014 at 8:18 AM, Robert Bradley
> <robert.bradley1@gmail.com> wrote:
>> On 10/04/2014 15:32, Toke Høiland-Jørgensen wrote:
>>> Robert Bradley <robert.bradley1@gmail.com> writes:
>>> 
>>>> - I had to add my cable modem configuration address to the BCP38
>>>> exception list (192.168.100.1).  This gets used for nothing except
>>>> configuration and checking the modem logs so this is understandable.  I
>>>> also end up adding a static route anyway since if Internet breaks, I
>>>> need a route to the modem...
>>> If you add a 'scope link' route on the wan interface, the BCP38 code
>>> *should* pick this up automatically and add an exception. Would be cool
>>> if you could test this :)
>> 
>> Just tested this now and it works fine. :)
> 
> How did you add scope link?
> 
>> 
>>>> - dnsmasq's default of dnssec-check-unsigned broke my DNS, since my
>>>> ISP servers do not support DNSSEC. In that case, everything winds up
>>>> as failing.
>>> That's an interesting failure mode. FWIW you can point it at
>>> 8.8.8.8/8.8.4.4 instead if you want dnssec verification :)
>> 
>> I was tempted to leave it as-is, but tested it now with a custom
>> /tmp/resolv.conf.manual file and it also works well with added DNSSEC
>> checks.
> 
> As if working around the time problem was not headache enough...
> 
> I note that until now the dnssec implementation was NOT doing negative
> proofs (proofs of non-existence of a signature), as I added
> dnssec-check-unsigned
> to /etc/dnsmasq.conf in this release.
> 
> dnssec
> dnssec-check-unsigned
> 
> I do forsee this (and dnssec in general) causing massive problems in
> environments
> that muck with dns. I have no idea as to how prevalent this problem is.
> 
> I'd like for it to not fail silently, but fall back to non-dnssec behavior
> in some way that gives the user a chance to figure out why their
> network isn't working
> and who to point a finger at.
> 
> Automagically falling back to 8.8.8.8 doesn't bother me much, except in places
> where that is blocked too.
> 
> Anyway.
> 
> 1) You can specify your dns servers in /etc/config/network, and disable fetching
> your providers's addresses via adding
> 
> option 'dns' '8.8.8.8 4.4.4.4'
> option 'peerdns' '0'

	Thanks a lot. This (plus a restart) actually got DNS and hence "the internet" working again (on a german deutsche trelekom ADSL line with cerowrt as secondary router after the dt supplied one).


> to the ge00 declaration. This will do the right thing to resolv.conf.auto.
> 
> Another thing the above is useful for if you have working ipv6 via
> dhcppd, you will
> get the ipv6 dns servers from upstream and use those only.... (otherwise dnsmasq
> will choose the "best" upstream and generally chooses the ipv4 one)
> 
> 2) Alternatively, you can disable dnssec by commenting it out in
> /etc/dnsmasq.conf
> 
> 3) Of course, I advocate pestering your provider to enable dnssec, (and ipv6)
> also.
> 
> I would like to obsolete resolve.conf.auto in favor of  some of the new
> options to dnsmasq -(-revaddr and another I forget), which will make resolving
> multi-homed and dns through vpns saner and easier
> 
> 4) I'd like to benchmark the impact of the non-existence proofs...
> 
>> 
>> --
>> Robert Bradley
>> 
>> 
>> 
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> 
> 
> 
> 
> -- 
> Dave Täht
> 
> NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[David Personette]

[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]

I just thought of it now, but at Dave's suggestion (because of having a DSL
with only 4/.5), I was using nfq_codel instead of straight up fq_codel.
Could the difference in the nfq_codel code path have protected me from the
bug? Just thought that it might be a clue for Felix... hopefully not a red
herring. Thanks all.

-- 
David P.



On Thu, Apr 10, 2014 at 1:35 PM, Jim Gettys <jg@freedesktop.org> wrote:

>
>
>
> On Thu, Apr 10, 2014 at 1:31 PM, Dave Taht <dave.taht@gmail.com> wrote:
>
>> 3.10.36-4 has (the refined hacks) that were in place for you... did it
>> keep working until the update?
>>
>
> Everything was stable; no problems noted.
>
>>
>> I abused my network from multiple locations last night and never got a
>> problem. Then again, I have always been unable to reproduce the bug
>> with the gear I have.
>>
>> With the increased qlens, the "fq" part of fq_codel still works, but
>> the codel part does only rarely.
>>
>
> Hopefully, Felix will figure out what's going on.
>                     - Jim
>
>>
>> On Thu, Apr 10, 2014 at 9:46 AM, Jim Gettys <jg@freedesktop.org> wrote:
>> > I'm up on 3.10.36-4 on a WNDR3800.  Installed via the gui, no problems
>> with
>> > performing the install.  I did not preserve settings.
>> >                                       - Jim
>> >
>> >
>> >
>> > On Thu, Apr 10, 2014 at 2:45 AM, Dave Taht <dave.taht@gmail.com> wrote:
>> >>
>> >> + dnsmasq 2.69 with dnssec enabled by default
>> >> + possible workaround for wifi bug #442 in increased qlen_*
>> >> + fix for ipv6 access to https://gw.home.lan:81
>> >> + fresh merge with opewrt
>> >> + update to 2048 bit cert generation
>> >> + fix for openssl heartbleed (fix also in -3) bug
>> >> + tested for an hour
>> >> + change to sqm to basically always use "simplest.qos" on inbound
>> >>
>> >> - I'm very, very, very, very, very, very, very, very, very tired.
>> >>
>> >> I really hope this results in a stable cerowrt. Please beat the hell
>> out
>> >> of it.
>> >>
>> >> I'm already planning a vacation.
>> >>
>> >> --
>> >> Dave Täht
>> >>
>> >> NSFW:
>> >>
>> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>> >> _______________________________________________
>> >> Cerowrt-devel mailing list
>> >> Cerowrt-devel@lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> >
>> >
>>
>>
>>
>> --
>> Dave Täht
>>
>> NSFW:
>> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

[-- Attachment #2: Type: text/html, Size: 4909 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

David,

I've been using both nfq and fq with a 16/1 DSL line, and never run into
it, but most of my traffic is on the 5GHz radio, not the 2.4GHz radio.

-Aaron

On Fri, Apr 11, 2014 at 11:50 AM, David Personette <dperson@gmail.com>wrote:

> I just thought of it now, but at Dave's suggestion (because of having a
> DSL with only 4/.5), I was using nfq_codel instead of straight up fq_codel.
> Could the difference in the nfq_codel code path have protected me from the
> bug? Just thought that it might be a clue for Felix... hopefully not a red
> herring. Thanks all.
>
> --
> David P.
>
>

[-- Attachment #2: Type: text/html, Size: 1187 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Robert Bradley]

[-- Attachment #1: Type: text/plain, Size: 3271 bytes --]

On 10/04/2014 18:29, Dave Taht wrote:
> On Thu, Apr 10, 2014 at 8:18 AM, Robert Bradley
> <robert.bradley1@gmail.com> wrote:
>> On 10/04/2014 15:32, Toke Høiland-Jørgensen wrote:
>>> If you add a 'scope link' route on the wan interface, the BCP38 code
>>> *should* pick this up automatically and add an exception. Would be cool
>>> if you could test this :)
>> Just tested this now and it works fine. :)
> How did you add scope link?

I added the route via Luci's web interface for it (Network/Static
Routes), using interface ge00 and target 192.168.100.1.  The other
settings were left at their defaults (netmask 255.255.255.255, gateway
blank, metric 0, MTU=1500).  I verified it via SSH and "ip -4 route show".

The command line equivalent to the resulting route would be "ip route
add 192.168.100.1 dev ge00 proto static" with or without an explicit
"scope link" appended.

> As if working around the time problem was not headache enough...
>
> I note that until now the dnssec implementation was NOT doing negative
> proofs (proofs of non-existence of a signature), as I added
> dnssec-check-unsigned
> to /etc/dnsmasq.conf in this release.
>
> dnssec
> dnssec-check-unsigned
>
> I do forsee this (and dnssec in general) causing massive problems in
> environments
> that muck with dns. I have no idea as to how prevalent this problem is.
>
> I'd like for it to not fail silently, but fall back to non-dnssec behavior
> in some way that gives the user a chance to figure out why their
> network isn't working
> and who to point a finger at.
>
> Automagically falling back to 8.8.8.8 doesn't bother me much, except in places
> where that is blocked too.
>
> Anyway.
>
> 1) You can specify your dns servers in /etc/config/network, and disable fetching
> your providers's addresses via adding
>
> option 'dns' '8.8.8.8 4.4.4.4'
> option 'peerdns' '0'
>
> to the ge00 declaration. This will do the right thing to resolv.conf.auto.

I tested that just now and it's working well with no resolv.conf funny
business.  On the benchmarking side, it's not a good quantitative result
but the resolution latency via Google DNS doesn't feel that much slower
than the non-validated ISP results.  Using dig to pull A records for the
RIR websites, I noticed that validation seems to increase the uncached
query time up to 10-fold compared to a similar +cdflag query, but is
very much distance-dependent.  For example, www.arin.net went from 27ms
to 210ms, but the ping RTT to their name servers is:

u.arin.net: 25ms
v.arin.net: 30ms
ns1.arin.net: 100ms
ns2.arin.net: 160ms

> Another thing the above is useful for if you have working ipv6 via
> dhcppd, you will
> get the ipv6 dns servers from upstream and use those only.... (otherwise dnsmasq
> will choose the "best" upstream and generally chooses the ipv4 one)
>
> 2) Alternatively, you can disable dnssec by commenting it out in
> /etc/dnsmasq.conf

I found that just disabling the dnssec-check-unsigned line is enough to
get DNS working again.

> 3) Of course, I advocate pestering your provider to enable dnssec, (and ipv6)
> also.

I agree, but I'm not expecting any rush for the major ISPs here to
support either!

-- 
Robert Bradley



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Dave Taht]

On Fri, Apr 11, 2014 at 7:52 AM, Daniel Ezell <dezell@stonescry.com> wrote:
> I've installed 3.10.36-4 a couple hours ago on a wndr3800 and everything is
> working well so far.
>
> A couple questions:
>
> redwoodcu.org is not coming up (as in can't find the server) but the ip
> address is working. Firefox DNSSEC Validator 1.1.5
> informs me that they have an invalid domain name signature. Do you all get
> the same error? Should I call their IT dept?

Yes.

> I'm working toward setting up a trio (possible quartet) of APs in a single
> network. I'd like to pick up a couple more wndr3800s and install cerowrt on
> them. In what way will babel Just Work® if I just plug two or three of them
> into one acting as the gateway? I want a seamless(ish) wireless signal
> throughout a three building campus.

yes.

>
> I'm working toward setting up a trio (possible quartet) of APs in a single
> network. I'd like to pick up a couple more wndr3800s and install cerowrt on
> them. In what way will babel Just Work® if I just plug two or three of them
> into one acting as the gateway?

Change the router ip addresses to be unique, etc.

Instructions for  setting up exterior router  and interior routers are here:

http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_an_interior_gateway_router

They no  doubt can be improved.

>I want a seamless(ish) wireless signal
> throughout a three building campus.

If by  seamless  you mean roaming, that would  require  bridging  the
wifis together which I've never  got  around to  writing documentation
 to.  Both WDS  and
BATMAN are  supported. You  can also   roam  by default by installing
babel+ahcp  +  adhoc
mode on your device.

If by  seamless you mean "able to access resources  across the campus"  the
above link  does it for everything except mdns.

>
> On Apr 9, 2014 11:45 PM, "Dave Taht" <dave.taht@gmail.com> wrote:
>>
>> + dnsmasq 2.69 with dnssec enabled by default
>> + possible workaround for wifi bug #442 in increased qlen_*
>> + fix for ipv6 access to https://gw.home.lan:81
>> + fresh merge with opewrt
>> + update to 2048 bit cert generation
>> + fix for openssl heartbleed (fix also in -3) bug
>> + tested for an hour
>> + change to sqm to basically always use "simplest.qos" on inbound
>>
>> - I'm very, very, very, very, very, very, very, very, very tired.
>>
>> I really hope this results in a stable cerowrt. Please beat the hell out
>> of it.
>>
>> I'm already planning a vacation.
>>
>> --
>> Dave Täht
>>
>> NSFW:
>> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]

Unfortunately, the bug has occurred after about a day and a half.  It's now
believed to be a generic OpenWrt bug, rather than a CeroWrt change.

root@cerowrt:/sys/kernel/debug/ieee80211/phy0/ath9k# cat queues
(VO):  qnum: 0 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(VI):  qnum: 1 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BE):  qnum: 2 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BK):  qnum: 3 qdepth:  0 ampdu-depth:  0 pending: 278 stopped: 1
(CAB): qnum: 8 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0



On Thu, Apr 10, 2014 at 2:46 AM, Dave Taht <dave.taht@gmail.com> wrote:

> as usual, it can be found at:
> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.36-4/
>
> On Wed, Apr 9, 2014 at 11:45 PM, Dave Taht <dave.taht@gmail.com> wrote:
> > + dnsmasq 2.69 with dnssec enabled by default
> > + possible workaround for wifi bug #442 in increased qlen_*
> > + fix for ipv6 access to https://gw.home.lan:81
> > + fresh merge with opewrt
> > + update to 2048 bit cert generation
> > + fix for openssl heartbleed (fix also in -3) bug
> > + tested for an hour
> > + change to sqm to basically always use "simplest.qos" on inbound
> >
> > - I'm very, very, very, very, very, very, very, very, very tired.
> >
> > I really hope this results in a stable cerowrt. Please beat the hell out
> of it.
> >
> > I'm already planning a vacation.
> >
> > --
> > Dave Täht
> >
> > NSFW:
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>
>
>
> --
> Dave Täht
>
> NSFW:
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 3258 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Neil Shepperd]

Bad news, or perhaps "interesting news": I just managed to trigger the
bug while testing with sw00 configured to use sfq. I don't know anything
about the qdiscs code (maybe even sfq and fq_codel share code), but this
might not be a bug in fq_codel...

Still on 3.10.34-4 right now.

On 11/04/14 19:50, David Personette wrote:
> I just thought of it now, but at Dave's suggestion (because of having a
> DSL with only 4/.5), I was using nfq_codel instead of straight up
> fq_codel. Could the difference in the nfq_codel code path have protected
> me from the bug? Just thought that it might be a clue for Felix...
> hopefully not a red herring. Thanks all.
> 
> -- 
> David P.
> 

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Dave Taht]

On Sat, Apr 12, 2014 at 4:45 AM, Neil Shepperd <nshepperd@gmail.com> wrote:
> Bad news, or perhaps "interesting news": I just managed to trigger the
> bug while testing with sw00 configured to use sfq. I don't know anything
> about the qdiscs code (maybe even sfq and fq_codel share code), but this
> might not be a bug in fq_codel...

I don't believe the bug to be in higher level qdiscs but buried deep
in some non-atomic access to the queue length estimator deep in the
ath9k driver.

> Still on 3.10.34-4 right now.
>
> On 11/04/14 19:50, David Personette wrote:
>> I just thought of it now, but at Dave's suggestion (because of having a
>> DSL with only 4/.5), I was using nfq_codel instead of straight up
>> fq_codel. Could the difference in the nfq_codel code path have protected
>> me from the bug? Just thought that it might be a clue for Felix...
>> hopefully not a red herring. Thanks all.
>>
>> --
>> David P.
>>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Jim Reisert AD1C]

On Thu, Apr 10, 2014 at 12:02 PM, Sebastian Moeller wrote:
> Hi Valdis,
>
>
> On Apr 10, 2014, at 18:40 , Valdis.Kletnieks@vt.edu wrote:
>
>> On Thu, 10 Apr 2014 15:06:25 +0100, Robert Bradley said:
>>> Try using TFTP with the *factory.img file instead, since that worked for me.
>>
>> I'd like to at least try to figure out why the sysupgrade path is busted
>> before I throw factory.img at it, which will probably wipe out all evidence.
>>
>> Any hints where to start looking?
>
>         You could try the following:
> scp /path/to /the/sysupgrade/image.bin root@gw.home.lan:/tmp
> ssh root@gw.home.lan
> cd /tmp
> sysupgrade -n -d 60 -v ./image.bin

I tried this - unfortunately, I lost all my settings in the process.

-- 
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Sebastian Moeller]

Hi Jim,


On Apr 13, 2014, at 02:22 , Jim Reisert AD1C <jjreisert@alum.mit.edu> wrote:

> On Thu, Apr 10, 2014 at 12:02 PM, Sebastian Moeller wrote:
>> Hi Valdis,
>> 
>> 
>> On Apr 10, 2014, at 18:40 , Valdis.Kletnieks@vt.edu wrote:
>> 
>>> On Thu, 10 Apr 2014 15:06:25 +0100, Robert Bradley said:
>>>> Try using TFTP with the *factory.img file instead, since that worked for me.
>>> 
>>> I'd like to at least try to figure out why the sysupgrade path is busted
>>> before I throw factory.img at it, which will probably wipe out all evidence.
>>> 
>>> Any hints where to start looking?
>> 
>>        You could try the following:
>> scp /path/to /the/sysupgrade/image.bin root@gw.home.lan:/tmp
>> ssh root@gw.home.lan
>> cd /tmp
>> sysupgrade -n -d 60 -v ./image.bin
> 
> I tried this - unfortunately, I lost all my settings in the process.

	Well, the "-n" in the shown evocation requests that the settings are not kept, so this behaves as expected. (Due to the amount of flux in openwrt trunk and cerowrt on top it generally is hazardous to keep the settings; it is way better to make a backup before and then compare files before restoring them)


I guess that means I forgot to lead the whole thing in with:

scp -r root@gw.home.lan:/overlay/* ./overlay_backup
(as /overlay contains all files changes after first boot-up all personalization and site specific configuration settings will be in there).

For completenes' sake:
root@nacktmulle:~# sysupgrade -h
Usage: /sbin/sysupgrade [<upgrade-option>...] <image file or URL>
       /sbin/sysupgrade [-q] [-i] <backup-command> <file>

upgrade-option:
	-d <delay>   add a delay before rebooting
	-f <config>  restore configuration from .tar.gz (file or url)
	-i           interactive mode
	-c           attempt to preserve all changed files in /etc/
	-n           do not save configuration over reflash
	-T | --test
	             Verify image and config .tar.gz but do not actually flash.
	-F | --force
	             Flash image even if image checks fail, this is dangerous!
	-q           less verbose
	-v           more verbose
	-h | --help  display this help

backup-command:
	-b | --create-backup <file>
	             create .tar.gz of files specified in sysupgrade.conf
	             then exit. Does not flash an image. If file is '-',
	             i.e. stdout, verbosity is set to 0 (i.e. quiet).
	-r | --restore-backup <file>
	             restore a .tar.gz created with sysupgrade -b
	             then exit. Does not flash an image. If file is '-',
	             the archive is read from stdin.
	-l | --list-backup
	             list the files that would be backed up when calling
	             sysupgrade -b. Does not create a backup file.



Best Regards
	Sebastian


> 
> -- 
> Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us

Re: [Cerowrt-devel] cerowrt-3.10.36-4 released

[Jim Reisert AD1C]

On Sat, Apr 12, 2014 at 6:30 PM, Sebastian Moeller wrote:

>         Well, the "-n" in the shown evocation requests that the settings are not kept, so this behaves as expected. (Due to the amount of flux in openwrt trunk and cerowrt on top it generally is hazardous to keep the settings; it is way better to make a backup before and then compare files before restoring them)

Danke.  I made a backup of my current settings, in case I need them next time.

-- 
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us