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 h
> 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:
> 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 '
> 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 ind
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 c
> 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
> 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
> From: Aleksander Morgado
> 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:
> > I fear though, that the fal
> 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
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
ModemManager-devel@li
> 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 though
> 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 - but
> 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 befo
> On 09 October 2017 at 10:30 Colin Helliwell wrote:
>
>
> > 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 possi
> 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 means
> it requires a SIM a
> On 07 November 2017 at 15:59 Aleksander Morgado
> wrote:
>
> Hey
>
> > I'd like to be able to get the h/w info without a SIM installed, but this
> > seems to cause modem_load_current_capabilities() to fail (because "AT_CPIN?"
> > errors). Hence the initialization overall fails.
> > I haven't
> 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 pending things that could get fi
> 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
> > mainstream-acceptable (it just 'wor
> 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 either method to be tried - if
> On 14 April 2017 at 13:57 Colin Helliwell
> 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 either metho
> 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 you to use the API? It should
> 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
> > > >
> > > > SMS '/org/
> On 26 September 2017 at 17:52 Dan Williams wrote:
>
> On Tue, 2017-09-26 at 16:15 +0100, Colin Helliwell wrote:
>
> > > On 26 September 2017 at 16:08 Colin Helliwell > > ystems.com> wrote:
> > >
> > > > On 26 September 2017
> On 26 September 2017 at 16:08 Colin Helliwell
> wrote:
>
> > 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.
> >
> > --
> 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 you to use the API? It should
> 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 erro
> On 21 September 2017 at 11:54 Colin Helliwell
> wrote:
>
> > On 19 September 2017 at 17:39 Aleksander Morgado
> > wrote:
> >
> > ...
> >
> > Another (better?) option would be to listen to updates in the
> > "Messages" pr
> On 19 September 2017 at 17:39 Aleksander Morgado
> wrote:
>
...
>
> Another (better?) option would be to listen to updates in the
> "Messages" property itself. E.g. just
> msging.connect('notify::messages',...) and setup a callback that will
> get called any time the Messages property is upd
> 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 Mode
> 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 loop and exit cleanly.
>
O
> On 14 September 2017 at 17:11 Dan Williams 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 - instead of the start-up "modems =
&g
> On 14 September 2017 at 17:11 Dan Williams 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 - instead of the start-up "modems =
&g
> 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
> access, and deadlock
> 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
> > notifcation
> >
> On 07 September 2017 at 08:32 Aleksander Morgado
> wrote:
>
> > Not sure if this is similar/same, but I have the same sort of issue when
> > enabling introspection (which I now need) and cross-compiling - discussed
> > here back in March.
> > I'm moving over now to using a stable release (i
> 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
> > setup (think of e.g.
> On 01 September 2017 at 17:17 Dan Williams wrote:
>
> On Fri, 2017-09-01 at 10:51 -0500, Dan Williams wrote:
>
> > On Fri, 2017-09-01 at 14:26 +0100, colin.helliw...@ln-systems.com
> > wrote:
> >
> > > I've been having a look at the modem-watcher-python example, and
> > > would like
> > > to
> On 19 July 2017 at 09:19 Aleksander Morgado wrote:
>
> On Wed, Jul 19, 2017 at 8:42 AM, Colin Helliwell
>
> wrote:
>
> > But I wondered whether anything had been re-structured elsewhere which
> > ought to address the problem anyway?
>
> Don't th
Yes, that seems to fix it
> On 19 July 2017 at 10:04 Aleksander Morgado wrote:
>
>
> Could you test the attached patch?
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modem
Just trying out this morning's Head revision, and it seems to be stalling at
the point it's trying to read its own number.
mmcli -L reports no modems, and the logs ends with (i.e. there's no further
messages at all):
Jul 19 09:19:19 wg daemon.debug ModemManager[830]: [1500452359.141518]
[src/m
> On 19 July 2017 at 07:42 Colin Helliwell
> wrote:
>
> > On 26 April 2017 at 17:48 Aleksander Morgado
> > wrote:
> >
> > On Wed, Apr 26, 2017 at 6:23 PM, Dan Williams wrote:
> >
> > > Patch was more for confirmation/debugging than intend
> On 26 April 2017 at 17:48 Aleksander Morgado wrote:
>
> On Wed, Apr 26, 2017 at 6:23 PM, Dan Williams wrote:
>
> >
> > Patch was more for confirmation/debugging than intended for commit. We
> > can plug this particular hole with patches like that, but probably want
> > to figure out a more
> On 22 June 2017 at 16:39 Aleksander Morgado wrote:
>
> On Thu, Jun 22, 2017 at 3:56 PM, Colin Helliwell
>
> wrote:
>
> > I think this is broken (along the lines of Ben's #if/#ifdef question).
> > Configuring with --with-systemd-journal results in
>
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 wrote:
>
> ---
> configur
Do an explicit longer initial timeout before we run the first check,
> and after that one setup the additional checks at a higher rate.
>
> Reported-by: Colin Helliwell
>
> ---
>
> Hey Colin,
>
> What do you think of this patch? Could you see if it helps with the issu
> 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
>
> ---
> 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 catching that logic, so instead
> 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.
>
> ---
>
> Hey Colin,
>
> On 22 May 2017 at 12:22 Aleksander Morgado wrote:
>
> On Mon, May 22, 2017 at 12:36 PM, Colin Helliwell
>
> wrote:
>
> > > Don't blindly try '+CMER=3,0,0,1' to enable and '+CMER=0' to disable
> > > Mobile Equipment Event Repo
> 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.
>
I've just tried this set
> 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 default. This information is most of
> > the times n
> 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 times not very usefu
> On 14 May 2017 at 18:32 Aleksander Morgado wrote:
>
> On Fri, May 12, 2017 at 3:40 PM, wrote:
>
> > I've been finding today that I'm getting failed connection attempts - it
> > looks like MM is checking the PDP ("+CGDACT?") whilst ppp/modem are still in
> > the process of getting themselves
> 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.
>
> Reported-by:
>
> ---
>
> Hey C
> On 08 May 2017 at 16:49 Dan Williams wrote:
>
> On Mon, 2017-05-08 at 10:17 +0100, colin.helliw...@ln-systems.com
> wrote:
>
> > I'm hooking together ModemManager and NetworkManager (without
> > systemd) and
> > would like to grab the Operator determined by MM when it enables the
> > modem
>
> On 25 April 2017 at 15:43 Dan Williams wrote:
>
> On Tue, 2017-04-25 at 10:32 +0200, Aleksander Morgado wrote:
>
> > On Tue, Apr 25, 2017 at 10:20 AM, Colin Helliwell
> >
> > wrote:
> >
> > > I've encountered a problem when using MM with
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
> On 18 April 2017 at 16:40 Aleksander Morgado wrote:
>
> On Tue, Apr 18, 2017 at 5:20 PM, Colin Helliwell
>
> wrote:
>
> > To keep things simple for now, these logs are with an unlocked SIM. This is
> > with my modified Cinterion plugin, which I've chuc
> On 18 April 2017 at 15:32 Colin Helliwell
> wrote:
>
> > 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:
&g
> On 18 April 2017 at 14:11 Aleksander Morgado wrote:
>
> On Tue, Apr 18, 2017 at 2:07 PM, Colin Helliwell
>
> wrote:
>
> > > Colin; does your modem accept +CSIM=1 / +CSIM=0 to lock/unlock the
> > > CSIM access? It's optional in the Telit plugin, but m
> 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 mm_telit_parse_csim_response in order to correctly
> 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.
>
> Ok, so maybe we should really move the logic
> On 15 April 2017 at 08:21 Colin Helliwell
> wrote:
>
> > On 14 April 2017 at 23:15 Aleksander Morgado
> > wrote:
> >
> > On Fri, Apr 14, 2017 at 4:57 PM, Colin Helliwell
> >
> > wrote:
> >
> > > Might have hung this off the
> On 14 April 2017 at 23:15 Aleksander Morgado wrote:
>
> On Fri, Apr 14, 2017 at 4:57 PM, Colin Helliwell
>
> wrote:
>
> > Might have hung this off the wrong thread, but it's along the same lines.
> > I've just noticed that whilst the mmcli status
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'
|operator
> On 14 April 2017 at 13:57 Colin Helliwell
> 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 either metho
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 either method to be tried - if the first step of the first
method fails (e.g. SPIC not supported), then try again us
> On 13 April 2017 at 12:07 Colin Helliwell
> wrote:
>
> 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 t
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
> 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
>
Ok with me
__
x27;ATZ'
#'OK' 'ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0'
'OK' @/etc/ppp/chatscripts/mode
'OK-AT-OK' @/etc/ppp/chatscripts/apn
'OK' 'ATDT*99***1#'
TIMEOUT 30
CONNECT ''
root@wg2xx-tx6s:~# cat /etc/ppp/chatscripts/
> On 22 March 2017 at 15:59 Dan Williams wrote:
>
> On Wed, 2017-03-22 at 14:41 +0000, Colin Helliwell wrote:
>
> > > On 22 March 2017 at 13:50 Dan Williams wrote:
> > >
> > > On Wed, 2017-03-22 at 13:23 +, colin.helliw...@ln-systems.com
> >
> 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 trying to make a pp
> 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]
> > mmcli -m 0 --enable
> 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)
> > {
> > g_assert (id);
> >
> > /* Some modems r
> On 17 March 2017 at 15:02 Colin Helliwell
> 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
> > unusual format for “AT+COPS=3,2;+COPS?” :
> >
> 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 representation
> 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 gets an
> > > 'unsupported' error? (My mode
> On 16 March 2017 at 16:23 Dan Williams wrote:
>
> On Thu, 2017-03-16 at 13:36 +0000, Colin Helliwell wrote:
>
> > > On 14 March 2017 at 14:18 Colin Helliwell > > ms.com> wrote:
> > >
> > > > On 13 March 2017 at 09:53 Colin Helliwell &g
> On 14 March 2017 at 14:18 Colin Helliwell
> wrote:
>
> > On 13 March 2017 at 09:53 Colin Helliwell
> > wrote:
> >
> > > On 13 March 2017 at 09:06 Colin Helliwell
> > > wrote:
> > >
> > > > On 10 March 2017 at 16:54 A
> On 15 March 2017 at 16:11 Dan Williams wrote:
>
> On Wed, 2017-03-15 at 15:36 +0000, Colin Helliwell wrote:
>
> >
> > No sign in the source of any calls to those functions.
> > Could the signal be being sent from a hardware and 'physical uart
> >
> On 14 March 2017 at 17:55 Dan Williams wrote:
>
> On Tue, 2017-03-14 at 14:18 +0000, 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_IO_HUP == POLLHUP from the
> On 14 March 2017 at 14:18 Colin Helliwell
> wrote:
>
> > On 13 March 2017 at 09:53 Colin Helliwell
> > wrote:
> >
> > > On 13 March 2017 at 09:06 Colin Helliwell
> > > wrote:
> > >
...
> > > Tracing in the driver, I can se
> On 13 March 2017 at 09:53 Colin Helliwell
> wrote:
>
> > On 13 March 2017 at 09:06 Colin Helliwell
> > wrote:
> >
> > > On 10 March 2017 at 16:54 Aleksander Morgado
> > > wrote:
> > >
> > > On Fri, Mar 10, 2017 at 5:43 PM,
> On 13 March 2017 at 09:06 Colin Helliwell
> wrote:
>
> > 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
&
> 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
> > > > > ... success ...
> > > > > poff
> > > > > mmcli -m 0
> 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 successfully with a cdc-wdm modem. It created a
> > wwan0 i
> On 09 March 2017 at 17:42 Dan Williams wrote:
>
> On Thu, 2017-03-09 at 09:19 +0000, Colin Helliwell wrote:
>
> > > On 08 March 2017 at 14:38 Aleksander Morgado
> > > wrote:
> > >
> > > On Wed, Mar 8, 2017 at 3:08 PM, Colin Helliwell
> &
> On 08 March 2017 at 14:38 Aleksander Morgado wrote:
>
> On Wed, Mar 8, 2017 at 3:08 PM, Colin Helliwell
>
> wrote:
>
> > But this brings me back (in a round-the-houses way!) to my original
> > question: when the PPP fails, for example with the ports assigned
> On 08 March 2017 at 14:08 Colin Helliwell
> 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.
> Dunno why - it has been wor
s for an external reason e.g. at the remote end,
then it can't retry?
> On 07 March 2017 at 13:50 Aleksander Morgado wrote:
>
> On Tue, Mar 7, 2017 at 1:26 PM, Colin Helliwell
>
> wrote:
>
> > > Mar 7 10:05:25 wg2 daemon.debug pppd[944]: sent [IPCP ConfReq
>
> On Wed, Mar 8, 2017 at 1:45 PM, Colin Helliwell
>
> 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 'unsupported'
> > error? (My
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 1:00 PM, wrote:
>
> > Th
at least these two formats:
> ^SCFG: "Radio/Band",("1-511","0-1")
> ^SCFG: "Radio/Band\",("1"-"147")
>
> Reported-by: Colin Helliwell
>
> ---
>
> Hey Colin,
>
> Could you test this patch in a real run? I a
> 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
> > mm_cinterion_parse_scfg_test () may not be able to pars
> On 07 March 2017 at 14:55 Aleksander Morgado wrote:
>
> On Tue, Mar 7, 2017 at 3:46 PM, Colin Helliwell
>
> wrote:
>
> > Yes, I see what you mean. Now, [my] confusion is: the PDP is (I believe)
> > being activated on ttyMux1 - the virtual port which is set
> On 07 March 2017 at 13:50 Aleksander Morgado wrote:
>
> On Tue, Mar 7, 2017 at 1:26 PM, Colin Helliwell
>
> wrote:
>
> > > Mar 7 10:05:25 wg2 daemon.debug pppd[944]: sent [IPCP ConfReq id=0x1
> > > ]
> > > Mar 7 10:05:25 wg2 daemon.info Modem
Is it right that MM should be showing the ppp port as going disconnected part
way through the ppp negotiation? [see below]
> On 07 March 2017 at 10:13 Colin Helliwell
> wrote:
>
> ...
> In case it's of use, here's the log of MM+pppd when trying (after a --enable
> On 07 March 2017 at 09:43 Colin Helliwell
> wrote:
>
> (Sorry - misformatted that last one)
>
> > On 06 March 2017 at 16:47 Dan Williams wrote:
> >
> > On Mon, 2017-03-06 at 15:35 +, colin.helliw...@ln-systems.com
> > wrote:
> >
>
(Sorry - misformatted that last one)
> On 06 March 2017 at 16:47 Dan Williams wrote:
>
> On Mon, 2017-03-06 at 15:35 +, colin.helliw...@ln-systems.com
> wrote:
>
> > I have MM hooked into a Mux driver which is presenting two virtual
> > ports:
> > one as the Primary, one for PPP. I'm attemp
1 - 100 of 130 matches
Mail list logo