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 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
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
31 matches
Mail list logo
