OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by pmgp - 02.04.2017
Last edited by Hans Dedecker - 06.04.2017

FS#673 - DHCP not working for some devices

Somewhere between r3293 and r3901, DHCP stopped working for some network devices.
In my case, two same model printers are left in the dark, while all other devices work as usual. Manually setting IP on the printer makes it work again.

r3901:

Sat Apr  1 13:04:43 2017 daemon.info dnsmasq-dhcp[1558]: DHCPDISCOVER(br-lan) a4:ee:57:78:redacted
Sat Apr  1 13:04:43 2017 daemon.info dnsmasq-dhcp[1558]: DHCPOFFER(br-lan) 192.168.10.136 a4:ee:57:78:redacted
Sat Apr  1 13:04:46 2017 daemon.info dnsmasq-dhcp[1558]: DHCPDISCOVER(br-lan) a4:ee:57:78:redacted
Sat Apr  1 13:04:46 2017 daemon.info dnsmasq-dhcp[1558]: DHCPOFFER(br-lan) 192.168.10.136 a4:ee:57:78:redacted
Sat Apr  1 13:04:52 2017 daemon.info dnsmasq-dhcp[1558]: DHCPDISCOVER(br-lan) a4:ee:57:78:redacted
Sat Apr  1 13:04:52 2017 daemon.info dnsmasq-dhcp[1558]: DHCPOFFER(br-lan) 192.168.10.136 a4:ee:57:78:redacted
Sat Apr  1 13:04:58 2017 daemon.info dnsmasq-dhcp[1558]: DHCPDISCOVER(br-lan) a4:ee:57:78:redacted
Sat Apr  1 13:04:58 2017 daemon.info dnsmasq-dhcp[1558]: DHCPOFFER(br-lan) 192.168.10.136 a4:ee:57:78:redacted
Sat Apr  1 13:05:04 2017 daemon.info dnsmasq-dhcp[1558]: DHCPDISCOVER(br-lan) a4:ee:57:78:redacted
Sat Apr  1 13:05:04 2017 daemon.info dnsmasq-dhcp[1558]: DHCPOFFER(br-lan) 192.168.10.136 a4:ee:57:78:redacted

(No address is received.)

I’ve confirmed with different router devices including two TPLINK 710N (ar71xx) and one ARCHER C20i (mt7620).
Running r3293 makes all go back to normal.

r3293:

Sat Apr  1 12:56:21 2017 daemon.info dnsmasq-dhcp[1125]: DHCPDISCOVER(br-lan) a4:ee:57:78:redacted
Sat Apr  1 12:56:21 2017 daemon.info dnsmasq-dhcp[1125]: DHCPOFFER(br-lan) 192.168.30.136 a4:ee:57:78:redacted
Sat Apr  1 12:56:21 2017 daemon.info dnsmasq-dhcp[1125]: DHCPREQUEST(br-lan) 192.168.30.136 a4:ee:57:78:redacted
Sat Apr  1 12:56:21 2017 daemon.info dnsmasq-dhcp[1125]: DHCPACK(br-lan) 192.168.30.136 a4:ee:57:78:redacted

Were there changes to dnsmasq or the networking stack between these revisions?
This problem looks strangely familiar to a wrong VLAN, only no VLANs here...


Closed by  Hans Dedecker
06.04.2017 12:51
Reason for closing:  Different project
Project Manager
Hans Dedecker commented on 04.04.2017 11:05

It seems the affected devices don't send a DHCP request in response to the DHCP offer received from dnsmasq; sniffing the DHCP offer in a working and non working case by means of tcpdump will be helpfull to trouble shoot the problem.

pmgp commented on 06.04.2017 02:24

Dumps on DHCP and ARP for LEDE stable 17.01 (good) and trunk r3922 (printers get no dhcp address).

Project Manager
Hans Dedecker commented on 06.04.2017 08:41

The issue seems to be caused by support for support for client-ids (RFC6842) in DHCP replies which was recently added in dnsmasq (http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=88a77a78ad27adc3ed87b7ee603643d26cb896ee).
Not clear if the DHCP client has issues with a bigger DHCP packet size (300 bytes vs 306 byes) or the presence of the DHCP client identifier option.
This is an issue which needs to be reported to the upstream dnsmasq mailing list

pmgp commented on 06.04.2017 12:47

Just tested on Debian, and it fails with dnsmasq trunk.
I'll try to report on the mailing list.

Tomasz Figa commented on 16.04.2017 10:24

I'm also having this problem on a recent LEDE snapshot (LEDE Reboot SNAPSHOT r3962-7d4147d / LuCI Master (git-17.102.25694-4453414)) with my Toshiba Regza J9x TV. Migrating to odhcpd as the main DHCP server makes it work again.

By the way, shouldn't the broken version be temporarily downgraded in LEDE until upstream fixes the problem?

Project Manager
Hans Dedecker commented on 17.04.2017 20:09

Problem has been reported upstream to the dnsmasq mailing list (http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q2/011413.html); feel free to report your issue as well. At the moment Lede trunk uses dnsmasq version test4 which allows trunk users to report regression issues with the test version; downgrading will of course lower the test coverage for the test version 4.
Let's wait for a moment what happens upstream before making a decision to downgrade the current version in trunk.

pmgp commented on 30.04.2017 23:13

The original problem has been resolved with current dnsmask trunk (Dnsmasq version 2.77test5-1-gb2a9c57), what is the procedure to ask for a pull request?
Thanks.

Project Manager
Hans Dedecker commented on 01.05.2017 20:05

A PR has been opened (https://github.com/lede-project/source/pull/1079) to update dnsmasq to 2.77 test5

pmgp commented on 03.05.2017 00:48

Thank you!

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing