search

AdguardTeam / AdGuardHome

Network-wide ads & trackers blocking DNS server
https://adguard.com/adguard-home.html
GNU General Public License v3.0
25.51k stars 1.83k forks source link

DHCP offer ignored for some clients. #4337

Open zglurb opened 2 years ago

zglurb commented 2 years ago

Issue Details

Expected Behavior

I've just installed AdGuard Home and enabled the DHCP server after disabling the one from my router. I expect my devices to get their network configuration from the AdGuard's DHCP server.

Actual Behavior

It's working fine for all of my devices except for one that ignores DHCP offers. In an old issue, I've read this :

If Unix-like (i.e. Linux, MacOS, FreeBSD, etc.), what DHCP client is used and how is it configured? The thing is that some clients may be configured to ignore some specific DHCP OFFERs. For example, dhclient on FreeBSD has an option -u which forces dhclient to reject leases with unknown options in them. The default behaviour is to accept such lease offers.

I don't really have access to my device. It's an IoT device, not a computer or a phone so i can't check that. But i figured it might be the issue.

Using Wireshark I compared the DHCP offers from my router (which is accepted) and from AdGuard (which is ignored) and the only difference I could spot was this option in AdGuard's offer that was not in my routers.

Option: (61) Client identifier
    Length: 7
    Hardware type: Ethernet (0x01)
    Client MAC address: <mydevicemacaddress> (<mydevicemacaddress>)

Is there an option to prevent AdGuard Home sending this so I can test if this is really the cause of the issue?

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Birbber commented 2 years ago

@zglurb Apologies for the long silence! Is this issue still reproducible on the latest release?

zglurb commented 2 years ago

Yes, I still have this issue with v0.107.9.

EugeneOne1 commented 2 years ago

@zglurb, hello again. This is actually an insteresting case. Could you please provide some details about the aforementioned device? Is it somehow old? FYI, the RFC 6842 states that the option must be present if client sends it.

We've actually implemented the del option in the latest edge build. You may find the usage hints on it in the wiki. Could you please perform the desired test?

zglurb commented 2 years ago

The device is a Devmel AirSend (http://devmel.com/en/airsend.html). I use it to control my shutters. It's not old. I bought mine 2 years ago. I don't know what kind of board it's using or what OS it's running on. I didn't contact the developers from Devmel though. Maybe I should have.

Anyway, I'll try the last edge build with the del option this weekend and I'll get back to you.

zglurb commented 2 years ago

OK so I updated my docker image to adguard/adguardhome:edge and added the del 61 option. The option is working but the DHCP offer still isn't accepted. So I guess option 61 wasn't the problem.

Here are more details (copy and paste from Wireshark) if you want to take a look at it. Otherwise it's OK, I'm fine with my router DHCP server.

DHCP discovery request from my device.

Frame 9272: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface \Device\NPF_{608A99CF-6EEC-4065-B976-EF173BC62DF2}, id 0
    Interface id: 0 (\Device\NPF_{608A99CF-6EEC-4065-B976-EF173BC62DF2})
        Interface name: \Device\NPF_{608A99CF-6EEC-4065-B976-EF173BC62DF2}
        Interface description: Ethernet 6
    Encapsulation type: Ethernet (1)
    Arrival Time: Aug 26, 2022 18:11:25.316927000 Paris, Madrid (heure d’été)
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1661530285.316927000 seconds
    [Time delta from previous captured frame: 0.002848000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 9.688772000 seconds]
    Frame Number: 9272
    Frame Length: 342 bytes (2736 bits)
    Capture Length: 342 bytes (2736 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:dhcp]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: CLIENT_MAC_ADDRESS (CLIENT_MAC_ADDRESS), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        Address: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: CLIENT_MAC_ADDRESS (CLIENT_MAC_ADDRESS)
        Address: CLIENT_MAC_ADDRESS (CLIENT_MAC_ADDRESS)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 328
    Identification: 0x0000 (0)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 128
    Protocol: UDP (17)
    Header Checksum: 0x39a6 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 0.0.0.0
    Destination Address: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
    Source Port: 68
    Destination Port: 67
    Length: 308
    Checksum: 0x28e4 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 19]
    [Timestamps]
        [Time since first frame: 0.000000000 seconds]
        [Time since previous frame: 0.000000000 seconds]
    UDP payload (300 bytes)
Dynamic Host Configuration Protocol (Discover)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x00033863
    Seconds elapsed: 0
    Bootp flags: 0x8000, Broadcast flag (Broadcast)
        1... .... .... .... = Broadcast flag: Broadcast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: CLIENT_MAC_ADDRESS (CLIENT_MAC_ADDRESS)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Discover)
        Length: 1
        DHCP: Discover (1)
    Option: (55) Parameter Request List
        Length: 6
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (15) Domain Name
        Parameter Request List Item: (119) Domain Search
        Parameter Request List Item: (252) Private/Proxy autodiscovery
    Option: (57) Maximum DHCP Message Size
        Length: 2
        Maximum DHCP Message Size: 500
    Option: (61) Client identifier
        Length: 7
        Hardware type: Ethernet (0x01)
        Client MAC address: CLIENT_MAC_ADDRESS (CLIENT_MAC_ADDRESS)
    Option: (0) Padding
        Padding: 0000
    Option: (255) End
        Option End: 255
    Padding: 000000000000000000000000000000000000000000000000000000000000000000

Ignored DHCP offer from AdGuard Home

Frame 9480: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface \Device\NPF_{608A99CF-6EEC-4065-B976-EF173BC62DF2}, id 0
    Interface id: 0 (\Device\NPF_{608A99CF-6EEC-4065-B976-EF173BC62DF2})
        Interface name: \Device\NPF_{608A99CF-6EEC-4065-B976-EF173BC62DF2}
        Interface description: Ethernet 6
    Encapsulation type: Ethernet (1)
    Arrival Time: Aug 26, 2022 18:11:25.466206000 Paris, Madrid (heure d’été)
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1661530285.466206000 seconds
    [Time delta from previous captured frame: 0.015244000 seconds]
    [Time delta from previous displayed frame: 0.149279000 seconds]
    [Time since reference or first frame: 9.838051000 seconds]
    Frame Number: 9480
    Frame Length: 342 bytes (2736 bits)
    Capture Length: 342 bytes (2736 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:dhcp]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: Synology_20:09:11 (SYNOLOGY_MAC_ADDRESS), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        Address: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: Synology_20:09:11 (SYNOLOGY_MAC_ADDRESS)
        Address: Synology_20:09:11 (SYNOLOGY_MAC_ADDRESS)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.201, Dst: 255.255.255.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 328
    Identification: 0xbe0e (48654)
    Flags: 0x40, Don't fragment
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0xb925 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.1.201
    Destination Address: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
    Source Port: 67
    Destination Port: 68
    Length: 308
    Checksum: 0xf31b [unverified]
    [Checksum Status: Unverified]
    [Stream index: 20]
    [Timestamps]
        [Time since first frame: 0.000000000 seconds]
        [Time since previous frame: 0.000000000 seconds]
    UDP payload (300 bytes)
Dynamic Host Configuration Protocol (Offer)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x00033863
    Seconds elapsed: 0
    Bootp flags: 0x8000, Broadcast flag (Broadcast)
        1... .... .... .... = Broadcast flag: Broadcast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0
    Your (client) IP address: 192.168.1.20
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: CLIENT_MAC_ADDRESS (CLIENT_MAC_ADDRESS)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (1) Subnet Mask (255.255.255.0)
        Length: 4
        Subnet Mask: 255.255.255.0
    Option: (3) Router
        Length: 4
        Router: 192.168.1.254
    Option: (6) Domain Name Server
        Length: 8
        Domain Name Server: 192.168.1.201
        Domain Name Server: 192.168.1.201
    Option: (51) IP Address Lease Time
        Length: 4
        IP Address Lease Time: (86400s) 1 day
    Option: (53) DHCP Message Type (Offer)
        Length: 1
        DHCP: Offer (2)
    Option: (54) DHCP Server Identifier (192.168.1.201)
        Length: 4
        DHCP Server Identifier: 192.168.1.201
    Option: (255) End
        Option End: 255
    Padding: 00000000000000000000000000000000000000000000

Accepted DHCP offer by my router

Frame 27558: 590 bytes on wire (4720 bits), 590 bytes captured (4720 bits) on interface \Device\NPF_{608A99CF-6EEC-4065-B976-EF173BC62DF2}, id 0
    Interface id: 0 (\Device\NPF_{608A99CF-6EEC-4065-B976-EF173BC62DF2})
        Interface name: \Device\NPF_{608A99CF-6EEC-4065-B976-EF173BC62DF2}
        Interface description: Ethernet 6
    Encapsulation type: Ethernet (1)
    Arrival Time: Aug 26, 2022 18:11:45.103588000 Paris, Madrid (heure d’été)
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1661530305.103588000 seconds
    [Time delta from previous captured frame: 0.000119000 seconds]
    [Time delta from previous displayed frame: 0.000119000 seconds]
    [Time since reference or first frame: 29.475433000 seconds]
    Frame Number: 27558
    Frame Length: 590 bytes (4720 bits)
    Capture Length: 590 bytes (4720 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:dhcp]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: FreeboxS_19:e7:02 (ROUTER_MAC_ADDRESS), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        Address: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: FreeboxS_19:e7:02 (ROUTER_MAC_ADDRESS)
        Address: FreeboxS_19:e7:02 (ROUTER_MAC_ADDRESS)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.254, Dst: 255.255.255.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 576
    Identification: 0x0000 (0)
    Flags: 0x40, Don't fragment
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x7607 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.1.254
    Destination Address: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
    Source Port: 67
    Destination Port: 68
    Length: 556
    Checksum: 0xa657 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 45]
    [Timestamps]
        [Time since first frame: 0.000000000 seconds]
        [Time since previous frame: 0.000000000 seconds]
    UDP payload (548 bytes)
Dynamic Host Configuration Protocol (Offer)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x00033863
    Seconds elapsed: 0
    Bootp flags: 0x8000, Broadcast flag (Broadcast)
        1... .... .... .... = Broadcast flag: Broadcast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0
    Your (client) IP address: 192.168.1.106
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: CLIENT_MAC_ADDRESS (CLIENT_MAC_ADDRESS)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Offer)
        Length: 1
        DHCP: Offer (2)
    Option: (54) DHCP Server Identifier (192.168.1.254)
        Length: 4
        DHCP Server Identifier: 192.168.1.254
    Option: (51) IP Address Lease Time
        Length: 4
        IP Address Lease Time: (43200s) 12 hours
    Option: (1) Subnet Mask (255.255.255.0)
        Length: 4
        Subnet Mask: 255.255.255.0
    Option: (3) Router
        Length: 4
        Router: 192.168.1.254
    Option: (6) Domain Name Server
        Length: 4
        Domain Name Server: 192.168.1.201
    Option: (255) End
        Option End: 255
    Padding: 000000000000000000000000000000000000000000000000000000000000000000000000…

I censored the MAC addresses. Honestly, I don't see much differences except the order the options are sent.

EugeneOne1 commented 2 years ago

@zglurb, I can't seem any significant discrepancies between the frames either. Could you please try to make those closer by setting the option 6 to a single IP address instead of duplicating it twice?

ainar-g commented 2 years ago

@EugeneOne1, just to be clear, the duplicated IP address is sent by AdGuard Home to prevent OSs, especially Android, from using one of their default servers as a secondary server. It would be weird if this is the thing that makes this particular device reject the lease, although not impossible, of course.

EugeneOne1 commented 2 years ago

@zglurb, we've came up with a few more suggestions. Could you please try to perform the following?

Firstly, check for updates of the Devmel AirSend's firmware? The outdated firmware versions often may cause such issues on IoT devices.

Then check for some cached DHCP configurations and leases from the router's DHCP. Perhaps, there is some kind of reset button to clear those.

Afterwards, try to create a static lease for the device with the 192.168.1.106 IP address. It's possible, the device expects the particular address but doesn't request it within the parameter.

If any of suggested helped? If no, could you please send us the whole Wireshark's dump file to inspect it thoroughly? You may send it to devteam@adguard.com.

EugeneOne1 commented 2 years ago

@zglurb, is the issue still relevant?

zglurb commented 2 years ago

Sorry I didn't have time to run these tests before. Yes I still have the issue.

Firstly, check for updates of the Devmel AirSend's firmware? The outdated firmware versions often may cause such issues on IoT devices.

They don't seem to provide any way to update the firmware.

Then check for some cached DHCP configurations and leases from the router's DHCP. Perhaps, there is some kind of reset button to clear those.

Do you mean some kind of security to only accept DHCP offers from a specific server ? I didn't find a way to reset the device. Neither a physical button nor an option in the app.

I can't seem any significant discrepancies between the frames either. Could you please try to make those closer by setting the option 6 to a single IP address instead of duplicating it twice? Afterwards, try to create a static lease for the device with the 192.168.1.106 IP address. It's possible, the device expects the particular address but doesn't request it within the parameter.

I tried both, didn't change anything.

If any of suggested helped? If no, could you please send us the whole Wireshark's dump file to inspect it thoroughly? You may send it to devteam@adguard.com.

I'm sending you an email with 2 non filtered Wireshark exports. One with AdGuard as DHCP server, the other one with my router.

EugeneOne1 commented 2 years ago

@zglurb, we've received and are investigating the files. Thanks for you help.

EugeneOne1 commented 2 years ago

@zglurb, hello again. We've checked the dumps and indeed there is no much difference between the DHCP responses. However, the thing that caught our attention is the amount of padding in the router's response. This led us to the RFC 2131 and the obsolete version of it (RFC 1541) which are recommending to keep the minimum size of the message of 576 bytes (perhaps, some clients refuse the smaller messages). So we've implemented it in the latest edge build. Could you please check it out?

zglurb commented 2 years ago

Hello again,

Sorry, still no success. The packets did get bigger after the update (342 bytes before, 618 after) but they are still ignored.

I have created a ticket to Devmel to ask them if it's possible to access the device to view the logs. I've also sent them the link to this issue. I'll get back to you if I get a positive answer.

brad925 commented 2 years ago

I am having this issue as well but it only affects Roku devices, wired and wireless, after updating to v0.107.12. AGH is running on Ubuntu server using the install script from here (not Docker). Packet captures show the DHCP Discover and DHCP Offer but the Roku does not accept the DHCP IP. This is the first time I've had this issue.

I tried to add a static DHCP mapping but that didn't work. I thought it might be because the Roku was sending option 12 (Host Name) but when I tried to add a static for the MAC, IP, and host name of RokuDevice, I received an error that the hostname is not unique.

Is there a log or a capture I can provide to help with troubleshooting?

Edit: I tried on a different SSID that uses a different DHCP server. That was successful on the Roku devices. The failing DHCP offers from AGH have a length of 782. I did notice in the AGH DHCP Offer there is a padding at the end of the bootstrap versus the other DHCP server ACK doesn't have padding.

ainar-g commented 2 years ago

@zglurb, there were some newer fixes in v0.107.13. Does the issue still persist?

@brad925, have you tried the latest version? Regarding the logs, see the verbose logs section in our FAQ.

piercedtiger commented 2 years ago

So I had a problem similar to @brad925. I've been fighting connectivity issues for 2 days now. We have 20+ devices on our home network between air conditioners, laptops, phones, thermostats, smart plugs, etc. Every single one is working fine, and has been for months. That is until 2 days ago when the Blink video doorbells stopped working right. No live view, no motion alerts, no video capture. Removed from app, unable to re-add them. Thought it was their flaky wifi hardware until the Roku TVs started dropping too. Main living room one, hard wired, was fine until tonight when it too failed to get an IP address wireless or hardwired. Finally on a whim I decided to try switching DHCP servers after reading this thread. (Didn't think it would help since I've released/renewed IPs and dropped/connected to WiFi a hundred times in the last 2 days chasing this issue.)

-Turned off AGH (completely, shut down the container on my NAS) and enabled the DHCP server on my router. Roku reconnected. -Turned DHCP on the router back off, started AGH on NAS. Roku failed to connect again. -DHCP on AGH off, DHCP on router on. Roku reconnected. -Now DHCP is back to AGH with DHCP on the router being off. Roku is connected, and Blink cameras are back online for the first time in 2 days.

WTF.

Edit: Well at least Blink finally emailed me saying login issues have been resolved, even though I never saw a notification there was an official issue in the first place. So that is explained now.

zglurb commented 2 years ago

@ainar-g Yes, I still have this issue.

I've also got an answer from the device manufacturer. They told me that they know about the incompatibility issues with some DHCP servers. They haven't localised the problem yet and it's not a priority for them.

lutfor-diu commented 1 year ago

Issue Details

  • Version of AdGuard Home server:

    • v0.107.3

  • How did you install AdGuard Home:

    • Docker

  • How did you setup DNS configuration:

    • Synology NAS

  • If it's a router or IoT, please write device model:

    • DS1513+

  • CPU architecture:

    • x64

  • Operating system and version:

    • DSM 7.0 (Linux)

Expected Behavior

I've just installed AdGuard Home and enabled the DHCP server after disabling the one from my router. I expect my devices to get their network configuration from the AdGuard's DHCP server.

Actual Behavior

It's working fine for all of my devices except for one that ignores DHCP offers. In an old issue, I've read this :

If Unix-like (i.e. Linux, MacOS, FreeBSD, etc.), what DHCP client is used and how is it configured? The thing is that some clients may be configured to ignore some specific DHCP OFFERs. For example, dhclient on FreeBSD has an option -u which forces dhclient to reject leases with unknown options in them. The default behaviour is to accept such lease offers.

I don't really have access to my device. It's an IoT device, not a computer or a phone so i can't check that. But i figured it might be the issue.

Using Wireshark I compared the DHCP offers from my router (which is accepted) and from AdGuard (which is ignored) and the only difference I could spot was this option in AdGuard's offer that was not in my routers.

Option: (61) Client identifier
    Length: 7
    Hardware type: Ethernet (0x01)
    Client MAC address: <mydevicemacaddress> (<mydevicemacaddress>)

Is there an option to prevent AdGuard Home sending this so I can test if this is really the cause of the issue?

I confirm. my pc wifi lan card dont get dhcp leases

rafaeltm commented 6 months ago

Hi there!, I'm now experimenting this same issue ! The IoT device affected is a Tapo C225, seems be running MSFT 5.0 and while the router DHCP is ok, the Adguard enters in a Offer loop and does not configure the IP