Repeater DHCP Issues

[penguin22]

Are they not pulling an ip address or they keep showing up in the logs. At least on the machine i tested yesterday, it clearly got an ip address form the dhcp scope but it kept requesting the ip again and again. On the one that was connected to the repeater, rebooting the repeater was the only thing that fixed the symptoms. You are right though, before with the wireless instability, i didn't even get this far. I attributed the problems to wireless issues.

I'll spend some more time doing network captures and comparing the packets and see if i find anything. So far the only difference i've found was that the asus reply for the devices that had the issues were broadcast instead of unicast.

At least from the client perspective, they never received an IP address; displaying the generic 169.x.x.x instead of the local IP expected; this is true if they were previously assigned an IP and showing in the router DHCP reservations table as well.

 

[agilani]

At least from the client perspective, they never received an IP address; displaying the generic 169.x.x.x instead of the local IP expected; this is true if they were previously assigned an IP and showing in the router DHCP reservations table as well.

Just to be clear, are they connected to wireless, but don't get an ip address or they don't connect to wireless either. So if you assign a static ip address in the client, does the wireless still work?

 

[penguin22]

Just to be clear, are they connected to wireless, but don't get an ip address or they don't connect to wireless either. So if you assign a static ip address in the client, does the wireless still work?

I will need to test further, but have seen where assigning a static IP does work, e.g. my scope is set to a max of 250 on a /24 leaving some free addresses for use and when manually setting to 252, I can access ping devices on the network. I think there may be some routing "challenges" still, especially with iOS devices, which don't play well with the Asus routers in my experience, but that is a topic for another thread.

 

[ColinTaylor]

@agilani You appear to have two different sets of messages in your logs. Regarding the DHCPREQUEST/DHCPACK messages, these might be the old WPAD problem as reported here. The current Merlin firmware (384.5) changed the default setting of DHCP option 252.

But that's not the only time those messages appear. Coincidentally my syslog was flooded with the same messages all day today from my wife's laptop. And yet the last time that happened was probably a month ago. Seems to be a Windows thing.

P.S. You still haven't told us what router model and firmware you have.

 

[penguin22]

Just to be clear, are they connected to wireless, but don't get an ip address or they don't connect to wireless either. So if you assign a static ip address in the client, does the wireless still work?

With the issue occurring on my Galaxy S9+, it will continuously attempt to connect between the three SSIDs on the AP (AC3200), so this is on 2.4GHz and both 5GHz channels, but displays "Failed to obtain IP address." On the AP, I also show it's connection in Wireless log while attempting to obtain an IP address:

Device    IP Address    Rx/Tx & RSSI    Connected    Flags
8C:45:00:34:1E:B3
<unknown>    <unknown>
    866 / 6 Mbps
-45 dBm    0:00:19    PSTAU_

After failing to obtain an IP for over an hour with the phone in use on 4G LTE, a simple reboot of the MB immediately allowed for an IP to be obtained on any of the AP SSIDs. I don't see anything meaningful in any of the router logs, but might be able to collect information that is relevant if needed to help troubleshoot since I can repeat the issue within a 24-hour time span.

 

[kfp]

I don't see anything meaningful in any of the router logs, but might be able to collect information that is relevant if needed to help troubleshoot since I can repeat the issue within a 24-hour time span.

FWIW I don’t think your problems are specific to media bridge mode. I run a fairly similar network like yours: AC3200 (AP) <-> AC68U (MB)

but with much less devices (including an Apple device).

Everything has been running great, 3200 uptime is 10+ days now on 384.6 alpha2, 68U uptime 7+days on John’s 33E4. I also have a Windows machine connected to the MB and several Windows machines connected to the AP, and have not observed the aggressive DHCP requests some of you are seeing.

Some thoughts: Have you turned off the usual suspects like airtime fairness and roam assist? Have you “forget this network” on the problematic devices and renter the password for your network?

 

[penguin22]

FWIW I don’t think your problems are specific to media bridge mode. I run a fairly similar network like yours: AC3200 (AP) <-> AC68U (MB)

but with much less devices (including an Apple device).

Everything has been running great, 3200 uptime is 10+ days now on 384.6 alpha2, 68U uptime 7+days on John’s 33E4. I also have a Windows machine connected to the MB and several Windows machines connected to the AP, and have not observed the aggressive DHCP requests some of you are seeing.

Some thoughts: Have you turned off the usual suspects like airtime fairness and roam assist? Have you “forget this network” on the problematic devices and renter the password for your network?

Yes to all of the usual suspects. Have reset enough to be confident that devices and routers have no ghosts in them. This includes changing the router SSID that the MB connects to with the bare minimum connections (MB, an Echo, and FireTV), and changing out the MB in question.

Not to be lost, the issue does not occur when using the EA-N66R as a MB, but has less functionality for the extended network segment (27 devices [4 wired, 23 wireless]).

 

[kfp]

This includes changing the router SSID that the MB connects to with the bare minimum connections (MB, an Echo, and FireTV), and changing out the MB in question.

What if you go even more bare and test without the Echo and FireTV? Those devices tend to rely on broadcast traffic a bit too much to announce+discover services.

 

[agilani]

@agilani You appear to have two different sets of messages in your logs. Regarding the DHCPREQUEST/DHCPACK messages, these might be the old WPAD problem as reported here. The current Merlin firmware (384.5) changed the default setting of DHCP option 252.

But that's not the only time those messages appear. Coincidentally my syslog was flooded with the same messages all day today from my wife's laptop. And yet the last time that happened was probably a month ago. Seems to be a Windows thing.

P.S. You still haven't told us what router model and firmware you have.

I have an ac88 currently running alpha 2 that is the router with the dhcp server and two ac68 repeaters. The symptoms are very rare, but when the do happen it happens pretty consistently for specific devices.

I think i saw a setting somehwere for adding a wpad with carriage return to the dhcp reply under other settings. That is set to yes right now.

 

[agilani]

With the issue occurring on my Galaxy S9+, it will continuously attempt to connect between the three SSIDs on the AP (AC3200), so this is on 2.4GHz and both 5GHz channels, but displays "Failed to obtain IP address." On the AP, I also show it's connection in Wireless log while attempting to obtain an IP address:

Device    IP Address    Rx/Tx & RSSI    Connected    Flags
8C:45:00:34:1E:B3
<unknown>    <unknown>
    866 / 6 Mbps
-45 dBm    0:00:19    PSTAU_

After failing to obtain an IP for over an hour with the phone in use on 4G LTE, a simple reboot of the MB immediately allowed for an IP to be obtained on any of the AP SSIDs. I don't see anything meaningful in any of the router logs, but might be able to collect information that is relevant if needed to help troubleshoot since I can repeat the issue within a 24-hour time span.

You have to try and have the issue happen on something that you can get wireshark traffic from. I have the same issue happening with a thermostat, but i can't do much to troubleshoot it.

 

[penguin22]

What if you go even more bare and test without the Echo and FireTV? Those devices tend to rely on broadcast traffic a bit too much to announce+discover services.

Did so from the router perspective following the update to 384.6 and also disabled the 2.4GHz and first 5GHz network on the AC3200, which removed most devices, but (realized that I need to test further and failed to finish the sentence ).

You have to try and have the issue happen on something that you can get wireshark traffic from. I have the same issue happening with a thermostat, but i can't do much to troubleshoot it.

I'll fire up Wireshark the next time it occurs on one of my Windows clients.

 

[kfp]

Did so from the router perspective following the update to 345.6 and also disabled the 2.4GHz and first 5GHz network on the AC3200, which removed most devices, but

But...?

Another thing to try might be turning IGMP Snooping on (and if that breaks things then then on IGMP Proxy as well).

 

[penguin22]

But...?

Another thing to try might be turning IGMP Snooping on (and if that breaks things then then on IGMP Proxy as well).

Edited my post, including the horrible version mistake I made typing from mobile while watching a movie last night. Realized that I need to test further and failed to finish the sentence . I loaded up Wireshark and now just need to wait for it to occur again.

 

[penguin22]

Ok, my mobile device is currently having this issue after coming back from lunch. In Wireshark, from my laptop, I see many DHCP Discover captures without a response being received.

Bootstrap Protocol (Discover)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0xf1063c75
    Seconds elapsed: 7
    Bootp flags: 0x0000 (Unicast)
    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: MurataMa_34:1e:b3 (8c:45:00:34:1e:b3)
    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: (61) Client identifier
        Length: 7
        Hardware type: Ethernet (0x01)
        Client MAC address: MurataMa_34:1e:b3 (8c:45:00:34:1e:b3)
    Option: (57) Maximum DHCP Message Size
        Length: 2
        Maximum DHCP Message Size: 1500
    Option: (60) Vendor class identifier
        Length: 18
        Vendor class identifier: android-dhcp-8.0.0
    Option: (12) Host Name
        Length: 16
        Host Name: Davids-Galaxy-S9
    Option: (55) Parameter Request List
        Length: 10
        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: (26) Interface MTU
        Parameter Request List Item: (28) Broadcast Address
        Parameter Request List Item: (51) IP Address Lease Time
        Parameter Request List Item: (58) Renewal Time Value
        Parameter Request List Item: (59) Rebinding Time Value
        Parameter Request List Item: (43) Vendor-Specific Information
    Option: (255) End
        Option End: 255
    Padding: 00

Hopefully this is the important part of the capture, there are five sections of each capture and this appears to have the most plentiful.

 

[kfp]

Ok, my mobile device is currently having this issue after coming back from lunch. In Wireshark, from my laptop, I see many DHCP Discover captures without a response being received.

Mobile and laptop both connected to the AP?

 

[penguin22]

Mobile and laptop both connected to the AP?

Laptop is connected to the AP and has IP, mobile failing to obtain IP from the same AP connection. Wireshark monitoring from the laptop, so seeing the broadcast on the network.

 

[JDB]

FYI you can install tcpdump on the router via Entware. Makes tracing much easier!


Sent from my iPhone using Tapatalk

 

[kfp]

Laptop is connected to the AP and has IP, mobile failing to obtain IP from the same AP connection. Wireshark monitoring from the laptop, so seeing the broadcast on the network.

What if you release the DHCP lease on the laptop manually? Basically forcing it to do a DHCPDISCOVER.

 

[penguin22]

Looking at the WS capture, I see a plentiful amount of DHCP Discovers occurring regularly. Following a restart of the MB, the Discovers still occur, but there are matching DHCP Requests with the same transaction ID that have the requested IP address. It appears that when the issue occurs, the DHCP Discover doesn't get the expected response to then have a DHCP Request with IP.

 

[kfp]

Looking at the WS capture, I see a plentiful amount of DHCP Discovers occurring regularly. Following a restart of the MB, the Discovers still occur, but there are matching DHCP Requests with the same transaction ID that have the requested IP address. It appears that when the issue occurs, the DHCP Discover doesn't get the expected response to then have a DHCP Request with IP.

So does your router see those requests and provide a response?

Maybe we’ll have to tcpdump on the router like @JDB suggested to see which hop is dropping the ball here. tcpdump on router + AP/Bridge would help a lot.