[mythtv-users] Network issues (slightly OT)

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


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
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
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 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"
>> and it’s not already in the neighbour table, your machine sends out an ARP
>> request "who has ?" 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