Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
On 26/09/18 17:33, Simon Kelley wrote: > On 24/09/18 11:45, gravit...@gmx.com wrote: >> >> Amof, the first and only frames my dongle sends on eth at start, are >> some Dhcp DISCOVER, no arps at all. >> Please note that such Dhcp DISCOVER frames come with the broadcast bit >> NOT set. >> Afaik, that meas my dongle is indeed asking the Dhcp server to send a >> unicast response, directly to its mac. >> Instead QNSMASQ sends those Dhcp OFFER frames to broadcast. >> Why it happens so? >> > > I can offer two reasons why it might be so. The first is that there's a > bug in dnsmasq, which is not unheard-of, but this is old code and a bug > has not been observed before. The second is that you're running dnsmasq > configured to always send broadcasts, using the --dhcp-broadcast option. > > Check all the dnsmasq configuration files, that's the sort of thing that > gets slipped in because is solves someone's problem one time, and "it > can't do any harm". > > Looking at the code, it also falls back to broadcast if the "hardware address length field is zero or greater than 16, or if the "hardware address type" field is zero. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq stops receiving packets after network restart
On 24/09/18 19:12, Kristian Evensen wrote: > Hello, > > I have some routers running OpenWRT (latest nightly) and that I have > to access remotely (using reverse SSH). When I restart networking > (/etc/init.d/network restart), clients on the LAN can no longer obtain > an IP address using DHCP. If I restart networking locally, DHCP works > as expected after the network is back up. > > In order to try and figure out what is going on, I have checked/tried > the following: > > * I started out by checking if dnsmasq has been restarted and if the > DHCP socket has been created. I can always see the socket in netstat. > * I then took a look at the firewall. I can see the DHCP packets in > the INPUT chain in filter, which according to my understanding of > Netfilter-internals is the last stop before a packet is delivered to a > socket. > * I then instrumented dnsmasq and added some logging in dhcp_packet() > in dhcp.c. This function is never called, as none of my log-messages > are written to syslog. I checked that the logging works by checking > for my messages when DHCP is working. > * Restarting dnsmasq makes DHCP work again. I can't see any difference > in for example netstat-output. > > Does anyone have any idea on what to try or where to look next? After > having spent a couple of days on this issue, I am quickly starting to > run out of ideas. > I wonder if this is caused by dnsmasq using the BINDTODEVICE sockopt on the DHCP socket. If the networking restart takes down and re-creates the network interface, then that socket may be remain bound to the old interface. This comment in whichdevice() in dhcp-common.c decribes the condition under which the binding happens. /* If we are doing DHCP on exactly one interface, and running linux, do SO_BINDTODEVICE to that device. This is for the use case of (eg) OpenStack, which runs a new dnsmasq instance for each VLAN interface it creates. Without the BINDTODEVICE, individual processes don't always see the packets they should. SO_BINDTODEVICE is only available Linux. Note that if wildcards are used in --interface, or --interface is not used at all, or a configured interface doesn't yet exist, then more interfaces may arrive later, so we can't safely assert there is only one interface and proceed. */ Simplest test is to make whichdevice always return NULL, and see if that helps. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
On 24/09/18 11:45, gravit...@gmx.com wrote: > > Amof, the first and only frames my dongle sends on eth at start, are > some Dhcp DISCOVER, no arps at all. > Please note that such Dhcp DISCOVER frames come with the broadcast bit > NOT set. > Afaik, that meas my dongle is indeed asking the Dhcp server to send a > unicast response, directly to its mac. > Instead QNSMASQ sends those Dhcp OFFER frames to broadcast. > Why it happens so? > I can offer two reasons why it might be so. The first is that there's a bug in dnsmasq, which is not unheard-of, but this is old code and a bug has not been observed before. The second is that you're running dnsmasq configured to always send broadcasts, using the --dhcp-broadcast option. Check all the dnsmasq configuration files, that's the sort of thing that gets slipped in because is solves someone's problem one time, and "it can't do any harm". Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] TCP DNSSEC request over IPv6 abandoned in v2.79
On 25/09/18 22:15, Chris Staite wrote: > Hi, > > I've recently upgraded my router to an alpha firmware that uses DNSmasq > v2.79. I'm having issues with it performing DNSSEC validation that I didn't > have with the old version of DNSmasq (which I'm not entirely sure which > version it was). > > I've managed to pin down the exact conditions that cause the error. When I > perform DNSSEC validation over IPv6 for a long domain it causes DNSmasq to > return SRVFAIL. Specifically, I get the log message "validation > 192-168-0-123.0d0f0601f95b420c82cb9dcac0f0a2d5.plex.direct is ABANDONED". > > The full trail of the log is: > > Sep 25 20:40:42 dnsmasq[24782]: query[A] > 192-168-0-123.0d0f0601f95b420c82cb9dcac0f0a2d5.plex.direct from 192.168.1.107 > Sep 25 20:40:42 dnsmasq[24782]: forwarded > 192-168-0-123.0d0f0601f95b420c82cb9dcac0f0a2d5.plex.direct to > 2606:4700:4700:: > Sep 25 20:40:42 dnsmasq[24782]: dnssec-query[DS] direct to > 2606:4700:4700:: > Sep 25 20:40:42 dnsmasq[24782]: dnssec-query[DNSKEY] . to 2606:4700:4700:: > Sep 25 20:40:42 dnsmasq[24782]: reply . is DNSKEY keytag 20326, algo 8 > Sep 25 20:40:42 dnsmasq[24782]: reply . is DNSKEY keytag 2134, algo 8 > Sep 25 20:40:42 dnsmasq[24782]: reply . is DNSKEY keytag 41656, algo 8 > Sep 25 20:40:42 dnsmasq[24782]: reply . is DNSKEY keytag 19036, algo 8 > Sep 25 20:40:42 dnsmasq[24782]: reply direct is DS keytag 20629, algo 8, > digest 1 > Sep 25 20:40:42 dnsmasq[24782]: reply direct is DS keytag 20629, algo 8, > digest 2 > Sep 25 20:40:42 dnsmasq[24782]: dnssec-query[DS] plex.direct to > 2606:4700:4700:: > Sep 25 20:40:42 dnsmasq[24782]: validation > 192-168-0-123.0d0f0601f95b420c82cb9dcac0f0a2d5.plex.direct is ABANDONED > > If the request is performed over UDP it is successful, but the length forces > it to fall back to TCP which has this issue. The only difference between the > queries that I can see from the packet captures is that the Transaction ID is > 0 for all of the follow-up queries over TCP. Looking through the source it > seems the processing for TCP is completely separate to UDP, so there may be a > logic error between them? > > I'm happy to provide any more packet captures or information as required. I > currently don't have a cross-compiling environment set up to build changes > for the router binary, but if that would be helpful I could probably make one. > You say "When I perform DNSSEC validation over IPv6" which implies, but doesn't state, that the same test works when talking to usptream DNS servers over IPv4? Is that the case? Certainly, a quick test here works over IPv4. I'm wondering if I need to resurrect my severely bit-rotted IPv6 tunnel setup? Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
