[PROBLEM] Running Moode seems to break my LAN...

[TheOldPresbyope]

Thanks for the tips.

As my granddaughter would say, what the heck is that all about? What OS is that "another" pi running, what/where is the NFS server involved, what are those scripts doing, and what else is it doing.

In effort to change one thing at a time I have moved the scripts to run locally off the moode Pi and monitor if that makes a difference. Then I'll look into the address mapping in the mesh as suggested. To answer your question, I'm running https://github.com/antiprism/mpd_oled

However, is there a downside to running scripts off another Pi that is connected via NFS?

I don't understand what "connected via NFS" means in this context since NFS = Network File Sharing.

An easy first test would have been simply to stop using the scripts and oled display and see if the network still "breaks" but since you've already moved them to the moOde player, that will suffice.

I agree with others that mesh networks can be tricky---I'm running my whole house off an eero mesh---but they are still a form of LAN. You mentioned several characteristics of your issue:

1. "Internet access would stop working". 

What does this mean? Does it literally mean packets can't flow between IP addresses on your LAN and IP addresses on the Internet or perhaps only that hosts on your LAN can't resolve fully qualified domain names (FQDN) to IP addresses on the Internet? The first would mean Internetwork routing is failing. The second that global DNS name resolution is failing.

* Here's a simple test on my moOde player that tests routing. I pinged the Google DNS server (being kind and hitting it only once) by its published IP address and received a proper response.

Code:

pi@720TR2:~ $ ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=35.4 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 35.374/35.374/35.374/0.000 ms

You could get more baroque and run traceroute but the ping will suffice for now. (if you run traceroute, the first line of the trace should be your local router, whatever it is.)

Assuming the first ping test succeeds, you can use ping again to check that DNS name resolution is working on your LAN

Code:

pi@720TR2:~ $ ping -c1 dns.google.com
PING dns.google.com (8.8.8.8) 56(84) bytes of data.
64 bytes from dns.google (8.8.8.8): icmp_seq=1 ttl=116 time=27.1 ms

--- dns.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.077/27.077/27.077/0.000 ms

2. "many of my devices would fail to get a local IP". This suggests local DHCP service is failing. What is providing this service on your LAN? Is there any possibility there are two DHCP servers fighting to be primary? (example---DHCP on a router and dnsmasq on a host.) Is there any possibility some rogue host is jamming DHCP service (whence the packet sniffing exercise I mentioned before).

As an aside, IP conflict has been mentioned by you and implied by others. Generally, this would not cause the above problems. One could examine the logs on the router. There should be a table of "Attached Devices" or "Connected Devices" or similar which lists devices by name, MAC address, IP address. Look for devices with different MAC addresses and duplicate IP addresses. If you find some, fix same.

As another aside, in common parlance, "hub" means a low-level network device which is very unlikely to cause the problems you report unless it is defective (example, by continuously forwarding a jam signal.)

This is all

Sorry, I hit the post instead of preview button.

This is all getting far afield from moOde.

Regards,
Kent