That's step one accomplished. You've proved that the tuner is a DHCP client, and it does attempt to acquire an IP address when it starts up.
Next step - why isn't it getting an IP address from OpenWRT? Is OpenWRT even receiving the DHCP Discover request in the first place?
What does tcpdump on OpenWRT reveal? Does it also show incoming DHCP Discover packets from the tuner? (Hint: if you run tcpdump on OpenWRT via SSH, without applying any filters, you'll drown in unhelpful information. Use man tcpdump to work out which filter(s) to apply so that you don't see unnecessary data.)
My eyes are starting to spin and I ask you to not do more for me. Or not much. As SiliconDust has yet another device of theirs in transit to me, maybe that 4th one will work. They are supposed to be networked, and using their software/app, you get TV on a device. The first one worked for 4-6 months without flaw. Now none (3 of 4) work, that way.
The best I could figure out is:
root@OpenWrt:~# tcpdump -v -c 4 arp | grep 00:18:DD:04:EE:EB
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
4 packets captured
137 packets received by filter
0 packets dropped by kernel
So... what changed? If it used to work, but now doesn't, what's different?
Either the device software has been changed, and now doesn't behave as expected, or something on your network has changed. If it's the former, all you can do is take it up with SiliconDust. If it's the latter, it's something within your power to fix.
So, OpenWRT received four packets from the tuner. That proves that traffic from the TV tuner can reach OpenWRT. That's another obstacle overcome. You're making progress!
If you want to filter only for DHCP packets, I would suggest this instead: tcpdump -nvi eth0 port 67 or port 68
Unless your network is particularly busy with renewing leases, that should be enough to catch the DHCP DORA sequence from the TV tuner without additional filters.
When DHCP works, you should see four separate transactions which make up the DORA sequence: Discover, Offer, Request, Acknowledge.
Discover: device comes online and says, "I want an IP address".
Offer: one or more DHCP servers respond and say, "Here, I've got an IP address for you."
Request: device says, "I'll take an IP address from you."
Acknowledge: DHCP server says, "Here you go. It's yours."
If you can see all four, then DHCP is working, and you should have the TV tuner's IP address at this point. If you can see fewer than four, then the full DHCP sequence did not complete.
Port 68 is used by the server to send the replies to the client. Port 67 is used by the client to send the request to the server. If you listen only on the respose port, you'll miss the incoming requests.
If you try again with "tcpdump -nvi eth0 'host ether 00:18:DD:04:EE:EB and (port 67 or port 68)'" you'll be able to see both sides of the transaction, if it occurs.
Alternately, just tcpdump -nvi eth0 host ether 00:18:DD:04:EE:EB on its own should show all traffic, if any, reaching OpenWRT from the TV tuner.
Your earlier tests proved the following:
The TV tuner does try to behave as a DHCP client (you saw the BOOTP packets coming from the tuner's MAC address)
Traffic from the tuner doesn't reach OpenWRT. My sincere apologies; I misread your earlier post. You filtered by MAC address in grep, not in tcpdump; there's a difference in how the two utilities behave. You caught 4 arp packets with tcpdump, but using grep to filter for the tuner's MAC address showed nothing; those 4 arp packets came from other sources.
So, the tuner can send DHCP Discover requests, but OpenWRT isn't receiving them. Something else on your network is intercepting the traffic from the TV tuner and preventing it from reaching OpenWRT. Still, your second tcpdump output above shows that you've become very proficient with tcpdump filters very quickly; I have every confidence that you'll crack the problem tonight.
Since your network is IPv4 only, make sure the IPv6 DHCP server is turned off in OpenWrt. That is not the default and can cause problems with a few clients that obtain only an IPv6 address then think that they are good even though there's really no IPv6 service.
If you have an extra router you can set up a test network with just the tuner, a router and your PC. This will reduce clutter on the monitors from other devices.
@mk24 -thnx. On the DHCP server page what do I do? Disable the Router Advertisement-Service or the DHCPv6-Service? Both? Something else? I'm too new at this to know what I'm doing. The iv6p service is used by 2 devices. One is this computer by which I communicate with this forum, so will disabling IP6V that prevent internet connection from this computer?
SiliconDust has sent another of the same model. Different MAC, but all else is literally the same. It too is not found and I can now firmly believe that this problem is not their devices, but something else.
Now I'm confused:
mark@Lexington:~$ sudo tcpdump -nvi eth0 'host ether 00:18:DD:04:EE:EB and (port 67 or port 68)'
tcpdump: eth0: No such device exists
(SIOCGIFHWADDR: No such device)
I had several of these running "in the day" and recall that they had a link-local discovery protocol that was troublesome in some way. As I recall, I resolved the situation by specifying a lease IP (by MAC) and used that IP directly in configuration of clients of the HDHomeRun boxes.
After 4 separate devices being installed/uninstalled along with associated firmware, software and apps, I was asked to use another router. I don't have one. And I'm unwilling to buy one to make their product work.
This topic is now closed. I issue this caveat emptor, watch your warranty on SiliconDust HDHomeRun products.