* [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
@ 2014-04-12 18:46 Frits Riep
2014-04-12 20:28 ` Sebastian Moeller
2014-04-19 19:12 ` Dave Taht
0 siblings, 2 replies; 8+ messages in thread
From: Frits Riep @ 2014-04-12 18:46 UTC (permalink / raw)
To: cerowrt-devel
I have a Netgear WNDR-3800 and I last updated the firmware about a week ago
successfully using the web interface. I've been trying today to upgrade to
the latest image the same way, but I am not having success and I've tried
the download several times and even with three different browsers but the
result is the same.
Current Image is 3.10.36-3
Using this new image for 3.10.36-4:
openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin
Error Message:
The uploaded image file does not contain a supported format. Make sure that
you choose the generic image format for your platform.
Please advise if I need to do something different, or have I found a bug.
thanks
-----Original Message-----
From: cerowrt-devel-bounces@lists.bufferbloat.net
[mailto:cerowrt-devel-bounces@lists.bufferbloat.net] On Behalf Of
cerowrt-devel-request@lists.bufferbloat.net
Sent: Saturday, April 12, 2014 7:54 AM
To: cerowrt-devel@lists.bufferbloat.net
Subject: Cerowrt-devel Digest, Vol 29, Issue 22
Send Cerowrt-devel mailing list submissions to
cerowrt-devel@lists.bufferbloat.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.bufferbloat.net/listinfo/cerowrt-devel
or, via email, send a message with subject or body 'help' to
cerowrt-devel-request@lists.bufferbloat.net
You can reach the person managing the list at
cerowrt-devel-owner@lists.bufferbloat.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Cerowrt-devel digest..."
Today's Topics:
1. Re: wired article about bleed and bloat and underfunded
critical infrastructure (dpreed@reed.com)
2. DNSSEC failure for *.cloudflare.com via dnsmasq? (Robert Bradley)
3. Re: DNSSEC failure for *.cloudflare.com via dnsmasq?
(Toke H?iland-J?rgensen)
4. Re: DNSSEC failure for *.cloudflare.com via dnsmasq?
(Robert Bradley)
5. Re: cerowrt-3.10.36-4 released (Neil Shepperd)
6. Re: DNSSEC failure for *.cloudflare.com via dnsmasq?
(Robert Bradley)
----------------------------------------------------------------------
Message: 1
Date: Fri, 11 Apr 2014 15:43:19 -0400 (EDT)
From: dpreed@reed.com
To: "Dave Taht" <dave.taht@gmail.com>
Cc: "cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>, bloat
<bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] wired article about bleed and bloat and
underfunded critical infrastructure
Message-ID: <1397245399.392818481@apps.rackspace.com>
Content-Type: text/plain; charset="utf-8"
I'm afraid it's not *just* underfunded. I reviewed the details of the code
involved and the fixes, and my conclusion is that even programmers of
security software have not learned how to think about design, testing, etc.
Especially the continuing use of C in a large shared process address space
for writing protocols that are by definition in the "security kernel"
(according to the original definition) of applications on which the public
depends.
Ever since I was part of the Multics Security Project (which was part of the
effort that produced the Orange Book
http://csrc.nist.gov/publications/history/dod85.pdf) in the 80's, we've
known that security-based code should not be exposed to user code and vice
versa. Yet the SSL libraries are linked in, in userspace, with the
application code.
Also, upgrades/changes to protocols related to security (which always should
have been in place on every end-to-end connection) should be reviewed *both
at the protocol design level* and also at the *implementation level* because
change creates risk. They should not be adopted blindly without serious
examination and pen-testing, yet this change just was casually thrown in in
a patch release.
I suspect that even if it were well funded, the folks who deploy the
technology would be slapdash at best. Remember the Y2K issue and the cost of
lazy thinking about dates. (I feel a little superior because in 1968 Multics
standardized on a 72-bit hardware microsecond-resolution hardware clock
because the designers actually thought about long-lived systems (actually
only 56 bits of the original clock worked, but the hardware was not expected
to last until the remaining bits could be added)).
The open source movement, unfortunately, made a monoculture of the SSL
source code, so it's much more dangerous and the vulnerable attack surface
of deployments is enormous.
Rant off. The summary is that good engineering is not applied where it must
be for the public interest. That remains true even if the NSA actually
snuck this code into the SSL implementation.
On Friday, April 11, 2014 2:22pm, "Dave Taht" <dave.taht@gmail.com> said:
> http://www.wired.com/2014/04/heartbleedslesson/
>
> And Dan Kaminisky writes about "Code in the Age of Cholera"
>
> http://dankaminsky.com/2014/04/10/heartbleed/
>
>
>
> --
> Dave T?ht
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140411/
5a81cc38/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 12 Apr 2014 12:06:55 +0100
From: Robert Bradley <robert.bradley1@gmail.com>
To: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
dnsmasq?
Message-ID: <53491E4F.4040108@gmail.com>
Content-Type: text/plain; charset="utf-8"
I noticed today that attempts to visit www.cloudflare.com and other
subdomains seem to be failing on the latest CeroWRT (3.10.36-4) when DNSSEC
checks are enabled, but not if I query Google DNS directly.
The resulting queries are:
root@cerowrt:~# dig www.cloudflare.com A IN
; <<>> DiG 9.9.4 <<>> www.cloudflare.com A IN ;; global options: +cmd ;; Got
answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23776 ;; flags: qr rd
ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; Query time: 808 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Apr 12 11:04:10 UTC 2014
;; MSG SIZE rcvd: 47
root@cerowrt:~# dig +adflag www.cloudflare.com A IN
; <<>> DiG 9.9.4 <<>> +adflag www.cloudflare.com A IN ;; global options:
+cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3689 ;; flags: qr rd
ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; Query time: 913 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Apr 12 11:04:21 UTC 2014
;; MSG SIZE rcvd: 47
root@cerowrt:~# dig +cdflag www.cloudflare.com A IN
; <<>> DiG 9.9.4 <<>> +cdflag www.cloudflare.com A IN ;; global options:
+cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19768 ;; flags: qr rd ra
cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; ANSWER SECTION:
www.cloudflare.com. 297 IN CNAME
www.cloudflare.com.cdn.cloudflare.net.
www.cloudflare.com.cdn.cloudflare.net. 297 IN CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 297 IN A
198.41.212.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
297 IN A 198.41.213.157
;; Query time: 22 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Apr 12 11:04:26 UTC 2014
;; MSG SIZE rcvd: 169
root@cerowrt:~# dig @8.8.8.8 www.cloudflare.com A IN
; <<>> DiG 9.9.4 <<>> @8.8.8.8 www.cloudflare.com A IN ; (1 server found) ;;
global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31488 ;; flags: qr rd
ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; ANSWER SECTION:
www.cloudflare.com. 84 IN CNAME
www.cloudflare.com.cdn.cloudflare.net.
www.cloudflare.com.cdn.cloudflare.net. 166 IN CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 166 IN A
198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
166 IN A 198.41.212.157
;; Query time: 22 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Apr 12 11:04:35 UTC 2014
;; MSG SIZE rcvd: 169
root@cerowrt:~# dig @8.8.8.8 +adflag www.cloudflare.com A IN
; <<>> DiG 9.9.4 <<>> @8.8.8.8 +adflag www.cloudflare.com A IN ; (1 server
found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59486 ;; flags: qr rd
ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; ANSWER SECTION:
www.cloudflare.com. 77 IN CNAME
www.cloudflare.com.cdn.cloudflare.net.
www.cloudflare.com.cdn.cloudflare.net. 159 IN CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 159 IN A
198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
159 IN A 198.41.212.157
;; Query time: 22 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Apr 12 11:04:41 UTC 2014
;; MSG SIZE rcvd: 169
root@cerowrt:~# dig @8.8.8.8 +cdflag www.cloudflare.com A IN
; <<>> DiG 9.9.4 <<>> @8.8.8.8 +cdflag www.cloudflare.com A IN ; (1 server
found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43503 ;; flags: qr rd ra
cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; ANSWER SECTION:
www.cloudflare.com. 69 IN CNAME
www.cloudflare.com.cdn.cloudflare.net.
www.cloudflare.com.cdn.cloudflare.net. 151 IN CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 151 IN A
198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
151 IN A 198.41.212.157
;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Apr 12 11:04:48 UTC 2014
;; MSG SIZE rcvd: 169
root@cerowrt:~#
Can anyone explain why this should be the case?
--
Robert Bradley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/
4de94408/attachment-0001.pgp>
------------------------------
Message: 3
Date: Sat, 12 Apr 2014 13:11:56 +0200
From: Toke H?iland-J?rgensen <toke@toke.dk>
To: Robert Bradley <robert.bradley1@gmail.com>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
dnsmasq?
Message-ID: <878urakdj7.fsf@alrua-x1.kau.toke.dk>
Content-Type: text/plain
Robert Bradley <robert.bradley1@gmail.com> writes:
> Can anyone explain why this should be the case?
If you turn on log-queries in the dnsmasq config, you can see the
results of the dnssec validation in the logs which might give a hint :)
-Toke
------------------------------
Message: 4
Date: Sat, 12 Apr 2014 12:13:25 +0100
From: Robert Bradley <robert.bradley1@gmail.com>
To: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
dnsmasq?
Message-ID: <53491FD5.4020600@gmail.com>
Content-Type: text/plain; charset="utf-8"
On 12/04/2014 12:06, Robert Bradley wrote:
> I noticed today that attempts to visit www.cloudflare.com and other
> subdomains seem to be failing on the latest CeroWRT (3.10.36-4) when
> DNSSEC checks are enabled, but not if I query Google DNS directly.
If it helps, it seems to be an issue with dnssec-check-unsigned again.
This time though was via Google's DNS. (Using the Virgin Media DNS
servers, dnssec-check-unsigned kills all DNS as per my previous posts.)
--
Robert Bradley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/
04b015bc/attachment-0001.pgp>
------------------------------
Message: 5
Date: Sat, 12 Apr 2014 21:45:09 +1000
From: Neil Shepperd <nshepperd@gmail.com>
To: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] cerowrt-3.10.36-4 released
Message-ID: <53492745.90101@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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.
>
------------------------------
Message: 6
Date: Sat, 12 Apr 2014 12:53:29 +0100
From: Robert Bradley <robert.bradley1@gmail.com>
To: Toke H?iland-J?rgensen <toke@toke.dk>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
dnsmasq?
Message-ID: <53492939.4090508@gmail.com>
Content-Type: text/plain; charset="utf-8"
On 12/04/2014 12:11, Toke H?iland-J?rgensen wrote:
> Robert Bradley <robert.bradley1@gmail.com> writes:
>
>> Can anyone explain why this should be the case?
> If you turn on log-queries in the dnsmasq config, you can see the
> results of the dnssec validation in the logs which might give a hint :)
>
> -Toke
OK, with log-queries on I get:
Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: query[A]
www.cloudflare.com from 127.0.0.1
Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: forwarded
www.cloudflare.com to 8.8.4.4
Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: dnssec-query[DS]
www.cloudflare.com to 8.8.4.4
Sat Apr 12 11:41:51 2014 daemon.info dnsmasq[14581]: forwarded
www.cloudflare.com to 8.8.8.8
Sat Apr 12 11:41:51 2014 daemon.info dnsmasq[14581]: forwarded
www.cloudflare.com to 8.8.4.4
Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
www.cloudflare.com is BOGUS DS
Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: validation result
is BOGUS
Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
www.cloudflare.com is <CNAME>
Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
www.cloudflare.com.cdn.cloudflare.net is <CNAME>
Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net is 198.41.213.157
Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net is 198.41.212.157
Running tcpdump -i ge00 port 53 -v -v -n during a query from Windows 7
nslookup, I see:
11:44:44.884477 IP (tos 0x90, ttl 64, id 16465, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.44272 > 8.8.8.8.53: [udp sum ok] 20890+ [1au] A?
www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
11:44:44.884652 IP (tos 0x90, ttl 64, id 26115, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.44272 > 8.8.4.4.53: [udp sum ok] 20890+ [1au] A?
www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
11:44:44.904068 IP (tos 0x0, ttl 47, id 47459, offset 0, flags [none],
proto UDP (17), length 197)
8.8.8.8.53 > 86.1.32.208.44272: [udp sum ok] 20890 q: A?
www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME
www.cloudflare.com.cdn.cloudflare.net.,
www.cloudflare.com.cdn.cloudflare.net. CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.,
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
198.41.212.157,
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
198.41.213.157 ar: . OPT UDPsize=512 OK (169)
11:44:44.904120 IP (tos 0x0, ttl 45, id 57740, offset 0, flags [none],
proto UDP (17), length 197)
8.8.4.4.53 > 86.1.32.208.44272: [udp sum ok] 20890 q: A?
www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME
www.cloudflare.com.cdn.cloudflare.net.,
www.cloudflare.com.cdn.cloudflare.net. CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.,
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
198.41.212.157,
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
198.41.213.157 ar: . OPT UDPsize=512 OK (169)
11:44:44.904720 IP (tos 0x90, ttl 64, id 16466, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.60232 > 8.8.8.8.53: [udp sum ok] 43145+ [1au] DS?
www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
11:44:45.430963 IP (tos 0x0, ttl 49, id 13829, offset 0, flags [none],
proto UDP (17), length 75)
8.8.8.8.53 > 86.1.32.208.60232: [udp sum ok] 43145 ServFail q: DS?
www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
11:44:45.434094 IP (tos 0x90, ttl 64, id 16467, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.27765 > 8.8.8.8.53: [udp sum ok] 6810+ [1au] AAAA?
www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
11:44:45.455145 IP (tos 0x0, ttl 47, id 13830, offset 0, flags [none],
proto UDP (17), length 221)
8.8.8.8.53 > 86.1.32.208.27765: [udp sum ok] 6810 q: AAAA?
www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME
www.cloudflare.com.cdn.cloudflare.net.,
www.cloudflare.com.cdn.cloudflare.net. CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.,
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. AAAA
2400:cb00:2048:1::c629:d59d,
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. AAAA
2400:cb00:2048:1::c629:d49d ar: . OPT UDPsize=512 OK (193)
11:44:45.455845 IP (tos 0x90, ttl 64, id 16468, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.63524 > 8.8.8.8.53: [udp sum ok] 37758+ [1au] DS?
www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
11:44:45.895583 IP (tos 0x0, ttl 47, id 16395, offset 0, flags [none],
proto UDP (17), length 75)
8.8.8.8.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS?
www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
11:44:45.896049 IP (tos 0x90, ttl 64, id 26116, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.63524 > 8.8.4.4.53: [udp sum ok] 37758+ [b2&3=0x182]
[1au] DS? www.cloudflare.com. ar: . OPT UDPsize=512 OK (47)
11:44:45.896242 IP (tos 0x90, ttl 64, id 16469, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.63524 > 8.8.8.8.53: [udp sum ok] 37758+ [b2&3=0x182]
[1au] DS? www.cloudflare.com. ar: . OPT UDPsize=512 OK (47)
11:44:46.335616 IP (tos 0x0, ttl 46, id 44525, offset 0, flags [none],
proto UDP (17), length 75)
8.8.4.4.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS?
www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
11:44:46.341564 IP (tos 0x0, ttl 47, id 47460, offset 0, flags [none],
proto UDP (17), length 75)
8.8.8.8.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS?
www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
That seems to suggest that it's the DS queries that are failing and that
this is probably not a dnsmasq bug. Trying Verisign's DNSSEC debugger
(http://dnssec-debugger.verisignlabs.com/blog.cloudflare.com) seems to
suggest that their nameservers refuse requests for DNSKEY records.
--
Robert Bradley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/
f7c270a9/attachment.pgp>
------------------------------
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
End of Cerowrt-devel Digest, Vol 29, Issue 22
*********************************************
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
2014-04-12 18:46 [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4 Frits Riep
@ 2014-04-12 20:28 ` Sebastian Moeller
2014-04-12 20:42 ` Valdis.Kletnieks
2014-04-13 13:57 ` Joel Stanley
2014-04-19 19:12 ` Dave Taht
1 sibling, 2 replies; 8+ messages in thread
From: Sebastian Moeller @ 2014-04-12 20:28 UTC (permalink / raw)
To: Frits Riep, Valdis.Kletnieks; +Cc: cerowrt-devel
Hi Frits,
On Apr 12, 2014, at 20:46 , Frits Riep <riep@riepnet.com> wrote:
> I have a Netgear WNDR-3800 and I last updated the firmware about a week ago
> successfully using the web interface. I've been trying today to upgrade to
> the latest image the same way, but I am not having success and I've tried
> the download several times and even with three different browsers but the
> result is the same.
>
> Current Image is 3.10.36-3
> Using this new image for 3.10.36-4:
> openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin
> Error Message:
> The uploaded image file does not contain a supported format. Make sure that
> you choose the generic image format for your platform.
>
> Please advise if I need to do something different, or have I found a bug.
I think Valdis Kletnieks reported the same for a 3800. Please try the "manual" route described below and report back your results to the list:
Here is the recipe I used, this should work for you as well, if you adjust the pathes and image names and run from a unix (no idea about windows)
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
Note the "-v" will make sysupgrade a bit chattier and might help pinpoint the cause of the failure (unless it is not a sysupgrade issue but a GUI issue)
Note two if the GUI would be borked that would be a case of poetic balance as we had the script non-functional for a while while the GUI still worked ;)
Best Regards
Sebastian
>
> thanks
>
> -----Original Message-----
> From: cerowrt-devel-bounces@lists.bufferbloat.net
> [mailto:cerowrt-devel-bounces@lists.bufferbloat.net] On Behalf Of
> cerowrt-devel-request@lists.bufferbloat.net
> Sent: Saturday, April 12, 2014 7:54 AM
> To: cerowrt-devel@lists.bufferbloat.net
> Subject: Cerowrt-devel Digest, Vol 29, Issue 22
>
> Send Cerowrt-devel mailing list submissions to
> cerowrt-devel@lists.bufferbloat.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> or, via email, send a message with subject or body 'help' to
> cerowrt-devel-request@lists.bufferbloat.net
>
> You can reach the person managing the list at
> cerowrt-devel-owner@lists.bufferbloat.net
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Cerowrt-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: wired article about bleed and bloat and underfunded
> critical infrastructure (dpreed@reed.com)
> 2. DNSSEC failure for *.cloudflare.com via dnsmasq? (Robert Bradley)
> 3. Re: DNSSEC failure for *.cloudflare.com via dnsmasq?
> (Toke H?iland-J?rgensen)
> 4. Re: DNSSEC failure for *.cloudflare.com via dnsmasq?
> (Robert Bradley)
> 5. Re: cerowrt-3.10.36-4 released (Neil Shepperd)
> 6. Re: DNSSEC failure for *.cloudflare.com via dnsmasq?
> (Robert Bradley)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 11 Apr 2014 15:43:19 -0400 (EDT)
> From: dpreed@reed.com
> To: "Dave Taht" <dave.taht@gmail.com>
> Cc: "cerowrt-devel@lists.bufferbloat.net"
> <cerowrt-devel@lists.bufferbloat.net>, bloat
> <bloat@lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] wired article about bleed and bloat and
> underfunded critical infrastructure
> Message-ID: <1397245399.392818481@apps.rackspace.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> I'm afraid it's not *just* underfunded. I reviewed the details of the code
> involved and the fixes, and my conclusion is that even programmers of
> security software have not learned how to think about design, testing, etc.
> Especially the continuing use of C in a large shared process address space
> for writing protocols that are by definition in the "security kernel"
> (according to the original definition) of applications on which the public
> depends.
>
> Ever since I was part of the Multics Security Project (which was part of the
> effort that produced the Orange Book
> http://csrc.nist.gov/publications/history/dod85.pdf) in the 80's, we've
> known that security-based code should not be exposed to user code and vice
> versa. Yet the SSL libraries are linked in, in userspace, with the
> application code.
>
> Also, upgrades/changes to protocols related to security (which always should
> have been in place on every end-to-end connection) should be reviewed *both
> at the protocol design level* and also at the *implementation level* because
> change creates risk. They should not be adopted blindly without serious
> examination and pen-testing, yet this change just was casually thrown in in
> a patch release.
>
> I suspect that even if it were well funded, the folks who deploy the
> technology would be slapdash at best. Remember the Y2K issue and the cost of
> lazy thinking about dates. (I feel a little superior because in 1968 Multics
> standardized on a 72-bit hardware microsecond-resolution hardware clock
> because the designers actually thought about long-lived systems (actually
> only 56 bits of the original clock worked, but the hardware was not expected
> to last until the remaining bits could be added)).
>
> The open source movement, unfortunately, made a monoculture of the SSL
> source code, so it's much more dangerous and the vulnerable attack surface
> of deployments is enormous.
>
> Rant off. The summary is that good engineering is not applied where it must
> be for the public interest. That remains true even if the NSA actually
> snuck this code into the SSL implementation.
>
>
> On Friday, April 11, 2014 2:22pm, "Dave Taht" <dave.taht@gmail.com> said:
>
>
>
>> http://www.wired.com/2014/04/heartbleedslesson/
>>
>> And Dan Kaminisky writes about "Code in the Age of Cholera"
>>
>> http://dankaminsky.com/2014/04/10/heartbleed/
>>
>>
>>
>> --
>> Dave T?ht
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140411/
> 5a81cc38/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 12 Apr 2014 12:06:55 +0100
> From: Robert Bradley <robert.bradley1@gmail.com>
> To: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
> Subject: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
> dnsmasq?
> Message-ID: <53491E4F.4040108@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I noticed today that attempts to visit www.cloudflare.com and other
> subdomains seem to be failing on the latest CeroWRT (3.10.36-4) when DNSSEC
> checks are enabled, but not if I query Google DNS directly.
>
> The resulting queries are:
>
> root@cerowrt:~# dig www.cloudflare.com A IN
>
> ; <<>> DiG 9.9.4 <<>> www.cloudflare.com A IN ;; global options: +cmd ;; Got
> answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23776 ;; flags: qr rd
> ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;www.cloudflare.com. IN A
>
> ;; Query time: 808 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Sat Apr 12 11:04:10 UTC 2014
> ;; MSG SIZE rcvd: 47
>
> root@cerowrt:~# dig +adflag www.cloudflare.com A IN
>
> ; <<>> DiG 9.9.4 <<>> +adflag www.cloudflare.com A IN ;; global options:
> +cmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3689 ;; flags: qr rd
> ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;www.cloudflare.com. IN A
>
> ;; Query time: 913 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Sat Apr 12 11:04:21 UTC 2014
> ;; MSG SIZE rcvd: 47
>
> root@cerowrt:~# dig +cdflag www.cloudflare.com A IN
>
> ; <<>> DiG 9.9.4 <<>> +cdflag www.cloudflare.com A IN ;; global options:
> +cmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19768 ;; flags: qr rd ra
> cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;www.cloudflare.com. IN A
>
> ;; ANSWER SECTION:
> www.cloudflare.com. 297 IN CNAME
> www.cloudflare.com.cdn.cloudflare.net.
> www.cloudflare.com.cdn.cloudflare.net. 297 IN CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 297 IN A
> 198.41.212.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> 297 IN A 198.41.213.157
>
> ;; Query time: 22 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Sat Apr 12 11:04:26 UTC 2014
> ;; MSG SIZE rcvd: 169
>
> root@cerowrt:~# dig @8.8.8.8 www.cloudflare.com A IN
>
> ; <<>> DiG 9.9.4 <<>> @8.8.8.8 www.cloudflare.com A IN ; (1 server found) ;;
> global options: +cmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31488 ;; flags: qr rd
> ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;www.cloudflare.com. IN A
>
> ;; ANSWER SECTION:
> www.cloudflare.com. 84 IN CNAME
> www.cloudflare.com.cdn.cloudflare.net.
> www.cloudflare.com.cdn.cloudflare.net. 166 IN CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 166 IN A
> 198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> 166 IN A 198.41.212.157
>
> ;; Query time: 22 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Sat Apr 12 11:04:35 UTC 2014
> ;; MSG SIZE rcvd: 169
>
> root@cerowrt:~# dig @8.8.8.8 +adflag www.cloudflare.com A IN
>
> ; <<>> DiG 9.9.4 <<>> @8.8.8.8 +adflag www.cloudflare.com A IN ; (1 server
> found) ;; global options: +cmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59486 ;; flags: qr rd
> ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;www.cloudflare.com. IN A
>
> ;; ANSWER SECTION:
> www.cloudflare.com. 77 IN CNAME
> www.cloudflare.com.cdn.cloudflare.net.
> www.cloudflare.com.cdn.cloudflare.net. 159 IN CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 159 IN A
> 198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> 159 IN A 198.41.212.157
>
> ;; Query time: 22 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Sat Apr 12 11:04:41 UTC 2014
> ;; MSG SIZE rcvd: 169
>
> root@cerowrt:~# dig @8.8.8.8 +cdflag www.cloudflare.com A IN
>
> ; <<>> DiG 9.9.4 <<>> @8.8.8.8 +cdflag www.cloudflare.com A IN ; (1 server
> found) ;; global options: +cmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43503 ;; flags: qr rd ra
> cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;www.cloudflare.com. IN A
>
> ;; ANSWER SECTION:
> www.cloudflare.com. 69 IN CNAME
> www.cloudflare.com.cdn.cloudflare.net.
> www.cloudflare.com.cdn.cloudflare.net. 151 IN CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 151 IN A
> 198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> 151 IN A 198.41.212.157
>
> ;; Query time: 26 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Sat Apr 12 11:04:48 UTC 2014
> ;; MSG SIZE rcvd: 169
>
> root@cerowrt:~#
>
> Can anyone explain why this should be the case?
>
> --
> Robert Bradley
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 899 bytes
> Desc: OpenPGP digital signature
> URL:
> <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/
> 4de94408/attachment-0001.pgp>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 12 Apr 2014 13:11:56 +0200
> From: Toke H?iland-J?rgensen <toke@toke.dk>
> To: Robert Bradley <robert.bradley1@gmail.com>
> Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
> dnsmasq?
> Message-ID: <878urakdj7.fsf@alrua-x1.kau.toke.dk>
> Content-Type: text/plain
>
> Robert Bradley <robert.bradley1@gmail.com> writes:
>
>> Can anyone explain why this should be the case?
>
> If you turn on log-queries in the dnsmasq config, you can see the
> results of the dnssec validation in the logs which might give a hint :)
>
> -Toke
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 12 Apr 2014 12:13:25 +0100
> From: Robert Bradley <robert.bradley1@gmail.com>
> To: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
> dnsmasq?
> Message-ID: <53491FD5.4020600@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 12/04/2014 12:06, Robert Bradley wrote:
>> I noticed today that attempts to visit www.cloudflare.com and other
>> subdomains seem to be failing on the latest CeroWRT (3.10.36-4) when
>> DNSSEC checks are enabled, but not if I query Google DNS directly.
>
> If it helps, it seems to be an issue with dnssec-check-unsigned again.
> This time though was via Google's DNS. (Using the Virgin Media DNS
> servers, dnssec-check-unsigned kills all DNS as per my previous posts.)
>
> --
> Robert Bradley
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 899 bytes
> Desc: OpenPGP digital signature
> URL:
> <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/
> 04b015bc/attachment-0001.pgp>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 12 Apr 2014 21:45:09 +1000
> From: Neil Shepperd <nshepperd@gmail.com>
> To: cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] cerowrt-3.10.36-4 released
> Message-ID: <53492745.90101@gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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.
>>
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 12 Apr 2014 12:53:29 +0100
> From: Robert Bradley <robert.bradley1@gmail.com>
> To: Toke H?iland-J?rgensen <toke@toke.dk>
> Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
> dnsmasq?
> Message-ID: <53492939.4090508@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 12/04/2014 12:11, Toke H?iland-J?rgensen wrote:
>> Robert Bradley <robert.bradley1@gmail.com> writes:
>>
>>> Can anyone explain why this should be the case?
>> If you turn on log-queries in the dnsmasq config, you can see the
>> results of the dnssec validation in the logs which might give a hint :)
>>
>> -Toke
>
> OK, with log-queries on I get:
>
> Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: query[A]
> www.cloudflare.com from 127.0.0.1
> Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: forwarded
> www.cloudflare.com to 8.8.4.4
> Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: dnssec-query[DS]
> www.cloudflare.com to 8.8.4.4
> Sat Apr 12 11:41:51 2014 daemon.info dnsmasq[14581]: forwarded
> www.cloudflare.com to 8.8.8.8
> Sat Apr 12 11:41:51 2014 daemon.info dnsmasq[14581]: forwarded
> www.cloudflare.com to 8.8.4.4
> Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
> www.cloudflare.com is BOGUS DS
> Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: validation result
> is BOGUS
> Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
> www.cloudflare.com is <CNAME>
> Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
> www.cloudflare.com.cdn.cloudflare.net is <CNAME>
> Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net is 198.41.213.157
> Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net is 198.41.212.157
>
> Running tcpdump -i ge00 port 53 -v -v -n during a query from Windows 7
> nslookup, I see:
>
> 11:44:44.884477 IP (tos 0x90, ttl 64, id 16465, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.44272 > 8.8.8.8.53: [udp sum ok] 20890+ [1au] A?
> www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
> 11:44:44.884652 IP (tos 0x90, ttl 64, id 26115, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.44272 > 8.8.4.4.53: [udp sum ok] 20890+ [1au] A?
> www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
> 11:44:44.904068 IP (tos 0x0, ttl 47, id 47459, offset 0, flags [none],
> proto UDP (17), length 197)
> 8.8.8.8.53 > 86.1.32.208.44272: [udp sum ok] 20890 q: A?
> www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME
> www.cloudflare.com.cdn.cloudflare.net.,
> www.cloudflare.com.cdn.cloudflare.net. CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.,
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
> 198.41.212.157,
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
> 198.41.213.157 ar: . OPT UDPsize=512 OK (169)
> 11:44:44.904120 IP (tos 0x0, ttl 45, id 57740, offset 0, flags [none],
> proto UDP (17), length 197)
> 8.8.4.4.53 > 86.1.32.208.44272: [udp sum ok] 20890 q: A?
> www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME
> www.cloudflare.com.cdn.cloudflare.net.,
> www.cloudflare.com.cdn.cloudflare.net. CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.,
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
> 198.41.212.157,
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
> 198.41.213.157 ar: . OPT UDPsize=512 OK (169)
> 11:44:44.904720 IP (tos 0x90, ttl 64, id 16466, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.60232 > 8.8.8.8.53: [udp sum ok] 43145+ [1au] DS?
> www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
> 11:44:45.430963 IP (tos 0x0, ttl 49, id 13829, offset 0, flags [none],
> proto UDP (17), length 75)
> 8.8.8.8.53 > 86.1.32.208.60232: [udp sum ok] 43145 ServFail q: DS?
> www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
> 11:44:45.434094 IP (tos 0x90, ttl 64, id 16467, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.27765 > 8.8.8.8.53: [udp sum ok] 6810+ [1au] AAAA?
> www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
> 11:44:45.455145 IP (tos 0x0, ttl 47, id 13830, offset 0, flags [none],
> proto UDP (17), length 221)
> 8.8.8.8.53 > 86.1.32.208.27765: [udp sum ok] 6810 q: AAAA?
> www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME
> www.cloudflare.com.cdn.cloudflare.net.,
> www.cloudflare.com.cdn.cloudflare.net. CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.,
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. AAAA
> 2400:cb00:2048:1::c629:d59d,
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. AAAA
> 2400:cb00:2048:1::c629:d49d ar: . OPT UDPsize=512 OK (193)
> 11:44:45.455845 IP (tos 0x90, ttl 64, id 16468, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.63524 > 8.8.8.8.53: [udp sum ok] 37758+ [1au] DS?
> www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
> 11:44:45.895583 IP (tos 0x0, ttl 47, id 16395, offset 0, flags [none],
> proto UDP (17), length 75)
> 8.8.8.8.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS?
> www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
> 11:44:45.896049 IP (tos 0x90, ttl 64, id 26116, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.63524 > 8.8.4.4.53: [udp sum ok] 37758+ [b2&3=0x182]
> [1au] DS? www.cloudflare.com. ar: . OPT UDPsize=512 OK (47)
> 11:44:45.896242 IP (tos 0x90, ttl 64, id 16469, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.63524 > 8.8.8.8.53: [udp sum ok] 37758+ [b2&3=0x182]
> [1au] DS? www.cloudflare.com. ar: . OPT UDPsize=512 OK (47)
> 11:44:46.335616 IP (tos 0x0, ttl 46, id 44525, offset 0, flags [none],
> proto UDP (17), length 75)
> 8.8.4.4.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS?
> www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
> 11:44:46.341564 IP (tos 0x0, ttl 47, id 47460, offset 0, flags [none],
> proto UDP (17), length 75)
> 8.8.8.8.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS?
> www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
>
> That seems to suggest that it's the DS queries that are failing and that
> this is probably not a dnsmasq bug. Trying Verisign's DNSSEC debugger
> (http://dnssec-debugger.verisignlabs.com/blog.cloudflare.com) seems to
> suggest that their nameservers refuse requests for DNSKEY records.
>
> --
> Robert Bradley
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 899 bytes
> Desc: OpenPGP digital signature
> URL:
> <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/
> f7c270a9/attachment.pgp>
>
> ------------------------------
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
> End of Cerowrt-devel Digest, Vol 29, Issue 22
> *********************************************
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
2014-04-12 20:28 ` Sebastian Moeller
@ 2014-04-12 20:42 ` Valdis.Kletnieks
2014-04-13 13:57 ` Joel Stanley
1 sibling, 0 replies; 8+ messages in thread
From: Valdis.Kletnieks @ 2014-04-12 20:42 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: Frits Riep, cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 398 bytes --]
On Sat, 12 Apr 2014 22:28:49 +0200, Sebastian Moeller said:
> 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 wish to apologize for not testing it yet - I was on a working 36-3 image
and didn't dare break it as I was doing prep work for today's software
and firmware upgrades for several petabytes of storage...
[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
2014-04-12 20:28 ` Sebastian Moeller
2014-04-12 20:42 ` Valdis.Kletnieks
@ 2014-04-13 13:57 ` Joel Stanley
2014-04-14 11:48 ` Frits Riep
2014-04-14 13:17 ` Sebastian Moeller
1 sibling, 2 replies; 8+ messages in thread
From: Joel Stanley @ 2014-04-13 13:57 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: Frits Riep, cerowrt-devel
On Sun, Apr 13, 2014 at 5:58 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> I think Valdis Kletnieks reported the same for a 3800. Please try the "manual" route described below and report back your results to the list:
I attempted an upgrade using the web interface from -3 to -4 and it
also failed. I tried from the shell:
root@cerowrt:/tmp# sysupgrade -c -v
openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade_new.bin
Saving config files...
etc/lighttpd/lighttpd.pem
etc/passwd-
etc/fw_env.config
etc/shadow
etc/passwd
etc/group-
etc/ethers
etc/config/wireless
etc/config/system
etc/config/polipo
etc/config/ucitrack
etc/config/network
etc/config/ubootenv
etc/config/dropbear
etc/config/firewall
etc/config/upnpd
etc/config/fstab
etc/config/luci
etc/config/dhcp
etc/config/sqm
etc/dropbear/dropbear_rsa_host_key
etc/dropbear/authorized_keys
etc/dropbear/dropbear_dss_host_key
etc/sudoers
etc/shadow-
etc/samba/secrets.tdb
etc/samba/smbpasswd
etc/group
etc/firewall.user
killall: watchdog: no process killed
Sending TERM to remaining processes ... logd netifd odhcpd lighttpd
crond lighttpd snmpd pimd xinetd dbus-daemon smbd nmbd avahi-daemon
miniupnpd polipo babeld natpmp ahcpd rngd ntpd dnsmasq ubusd askfirst
Sending KILL to remaining processes ... askfirst
Switching to ramdisk...
Performing system upgrade...
Unlocking firmware ...
Writing from <stdin> to firmware ...
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not found
Error fixing up TRX header
Upgrade completed
Rebooting system...
After reboot:
root@cerowrt:~# cat /etc/openwrt_release
DISTRIB_ID="CeroWrt"
DISTRIB_RELEASE="3.10.36-4"
DISTRIB_REVISION="r40438"
The system appears to be working okay, except my 2.4GHz interface is
missing - I haven't spent any real time looking into that.
Regards,
Joel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
2014-04-13 13:57 ` Joel Stanley
@ 2014-04-14 11:48 ` Frits Riep
2014-04-14 13:17 ` Sebastian Moeller
1 sibling, 0 replies; 8+ messages in thread
From: Frits Riep @ 2014-04-14 11:48 UTC (permalink / raw)
To: 'Joel Stanley', 'Sebastian Moeller'; +Cc: cerowrt-devel
Thanks, Joel, Sebastian, and Valdis for your information and assistance.
I didn't know how to do the manual routes described, so I used a TFTP tool
to update the firmware to the latest by using the information on the OpenWRT
website on TFTP updating of the Netgear WNDR-3800. Of course, I could not
use the sysupdate version of the firmware, and in the TFTP update to the
bootloader the IP address for the target is 192.168.1.1 which is the default
for the bootloader.
The description on how to do this is actually in the WNDR3700 router:
http://wiki.openwrt.org/toh/netgear/wndr3700#upgrading.openwrt
"OEM installation using the TFTP method (recommended)
"Hold the 'System Restore' button on the underside of the router while
powering it on, and hold the button until the power led blinks green. Then,
upload the .img firmware as described in Installing OpenWrt via TFTP (see
the section titled Bootloader contains TFTP server). However, note that the
router will not accept the firmware when the filename is too long! Using
firmware.img as filename should work. After upload, the power led is turned
off and flashing starts, after that is finished the router will restart and
the power led will eventually become stable green (it will be stable orange
for quite some time first)."
Naturally, at this point I was at the factory defaults and needed to restore
my settings. Once I did that everything seems to be working well so far.
The wireless is working fine on both 2.4 and 5 Ghz. I also set up the sqm
to "fq-codel" and the latencies are rock stable on pings while running a
Speedtest (both up and down).
Thanks to all for the good work on this release. So the only issue I had
was that I could not get to this release using a firmware upgrade via the
web interface.
Frits
-----Original Message-----
From: joel.stan@gmail.com [mailto:joel.stan@gmail.com] On Behalf Of Joel
Stanley
Sent: Sunday, April 13, 2014 9:58 AM
To: Sebastian Moeller
Cc: Frits Riep; Valdis.Kletnieks@vt.edu; cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Having issue upgrading to latest image
3.10.36-4
On Sun, Apr 13, 2014 at 5:58 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> I think Valdis Kletnieks reported the same for a 3800. Please try the
"manual" route described below and report back your results to the list:
I attempted an upgrade using the web interface from -3 to -4 and it also
failed. I tried from the shell:
root@cerowrt:/tmp# sysupgrade -c -v
openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade_new.bin
Saving config files...
etc/lighttpd/lighttpd.pem
etc/passwd-
etc/fw_env.config
etc/shadow
etc/passwd
etc/group-
etc/ethers
etc/config/wireless
etc/config/system
etc/config/polipo
etc/config/ucitrack
etc/config/network
etc/config/ubootenv
etc/config/dropbear
etc/config/firewall
etc/config/upnpd
etc/config/fstab
etc/config/luci
etc/config/dhcp
etc/config/sqm
etc/dropbear/dropbear_rsa_host_key
etc/dropbear/authorized_keys
etc/dropbear/dropbear_dss_host_key
etc/sudoers
etc/shadow-
etc/samba/secrets.tdb
etc/samba/smbpasswd
etc/group
etc/firewall.user
killall: watchdog: no process killed
Sending TERM to remaining processes ... logd netifd odhcpd lighttpd crond
lighttpd snmpd pimd xinetd dbus-daemon smbd nmbd avahi-daemon miniupnpd
polipo babeld natpmp ahcpd rngd ntpd dnsmasq ubusd askfirst Sending KILL to
remaining processes ... askfirst Switching to ramdisk...
Performing system upgrade...
Unlocking firmware ...
Writing from <stdin> to firmware ...
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not
found Error fixing up TRX header
Upgrade completed
Rebooting system...
After reboot:
root@cerowrt:~# cat /etc/openwrt_release DISTRIB_ID="CeroWrt"
DISTRIB_RELEASE="3.10.36-4"
DISTRIB_REVISION="r40438"
The system appears to be working okay, except my 2.4GHz interface is missing
- I haven't spent any real time looking into that.
Regards,
Joel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
2014-04-13 13:57 ` Joel Stanley
2014-04-14 11:48 ` Frits Riep
@ 2014-04-14 13:17 ` Sebastian Moeller
2014-04-15 0:29 ` Joel Stanley
1 sibling, 1 reply; 8+ messages in thread
From: Sebastian Moeller @ 2014-04-14 13:17 UTC (permalink / raw)
To: Joel Stanley; +Cc: Frits Riep, cerowrt-devel
Hi Joel,
On Apr 13, 2014, at 15:57 , Joel Stanley <joel@jms.id.au> wrote:
> On Sun, Apr 13, 2014 at 5:58 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>> I think Valdis Kletnieks reported the same for a 3800. Please try the "manual" route described below and report back your results to the list:
>
> I attempted an upgrade using the web interface from -3 to -4 and it
> also failed. I tried from the shell:
>
> root@cerowrt:/tmp# sysupgrade -c -v
> openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade_new.bin
> Saving config files...
> etc/lighttpd/lighttpd.pem
> etc/passwd-
> etc/fw_env.config
> etc/shadow
> etc/passwd
> etc/group-
> etc/ethers
> etc/config/wireless
> etc/config/system
> etc/config/polipo
> etc/config/ucitrack
> etc/config/network
> etc/config/ubootenv
> etc/config/dropbear
> etc/config/firewall
> etc/config/upnpd
> etc/config/fstab
> etc/config/luci
> etc/config/dhcp
> etc/config/sqm
> etc/dropbear/dropbear_rsa_host_key
> etc/dropbear/authorized_keys
> etc/dropbear/dropbear_dss_host_key
> etc/sudoers
> etc/shadow-
> etc/samba/secrets.tdb
> etc/samba/smbpasswd
> etc/group
> etc/firewall.user
> killall: watchdog: no process killed
> Sending TERM to remaining processes ... logd netifd odhcpd lighttpd
> crond lighttpd snmpd pimd xinetd dbus-daemon smbd nmbd avahi-daemon
> miniupnpd polipo babeld natpmp ahcpd rngd ntpd dnsmasq ubusd askfirst
> Sending KILL to remaining processes ... askfirst
> Switching to ramdisk...
> Performing system upgrade...
> Unlocking firmware ...
>
> Writing from <stdin> to firmware ...
> Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not found
> Error fixing up TRX header
I would not be amazed if this issue would throw off the GUI method. Have you tried the GUI without keeping the configuration, and does that also fail? (When I update on the command line with the "-n" switch (do not keep old configuration) I do not see any of the two lines containing information about TRX)
Best Regards
Sebastian
>
> Upgrade completed
> Rebooting system...
>
> After reboot:
>
> root@cerowrt:~# cat /etc/openwrt_release
> DISTRIB_ID="CeroWrt"
> DISTRIB_RELEASE="3.10.36-4"
> DISTRIB_REVISION="r40438"
>
> The system appears to be working okay, except my 2.4GHz interface is
> missing - I haven't spent any real time looking into that.
>
> Regards,
>
> Joel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
2014-04-14 13:17 ` Sebastian Moeller
@ 2014-04-15 0:29 ` Joel Stanley
0 siblings, 0 replies; 8+ messages in thread
From: Joel Stanley @ 2014-04-15 0:29 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: Frits Riep, cerowrt-devel
On Mon, Apr 14, 2014 at 10:47 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> I would not be amazed if this issue would throw off the GUI method. Have you tried the GUI without keeping the configuration, and does that also fail? (When I update on the command line with the "-n" switch (do not keep old configuration) I do not see any of the two lines containing information about TRX)
No, I haven't tried that. I'll give it a go next time I upgrade.
Cheers,
Joel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
2014-04-12 18:46 [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4 Frits Riep
2014-04-12 20:28 ` Sebastian Moeller
@ 2014-04-19 19:12 ` Dave Taht
1 sibling, 0 replies; 8+ messages in thread
From: Dave Taht @ 2014-04-19 19:12 UTC (permalink / raw)
To: Frits Riep; +Cc: cerowrt-devel
I just tried a sysupgrade from 3.10.36-1 to 3.10.36-6 and saw this error go by:
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not found
Error fixing up TRX header
The upgrade did indeed succeed, regardless, and kept the files in place.
The only "big" update to the conf files I think I've made to the default
config since -1 was enabling dnssec-check-unsigned by default
in /etc/dnsmasq.conf
Going to go beat up wifi for a while today and look into some other dnssec
issues.
On Sat, Apr 12, 2014 at 11:46 AM, Frits Riep <riep@riepnet.com> wrote:
> I have a Netgear WNDR-3800 and I last updated the firmware about a week ago
> successfully using the web interface. I've been trying today to upgrade to
> the latest image the same way, but I am not having success and I've tried
> the download several times and even with three different browsers but the
> result is the same.
>
> Current Image is 3.10.36-3
> Using this new image for 3.10.36-4:
> openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin
> Error Message:
> The uploaded image file does not contain a supported format. Make sure that
> you choose the generic image format for your platform.
>
> Please advise if I need to do something different, or have I found a bug.
>
> thanks
>
> -----Original Message-----
> From: cerowrt-devel-bounces@lists.bufferbloat.net
> [mailto:cerowrt-devel-bounces@lists.bufferbloat.net] On Behalf Of
> cerowrt-devel-request@lists.bufferbloat.net
> Sent: Saturday, April 12, 2014 7:54 AM
> To: cerowrt-devel@lists.bufferbloat.net
> Subject: Cerowrt-devel Digest, Vol 29, Issue 22
>
> Send Cerowrt-devel mailing list submissions to
> cerowrt-devel@lists.bufferbloat.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> or, via email, send a message with subject or body 'help' to
> cerowrt-devel-request@lists.bufferbloat.net
>
> You can reach the person managing the list at
> cerowrt-devel-owner@lists.bufferbloat.net
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Cerowrt-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: wired article about bleed and bloat and underfunded
> critical infrastructure (dpreed@reed.com)
> 2. DNSSEC failure for *.cloudflare.com via dnsmasq? (Robert Bradley)
> 3. Re: DNSSEC failure for *.cloudflare.com via dnsmasq?
> (Toke H?iland-J?rgensen)
> 4. Re: DNSSEC failure for *.cloudflare.com via dnsmasq?
> (Robert Bradley)
> 5. Re: cerowrt-3.10.36-4 released (Neil Shepperd)
> 6. Re: DNSSEC failure for *.cloudflare.com via dnsmasq?
> (Robert Bradley)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 11 Apr 2014 15:43:19 -0400 (EDT)
> From: dpreed@reed.com
> To: "Dave Taht" <dave.taht@gmail.com>
> Cc: "cerowrt-devel@lists.bufferbloat.net"
> <cerowrt-devel@lists.bufferbloat.net>, bloat
> <bloat@lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] wired article about bleed and bloat and
> underfunded critical infrastructure
> Message-ID: <1397245399.392818481@apps.rackspace.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> I'm afraid it's not *just* underfunded. I reviewed the details of the code
> involved and the fixes, and my conclusion is that even programmers of
> security software have not learned how to think about design, testing, etc.
> Especially the continuing use of C in a large shared process address space
> for writing protocols that are by definition in the "security kernel"
> (according to the original definition) of applications on which the public
> depends.
>
> Ever since I was part of the Multics Security Project (which was part of the
> effort that produced the Orange Book
> http://csrc.nist.gov/publications/history/dod85.pdf) in the 80's, we've
> known that security-based code should not be exposed to user code and vice
> versa. Yet the SSL libraries are linked in, in userspace, with the
> application code.
>
> Also, upgrades/changes to protocols related to security (which always should
> have been in place on every end-to-end connection) should be reviewed *both
> at the protocol design level* and also at the *implementation level* because
> change creates risk. They should not be adopted blindly without serious
> examination and pen-testing, yet this change just was casually thrown in in
> a patch release.
>
> I suspect that even if it were well funded, the folks who deploy the
> technology would be slapdash at best. Remember the Y2K issue and the cost of
> lazy thinking about dates. (I feel a little superior because in 1968 Multics
> standardized on a 72-bit hardware microsecond-resolution hardware clock
> because the designers actually thought about long-lived systems (actually
> only 56 bits of the original clock worked, but the hardware was not expected
> to last until the remaining bits could be added)).
>
> The open source movement, unfortunately, made a monoculture of the SSL
> source code, so it's much more dangerous and the vulnerable attack surface
> of deployments is enormous.
>
> Rant off. The summary is that good engineering is not applied where it must
> be for the public interest. That remains true even if the NSA actually
> snuck this code into the SSL implementation.
>
>
> On Friday, April 11, 2014 2:22pm, "Dave Taht" <dave.taht@gmail.com> said:
>
>
>
>> http://www.wired.com/2014/04/heartbleedslesson/
>>
>> And Dan Kaminisky writes about "Code in the Age of Cholera"
>>
>> http://dankaminsky.com/2014/04/10/heartbleed/
>>
>>
>>
>> --
>> Dave T?ht
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140411/
> 5a81cc38/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 12 Apr 2014 12:06:55 +0100
> From: Robert Bradley <robert.bradley1@gmail.com>
> To: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
> Subject: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
> dnsmasq?
> Message-ID: <53491E4F.4040108@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I noticed today that attempts to visit www.cloudflare.com and other
> subdomains seem to be failing on the latest CeroWRT (3.10.36-4) when DNSSEC
> checks are enabled, but not if I query Google DNS directly.
>
> The resulting queries are:
>
> root@cerowrt:~# dig www.cloudflare.com A IN
>
> ; <<>> DiG 9.9.4 <<>> www.cloudflare.com A IN ;; global options: +cmd ;; Got
> answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23776 ;; flags: qr rd
> ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;www.cloudflare.com. IN A
>
> ;; Query time: 808 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Sat Apr 12 11:04:10 UTC 2014
> ;; MSG SIZE rcvd: 47
>
> root@cerowrt:~# dig +adflag www.cloudflare.com A IN
>
> ; <<>> DiG 9.9.4 <<>> +adflag www.cloudflare.com A IN ;; global options:
> +cmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3689 ;; flags: qr rd
> ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;www.cloudflare.com. IN A
>
> ;; Query time: 913 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Sat Apr 12 11:04:21 UTC 2014
> ;; MSG SIZE rcvd: 47
>
> root@cerowrt:~# dig +cdflag www.cloudflare.com A IN
>
> ; <<>> DiG 9.9.4 <<>> +cdflag www.cloudflare.com A IN ;; global options:
> +cmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19768 ;; flags: qr rd ra
> cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;www.cloudflare.com. IN A
>
> ;; ANSWER SECTION:
> www.cloudflare.com. 297 IN CNAME
> www.cloudflare.com.cdn.cloudflare.net.
> www.cloudflare.com.cdn.cloudflare.net. 297 IN CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 297 IN A
> 198.41.212.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> 297 IN A 198.41.213.157
>
> ;; Query time: 22 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Sat Apr 12 11:04:26 UTC 2014
> ;; MSG SIZE rcvd: 169
>
> root@cerowrt:~# dig @8.8.8.8 www.cloudflare.com A IN
>
> ; <<>> DiG 9.9.4 <<>> @8.8.8.8 www.cloudflare.com A IN ; (1 server found) ;;
> global options: +cmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31488 ;; flags: qr rd
> ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;www.cloudflare.com. IN A
>
> ;; ANSWER SECTION:
> www.cloudflare.com. 84 IN CNAME
> www.cloudflare.com.cdn.cloudflare.net.
> www.cloudflare.com.cdn.cloudflare.net. 166 IN CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 166 IN A
> 198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> 166 IN A 198.41.212.157
>
> ;; Query time: 22 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Sat Apr 12 11:04:35 UTC 2014
> ;; MSG SIZE rcvd: 169
>
> root@cerowrt:~# dig @8.8.8.8 +adflag www.cloudflare.com A IN
>
> ; <<>> DiG 9.9.4 <<>> @8.8.8.8 +adflag www.cloudflare.com A IN ; (1 server
> found) ;; global options: +cmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59486 ;; flags: qr rd
> ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;www.cloudflare.com. IN A
>
> ;; ANSWER SECTION:
> www.cloudflare.com. 77 IN CNAME
> www.cloudflare.com.cdn.cloudflare.net.
> www.cloudflare.com.cdn.cloudflare.net. 159 IN CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 159 IN A
> 198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> 159 IN A 198.41.212.157
>
> ;; Query time: 22 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Sat Apr 12 11:04:41 UTC 2014
> ;; MSG SIZE rcvd: 169
>
> root@cerowrt:~# dig @8.8.8.8 +cdflag www.cloudflare.com A IN
>
> ; <<>> DiG 9.9.4 <<>> @8.8.8.8 +cdflag www.cloudflare.com A IN ; (1 server
> found) ;; global options: +cmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43503 ;; flags: qr rd ra
> cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;www.cloudflare.com. IN A
>
> ;; ANSWER SECTION:
> www.cloudflare.com. 69 IN CNAME
> www.cloudflare.com.cdn.cloudflare.net.
> www.cloudflare.com.cdn.cloudflare.net. 151 IN CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 151 IN A
> 198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
> 151 IN A 198.41.212.157
>
> ;; Query time: 26 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Sat Apr 12 11:04:48 UTC 2014
> ;; MSG SIZE rcvd: 169
>
> root@cerowrt:~#
>
> Can anyone explain why this should be the case?
>
> --
> Robert Bradley
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 899 bytes
> Desc: OpenPGP digital signature
> URL:
> <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/
> 4de94408/attachment-0001.pgp>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 12 Apr 2014 13:11:56 +0200
> From: Toke H?iland-J?rgensen <toke@toke.dk>
> To: Robert Bradley <robert.bradley1@gmail.com>
> Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
> dnsmasq?
> Message-ID: <878urakdj7.fsf@alrua-x1.kau.toke.dk>
> Content-Type: text/plain
>
> Robert Bradley <robert.bradley1@gmail.com> writes:
>
>> Can anyone explain why this should be the case?
>
> If you turn on log-queries in the dnsmasq config, you can see the
> results of the dnssec validation in the logs which might give a hint :)
>
> -Toke
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 12 Apr 2014 12:13:25 +0100
> From: Robert Bradley <robert.bradley1@gmail.com>
> To: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
> dnsmasq?
> Message-ID: <53491FD5.4020600@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 12/04/2014 12:06, Robert Bradley wrote:
>> I noticed today that attempts to visit www.cloudflare.com and other
>> subdomains seem to be failing on the latest CeroWRT (3.10.36-4) when
>> DNSSEC checks are enabled, but not if I query Google DNS directly.
>
> If it helps, it seems to be an issue with dnssec-check-unsigned again.
> This time though was via Google's DNS. (Using the Virgin Media DNS
> servers, dnssec-check-unsigned kills all DNS as per my previous posts.)
>
> --
> Robert Bradley
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 899 bytes
> Desc: OpenPGP digital signature
> URL:
> <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/
> 04b015bc/attachment-0001.pgp>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 12 Apr 2014 21:45:09 +1000
> From: Neil Shepperd <nshepperd@gmail.com>
> To: cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] cerowrt-3.10.36-4 released
> Message-ID: <53492745.90101@gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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.
>>
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 12 Apr 2014 12:53:29 +0100
> From: Robert Bradley <robert.bradley1@gmail.com>
> To: Toke H?iland-J?rgensen <toke@toke.dk>
> Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
> dnsmasq?
> Message-ID: <53492939.4090508@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 12/04/2014 12:11, Toke H?iland-J?rgensen wrote:
>> Robert Bradley <robert.bradley1@gmail.com> writes:
>>
>>> Can anyone explain why this should be the case?
>> If you turn on log-queries in the dnsmasq config, you can see the
>> results of the dnssec validation in the logs which might give a hint :)
>>
>> -Toke
>
> OK, with log-queries on I get:
>
> Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: query[A]
> www.cloudflare.com from 127.0.0.1
> Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: forwarded
> www.cloudflare.com to 8.8.4.4
> Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: dnssec-query[DS]
> www.cloudflare.com to 8.8.4.4
> Sat Apr 12 11:41:51 2014 daemon.info dnsmasq[14581]: forwarded
> www.cloudflare.com to 8.8.8.8
> Sat Apr 12 11:41:51 2014 daemon.info dnsmasq[14581]: forwarded
> www.cloudflare.com to 8.8.4.4
> Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
> www.cloudflare.com is BOGUS DS
> Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: validation result
> is BOGUS
> Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
> www.cloudflare.com is <CNAME>
> Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
> www.cloudflare.com.cdn.cloudflare.net is <CNAME>
> Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net is 198.41.213.157
> Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net is 198.41.212.157
>
> Running tcpdump -i ge00 port 53 -v -v -n during a query from Windows 7
> nslookup, I see:
>
> 11:44:44.884477 IP (tos 0x90, ttl 64, id 16465, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.44272 > 8.8.8.8.53: [udp sum ok] 20890+ [1au] A?
> www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
> 11:44:44.884652 IP (tos 0x90, ttl 64, id 26115, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.44272 > 8.8.4.4.53: [udp sum ok] 20890+ [1au] A?
> www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
> 11:44:44.904068 IP (tos 0x0, ttl 47, id 47459, offset 0, flags [none],
> proto UDP (17), length 197)
> 8.8.8.8.53 > 86.1.32.208.44272: [udp sum ok] 20890 q: A?
> www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME
> www.cloudflare.com.cdn.cloudflare.net.,
> www.cloudflare.com.cdn.cloudflare.net. CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.,
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
> 198.41.212.157,
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
> 198.41.213.157 ar: . OPT UDPsize=512 OK (169)
> 11:44:44.904120 IP (tos 0x0, ttl 45, id 57740, offset 0, flags [none],
> proto UDP (17), length 197)
> 8.8.4.4.53 > 86.1.32.208.44272: [udp sum ok] 20890 q: A?
> www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME
> www.cloudflare.com.cdn.cloudflare.net.,
> www.cloudflare.com.cdn.cloudflare.net. CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.,
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
> 198.41.212.157,
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
> 198.41.213.157 ar: . OPT UDPsize=512 OK (169)
> 11:44:44.904720 IP (tos 0x90, ttl 64, id 16466, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.60232 > 8.8.8.8.53: [udp sum ok] 43145+ [1au] DS?
> www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
> 11:44:45.430963 IP (tos 0x0, ttl 49, id 13829, offset 0, flags [none],
> proto UDP (17), length 75)
> 8.8.8.8.53 > 86.1.32.208.60232: [udp sum ok] 43145 ServFail q: DS?
> www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
> 11:44:45.434094 IP (tos 0x90, ttl 64, id 16467, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.27765 > 8.8.8.8.53: [udp sum ok] 6810+ [1au] AAAA?
> www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
> 11:44:45.455145 IP (tos 0x0, ttl 47, id 13830, offset 0, flags [none],
> proto UDP (17), length 221)
> 8.8.8.8.53 > 86.1.32.208.27765: [udp sum ok] 6810 q: AAAA?
> www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME
> www.cloudflare.com.cdn.cloudflare.net.,
> www.cloudflare.com.cdn.cloudflare.net. CNAME
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.,
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. AAAA
> 2400:cb00:2048:1::c629:d59d,
> cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. AAAA
> 2400:cb00:2048:1::c629:d49d ar: . OPT UDPsize=512 OK (193)
> 11:44:45.455845 IP (tos 0x90, ttl 64, id 16468, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.63524 > 8.8.8.8.53: [udp sum ok] 37758+ [1au] DS?
> www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
> 11:44:45.895583 IP (tos 0x0, ttl 47, id 16395, offset 0, flags [none],
> proto UDP (17), length 75)
> 8.8.8.8.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS?
> www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
> 11:44:45.896049 IP (tos 0x90, ttl 64, id 26116, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.63524 > 8.8.4.4.53: [udp sum ok] 37758+ [b2&3=0x182]
> [1au] DS? www.cloudflare.com. ar: . OPT UDPsize=512 OK (47)
> 11:44:45.896242 IP (tos 0x90, ttl 64, id 16469, offset 0, flags [DF],
> proto UDP (17), length 75)
> 86.1.32.208.63524 > 8.8.8.8.53: [udp sum ok] 37758+ [b2&3=0x182]
> [1au] DS? www.cloudflare.com. ar: . OPT UDPsize=512 OK (47)
> 11:44:46.335616 IP (tos 0x0, ttl 46, id 44525, offset 0, flags [none],
> proto UDP (17), length 75)
> 8.8.4.4.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS?
> www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
> 11:44:46.341564 IP (tos 0x0, ttl 47, id 47460, offset 0, flags [none],
> proto UDP (17), length 75)
> 8.8.8.8.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS?
> www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
>
> That seems to suggest that it's the DS queries that are failing and that
> this is probably not a dnsmasq bug. Trying Verisign's DNSSEC debugger
> (http://dnssec-debugger.verisignlabs.com/blog.cloudflare.com) seems to
> suggest that their nameservers refuse requests for DNSKEY records.
>
> --
> Robert Bradley
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 899 bytes
> Desc: OpenPGP digital signature
> URL:
> <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/
> f7c270a9/attachment.pgp>
>
> ------------------------------
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
> End of Cerowrt-devel Digest, Vol 29, Issue 22
> *********************************************
>
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-04-19 19:12 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-12 18:46 [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4 Frits Riep
2014-04-12 20:28 ` Sebastian Moeller
2014-04-12 20:42 ` Valdis.Kletnieks
2014-04-13 13:57 ` Joel Stanley
2014-04-14 11:48 ` Frits Riep
2014-04-14 13:17 ` Sebastian Moeller
2014-04-15 0:29 ` Joel Stanley
2014-04-19 19:12 ` Dave Taht
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox