Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Problem: Running Moode seems to break my LAN...
#1
So it's quite likely this has nothing to do with moode! But posting it here for help.


This is tricky to explain. Over the last month or so I've had an intermittent issue on my home network where internet access would stop working and many of my devices would fail to get a local IP. 

After much trial and error I've narrowed it down to one raspberry pi running Moode

I discovered that if the network is down and I unplug the LAN connection from the raspberry pi it all magically works again, straight away. Very odd. 

So I want to figure out how to debug this further, is it a DNS issue? An IP conflict? What's challenging to figure this out is it only happens after a day or so, it's not an instant failure. But it IS an instant fix. What sort of investigation can I do to narrow down the cause?

Some extra context, I have a few scripts that are running (LCD display etc) that are on another pi. The python files are there linked via NFS. Not sure if that's a factor.
Reply
#2
1. You have not provided any info on HOW is your home network set up (plus devices, access points, repeaters, etc)
2. How is the 'problem' RPi connected to the home network (actual description)?
3. Have you tried to connect the 'problem' RPi differently (assign an IP address on the router, WiFi vs LAN, etc)?
4. Have you tried to change the OS on the 'problem' RPi (non-MoOde, MoOde)?
Reply
#3
(04-11-2021, 08:59 AM)CallMeMike Wrote: 1. You have not provided any info on HOW is your home network set up (plus devices, access points, repeaters, etc)
2. How is the 'problem' RPi connected to the home network (actual description)?
3. Have you tried to connect the 'problem' RPi differently (assign an IP address on the router, WiFi vs LAN, etc)?
4. Have you tried to change the OS on the 'problem' RPi (non-MoOde, MoOde)?

Good point.

1.

Modem ----(wired)--> Mesh Router (3x) ---(wireless)--> lots of devices
                                                         ----(wired)--> 8 port hub --(wired)--> PC
                                                                                              --(wired)--> PI (moode)

2.

Modem goes to mesh router, then to 8 port hub, then RPI

3. I've set the router to fix the address to a static IP, not much else. But the issue existed before i did that.

4. I have not
Reply
#4
@quarryman

I've been hanging around the moOde forum since the days when it was a single thread on diyAudio.com, almost 6 years now. (Not bragging; there's several here who discovered moOde before I did.)

I don't recall any moOde user ever reporting these symptoms.

One thing in your description which intrigued me is

Quote:Some extra context, I have a few scripts that are running (LCD display etc) that are on another pi. The python files are there linked via NFS. Not sure if that's a factor.

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.

If nothing else, you could to do some packet sniffing on your LAN (maybe you are experiencing packet storms, for example) but that's outside the scope of this forum.

Regards,
Kent

PS - it's always useful to post your moOde system configuration info when you have an issue.
Reply
#5
It's a long shot, but is that Raspberry Pi's pseudo-static IP address outside of any DHCP pool from which DHCP addresses are issued on your network?
Cheers,
  Miss Sissy Princess
Reply
#6
With a mesh wireless and an 8 port hub in your network you have a large degree of complexity when it comes to addressing. You could easily have a conflict between what the mesh router does and what the hub does. Begin by mapping your network, understand what address ranges are assigned by which device, how they translate from device to device, which are assigned dynamically, and who by. The problem is almost certainly in there rather than in moOde.
----------------
Robert
Reply
#7
Thanks for the tips.


Quote: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?
Reply
#8
(04-13-2021, 08:33 PM)quarryman Wrote: Thanks for the tips.


Quote: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
Reply


Forum Jump: