On 11/7/22 16:08, Aleksander Morgado wrote:
Please note that the automatic registration you're seeing (+COPS=0) is
being started because you likely run a Simple.Connect() while the
modem was disabled (as opposed to running a Modem.Enable() first and
then a Simple.Connect()). Not saying that
Hi,
I have yet another question around the Fibocom MA510 modem. I'm
observing an issue where the modem is in registered state when
ModemManager starts up. MM ignores this due to
3GPP registration state change ignored as modem isn't enabled (line 832)
MM then triggers an automatic network
On 10/20/22 11:16, Aleksander Morgado wrote:
There is probably no generic way to resolve this because the current
implementation seems correct. But do you have guidance how to fix this
with - perhaps with a non-upstreamed patch? Perhaps, we could start a
timer when getting the denied status
Hi Aleksander,
just to be clear, this is what I'm referring to:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blob/ec28c85a6a29e819266c4fb167e4defe9a2a33d9/src/mm-iface-modem-simple.c#L186
What would you suggest setting this to? Should this value be retrieved
via the modem's
Hi Aleksander,
On 10/20/22 10:51, Aleksander Morgado wrote:
Hey,
I have another question about the Fibocom MA510-GL: When +COPS=0 is
issued, often the modem emits the following sequence of URC which makes
ModemManager abort the simple connect flow:
+CEREG: 0 (idle)
+CEREG: 2 (searching)
Hi,
I have another question about the Fibocom MA510-GL: When +COPS=0 is
issued, often the modem emits the following sequence of URC which makes
ModemManager abort the simple connect flow:
+CEREG: 0 (idle)
+CEREG: 2 (searching)
+CEREG: 3 (denied)
+CEREG: 5,... (registered, roaming)
I guess
Hi,
I saw that the registration timeout, i.e. the max time to wait from
+COPS=0 to registered state to be reached, is set to 60s. On a modem I
am working on (Fibocom MA510-GL), I can see that this can take multiple
if not many minutes in certain cases. This appears to depend on what
RATs and
Hi Aleksander,
Thanks for the pointers. We'll try to get in touch with Quectel.
Sven
On 9/5/22 19:19, Aleksander Morgado wrote:
Hey,
We're observing an interesting behavior with the Quectel EG91-E modem
(using QMI comms). Every now and then, we lose connectivity. When
looking at the
Hi,
We're observing an interesting behavior with the Quectel EG91-E modem
(using QMI comms). Every now and then, we lose connectivity. When
looking at the debug-level logs, we can see that the modem sends and
indication with "Dormancy Status" set to "traffic-channel-dormant". This
does not
Hi,
Quick question: Is it safe to call SetAllowedModes on a modem that is
currently connected? I assume it is and that ModemManager will
disconnect the connection if necessary.
Thanks and best regards,
Sven
Hi,
When trying to set the allowed modes (4G only in my case), the setting
doesn't seem to persist across power-cycles of the modem. Is there a way
to make this setting permanent or reset it every time the modem state
machine is brought up by ModemManager (perhaps a simple external script,
Hi,
I have a question around how to properly call base class methods and
passing the async result back to the caller. Consider the following
scenario:
* MMBroadbandBearerFibocomEcm inherits from MMBroadbandBearer
* MMBroadbandBearerFibocomEcm implements its own connect_3gpp and
Hi,
I'm troubleshooting a problem with the Fibocom L610 LTE Cat-1 modem and
ModemManager 1.18.6. The modem/SIM appears to connect PDP context 0
automatically. The APN seems to be populated from the SIM. When trying
to connect, ModemManager searches for the best context. If context 0
matches
Hi,
I'm getting a build error for ModemManager 1.18.6 with meson 0.53.2.
This error does not occur with meson 0.61.2 in an otherwise identical
environment. According to the NEWS file, the minimum meson version
should be 0.53.0 (ModemManager 1.18.2).
[...]
[127/452] cc
Never mind, I had forgotten to adjust the option driver so there was no
AT port to go along with the data port. The modem object is now created
as expected.
Sven
On 1/5/22 11:30, Sven Schwermer wrote:
Hi,
I'm adding cdc_ether support to the Fibocom plugin. Unfortunately, the
create_modem
Hi,
I'm adding cdc_ether support to the Fibocom plugin. Unfortunately, the
create_modem method is never called. I have added "cdc_ether" to the
list of allowed drivers in the Fibocom plugin code. However, looking at
the log, I see that the port is ignored. The plugin manager seems to be
Hi,
How does ModemManager handle default bearers that connect automatically?
Specifically, I’m working with a Quectel BG95 that automatically connects on
PDP context #1. How would this work best with the ModemManager state machine?
I’m not sure if the 3gpp profile manager is compatible because
Hi,
Where would I have to change the Quectel plug-in in order to use a DHCP bearer
if there is a net interface (ECM) associated with a modem. Currently, a PPP
bearer is created even if a net interface is available. This is for a BG95
modem which comes with a ECM mode.
Sven
Hi Aleksander,
> Yes, this confirms the assumption. We should try to use SSSP for the
> manual/automatic registration attempt.
I looked a little into the source, but I’m not intimately familiar with it. Are
you suggesting to call qmi_client_nas_set_system_selection_preference instead
of
Hi,
We’re facing a problem where ModemManager (v1.10.0) doesn’t respect the allowed
modes when the modem (Quectel BG96) fails to connect the first try.
First, we set the allowed modes to 4G (--set-allowed-modes=4g) which works. We
verified this by running AT+QCFG=“nwscanmode” which is
t a MM related issue.
>
> Enrico
>
>
> On Thu, 7 May 2020, Sven Schwermer wrote:
>
>> Date: Thu, 7 May 2020 15:43:51
>> From: Sven Schwermer
>> To: "ModemManager (development)"
>> Subject: Bearer MTU not recognised by NetworkManager
>> H
Hi,
I’m observing that NetworkManager (v1.20.2) does not recognise the MTU (=1360)
exposed by the ModemManager’s (v1.10.6) bearer object and instead uses some
default value (=1500). This seems to lead to issues which are fixed when
manually setting the MTU to a lower value. When checking the
Hi,
I’m currently investigating why my Quectel EG91-E modem (QMI) sometimes drops
the connection. At the respective times, I can find the following lines in the
logs:
bearer call end reason (1): 'generic-unspecified'
bearer verbose call end reason (3,1028): [cm] (null)
Now unfortunately,
Hi again,
Please excuse the continuation of the monologue, but I believe I have found a
good hint if not the reason for the issue at hand. I noticed two things:
1. When NetworkManager wasn’t running on my device, I couldn’t establish the
connection manually.
2. When I talked to the native UART
Hi all,
>> Might this imply that we're talking about the initial bearer and that
>> when MM tries to connect, because it will attempt to close any existing
>> connection, the modem is telling MM "no"?
>>
>> We already know we need to be better about auto-detecting that the
>> initial bearer is
Hi all,
> On 15 Mar 2019, at 16:03, matthew stanger wrote:
>
> Anyway, the only thing I can think of is a timing issue with the modem
> firwmare and network registration or initial bearer setup or something
> like that. Perhaps MM isn't querying some ready state well enough, or
> the modem
Hi again,
I did some more work and now I am able to connect manually (without
ModemManager). All that’s required is the AT^SWWAN=1,1 command if the APN is
already correctly configured. I checked this via AT+CGDCONT?. Note, that this
only works for CID=1. After changing the APN for CID=1, the
Hi Matthew,
Thanks for the update!
> I've had a long back-and-forth with the vendor but basically we still can't
> get the demo board reliably working with basic AT commands.
> In short I'm still working on it but really don't understand why this modem
> model continues to prove so difficult
Hi Matthew,
I have the same issues with the ELS61 modem. Did you make any progress regarding
this issue? Could the GPRS/AutoAttach setting (see AT^SCFG) have anything to do
with this?
Best regards,
Sven
___
ModemManager-devel mailing list
> Could you give me a pointer?
Never mind, I found a way to make it work. However, I’m not sure whether it’s a
good idea to add the 0x8087 VendorID to the Sierra plugin.
diff --git a/plugins/Makefile.am b/plugins/Makefile.am
index 17a21a0d..3b555194 100644
--- a/plugins/Makefile.am
+++
> 8087 is Intel's VID, and we don't have a specific plugin in MM for
> devices with the Intel VID. We could extend the "xmm" plugin to do
> this though.
That sounds like a good idea. I’ve had a quick look at the code but couldn’t
find where the VID:PID matching is happening or where the VID:PID
Hi Aleksander,
> ModemManager does not know how to use the cdc-ncm ports exposed by the
> modem, the implementation is missing.
> IIRC we had some attempt to implement this, and I even got some HL
> modules sent by Sierra to me, but I'm missing the devkit to use them
That explains the issues I’m
I managed to pull the following NetworkManager debug logs:
[1552470915.7827] platform: signal: link added: 7: wwan0
mtu 1500 arp 1 wwan? not-init
addrgenmode eui64 addr 00:00:11:12:13:14 driver cdc_ncm rx:0,0 tx:0,0
[1552470915.7849] manager: wwan0: factory failed to create device:
Device
Hi Dan,
> ETSI 27.007 says for the "signal" CIND indicator:
>
> "signal" signal quality (0-5)
>
> so if the modem isn't presenting something useful here, I'm not sure
> why it's implementing this indicator in the first place :)
For ublox, the “signal” indicator translates directly to power
Hi,
I’m currently trying to get the Sierra HL7692 up and running. In my first
attempt, I set the USB composition to AT+KUSBCOMP=2 so that I would get 1x MBIM
+ 3x CDC-ACM. This worked but the modem was only recognised as “generic” which
didn’t allow for extended signal query, etc.
Next, I set
Hi,
I’m wondering what factors into the Signal Quality value for LTE modems. My
suspicion is that only the “Signal” field of the +CIND message is used, but if
I understood the manual for the ublox LARA-R211 correctly, that’s a poor
quantity to use for this purpose as it only represents the
Hi again!
> I’m currently using a 4.1.x kernel. I’ll try with a 4.18.x kernel now. I’ll
> keep you posted.
I have gotten a step further with a newer kernel. DNS works as well as simple
pinging (ICMP). However, when trying to establish a TCP connection, the
connection times out. I then went
Hi Aleksander,
> We try to set 802.3 (with ethernet headers) and the modem returns "success"
> but with raw-ip as protocol instead. Looks like this device MUST be used in
> raw-ip mode. One thing to fix in our side is to check the returned protocol
> value in the Set Data Format reply, because
Hi,
> Could you try requesting for an IP4-only connection (flagging as
> disabled the IPv6 settings explicitly)? Looks like the IPv4 setup
> succeeds and the IPv6 setup fails. Not saying that is the only fix
> needed, because I believe the modem should allow the IPv4 setup even
> if the IPv6
Hi,
I am trying to connect a QMI modem (u-blox SARA-R412M) using ModemManager 1.8.2
and libqmi 1.20.0. The modem transitions into the connected state which makes
NetworkManager start the DHCP procedure. That, however, never succeeds. In the
ModemManager logs, I can see that QMI reports IPv4
Hi Aleksander,
Great to hear your input on the issue, thank you!
I have some preliminary positive results with the connection status check
disabled. I would like to understand the consequences of this change though.
Are there scenarios where pppd wouldn’t detect the disconnection? In other
2018, at 16:46, Sven Schwermer wrote:It looks like I celebrated prematurely. As soon as I disabled the debug-level logging for NetworkManager and ModemManager, the issue started to appear again. This tells me that there is some sort of race condition. I’ll look into this more but I’d appreciate
explain the
desired/expected series of events when the peer hangs up and pppd terminates.
Thank you!
Sven
> On 23 Oct 2018, at 17:18, Sven Schwermer wrote:
>
> Hi again,
>
> I think, I have found a fix for this. With the following two patches applied
> to NetworkManager 1.12.
er/commit/3392c439582b4ba5da19423fbaeed5843aeae9a9>
I suspect, the latter made the difference because pppd basically hangs when the
bus method call doesn’t return.
Sven
> On 23 Oct 2018, at 11:37, Sven Schwermer wrote:
>
> Hi Aleksander, Matthew,
>
> I looked into this and the issue that Aleksand
>
> Regards,
> Matthew Starr
>
>> Date: Mon, 22 Oct 2018 11:39:37 +0200
>> From: Sven Schwermer mailto:s...@svenschwermer.de>>
>> To: Aleksander Morgado > <mailto:aleksan...@aleksander.es>>
>> Cc: modemmanager-devel@lists.freedesktop.org
and is never reset, which causes
> the serial port to never retry communications over the serial port again.
>
> Regards,
> Matthew Starr
>
>> Date: Mon, 22 Oct 2018 11:39:37 +0200
>> From: Sven Schwermer mailto:s...@svenschwermer.de>>
>> To: Aleksander Mo
,
Sven
excerpt.long.gz
Description: GNU Zip compressed data
> On 20 Oct 2018, at 16:26, Sven Schwermer wrote:
>
> Hi again,
>
> I now managed to capture the event in the journal. I limited the auto connect
> retried to 4 in order to keep the log size manageable. I didn’t h
Hi again,
I now managed to capture the event in the journal. I limited the auto connect
retried to 4 in order to keep the log size manageable. I didn’t have
debug-level logging active for NetworkManager at the time. I’ll enable that now
and try to reproduce. Please find the log attached. The
Hi,
I am running an embedded system with a u-blox SARA-U270 modem and
NetworkManager 1.12.2 / ModemManager 1.8.0. For some reason, the modem
connection seems to break over time. I am not quite sure why that’s the case,
but when I look into the journal, I see NetworkManager and ModemManager
49 matches
Mail list logo
