Re: LE910 connection with custom APN on AT SIM
Hi Bjørn, Comments below. Bjørn Mork wrote the following: > Nate Pleasant <nate.pleas...@accelerated.com> writes: > > > I have a Telit LE910 modem that ModemManager doesn't seem to be able > > to connect with when using an AT SIM card with a custom APN. See > > output and debug messages below for reference. If I connect this same > > SIM card with a Sierra MC7354 or Sierra MC7455 modem, it's able to > > connect with ModemManager just fine. Is there something I'm missing > > when connecting with this Telit LE910 modem? > > I hope some Telit experts will chime in if I am wrong but the LE910 is > based on an Intel chipset, isn't it? > > If so, then I think some of the findings wrt the Sierra Wireless EM7345 > are relevant. My memory is foggy at best, but I found this: > https://lists.freedesktop.org/archives/libmbim-devel/2014-May/000283.html > > There were a few surprises (to me at least) there. I don't know how > much of that has been fixed/changed in newer firmware revisions. But > some issues to be aware of: > > - the modem might bring up a default bearer using some APN you never > configured, based on the SIM/operator. We have seen this on Sierra modems as well when the AT+CGDCONT list has APN's but we are connecting through QMI, sometimes it uses the APN from the +CGDCONT list. > - this default bearer can conflict with later attempts to connect other > APNs using MBIM and the same IP-type. Note that in my case I could > easily detect this error since I knew the two APNs used different > address types (global vs rfc1918) > > - you might be able to work around the issues by explictly configuring > contexts before attempting to do an MBIM connect. We actually do this, we have a wrapper that ensures before we connect that the AT command versions and the MBIM versions of all contexts match. It has saved us on more than one modem. > My proposal is to play with the AT+CGDCONT list and see if it changes > the behaviour in any way. We have learned that the data session is working, we can use the telit socket commands (at#sd etc) to make a connection to a website and load a web page, however, no traffic seems to pass through the wwan0 interface. We can however put another SIM in there and have it work fine. It sure is confusing. I would suspect the MBIM driver if it were not for the large number of working SIM/APN combinations that work. This particular SIM/custom APN is the first we have had that does not work, yet clearly the data connection is working on the radio side. Big thanks for any and all ideas :-), Cheers, Davidm -- David McCullough, david.mccullo...@accelerated.com, Ph: 0410 560 763 ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [PATCH] telit: support QMI and MBIM modems
Aleksander Morgado wrote the following: > On Mon, Mar 27, 2017 at 12:47 PM, David McCullough > <david.mccullo...@accelerated.com> wrote: > > I am a little late to the party but here is the patch I have been running > > to do this. I have been meaning to clean it up and send it in. Not sure > > if there is anything here that will help out but I figured it can't hurt :-) > > This is more or less the MBIM part of what we're suggesting to do but > on mm-1-6, right? In git master we no longer require the TELIT_TAGGED > tag, and we have the "mm_kernel_device" support instead of the > GUDevDevice. > > David, if you could test your setup with git master (it's compatible > to 1.6.x) and Daniele's updated patch, it would be great. I would love to. I have been trying to move to master for some time now but on our platform there is a severe memory corruption in later versions that has been very hard to track down. One of the object initialisers is overwriting memory in the wrong part of an object and causing MM to crash. I did know where is was (and who) but I was pulled off it for higher priority issues and it sbeen a while now :-( Any thoughts on what could be causing glib object iitialisers to get out of sync would be appreciated. IIRC is was in and around the SIM creation and all in egenric code. Doesn't seem to matter which Modem I am using it will crash. Eventually I will be free'd up to resolve this, hopefully sooner rather than later ;-) As for the Telit, it would be nice if we could pull in some of the Telit plugins AT command based methods to supplement the MBIM interface. I couldn't see any example of that but any advice on the best approach would be appreciated. Cheers, Davidm -- David McCullough, david.mccullo...@accelerated.com, Ph: 0410 560 763 ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: incorrect 'locked' status
Hi Aleksander,
I can confirm it works fine with your patch applied,
Thanks,
Davidm
Aleksander Morgado wrote the following:
> On Tue, Oct 18, 2016 at 8:19 AM, David McCullough
> <david.mccullo...@accelerated.com> wrote:
> > I have had a problem here on the MC7304 using Vodfone SIMs (AU).
> >
> > ModemManager is flagging the device as locked (PIN lock) even though there
> > is no lock on the SIM.
> >
> > I ran it with DEBUG (just the PIN / locked transition is attached).
> >
> > Fairly recent clone of ModemManager, src/mm-iface-modem.c has not changed.
> >
> > The attached patch lets the modem connect fine but I figure it is probably
> > not correct.
> >
> > Basically the new state (lock) is set to MM_MODEM_LOCK_UNKNOWN and the old
> > state (old_lock) is also set to MM_MODEM_LOCK_UNKNOWN. For this condition
> > the code transitions to the "locked" state.
> >
> > Let me know if you need and more info or debug,
>
> So, PIN1 is disabled and therefore we check PIN2 and it is "not
> initialized", which we translate to UNKNOWN. In this case, we should
> have provided the state of PIN1 and ignore the state of PIN2.
>
> Can you test the attached patch?
>
> --
> Aleksander
> https://aleksander.es
> From 86f2ac1e660af39bc51d5521666ad5a2b7df2345 Mon Sep 17 00:00:00 2001
> From: Aleksander Morgado <aleksan...@aleksander.es>
> Date: Tue, 18 Oct 2016 10:28:50 +0200
> Subject: [PATCH] broadband-modem-qmi: don't use PIN2 lock state if unknown
>
> ---
> src/mm-broadband-modem-qmi.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/mm-broadband-modem-qmi.c b/src/mm-broadband-modem-qmi.c
> index bc13925..b4f7b56 100644
> --- a/src/mm-broadband-modem-qmi.c
> +++ b/src/mm-broadband-modem-qmi.c
> @@ -1792,8 +1792,14 @@ dms_uim_get_pin_status_ready (QmiClientDms *client,
> _status,
> NULL, /* verify_retries_left */
> NULL, /* unblock_retries_left */
> -NULL))
> -lock = mm_modem_lock_from_qmi_uim_pin_status (current_status, FALSE);
> +NULL)) {
> +MMModemLock lock2;
> +
> +/* We only use the PIN2 status if it isn't unknown */
> +lock2 = mm_modem_lock_from_qmi_uim_pin_status (current_status,
> FALSE);
> + if (lock2 != MM_MODEM_LOCK_UNKNOWN)
> +lock = lock2;
> +}
>
> /* We're done! */
> g_simple_async_result_set_op_res_gpointer (ctx->result, GUINT_TO_POINTER
> (lock), NULL);
> --
> 2.10.0
>
--
David McCullough, david.mccullo...@accelerated.com, Ph: 0410 560 763
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
incorrect 'locked' status
Hi All, I have had a problem here on the MC7304 using Vodfone SIMs (AU). ModemManager is flagging the device as locked (PIN lock) even though there is no lock on the SIM. I ran it with DEBUG (just the PIN / locked transition is attached). Fairly recent clone of ModemManager, src/mm-iface-modem.c has not changed. The attached patch lets the modem connect fine but I figure it is probably not correct. Basically the new state (lock) is set to MM_MODEM_LOCK_UNKNOWN and the old state (old_lock) is also set to MM_MODEM_LOCK_UNKNOWN. For this condition the code transitions to the "locked" state. Let me know if you need and more info or debug, Cheers, Davidm -- David McCullough, david.mccullo...@accelerated.com, Ph: 0410 560 763 [1476737537.254666] [mm-broadband-modem-qmi.c:3267] load_power_state(): Getting device operating mode... [/dev/cdc-wdm0] Sent message... <<<<<< RAW: <<<<<< length = 13 <<<<<< data = 01:0C:00:00:02:03:00:08:00:2D:00:00:00 [/dev/cdc-wdm0] Sent message (translated)... <<<<<< QMUX: <<<<<< length = 12 <<<<<< flags = 0x00 <<<<<< service = "dms" <<<<<< client = 3 <<<<<< QMI: <<<<<< flags = "none" <<<<<< transaction = 8 <<<<<< tlv_length = 0 <<<<<< message = "Get Operating Mode" (0x002D) [/dev/cdc-wdm0] Received message... >>>>>> RAW: >>>>>> length = 24 >>>>>> data = >>>>>> 01:17:00:80:02:03:02:08:00:2D:00:0B:00:02:04:00:00:00:00:00:01:01:00:00 [/dev/cdc-wdm0] Received message (translated)... >>>>>> QMUX: >>>>>> length = 23 >>>>>> flags = 0x80 >>>>>> service = "dms" >>>>>> client = 3 >>>>>> QMI: >>>>>> flags = "response" >>>>>> transaction = 8 >>>>>> tlv_length = 11 >>>>>> message = "Get Operating Mode" (0x002D) >>>>>> TLV: >>>>>> type = "Result" (0x02) >>>>>> length = 4 >>>>>> value = 00:00:00:00 >>>>>> translated = SUCCESS >>>>>> TLV: >>>>>> type = "Mode" (0x01) >>>>>> length = 1 >>>>>> value = 00 >>>>>> translated = online [1476737537.287534] [mm-broadband-modem-qmi.c:1836] load_unlock_required_context_step(): loading unlock required (DMS)... [/dev/cdc-wdm0] Sent message... <<<<<< RAW: <<<<<< length = 13 <<<<<< data = 01:0C:00:00:02:03:00:09:00:2B:00:00:00 [/dev/cdc-wdm0] Sent message (translated)... <<<<<< QMUX: <<<<<< length = 12 <<<<<< flags = 0x00 <<<<<< service = "dms" <<<<<< client = 3 <<<<<< QMI: <<<<<< flags = "none" <<<<<< transaction = 9 <<<<<< tlv_length = 0 <<<<<< message = "UIM Get PIN Status" (0x002B) [/dev/cdc-wdm0] Received message... >>>>>> RAW: >>>>>> length = 32 >>>>>> data = >>>>>> 01:1F:00:80:02:03:02:09:00:2B:00:13:00:02:04:00:00:00:00:00:12:03:00:00:00:00:11:03:00:03:03:0A [/dev/cdc-wdm0] Received message (translated)... >>>>>> QMUX: >>>>>> length = 31 >>>>>> flags = 0x80 >>>>>> service = "dms" >>>>>> client = 3 >>>>>> QMI: >>>>>> flags = "response" >>>>>> transaction = 9 >>>>>> tlv_length = 19 >>>>>> message = "UIM Get PIN Status" (0x002B) >>>>>> TLV: >>>>>> type = "Result" (0x02) >>>>>> length = 4 >>>>>> value = 00:00:00:00 >>>>>> translated = SUCCESS >>>>>> TLV: >>>>>> type = "PIN2 Status" (0x12) >>>>>> length = 3 >>>>>> value = 00:00:00 >>>>>> translated = [ current_status = 'not-initialized' verify_retries_left >>>>>> = '0' unblock_retries_left = '0' ] >>>>>> TLV: >>>>>>
Re: ModemManager kills gpsd socket
Brent Sink wrote the following: > Hello, > > I have a Huawei mu609 mPCIe module that has GSM + GPS, and I'm using > ModemManager (and NetworkManager) to setup the connection to the network, > and gpsd to retrieve the GPS coordinates from the module. This module > creates 5 serial ports (ttyUSB0 - ttyUSB4). ttyUSB2 is used to send AT > commands, and ttyUSB3 is the output of the GPS data. If I disable > ModemManager, I can get the GPS data from gpspipe and from a gpsd socket > that I have created. > > However, when ModemManager is enabled, I no longer get any data from the > GPS. It seems like it just resets the device and gets rid of any > configurations I made. I realize that I can also get the GPS data inside > of ModemManager using --location-get-gps-nmea, but this has no connection > to my gpsd socket. > > Am I doing something wrong? Is there a way to still get data via a gpsd > socket while using ModemManager? Let me know if you need the debug logs. > Thanks! Pretty sure you want to look at '--location-enable-gps-unmanaged' to allow other processes to manage the GPS data on the GPS data port without MM getting in the way, MM will still setup the GPS parameters though, but you should be able to run gpsd on ttyUSB3, Cheers, Davidm -- David McCullough, david.mccullo...@accelerated.com, Ph: 0410 560 763 ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager kills gpsd socket
Brent Sink wrote the following:
> Well, I think I found the issue. On line #3365 in
> plugins/huawei/mm-broadband-modem-huawei.c, I found this:
>
> static char *gps_startup[] = {
> "^WPDOM=0",
> "^WPDST=1",
> "^WPDFR=65535,30",
> "^WPDGP",
> NULL
> };
>
> http://cgit.freedesktop.org/ModemManager/ModemManager/tree/plugins/huawei/mm-broadband-modem-huawei.c?id=1.4.0
>
> So, I guess I need to change this, unless there is a way to do this at
> runtime?
You got it, its hard coded to 30 seconds. Thats what I was refering to.
I am sure a patch to make it configurable would be welcome ;-)
You could try issuing:
mmcli -m XXX --command=^WPDFR=65535,1
after the modem connects ? Not sure if that will work (or stick for long)
Cheers,
Davidm
> On Mon, Sep 7, 2015 at 12:31 AM, Brent Sink <brent.s...@gmail.com> wrote:
>
> > Thanks David! I totally missed that one in the man page. I'm now able to
> > use gpsd on ttyUSB3. However, I noticed one strange thing... when I have
> > gpsd running without MM, I have it set up to report the position every 1
> > second. When MM is running, it seems to have changed it to every 30
> > seconds. I tried forcing it to report every 1s using the required AT
> > commands, but I can't seem to change it.
> >
> > You mentioned that MM will still setup the GPS parameters... is there a
> > way for me to change the parameters to report every 1s? The --command
> > option seems to only be available in debug mode.
> >
> > On Sun, Sep 6, 2015 at 9:21 PM, David McCullough <
> > david.mccullo...@accelerated.com> wrote:
> >
> >>
> >>
> >> Brent Sink wrote the following:
> >> > Hello,
> >> >
> >> > I have a Huawei mu609 mPCIe module that has GSM + GPS, and I'm using
> >> > ModemManager (and NetworkManager) to setup the connection to the
> >> network,
> >> > and gpsd to retrieve the GPS coordinates from the module. This module
> >> > creates 5 serial ports (ttyUSB0 - ttyUSB4). ttyUSB2 is used to send AT
> >> > commands, and ttyUSB3 is the output of the GPS data. If I disable
> >> > ModemManager, I can get the GPS data from gpspipe and from a gpsd socket
> >> > that I have created.
> >> >
> >> > However, when ModemManager is enabled, I no longer get any data from the
> >> > GPS. It seems like it just resets the device and gets rid of any
> >> > configurations I made. I realize that I can also get the GPS data
> >> inside
> >> > of ModemManager using --location-get-gps-nmea, but this has no
> >> connection
> >> > to my gpsd socket.
> >> >
> >> > Am I doing something wrong? Is there a way to still get data via a gpsd
> >> > socket while using ModemManager? Let me know if you need the debug
> >> logs.
> >> > Thanks!
> >>
> >> Pretty sure you want to look at '--location-enable-gps-unmanaged' to allow
> >> other processes to manage the GPS data on the GPS data port without MM
> >> getting in the way,
> >>
> >> MM will still setup the GPS parameters though, but you should be able to
> >> run gpsd on ttyUSB3,
> >>
> >> Cheers,
> >> Davidm
> >>
> >> --
> >> David McCullough, david.mccullo...@accelerated.com, Ph: 0410 560 763
> >>
> >
> >
> >
> > --
> > -brent
> >
>
>
>
> --
> -brent
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
--
David McCullough, david.mccullo...@accelerated.com, Ph: 0410 560 763
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: CPU loading issue
Marc Murphy wrote the following: I am using buildroot 2015.05 using glibc/eglibc Linaro toolchain gcc-linaro-arm-linux-gnueabihf-4.9-2014.05_linux Libqmi 1.12.6 MM 1.4.6 3.12 kernel Same issue is also on buildroot 2014.05 Hmm, ran over night, still at 4-5% CPU. I some some patches I have yet to send to the list in my tree, but I cannot see any of them making a difference. I am guessing you are going to have to go down the debug the problem path and get more info on the problem before you can find the cause. Cheers, Davidm -Original Message- From: ModemManager-devel [mailto:modemmanager-devel- boun...@lists.freedesktop.org] On Behalf Of David McCullough Sent: 11 June 2015 14:19 To: Marc Murphy Cc: 'Dan Williams'; 'modemmanager-devel@lists.freedesktop.org'; 'Aleksander Morgado' Subject: Re: CPU loading issue Marc Murphy wrote the following: My system is based on an AM3359 (BBB) running at 1GHz so should be able to cope with the GPS stream. If I use gdbserver and attach to MM, when the loading is getting really high I can pause the process and the loading instantly drops. If I wait a couple of seconds and resume the loading drops to a reasonable level and then slowly creeps up again. Ok, I have been running all day with the 1s setting, no change from my last update. Sitting at 4-6% and only peaking when we are doing other things to modem manager. I just updated to current master for libqmi and ModemManager just to be sure, so far its working the same, will see if it holds up over more than 30 minutes. What sort of build env are you using for your system ? I am running linux 3.10/uClibc built with gcc version 4.8.3. Latest modem manager, latest libqmi, linux native threads (uClibc), not sure what else might make a difference here. Cheers, Davidm Is there any timestamp logging that I can enable in a similar way to Gstreamer debug ? Cheers Marc -Original Message- From: ModemManager-devel [mailto:modemmanager-devel- boun...@lists.freedesktop.org] On Behalf Of David McCullough Sent: 11 June 2015 02:45 To: Aleksander Morgado Cc: Dan Williams; modemmanager-devel@lists.freedesktop.org; Marc Murphy Subject: Re: CPU loading issue Aleksander Morgado wrote the following: On Wed, Jun 10, 2015 at 4:30 PM, David McCullough david.mccullo...@accelecon.com wrote: I am using an embedded platform and after a bit of fiddling I have built the package and used it. Trace attached. Thanks; that gets us further since the two functions that are getting called all the time are match and pcre_exec. Unfortunately that doesn't tell us *which* regex this is... Aleksander, any ideas? Remember Marc has modded the GPS to send data every second. Maybe the Huawei is sending more info per second than other modesm are sending ? IIRC the GPS (NMEA?) dumps comes in on 2 of the USB tty ports, both of which MM is watching. The incoming data is parsed using the modem manager pattern matching, thus the match/pcre stuff you see. The GPS data can be fairly verbose from memory, depending on numbers of satelites etc, maybe we are just getting too much ? I am not and expert on the GPS data so I really can't say. Perhaps the combination of all modem chitchat is just queuing up and modem manager is getting behind ? I have a 400MHz ARM that I have been running the MU609 in for the last day. It polls at the default 30 seconds and is still running at 0% popping up to 5-6% every now and then. Could you maybe set the same 1s update in the MU609 and see if MM behaves worse in the same board? Running now, no signs yet. CPU is higher, always 4-6%, will see how it goes over time. Cheers, Davidm -- David McCullough, david.mccullo...@accelecon.com, Ph: 0410 560 763 ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel -- David McCullough, david.mccullo...@accelecon.com, Ph: 0410 560 763 ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel -- David McCullough, david.mccullo...@accelecon.com, Ph: 0410 560 763 ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
[PATCH] Fix '0' prefixed IMEI/ESN/MEID on QMI modems
QMI modems are incorrectly ignoring IMEI/ESN/MEID numbers that start with a
'0'. Fix this up. Seen on an ATT Beam (340u)
Signed-off-by: David McCullough david.mccullo...@accelecon.com
diff --git a/src/mm-broadband-modem-qmi.c b/src/mm-broadband-modem-qmi.c
index 4d234c6..f158fdf 100644
--- a/src/mm-broadband-modem-qmi.c
+++ b/src/mm-broadband-modem-qmi.c
@@ -1223,13 +1223,13 @@ dms_get_ids_ready (QmiClientDms *client,
*/
if (qmi_message_dms_get_ids_output_get_imei (output, str, NULL)
-str[0] != '\0' str[0] != '0') {
+str[0] != '\0') {
g_free (ctx-self-priv-imei);
ctx-self-priv-imei = g_strdup (str);
}
if (qmi_message_dms_get_ids_output_get_esn (output, str, NULL)
-str[0] != '\0' str[0] != '0') {
+str[0] != '\0') {
g_free (ctx-self-priv-esn);
len = strlen (str);
if (len == 7)
@@ -1241,7 +1241,7 @@ dms_get_ids_ready (QmiClientDms *client,
}
if (qmi_message_dms_get_ids_output_get_meid (output, str, NULL)
-str[0] != '\0' str[0] != '0') {
+str[0] != '\0') {
g_free (ctx-self-priv-meid);
len = strlen (str);
if (len == 14)
--
David McCullough, david.mccullo...@accelecon.com, Ph: 0410 560 763
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
