[Closed but Unresolved] Locate Device on Network?

Installing and Using OpenWrt
16

AFAIK, this is a "stock" or unaltered since installation, OpenWrt SNAPSHOT r7066-060e1ecefa / LuCI Master (git-18.151.24607-5452cc2)

As other devices are found on this network, both cabled (ethernet) and wireless, I assume that the DHCP is automatically issuing IP addresses. As arp shows nothing, I now assume that the mfg.'s guide to "solid green has IP address", is more in the way of guidelines, not unlike Hector Barbossa telling Elizabeth Swann that the pirate rules are more like guidelines.

root@OpenWrt:~# arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.1.188    0x1         0x2         00:26:82:7f:1e:31     *        br-lan
192.168.1.185    0x1         0x2         4c:cc:6a:63:b1:bf     *        br-lan
192.168.1.150    0x1         0x0         70:5a:b6:68:c3:3d     *        br-lan
192.168.1.184    0x1         0x2         6c:33:a9:13:d1:12     *        br-lan
192.168.1.149    0x1         0x2         20:d1:60:4a:54:74     *        br-lan
192.168.1.220    0x1         0x2         b4:f1:da:e7:88:40     *        br-lan
104.35.224.1     0x1         0x2         00:01:5c:6e:56:46     *        eth0.2

What do I do next?

17

Prove it. Stick a sniffer (e.g., to pick a completely random and totally unexpected example out of thin air, tcpdump) directly on the tuner, to see what (if anything) it attempts to do by means of communication. Reset the tuner to factory defaults and see what communication it attempts while booting.

This is all part of the black art of troubleshooting. As a Linux user (your computer runs Linux and is called "Lexington"), you're automatically, intrinsically, and immediately good at troubleshooting. This is definitely within your skill set.

If the tuner is set up for DHCP, you'll be able to see the DHCP Discover packets and can then work out the next step of troubleshooting. If it's set up with a static address, you might be able to identify what that static address is, depending on what communication the tuner attempts.

18

To do as you suggest, I must first say that there is no "factory default" setting on the device. It's all either hardware or firmware. It is either powered or not.
I'm going to disconnect the computer's ethernet cable. Connect the tuner via 'net cable, and see if I can, using the "Terminal", run arp again. The last time I ran tcpdump, the output never stopped and I had to CTRL-C to break away.

Back in 10 minutes. Thnx, @iplaywithtoys

19

That's how tcpdump works.

However, you can filter the output to narrow down the noise. Common filter examples include protocols, IP addresses, and port numbers. You can even filter by MAC address. (man tcpdump will provide further information.)

If your computer is connected directly to the tuner, and vice-versa, then there's unlikely to be a massive amount of noise; the output should be easy enough to follow.

20

So, there is no device found, if I am understanding this output.

mark@Lexington:~$ sudo tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp5s0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:28:17.463044 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:cc:6a:63:b1:bf (oui Unknown), length 300
11:28:17.527363 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:18:dd:04:ee:eb (oui Unknown), length 300
11:28:21.241597 IP6 Lexington.mdns > ff02::fb.mdns: 0 [9q] PTR (QM)? _nfs._tcp.local. PTR (QM)? _ipp._tcp.local. PTR (QM)? _ipps._tcp.local. PTR (QM)? _ftp._tcp.local. PTR (QM)? _webdav._tcp.local. PTR (QM)? _webdavs._tcp.local. PTR (QM)? _sftp-ssh._tcp.local. PTR (QM)? _smb._tcp.local. PTR (QM)? _afpovertcp._tcp.local. (141)
11:28:22.527540 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:18:dd:04:ee:eb (oui Unknown), length 300
11:28:35.234272 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
11:28:35.250285 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
11:28:35.266565 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:cc:6a:63:b1:bf (oui Unknown), length 300
11:28:35.734316 IP6 :: > ff02::1:ffd3:61d3: ICMP6, neighbor solicitation, who has Lexington, length 32
11:28:36.118319 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
11:28:36.758502 IP6 Lexington > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
11:28:36.770325 IP6 Lexington > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
11:28:36.998821 IP6 Lexington.mdns > ff02::fb.mdns: 0*- [0q] 2/0/0 (Cache flush) PTR Lexington.local., (Cache flush) AAAA fe80::aa22:a142:b7d3:61d3 (141)
11:28:37.014270 IP6 Lexington > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
^C
13 packets captured
13 packets received by filter
0 packets dropped by kernel
21

Ding ding ding, we have a winner.

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

1 Like
22

@iplaywithtoys

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

23

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.

24

I get no IP, or DORP info as I read what you wrote, above.

root@OpenWrt:~# tcpdump -v -n port 68
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
2 packets received by filter
0 packets dropped by kernel

and

root@OpenWrt:~# tcpdump -i eth0 -vvv -s 1500 '((port 68) and (udp[38:4] = 0x3e0c
cf08))'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
^C
0 packets captured
1 packet received by filter
0 packets dropped by kernel
25

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:

  1. The TV tuner does try to behave as a DHCP client (you saw the BOOTP packets coming from the tuner's MAC address)
  2. 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.

26

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.

27

@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?

28

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 found arp-scan. It is easier to use for noobs.

mark@Lexington:/$ sudo arp-scan 192.168.1.0/24
Interface: enp5s0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.1.1	18:d6:c7:24:82:b5	(Unknown)
192.168.1.184	6c:33:a9:13:d1:12	Magicjack LP
192.168.1.220	b4:f1:da:e7:88:40	(Unknown)
192.168.1.129	28:56:5a:40:9a:8d	(Unknown)
29

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.

Perhaps some hints in https://www.silicondust.com/hdhomerun/hdhomerun_development.pdf

30

@iplaywithtoys -- I'm back at it. Even the 4th tuner is not properly networking (solid green and channel discovery working).

root@Lexington:/home/mark# fping -c 1 -g 192.168.1.0/24 && arp -n | grep "00:18:dd:04:ee:eb"

192.168.1.1 : [0], 84 bytes, 0.31 ms (0.31 avg, 0% loss)
192.168.1.184 : [0], 84 bytes, 1.32 ms (1.32 avg, 0% loss)
192.168.1.185 : [0], 84 bytes, 0.03 ms (0.03 avg, 0% loss)
192.168.1.149 : [0], 84 bytes, 406 ms (406 avg, 0% loss)
192.168.1.215 : [0], 84 bytes, 528 ms (528 avg, 0% loss)

Then fping from 192.168.1.185 (this computer) tried to ping to the address range: 192.168.1.0 to .254.

The five that returned a ping are

192.168.1.1 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 0.31/0.31/0.31
192.168.1.149 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 406/406/406
192.168.1.184 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 1.32/1.32/1.32
192.168.1.185 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 0.03/0.03/0.03
92.168.1.215 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 528/528/528

and I still cannot find the tuner's IP address.

31

@jeff -- As the Silicondust people have newer firmware I must have how long ago "in the day" was. By 2008, the devices are MDX-Auto.

32

What gives here?

root@OpenWrt:~# opkg install arp-scan
Installing arp-scan (1.9.5-1) to root...
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/packages/arp-scan_1.9.5-1_mips_24kc.ipk
Installing libpcap1 (1.9.0-2) to root...
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/base/libpcap1_1.9.0-2_mips_24kc.ipk
Collected errors:

  • check_data_file_clashes: Package libpcap1 wants to install file /usr/lib/libpcap.so.1
    But that file is already provided by package * libpcap
  • opkg_install_cmd: Cannot install package arp-scan.

I read on the net that arp-scan is available on OpenWRT around 2018. Did something change, or do I have a fault in my router's firmware?

33

Perhaps 8-10 years ago? I think it was the second-generation, ATSC devices.

34

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.

35

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