MotioneyeOS randomly breaks DHCP assignments, disconnects other LAN devices.

[Cubytus]

Preliminary Docs

I confirm that I have read the CONTRIBUTING guide before opening this issue.

I confirm that I have read the FAQ before opening this issue.

motionEyeOS Version

I am running motionEyeOS version: 20200606

Board Model

I am using the following board/model: Raspberry Pi Zero

Camera

I am using the following type of camera: V4L2 or MMAL, unsure. The default setting in motioneyeOS when using this camera model.

My camera model is: official Rasbperry Pi camera

Network Connection

My motionEyeOS unit is connected to the network via: AmazonBasics USB-to-Ethernet adapter

Peripherals

Strictly speaking, none.
However, motionEyeOS is configured to:
Reboot if it cannot reach the Internet in a 120 seconds timeframe (intentionally long delay to allow for older router / older modem reboot rime)
Send a copy of all its recordings to another NAS through FTP.

Log Files

None yet, read below.

I consider the following log files relevant to this issue:

• (attach e.g. motioneye.log)
• (attach e.g. boot.log)

Hi to all,

after this technical presentation, see there are no logs! No wait, seriously, I don't know how to pull them given the circumstances.

Symptoms:

Seemingly at random, devices on the same LAN cannot connect to the Internet, nor can they connect to each other, either using their hostnames or their IP addresses. Upon further testing every device, they appear unable to get a local IP address (192.168.1.x).

Already tried:

LAN IP assignment conflict: doesn't happen since the router uses semi-fixed DHCP assignments and devices on the LAN don't change when problem occurs
Resetting router: doesn't change anything: router runs, but cannot issue LAN IP addresses while crashed MotionEyeOS is present.
Disconnecting-reconnecting MotionEyeOS: this only results in briefly restoring proper DHCP assignment and Internet access, before failing again as MotionEyeOS is reconnected.

Steps to reproduce:

• MotionEyeOS is imaged onto a microSD card using balena Etcher
• Insert card into Raspberry Pi Zero, plug in Ethernet before powering (very important, else it will endlessly fail to boot)
• Plug in power, let boot
• Scan LAN using Angry IP Scanner to find MotionEyeOS IP.
• Connect using this IP
• Leave every setting by default, just add a watchdog for automatic reboot if it can't reach a given host within 120 seconds.
• After system is up and running, briefly unplugging the LAN before reconnecting may trigger this undesirable behavior.
• An unexpected power outage on the RPi may trigger this behavior.
• After it occurs, MotionEyeOS is unreachable, hence the absence of logs.

Now, this bug seemingly appears at random times, but often enough to cripple usage.
Disconnecting the failed MotionEyeOS from the LAN restores connectivity to the others devices within seconds.

I had used MotionEyeOS intermittently before, though not consistently because of its shortcomings (no loop recording option, no sound, general instability in the long run).

How do I pull logs from a crashed, unreachable MotionEyeOS installation? Where would they be located on the microSD card?

[starbasessd]

Lets answer / make suggestions in reverse order here:
Other than using Etcher, you don't say how, or what OS you are using for copying the images to the microSDCards, It would be helpful to know to tell you how to get the logs.

It sounds like the LAN has issues. I would suggest putting a file into the /boot partition to force a specific static IP address:
https://github.com/ccrisan/thingos/wiki/static_ip.conf

Are you using an OTG adapter or just a USB a Female to USB Micro Male?
I use a Belkin Ethernet to USB2 adapter with an OTG cable without issue.

Could 2 of your adapters have the same MAC address?

I use Win32DiskImager most of the time (and put the ssh or ssh.txt file in the /boot partition to enable connecting via ssh. (and my wpa_supplicant file when not using the ethernet adapter)

Do you have a mini HDMI to HDMI adapter/cable to watch the boot up process?

That's enough for now.

[starbasessd]

Where are you turning on your watchdog? WebGUI, Expert Settings, Connectivity Watch?
Your camera should be auto-discovered and if a PiCam (CSI ribbon cable) shows as a MMAL type.
Do you get similar issues if you re-image the PiZero having this issue as RaspberryPiOS (without changing any other PiZero)?

[Cubytus]

Answers:
OS: Mac OS X 10.11.6 (can't read ext2 partitions, but I have a working Ubuntu on hand, if that matters…)
OTG adapter: no, just plain micro USB male to USB-A female, then the USB-to-Ethernet adapter. Nothing fancy.
Issues with LAN: issue only appears when MotionEyeOS is present. In the few cases I add a device to the LAN (mainly bridged virtual machines), they receive a local IP through DHCP without a hitch within seconds.
Could 2 of your adapters have the same MAC address: Nope. I don't bother modifying MAC addresses. For static DHCP assignment purposes, I keep all MAC addresses in a Calc file, and all are unique.
Watchdog: don't remember where I turned it on, sorry. I thought there was only one place, though.

I'll go through the suggestions a bit later.
Boot process: to be pictured…
Adding static IP request from the RPi zero: to be tried…
Same setup, different image: to be tried last, will take more time…

[starbasessd]

I used a handy Pi3 with 20200606 on it, and had an issue with it. Turned on WebGUI, Expert Settings, Connectivity Watch, and it rebooted, and failed to bring anything but SSH up on the IP address. Switched to dev20201026, enabled as above, no issue.
Installed 20200606 for a PiZero (no wifi) and a Belkin Ethernet to USB adapter with OTG adapter.
First boot normal
Enabled Connectivity Watch, rebooted, failed.
So, the issue appears to be with 20200606 if using Connectivity Watch in WebGUI, Expert Settings in at least Pi and Pi3 images. Does not appear to be an issue in dev20201026 for either Pi or Pi3 images. Reporting to @ccrisan as 'bug' for 20200606, but corrected in dev20201026.

[starbasessd]

OS: Mac OS X 10.11.6 (can't read ext2 partitions, but I have a working Ubuntu on hand, if that matters…)
Need to be able to read ext4 partitions /root (partition2) and /data (partition3) If Ubuntu is on iron (not a VM) should be able to read them
OTG adapter: no, just plain micro USB male to USB-A female, then the USB-to-Ethernet adapter. Nothing fancy.
Makes a big difference. This is where USB-on-the-go (OTG) comes in. It adds an extra pin to the micro-USB socket. If you plug a normal A-to-B USB cable, the device acts in peripheral mode. If you connect a special USB-OTG cable, it has the pin connected at one end, and the device at that end acts in host mode.

[sirjeannot]

I've had the same issue with and pinned it down to one raspi0w with motioneyeOS disconnecting another raspi0w with motioneyeos as well. it's been so since 2017 with all revisions of motioneyeOS I've used until the last stable.
all the cameras do have the exact same image and config, as dhcp reservations do the difference on the network.
I haven't been able to find out why. I ended up excluding that raspi0w from the network.

[Cubytus]

@starbasessd Like sirjeannot, the bug reoccurred recently with a stock configuration of 20200606. In other words, no special config, MotionEyeOS wasn't even recording, just idling on the LAN. I installed dev20201026, not restoring previous config.

Haven't tried with RaspberryPiOS yet as I needed to have video recording recently.

@sirjeannot Useful tip as I wanted to upgrade to a raspi0w myself, and maybe add one or two. A disconnected MotionEyeOS isn't very useful IMHO as it simply could get stolen along with its recordings. I only need it from time to time, since auto-delete of recordings once card is full isn't a feature yet (and may never be), What replacement platform have you found?

[sirjeannot]

@Cubytus : My issue was the IR cam for children monitoring at bedtime :D I've not found a suitable replacement yet. I do use outdoor dahua cams in RTSP, raspi0w are limited to indoor use so that risk is more or less leveraged. I don't do local recording, I'm moving to a centralized nvr using frigate to automate more image analysis. I have a system with an ncs2+openvino+analysis of recordings currently, but it's far from being the best solution.

[Cubytus]

@sirjeannot That's a bit more complex than I wished. I wanted a standalone solution that would be able to upload recordings to a remote server, have decent low-light performance, and auto-delete oldest recordings once memory is full No fancy stuff like face recognition. Turns out I forgot about reliability, and MotionEyeOS falls somewhat short on these, at least on the very common RPi0.

True, there are other platforms available like the Orange Pi, Nano Pi NEO, Odroid, but AFAIK none of these manufacturers thought about including a night vision camera in their lineup. Plus, being far less widespread than the RPi, I'm a bit concerned when time will come to get some help.

[sirjeannot]

@Cubytus Your specs are the same as mine! After much testing (all possible distros, stock clocks and downclocking, on 4 different rapi0w), the rtsp streaming always fails the same way. It looks like either a csi driver issue or a hardware fault. I've tested the stability with heavy workloads on these 4 without any issues.
anyways, I'm turning to dedicated hardware, cheap rtsp camera and not bound to cloud services : a whole new challenge!