brada4
commented
3 months ago How one of three possible working configurations is qualified as improper? In general you do not need modemmanager, native luci extensions suffice.
Open arinc9 opened 3 months ago
brada4
commented
3 months ago How one of three possible working configurations is qualified as improper? In general you do not need modemmanager, native luci extensions suffice.
arinc9
commented
3 months ago How one of three possible working configurations is qualified as improper?
Sorry, what does that mean? Where do you see that "one of three possible working configurations" do I claim is improper? I have clearly stated that the modem is not detected properly at boot.
In general you do not need modemmanager, native luci extensions suffice.
I disagree with your suggestion. I'd much rather prefer to have this issue fixed instead of using something else to evade the issue.
feckert
commented
1 month ago If this only happens at boot, it is usually because the modem is not yet ready to respond on the cdc_wdm interface. I suspect that it is not responding to the cdc_wdm interface during the probe phase of the ModemManager. The ModemManager then assumes that cdc_wdm (qmi/mbim) is not supported. As a workaround you could delay the start of ModemManager. But the cleanest solution would be that the ModemManager extends the probe phase and thus gives the modem more time to respond correctly during probing.
Will the modem be detected if you restart the ModemManager? This is definitely a timing thing.
I'm going to close this because I don't think we can do anything about it. If you disagree, feel free to reopen the ticket.
arinc9
commented
1 month ago Will the modem be detected if you restart the ModemManager?
After running service modemmanager restart and waiting for a minute to get past the error: couldn't find the ModemManager process in the bus response, I see the same output I've mentioned in the issue report.
I'm going to close this because I don't think we can do anything about it. If you disagree, feel free to reopen the ticket.
As I've mentioned:
This issue is not there on Buildroot which utilises ModemManager 1.22.0 unmodified.
I think the problem stems from the modifications made to ModemManager for OpenWrt. Therefore, I believe that this issue report should remain open until the issue it reports is fixed. I see no option in this page to re-open the issue. I'm going to wait 48 hours for you to re-open it or provide me the means to do so on my own. Otherwise, I will open another issue with the same report.
feckert
commented
1 month ago Then you need to give us some more information.
Will the modem be detected if you restart the ModemManager?
After running
service modemmanager restartand waiting for a minute to get past theerror: couldn't find the ModemManager process in the busresponse, I see the same output I've mentioned in the issue report.
Is the dbus service running?
Could use please execute the following command /etc/init.d/modemmanager restart and past the log message from syslog?
dangowrt
commented
1 month ago Looks like hotplug script may need to be extended to notify MM about the addition of the cdc_mbim as well as mbim network device. And maybe PCIe MHI devices...
feckert
commented
3 weeks ago What are the content of the files events.cache in /var/run/modemmanager/?
Is the sysfs path of your Modem listed there?
This file is used to simulate the udev events for the ModemManger in OpenWrt.
This file is filled with the different subsystem events from hotplug.d.
dangowrt
commented
3 weeks ago I managed to reproduce this only on kernels which got all USB drivers for MBIM and QMI as well as USB serial devices exposed by modems built-in. With OpenWrt's default kernel config which builds all those things as modules I can not reproduce the issue.
The reason is simple: Especially on warm reboot, the modem is probed and devices are added before userspace is ready to process any hotplug events.
Hence I suggest to close this ticket as the bug is only present and directly caused by use of a custom kernel which has all those drivers built-in (having drivers built-in which usually aren't may obviously cause havoc for all sorts of applications relying on hotplug events).
arinc9
commented
3 weeks ago Building a kernel with built-in drivers is standard practice. Whether or not they can be built as kernel modules for OpenWrt, I find it poor design for an operating system to depend on kernel modules to operate properly. Therefore, I see my issue as valid. With that said, I'm not here to argue the policy of the development of OpenWrt, so I'm fine with this issue being closed with a 'won't fix' resolution for this reason.
dangowrt
commented
3 weeks ago @arinc9 In that case it would be an issue to be opened for procd, as this is where handling coldplug is missing for built-in drivers, and modemmanager relies on that to receive hotplug events for every modem-related device.
"Standard practise" is obviously a matter of definition. In OpenWrt, it is not standard practise to have USB device drivers, or any drivers which are not required for failsafe mode, built-in. Often times this is not even an option as many devices come with proprietary bootloaders which impose a size limit on the size of the kernel image to be loaded, which is why we try to keep it is slim as possible.
brada4
commented
3 weeks ago udev fires all events on start at the price of keeping device "database" in userspace.
Maintainer: @feckert, @aleksander0m Environment: aarch64, Banana Pi BPI-R4, OpenWrt SNAPSHOT
Description:
This issue only happens for the modem on the M.2 socket. Modems on the mPCIe sockets are detected properly. This issue is not there on Buildroot which utilises ModemManager 1.22.0 unmodified.
At boot, the modem won't be detected properly. The cdc_mbim driver is missing from the drivers section.
Same modem on Buildroot is detected properly.
The modem is detected properly on OpenWrt after manually resetting the modem.
All modems seem to be brought up by the kernel properly on OpenWrt.