[mythtv-users] HDHR failing

[Stephen Worthington]

On Sat, 14 Nov 2020 16:43:25 -0700, you wrote:

>On Fri, Nov 13, 2020 at 7:55 PM Stephen Worthington <
>stephen_agent at jsw.gen.nz> wrote:
>
>>
>> and then run this command:
>>
>> sudo tshark -tad -P -w eth0.pcap -i eth0 ether host <MAC address of
>> HDHR>
>>
>> Adjust the "eth0" bits to the name of your Ethernet port if necessary.
>> Ping the HDHR again and check that tshark shows the ping.
>>
>> Then restart mythbackend and tshark should see all the traffic it does
>> with the HDHR (if any).  That will also be stored to the eth0.pcap
>> file which can be loaded into Wireshark on any PC that has it
>> installed.  You can also make it available for us to look at if you
>> need help with working out what is going on.
>>
>
>tshark returns the following after reboot.  I do need help working out
>what's going on:
>   11 5.004453703 Silicond_06:68:bf ? Giga-Byt_21:c1:0c ARP 60 Who has
>192.168.1.200? Tell 192.168.1.42
>   12 5.004462014 Giga-Byt_21:c1:0c ? Silicond_06:68:bf ARP 42
>192.168.1.200 is at 00:24:1d:21:c1:0c
>   13 5.178415918 Giga-Byt_21:c1:0c ? Silicond_06:68:bf ARP 42 Who has
>192.168.1.42? Tell 192.168.1.200
>   14 5.178635208 Silicond_06:68:bf ? Giga-Byt_21:c1:0c ARP 60 192.168.1.42
>is at 00:18:dd:06:68:bf
>
>Since this capture continued after a reboot, I assume I need to stop it.
>How do I do so?

Control-C stops tshark, and most command line programs.

The log posted probably does not show the start of the Ethernet
traffic, as the first packet you posted (packet 11) is an ARP request
broadcast from the HDHR trying to find the MythTV box's IP address.
That is unexpected - it suggests that the HDHR was talking to the
MythTV box not long ago and lost the connection and is trying to
re-establish it.  But as I understand things, it is the MythTV box
that connects to the HDHR, not the other way around, and I would have
expected the MythTV box to be trying to find the HDHR.  Packet 12 is
the ARP reply from the MythTV box (using a Gigabyte motherboard
Ethernet port, from the MAC address).

Then we get two packets more like I would have expected, where the
MythTV box does an ARP request to find the HDHR's IP address in packet
13, and gets a reply in packet 14.  Except packet 11 has already
provided that IP address, and packet 13 has the MAC address of the
HDHR in it, rather than being a broadcast packet with an all FF MAC
address that tshark would not have captured.

If there was no more traffic captured after that, then what was
captured does not really help.  We can see that the MythTV box and the
HDHR both know each other's IP addresses and should therefore be able
to talk to each other, but that is about all.  There is nothing to
explain why they are not talking to each other.