<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 14, 2020, 8:20 PM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, 14 Nov 2020 16:43:25 -0700, you wrote:<br>
<br>
>On Fri, Nov 13, 2020 at 7:55 PM Stephen Worthington <<br>
><a href="mailto:stephen_agent@jsw.gen.nz" target="_blank" rel="noreferrer">stephen_agent@jsw.gen.nz</a>> wrote:<br>
><br>
>><br>
>> and then run this command:<br>
>><br>
>> sudo tshark -tad -P -w eth0.pcap -i eth0 ether host <MAC address of<br>
>> HDHR><br>
>><br>
>> Adjust the "eth0" bits to the name of your Ethernet port if necessary.<br>
>> Ping the HDHR again and check that tshark shows the ping.<br>
>><br>
>> Then restart mythbackend and tshark should see all the traffic it does<br>
>> with the HDHR (if any).  That will also be stored to the eth0.pcap<br>
>> file which can be loaded into Wireshark on any PC that has it<br>
>> installed.  You can also make it available for us to look at if you<br>
>> need help with working out what is going on.<br>
>><br>
><br>
>tshark returns the following after reboot.  I do need help working out<br>
>what's going on:<br>
>   11 5.004453703 Silicond_06:68:bf ? Giga-Byt_21:c1:0c ARP 60 Who has<br>
>192.168.1.200? Tell 192.168.1.42<br>
>   12 5.004462014 Giga-Byt_21:c1:0c ? Silicond_06:68:bf ARP 42<br>
>192.168.1.200 is at 00:24:1d:21:c1:0c<br>
>   13 5.178415918 Giga-Byt_21:c1:0c ? Silicond_06:68:bf ARP 42 Who has<br>
>192.168.1.42? Tell 192.168.1.200<br>
>   14 5.178635208 Silicond_06:68:bf ? Giga-Byt_21:c1:0c ARP 60 192.168.1.42<br>
>is at 00:18:dd:06:68:bf<br>
><br>
>Since this capture continued after a reboot, I assume I need to stop it.<br>
>How do I do so?<br>
<br>
Control-C stops tshark, and most command line programs.<br>
<br>
The log posted probably does not show the start of the Ethernet<br>
traffic, as the first packet you posted (packet 11) is an ARP request<br>
broadcast from the HDHR trying to find the MythTV box's IP address.<br>
That is unexpected - it suggests that the HDHR was talking to the<br>
MythTV box not long ago and lost the connection and is trying to<br>
re-establish it.  But as I understand things, it is the MythTV box<br>
that connects to the HDHR, not the other way around, and I would have<br>
expected the MythTV box to be trying to find the HDHR.  Packet 12 is<br>
the ARP reply from the MythTV box (using a Gigabyte motherboard<br>
Ethernet port, from the MAC address).<br>
<br>
Then we get two packets more like I would have expected, where the<br>
MythTV box does an ARP request to find the HDHR's IP address in packet<br>
13, and gets a reply in packet 14.  Except packet 11 has already<br>
provided that IP address, and packet 13 has the MAC address of the<br>
HDHR in it, rather than being a broadcast packet with an all FF MAC<br>
address that tshark would not have captured.<br>
<br>
If there was no more traffic captured after that, then what was<br>
captured does not really help.  We can see that the MythTV box and the<br>
HDHR both know each other's IP addresses and should therefore be able<br>
to talk to each other, but that is about all.  There is nothing to<br>
explain why they are not talking to each other.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>