[Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4

Sebastian Moeller moeller0 at gmx.de
Sat Apr 12 16:28:49 EDT 2014


Hi Frits,


On Apr 12, 2014, at 20:46 , Frits Riep <riep at 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 at gw.home.lan:/tmp
ssh root at 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 at lists.bufferbloat.net
> [mailto:cerowrt-devel-bounces at lists.bufferbloat.net] On Behalf Of
> cerowrt-devel-request at lists.bufferbloat.net
> Sent: Saturday, April 12, 2014 7:54 AM
> To: cerowrt-devel at lists.bufferbloat.net
> Subject: Cerowrt-devel Digest, Vol 29, Issue 22
> 
> Send Cerowrt-devel mailing list submissions to
> 	cerowrt-devel at 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 at lists.bufferbloat.net
> 
> You can reach the person managing the list at
> 	cerowrt-devel-owner at 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 at 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 at reed.com
> To: "Dave Taht" <dave.taht at gmail.com>
> Cc: "cerowrt-devel at lists.bufferbloat.net"
> 	<cerowrt-devel at lists.bufferbloat.net>, bloat
> 	<bloat at lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] wired article about bleed and bloat and
> 	underfunded critical infrastructure
> Message-ID: <1397245399.392818481 at 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 at 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 at 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 at gmail.com>
> To: cerowrt-devel <cerowrt-devel at lists.bufferbloat.net>
> Subject: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
> 	dnsmasq?
> Message-ID: <53491E4F.4040108 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at toke.dk>
> To: Robert Bradley <robert.bradley1 at gmail.com>
> Cc: cerowrt-devel <cerowrt-devel at lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
> 	dnsmasq?
> Message-ID: <878urakdj7.fsf at alrua-x1.kau.toke.dk>
> Content-Type: text/plain
> 
> Robert Bradley <robert.bradley1 at 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 at gmail.com>
> To: cerowrt-devel <cerowrt-devel at lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
> 	dnsmasq?
> Message-ID: <53491FD5.4020600 at 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 at gmail.com>
> To: cerowrt-devel at lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] cerowrt-3.10.36-4 released
> Message-ID: <53492745.90101 at 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 at gmail.com>
> To: Toke H?iland-J?rgensen <toke at toke.dk>
> Cc: cerowrt-devel <cerowrt-devel at lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
> 	dnsmasq?
> Message-ID: <53492939.4090508 at 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 at 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 at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel




More information about the Cerowrt-devel mailing list