Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ustreamer causing WLAN1 network interface to go DOWN after connection from remote device #293

Closed
zimmertr opened this issue Oct 25, 2024 · 5 comments
Assignees
Labels

Comments

@zimmertr
Copy link

zimmertr commented Oct 25, 2024

I have a Raspberry Pi that I use to run my 3D Printer. This Raspberry Pi runs a piece of software called Crowsnest which uses ustreamer to stand up a webcam server so that people can monitor their 3D prints while they're occuring. This Raspberry Pi is installed inside my 3D printer's electronics compartment which causes the wireless reception to be poor. To solve this, I've installed a USB Wireless Adapter with an antenna outside of the chassis.

All of this works great. However, the moment I try and load the webcam feed, ustreamer appears to set the wlan1 network interface to DOWN which breaks the network connectivity to the device. I can see through a monitor connected to the Raspberry Pi that it continues to function. And I can still interact with it just fine. But it loses network connectivity.

At first I thought this was an issue with Crowsnest. But after filing an issue with that project and talking with a dev, it appears to actually be an issue with ustreamer. Here is a video recording that triggers the bug to occur: https://youtu.be/LSgYNcJOXDE

There are a few other videos I recorded that are linked in that thread. Namely, one that executes iperf and demonstrates that the device is not failing when the bandwidth load is high. https://www.youtube.com/watch?v=lghwhJxn3MU

I forgot to show in the video above, but I'm currently running version 6.16 of ustreamer as well.

@mdevaev
Copy link
Member

mdevaev commented Oct 25, 2024

Hello. It's a very weird problem. Ustreamer did nothing with network interfaces so I'm inclined to think that this is a problem with the kernel. There is simply nothing to fix on the part of ustreamer, because it uses normal socket operations.

I know this is not the answer you expected, but I really don't know how I can help. Sorry.

@zimmertr
Copy link
Author

Got it, okay. I suppose next I'll try a different Linux distribution and/or kernel and report back. Failing that, a separate USB Wireless Adapter I guess? Perhaps it's a bug in the driver? I'm not inclined to think that's the case though, because it works fine when I saturate the connection with iperf.

@zimmertr
Copy link
Author

zimmertr commented Oct 25, 2024

I noticed that dmesg was continuously dumping the following error message:

brcmfmac: brcmf_set_channel: set chanspec fail, reason -52

Screenshot 2024-10-25 at 11 14 55 AM

This is interesting, because brcmfmac is the driver used by the Raspberry Pi's internal wlan0 NIC

Screenshot 2024-10-25 at 11 15 31 AM

I set up a second NetworkManager connection profile for wlan0 and enabled it and rebooted. Then those errors stopped getting logged.

Screenshot 2024-10-25 at 11 17 12 AM

Afterwards, I went ahead and started up a ustreamer server again and connected to it over 192.168.30.170 via wlan1 as usual and it did not crash!

However, using bmon, I can see that wlan0 is the one transferring data continuously, NOT wlan1. Despite the fact that I am hitting the ustreamer server over wlan1's IP Address.

Screenshot 2024-10-25 at 11 29 36 AM

Like, I'm happy things are working right now. But something is still wrong. ustreamer is only seemingly functional when it can use wlan0. And even when I connect to the Raspberry Pi over wlan1, I still see that wlan0 is being used to transfer data. This is problematic because the wireless reception of that NIC is poor, and I can only get 7-11FPS over the 720p stream. Which is what originally led to me purchasing the USB wireless adapter to begin with.

Screenshot 2024-10-25 at 11 20 26 AM

@zimmertr
Copy link
Author

Seems to have been a mt7921u driver issue. Solution: here.

@mdevaev
Copy link
Member

mdevaev commented Oct 26, 2024

Glad to hear it.

@mdevaev mdevaev self-assigned this Oct 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants