From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 55F0021F207 for ; Thu, 10 Oct 2013 11:53:14 -0700 (PDT) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:41369 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VULMF-0004uE-9T; Thu, 10 Oct 2013 19:53:11 +0100 Received: from archie.thekelleys.org.uk ([192.168.1.167]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1VULMC-0005Zm-O6; Thu, 10 Oct 2013 19:53:08 +0100 Message-ID: <5256F796.6040402@thekelleys.org.uk> Date: Thu, 10 Oct 2013 19:53:10 +0100 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Dave Taht References: <9A9AF30E-7F5A-41DF-AE94-0C92AD7BBED9@imap.cc> <5256DBB1.50707@thekelleys.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsmasq-discuss@lists.thekelleys.org.uk, "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] [Dnsmasq-discuss] Names not resolved on Wireless X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 18:53:14 -0000 I'm not sure that's the problem, but it's worth a try. Another thing to do is add a a line to log if bindtodevice() in src/dhcp-common.c actually sets the SO_BINDTODEVICE sockopt. It's not supposed to even is there's currently exactly one interface, if there's a possibility that more will appear. This could be relevant in this case, but I'm not sure where the regression could come from. Hmm, are you using --listen-address or --interface to configure dnsmasq to server particular interfaces? Or maybe --except-interface? Now there's a thought..... Simon. On 10/10/13 19:30, Dave Taht wrote: > On Thu, Oct 10, 2013 at 9:54 AM, Simon Kelley wrote: >> >> Does reverting >> >> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=397542b213ab4071734f1cdf4cc914d87100456f >> >> fix the issue? I fear it might. > > Seems likely. > > I reverted that patch and put it in this build > > http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.15-3/ > > I won't be in a position to test stuff myself til sunday but cero's > devoted userbase seems to be hoovering over the reload button and will > probably beat me to it.... > > >> >> Cheers, >> >> Simon. >> >> >> >> On 10/10/13 15:43, Dave Taht wrote: >>> >>> Dear Dr. Dnsmasq: >>> >>> When cerowrt made the jump between dnsmasq-2.67-test10 and >>> dnsmasq-2.67-test17, detection of interfaces other than the first >>> started failing. It seems to be related to interfaces that come up >>> after dnsmasq starts, as restarting it after the device is fully >>> booted works. Have moved forward to 2.67-rc3 to no avail. >>> >>> (along the way we migrated from kernel 3.10.11 to 3.10.13 to 3.10.15 >>> but I doubt that's the issue) >>> >>> Hot, fresh, firmware can be had at: >>> >>> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/ >>> >>> >>> [10:39:25] has anyone had IPv4 DHCP problems in the last two >>> 3.10.x >>> builds? currently running 3.10.11-3 and it works flawlessly. >>> upgraded to 3.10.13-2 and 3.10.15-1 and both present me with an >>> identical issue. upon reboot after upgrading, DHCP leases are no >>> longer handed out on the wireless interfaces. disabling and >>> re-enabling DHCP on the wireless interfaces will fix the problem, but >>> the problem >>> [10:39:26] returns after a reboot. disable/reenable DHCP on the >>> interface will again temporarily fix it. >>> [10:42:03] also tried a fresh install (using reset to defaults >>> option) to avoid anything not properly interpreted from the config of >>> the previous version, but still get the same issue. >>> >>> >>> On Thu, Oct 10, 2013 at 5:30 AM, David Personette >>> wrote: >>>> >>>> Just tested again with 3.10.15-2. My OSX (10.8.5) laptop worked, neither >>>> my >>>> Nexus 7 (2013 w/CM10.2) or my Fedora 19 laptop could resolve DNS over >>>> wireless. My wired Linux server (Ubuntu 12.04.3) was working fine as >>>> well. >>>> Reverted to 3.10.11-3 once more. >>>> >>>> -- >>>> David P. >>>> >>>> >>>> On Mon, Oct 7, 2013 at 7:40 PM, David Personette >>>> wrote: >>>>> >>>>> >>>>> I can confirm it as well. I wiped my config back to defaults, and it >>>>> wasn't fixed. Reinstalled the 3.10.11-3 build, and restored my configs >>>>> and >>>>> all is well. >>>>> >>>>> -- >>>>> David P. >>>>> >>>>> >>>>> On Mon, Oct 7, 2013 at 7:07 PM, Fred Stratton >>>>> wrote: >>>>>> >>>>>> >>>>>> True for the last two builds. Wired works as expected. >>>>>> >>>>>> Is this a problem with the development version of DNSMasq? What is the >>>>>> recommended workaround? >>>>>> >>>>>> _______________________________________________ >>>>>> Cerowrt-devel mailing list >>>>>> Cerowrt-devel@lists.bufferbloat.net >>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > >