OpenWrt/LEDE Project

  • Status Waiting on reporter
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version openwrt-19.07
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by rjb - 18.01.2020
Last edited by Hans Dedecker - 02.02.2020

FS#2748 - Printer no more receiving IP address since 19.07.0

Dear community,
Previously I had OpenWRT 18.06.5 in use and my printer (HP LaserJet Pro 400 M475dw) was connecting fine over 2.4 GHz WiFi and obtained an IP address of defined DHCP static leases.
I went to 19.07.0 by starting from scratch on the same Netgear R7800 hardware. Everything works fine except for the mentioned printer.
It connects to WiFi and is shown in the list of associated stations, but it doesn’t receive an IP. The syslog prints following two lines about every minute:
Sat Jan 18 13:12:19 2020 dnsmasq-dhcp[20788]: DHCPDISCOVER(wlan1) 34:23:87:xx:xx:xx
Sat Jan 18 13:12:19 2020 dnsmasq-dhcp[20788]: DHCPOFFER(wlan1) 34:23:87:xx:xx:xx

What I’ve tried so far:
- enable/disable static leases: same behavior
- enable/disable KRACK countermeasures: same behavior
- require/optional/disable 802.11w Management Frame Protection: with require and even with optional the printer would not connect to WiFi at all
- factory reset printer and try again: no difference

Additional info:
- I have no WPA3 packets installed or activated - just default firmware image obtained from OpenWRT. Only additional packet is luci-ssl (+dependencies)
- all other devices that connect to 2.4 GHz or 5 GHz get their IP addresses. Those are mobile phones, laptops, tablets, TV’s, Chromecast, vacuum robot...
- As well no problem with physically connected devices like NAS, VoIP phone base, home automation system
- Printer display shows WiFi is connected but IP is set to
- It doesn’t look like a WiFi issue, more like something is different with the DHCP server between 18.06.5 and 19.07.0

rjb commented on 02.02.2020 15:46

Same situation with 19.07.1:

Sun Feb 2 16:41:38 2020 dnsmasq-dhcp[2089]: DHCPDISCOVER(br-lan) 34:23:87:xx:xx:xx
Sun Feb 2 16:41:38 2020 dnsmasq-dhcp[2089]: DHCPOFFER(br-lan) 34:23:87:xx:xx:xx
Sun Feb 2 16:42:43 2020 dnsmasq-dhcp[2089]: DHCPDISCOVER(br-lan) 34:23:87:xx:xx:xx
Sun Feb 2 16:42:43 2020 dnsmasq-dhcp[2089]: DHCPOFFER(br-lan) 34:23:87:xx:xx:xx
Sun Feb 2 16:43:47 2020 dnsmasq-dhcp[2089]: DHCPDISCOVER(br-lan) 34:23:87:xx:xx:xx
Sun Feb 2 16:43:47 2020 dnsmasq-dhcp[2089]: DHCPOFFER(br-lan) 34:23:87:xx:xx:xx

Project Manager
Hans Dedecker commented on 02.02.2020 16:42

Are you capable of taking tcpdump traces of the working and the non-working DHCP exchange ?
Maybe comparing the contents of the DHCP messages will give a clue what's going on

rjb commented on 02.02.2020 21:18

Hi Hans

Thanks for your reply.
Yes, please see attached files: One shows the successful DHCP for an Android phone (tcpdump_dhcp_working), the other shows the DHCP for the printer (tcpdump_dhcp_printer).

It looks like the printer doesn't understand the OFFER packet, as it won't answer with the REQUEST packet?
Unfortunately I don't have a tcpdump of OpenWRT 18.06 (where the printer was working), but I guess soemthing must have been different.
With -vvv I spotted the "bad udp cksum 0x84ab → 0xfda5!" within the OFFER packet - could this be a problem for the printer?

Project Manager
Hans Dedecker commented on 03.02.2020 20:44

I'm afraid if we cannot compare with a working DHCP exchange on OpenWrt 18.06 it will be hard to pinpoint the issue as the tcpdump traces don't show anything obvious wrong.

rjb commented on 16.02.2020 18:46

ok, will try to test it in about two weeks time.

rjb commented on 07.03.2020 19:37

Hi Hans

So I installed OpenWRT 18.06.8 from scratch, enabled WiFi and started tcpdump.
The results are in the attached files. Both the android device as well as the printer received an IP.

Next test will be with newly released 19.07.2.

rjb commented on 07.03.2020 19:59

Hello again,

I upgraded from 18.06.8 to 19.07.2 by keeping the settings and did the same tcpdump again.
And as in previous 19.07 versions, the printer won't get the IP.

Any ideas?

Project Manager
Hans Dedecker commented on 08.03.2020 20:44

Having checked the tcpdump traces I fail to understand why the printer does not get an IP with 19.07.02. DHCP wise everything looks fine as the DHCP offers are identical in both cases

rjb commented on 08.03.2020 21:39

Hi Hans

Do you have any advice how to further track down the issue?

Project Manager
Baptiste Jonglez commented on 09.03.2020 13:57

That might happen if the UDP checksum is wrong and the printer checks it.

In both your tcpdump traces, the UDP checksum is shown as wrong, but it's possible it gets "fixed" by the hardware on 18.06 but not on 19.07

Project Manager
Baptiste Jonglez commented on 09.03.2020 13:59

To be sure, you can try sniffing the packets over the air, or more simply capture the DHCP responses that you receive on another host also connected to 2.4 GHz wifi.

Project Manager
Hans Dedecker commented on 09.03.2020 14:48

The printed UDP checksum failure is not the root cause of the issue; I've seen this before with other DHCP exchanges and for the Android DHCP exchange this is similar.
If the printer can be connected wired to the device it would be interesting to see if the same issue is observed during the DHCP exchange

rjb commented on 14.03.2020 15:29

Hi Hans

By using the wired connection the printer actually receives the IP address as seen in attached tcpdump (OpenWRT 19.07.2 running).
Unfortunately I can't keep it connected like this except for testing.

Project Manager
Hans Dedecker commented on 18.03.2020 20:34


Thank you for the testing; we can with almost certainty assume the issue is not related to dnsmasq which acts as DHCP behavior.
I hope someone can chime in with more wireless knowledge than me as it seems the issue is rather related to wireless.

PsySc0rpi0n commented on 19.04.2020 23:04

Hello everyone.

I have a NetGear NighHawk X4S (R7800) with OpenWrt-19.07. No extra packages or anything out of the ordinary in terms of configurations.
I have an HP Deskjet 3070A and had the same issue. HP was getting a weird IP and the router was trying to assign a different (but internal ip) but the printer was not ACK'ing the DHCP from the router.

This HP does not supports 5Ghz wireless networks an while I was discussing with one other OpenWrt user how to overcome this, he suggested to change something in the Wireless security settings, just for the sake of it.

So I changed the cipher mode from 'auto' to TKIP and after this the printer accepted the IP the router was trying to assign to it and I was able to connect it to my router wireless. Printer is now working normally.

Seems to be just a workaround as probably this is something that can be fixed and changed back to the default cipher mode.

rjb commented on 20.04.2020 17:57


I can confirm this behavior. Only the TKIP setting will work. Auto, CCMP and TKIP+CCMP will fail.
Since TKIP is considered insecure, this is no option for me (my workaround for the moment is to use an USB stick to print from or scan to).

I'm pretty sure this had been working in 18.06 in the auto setting that has defaulted to CCMP, too.

Timmo Verlaan commented on 04.12.2020 20:33


I have a TP-link Archer C7 with openwrt 19.07.04 and I can confirm the same issue and the same resolution. Setting it to TKIP immediately solved my connection issues with the printer. When using 'auto' the syslog shows DISCOVER/OFFER and then BOOTP messages, and when using TKIP I see the normal DISCOVER/OFFER/REQUEST/REPLY.

Example BOOTP message: dnsmasq-dhcp[]: BOOTP(<lan>) <MAC> no address configured

Is there anything else I can do to help solve the bug?

albrecht commented on 22.12.2020 18:37

Same issue here. This shouldn't be related to DHCP as I am not even using OpenWrt's DHCP server, the "router" in question is set up as a dumb AP bridged to the wired network. If I connect the printer to another non-OpenWrt AP on the same network it works fine.
Switching to the insecure TKIP fixes the problem for me as well. The affected printer is an HP B110a, 10 years old.


Available keyboard shortcuts


Task Details

Task Editing