Re: [Dnsmasq-discuss] Confusion about "no address range available for DHCPv6 request via ..."
On Wed, Apr 19, 2023 at 1:02 PM Daniel Farina wrote: > > I thought about using the constructor feature, but I was trying to figure > out if there was some way to get dnsmasq to respond to the DHCP query > without occupying space in the /64... > Editorial error: I meant the /80. the only /64 involved is on the virtual machine host.It should read: I thought about using the constructor feature, but I was trying to figure out if there was some way to get dnsmasq to respond to the DHCP query without occupying space in the /80 I'd like the VM to use (e.g. by listening and responding to DHCP via link local addresses. In such a case the address range would have to be telegraphed rather than read from the interface. As seen in my example, one address suffices for the one VM that is free to bind anything in the /80. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Confusion about "no address range available for DHCPv6 request via ..."
On Wed, Apr 19, 2023 at 12:55 PM Petr Menšík wrote: > Are you aware that 80 on the end of dhcp-range is lease time, not any > prefix size? Consider using of constructor:tapvm4qyj3a instead of manual > end address. If I see correctly the end address is the same as the start > address. Not sure how this should behave, but I would not be surprised > if it did not work. > Hmm, my read of the manual page suggests it should be the prefix length? -F, --dhcp-range=[tag:[,tag:],][set:,][,|constructor:][,][,][,] As far as I can tell, it worked as expected, though I was experimenting with a few things so I am not sure at this time. I thought about using the constructor feature, but I was trying to figure out if there was some way to get dnsmasq to respond to the DHCP query without occupying space in the /64 I'd like the VM to use (e.g. by listening and responding to DHCP via link local addresses. In such a case the address range would have to be telegraphed rather than read from the interface. As seen in my example, one address suffices for the one VM that is free to bind anything in the /80. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] proxy-dnssec, how does it work (with unbound as upstream)
On 17. 04. 23 15:57, Simon Kelley wrote: On 17/04/2023 01:10, Petr Menšík wrote: I do not understand why should be proxy-dnssec caching unreliable. It should be as simple as storing AD bit from the reply in cache entry. I expect just extra bit is something we can afford. I explained this somewhere up-thread. The problem is that there's one AD per reply, but possibly more than one RR per reply. The AD bit is only set if ALL the RRs are validated. The canonical example is a reply which is a CNAME to an A or where the CNAME is DNSSEC protected but the A or is not. The AD bit will be clear, leading to the CNAME getting cached without its validated status. See www.comcast.com for a real world example. I thought dnsmasq does not do anything special with cnames. Just caches it for the name, which reply contained it. I thought it does not insert separate CNAME entries into the cache. But haven't looked how the cache looks like. Anyway, if any part of the name chain is not signed, I think it is okay to mark also signed parts without AD bit. For majority of uses it won't make a difference. Network Manager should stop passing dnssec-proxy in case it is configured via DBus however. I think this is not what people really want and definitely not when remote resolvers addresses are provided and not really protected. Far better would be ability to configure DNSSEC validation per connection. I hope I will find time to prepare a change allowing to do that soon. Would need just DBus interface to turn validation on and off. Trust anchor can stay present always. Are you talking about upstream connections? If so, there's something like that in position already. Something like server=/example.com/1.2.3.4 will suppress DNSSEC validation when forwarding *.example.com to 1.2.3.4 UNLESS there's a trust anchor configured for example.com. That covers the most obvious case, and I can't think of others that need more explicit control. DO you have any? No, what I had on mind were connections of Network Manager. Those listed by "nmcli c" command. While majority of network resolvers works just fine with DNSSEC validation, it may cause issues on some. Network Manager reconfigures dnsmasq via DBus call setting servers. It would be nice if it could also disable validation on servers from known connection, where resolvers do not forward EDNS with DO=1 bit back to client. Because dnssec validation can be enabled only always or never, it cannot adjust automatically if I move with my laptop to another wi-fi network. Or there would have to be something to stop dnsmasq, (re)create configuration snippet and restart it. It would be better if global dnssec validation status could be toggled runtime. Even better if just servers provided by NM from affected connection, lets say wifi SSID of train network, could be marked non-validating. Ie. not per domain, but per server. Not sure it it is possible to use server=/./1.2.3.4 to disable DNSSEC on that server. I expect because trust anchor would be defined for root, it would do validation for it. For example unbound-control has optional +i flag for forwarding zone, which means for these servers ignore validation. It is sort of per-domain usually, but can be done also for root zone forwarder. Cheers, Simon. On 4/13/23 23:15, Simon Kelley wrote: I'm not clear where the EDE in a reply fits in to this. I agree, it seems to be all about AD bit in reality. --proxy-dnssec does only one thing: it stops dnsmasq from zeroing the authenticated data (AD) bit in replies before returning them to clients. This means that clients can rely on the AD bit to tell if the answer is secure, with a couple of caveats. 1) The path between dnsmasq and it's upstream servers is trusted. There's nothing to stop an attacker spoofing answers with the AD bit set since there's no cryptographic validation being done by dnsmasq. 2) Dnsmasq caching must be off. The AD bit is NOT cached, so replies from the dnsmasq cache will always have the AD bit set to zero. Only replies coming direct from upstream queries potentially have the AD bit set. This is why the man page tells you to set the cache size to zero. This seems somehow easy to fix. Just save AD bit when proxy-dnssec is enabled. Or save it always, but after AD bit is reset when not using proxy-dnssec. The reason why caching the AD bit isn't done is that it doesn't work because the AD bit refers to ALL the answers in to answer section: it's set only if they are all validated. If only some of the answers are validated, AD will be zero, and when a validated answer is cached, the validation status will be wrong. It seems to be just small corner case, which does not matter usually. If we do not mark the response with AD bit which still was, it is not a big deal. A problem it would be if we marked response which had not it in the original answer. A real world example is www.com
Re: [Dnsmasq-discuss] Confusion about "no address range available for DHCPv6 request via ..."
Are you aware that 80 on the end of dhcp-range is lease time, not any prefix size? Consider using of constructor:tapvm4qyj3a instead of manual end address. If I see correctly the end address is the same as the start address. Not sure how this should behave, but I would not be surprised if it did not work. Try this: dhcp-range=2a01:4f9:2b:35a:7df2::2,constructor:tapvm4qyj3a,80 On 18. 04. 23 10:40, Daniel Farina wrote: Hello everyone, I have been trying to set up an IPv6-only network for a virtual machine with route advertisements and DHCP configuration. I've had some success, but I have a question. I have a dnsmasq.conf that looks like this, to delegate a /80 chunk of a /64 network to a virtual machine: interface=tapvm4qyj3a enable-ra dhcp-authoritative leasefile-ro ra-param=tapvm4qyj3a,mtu:1280,high,60,1200 dhcp-range=2a01:4f9:2b:35a:7df2::2,2a01:4f9:2b:35a:7df2::2,80 If I have an address configuration like this on the host outside the virtual machine, it works well: 3: tapvm4qyj3a: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 82:d6:93:69:72:82 brd ff:ff:ff:ff:ff:ff inet6 2a01:4f9:2b:35a:7df2::1/80 scope global valid_lft forever preferred_lft forever inet6 fe80::80d6:93ff:fe69:7282/64 scope link valid_lft forever preferred_lft forever The thing I find dissatisfying about this is that the VM is not able to listen on 2a01:4f9:2b:35a:7df2::1 anymore once I've done this, is my understanding: the host will process the traffic, right? If I remove the address on the guest's network, dnsmasq warns me repeatedly, and does not work: ip addr del 2a01:4f9:2b:35a:7df2::1/80 dev tapvm4qyj3a dnsmasq-dhcp: no address range available for DHCPv6 request via tapvm4qyj3a dnsmasq-dhcp: no address range available for DHCPv6 request via tapvm4qyj3a dnsmasq-dhcp: no address range available for DHCPv6 request via tapvm4qyj3a ... My question is partially that of norms: is it normal to squat on a bit of the guest's address space like this? Is there a preferred way that avoids this, or does something different still? I know that a number of non-SLAAC configurations tend to sit on ::2 as the first unicast address, is this related to the reason why? I will be expanding my use of dnsmasq to DNS, so this may figure in the answer. Thank you for considering my question. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Behavior on DHCP denied
On Wed, Apr 19, 2023 at 04:32:46PM +0300, 0zl wrote: > On 4/19/23 13:35, 0zl wrote: > > On 4/19/23 11:38, Buck Horn wrote: > > > Wed, Apr 19, 2023, 0zl wrote: > > > >. > > > > Note that the capture includes a ARP probe from the ESP and no > > > > response, just keep in mind that the WiFi router does in fact > > > > respond to it, it just doesn't do so over that bridge port so it > > > > didn't get captured on the gateway's end. > > > > > > I think your issue starts earlier: > > > Your pcap indicates a failing lease renewal. > > > > > > Lines 12 to 18 show your ESP is attempting to renew its DHCP lease > > > through 10.46.109.1 after ~62 seconds as expected (about half the > > > 120secs leasetime) - but those requests seem to never have received > > > a reply. > > > > > > In absence of a reply from the known DHCP server, lines 19 to 27 > > > then show your ESP to send renewal requests to the broadcast > > > address. > > > > > > As those are not answered either, your ESP finally releases its > > > expired lease (line 28). > > > > > > It then initiates DHCP negotiation for a completely new lease, by > > > broadcasting for DHCP servers, and it's only then that ARP probing > > > would prompt it to DHCPDECLINE. > > > > > > But I'd have expected dnsmasq to have extended your ESP's existing > > > lease straight for the first DHCPREQUEST for renewal (line 12). > > > > > > This would suggest that dnsmasq has not received or ignored both > > > those DHCPREQUESTs for renewal as well as the DHCPRELEASE, which > > > could explain both the failed renewal as well as the offending > > > DHCPDECLINEs. > > > > > > Are you splitting your network, e.g. into several VLANs? > > > > > > It would be interesting to see what dnsmasq has been logging for > > > that exchange, to verify whether and how dnsmasq would have received > > > those DHCPREQUESTs for renewal. > > > > Some good news, it turns out my firewall was dropping any incoming DHCP > > message that was not a broadcast (only 255.255.255.255 was getting in) > > causing this problem. > > I declared victory too soon. NOT SOLVED. > > If the ESP was reconnecting and the ARP entry was still in cache, it will > refuse to connect HOWEVER renewal is now solved. OKay, tell us what is at _your_ side. * Overview * Configuration * Logging * What is on the wire ( ".pcap" ) Groeten Geert Stappers P.S. > > You could consider this problem solved. > > Sorry for all the noise and concern for nothing. Advice: Document to working setup Request: Document it here, this mailinglist (archive) -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Behavior on DHCP denied
On 4/19/23 13:35, 0zl wrote: On 4/19/23 11:38, Buck Horn wrote: Yes this is proxy ARP in https://en.wikipedia.org/wiki/Proxy_ARP. HostAPd has an option called proxy_arp which setups up proxy_arp with additional requirements to meet the Hotspot 2.0 standards. It comes built in with a couple of snoopers, including a DHCP snooper to configure proxy_arp without the need for additional software. I've attached a pcap file, if you need any more logs or information please let me know. Only thing I've changed for this capture is setting the lease time to 2m in order to make it faster for me to capture this for you, in normal operation it was set to 8hours. Note that the capture includes a ARP probe from the ESP and no response, just keep in mind that the WiFi router does in fact respond to it, it just doesn't do so over that bridge port so it didn't get captured on the gateway's end. I think your issue starts earlier: Your pcap indicates a failing lease renewal. Lines 12 to 18 show your ESP is attempting to renew its DHCP lease through 10.46.109.1 after ~62 seconds as expected (about half the 120secs leasetime) - but those requests seem to never have received a reply. In absence of a reply from the known DHCP server, lines 19 to 27 then show your ESP to send renewal requests to the broadcast address. As those are not answered either, your ESP finally releases its expired lease (line 28). It then initiates DHCP negotiation for a completely new lease, by broadcasting for DHCP servers, and it's only then that ARP probing would prompt it to DHCPDECLINE. But I'd have expected dnsmasq to have extended your ESP's existing lease straight for the first DHCPREQUEST for renewal (line 12). This would suggest that dnsmasq has not received or ignored both those DHCPREQUESTs for renewal as well as the DHCPRELEASE, which could explain both the failed renewal as well as the offending DHCPDECLINEs. Are you splitting your network, e.g. into several VLANs? It would be interesting to see what dnsmasq has been logging for that exchange, to verify whether and how dnsmasq would have received those DHCPREQUESTs for renewal. Kind regards, Buck ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss Some good news, it turns out my firewall was dropping any incoming DHCP message that was not a broadcast (only 255.255.255.255 was getting in) causing this problem. You could consider this problem solved. Sorry for all the noise and concern for nothing. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss I declared victory too soon. NOT SOLVED. If the ESP was reconnecting and the ARP entry was still in cache, it will refuse to connect HOWEVER renewal is now solved. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Behavior on DHCP denied
On 4/19/23 11:38, Buck Horn wrote: Yes this is proxy ARP in https://en.wikipedia.org/wiki/Proxy_ARP. HostAPd has an option called proxy_arp which setups up proxy_arp with additional requirements to meet the Hotspot 2.0 standards. It comes built in with a couple of snoopers, including a DHCP snooper to configure proxy_arp without the need for additional software. I've attached a pcap file, if you need any more logs or information please let me know. Only thing I've changed for this capture is setting the lease time to 2m in order to make it faster for me to capture this for you, in normal operation it was set to 8hours. Note that the capture includes a ARP probe from the ESP and no response, just keep in mind that the WiFi router does in fact respond to it, it just doesn't do so over that bridge port so it didn't get captured on the gateway's end. I think your issue starts earlier: Your pcap indicates a failing lease renewal. Lines 12 to 18 show your ESP is attempting to renew its DHCP lease through 10.46.109.1 after ~62 seconds as expected (about half the 120secs leasetime) - but those requests seem to never have received a reply. In absence of a reply from the known DHCP server, lines 19 to 27 then show your ESP to send renewal requests to the broadcast address. As those are not answered either, your ESP finally releases its expired lease (line 28). It then initiates DHCP negotiation for a completely new lease, by broadcasting for DHCP servers, and it's only then that ARP probing would prompt it to DHCPDECLINE. But I'd have expected dnsmasq to have extended your ESP's existing lease straight for the first DHCPREQUEST for renewal (line 12). This would suggest that dnsmasq has not received or ignored both those DHCPREQUESTs for renewal as well as the DHCPRELEASE, which could explain both the failed renewal as well as the offending DHCPDECLINEs. Are you splitting your network, e.g. into several VLANs? It would be interesting to see what dnsmasq has been logging for that exchange, to verify whether and how dnsmasq would have received those DHCPREQUESTs for renewal. Kind regards, Buck ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss Some good news, it turns out my firewall was dropping any incoming DHCP message that was not a broadcast (only 255.255.255.255 was getting in) causing this problem. You could consider this problem solved. Sorry for all the noise and concern for nothing. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Behavior on DHCP denied
On 4/19/23 08:37, Geert Stappers wrote: On Wed, Apr 19, 2023 at 03:16:37AM +0300, 0zl wrote: On 4/18/23 22:51, Geert Stappers wrote: On Tue, Apr 18, 2023 at 08:24:17PM +0100, Simon Kelley wrote: On 18/04/2023 16:35, 0zl wrote: Hello, This is an issue I've experienced with ESP8266 and proxy ARP on my WiFi network. Please confirm that it is proxy ARP as in https://en.wikipedia.org/wiki/Proxy_ARP Yes this is proxy ARP in https://en.wikipedia.org/wiki/Proxy_ARP. Acknowlegde HostAPd has an option called proxy_arp which setups up proxy_arp with additional requirements to meet the Hotspot 2.0 standards. It comes built in with a couple of snoopers, including a DHCP snooper to configure proxy_arp without the need for additional software. Somehow I do read: "I could make it complicated, so I made it complicated" The good thing, the thing I might regret, is that we have now this interesting problem ... I was able to work around it by assigning the devices an infinite lease, however I think dnsmasq's behavior is undesirable. In short, ESP8266 is on a network with proxy ARP setup; getting the initial lease works fine, however once proxy ARP kicks in it fails to renew. This is the chain of events leading up to the issue: * MCU tries to renew the address * dnsmasq properly renews its address * MCU sends an ARP request to check if the address is in use and receives an ARP reply from the router because of proxy ARP * MCU mistakenly believes that the address was assigned already even though it was not, sends a DENIED message back to dnsmasq and tries again * dnsmasq then allocates the exact same address that the MCU just rejected I think in this scenario, dnsmasq should try to allocate a different address because MCU has rejected it already. Not sure what people in this mailing list think, but it feels like dnsmasq shouldn't be doing this. This situation was considered and there should be sensible behaviour. Dnsmasq uses a hash of the MAC address to determine which the address to offer to the client, which would cause the same address always to be offered to the client. But if a client returns a DHCPDECLINE reply then a global variable is incremented. That variable is also used as an input to the hash function, so when the client asks again for an address it should get offered a different one. So, this situation has been considered, but something is going wrong in your setup. Please could you post more details of the configuration you are using and logs of what happens so we can try and work out what is going wrong? Yes, interesting problem. I do hope there will be libpcap files. I've attached a pcap file, See it. if you need any more logs or information please let me know. Simon already did: Please could you post more details of the configuration you are using and logs of what happens so we can try and work out what is going wrong? Only thing I've changed for this capture is setting the lease time to 2m in order to make it faster for me to capture this for you, in normal operation it was set to 8hours. Have that visible in the configuration file. Note that the capture includes a ARP probe from the ESP Which package number (which package numbers) in the .pcap are we talking about? If it are 6 and 7, say so. and no response, just keep in mind that the WiFi router does in fact respond to it, it just doesn't do so over that bridge port so it didn't get captured on the gateway's end. "that bridge port"??? Regards Geert Stappers Looking forward to the further information for Subject: Re: [Dnsmasq-discuss] Behavior on DHCP denied Hi, Regarding the packages numbers in the .pcap. Buck wrote a really good response which explains what I was talking about in depth. So I don't think there is a need to respond to it. As for my config file, I'll share it here: domain-needed bogus-priv no-resolv server=127.0.0.1#40 local=/rlan.eu.org/ domain=rlan.eu.org dhcp-fqdn address=/use-application-dns.net/ address=/wpad.rlan.eu.org/ interface=br-lan dhcp-authoritative dhcp-rapid-commit dhcp-option=42,0.0.0.0 dhcp-range=10.146.97.0,10.146.98.255,8h I didn't mention it in the previous emails, but the first thing I tried was remove dhcp-authoritative anddhcp-rapid-commit but that did not help. The capture I sent used that config, but with 2m set instead of 8h as lease time. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Behavior on DHCP denied
On 4/19/23 11:38, Buck Horn wrote: Yes this is proxy ARP in https://en.wikipedia.org/wiki/Proxy_ARP. HostAPd has an option called proxy_arp which setups up proxy_arp with additional requirements to meet the Hotspot 2.0 standards. It comes built in with a couple of snoopers, including a DHCP snooper to configure proxy_arp without the need for additional software. I've attached a pcap file, if you need any more logs or information please let me know. Only thing I've changed for this capture is setting the lease time to 2m in order to make it faster for me to capture this for you, in normal operation it was set to 8hours. Note that the capture includes a ARP probe from the ESP and no response, just keep in mind that the WiFi router does in fact respond to it, it just doesn't do so over that bridge port so it didn't get captured on the gateway's end. I think your issue starts earlier: Your pcap indicates a failing lease renewal. Lines 12 to 18 show your ESP is attempting to renew its DHCP lease through 10.46.109.1 after ~62 seconds as expected (about half the 120secs leasetime) - but those requests seem to never have received a reply. In absence of a reply from the known DHCP server, lines 19 to 27 then show your ESP to send renewal requests to the broadcast address. As those are not answered either, your ESP finally releases its expired lease (line 28). It then initiates DHCP negotiation for a completely new lease, by broadcasting for DHCP servers, and it's only then that ARP probing would prompt it to DHCPDECLINE. But I'd have expected dnsmasq to have extended your ESP's existing lease straight for the first DHCPREQUEST for renewal (line 12). This would suggest that dnsmasq has not received or ignored both those DHCPREQUESTs for renewal as well as the DHCPRELEASE, which could explain both the failed renewal as well as the offending DHCPDECLINEs. Are you splitting your network, e.g. into several VLANs? It would be interesting to see what dnsmasq has been logging for that exchange, to verify whether and how dnsmasq would have received those DHCPREQUESTs for renewal. Kind regards, Buck ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss I think your analysis is on point and no that network in particular is not split into several VLANs. The dnsmasq logs don't show anything special, what config should I set to make the logs more useful? ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Behavior on DHCP denied
Yes this is proxy ARP in https://en.wikipedia.org/wiki/Proxy_ARP. HostAPd has an option called proxy_arp which setups up proxy_arp with additional requirements to meet the Hotspot 2.0 standards. It comes built in with a couple of snoopers, including a DHCP snooper to configure proxy_arp without the need for additional software. I've attached a pcap file, if you need any more logs or information please let me know. Only thing I've changed for this capture is setting the lease time to 2m in order to make it faster for me to capture this for you, in normal operation it was set to 8hours. Note that the capture includes a ARP probe from the ESP and no response, just keep in mind that the WiFi router does in fact respond to it, it just doesn't do so over that bridge port so it didn't get captured on the gateway's end. I think your issue starts earlier: Your pcap indicates a failing lease renewal. Lines 12 to 18 show your ESP is attempting to renew its DHCP lease through 10.46.109.1 after ~62 seconds as expected (about half the 120secs leasetime) - but those requests seem to never have received a reply. In absence of a reply from the known DHCP server, lines 19 to 27 then show your ESP to send renewal requests to the broadcast address. As those are not answered either, your ESP finally releases its expired lease (line 28). It then initiates DHCP negotiation for a completely new lease, by broadcasting for DHCP servers, and it's only then that ARP probing would prompt it to DHCPDECLINE. But I'd have expected dnsmasq to have extended your ESP's existing lease straight for the first DHCPREQUEST for renewal (line 12). This would suggest that dnsmasq has not received or ignored both those DHCPREQUESTs for renewal as well as the DHCPRELEASE, which could explain both the failed renewal as well as the offending DHCPDECLINEs. Are you splitting your network, e.g. into several VLANs? It would be interesting to see what dnsmasq has been logging for that exchange, to verify whether and how dnsmasq would have received those DHCPREQUESTs for renewal. Kind regards, Buck ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
