Mailing List Archive

> On Mar 6, 2024, at 10:34?AM, Steve Greene <sgreene820@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?
>

I think your ip addresses have changed since you changed routers. The router typically hands out ip addresses, and you may have changed to 192.168.0.NNN from 192.168.1.NNN, or something similar.



_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

I have static ip addresses configured, also ping to the master backend
address doesn't work, so the issue is more than just the backend.

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


On Wed, Mar 6, 2024 at 12:27?PM Jay Harbeston <jharbestonus@gmail.com>
wrote:

>
>
> > On Mar 6, 2024, at 10:34?AM, Steve Greene <sgreene820@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?
> >
>
> I think your ip addresses have changed since you changed routers. The
> router typically hands out ip addresses, and you may have changed to
> 192.168.0.NNN from 192.168.1.NNN, or something similar.
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

On Wed, Mar 6, 2024, 11:34?AM Steve Greene <sgreene820@gmail.com> wrote:

> I have static ip addresses configured, also ping to the master backend
> address doesn't work, so the issue is more than just the backend.
>
> Steve Greene
> (301) 842-8923
> historicity.co
> An independent archival professional specializing in still photography,
> moving images and recorded sound.
>
>
> On Wed, Mar 6, 2024 at 12:27?PM Jay Harbeston <jharbestonus@gmail.com>
> wrote:
>
>>
>>
>> > On Mar 6, 2024, at 10:34?AM, Steve Greene <sgreene820@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?
>> >
>>
>> I think your ip addresses have changed since you changed routers. The
>> router typically hands out ip addresses, and you may have changed to
>> 192.168.0.NNN from 192.168.1.NNN, or something similar.
>
>
Thats all layer 2 as long as long as the submet mask is correct, all arp
based traffic. Double check the subnet masks and ensure that is correct,
traffic should not go to the router if on same subnet.

>
>>

On 06/03/2024 17:32, Steve Greene wrote:
> On Wed, Mar 6, 2024 at 12:27?PM Jay Harbeston <jharbestonus@gmail.com>
> wrote:
>
>>
>>
>>> On Mar 6, 2024, at 10:34?AM, Steve Greene <sgreene820@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?
>>>
>>
>> I think your ip addresses have changed since you changed routers. The
>> router typically hands out ip addresses, and you may have changed to
>> 192.168.0.NNN from 192.168.1.NNN, or something similar.
>>
>>
> (fixed top-posting)
> I have static ip addresses configured, also ping to the master backend
> address doesn't work, so the issue is more than just the backend.
>
Yeah, but that doesn't work if your /router/ is configuring itself to a different subnet. Whatever
you plug into it won't pass if it has any other subnet than what the router wnats.

--

Mike Perkins


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

The subnet range used is 192.168.1.xxx. The router definitely sees the
workstation and uses my assigned IP address. I have set the netmask to
255.255.255.0, but when I review the entries, it goes to "24". Possibly
need to change it in /etc/network/interfaces.

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


On Wed, Mar 6, 2024 at 12:45?PM Mike Perkins <mikep@randomtraveller.org.uk>
wrote:

> On 06/03/2024 17:32, Steve Greene wrote:
> > On Wed, Mar 6, 2024 at 12:27?PM Jay Harbeston <jharbestonus@gmail.com>
> > wrote:
> >
> >>
> >>
> >>> On Mar 6, 2024, at 10:34?AM, Steve Greene <sgreene820@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?
> >>>
> >>
> >> I think your ip addresses have changed since you changed routers. The
> >> router typically hands out ip addresses, and you may have changed to
> >> 192.168.0.NNN from 192.168.1.NNN, or something similar.
> >>
> >>
> > (fixed top-posting)
> > I have static ip addresses configured, also ping to the master backend
> > address doesn't work, so the issue is more than just the backend.
> >
> Yeah, but that doesn't work if your /router/ is configuring itself to a
> different subnet. Whatever
> you plug into it won't pass if it has any other subnet than what the
> router wnats.
>
> --
>
> Mike Perkins
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

On 3/6/24 12:57 PM, Steve Greene wrote:
> the entries, it goes to "24". Possibly need to change it in
> /etc/network/interfaces.

A /24 would be correct.

Doug

> On Mar 6, 2024, at 1:06?PM, Doug Lytle via mythtv-users <mythtv-users@mythtv.org> wrote:
>
> On 3/6/24 12:57 PM, Steve Greene wrote:
>> the entries, it goes to "24". Possibly need to change it in /etc/network/interfaces.
>
> A /24 would be correct.
>

There is something misconfigured in your network, either ip address / network stuff… OR….
Maybe there is a wiring issue if all is correct regarding ip addresses / network?

So can your mythtv server access the router? Can it ping google.com <http://google.com/>?

Can your client(s) ping the router? Can they ping the router… can they ping google.com <http://google.com/>?

maybe a guest network was set up inadvertently?

So many things it could be… requires methodical trouble shooting..

> On Mar 7, 2024, at 02:31, Jay Harbeston <jharbestonus@gmail.com> wrote:
>
>
>> On Mar 6, 2024, at 1:06?PM, Doug Lytle via mythtv-users <mythtv-users@mythtv.org> wrote:
>>
>> On 3/6/24 12:57 PM, Steve Greene wrote:
>>> the entries, it goes to "24". Possibly need to change it in /etc/network/interfaces.
>>
>> A /24 would be correct.
>>
>
> There is something misconfigured in your network, either ip address / network stuff… OR….
> Maybe there is a wiring issue if all is correct regarding ip addresses / network?
>
> So can your mythtv server access the router? Can it ping google.com?
>
> Can your client(s) ping the router? Can they ping the router… can they ping google.com?
>
> maybe a guest network was set up inadvertently?
>
> So many things it could be… requires methodical trouble shooting..

Indeed so many things …

You need a firewall because …

* You have a real ip
You already said you dont

* You have windows machines on your network
You dont want a compromised machine joining a bot-netwotk by calling OUT
Having a firewall does not protect you when you use eg a browser (ESTABLISHED/RELATED are allowed through the firewall)

* You run devices eg alexa eg doorbell camera without puttting them in a DMZ (aka a guest network)
How foolish! (and the firewall does not help you)

* Router firmware is broken

There may be other reasons, I don’t know about or did not think about

But in general you don’t need s firewall on your router, and various router firewalls do stupid things that will inhibit mythtv.
If you explicitly allow port forwarding to a machine the the firewall does nothing about those ports to that machine.

You don’t want a mis-configured network but routers will allow multiple networks/subnets
I do that when configuring another master mythtv - fine when backendA and frontendA are on one subnet backendB frontendB on another, messy routing when one frontend talks to both backends.

So first I would test without a firewall. If you have windows machines make sure they have their own firewall. I read honeypot tests show windows machines without fire wall being infected within 20 min.

James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, 6 Mar 2024 12:57:40 -0500, you wrote:

>The subnet range used is 192.168.1.xxx. The router definitely sees the
>workstation and uses my assigned IP address. I have set the netmask to
>255.255.255.0, but when I review the entries, it goes to "24". Possibly
>need to change it in /etc/network/interfaces.

/24 means 24 bits of mask, which is just another way of saying
255.255.255.0 (3 x 8 bits of mask 255 = 0xFF, so 24 bits of mask in
total).

Are you using a separate Ethernet switch, or just a switch built into
your router? Is your router set to use its builtin switch as a
switch, or is it using the ports as separate routeable subnet ports?
That is a feature available in good routers. What is the router?

In general, when traffic is going between addresses on the same subnet
(192.168.1.0/24 in your case), it should not be being processed by the
router, but just handled by the Ethernet switch hardware, a separate
part of the router box. A switch does not do any firewalling - it
only drops packets when the destination address can not be found on
any of the switch ports. Only if a packet has an address outside the
range of the subnet addresses should it be passed on to the router
section of your router box and processed by the firewall(s) and then
mapped against the routing table to see where to send it.

Also note that ping packets will only get a response from devices that
have ping responses enabled. Quite a lot of devices have ping
responses disabled by default. If the pings were working with your
old router, then they still should with the new router, but you may
simply have not ever needed to try pings with the old router as the
networking was working.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Thanks for the analysis. My router (G3100 Verizon FIOS) has a built-in 4
port switch. The slave backend is behind another 8 port dumb switch (I
needed to network a printer in the same room). DNS seems to work at the
backend workstation, I can ping google.com. I discovered an address
conflict with one of my numerous wifi devices and my slave backend, but
it's not the communications with the secondary backend that seems to be the
problem. I will note that I can't ping my primary backend from my laptop,
which can ping the slave. The slave can't ping the master. The difference
seems to be the slave is behind another switch. I've made some changes in
the IPV4 connection list on the router. I'm going to give it an hour or two
to update (home router).

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


On Wed, Mar 6, 2024 at 6:30?PM Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

> On Wed, 6 Mar 2024 12:57:40 -0500, you wrote:
>
> >The subnet range used is 192.168.1.xxx. The router definitely sees the
> >workstation and uses my assigned IP address. I have set the netmask to
> >255.255.255.0, but when I review the entries, it goes to "24". Possibly
> >need to change it in /etc/network/interfaces.
>
> /24 means 24 bits of mask, which is just another way of saying
> 255.255.255.0 (3 x 8 bits of mask 255 = 0xFF, so 24 bits of mask in
> total).
>
> Are you using a separate Ethernet switch, or just a switch built into
> your router? Is your router set to use its builtin switch as a
> switch, or is it using the ports as separate routeable subnet ports?
> That is a feature available in good routers. What is the router?
>
> In general, when traffic is going between addresses on the same subnet
> (192.168.1.0/24 in your case), it should not be being processed by the
> router, but just handled by the Ethernet switch hardware, a separate
> part of the router box. A switch does not do any firewalling - it
> only drops packets when the destination address can not be found on
> any of the switch ports. Only if a packet has an address outside the
> range of the subnet addresses should it be passed on to the router
> section of your router box and processed by the firewall(s) and then
> mapped against the routing table to see where to send it.
>
> Also note that ping packets will only get a response from devices that
> have ping responses enabled. Quite a lot of devices have ping
> responses disabled by default. If the pings were working with your
> old router, then they still should with the new router, but you may
> simply have not ever needed to try pings with the old router as the
> networking was working.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

On Thu, Mar 7, 2024 at 12:47?AM Steve Greene <sgreene820@gmail.com> wrote:
>
> Thanks for the analysis. My router (G3100 Verizon FIOS) has a built-in 4 port switch. The slave backend is behind another 8 port dumb switch (I needed to network a printer in the same room). DNS seems to work at the backend workstation, I can ping google.com. I discovered an address conflict with one of my numerous wifi devices and my slave backend, but it's not the communications with the secondary backend that seems to be the problem. I will note that I can't ping my primary backend from my laptop, which can ping the slave. The slave can't ping the master. The difference seems to be the slave is behind another switch. I've made some changes in the IPV4 connection list on the router. I'm going to give it an hour or two to update (home router).
>

Try turning off "Self Organizing Network" on the G3100.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, 6 Mar 2024 19:44:20 -0500, you wrote:

>Thanks for the analysis. My router (G3100 Verizon FIOS) has a built-in 4
>port switch. The slave backend is behind another 8 port dumb switch (I
>needed to network a printer in the same room). DNS seems to work at the
>backend workstation, I can ping google.com. I discovered an address
>conflict with one of my numerous wifi devices and my slave backend, but
>it's not the communications with the secondary backend that seems to be the
>problem. I will note that I can't ping my primary backend from my laptop,
>which can ping the slave. The slave can't ping the master. The difference
>seems to be the slave is behind another switch. I've made some changes in
>the IPV4 connection list on the router. I'm going to give it an hour or two
>to update (home router).

The simple thing to do would be to connect everything on your LAN to
the separate 8 port switch and see if they can talk to each other
then. That does not help with the WiFi devices, but it makes it easy
to see if the router LAN ports are doing something other than just
Ethernet switching between themselves.

It sounds like the change of router has also changed the subnet prefix
used for your internal network. That is always a problem as there are
places in various bits of configuration where you wind up having to
use an IP address which will then not be updated to the new subnet
unless you remember it and manually change it. This can cause all
sorts of network problems. Personally, I prefer to run my own
internal DNS servers and use DNS names instead of IP addresses, but
even then there are some configurations that do not permit the use of
DNS names. And running DNS servers is not a trivial thing either.

If the subnet prefix has changed, then you also need to reboot every
single device on your network so that they will get new IP addresses
in the correct range from the new router's DHCP server. And update
any static IP addresses, which you might have on server boxes like the
MythTV backends.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Steve Greene <sgreene820@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@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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@thehobsons.co.uk> wrote:

> Steve Greene <sgreene820@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@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

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@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@thehobsons.co.uk> wrote:
>
>> Steve Greene <sgreene820@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@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>>
>