On 1/12/22 4:25 AM, Aleksander Morgado wrote:
In the openwrt git master branch (which I believe it's what you're using) that logic was updated to use a new wrapper script in /usr/sbin/ModemManager-wrapper, and this scripts introduces a bogus "sleep 2" in between the MM start and the call to mm_report_events_from_cache:/usr/sbin/ModemManager "$@" 1>/dev/null 2>/dev/null & CHILD="$!" sleep 2 mm_report_events_from_cache I think that sleep is breaking the modem detection here, because the realtime events are reported as soon as MM is detected, and the cached ones are reported more than 2s later, and MM has a strict timing of how long to wait for new port events since the last port event has happened.
The OpenWrt I'm using is a bit of a frakenstein, due to how I got to this point, but it's approximately 21.02 with some dev pieces. It could probably be rebased on 21.02, but that requires some effort. In any event, although I'm using latest MM (along with patches we've discussed), the packaging and scripts is very much like what's in 21.02 - I went through and double checked that there's no changes like this. In any case, I don't have the wrapper script or the sleep 2. As an aside, I went and turned off all the plugins except for quectel (this could be done for OpenWrt menuconfig, but that's another topic) just to avoid confusion. What I can see, is that even on an apparently successful connection, is there seems to be some confusion about what's available for ports, but I don't know enough about the mechanism to say if it's OK or not. I'll post a log of this shortly.
