Some devices connect to wifi but don't seem to get an IP address

Installing and Using OpenWrt
1

Hi,

I'm having a really annoying issue with Openwrt which only seems to impact 1 device. Oddly enough it's now a different device from the last time it happened.

Nothing seems to fix it except for rolling back to stock firmware.

After rolling back to stock ( usr/sbin/fw_printenv -n boot_part then /usr/sbin/fw_setenv boot_part 2)

I can then of course flash back Openwrt let it do it's thing, and hey presto after doing the usual restore all settings to default and then carefully setting everything up it works!

But only for about 24 - 48 hours... then I get a device that won't connect (connects to wifi but device says no internet) so it appears the device doesn't even get an IP address.

No amount of rebooting fixes this, all other devices work fine and the only solution is to rollback, reinstall, and have it work for 24 hours.

Eventually of course I give up and go back to the awful stock which works but is rubbish for various reasons we all know about. (So much for all the marketing about this router being compatible with Openwrt) Yes you've guessed it, I was fooled into purchasing a piece of junk in the form of a Linksys WRT3200ACM because I simply believed what they were telling me.

The last time this happened it was a Windows PC with a USB wifi card, this time it's an Android tablet.

Two completely different OS's with different hardware with exactly the same problem? I have my suspisions this is either DHCP related, or some kind of bad wifi auth.

I'll keep the details at that for now because I'm not really sure what configs/info you'll need from me to help get to the bottom of this and I don't want to speculate and inadvertantly create red herrings.

Basic stuff.

Make/Model: Linksys WRT3200ACM

Firmware Ver: OpenWrt 19.07.4 r11208-ce6496d796 / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01

Settings mostly defaults Wifi setup for WPA2-PSK AES (no mixed mode) on both Radio 0 and 1; Radio 2 (Radar detection) I leave disabled, Adblock is the only extra service I have installed.

Thanks in advance for any help you are able to provide me with.

2

I would suspect dhcp pool starvation, but by default it is 150 addresses, so unless you reduced that it must be enough for a home network.
You can verify that with: uci show dhcp.lan
Another reason could be that some client is acting maliciously and reserves all the pool.
In any case a look at the logs could provide some clues.
logread -e dnsmasq
Also the cat /tmp/dhcp.leases will show all the active leases.

2 Likes
3

Hey trendy really appreciate your speedy reply!

Literally my network is 1 PC on the 5Ghz, 2 Roku's on the 2.4 Ghz and 1 Android Tablet. A Humax TV box connects via the LAN and has a static IP.

uci show dhcp.lan

dhcp.@dnsmasq[0]=dnsmasq
dhcp.@dnsmasq[0].domainneeded='1'
dhcp.@dnsmasq[0].boguspriv='1'
dhcp.@dnsmasq[0].filterwin2k='0'
dhcp.@dnsmasq[0].localise_queries='1'
dhcp.@dnsmasq[0].rebind_protection='1'
dhcp.@dnsmasq[0].rebind_localhost='1'
dhcp.@dnsmasq[0].local='/lan/'
dhcp.@dnsmasq[0].domain='lan'
dhcp.@dnsmasq[0].expandhosts='1'
dhcp.@dnsmasq[0].nonegcache='0'
dhcp.@dnsmasq[0].authoritative='1'
dhcp.@dnsmasq[0].readethers='1'
dhcp.@dnsmasq[0].leasefile='/tmp/dhcp.leases'
dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.auto'
dhcp.@dnsmasq[0].nonwildcard='1'
dhcp.@dnsmasq[0].localservice='1'
dhcp.@dnsmasq[0].confdir='/tmp/dnsmasq.d'
dhcp.lan=dhcp
dhcp.lan.interface='lan'
dhcp.lan.start='100'
dhcp.lan.limit='150'
dhcp.lan.leasetime='12h'
dhcp.lan.dhcpv6='server'
dhcp.lan.ra='server'
dhcp.wan=dhcp
dhcp.wan.interface='wan'
dhcp.wan.ignore='1'

cat /tmp/dhcp.leases (I've put xx for privacy on MAC and some bits of hostnames)

1602631691 76:7b:6a:xx:xx:xx 192.168.1.190 xxx-iPhone 01:76:7b:xx:xx:xx:xx
1602631272 64:66:b3:xx:xx:xx 192.168.1.173 DESKTOP-xxx 01:64:66:xx:xx:xx:xx
1602631226 c8:3a:6b:xx:xx:xx 192.168.1.115 * *
1602631226 c8:3a:6b:xx:xx:xx 192.168.1.102 Bedroom *
1602631226 a0:72:2c:xx:xx:xx 192.168.1.127 HUMAX

I'm still reading through logread -e dnsmasq will post it shortly after I anonymize some of the MAC's and host names for privacy.

4

There is no need to post all of it. If a transaction went fine, there is nothing to see. Focus on when a device doesn't get the lease from DHCP.
Also: tcpdump -i br-lan -evn udp port 67 to make sure that you receive and send the dhcp related packets.

2 Likes
5

If your network is IPv4 only, turn off the IPv6 DHCP server.

6

Gah, So I had the Android device powered off while I was fishing around in the logs, powered it back on and now it's working fine!

This issue will happen again though probably within another 24 hours.

Roughly 14:50 is when it finally connected, -e dnsmasq shows some entries prior to that (the point at which it was broken)

Tue Oct 13 12:20:19 2020 daemon.info dnsmasq-dhcp[3596]: read /etc/ethers - 0 addresses
Tue Oct 13 12:20:22 2020 daemon.info dnsmasq-dhcp[3596]: DHCPDISCOVER(br-lan) 192.168.1.127 a0:72:2c:xx:xx:xx
Tue Oct 13 12:20:22 2020 daemon.info dnsmasq-dhcp[3596]: DHCPOFFER(br-lan) 192.168.1.127 a0:72:2c:xx:xx:xx
Tue Oct 13 12:20:26 2020 daemon.info dnsmasq-dhcp[3596]: DHCPDISCOVER(br-lan) c8:3a:6b:xx:xx:xx
Tue Oct 13 12:20:26 2020 daemon.info dnsmasq-dhcp[3596]: DHCPOFFER(br-lan) 192.168.1.115 c8:3a:6b:xx:xx:xx
Tue Oct 13 12:20:26 2020 daemon.info dnsmasq-dhcp[3596]: DHCPDISCOVER(br-lan) 192.168.1.127 a0:72:2c:xx:xx:xx
Tue Oct 13 12:20:26 2020 daemon.info dnsmasq-dhcp[3596]: DHCPOFFER(br-lan) 192.168.1.127 a0:72:2c:xx:xx:xx
Tue Oct 13 12:20:26 2020 daemon.info dnsmasq-dhcp[3596]: DHCPREQUEST(br-lan) 192.168.1.127 a0:72:2c:xx:xx:xx
Tue Oct 13 12:20:26 2020 daemon.info dnsmasq-dhcp[3596]: DHCPACK(br-lan) 192.168.1.127 a0:72:2c:xx:xx:xx HUMAX
Tue Oct 13 12:20:26 2020 daemon.info dnsmasq-dhcp[3596]: DHCPDISCOVER(br-lan) c8:3a:6b:xx:xx:xx
Tue Oct 13 12:20:26 2020 daemon.info dnsmasq-dhcp[3596]: DHCPOFFER(br-lan) 192.168.1.115 c8:3a:6b:xx:xx:xx
Tue Oct 13 12:20:26 2020 daemon.info dnsmasq-dhcp[3596]: DHCPREQUEST(br-lan) 192.168.1.102 c8:3a:6b:xx:xx:xx
Tue Oct 13 12:20:26 2020 daemon.info dnsmasq-dhcp[3596]: DHCPACK(br-lan) 192.168.1.102 c8:3a:6b:xx:xx:xx Bedroom
Tue Oct 13 12:20:26 2020 daemon.info dnsmasq-dhcp[3596]: DHCPREQUEST(br-lan) 192.168.1.115 c8:3a:6b:xx:xx:xx
Tue Oct 13 12:20:26 2020 daemon.info dnsmasq-dhcp[3596]: DHCPACK(br-lan) 192.168.1.115 c8:3a:6b:xx:xx:xx
Tue Oct 13 12:21:11 2020 daemon.info dnsmasq-dhcp[3596]: DHCPREQUEST(br-lan) 192.168.1.173 64:66:b3:xx:xx:xx
Tue Oct 13 12:21:11 2020 daemon.info dnsmasq-dhcp[3596]: DHCPACK(br-lan) 192.168.1.173 64:66:b3:xx:xx:xx DESKTOP-xxx
Tue Oct 13 12:21:12 2020 daemon.info dnsmasq[3596]: read /etc/hosts - 4 addresses
Tue Oct 13 12:21:12 2020 daemon.info dnsmasq[3596]: read /tmp/hosts/odhcpd - 2 addresses
Tue Oct 13 12:21:12 2020 daemon.info dnsmasq[3596]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
Tue Oct 13 12:21:12 2020 daemon.info dnsmasq-dhcp[3596]: read /etc/ethers - 0 addresses
Tue Oct 13 12:21:12 2020 daemon.info dnsmasq-dhcp[3596]: DHCPREQUEST(br-lan) 192.168.1.173 64:66:b3:xx:xx:xx
Tue Oct 13 12:21:12 2020 daemon.info dnsmasq-dhcp[3596]: DHCPACK(br-lan) 192.168.1.173 64:66:b3:xx:xx:xx DESKTOP-xxx
Tue Oct 13 12:28:11 2020 daemon.info dnsmasq-dhcp[3596]: DHCPREQUEST(br-lan) 192.168.1.190 76:7b:6a:xx:xx:xx
Tue Oct 13 12:28:11 2020 daemon.info dnsmasq-dhcp[3596]: DHCPACK(br-lan) 192.168.1.190 76:7b:6a:xx:xx:xx xxx-iPhone

I'll get tcpdump up and ready for the next time this happens, thanks for your help I'll probably be back again in 24 hours!

7

I mean IPv6 is no big deal for me, so I could probably try disabling the IPv6 DHCP server at some point when it happens again.

Are there known issues with the IPv6 DHCP server? I'm pretty clueless with IPv6 so I just tend to leave that stuff alone as much as possible.

8

No, there is no connection between dhcpv4 and dhcpv6. They are different servers listening to different ports.

9

Yeah I figured as much regards dhcpv6, I can always give that a try later.

Installed tcpdump and I've been running it whilst trying to connect the Android device, does it output any connections to the screen or should I be looking for the results in a log file somewhere?

I don't seem to be getting any results...

10

No it should show them on the screen.
Verify that the lan interface is br-lan: ifstatus lan | grep device

2 Likes
12

Yeah it's working, rebooted a known working device and I can see the tcpdump magic happening.

The Android is not showing up even though client side it's saying connected to wifi no internet.

Sorry for the multiple replies, just getting used to the forum format.

13

Just be careful with your daily quota of replies. Merge some replies if needed.

If the AP is running on the router and the wifi is part of the bridged lan interface (the default configuration that is), then tcpdump will show everything. If the AP is a separate device, then there might be something wrong there which is blocking them.

2 Likes
14

Yeah it's all on the same Router. By AP I meant the software running on openwrt that does the wireless authentication.

15

are you using default openwrt 19.07.4 drivers and firmware wifi on the wrt? if so you can try eduperez ipk with tagabe patch

sorry edit,yes: ipk*

1 Like
16

I assume I'm on the defaults yes.

"can try eduperez ipk with tagabe patch"

I'm not sure I know how?

EDIT

I think I found what I need here:

Should I install kmod-mwlwifi or mwlwifi-firmware or both?

Thanks.

EDIT

Tried, but same problem persists.

EDIT

After some reading, disabling WMM fixed the Android client... but then the Windows 10 PC got exactly the same issue!

After disabling WMM on both radios, restarting each radio, enabling WMM again on both radios and finally rebooting the wrt (just to make absolutely sure) all devices are now working fine again.

I suspect this issue will come back again, from my limited knowledge and what I was able to Google WMM has something to do with QoS.
Could it be some sort of throttling bug perhaps?

Pretty sure the culprit is WMM now, and at least now I have a work around until I find a more permenant fix.

Thanks everybody for your help!

17

that should be last step on wrt 3200 acm, first step i would try only on 2.4 ghz wpa/wpa2 mixed mode, if that does not work, i 'll try disable WMM on the 2,4 ghz. 2,4 is an example. if for some reason is the other way around, change that 5 ghz. but another way is to use just radio2 for devices like that..

18

Been stable for a week now.

That driver seems to be doing the trick.

Thank you!

19

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.