Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#673 - DHCP not working for some devices #5670

Closed
openwrt-bot opened this issue Apr 2, 2017 · 9 comments
Closed

FS#673 - DHCP not working for some devices #5670

openwrt-bot opened this issue Apr 2, 2017 · 9 comments
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Apr 2, 2017

mgondium:

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...

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Apr 4, 2017

dedeckeh:

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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Apr 6, 2017

mgondium:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Apr 6, 2017

dedeckeh:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Apr 6, 2017

mgondium:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Apr 16, 2017

tfiga:

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?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Apr 17, 2017

dedeckeh:

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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Apr 30, 2017

mgondium:

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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented May 1, 2017

dedeckeh:

A PR has been opened (lede-project/source#1079) to update dnsmasq to 2.77 test5

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented May 3, 2017

mgondium:

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant