[mythtv-users] Network issues (slightly OT)

Steve Greene sgreene820 at gmail.com
Mon Mar 18 16:45:57 UTC 2024

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 Greene
(301) 842-8923
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/03f5631c/attachment.htm>

More information about the mythtv-users mailing list