* [Cerowrt-devel] test-ipv6.com vs dnssec @ 2014-04-25 17:39 Dave Taht 2014-04-25 18:01 ` Jim Gettys 0 siblings, 1 reply; 15+ messages in thread From: Dave Taht @ 2014-04-25 17:39 UTC (permalink / raw) To: cerowrt-devel, dnsmasq-discuss jg tells me the test-ipv6.com site fails with dnssec and enabled on native ipv6. disabling dnssec works. anyone can confirm? get a log/packet capture? -- Dave Täht ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] test-ipv6.com vs dnssec 2014-04-25 17:39 [Cerowrt-devel] test-ipv6.com vs dnssec Dave Taht @ 2014-04-25 18:01 ` Jim Gettys 2014-04-25 18:45 ` James Cloos ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Jim Gettys @ 2014-04-25 18:01 UTC (permalink / raw) To: Dave Taht; +Cc: dnsmasq-discuss, cerowrt-devel [-- Attachment #1: Type: text/plain, Size: 924 bytes --] More specifically, after boot, most of the time test-ipv6.com reports lots of problems. Then I turned off both dnssec and dnssec-check-unsigned, and restarted dnsmasq; clean bill of health from test-ipv6.com. Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a clean bill of health. Then I turned on both at the same time, and things are working. So we seem to have a boot time race of some sort. - Jim On Fri, Apr 25, 2014 at 1:39 PM, Dave Taht <dave.taht@gmail.com> wrote: > jg tells me the test-ipv6.com site fails with dnssec and enabled on > native ipv6. > > disabling dnssec works. > > anyone can confirm? get a log/packet capture? > > > -- > Dave Täht > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > [-- Attachment #2: Type: text/html, Size: 2209 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] test-ipv6.com vs dnssec 2014-04-25 18:01 ` Jim Gettys @ 2014-04-25 18:45 ` James Cloos 2014-04-25 18:49 ` [Cerowrt-devel] [Dnsmasq-discuss] " Simon Kelley 2014-04-25 19:24 ` [Cerowrt-devel] " Török Edwin 2 siblings, 0 replies; 15+ messages in thread From: James Cloos @ 2014-04-25 18:45 UTC (permalink / raw) To: cerowrt-devel; +Cc: dnsmasq-discuss None of the posted examples which I've looked at have been dnssec signed. There must be a bug in how dnsmasq tries to prove the non-existance of the signatures. Unbound, running on a box inside of a openwrt nat, has no problems with any of them. To confirm whether the bug is in dnsmasq or at goog, someone should run their own verifying resolver (such as unbound) on a public box, open it just enough for their cerowrt to use it, configure it to log verbosely, and have their cero use it. If that also leads to fails, then dnsmasq has the bug. Otherwise, goog does something "interesting". How much ram is available in cero for the resolver? Unbound on glibc/ amd64 only needs a bit less than 78M virt, 18M rss (with a well-stocked cache). The other verifying resolvers probably need similar resources. Even back when I used a dialup, unbound was perfectly usable inside¹. The extra traffic from verifying from the roots down shouldn't hurt. 1] in its early days it could DoS, but that issue was fixed. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] test-ipv6.com vs dnssec 2014-04-25 18:01 ` Jim Gettys 2014-04-25 18:45 ` James Cloos @ 2014-04-25 18:49 ` Simon Kelley 2014-04-25 19:43 ` Török Edwin 2014-04-28 19:07 ` Dave Taht 2014-04-25 19:24 ` [Cerowrt-devel] " Török Edwin 2 siblings, 2 replies; 15+ messages in thread From: Simon Kelley @ 2014-04-25 18:49 UTC (permalink / raw) To: Jim Gettys, Dave Taht; +Cc: dnsmasq-discuss, cerowrt-devel On 25/04/14 19:01, Jim Gettys wrote: > More specifically, after boot, most of the time test-ipv6.com reports lots > of problems. > > Then I turned off both dnssec and dnssec-check-unsigned, and restarted > dnsmasq; clean bill of health from test-ipv6.com. > > Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a > clean bill of health. > > Then I turned on both at the same time, and things are working. > > So we seem to have a boot time race of some sort. > - Jim > > test-ipv6.com is unsigned, so the important thing which is likely failing is the query for the DS record of test-ipv6.com, which should return NSEC records providing it doesn't exist, signed by .com Simon. > > On Fri, Apr 25, 2014 at 1:39 PM, Dave Taht <dave.taht@gmail.com> wrote: > >> jg tells me the test-ipv6.com site fails with dnssec and enabled on >> native ipv6. >> >> disabling dnssec works. >> >> anyone can confirm? get a log/packet capture? >> >> >> -- >> Dave Täht >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] test-ipv6.com vs dnssec 2014-04-25 18:49 ` [Cerowrt-devel] [Dnsmasq-discuss] " Simon Kelley @ 2014-04-25 19:43 ` Török Edwin 2014-04-25 19:48 ` Török Edwin 2014-04-28 19:07 ` Dave Taht 1 sibling, 1 reply; 15+ messages in thread From: Török Edwin @ 2014-04-25 19:43 UTC (permalink / raw) To: cerowrt-devel On 04/25/2014 09:49 PM, Simon Kelley wrote: > On 25/04/14 19:01, Jim Gettys wrote: >> More specifically, after boot, most of the time test-ipv6.com reports lots >> of problems. >> >> Then I turned off both dnssec and dnssec-check-unsigned, and restarted >> dnsmasq; clean bill of health from test-ipv6.com. >> >> Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a >> clean bill of health. >> >> Then I turned on both at the same time, and things are working. >> >> So we seem to have a boot time race of some sort. >> - Jim >> >> > > > test-ipv6.com is unsigned, so the important thing which is likely > failing is the query for the DS record of test-ipv6.com, which should > return NSEC records providing it doesn't exist, signed by .com According to http://dnssec-debugger.verisignlabs.com/test-ipv6.com test-ipv6.com No DS records found for test-ipv6.com in the com zone Query to ns1.test-ipv6.com/216.218.228.118 for test-ipv6.com/DNSKEY timed out or failed Query to ns2.test-ipv6.com/209.128.193.197 for test-ipv6.com/DNSKEY timed out or failed Failed to get DNSKEY RR set for zone test-ipv6.com No response from test-ipv6.com nameservers Compare this to a domain that works with check-unsigned on: openwrt.org No DS records found for openwrt.org in the org zone No DNSKEY records found openwrt.org A RR has value 78.24.191.177 No RRSIGs found Is the timeout/failed DNSKEY reply for test-ipv6.com the problem? with dnssec-check-unsigned turned on (and no IPv6, just IPv4) I get this: dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12 dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1 dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12 dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1 dnsmasq: query[A] test-ipv6.com from 172.30.42.12 dnsmasq: forwarded test-ipv6.com to 213.154.124.1 dnsmasq: dnssec-query[DS] test-ipv6.com to 213.154.124.1 dnsmasq: dnssec-query[DNSKEY] com to 213.154.124.1 dnsmasq: dnssec-query[DS] com to 213.154.124.1 dnsmasq: dnssec-query[DNSKEY] . to 213.154.124.1 dnsmasq: reply . is DNSKEY keytag 40926 dnsmasq: reply . is DNSKEY keytag 19036 dnsmasq: reply com is DS keytag 30909 dnsmasq: reply com is DNSKEY keytag 30909 dnsmasq: reply com is DNSKEY keytag 56657 dnsmasq: validation result is INSECURE dnsmasq: reply test-ipv6.com is 216.218.228.119 dnsmasq: query[A] ipv4.test-ipv6.com.home.lan from 172.30.42.12 dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN dnsmasq: query[AAAA] ipv4.test-ipv6.com.home.lan from 172.30.42.12 dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12 dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 213.154.124.1 dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12 dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 dnsmasq: query[A] ipv6.test-ipv6.com from 172.30.42.12 dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1 dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 213.154.124.1 dnsmasq: query[AAAA] ipv6.test-ipv6.com from 172.30.42.12 dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1 dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 213.154.124.1 dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 213.154.124.1 dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12 dnsmasq: dnssec retry to 213.154.124.1 dnsmasq: reply ipv4.test-ipv6.com is BOGUS DS dnsmasq: validation result is BOGUS dnsmasq: reply ipv4.test-ipv6.com is 216.218.228.119 dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12 dnsmasq: dnssec retry to 213.154.124.1 dnsmasq: query[A] ipv6.test-ipv6.com from 172.30.42.12 dnsmasq: dnssec retry to 213.154.124.1 dnsmasq: query[AAAA] ipv6.test-ipv6.com from 172.30.42.12 dnsmasq: dnssec retry to 213.154.124.1 dnsmasq: query[A] ipv4.test-ipv6.com.home.lan from 172.30.42.12 dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN dnsmasq: query[AAAA] ipv4.test-ipv6.com.home.lan from 172.30.42.12 dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 dnsmasq: query[A] ipv6.test-ipv6.com.home.lan from 172.30.42.12 dnsmasq: config ipv6.test-ipv6.com.home.lan is NXDOMAIN dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1 dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1 dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1 dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1 dnsmasq: query[AAAA] ipv6.test-ipv6.com.home.lan from 172.30.42.12 dnsmasq: config ipv6.test-ipv6.com.home.lan is NXDOMAIN dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12 dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1 dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12 dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1 dnsmasq: query[A] ipv6.test-ipv6.com from 172.30.42.12 dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1 dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 193.231.252.1 dnsmasq: query[AAAA] ipv6.test-ipv6.com from 172.30.42.12 dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1 dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 193.231.252.1 dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12 dnsmasq: dnssec retry to 193.231.252.1 dnsmasq: reply ipv4.test-ipv6.com is BOGUS DS dnsmasq: validation result is BOGUS dnsmasq: reply ipv4.test-ipv6.com is 216.218.228.119 dnsmasq: reply ipv4.test-ipv6.com is BOGUS DS dnsmasq: validation result is BOGUS dnsmasq: reply ipv4.test-ipv6.com is NODATA-IPv6 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] test-ipv6.com vs dnssec 2014-04-25 19:43 ` Török Edwin @ 2014-04-25 19:48 ` Török Edwin 0 siblings, 0 replies; 15+ messages in thread From: Török Edwin @ 2014-04-25 19:48 UTC (permalink / raw) To: cerowrt-devel On 04/25/2014 10:43 PM, Török Edwin wrote: > On 04/25/2014 09:49 PM, Simon Kelley wrote: >> On 25/04/14 19:01, Jim Gettys wrote: >>> More specifically, after boot, most of the time test-ipv6.com reports lots >>> of problems. >>> >>> Then I turned off both dnssec and dnssec-check-unsigned, and restarted >>> dnsmasq; clean bill of health from test-ipv6.com. >>> >>> Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a >>> clean bill of health. >>> >>> Then I turned on both at the same time, and things are working. >>> >>> So we seem to have a boot time race of some sort. >>> - Jim >>> >>> >> >> >> test-ipv6.com is unsigned, so the important thing which is likely >> failing is the query for the DS record of test-ipv6.com, which should >> return NSEC records providing it doesn't exist, signed by .com Also retrieving those signatures seems to work (from the LAN): $ dig +dnssec -t DS test-ipv6.com ; <<>> DiG 9.9.5-3-Debian <<>> +dnssec -t DS test-ipv6.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47250 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;test-ipv6.com. IN DS ;; AUTHORITY SECTION: com. 874 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1398455240 1800 900 604800 86400 com. 874 IN RRSIG SOA 8 1 900 20140502194720 20140425183720 56657 com. Em3k/33z2feLqtirerPNVE4HwF+ZstYVtR+J7rowCn/++FnDtRv7OBZp rbtNBI90BQj23QjzEkrwaBmVfcFOQSNhdAIHFxPSqOPCWbxdwQxf18yi 3ifhorL9mUX7ir2AqLb57LX+sPaFYOlAPQSIie4+nELiXZfH4mQ2cEXr eLY= CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 874 IN RRSIG NSEC3 8 2 86400 20140501044827 20140424033827 56657 com. JUeicIqLHJIYo10Z0M2LbKefhiW3g2T45jv0l0wxZC/8fdKLCBqIpk2k cjy1CSs1pzpR58BZM3E7QfVMZO61ncCOnK1Zarry6Z0ZYMm54sL625dl MMfYMhMpLVuzbBaK8TJmX3jvQWR8bxkoEXYUy3bP7+x88lHPK6wYkJlB VSA= CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 874 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM ERPPHPFQOHA3Q5F237FVRROKA4N73V2M.com. 874 IN RRSIG NSEC3 8 2 86400 20140501112409 20140424101409 56657 com. Zbz49pAXUE4iYhGmN3ywbWpWECc4fdBkT2HBwApFLr4UGDG67YbjtxhI D4ihlqTCKZES4/zFp4DqdA45/ha6m6nKUfo4/hE2y/ljhGbx08GqY3Ba cBWvBrfnmS1EGU8Yh1VG8tQ5CYK8qO6isUIzyGaV4Wpn4SQmTEAmaqfn FHk= ERPPHPFQOHA3Q5F237FVRROKA4N73V2M.com. 874 IN NSEC3 1 1 0 - ERPT5A7MVN31GIUL5DMRAU0K8N2IGLTI NS DS RRSIG ;; Query time: 29 msec ;; SERVER: 172.30.42.1#53(172.30.42.1) ;; WHEN: Fri Apr 25 22:48:01 EEST 2014 ;; MSG SIZE rcvd: 763 > > According to http://dnssec-debugger.verisignlabs.com/test-ipv6.com > test-ipv6.com > No DS records found for test-ipv6.com in the com zone > Query to ns1.test-ipv6.com/216.218.228.118 for test-ipv6.com/DNSKEY timed out or failed > Query to ns2.test-ipv6.com/209.128.193.197 for test-ipv6.com/DNSKEY timed out or failed > Failed to get DNSKEY RR set for zone test-ipv6.com > No response from test-ipv6.com nameservers > > Compare this to a domain that works with check-unsigned on: > openwrt.org > No DS records found for openwrt.org in the org zone > No DNSKEY records found > openwrt.org A RR has value 78.24.191.177 > No RRSIGs found > > Is the timeout/failed DNSKEY reply for test-ipv6.com the problem? > > with dnssec-check-unsigned turned on (and no IPv6, just IPv4) I get this: > dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12 > dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 > dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 > dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1 > dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12 > dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 > dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1 > dnsmasq: query[A] test-ipv6.com from 172.30.42.12 > dnsmasq: forwarded test-ipv6.com to 213.154.124.1 > dnsmasq: dnssec-query[DS] test-ipv6.com to 213.154.124.1 > dnsmasq: dnssec-query[DNSKEY] com to 213.154.124.1 > dnsmasq: dnssec-query[DS] com to 213.154.124.1 > dnsmasq: dnssec-query[DNSKEY] . to 213.154.124.1 > dnsmasq: reply . is DNSKEY keytag 40926 > dnsmasq: reply . is DNSKEY keytag 19036 > dnsmasq: reply com is DS keytag 30909 > dnsmasq: reply com is DNSKEY keytag 30909 > dnsmasq: reply com is DNSKEY keytag 56657 > dnsmasq: validation result is INSECURE > dnsmasq: reply test-ipv6.com is 216.218.228.119 > dnsmasq: query[A] ipv4.test-ipv6.com.home.lan from 172.30.42.12 > dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN > dnsmasq: query[AAAA] ipv4.test-ipv6.com.home.lan from 172.30.42.12 > dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN > dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12 > dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 > dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 213.154.124.1 > dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12 > dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 > dnsmasq: query[A] ipv6.test-ipv6.com from 172.30.42.12 > dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1 > dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 213.154.124.1 > dnsmasq: query[AAAA] ipv6.test-ipv6.com from 172.30.42.12 > dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1 > dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 213.154.124.1 > dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 213.154.124.1 > dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12 > dnsmasq: dnssec retry to 213.154.124.1 > dnsmasq: reply ipv4.test-ipv6.com is BOGUS DS > dnsmasq: validation result is BOGUS > dnsmasq: reply ipv4.test-ipv6.com is 216.218.228.119 > dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 > dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 > dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12 > dnsmasq: dnssec retry to 213.154.124.1 > dnsmasq: query[A] ipv6.test-ipv6.com from 172.30.42.12 > dnsmasq: dnssec retry to 213.154.124.1 > dnsmasq: query[AAAA] ipv6.test-ipv6.com from 172.30.42.12 > dnsmasq: dnssec retry to 213.154.124.1 > dnsmasq: query[A] ipv4.test-ipv6.com.home.lan from 172.30.42.12 > dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN > dnsmasq: query[AAAA] ipv4.test-ipv6.com.home.lan from 172.30.42.12 > dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN > dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 > dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 > dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 > dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 > dnsmasq: query[A] ipv6.test-ipv6.com.home.lan from 172.30.42.12 > dnsmasq: config ipv6.test-ipv6.com.home.lan is NXDOMAIN > dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1 > dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1 > dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1 > dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1 > dnsmasq: query[AAAA] ipv6.test-ipv6.com.home.lan from 172.30.42.12 > dnsmasq: config ipv6.test-ipv6.com.home.lan is NXDOMAIN > dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12 > dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 > dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1 > dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1 > dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12 > dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1 > dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1 > dnsmasq: query[A] ipv6.test-ipv6.com from 172.30.42.12 > dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1 > dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 193.231.252.1 > dnsmasq: query[AAAA] ipv6.test-ipv6.com from 172.30.42.12 > dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1 > dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 193.231.252.1 > dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12 > dnsmasq: dnssec retry to 193.231.252.1 > dnsmasq: reply ipv4.test-ipv6.com is BOGUS DS > dnsmasq: validation result is BOGUS > dnsmasq: reply ipv4.test-ipv6.com is 216.218.228.119 > dnsmasq: reply ipv4.test-ipv6.com is BOGUS DS > dnsmasq: validation result is BOGUS > dnsmasq: reply ipv4.test-ipv6.com is NODATA-IPv6 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] test-ipv6.com vs dnssec 2014-04-25 18:49 ` [Cerowrt-devel] [Dnsmasq-discuss] " Simon Kelley 2014-04-25 19:43 ` Török Edwin @ 2014-04-28 19:07 ` Dave Taht 2014-04-28 19:57 ` James Cloos 1 sibling, 1 reply; 15+ messages in thread From: Dave Taht @ 2014-04-28 19:07 UTC (permalink / raw) To: Simon Kelley; +Cc: dnsmasq-discuss, cerowrt-devel On Fri, Apr 25, 2014 at 11:49 AM, Simon Kelley <simon@thekelleys.org.uk> wrote: > On 25/04/14 19:01, Jim Gettys wrote: >> More specifically, after boot, most of the time test-ipv6.com reports lots >> of problems. >> >> Then I turned off both dnssec and dnssec-check-unsigned, and restarted >> dnsmasq; clean bill of health from test-ipv6.com. >> >> Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a >> clean bill of health. >> >> Then I turned on both at the same time, and things are working. >> >> So we seem to have a boot time race of some sort. >> - Jim >> >> > > > test-ipv6.com is unsigned, so the important thing which is likely > failing is the query for the DS record of test-ipv6.com, which should > return NSEC records providing it doesn't exist, signed by .com As one example of a registrar not with the program, name.com (registrar for bufferbloat.net) does not allow for ds records to come from it, so that domain can't be fully signed. So it sounds to me as if negative proofs are not possible with registrars that lack this support? > > Simon. > > > >> >> On Fri, Apr 25, 2014 at 1:39 PM, Dave Taht <dave.taht@gmail.com> wrote: >> >>> jg tells me the test-ipv6.com site fails with dnssec and enabled on >>> native ipv6. >>> >>> disabling dnssec works. >>> >>> anyone can confirm? get a log/packet capture? >>> >>> >>> -- >>> Dave Täht >>> _______________________________________________ >>> Cerowrt-devel mailing list >>> Cerowrt-devel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>> >> >> >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss@lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] test-ipv6.com vs dnssec 2014-04-28 19:07 ` Dave Taht @ 2014-04-28 19:57 ` James Cloos 2014-04-28 20:17 ` Török Edwin 0 siblings, 1 reply; 15+ messages in thread From: James Cloos @ 2014-04-28 19:57 UTC (permalink / raw) To: Dave Taht; +Cc: dnsmasq-discuss, cerowrt-devel >>>>> "DT" == Dave Taht <dave.taht@gmail.com> writes: DT> As one example of a registrar not with the program, name.com DT> (registrar for bufferbloat.net) does not allow for ds records to DT> come from it, so that domain can't be fully signed. DT> So it sounds to me as if negative proofs are not possible with DT> registrars that lack this support? No. Signed parent zones (like com, net, org) always provide either a signed DS record if it exists or proof of non-existance. Try doing: dig @i.gtld-servers.net. bufferbloat.net ds +dnssec The two nsec3 records (each signed by an rrsig record) prove that there is no DS record in net. with the name bufferbloat.net. Compare that with what you get asking for ns records: That replies with the two ns records, as well as the proof that the DS records do not exist. Now, try with a zone which is signed: dig @i.gtld-servers.net. jhcloos.net ns +dnssec dig @i.gtld-servers.net. jhcloos.net ds +dnssec The first returns both the ns and ds records, with an rrsig over the ds records (returned in the authority section); the latter returns the signed ds records in the answer section and net's own signed ns set in the authority section. Given that some zones have nameservers which fail to respond if they do not like or understand the query, it seems that only root-down verifi- cation can work. Unless I'm missing something.... -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] test-ipv6.com vs dnssec 2014-04-28 19:57 ` James Cloos @ 2014-04-28 20:17 ` Török Edwin 2014-04-30 21:44 ` James Cloos 0 siblings, 1 reply; 15+ messages in thread From: Török Edwin @ 2014-04-28 20:17 UTC (permalink / raw) To: cerowrt-devel On 04/28/2014 10:57 PM, James Cloos wrote: >>>>>> "DT" == Dave Taht <dave.taht@gmail.com> writes: > > DT> As one example of a registrar not with the program, name.com > DT> (registrar for bufferbloat.net) does not allow for ds records to > DT> come from it, so that domain can't be fully signed. > > DT> So it sounds to me as if negative proofs are not possible with > DT> registrars that lack this support? > > No. Signed parent zones (like com, net, org) always provide either a > signed DS record if it exists or proof of non-existance. > > Try doing: > > dig @i.gtld-servers.net. bufferbloat.net ds +dnssec > > The two nsec3 records (each signed by an rrsig record) prove that there > is no DS record in net. with the name bufferbloat.net. > > Compare that with what you get asking for ns records: > > That replies with the two ns records, as well as the proof that the DS > records do not exist. > > Now, try with a zone which is signed: > > dig @i.gtld-servers.net. jhcloos.net ns +dnssec > dig @i.gtld-servers.net. jhcloos.net ds +dnssec > > The first returns both the ns and ds records, with an rrsig over the ds > records (returned in the authority section); the latter returns the > signed ds records in the answer section and net's own signed ns set in > the authority section. > > Given that some zones have nameservers which fail to respond if they do > not like or understand the query, it seems that only root-down verifi- > cation can work. Unless I'm missing something.... Given that a NS is more likely to get answered than a DS (by a nameserver that is broken/doesn't support DNSSEC), can you make a NS query, and decide based on the reply whether you should switch to a top-down verification? i.e. if the NS answer included everything you wanted, then you're done, otherwise, for broken nameserver, you fallback to verifying from the root that they're indeed unsigned. Does that make sense, or the NS reply doesn't have all the required info? Best regards, --Edwin ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] [Dnsmasq-discuss] test-ipv6.com vs dnssec 2014-04-28 20:17 ` Török Edwin @ 2014-04-30 21:44 ` James Cloos 0 siblings, 0 replies; 15+ messages in thread From: James Cloos @ 2014-04-30 21:44 UTC (permalink / raw) To: Török Edwin; +Cc: cerowrt-devel >>>>> "TE" == Török Edwin <edwin+ml-cerowrt@etorok.net> writes: TE> or the NS reply doesn't have all the required info? Replies to NS requests include DS records iff the requests are sent to the parent of the zone, even when the requestor sets the DO bit. That is to say, when the replies are glue records. Everything is optimized for root->down verification. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] test-ipv6.com vs dnssec 2014-04-25 18:01 ` Jim Gettys 2014-04-25 18:45 ` James Cloos 2014-04-25 18:49 ` [Cerowrt-devel] [Dnsmasq-discuss] " Simon Kelley @ 2014-04-25 19:24 ` Török Edwin 2014-04-25 19:42 ` Dave Taht 2 siblings, 1 reply; 15+ messages in thread From: Török Edwin @ 2014-04-25 19:24 UTC (permalink / raw) To: cerowrt-devel On 04/25/2014 09:01 PM, Jim Gettys wrote: > More specifically, after boot, most of the time test-ipv6.com <http://test-ipv6.com> reports lots of problems. > > Then I turned off both dnssec and dnssec-check-unsigned, and restarted dnsmasq; clean bill of health from test-ipv6.com <http://test-ipv6.com>. > > > So we seem to have a boot time race of some sort. There is definitely something wrong when ipv6 is enabled (I just noticed that since my latest upgrade I forgot to enable it). When I enable ipv6 for PPPoE, then IPv6 works in the sense I can ping6 stuff from the router ... except IPv4 is completely broken: there is no default route added according to 'ip route show', and even if I add a default route machines from LAN still can't reach IPv4 (presumably firewall would need to be reloaded too?). It doesn't seem to be dnssec related, as even if I turn both dnssec and dnssec-check-unsigned off the behaviour is still the same. I haven't investigated more deeply whats wrong yet. Do you think it could be related to your race condition? > Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a clean bill of health. I've been using this for a while, it gets me a 0/10 score, i.e. ipv4 works, ipv6 fails, dual stack works with ipv4. > > Then I turned on both at the same time, and things are working. With both on I get a 'n/a' as a result, saying that dual-stack lookups timed out, presumably because ipv6 is off see below. Best regards, --Edwin ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] test-ipv6.com vs dnssec 2014-04-25 19:24 ` [Cerowrt-devel] " Török Edwin @ 2014-04-25 19:42 ` Dave Taht 2014-04-26 19:41 ` Sebastian Moeller 0 siblings, 1 reply; 15+ messages in thread From: Dave Taht @ 2014-04-25 19:42 UTC (permalink / raw) To: Török Edwin; +Cc: cerowrt-devel We used to arbitrarily restart dnsmasq after boot with a script. Perhaps doing a /etc/init.d/dnsmasq reload 60 sec after boo will show something. But I am puzzled as to not getting an ipv4 route. This hints at an issue on the ubus. I am trying to take a bit of vacation for the next week or so, it was my hope everything was actually working... ... and even if it isn't, I need a break. Good Luck on this y'all, I'll be back after a tan. On Fri, Apr 25, 2014 at 12:24 PM, Török Edwin <edwin+ml-cerowrt@etorok.net> wrote: > On 04/25/2014 09:01 PM, Jim Gettys wrote: >> More specifically, after boot, most of the time test-ipv6.com <http://test-ipv6.com> reports lots of problems. >> >> Then I turned off both dnssec and dnssec-check-unsigned, and restarted dnsmasq; clean bill of health from test-ipv6.com <http://test-ipv6.com>. >> >> >> So we seem to have a boot time race of some sort. > > There is definitely something wrong when ipv6 is enabled (I just noticed that since my latest upgrade I forgot to enable it). > When I enable ipv6 for PPPoE, then IPv6 works in the sense I can ping6 stuff from the router ... except IPv4 is completely broken: there is no default route added according to 'ip route show', > and even if I add a default route machines from LAN still can't reach IPv4 (presumably firewall would need to be reloaded too?). > It doesn't seem to be dnssec related, as even if I turn both dnssec and dnssec-check-unsigned off the behaviour is still the same. > I haven't investigated more deeply whats wrong yet. Do you think it could be related to your race condition? > >> Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a clean bill of health. > > I've been using this for a while, it gets me a 0/10 score, i.e. ipv4 works, ipv6 fails, dual stack works with ipv4. > >> >> Then I turned on both at the same time, and things are working. > > With both on I get a 'n/a' as a result, saying that dual-stack lookups timed out, presumably because ipv6 is off see below. > > > > Best regards, > --Edwin > _______________________________________________ > 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] 15+ messages in thread
* Re: [Cerowrt-devel] test-ipv6.com vs dnssec 2014-04-25 19:42 ` Dave Taht @ 2014-04-26 19:41 ` Sebastian Moeller 2014-04-27 16:15 ` Dave Taht 0 siblings, 1 reply; 15+ messages in thread From: Sebastian Moeller @ 2014-04-26 19:41 UTC (permalink / raw) To: Dave Taht; +Cc: cerowrt-devel Hi List, hi Dave, so I had to restart cerowrt 3.10.36-6 today after coming home from a 5 day trip. I had some issues connecting with a macbook and one of 2 nexus 4s. after a reboot of the router both MacBooks connected fine on the 5GHz radio but none of the nexi connected to either the 2.4GHz nor the 5GHz radio, instead they produced endless repetitions of: Sat Apr 26 21:27:15 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: disassociated Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: authenticated Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: associated (aid 1) Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 WPA: pairwise key handshake completed (RSN) Sat Apr 26 21:27:30 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 Sat Apr 26 21:27:33 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 Sat Apr 26 21:27:35 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 Sat Apr 26 21:27:39 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 Sat Apr 26 21:27:47 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 Following Dave's recommendation of issuing a "/etc/init.d/dnsmasq reload" allowed both phones to connect again, so we might still have a race hidden somewhere… (This is on a system without working ipv6 currently). 3.10.36-6 looks like it needs a bit more maturation time ;) It would be interesting to learn whether the same approach might help other people as well... Best Regards Sebastian On Apr 25, 2014, at 21:42 , Dave Taht <dave.taht@gmail.com> wrote: > We used to arbitrarily restart dnsmasq after boot with a script. > Perhaps doing a /etc/init.d/dnsmasq reload 60 sec after boo will show > something. > > But I am puzzled as to not getting an ipv4 route. This hints at an > issue on the ubus. > > I am trying to take a bit of vacation for the next week or so, it was > my hope everything was actually working... > > ... and even if it isn't, I need a break. Good Luck on this y'all, > I'll be back after a tan. > > > On Fri, Apr 25, 2014 at 12:24 PM, Török Edwin > <edwin+ml-cerowrt@etorok.net> wrote: >> On 04/25/2014 09:01 PM, Jim Gettys wrote: >>> More specifically, after boot, most of the time test-ipv6.com <http://test-ipv6.com> reports lots of problems. >>> >>> Then I turned off both dnssec and dnssec-check-unsigned, and restarted dnsmasq; clean bill of health from test-ipv6.com <http://test-ipv6.com>. >>> >>> >>> So we seem to have a boot time race of some sort. >> >> There is definitely something wrong when ipv6 is enabled (I just noticed that since my latest upgrade I forgot to enable it). >> When I enable ipv6 for PPPoE, then IPv6 works in the sense I can ping6 stuff from the router ... except IPv4 is completely broken: there is no default route added according to 'ip route show', >> and even if I add a default route machines from LAN still can't reach IPv4 (presumably firewall would need to be reloaded too?). >> It doesn't seem to be dnssec related, as even if I turn both dnssec and dnssec-check-unsigned off the behaviour is still the same. >> I haven't investigated more deeply whats wrong yet. Do you think it could be related to your race condition? >> >>> Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a clean bill of health. >> >> I've been using this for a while, it gets me a 0/10 score, i.e. ipv4 works, ipv6 fails, dual stack works with ipv4. >> >>> >>> Then I turned on both at the same time, and things are working. >> >> With both on I get a 'n/a' as a result, saying that dual-stack lookups timed out, presumably because ipv6 is off see below. >> >> >> >> Best regards, >> --Edwin >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > -- > Dave Täht > > NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] test-ipv6.com vs dnssec 2014-04-26 19:41 ` Sebastian Moeller @ 2014-04-27 16:15 ` Dave Taht 2014-04-27 19:49 ` Sebastian Moeller 0 siblings, 1 reply; 15+ messages in thread From: Dave Taht @ 2014-04-27 16:15 UTC (permalink / raw) To: Sebastian Moeller; +Cc: cerowrt-devel On Sat, Apr 26, 2014 at 12:41 PM, Sebastian Moeller <moeller0@gmx.de> wrote: > Hi List, hi Dave, > > so I had to restart cerowrt 3.10.36-6 today after coming home from a 5 day trip. I had some issues connecting with a macbook and one of 2 nexus 4s. after a reboot of the router both MacBooks connected fine on the 5GHz radio but none of the nexi connected to either the 2.4GHz nor the 5GHz radio, instead they produced endless repetitions of: > Sat Apr 26 21:27:15 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 > Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: disassociated > Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: authenticated > Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: associated (aid 1) > Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 WPA: pairwise key handshake completed (RSN) > Sat Apr 26 21:27:30 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 > Sat Apr 26 21:27:33 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 > Sat Apr 26 21:27:35 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 > Sat Apr 26 21:27:39 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 > Sat Apr 26 21:27:47 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 Well, somehow dnsmasq ran out of leases, or was unable to derive an ip address range from the interface's ifconfig. There are only a very few leases by default (28), and they time out after a few hours, so a bunch of drive-by dhcp requests could have run you out, but I'd suspect a bug unless you have/had a large number of leases in /tmp/dhcp.leases. I have been fiddling with things, and (for example) changing wifi parameters and doing a reload sometimes loses the ip address on one or more wifi interfaces. (you get a different error from dnsmasq in that case) So I figure we have multiple race conditions right now causing problems, in addition to some long term bugs in wifi handling. Tighter integration of dnsmasq with the ubus system would be good. A better grip on how to exercise and debug ubus events would be good too. Of possible relevance, this just landed in openwrt head: https://dev.openwrt.org/changeset/40573 There are also some routing bugs fixed in 3.10.37 I have been running without setting a multicast_rate now for half a day on 3.10.36-7 > > Following Dave's recommendation of issuing a "/etc/init.d/dnsmasq reload" allowed both phones to connect again, so we might still have a race hidden somewhere… (This is on a system without working ipv6 currently). 3.10.36-6 looks like it needs a bit more maturation time ;) It would be interesting to learn whether the same approach might help other people as well... > > Best Regards > Sebastian > > > > On Apr 25, 2014, at 21:42 , Dave Taht <dave.taht@gmail.com> wrote: > >> We used to arbitrarily restart dnsmasq after boot with a script. >> Perhaps doing a /etc/init.d/dnsmasq reload 60 sec after boo will show >> something. >> >> But I am puzzled as to not getting an ipv4 route. This hints at an >> issue on the ubus. >> >> I am trying to take a bit of vacation for the next week or so, it was >> my hope everything was actually working... >> >> ... and even if it isn't, I need a break. Good Luck on this y'all, >> I'll be back after a tan. >> >> >> On Fri, Apr 25, 2014 at 12:24 PM, Török Edwin >> <edwin+ml-cerowrt@etorok.net> wrote: >>> On 04/25/2014 09:01 PM, Jim Gettys wrote: >>>> More specifically, after boot, most of the time test-ipv6.com <http://test-ipv6.com> reports lots of problems. >>>> >>>> Then I turned off both dnssec and dnssec-check-unsigned, and restarted dnsmasq; clean bill of health from test-ipv6.com <http://test-ipv6.com>. >>>> >>>> >>>> So we seem to have a boot time race of some sort. >>> >>> There is definitely something wrong when ipv6 is enabled (I just noticed that since my latest upgrade I forgot to enable it). >>> When I enable ipv6 for PPPoE, then IPv6 works in the sense I can ping6 stuff from the router ... except IPv4 is completely broken: there is no default route added according to 'ip route show', >>> and even if I add a default route machines from LAN still can't reach IPv4 (presumably firewall would need to be reloaded too?). >>> It doesn't seem to be dnssec related, as even if I turn both dnssec and dnssec-check-unsigned off the behaviour is still the same. >>> I haven't investigated more deeply whats wrong yet. Do you think it could be related to your race condition? >>> >>>> Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a clean bill of health. >>> >>> I've been using this for a while, it gets me a 0/10 score, i.e. ipv4 works, ipv6 fails, dual stack works with ipv4. >>> >>>> >>>> Then I turned on both at the same time, and things are working. >>> >>> With both on I get a 'n/a' as a result, saying that dual-stack lookups timed out, presumably because ipv6 is off see below. >>> >>> >>> >>> Best regards, >>> --Edwin >>> _______________________________________________ >>> Cerowrt-devel mailing list >>> Cerowrt-devel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> >> >> -- >> Dave Täht >> >> NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] test-ipv6.com vs dnssec 2014-04-27 16:15 ` Dave Taht @ 2014-04-27 19:49 ` Sebastian Moeller 0 siblings, 0 replies; 15+ messages in thread From: Sebastian Moeller @ 2014-04-27 19:49 UTC (permalink / raw) To: Dave Taht; +Cc: cerowrt-devel Hi Dave, thanks for the information. On Apr 27, 2014, at 18:15 , Dave Taht <dave.taht@gmail.com> wrote: > On Sat, Apr 26, 2014 at 12:41 PM, Sebastian Moeller <moeller0@gmx.de> wrote: >> Hi List, hi Dave, >> >> so I had to restart cerowrt 3.10.36-6 today after coming home from a 5 day trip. I had some issues connecting with a macbook and one of 2 nexus 4s. after a reboot of the router both MacBooks connected fine on the 5GHz radio but none of the nexi connected to either the 2.4GHz nor the 5GHz radio, instead they produced endless repetitions of: >> Sat Apr 26 21:27:15 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 >> Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: disassociated >> Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: authenticated >> Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: associated (aid 1) >> Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 WPA: pairwise key handshake completed (RSN) >> Sat Apr 26 21:27:30 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 >> Sat Apr 26 21:27:33 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 >> Sat Apr 26 21:27:35 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 >> Sat Apr 26 21:27:39 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 >> Sat Apr 26 21:27:47 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00 > > Well, somehow dnsmasq ran out of leases, or was unable to derive an > ip address range from the interface's > ifconfig. There are only a very few leases by default (28), and they > time out after a few hours, so a bunch of drive-by > dhcp requests could have run you out, but I'd suspect a bug unless > you have/had a large number of leases in > /tmp/dhcp.leases. Alas, I rebooted before checking that file (I should have saved the borked state somewhere, but was too eager to get internet access working again ;) ) I will monitor tis more closely on 3.10.38-1. Best Regards Sebastian > > I have been fiddling with things, and (for example) changing wifi > parameters and doing a reload sometimes > loses the ip address on one or more wifi interfaces. (you get a > different error from dnsmasq in that case) > > So I figure we have multiple race conditions right now causing > problems, in addition to some long term > bugs in wifi handling. Tighter integration of dnsmasq with the ubus > system would be good. A better grip > on how to exercise and debug ubus events would be good too. > > Of possible relevance, this just landed in openwrt head: > > https://dev.openwrt.org/changeset/40573 > > There are also some routing bugs fixed in 3.10.37 > > I have been running without setting a multicast_rate now for half a > day on 3.10.36-7 > > >> >> Following Dave's recommendation of issuing a "/etc/init.d/dnsmasq reload" allowed both phones to connect again, so we might still have a race hidden somewhere… (This is on a system without working ipv6 currently). 3.10.36-6 looks like it needs a bit more maturation time ;) It would be interesting to learn whether the same approach might help other people as well... >> >> Best Regards >> Sebastian >> >> >> >> On Apr 25, 2014, at 21:42 , Dave Taht <dave.taht@gmail.com> wrote: >> >>> We used to arbitrarily restart dnsmasq after boot with a script. >>> Perhaps doing a /etc/init.d/dnsmasq reload 60 sec after boo will show >>> something. >>> >>> But I am puzzled as to not getting an ipv4 route. This hints at an >>> issue on the ubus. >>> >>> I am trying to take a bit of vacation for the next week or so, it was >>> my hope everything was actually working... >>> >>> ... and even if it isn't, I need a break. Good Luck on this y'all, >>> I'll be back after a tan. >>> >>> >>> On Fri, Apr 25, 2014 at 12:24 PM, Török Edwin >>> <edwin+ml-cerowrt@etorok.net> wrote: >>>> On 04/25/2014 09:01 PM, Jim Gettys wrote: >>>>> More specifically, after boot, most of the time test-ipv6.com <http://test-ipv6.com> reports lots of problems. >>>>> >>>>> Then I turned off both dnssec and dnssec-check-unsigned, and restarted dnsmasq; clean bill of health from test-ipv6.com <http://test-ipv6.com>. >>>>> >>>>> >>>>> So we seem to have a boot time race of some sort. >>>> >>>> There is definitely something wrong when ipv6 is enabled (I just noticed that since my latest upgrade I forgot to enable it). >>>> When I enable ipv6 for PPPoE, then IPv6 works in the sense I can ping6 stuff from the router ... except IPv4 is completely broken: there is no default route added according to 'ip route show', >>>> and even if I add a default route machines from LAN still can't reach IPv4 (presumably firewall would need to be reloaded too?). >>>> It doesn't seem to be dnssec related, as even if I turn both dnssec and dnssec-check-unsigned off the behaviour is still the same. >>>> I haven't investigated more deeply whats wrong yet. Do you think it could be related to your race condition? >>>> >>>>> Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a clean bill of health. >>>> >>>> I've been using this for a while, it gets me a 0/10 score, i.e. ipv4 works, ipv6 fails, dual stack works with ipv4. >>>> >>>>> >>>>> Then I turned on both at the same time, and things are working. >>>> >>>> With both on I get a 'n/a' as a result, saying that dual-stack lookups timed out, presumably because ipv6 is off see below. >>>> >>>> >>>> >>>> Best regards, >>>> --Edwin >>>> _______________________________________________ >>>> Cerowrt-devel mailing list >>>> Cerowrt-devel@lists.bufferbloat.net >>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>> >>> >>> >>> -- >>> Dave Täht >>> >>> NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article >>> _______________________________________________ >>> Cerowrt-devel mailing list >>> Cerowrt-devel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > > > > -- > Dave Täht > > NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-04-30 21:47 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-25 17:39 [Cerowrt-devel] test-ipv6.com vs dnssec Dave Taht 2014-04-25 18:01 ` Jim Gettys 2014-04-25 18:45 ` James Cloos 2014-04-25 18:49 ` [Cerowrt-devel] [Dnsmasq-discuss] " Simon Kelley 2014-04-25 19:43 ` Török Edwin 2014-04-25 19:48 ` Török Edwin 2014-04-28 19:07 ` Dave Taht 2014-04-28 19:57 ` James Cloos 2014-04-28 20:17 ` Török Edwin 2014-04-30 21:44 ` James Cloos 2014-04-25 19:24 ` [Cerowrt-devel] " Török Edwin 2014-04-25 19:42 ` Dave Taht 2014-04-26 19:41 ` Sebastian Moeller 2014-04-27 16:15 ` Dave Taht 2014-04-27 19:49 ` Sebastian Moeller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox