Crowsnest Setting WLAN1 Network Interface DOWN #276
Comments
|
That's some interesting bug. But as you already noticed, Crowsnest is basically doing nothing, that could create this problem. I recommend to get Nginx, Mainsail and Crowsnest out of the equation and test it only with ustreamer. So run the following command: /home/tj/crowsnest/bin/ustreamer/ustreamer --host 0.0.0.0 -p 8080 -d /dev/v4l/by-id/usb-046d_HD_Pro_Webcam_C920_809E7D1F-video-index0 --device-timeout=2 --encoder=HW -r 1280x720 -f 10 --allow-origin=* --format=yuyvThen connect to |
|
Hm, yeah. You're totally right. It does seem like an upstream issue with Here's another screen recording: https://www.youtube.com/watch?v=3VNb6MwUPKQ |
|
Can you try |
|
I cannot bring the network interface down with I'll try and test against the newest version as you suggested on Discord and report back after lunch. What's also interesting, is that I am not observing the same behavior when I run curl hektor.sol.milkyway:8080/stream --output /dev/null |
|
Unfortunately it occurs with version 6.16 as well. Here is another screen recording showing that as well as the note I made above about it only failing when the traffic originates from outside of the device itself. https://www.youtube.com/watch?v=QSUJxR5HU0g I'll go ahead and file a different issue with |
|
Issue posted: pikvm/ustreamer#293 |
Do you use localhost or 127.0.0.1 for that? These addresses point to loopback apdapter which is a virtual interface. |
|
I used the FQDN which resolves to the 192.168.30.170 IP Address. I just repeated the experiment and I can see that 
|
|
Thanks for your information. Anyways did you check the syslog for entries of the usb device disconnecting or something related? |
|
No, but I did notice that
This is interesting, because 
I set up a second NetworkManager connection profile for 
Afterwards, I went ahead and started up a ustreamer server again and connected to it over 192.168.30.170 via However, using 
Like, I'm happy things are working right now. But something is still wrong. 
|
|
Right above the brcmfmac spam you can see your wifi stick disconnecting and reconnecting to the usb bus. Also you can see a tx timeout. |
|
I think that It was previously difficult to get crash information. The crash only occurs if However, I've just attached a USB keyboard to the Pi, set a password for my user, turned off the Give me a while and I will trigger a crash and record of a video of the screen to gather more data. |
|
Okay, I've gotten to the bottom of this. Mostly. I recorded a long video of the DSI screen and then when I started to watch it over I realized none of this was necessary at all I could simply use In this, I saw various messages repeating like the following examples:
This led to me trying a few things. I removed the Wireless adapter from the extension cable it was using in case the cable was causing a power/bandwidth problem. That didn't fix anything. Then I removed one unnecessary USB device from my Pi (A Noctua fan) to see if that might help with reducing power consumption. That's didn't fix anything either. It was at that point I was starting to worry that I messed something up between when I wired my printer's power supply to a buck converter and then eventually the Raspberry Pi. And I was over/under volting the device. I'm a software engineer, but do not have any real experience with electrical engineering. On a whim, I decided to change to a new USB Wireless Adapter that just came in the mail. And the problem went away entirely. To rule out any power issues, I ran So I'm inclined to believe it's an issue with the A huge thank you @mryel00 and @rackrick for patiently trying to help me troubleshoot this over the past day. Now I can finally finish up this guide and put the printer back together :) |
|
Still only getting like 7-11fps at 720p though. So I still need to figure that out. Not sure why it's been capped at 10 by
|
|
Okay, managed to get up to about 15fps for my Logitech C920 with this configuration: [crowsnest]
log_path: ~/klipper_logs/crowsnest.log
log_level: verbose
delete_log: false
no_proxy: false
[cam 1]
mode: ustreamer
port: 8080
device: /dev/v4l/by-id/usb-046d_HD_Pro_Webcam_C920_809E7D1F-video-index0
resolution: 800x600
max_fps: 30
v4l2ctl: focus_automatic_continuous=0,focus_absolute=70,brightness=100,contrast=100,saturation=100,sharpness=200,backlight_compensation=1
custom_flags: --format=yuyvI gather from the Discord forums that the recommended solution to further improve FPS would be to use WebRTC which requires
So I suspect this is the best possible outcome at this time. I don't exactly understand why I cannot reach higher resolutions/fps though as this does not appear to be a bandwidth constraint. |
|
Higher resolutions and MJPEG (normal ustreamer format) needs a lot more bandwidth to transfer the images (its just multiple jpeg per second. nothing advanced). WebRTC is much more bandwidth optimiced then MJPEG. |
|
About your fps. You should not use |
|
If I remove the |
|
Also, I'm starting to think my original issue was not necessarily driver related so much as power related.
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#typical-power-requirements |
|
Okay, so I've come to learn that the Raspberry Pi 5 requests the input current from the USB-C port when it boots. If no response is received, or it is less than 3A, the USB-C devices are limited to consuming 600mA. However, if it's greater than 3A, they can use up to 1.6A. Since my device is powered by the GPIO pins I was being limited.
This can be fixed by turning this feature off and manually defining the input amperage. sudo raspi-config
# 4 Performance Options
# P4 USB Current
# Would you like the USB current limit to be disabled? -> Yes
sudo rpi-eeprom-config --edit
# Add PSU_MAX_CURRENT=5000
# Save and exit the file: Ctrl+X -> Return
sudo rebootAfter this, the NETGEAR wireless USB adapter works just fine. |
What happened
I recently flashed my printer to run Klipper which is driven by a Raspberry Pi 5. The Pi is installed beneath the printer in it's electronics housing which results in poor wireless reception. So I purchased a USB wireless adapter with an antenna that sits outside of the printer. This works great, however, I've been chasing down a bug where the Pi would randomly disconnect from my network when I would interact with Mainsail, Fluidd, or KlipperScreen. I believe the ultimate catalyst if the bug in all of these cases is Crowsnest.
The Internal wireless chip is
wlan0and the USB wireless adapter iswlan1. I run Raspberry Pi OS Lite which uses NetworkManager. I've defined a connection profile forwlan1but notwlan0. So, on boot,wlan1comes up and gets an IP from my router through a static ip reservation.This all works great, and I can use Mainsail, KlipperScreen, etc just fine. But as soon as I try and load any UI element that loads the webcam, the
wlan1interface gets setDOWNand networking breaks. Locally on KlipperScreen, Klipper continues to function just fine. So it's not crashing or anything. The networking just breaks.I poked through the code and I'm not sure where this could be happening, but I suspect it has to do with how ustreamer binds to a NIC. I don't see any configuration options documented that allow this to be configurable.
It does eventually recover and wlan0 comes back up. I'll share some STDOUT from ping showing this in the Additional information section below. But it takes minutes.
Here is a screen recording demos the bug occurring around 1:40: https://www.youtube.com/watch?v=WBQlUoP5Dfc
What did you expect to happen
Crowsnest to support multiple network interfaces, not default to the first one, and to work with any of them
How to reproduce
Run Klipper, Mainsail, Crowsnest on a device with multiple wireless NICs and a USB Webcam. Have the first NIC
DOWNand the second NICUP. Load the webcam and observe the second NIC be set toDOWN.Additional information
Crownest Config
Network Manager Connection Config
ip addr
Crowsnest Debug Log
STDOUT from Ping During Failure and Eventual Recovery
The text was updated successfully, but these errors were encountered: