[mythtv-users] Network issues (slightly OT)

Steve Greene sgreene820 at gmail.com
Mon Mar 18 18:22:46 UTC 2024


FIXED!

Steps I took:
1) check /etc/hosts file for both backends and all frontends to make sure
they point to the same IP addresses
2) check that IP address for primary backend is setup correctly in
/home/myth/.mythtv/config.xml
3) check that bind-address is setup correctly in /etc/mysql
4) IPV6 settings for both backends should be set to AUTOMATIC (DHCP only),
THIS is probably what broke, I had it set to "AUTOMATIC"

Thanks to all for the advice.

Steve Greene
(301) 842-8923
historicity.co
An independent archival professional specializing in still photography,
moving images and recorded sound.


On Mon, Mar 18, 2024 at 12:45 PM Steve Greene <sgreene820 at gmail.com> wrote:

> Simon,
> My primary backend is on the same subnet as the slave. I just tried
> resetting the router, which I bought used. Regarding that passive switch
> that the slave is behind: I have a Raspberry Pi (running pihole) and a
> networked printer running off that same switch. I can ping the RPi and
> print. I have a dual boot setup for that primary that is inaccessible from
> the net. I can ping the Windows installation (different IP address, same
> hardware) successfully. This suggests that the problem is local to my
> Ubuntu setup and that the router and the switch aren't implicated.
>
> I guess the next thing to try is to revert the primary backend to DHCP and
> see if its accessible.
>
> Steve
>
>
>
>
>
> Steve Greene
> (301) 842-8923
> historicity.co
> An independent archival professional specializing in still photography,
> moving images and recorded sound.
>
>
> On Sat, Mar 9, 2024 at 2:19 PM Simon <linux at thehobsons.co.uk> wrote:
>
>> Steve Greene <sgreene820 at gmail.com> wrote:
>>
>> > I just upgraded my router and my backend is not accessible to my
>> frontends, neither can it be pinged from the local net. The workstation
>> itself accesses the internet just fine. I thought firewalls only affected
>> outward facing ports. Anyone dealt with something like this?
>>
>> OK, lets start with the basics :
>>
>>
>> Hardware check - have you got lights on all the devices where there
>> should be lights ? E.g. each network card should have a link status showing
>> it’s connected, and it may indicate (by colours or different lights) what
>> speed the link is running at. If anywhere there isn’t a light where there
>> should be, then investigate the cabling - try swapping ports & cables to
>> narrow it down to a specific cable or device. When you’ve done that, move
>> on to ...
>>
>>
>> On your devices (frontend, backend, space backend) run "ip address show"
>> and see what you get. You should see something like :
>> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>> group default qlen 1
>> >     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> >     inet 127.0.0.1/8 scope host lo
>> >        valid_lft forever preferred_lft forever
>> >     inet6 ::1/128 scope host
>> >        valid_lft forever preferred_lft forever
>> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
>> group default qlen 1000
>> >     link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
>> >     inet 192.168.nn.nn/24 brd 192.168.nn.255 scope global eth0
>> >        valid_lft forever preferred_lft forever
>>
>> The line "inet 192.168.nn.nn/24 brd 192.168.nn.255 scope global eth0"
>> against eth0 is the IPv4 address.
>> So the first check is : do all devices have the same subnet ?
>> Does the backend have the address you expect ?
>>
>> The do "ip route show”, which should return a couple of lines including
>> one like this :
>> > default via 192.168.nn.nn dev eth0 onlink
>>
>> Where the "via ..." should show the IPv4 address of the router, and it
>> should be in the same subnet.
>>
>>
>> Assuming that’s all OK, then your layer 3 should be OK. As suggested,
>> having changed the router, things may have changed.
>>
>>
>> Now lets have a look at layer 2.
>>
>> On the various machines, run "ip neigh show” ("arp -an" will show you the
>> same information, in a different format, but you need to be root to run
>> it), and you should get something like this :
>> > 192.168.nn.nn dev eth0 lladdr aa:aa:aa:aa:aa:aa STALE
>> > 192.168.nn.nn dev eth0 lladdr bb:bb:bb:bb:bb:bb REACHABLE
>> > 192.168.nn.nn dev eth0  FAILED
>>
>> This shows the neighbour tables, a.k.a. ARP table or ARP cache - i.e. the
>> neighbours the machine knows about. STALE means it’s not seen an ARP*
>> packet from it for a while, REACHABLE means it has seen a packet recently,
>> FAILED (or "<incomplete>" from arp) means it’s not been able to find the
>> layer 2 (MAC) address of the neighbour - typically because either the
>> device isn’t there or there’s a hardware problem stopping any packets
>> getting through. You may need to "ping 192.168.nn.nn" to trigger your
>> machine to do address resolution to find the hardware address for the
>> neighbour if it’s not already trying to send packets to it.
>> * ARP is address resolution protocol. It’s the means IPv4 devices use to
>> find the hardware address for a neighbour. So when you "ping 192.168.1.1"
>> and it’s not already in the neighbour table, your machine sends out an ARP
>> request "who has 192.168.1.1 ?" and if it’s there it will reply "I’m here"
>> and your machine can capture it’s hardware address and inseret it into the
>> neighbour table. Once it knows the hardware address, then it can build a
>> packet using the neighbours hardware address in the ethernet packet and
>> send it. If ping tells you "Destination Host Unreachable", that means the
>> arp process failed to find the neighbour, so there’s no entry in the
>> neighbour table, so it can’t reach the remote device.
>>
>>
>> At this point, you should know that your IP addressing is correct, and
>> know which machines can speak (at layer 2) to each other.
>> If you haven’t found the problem yet, start doodling ! Draw yourself a
>> diagram of what’s plugged into what - and maybe add lines showing the route
>> of a packet through the devices where you know it’s getting through. With
>> any luck, you’ll be able to see something like "the devices plugged into
>> this switch can see each other, the devices plugged into the router can see
>> each other, but nothing in the first group can see anything in the second
>> group” which would tell you that there is no traffic between the switch and
>> the router
>>
>>
>> Simon
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20240318/01056e7a/attachment.htm>


More information about the mythtv-users mailing list