[mythtv-users] HDHR failing

Stephen Worthington stephen_agent at jsw.gen.nz
Sun Nov 15 05:10:45 UTC 2020


On Sat, 14 Nov 2020 20:37:47 -0700, you wrote:

>On Sat, Nov 14, 2020, 8:20 PM Stephen Worthington <stephen_agent at jsw.gen.nz>
>wrote:
>
>> 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.
>>
>
>I guess what I'm asking is this.  Issuing the tshark command seems to have
>initiated a process that restarts after reboot.  Otherwise I could not have
>seen the boot-up traffic.  Don't I now need to cancel the restart going
>forward? I don't want to sniff every packet from now on.  Or does it maybe
>only restart once?

No, tshark does not restart on reboot.  There is no background
process, just tshark.  It will only capture traffic while it is
running.  The traffic it captured looks to have been from mythbackend,
but it will have been current traffic, not from boot time.


More information about the mythtv-users mailing list