On 1/12/22 9:58 AM, Aleksander Morgado wrote:
Hey,
I'm not sure there's an easy way to do that; but in this case we may
also be interested in the QMI messages really, because we also want to
make sure the port probing is working as expected; i.e. if this issue
happens not only upon MM start,
Hey,
> >>> Also, please note that if you fully disable the PPP usage (maybe
> >>> making sure that data_at_primary is always NULL in
> >>> mm_base_modem_organize_ports()), what you will achieve is that the
> >>> modem ends up not usable ("Failed to find a data port in the modem").
> >>> You need t
Hey,
>
> > The list of available ports is decided during probing. If probing ends
> > with only 2 TTY ports (as in the log you posted earlier), then QMI
> > will be fully ignored and the net port will never be used. We really
> > need to fix the probing phase so that that doesn't happen. If you
>
On 1/12/22 9:16 AM, Aleksander Morgado wrote:
Hey,
The list of available ports is decided during probing. If probing ends
with only 2 TTY ports (as in the log you posted earlier), then QMI
will be fully ignored and the net port will never be used. We really
need to fix the probing phase so th
On 1/12/22 4:25 AM, Aleksander Morgado wrote:
Hey
Also, please note that if you fully disable the PPP usage (maybe
making sure that data_at_primary is always NULL in
mm_base_modem_organize_ports()), what you will achieve is that the
modem ends up not usable ("Failed to find a data port in the m
Hey,
> > 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
Hey,
On Wed, Jan 12, 2022 at 1:10 PM Peter Naulls wrote:
>
> On 1/12/22 3:55 AM, Aleksander Morgado wrote:
>
> >
> > The main problem with these errors is that they're not standard 3GPP
> > errors, they're vendor-specific, and at the moment there is no support
> > for configuring and enabling ven
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_r
On 1/12/22 3:55 AM, Aleksander Morgado wrote:
The main problem with these errors is that they're not standard 3GPP
errors, they're vendor-specific, and at the moment there is no support
for configuring and enabling vendor-specific error codes. It would be
great to have that support somehow; e.g
Hey
> > Also, please note that if you fully disable the PPP usage (maybe
> > making sure that data_at_primary is always NULL in
> > mm_base_modem_organize_ports()), what you will achieve is that the
> > modem ends up not usable ("Failed to find a data port in the modem").
> > You need to decide wh
Hey,
>
> I'm seeing this.
>
> [16076]: [1641922135.360300] [modem0/sim0] couldn't load list of
> emergency numbers: Failed to parse CRSM query result '+CRSM: 148,8,""'
>
> Seems like the regex in mm_3gpp_parse_crsm_response needs some work. Here it
> is:
>
> r = g_regex_new
> ("\\+CRSM:\\s
Hey Peter,
>
> I'm looking at the errors returned by some of the GPS operations. e.g.:
>
> /usr/bin/mmcli -m 0 --command=AT+QGPSEND
> error: command failed:
> 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.Unknown:
> Unknown mobile equipment error: 505'
>
> These are documented
12 matches
Mail list logo
