Certain devices ignore DHCPOFFER

Ah, I now understand what you were getting at with the "option 6" question earlier.

Good suggestion, I've tried with two DNS server and then also just one, and even removing the option 6 override completely, but the HDHomerun still doesn't take an IP address.

Going back to @trendy's comment above, I think this is more on point. My output from tcpdump above shows the requests from HDHomerun, and it shows requests-from and replies-to other hosts on the network, but it doesn't show any reply from OpenWRT to HDHomerun. The DHCPOffer is logged in the dnsmasq log, but the message doesn't appear in the tcpdump.

Doesn't this suggest the issue is internal to OpenWrt / dnsmasq?
Edit: or perhaps something blocking it in iptables?

iptables -t raw -j TRACE -m udp -s udp --dport 67:68

what's this...

##################################### Issue
In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 348:
10.214.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Repl

either way... i'm leaning toward the same conclusion... re: packets not leaving the router... if you can get a command similar to the iptables raw above... ( you might need some opkg mod action )... it might shed some light on that....

but it raises the question... what non-standard services if any are you running?... and if you haven't already... explain in detail how exactly each interface is configured?

Also, long-shot.... working devices seem to be passing;

Vendor-Class Option

non-working ones are not...?

1 Like

Thanks again for your time on this. You're right, I missed that response.

Anyway, next step for me is to go back to factory settings (I have two identical OpenWrt devices so can do this on the test bench) and start adding my mods in one by one until the HDHomerun starts showing this behaviour.

It's a job for this evening, so I'll report back later.

By the way. I'm not very good at iptables commands - I blindly copy/pasted your cmd and got an error "no command specified"

Updated to add (since I am unable, as a new user, to post any more replies for the next 14 hours!)...

Here's what I have learned this afternoon about tracing iptables:

# install preqiusites
opkg install kmod-ipt-raw iptables-mod-trace

# Set-up tracing
iptables -t raw -A OUTPUT -p udp --dport 68 -j TRACE

# ... read the logs

# output the rules for comparison with logs
iptables -L -n -v --line-numbers

# Afterwards, tidy up the rule
iptables -t raw -D OUTPUT -p udp --dport 68 -j TRACE

The outputs from the above are somewhat verbose... and quite specific to my implementation. But skipping to the end a bit, the above analysis led me to a Google search that found this:

Certainly, it looks plausible that there's an mwan3 rule that might be affecting or filtering the broadcast DHCPOFFER for the hdhomerun/squeezebox. Leads to two lines of enquiry:

  1. Why is dnsmasq sending broadcast DHCPOFFER for hdhomerun and squeezebox? It sends DHCPOFFER for other clients as unicast. Can this behaviour be changed?
  2. Can I work out what to change in my mwan3 config to take away the lo rule that's possibly affecting the dhcpoffer broadcast? The link above fizzles out before reaching a conclusion...

My quest continues!

1 Like

This is the correct way to send a DHCPOFFER. Remember that the host still doesn't have an IP address, so sending to 255.255.255.255 is correct. The host MAC address is used as "Client-Ethernet-Address" to identify the correct host that this OFFER is destined to. Other hosts are just renewing their lease, so they send a unicast REQUEST and server responds with ACK.

Since you have the test unit, I suggest you start with bare minimum configuration and verify everything works before adding new packages. I believe even more now that there seems to be some problem in the mac-address-table sending the packet to the wrong interface.

1 Like

There seems to be a subtlety to DHCP offers that your response misses... and I think this is at the very core of the issue that I am experiencing. Some of my devices send their REQUEST in a way that solicits a unicast OFFER. Others send a REQUEST that solicits a broadcast OFFER. At least, that's how I read this, from stackexchange: https://networkengineering.stackexchange.com/a/16954

Anyway, as per plan, I went back to factory settings on my 'spare' unit, and confirmed that there is no issue for HDHomerun and Squeezebox devices IP address allocation by DHCP 'out of the box'.

Next, because I already had my suspicions, I installed MWAN3

opkg update && opkg install mwan3
reboot

After reboot, the HDHomerun and Squeezebox devices could not get IP addresses, and everything else could.

I went back to the issue report I found in github and asked there. I turns out the solution had been staring me in the face - a small change to mwan3 config (set local_source to none) and this changes the iptables rules, allowing the DHCPOFFER broadcasts out.

Thanks again to everyone for their assistance troubleshooting this issue for me. Really appreciated.

4 Likes

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