search

motioneye-project / motioneyeos

A Video Surveillance OS For Single-board Computers
Other
7.86k stars 898 forks source link

MotioneyeOS randomly breaks DHCP assignments, disconnects other LAN devices. #2788

Open Cubytus opened 3 years ago

Cubytus commented 3 years ago

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:

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:

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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!