Hey,
>
> But there is no 100% fix. Certainly we can and should improve the
> probing and I'm happy to test that. But with the PPP code in place,
> there's always going to be a code path where things didn't work
> out quite right with timing, or some error condition was triggered
> or whatever tha
On 1/18/22 11:04 AM, Dan Williams wrote:
What's your desired error state when detection fails? Just mark the
whole modem as failed, and you'd have some custom logic to twiddle
modem power and/or reboot the machine?
I don't know the ins and outs of the error mechanism, so you tell me -
but wha
On Tue, 2022-01-18 at 09:57 +0100, Aleksander Morgado wrote:
> Hey Dan!
>
> > > > > If MM detects a single TTY port, it's going to default to use
> > > > > PPP.
> > > > > It's not a fallback to PPP, it's using whatever it has for
> > > > > data
> > > > > connection, if PPP is the only way forward,
On Tue, 2022-01-18 at 05:35 -0500, Peter Naulls wrote:
> On 1/17/22 2:06 PM, Dan Williams wrote:
> own problems, but maybe not the ones you're worried about.
> >
> > I haven't read the whole thread in detail, so forgive me if this
> > was
> > covered. Perhaps a way of tagging a modem/driver/what
On 1/17/22 2:06 PM, Dan Williams wrote:
own problems, but maybe not the ones you're worried about.
I haven't read the whole thread in detail, so forgive me if this was
covered. Perhaps a way of tagging a modem/driver/whatever with "never
use PPP" would be workable. Off by default of course.
I
Hey Dan!
> > > > If MM detects a single TTY port, it's going to default to use
> > > > PPP.
> > > > It's not a fallback to PPP, it's using whatever it has for data
> > > > connection, if PPP is the only way forward, PPP will be.
> > >
> > > I don't want PPP, ever. I don't know how many times I ca
On Fri, 2022-01-14 at 16:29 +0100, Aleksander Morgado wrote:
> Hey Peter,
>
> On Fri, Jan 14, 2022 at 4:14 PM Peter Naulls
> wrote:
> >
> > On 1/14/22 10:09 AM, Aleksander Morgado wrote:
> > logic is not going to change.
> > >
> > > If MM detects a single TTY port, it's going to default to use
Hey Peter,
On Fri, Jan 14, 2022 at 4:14 PM Peter Naulls wrote:
>
> On 1/14/22 10:09 AM, Aleksander Morgado wrote:
> logic is not going to change.
> >
> > If MM detects a single TTY port, it's going to default to use PPP.
> > It's not a fallback to PPP, it's using whatever it has for data
> > conn
On 1/14/22 10:09 AM, Aleksander Morgado wrote:
logic is not going to change.
If MM detects a single TTY port, it's going to default to use PPP.
It's not a fallback to PPP, it's using whatever it has for data
connection, if PPP is the only way forward, PPP will be.
I don't want PPP, ever. I do
Hey Peter,
> > So removing the timing logic is not possible; but why not add an
> > extremely longer value that will definitely be safe? E.g. why not set
> > EXTRA_PROBING_TIME_MSECS to 6 to make it wait up to 1 minute in
> > between port additions in the same device? Well, if we wait so long
On 1/14/22 9:01 AM, Aleksander Morgado wrote:
Hey,
So removing the timing logic is not possible; but why not add an
extremely longer value that will definitely be safe? E.g. why not set
EXTRA_PROBING_TIME_MSECS to 6 to make it wait up to 1 minute in
between port additions in the same dev
Hey,
> > For a quick workaround in your case, can you try modifying
> > EXTRA_PROBING_TIME_MSECS in mm-plugin-manager.c and change it from
> > 1500 to something bigger like e.g. 3000 or 4000?
> >
> > There's one thing clear though; the longer timeout should not be
> > applied by default, as that w
On 1/14/22 4:28 AM, Aleksander Morgado wrote:
Hey Peter,
For a quick workaround in your case, can you try modifying
EXTRA_PROBING_TIME_MSECS in mm-plugin-manager.c and change it from
1500 to something bigger like e.g. 3000 or 4000?
There's one thing clear though; the longer timeout should not
Hey,
> So, the problem is the timing here exclusively, there is no failed QMI
> protocol probing. This system you're running seems to be a bit slow,
> and the events reported are taking a lot of time to complete before
> the next one can be processed; we should definitely fix this in
> ModemManage
Hey Peter,
On Thu, Jan 13, 2022 at 3:22 PM Peter Naulls wrote:
>
> On 1/13/22 5:08 AM, Aleksander Morgado wrote:
> > Hey Peter,
> >
>
> >
> > Unfortunately this log is missing the port notifications and the port
> > probing phase; so we cannot investigate why the QMI port was not
> > included in
Hey Peter,
> > 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, also when you power cycle the
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
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
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
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 whether that's better t
Hey Peter,
> >> I see. So the problem is that I have to keep port 02 open for mmcli
> >> commands,
> >> but if I do it'll try to use this for PPP still sometimes.
> >>
> >
> > Please note that the reason to use PPP is not that MM sometimes
> > prefers it over QMI+NET. If PPP is being used, it's l
On 1/1/22 2:33 PM, Aleksander Morgado wrote:
Hey Peter,
I see. So the problem is that I have to keep port 02 open for mmcli commands,
but if I do it'll try to use this for PPP still sometimes.
Please note that the reason to use PPP is not that MM sometimes
prefers it over QMI+NET. If PPP
Hey,
> > * A new FCC unlock operation management via external scripts is
> >introduced, which will avoid to automatically unlock FCC locked
> >devices unless the user has configured the operation manually, or
> >unless an official vendor-provided FCC unlock tool is found in the
> >
Hey Peter,
> >> # AWC EM12-AW
> >> # ttyUSB0 (if #0): QCDM/DIAG port
> >> # ttyUSB1 (if #1): GPS data port
> >> # ttyUSB2 (if #2): AT primary port
> >> # ttyUSB3 (if #3): AT secondary port
> >> ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0512", ENV{.MM_USBIFNUM}=="00",
> >> SUBSYSTEM=="tty", E
Aleksander Morgado writes:
> * A new FCC unlock operation management via external scripts is
>introduced, which will avoid to automatically unlock FCC locked
>devices unless the user has configured the operation manually, or
>unless an official vendor-provided FCC unlock tool is foun
On 12/30/21 8:28 AM, Aleksander Morgado wrote:
Hey,
# AWC EM12-AW
# ttyUSB0 (if #0): QCDM/DIAG port
# ttyUSB1 (if #1): GPS data port
# ttyUSB2 (if #2): AT primary port
# ttyUSB3 (if #3): AT secondary port
ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0512", ENV{.MM_USBIFNUM}=="00",
SUBSYSTEM=
Hey,
> ACTION!="add|change|move|bind", GOTO="mm_awc_port_types_end"
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="2c7c", GOTO="mm_awc_port_types"
> GOTO="mm_awc_port_types_end"
>
> LABEL="mm_awc_port_types"
>
> SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*",
> ENV{.MM_USBIFNUM}="$attr{bInterfaceNumber}
On 12/3/21 9:52 AM, Aleksander Morgado wrote:
Hey,
And two, that we never, ever try to use PPP. To that end,
I may need to fashion a patch to make this so - maybe just a runtime
option to stop it being used. Actually removing it from the build is
more work than I care to take on.
You can a
Hey,
> >> However, and by all means convince me otherwise, I could still see
> >> the fall though case to PPP happening when things are not quite ready
> >> with the USB stack, QMI driver, etc. And that's a real problem for me.
> >
> > Here we're relying on two things: the kernel exposes all port
On 12/3/21 3:48 AM, Aleksander Morgado wrote:
Hey,
However, and by all means convince me otherwise, I could still see
the fall though case to PPP happening when things are not quite ready
with the USB stack, QMI driver, etc. And that's a real problem for me.
Here we're relying on two thin
Hey,
>
> Aleksander Morgado wrote on Fri, Dec 03, 2021 at 11:02:12AM +0100:
> > I'll give it some time before a new release I think; this issue should
> > affect openwrt only, and there was no bump to 1.18.4 there yet.
>
> I've missed why these udev rules should only affect openwrt?
> procd doesn'
Thanks for the quick reply!
Aleksander Morgado wrote on Fri, Dec 03, 2021 at 11:02:12AM +0100:
> I'll give it some time before a new release I think; this issue should
> affect openwrt only, and there was no bump to 1.18.4 there yet.
I've missed why these udev rules should only affect openwrt?
Hey Dominique
> > > > Could you please test the following single patch on top of 1.18.4?
> > > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/700
> > >
> > > I ran through a couple of test cases and this appear to be doing the right
> > > thing. Thanks.
> > >
> >
>
Hello,
Aleksander Morgado wrote on Thu, Dec 02, 2021 at 04:24:39PM +0100:
> > > Could you please test the following single patch on top of 1.18.4?
> > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/700
> >
> > I ran through a couple of test cases and this appear to
Hey,
> > The udev rules themselves are robust. The problem may be the time
> > required by the module to expose the ports in the system, and the time
> > required by the module to actually reply anything in those ports.
> > Those two last things are handled by timeouts in ModemManager, and if
> >
On 12/2/21 4:46 PM, Aleksander Morgado wrote:
The udev rules themselves are robust. The problem may be the time
required by the module to expose the ports in the system, and the time
required by the module to actually reply anything in those ports.
Those two last things are handled by timeouts
> >>> Could you please test the following single patch on top of 1.18.4?
> >>> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/700
> >>>
> >>
> >> I ran through a couple of test cases and this appear to be doing the right
> >> thing. Thanks.
> >>
> >
> > Thanks for tes
On 12/2/21 10:24 AM, Aleksander Morgado wrote:
Hey
Could you please test the following single patch on top of 1.18.4?
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/700
I ran through a couple of test cases and this appear to be doing the right
thing. Thanks.
Hey
> > Could you please test the following single patch on top of 1.18.4?
> > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/700
> >
>
> I ran through a couple of test cases and this appear to be doing the right
> thing. Thanks.
>
Thanks for testing, will merge and
On 12/1/21 4:11 PM, Aleksander Morgado wrote:
Could you please test the following single patch on top of 1.18.4?
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/700
I ran through a couple of test cases and this appear to be doing the right
thing. Thanks.
Hey Peter,
> > > Wondering, would you be able to also test 1.18.4 but with these 2
> > > changes reverted? The regex related fix was a big one, maybe it broke
> > > something else.
> > >
> > > 2beae71a6 kerneldevice,generic: simplify DEVPATH matching logic
> > > 1bd70df8a kerneldevice,generic: inp
Hey Peter,
> > Wondering, would you be able to also test 1.18.4 but with these 2
> > changes reverted? The regex related fix was a big one, maybe it broke
> > something else.
> >
> > 2beae71a6 kerneldevice,generic: simplify DEVPATH matching logic
> > 1bd70df8a kerneldevice,generic: input pattern t
On 12/1/21 5:11 AM, Aleksander Morgado wrote:
Hey Peter
Wondering, would you be able to also test 1.18.4 but with these 2
changes reverted? The regex related fix was a big one, maybe it broke
something else.
2beae71a6 kerneldevice,generic: simplify DEVPATH matching logic
1bd70df8a kerneldevi
Hey Peter
On Tue, Nov 30, 2021 at 2:55 PM Peter Naulls wrote:
>
> On 11/29/21 11:12 AM, Dan Williams wrote:
>
> >
> > Do you have debug logs from MM? At the very least MM has to find a
> > netdevice for the modem, otherwise it would fall back to an available
> > AT port for PPP. Does MM find one?
On 11/29/21 11:12 AM, Dan Williams wrote:
Do you have debug logs from MM? At the very least MM has to find a
netdevice for the modem, otherwise it would fall back to an available
AT port for PPP. Does MM find one?
Here are two logs to compare. In both cases the kernel is 4.14.256; the
only d
On Mon, 2021-11-29 at 10:52 -0500, Peter Naulls wrote:
> On 11/26/21 4:52 AM, Aleksander Morgado wrote:
> > Hey hey,
> >
> > This is the second bugfix release in the 1.18.x series, built from
> > the mm-1-18
> > branch.
> >
>
> Thanks!
>
> I've been chasing, as I mentioned a while ago, where "
On 11/26/21 4:52 AM, Aleksander Morgado wrote:
Hey hey,
This is the second bugfix release in the 1.18.x series, built from the mm-1-18
branch.
Thanks!
I've been chasing, as I mentioned a while ago, where "sometimes" the modem
connection will be brought up as PPP, not qmi. This kind of con
Hey hey,
This is the second bugfix release in the 1.18.x series, built from the mm-1-18
branch.
ModemManager 1.18.4
---
* A new FCC unlock operation management via external scripts is introduced,
which will avoid to automatically unlock FCC locked devi
53 matches
Mail list logo
