Windows laptop issue obtaining IP through DHCP

Installing and Using OpenWrt Network and Wireless Configuration
1

A Windows-7 laptop connecting in below config has trouble obtaining IP from OpenWRT router.
DHCP logs pasted below, this keeps repeating.

This happens over WiFi and ethernet cable, both.
Sometimes it works, especially when I set a Static IP on the laptop and after some time revert it back to DHCP; that somehow sets the DHCP states rolling.

I am using this as workaround, but would like to know the root-cause.

I can see how client is coming from a different network.
Next step would have been dhcprequest ; but that doesn't happen.
Hence a reasonable answer would be it's client side issue.

However same laptop connects fine in a simpler setup, as given below.

Appreciate any help.

DHCPDISCOVER(br-lan) 192.168.43.171 4c:bb:58:1d:78:13
DHCPOFFER(br-lan) 192.168.7.9 4c:bb:58:1d:78:13
DHCPDISCOVER(br-lan) 192.168.43.171 4c:bb:58:1d:78:13
DHCPOFFER(br-lan) 192.168.7.9 4c:bb:58:1d:78:13

Problem setup:

Laptop ==== WiFi access point(Archer C7, in dumb-AP mode, dhcp disabled,cable in LAN port) ==== OpenWRT router(x86)

Working setup:

Laptop ==== WiFi router(DLINK in default(router) mode, dhcp enabled)

Is it that additional hop causing problem for dhcp request packets to reach across?
If so, it doesn't look to be a physical layer problem.

2

How are the firewalls configured? Could it be the Windows device is not getting the DHCPOFFER packets?

3

It's possible the laptop has anti-virus/firewalls enabled. People install lot of bloatware, intentional or otherwise.
But how does that not interfere in the working setup?

4

I was referring to firewalls on the routers, the laptop should open its own firewall by itself.

5

I have pretty standard firewall rules.
I am using a captive portal (wifidog) and multi-wan.
I had even tried "whitelisting" the mac address in captive portal.
Captive portal firewall rules kick in after a client obtains DHCP.
Does not give any problem for many many other DHCP clients.

6

You can try the following commands in an administrative command prompt:

netsh interface ip reset
netsh winsock reset

Reboot the machine and test again.

Can other devices obtain a DHCP lease just fine?

2 Likes
7

Yes, they do. I see this issue (the dhcp discover-offer loop) in about 2% of all devices (and every-time its windows).
I am awaiting next occurrence to try these commands.
From the description I already love them. Reset complete network stack using CLI on windows, really awesome. Thank you.

8

When it comes down to Windows....
Weird things can happen :smile:
Could be everything, drivers, a problem with the dhcp service or some other services or something deeper is broken.
But most of the time network related problems can be fixed by resetting the network settings.
Be aware that those commands will reset everything (network related) to it's defaults.
You maybe have to reinstall some software.

2 Likes
9

Did you make sure your DHCP server is set to be authoritative?

I can see the client is trying to discover a 192.168.43.x address, whereas the DHCP server offers a 192.168.7.x. This won't be an issue if you use /16, /17, or /18 netmasks. However usually people use a /24 netmask in the 192.168.x.y range. If you do for the DHCP server, then the server sees the discover for an IP address outside it's range, and only an authoritative DHCP server would actively deny it. A non-authoritative one just ignores it, leaving the client in the dark, so that all it can do is retry.

Seems to early for me to think, obviously there is the reply from the server already. Sorry for that. However, my suggestion would be to check on the Windows machine if the DHCP offer has reached it, using Wireshark, for instance. Maybe the C7 suppressed it, possibly on grounds of a netmask mismatch.

1 Like
10

Yes, i see that option authoritative '1' is set in /etc/config/dhcp

And, it's a /24 network.
I guess client had 192.168.43.x ip from it's previous connection.

I suppose dhcp offer/ack not reaching the client is a possibility, as I notice that sometimes even after ACK, the discover/offer continues.
What would be the reason for client not receiving offer/ack packets?
Or is it receiving but some firewall/anti-virus dropping it?

There is no netmask mismatch issue. This is a very simple /24 network which is working for about 50 other DHCP clients.