Re: [libmm-glib] MM API usage and GLib

Apologies for hijacking the thread, but I also have a need to write a C++ app to access certain MM 'status' info (IMIE, signal strength, etc). I can shell out to mmcli and awk/parse the response, but lib-based coding would probably be more 'correct'. I was struggling though to get to grips with

Re: Cinterion plugin - unsupported ^SIND="simstatus"

> On 01 January 2018 at 11:27 Colin Helliwell wrote: > > > > On 01 January 2018 at 10:48 Aleksander Morgado wrote: > > > > > > On Sat, Dec 30, 2017 at 4:30 PM, Colin Helliwell > > wrote: > > > > > >> On 30 December 2017 at 15:

Re: Cinterion plugin - unsupported ^SIND="simstatus"

> On 01 January 2018 at 10:48 Aleksander Morgado wrote: > > > On Sat, Dec 30, 2017 at 4:30 PM, Colin Helliwell > wrote: > > > >> On 30 December 2017 at 15:07 Colin Helliwell wrote: > >> > >> > >> The Cinterion plugin tries 'AT^SI

Re: Cinterion plugin - unsupported ^SIND="simstatus"

> On 30 December 2017 at 15:07 Colin Helliwell wrote: > > > The Cinterion plugin tries 'AT^SIND="simstatus",2' in after_sim_unlock(). I > have two Cinterion modems, neither of which - according to their AT Command > Set spec - support the simstatus indicator on

Cinterion plugin - unsupported ^SIND="simstatus"

The Cinterion plugin tries 'AT^SIND="simstatus",2' in after_sim_unlock(). I have two Cinterion modems, neither of which - according to their AT Command Set spec - support the simstatus indicator on this command, and so instead return "+CME ERROR: 21" (invalid index). Nonetheless, the operation

Re: Fwd: cinterion: modification to fetching unlock retries

> On 30 December 2017 at 11:38 Colin Helliwell wrote: > > > > From: Aleksander Morgado > > Date: Fri, Dec 29, 2017 at 10:09 PM > > Subject: Re: cinterion: modification to fetching unlock retries > > To: Colin Helliwell > > > > > > Hey

Re: PATCH: Make CSIM response parser a generic function

> On 30 December 2017 at 10:34 Colin Helliwell wrote: > > > > On 29 December 2017 at 22:01 Aleksander Morgado wrote: > > > > > > On Fri, Dec 29, 2017 at 9:21 AM, Colin Helliwell > > wrote: > > > As a precursor to a generic load_unlock_retries

Re: Fwd: cinterion: modification to fetching unlock retries

> From: Aleksander Morgado <aleksan...@aleksander.es> > Date: Fri, Dec 29, 2017 at 10:09 PM > Subject: Re: cinterion: modification to fetching unlock retries > To: Colin Helliwell > > > Hey, > > On Fri, Dec 29, 2017 at 2:27 PM, Colin Helliwell wrote: >

Re: PATCH: Make CSIM response parser a generic function

> On 29 December 2017 at 22:01 Aleksander Morgado wrote: > > > On Fri, Dec 29, 2017 at 9:21 AM, Colin Helliwell > wrote: > > As a precursor to a generic load_unlock_retries method, the attached patch > > moves the CSIM Response parser from the Telit plugin into th

PATCH: Make CSIM response parser a generic function

As a precursor to a generic load_unlock_retries method, the attached patch moves the CSIM Response parser from the Telit plugin into the core code. move_csim_parser.patch Description: Binary data ___ ModemManager-devel mailing list

Re: cinterion: modification to fetching unlock retries

> On 28 December 2017 at 17:39 Aleksander Morgado wrote: > > > >> >> >> > > Hi, I just wondered if there was any appetite for re-visiting > >> >> >> > > this issue. The latest 'GTask' rework to the plugin means I'll > >> >> >> > > need to redo accordingly the patch I've been using - but

Re: cinterion: modification to fetching unlock retries

> On 28 December 2017 at 17:00 Aleksander Morgado wrote: > > > Hey Colin! > > >> >> > > Hi, I just wondered if there was any appetite for re-visiting this > >> >> > > issue. The latest 'GTask' rework to the plugin means I'll need to > >> >> > > redo accordingly the patch I've been using -

Re: cinterion: modification to fetching unlock retries

> On 28 December 2017 at 14:19 Aleksander Morgado wrote: > > > >> > > Hi, I just wondered if there was any appetite for re-visiting this > >> > > issue. The latest 'GTask' rework to the plugin means I'll need to redo > >> > > accordingly the patch I've been using - but thought I'd enquire

Re: Equipment info without SIM installed

> On 07 November 2017 at 18:16 Aleksander Morgado > wrote: > .. > > In the case above none of the commands we have was successful > determining capabilities :/ But we could improve the +CPIN? check and > also assume that if it's telling us "SIM not inserted" then it

Re: Roadmap for next stable 1.8?

> On 03 November 2017 at 08:55 Aleksander Morgado > wrote: > > Hey, > > It's been already a while since we released 1.6.0, and there are a lot > of things in git master that haven't been released yet, so maybe it's > time for a 1.8.0 release. > > I see two big

Re: cinterion: modification to fetching unlock retries

> On 09 October 2017 at 10:36 Aleksander Morgado > wrote: > > > Sorry - pasted the wrong URL! See instead: > > https://lists.freedesktop.org/archives/modemmanager-devel/2017-April/004485.html > > I didn't get to a point where I thought my patch would be > >

Re: cinterion: modification to fetching unlock retries

> On 09 October 2017 at 10:20 Aleksander Morgado > wrote: > > > > Some Cinterion modems support AT^SPIC to fetch the 'unlock retries', but > > > some don't. Another method possibly available is to used AT+CSIM (as per > > > Telit plugin). > > > This aims to allow

Re: cinterion: modification to fetching unlock retries

> On 14 April 2017 at 13:57 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > Some Cinterion modems support AT^SPIC to fetch the 'unlock retries', but > some don't. Another method possibly available is to used AT+CSIM (as per > Telit plugin). > This

Re: [PATCH] libmm-glib,sms: fix get|dup_data() introspection annotations

> On 26 September 2017 at 14:23 Aleksander Morgado > wrote: > > We need to specify explicitly that the return type is an array of > > guint8 elements. > > --- > > Hey Colin, > > Could you apply this patch and see if the generated introspection support > allows

Re: [PATCH] libmm-glib,sms: fix get|dup_data() introspection annotations

> On 26 September 2017 at 18:54 Aleksander Morgado > wrote: > > > > > I haven't yet explored parsing that response format, but another > > > > example follows. Can you sanity-check? At first glance it looks a > > > > little odd. > > > > > > > > mmcli -m 0 -s 1

Re: [PATCH] libmm-glib,sms: fix get|dup_data() introspection annotations

> On 26 September 2017 at 17:52 Dan Williams <d...@redhat.com> wrote: > > On Tue, 2017-09-26 at 16:15 +0100, Colin Helliwell wrote: > > > > On 26 September 2017 at 16:08 Colin Helliwell <colin.helliwell@ln-s > > > ystems.com> wrote: > > >

Re: [PATCH] libmm-glib,sms: fix get|dup_data() introspection annotations

> On 26 September 2017 at 16:08 Colin Helliwell > <colin.helliw...@ln-systems.com> wrote: > > > On 26 September 2017 at 14:23 Aleksander Morgado <aleksan...@aleksander.es> > > wrote: > > > > We need to specify explicitly that the return

Re: [PATCH] libmm-glib,sms: fix get|dup_data() introspection annotations

> On 26 September 2017 at 14:23 Aleksander Morgado > wrote: > > We need to specify explicitly that the return type is an array of > > guint8 elements. > > --- > > Hey Colin, > > Could you apply this patch and see if the generated introspection support > allows

Re: SMS get_data() with binary PDU

> On 25 September 2017 at 14:30 colin.helliw...@ln-systems.com wrote: > > This may be a python question rather than MM (!) but if a PDU SMS message > contains the data DEADBEEF then I see 'get_data()[1]' give a value of 4. But > how to extract the data bytes? > I think there must be an

Re: Received SMS with python

> On 21 September 2017 at 11:54 Colin Helliwell > <colin.helliw...@ln-systems.com> wrote: > > > On 19 September 2017 at 17:39 Aleksander Morgado <aleksan...@aleksander.es> > > wrote: > > > > ... > > > > Another (better?) option wou

Re: Received SMS with python

> On 19 September 2017 at 09:03 colin.helliw...@ln-systems.com wrote: > > I came across an old example (get-sms.py) using dbus, but are there any > examples via gi/Glib for reading and deleting received SMSs (and any events > that can be hooked for catching the reception)? > I'm guessing the

Re: Python libmm problems

> On 15 September 2017 at 16:46 Aleksander Morgado > wrote: > > > > > > Though this is coming together nicely now, I don't need the script to run > > forever once it's done its stuff. Is there a way send a HUP/TERM to itself? > > You can always quit the GLib main

Re: Python libmm problems

> On 14 September 2017 at 17:11 Dan Williams <d...@redhat.com> wrote: > > On Thu, 2017-09-14 at 15:35 +0100, Colin Helliwell wrote: > .. > > Thanks Dan. I've persevered with GLib, and made a bit of progress. > > On top of your suggestion - i

Re: Python libmm problems

> On 14 September 2017 at 17:11 Dan Williams <d...@redhat.com> wrote: > > On Thu, 2017-09-14 at 15:35 +0100, Colin Helliwell wrote: > .. > > Thanks Dan. I've persevered with GLib, and made a bit of progress. > > On top of your suggestion - i

Re: Python libmm problems

> On 13 September 2017 at 19:39 Dan Williams wrote: > ... > > The two major patterns for doing all of this are (a) threads and (b) > event-driven programming. GLib is an example of (b), and it really > does remove the error-prone issues of lock management, concurrent data >

Re: Python libmm problems

> On 13 September 2017 at 17:57 Dan Williams wrote: > > On Wed, 2017-09-13 at 17:23 +0100, colin.helliw...@ln-systems.com > wrote: > > > I'm trying to write some python to get the operator id off the > > modem. > > Due to limited knowledge of such things, I'm *not* using any >

Re: [PATCH] build: import gtk-doc support

> On 06 September 2017 at 20:18 Dan Williams wrote: > > On Mon, 2017-08-28 at 12:59 +0200, Aleksander Morgado wrote: > > > Remove the need to run `gtkdocize' when building from git; this > > should > > be an operation done by the maintainer when modernizing the gtk-doc > >

Re: Parallel enables occurring (when SIM PIN enabled)

> On 19 July 2017 at 09:19 Aleksander Morgado <aleksan...@aleksander.es> wrote: > > On Wed, Jul 19, 2017 at 8:42 AM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > But I wondered whether anything had been re-structured elsewhere which >

Re: Parallel enables occurring (when SIM PIN enabled)

> On 19 July 2017 at 07:42 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > > On 26 April 2017 at 17:48 Aleksander Morgado <aleksan...@aleksander.es> > > wrote: > > > > On Wed, Apr 26, 2017 at 6:23 PM, Dan Williams <d

Re: [PATCH 2/4] build: only define WITH_SYSTEMD_JOURNAL if enabled

> On 22 June 2017 at 16:39 Aleksander Morgado <aleksan...@aleksander.es> wrote: > > On Thu, Jun 22, 2017 at 3:56 PM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > I think this is broken (along the lines of Ben's #if/#ifdef question).

Re: [PATCH 2/4] build: only define WITH_SYSTEMD_JOURNAL if enabled

I think this is broken (along the lines of Ben's #if/#ifdef question). Configuring with --with-systemd-journal results in #define WITH_SYSTEMD_JOURNAL 0 in config.h, but the code (e.g. mm-log.c) is using a '#if defined' ? > On 22 June 2017 at 09:59 Aleksander Morgado

Re: Received SMS and where they'll be stored

> On 23 May 2017 at 14:19 colin.helliw...@ln-systems.com wrote: > > I'm re-exploring what happens through MM with received SMS - and could do > with some clarification on how it all interacts (modem vs. MM). > > # mmcli -m 0 --messaging-status > > /org/freedesktop/ModemManager1/Modem/0 > >

Re: [PATCH1 1/4 v3] helpers: new 'AT+CMER=?' parser

> On 22 May 2017 at 13:43 Aleksander Morgado wrote: > > --- > > Hey Colin, > > Please try now with this v3 patch. I modified the helper method to allow the > comma-separated number sequence you get in your EHS5 for the modes, i.e.: > "(1,2)". The regex wasn't

Re: [PATCH 2/4 v2] broadband-modem: query +CMER format before enabling/disabling

> On 22 May 2017 at 12:47 Aleksander Morgado wrote: > > Don't blindly try '+CMER=3,0,0,1' to enable and '+CMER=0' to disable > Mobile Equipment Event Reporting. We now query the device for the > > supported formats and use that info to build commands that will work. >

Re: [PATCH 2/4] broadband-modem: query +CMER format before enabling/disabling

> On 22 May 2017 at 12:22 Aleksander Morgado <aleksan...@aleksander.es> wrote: > > On Mon, May 22, 2017 at 12:36 PM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > > Don't blindly try '+CMER=3,0,0,1' to enable and '+CMER=0' to disable

Re: [PATCH 2/4] broadband-modem: query +CMER format before enabling/disabling

> On 21 May 2017 at 13:54 Aleksander Morgado wrote: > > Don't blindly try '+CMER=3,0,0,1' to enable and '+CMER=0' to disable > Mobile Equipment Event Reporting. We now query the device for the > > supported formats and use that info to build commands that will work. >

Re: [PATCH 1/2] log: new --log-func-loc option to enable function location in logs

> On 22 May 2017 at 09:14 Aleksander Morgado wrote: > > Hey, > > On Thu, May 18, 2017 at 12:43 PM, Aleksander Morgado > wrote: > > > The --debug output is a bit annoying right now because it includes the > > function location information by

Re: [PATCH 1/2] log: new --log-func-loc option to enable function location in logs

> On 18 May 2017 at 12:51 Thomas Haller wrote: > > On Thu, 2017-05-18 at 12:43 +0200, Aleksander Morgado wrote: > > > The --debug output is a bit annoying right now because it includes > > the > > function location information by default. This information is most of > > the

Re: [PATCH] iface-modem: fix setting up signal quality retrieval logic

> On 15 May 2017 at 11:30 Aleksander Morgado wrote: > > If going directly e.g. from "Searching" to "Connecting", just setup > the signal quality retrieval logic right away, don't assume we always > go through "Registered" state before starting a connection. > >

Re: Parallel enables occurring (when SIM PIN enabled)

> On 25 April 2017 at 15:43 Dan Williams <d...@redhat.com> wrote: > > On Tue, 2017-04-25 at 10:32 +0200, Aleksander Morgado wrote: > > > On Tue, Apr 25, 2017 at 10:20 AM, Colin Helliwell > > > > <colin.helliw...@ln-systems.com> wrote: > >

Parallel enables occurring (when SIM PIN enabled)

I've encountered a problem when using MM with Network Manager, when the SIM PIN is enabled - in short it seems that MM is able to hit a state where two 'enable' operations are happening in parallel, one from unlocking the SIM and one from starting the 'simple connect'. The detail and discussion

Re: [PATCH] telit: add error_code recognition to +CSIM parser

> On 18 April 2017 at 16:40 Aleksander Morgado <aleksan...@aleksander.es> wrote: > > On Tue, Apr 18, 2017 at 5:20 PM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > To keep things simple for now, these logs are with an unlocked SIM. Thi

Re: [PATCH] telit: add error_code recognition to +CSIM parser

> On 18 April 2017 at 15:32 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > > On 18 April 2017 at 15:05 Carlo Lobrano <c.lobr...@gmail.com> wrote: > > > > Hi Aleksander, > > > > see below my reply > > > > Il giovedì

Re: cinterion: modification to fetching unlock retries

> On 18 April 2017 at 14:11 Aleksander Morgado <aleksan...@aleksander.es> wrote: > > On Tue, Apr 18, 2017 at 2:07 PM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > > Colin; does your modem accept +CSIM=1 / +CSIM=0 to lock/unlo

Re: [PATCH] telit: add error_code recognition to +CSIM parser

> On 18 April 2017 at 15:05 Carlo Lobrano wrote: > > Hi Aleksander, > > see below my reply > > Il giovedì 6 aprile 2017, Aleksander Morgado ha > scritto: > > > Hey Carlo, > > > > On 04/04/17 14:55, Carlo Lobrano wrote: > > > - Refactored

Re: cinterion: modification to fetching unlock retries

> On 18 April 2017 at 09:20 Aleksander Morgado wrote: > > On Tue, Apr 18, 2017 at 9:59 AM, Carlo Lobrano wrote: > > > the examples in the docs do not show quoted strings, but I just gave a try > > with a couple of modems and I saw no problems. >

Re: [PATCH 1/2] modem-helpers: if operator not in UCS2, see if already valid UTF-8

> On 14 April 2017 at 23:15 Aleksander Morgado <aleksan...@aleksander.es> wrote: > > On Fri, Apr 14, 2017 at 4:57 PM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > Might have hung this off the wrong thread, but it's along the same line

Re: [PATCH 1/2] modem-helpers: if operator not in UCS2, see if already valid UTF-8

Might have hung this off the wrong thread, but it's along the same lines. I've just noticed that whilst the mmcli status now decodes the operator, the --sim status doesn't: # mmcli -m 0 ... 3GPP | imei: '358606050452806' | enabled locks: 'none' |

Re: cinterion: modification to fetching unlock retries

> On 14 April 2017 at 13:57 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > Some Cinterion modems support AT^SPIC to fetch the 'unlock retries', but some > don't. Another method possibly available is to used AT+CSIM (as per Telit > plugin). > This

Re: [PATCH v3] telit: unsupported CSIM lock should not skip loading unlock retries

Hi, This thread turns out to be relevant to the latest in my battle with Cinterion modules. Their EHS5 doesn't support AT^SPIC, but it turns out it does support the CSIM commands used by the telit plugin - https://developer.gemalto.com/tutorial/how-query-pin-counter-ehsx Looks like there may be

Re: Try to normalize both operator name and code

> On 25 March 2017 at 20:39 Aleksander Morgado wrote: > > Hey Colin and Dan, > > What do you think of these two patches? > > Cheers! > > [PATCH 1/2] modem-helpers: if operator not in UCS2, see if already > [PATCH 2/2] broadband-modem: normalize also operator code >

Re: PPP modem differences

s/pin AT root@wg2xx-tx6s:~# cat /etc/ppp/chatscripts/mode AT root@wg2xx-tx6s:~# cat /etc/ppp/chatscripts/apn AT+CGDCONT=1,"IP","wap.vodafone.co.uk" === > On 22 March 2017 at 15:59 Dan Williams <d...@redhat.com> wrote: > > On Wed, 2017-03-22 at 14:41 +

Re: PPP modem differences

> On 22 March 2017 at 15:59 Dan Williams <d...@redhat.com> wrote: > > On Wed, 2017-03-22 at 14:41 +, Colin Helliwell wrote: > > > > On 22 March 2017 at 13:50 Dan Williams <d...@redhat.com> wrote: > > > > > > On Wed, 2017-03-22 at 13:2

Re: PPP modem differences

> On 22 March 2017 at 13:50 Dan Williams wrote: > > On Wed, 2017-03-22 at 13:23 +, colin.helliw...@ln-systems.com > wrote: > > > I know this might not be an issue with MM, but as there's also a lot > > of > > modem-savvy people here.. :) > > > > I've got the same system

Re: PPP port being left open?

> On 22 March 2017 at 13:43 Dan Williams wrote: > > On Wed, 2017-03-22 at 10:40 +, colin.helliw...@ln-systems.com > wrote: > > > I've noticed a situation where MM seems to not be fully closing the > > PPP > > port. [1.8 Master, updated probably a couple of days ago] > >

Re: Unexpected COPS format

> On 17 March 2017 at 19:56 Aleksander Morgado wrote: > > On Fri, Mar 17, 2017 at 6:40 PM, Dan Williams wrote: > > > I ended up with something like: > > > > void > > mm_3gpp_normalize_operator_id (gchar **id, > > MMModemCharset cur_charset) > > { >

Re: Unexpected COPS format

> On 17 March 2017 at 15:02 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > > On 17 March 2017 at 14:16 colin.helliw...@ln-systems.com wrote: > > > > I’m reviewing the info fetched on my modems, and one of them is giving an > >

Re: Unexpected COPS format

> On 17 March 2017 at 14:16 colin.helliw...@ln-systems.com wrote: > > I’m reviewing the info fetched on my modems, and one of them is giving an > unusual format for “AT+COPS=3,2;+COPS?” : > >    +COPS: 0,2,"00320033003400310035",0 > > This seems to be some sort of ‘wide char’ hex

Re: Cinterion 'simstatus'

> On 09 March 2017 at 08:02 Aleksander Morgado wrote: > > On Wed, Mar 8, 2017 at 9:29 PM, Reinhard Speyerer wrote: > > > > I'll look for a command which can achieve the same test - perhaps the > > > function could switch over to the alternative if it

Re: 'port forced close' after failed ppp

> On 16 March 2017 at 16:23 Dan Williams <d...@redhat.com> wrote: > > On Thu, 2017-03-16 at 13:36 +, Colin Helliwell wrote: > > > > On 14 March 2017 at 14:18 Colin Helliwell <colin.helliwell@ln-syste > > > ms.com> wrote: > > >

Re: 'port forced close' after failed ppp

> On 14 March 2017 at 14:18 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > > On 13 March 2017 at 09:53 Colin Helliwell <colin.helliw...@ln-systems.com> > > wrote: > > > > > On 13 March 2017 at 09:06 Colin Helliwe

Re: 'port forced close' after failed ppp

> On 14 March 2017 at 17:55 Dan Williams <d...@redhat.com> wrote: > > On Tue, 2017-03-14 at 14:18 +, Colin Helliwell wrote: > > > Still trying to get to the bottom of this problem. > > What are the events which can cause the G_IO_HUP (in MM)? > > G_I

Re: 'port forced close' after failed ppp

> On 14 March 2017 at 14:18 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > > On 13 March 2017 at 09:53 Colin Helliwell <colin.helliw...@ln-systems.com> > > wrote: > > > > > On 13 March 2017 at 09:06 Colin Helliwe

Re: 'port forced close' after failed ppp

> On 13 March 2017 at 09:53 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > > On 13 March 2017 at 09:06 Colin Helliwell <colin.helliw...@ln-systems.com> > > wrote: > > > > > On 10 March 2017 at 16:54 Aleksander Morgado <aleksan.

Re: 'port forced close' after failed ppp

> On 13 March 2017 at 09:06 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > > On 10 March 2017 at 16:54 Aleksander Morgado <aleksan...@aleksander.es> > > wrote: > > > > On Fri, Mar 10, 2017 at 5:43 PM, Aleksander

Re: 'port forced close' after failed ppp

> On 10 March 2017 at 16:54 Aleksander Morgado wrote: > > On Fri, Mar 10, 2017 at 5:43 PM, Aleksander Morgado > wrote: > > > > > > mmcli -m 0 --enable > > > > > mmcli -m 0 --simple-connect="apn=wap.vodafone.co.uk" > > > > > pon > > > > >

Re: ModemManager and ppp

> On 10 March 2017 at 16:37 Aleksander Morgado wrote: > > On Fri, Mar 10, 2017 at 5:24 PM, Tom Hayward wrote: > > > I'm a new user of ModemManager and trying to understand the scope of > > the software. > > > > I've used ModemManager

Re: 'port forced close' after failed ppp

> On 08 March 2017 at 14:38 Aleksander Morgado <aleksan...@aleksander.es> wrote: > > On Wed, Mar 8, 2017 at 3:08 PM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > But this brings me back (in a round-the-houses way!) to my origin

Re: 'port forced close' after failed ppp

> On 08 March 2017 at 14:08 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > Firstly the SIM I've mostly been using ['SIM1'] seems to have a problem > establishing a PPP - it gets through the LCP negotiation but then fails the > IPCP negotiation. > Dunn

Re: 'port forced close' after failed ppp

> On 07 March 2017 at 13:50 Aleksander Morgado <aleksan...@aleksander.es> wrote: > > On Tue, Mar 7, 2017 at 1:26 PM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > > Mar 7 10:05:25 wg2 daemon.debug pppd[944]: sent [IPCP ConfReq id=0

Re: Cinterion 'simstatus'

lt;aleksan...@aleksander.es> wrote: > > On Wed, Mar 8, 2017 at 1:45 PM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > I'll look for a command which can achieve the same test - perhaps the > > function could switch over to the alternative if it gets an 'un

Re: Cinterion 'simstatus'

I'll look for a command which can achieve the same test - perhaps the function could switch over to the alternative if it gets an 'unsupported' error? (My modems give a "+CME ERROR: 22") > On 08 March 2017 at 12:32 Aleksander Morgado wrote: > > On Wed, Mar 8, 2017 at

Re: [PATCH] cinterion: improve ^SCFG=? response parser to handle EHS5 format

given). > > We now support at least these two formats: > ^SCFG: "Radio/Band",("1-511","0-1") > ^SCFG: "Radio/Band\",("1"-"147") > > Reported-by: Colin Helliwell <colin.helliw...@ln-systems.com> > > --

Re: Parsing Cinterion RadioBand

> On 07 March 2017 at 16:28 Aleksander Morgado wrote: > > On Mon, Mar 6, 2017 at 11:38 AM, wrote: > > > I’m using the Cinterion plugin on an EHS5. This does include ‘Radio Band’ in > > its response to ‘AT^SCFG=?’, but in a format that

Re: 'port forced close' after failed ppp

> On 07 March 2017 at 09:43 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > (Sorry - misformatted that last one) > > > On 06 March 2017 at 16:47 Dan Williams <d...@redhat.com> wrote: > > > > On Mon, 2017-03-06 at 15:35 +0

Re: glib-mkenums error for ublox plugin

> On 15 February 2017 at 08:49 Aleksander Morgado > wrote: > >> (By the way - the configure summary is reporting "ModemManager 1.7.0"?) > >That is normal. The version in git master is 1.7.x; the next stablemajor >release will be 1.8.0. Is there a schedule for

Re: Modem creation/startup order

> On 15 February 2017 at 18:04 Aleksander Morgado > wrote: > ... > > The purpose of ID_MM_PHYSDEV_UID is to have the user provide a "unique > id" which may be used as name when referencing a modem, e.g. "mmcli -m > NAME"; but that also serves the purpose of binding

Re: Updated plugin not being found

On 16 February 2017 at 11:23 colin.helliw...@ln-systems.com wrote: > > I’m doing quite a bit of debug of a plugin, and simply copying the new .so > into the plugins directory. Oh, and also rebuilding the ModemManager now and > again. > > This did work a few times, but I’ve got a situation

Re: Cinterion plugin (in)compatibilities

> On 14 February 2017 at 23:07 Aleksander Morgado <aleksan...@aleksander.es> > wrote: > > On Tue, Feb 14, 2017 at 10:51 AM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > > > > I'm not confident of correctly interpreting

Re: glib-mkenums error for ublox plugin

> On 15 February 2017 at 09:12 Aleksander Morgado > wrote: > > On Wed, Feb 15, 2017 at 9:49 AM, Aleksander Morgado > wrote: > > > Worst case, we just add a custom mkdir step in those enums generation rules. > > Could you test the attached

Re: Modem creation/startup order

> On 15 February 2017 at 15:07 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > > On 15 February 2017 at 14:11 Aleksander Morgado <aleksan...@aleksander.es> > > wrote: > > > > Is the logic stopping there? the ID_MM_PHYSDEV_UID should

Re: Modem creation/startup order

> On 15 February 2017 at 14:11 Aleksander Morgado <aleksan...@aleksander.es> > wrote: > > On Wed, Feb 15, 2017 at 10:46 AM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > > > I get the feeling its written with nearly-but-n

Re: Modem creation/startup order

> On 15 February 2017 at 09:18 Aleksander Morgado <aleksan...@aleksander.es> > wrote: > > On Wed, Feb 15, 2017 at 10:00 AM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > > On 14 February 2017 at 17:28 Dan Williams <d...@redha

Re: Modem creation/startup order

> On 14 February 2017 at 17:28 Dan Williams <d...@redhat.com> wrote: > > On Tue, 2017-02-14 at 15:16 +, Colin Helliwell wrote: > > > > On 14 February 2017 at 12:59 Aleksander Morgado <aleksander@aleksan > > > der.es> wrote: > > > >

Re: glib-mkenums error for ublox plugin

> On 14 February 2017 at 21:40 Aleksander Morgado > wrote: > > On Tue, Feb 14, 2017 at 7:51 PM, Aleksander Morgado > wrote: > > > Could you apply the attached patch and retry? It could just be the > > order of the files generated, because

Re: ABOUT-NLS missing?

On 14 February 2017 at 15:34 colin.helliw...@ln-systems.com wrote: > > Just updated my env setup to the latest master > (git://anongit.freedesktop.org/ModemManager/ModemManager), but configure is > giving an error: > > configure.ac:86: error: required file './ABOUT-NLS' not found > > Am I

Re: Modem creation/startup order

> On 14 February 2017 at 12:59 Aleksander Morgado <aleksan...@aleksander.es> > wrote: > > On Tue, Feb 14, 2017 at 12:54 PM, Colin Helliwell > ... > > > Yes, the idea is that both ports end up grabbed in the same modem. How > > > are these ports exposed b

Re: Modem creation/startup order

> On 14 February 2017 at 11:33 Aleksander Morgado <aleksan...@aleksander.es> > wrote: > > On Tue, Feb 14, 2017 at 11:39 AM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > > > Thanks. The question arises from needing to have mon

Re: Modem creation/startup order

> On 13 February 2017 at 13:40 Aleksander Morgado <aleksan...@aleksander.es> > wrote: > > On Mon, Feb 13, 2017 at 2:05 PM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > > > Thanks. The question arises from needing to have mon

Re: Cinterion plugin (in)compatibilities

> On 14 February 2017 at 09:30 Aleksander Morgado <aleksan...@aleksander.es> > wrote: > > On Tue, Feb 14, 2017 at 10:10 AM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > > > > ... > > > > > I'm not confident

Re: Cinterion bug? (Re: Handling received SMS)

> On 14 February 2017 at 09:19 Aleksander Morgado <aleksan...@aleksander.es> > wrote: > > On Tue, Feb 14, 2017 at 9:11 AM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > > > All I'm seeing in the logs is "+CIEV:

Cinterion bug? (Re: Handling received SMS)

> On 13 February 2017 at 09:48 Aleksander Morgado > wrote: > > On Mon, Feb 13, 2017 at 9:13 AM, wrote: > > > All I'm seeing in the logs is "+CIEV: message,1". > > Checking back through the logs for unsolicited event setups, I also see

Re: Cinterion plugin (in)compatibilities

> On 13 February 2017 at 14:14 Aleksander Morgado <aleksan...@aleksander.es> > wrote: > > On Mon, Feb 13, 2017 at 2:56 PM, Colin Helliwell > > <colin.helliw...@ln-systems.com> wrote: > > > > > For simplicity, I’d begun my exploration of MM using t

Re: Handling received SMS

> On 13 February 2017 at 11:46 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > > On 13 February 2017 at 09:48 Aleksander Morgado <aleksan...@aleksander.es> > > wrote: > > > > On Mon, Feb 13, 2017 at 9:13 AM, <colin.helliw...@

Re: Cinterion plugin (in)compatibilities

> On 10 February 2017 at 17:52 Aleksander Morgado > wrote: > > On Fri, Feb 10, 2017 at 3:40 PM, wrote: > > > For simplicity, I’d begun my exploration of MM using the Generic plugin. My > > design has a choice of two Cinterion modems

  1   2   >