[Closed but Unresolved] Locate Device on Network?

I've installed a ethernet cable based TV tuner (for USA it's ATSC). There are but 3 inputs to the tuner, the tv signal, power and an ethernet cable. That cable, connects (through unmanaged switches) to the router. On powering up the tuner, it boots and obtains an IP address but isn't found on my network.

What devices nmap shows are:

``Starting Nmap 7.60 ( https://nmap.org ) at 2019-08-03 09:24 PDT
Nmap scan report for OpenWrt.lan (192.168.1.1)
Host is up (0.00026s latency).
MAC Address: 18:D6:C7:24:82:B5 (Tp-link Technologies)
Nmap scan report for 192.168.1.184
Host is up (0.010s latency).
MAC Address: 6C:33:A9:13:D1:12 (Magicjack LP)
Nmap scan report for Lexington.lan (192.168.1.185)
Host is up.
Nmap done: 256 IP addresses (3 hosts up) scanned in 4.14 seconds

The makers [Troubleshooting](https://www.silicondust.com/support/troubleshooting/#no-tuners-found) guide reads:

"If the network LED is solid green, then the HDHomeRun has an address.

If you are on a wired connection and it is still not discovered,
if you have the PC configured to use a static IP address, check
to make sure that the subnet mask entered exactly matches what
the router is assigning via DHCP. Any mismatch, no matter how
small, can prevent discovery of the device from working."

In email correspondence with Tech Support at SiliconDust, the maker of the tuner, they suggest setting a static IP address for it. Also in the LuCI menus, where are the "allowed devices"? I've looked. 

Thank you.

To be certain that the router issues IP addresses to devices, I have cold booted the router. This is the 3rd device that SiliconDust (the manufacturer) has sent me. I bought this model "refurbished". The first unit was found and worked without flaw for months but died. It was under warranty to another device was sent. It too could not be found on the network, and now this 3rd one, delivered to me yesterday also can't be found.

Use a crossover cable. Connect the TV tuner directly to your PC. Eliminate the rest of your network first.

Use nmap to scan for open ports on this IP address.

mark@Lexington:~$ sudo nmap -sn 192.168.1.1/24
[sudo] password for mark: 

Starting Nmap 7.60 ( https://nmap.org ) at 2019-08-03 09:52 PDT
Nmap scan report for OpenWrt.lan (192.168.1.1)
Host is up (0.00028s latency).
MAC Address: 18:D6:C7:24:82:B5 (Tp-link Technologies)
Nmap scan report for Lexington.lan (192.168.1.185)
Host is up.
Nmap done: 256 IP addresses (2 hosts up) scanned in 3.77 seconds

That's a great idea. I'll have to buy that. Will a crossover adapter serve the same?

As long as the end result is that the PC NIC and tuner NIC can communicate, it doesn't really matter. Many NICs these days support auto-MDIX; you might find that a regular network cable is sufficient.

By the way, nmap -sn doesn't do a port scan. You might find nmap --help to be of use.

Please bear with my ignorance of network engineering. With a non-crossover cable, and the tuner plugged into the computer directly:

mark@Lexington:~$ ifconfig
enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::aa22:a142:b7d3:61d3  prefixlen 64  scopeid 0x20<link>
        ether 4c:cc:6a:63:b1:bf  txqueuelen 1000  (Ethernet)
        RX packets 45497  bytes 39690797 (39.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 39997  bytes 7094604 (7.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 9059  bytes 802752 (802.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9059  bytes 802752 (802.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

That looks normal.

  • What does tcpdump show?
  • What does tcpdump show if you restart the TV tuner?
  • What does tcpdump show if you forcibly reset the TV tuner to factory defaults?
  • Does anything (including tcpdump or even arp) help to identify what IP address the tuner might be configured with?

Connecting the tuner directly to the PC won't do much because the PC is not a DHCP server. Connect them both to your OpenWrt router's LAN network and use DHCP configuration on both.

The tuner should be findable at tunerhostname.lan where tunerhostname is configured in the tuner.

Examine the "DHCP Leases" section of the OpenWrt main status page on the web or use cat /tmp/dhcp.leases from the CLI. If you see the tuner's MAC address and its IP address but no hostname either there is no hostname set in the tuner, or it has the same hostname conflicting with some other device.

2 Likes

I know that unmanaged switch(es) shouldn't matter, but did you try connecting the tuner directly to the router?

Correct. Unless it's possible to set a static IP for the tuner. But then again, if it's designed to work over the network then that should be the aim.

1 Like

No hostname and no MAC, either.

root@OpenWrt:~# cat /tmp/dhcp.leases
1564894942 4c:cc:6a:63:b1:bf 192.168.1.185 Lexington *
1564894679 6c:33:a9:13:d1:12 192.168.1.184 * *
1564888935 b4:f1:da:e7:88:40 192.168.1.220 android-5a6cf260431007f 01:b4:f1:da:e7:88:40
1564895448 20:d1:60:4a:54:74 192.168.1.149 android-97e811c0dff70d6c 01:20:d1:60:4a:54:74
1564854319 00:26:82:7f:1e:31 192.168.1.188 clamour 01:00:26:82:7f:1e:31

Correct, and it doesn't need to be, not for the purpose of this exercise.

tcpdump and arp are sufficient to identify a potential DHCP client, even if the connected computer isn't a DHCP server. In addition, even if the questionable device is configured with a static address, there is a chance that it might attempt to beacon for NTP, or DNS, or another useful service, which might give the OP a clue about what IP address the device has.

The OP's original assertion is that "it boots and obtains an IP address but isn't found on my network.", and the OP cites the manufacturer's troubleshooting information which says, "If the network LED is solid green, then the HDHomeRun has an address."

The OP is therefore relying on the LED state to deduce that the device has an IP address, but is unable to determine what that IP address is. The manufacturer's documentation merely notes that a solid green LED indicates that an IP address is assigned, but carefully does not indicate whether that IP address is static or dynamic.

If the tuner had picked up an IP address via DHCP, the OP would have found the address already in the DHCP server's lease table.

So if the tuner is configured to use DHCP, a direct connection with tcpdump or arp running should be sufficient to identify it and provide a useful starting point for further troubleshooting. If the tuner is configured to use a static IP address, a direct connection with tcpdump or arp running might - depending on the tuner's IP configuration - reveal the static IP address.

Do any of those MAC addresses match the label on the tuner?

If the device is on the network but it is not receiving a DHCP address it is probably not configured as a DHCP client. (Or the network is broken by having two DHCP servers contending with each other)

No.

The label on the tuner says: MAC: 00:18:DD:04:EE:EB

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?

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.

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

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.

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