Re: Modem creation/startup order

2017-02-16 Thread Aleksander Morgado
On Thu, Feb 16, 2017 at 1:31 PM, Colin Helliwell
 wrote:
>
> I'm back on this, trying to do it properly. I've removed by mod to 
> mm-plugin.c, and added a udev tag
>
> G_MODULE_EXPORT MMPlugin *
> mm_plugin_create (void)
> {
> static const gchar *subsystems[] = { "tty", "net", "usb", NULL };
> static const gchar *vendor_strings[] = { "cinterion", "siemens", NULL };
> static const guint16 vendor_ids[] = { 0x1e2d, 0x0681, 0 };
> static const gchar *drivers[] = { "linmux", NULL };
> static const MMAsyncMethod custom_init = {
> .async  = G_CALLBACK (cinterion_custom_init),
> .finish = G_CALLBACK (cinterion_custom_init_finish),
> };
> static const gchar *udev_tags[] = {
> "ID_MM_CINT_LINMUX",
> NULL
> };
>
> return MM_PLUGIN (
> g_object_new (MM_TYPE_PLUGIN_CINTERION,
>   MM_PLUGIN_NAME,   "Cinterion",
>   MM_PLUGIN_ALLOWED_SUBSYSTEMS, subsystems,
>   MM_PLUGIN_ALLOWED_UDEV_TAGS,  udev_tags,
>   MM_PLUGIN_ALLOWED_VENDOR_STRINGS, vendor_strings,
>   MM_PLUGIN_ALLOWED_VENDOR_IDS, vendor_ids,
>   MM_PLUGIN_ALLOWED_DRIVERS,drivers,
>   MM_PLUGIN_ALLOWED_AT, TRUE,
>   MM_PLUGIN_ALLOWED_QMI,TRUE,
>   MM_PLUGIN_CUSTOM_INIT,_init,
>   NULL));
> }
>
> i.e. I've left in, for now, the MM_PLUGIN_ALLOWED_DRIVERS/drivers additions.
> ENV{ID_MM_CINT_LINMUX}="1" is added to the udev rules, and everything 
> reloaded.
> Which puts me back to getting
> [src/mm-plugin.c:251] apply_pre_probing_filters(): (Cinterion) [ttyMux1] 
> filtered as couldn't retrieve drivers
> What would be the neatest way to address this?

Does it go on if you remove the MM_PLUGIN_ALLOWED_DRIVERS check?

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


Re: glib-mkenums error for ublox plugin

2017-02-16 Thread Aleksander Morgado
On Thu, Feb 16, 2017 at 2:24 PM, Colin Helliwell
 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 release of 1.8.0?  (At some point I'd like to get 
> onto a fixed tag/branch as opposed to tracking the head)

Not yet, no. We may want to sync with new distribution releases,
though, suggestions welcome.

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


Re: Updated plugin not being found

2017-02-16 Thread Colin Helliwell

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 where ModemManager isn’t 
> finding the plugin. I’m pretty sure I’m copying from the same place as 
> before. Is there something else needs updating, some broken linkage somewhere 
> in what I’ve now got on the system?
> 
>  


Ah, ok  - I think I was looking at the wrong part of the debug output :S
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


Re: glib-mkenums error for ublox plugin

2017-02-16 Thread Colin Helliwell

> 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 release of 1.8.0?  (At some point I'd like to get onto 
a fixed tag/branch as opposed to tracking the head)
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


Re: Updated plugin not being found

2017-02-16 Thread Aleksander Morgado
On Thu, Feb 16, 2017 at 12:23 PM,   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 where ModemManager isn’t
> finding the plugin. I’m pretty sure I’m copying from the same place as
> before. Is there something else needs updating, some broken linkage
> somewhere in what I’ve now got on the system?


You need to take into account that the ModemManager program will look
for the plugin files in the ${libdir}/ModemManager directory set
during compilation.
When building the project, are you using a explicit --prefix or a
explicit --libdir? If you're using none of them, then by default the
plugins directory will be /usr/local/lib/ModemManager and that is
where MM would look for plugins; likely not what you want. So maybe
you copied over a new ModemManager program that was built without the
correct prefix?

Just make sure you use the same prefix paths when doing your own local
builds and the real system builds (this is assuming you're building
locally and copying file to a remote system). If both build and target
systems are the same; e.g. building and running on the same machine,
better use "make install" to install files in the correct place
directly.

What's the exact error you're getting anyway?

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


Re: Modem creation/startup order

2017-02-16 Thread Colin Helliwell

> 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 together ports with
> the same "unique id", as the default "unique id" being used right now
> is the sysfs path of the physical device (the one that owns all
> ports).
> 

OK, I've added that and now - albeit with an ugly hack because of the 'parent' 
issue in the driver - have the two ports on the same modem. Might try again on 
the driver at some later date.
Thanks for guidance.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


Re: Cinterion plugin (in)compatibilities

2017-02-16 Thread Colin Helliwell

> On 14 February 2017 at 23:07 Aleksander Morgado  
> wrote:
> 
> On Tue, Feb 14, 2017 at 10:51 AM, Colin Helliwell
> 
>  wrote:
> 
> > > > > I'm not confident of correctly interpreting the regex in 
> > > > > smong_query_ready() (let alone fixing it properly!), but I wonder if 
> > > > > the SMONG problem is that it's getting an additional CRLF. The 
> > > > > response to the command is
> > > > > 
> > > > > GPRS MonitorBCCH G PBCCH PAT MCC MNC NOM TA RAC # Cell #
> > > > 
> > > > Sorry, that should be
> > > > 'GPRS MonitorBCCH G PBCCH PAT MCC MNC NOM TA RAC # Cell # 44 1 - - 234 
> > > > 10 - - - OK'
> > > 
...
> > 
> > Still reporting as invalid reply, I'm afraid.
> 
> Please retry with the attached patch and let me know if you have any
> issue in the ^SMONG response parsing.
> 

Yep, that appears to have solved it. Thanks.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


Re: Cinterion plugin (in)compatibilities

2017-02-16 Thread Aleksander Morgado
On Thu, Feb 16, 2017 at 11:22 AM, Colin Helliwell
 wrote:
>> > > > > I'm not confident of correctly interpreting the regex in 
>> > > > > smong_query_ready() (let alone fixing it properly!), but I wonder if 
>> > > > > the SMONG problem is that it's getting an additional CRLF. The 
>> > > > > response to the command is
>> > > > >
>> > > > > GPRS MonitorBCCH G PBCCH PAT MCC MNC NOM TA RAC # Cell #
>> > > >
>> > > > Sorry, that should be
>> > > > 'GPRS MonitorBCCH G PBCCH PAT MCC MNC NOM TA RAC # Cell # 44 1 - - 234 
>> > > > 10 - - - OK'
>> > >
> ...
>> >
>> > Still reporting as invalid reply, I'm afraid.
>>
>> Please retry with the attached patch and let me know if you have any
>> issue in the ^SMONG response parsing.
>>
>
> Yep, that appears to have solved it. Thanks.

Thanks for checking; pushed to git master and backported to mm-1-6 and mm-1-4.

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


Locking MM to 4g only

2017-02-16 Thread Russ Westrem
Im am trying to lock to 4g only.

  Modes|  supported: 'allowed: 2g, 3g, 4g; preferred: none'
   |current: 'allowed: 2g, 3g, 4g; preferred: none'



root@LEDE:~# mmcli -m 0 --set-allowed-modes=4g
error: couldn't set current modes:
'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Unsupported: Cannot
change modes: only one combination supported'
root@LEDE:~# mmcli -m 0 --set-preferred-mode=4g
error: setting preferred mode requires list of allowed modes
root@LEDE:~#
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


Re: Locking MM to 4g only

2017-02-16 Thread Aleksander Morgado
On Thu, Feb 16, 2017 at 4:29 PM, Russ Westrem
 wrote:
> Im am trying to lock to 4g only.
>
>   Modes|  supported: 'allowed: 2g, 3g, 4g; preferred: none'
>|current: 'allowed: 2g, 3g, 4g; preferred: none'
>
>
>
> root@LEDE:~# mmcli -m 0 --set-allowed-modes=4g
> error: couldn't set current modes:
> 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Unsupported: Cannot
> change modes: only one combination supported'

Is this in MBIM mode? There isn't any support for mode/capabilities
changing in plain MBIM mode. If this is in QMI mode, try
--set-current-capabilities=lte instead. ModemManager only exposes the
list of mode combinations that are allowed by the modem in the current
capability. See
https://sigquit.wordpress.com/2013/06/03/changing-modes-and-capabilities-in-modemmanager/

> root@LEDE:~# mmcli -m 0 --set-preferred-mode=4g
> error: setting preferred mode requires list of allowed modes

--preferred-mode must be given with --allowed-modes. E.g. there may be
a combination saying "allowed 2G, 3G and 4G" but preferred "4G".

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


Re: Locking MM to 4g only

2017-02-16 Thread Russ Westrem
On Feb 16, 2017 2:00 PM, "Dan Williams"  wrote:

On Thu, 2017-02-16 at 17:36 +0100, Aleksander Morgado wrote:
> On Thu, Feb 16, 2017 at 4:29 PM, Russ Westrem
>  wrote:
> > Im am trying to lock to 4g only.
> >
> >   Modes|  supported: 'allowed: 2g, 3g, 4g; preferred: none'
> >|current: 'allowed: 2g, 3g, 4g; preferred: none'
> >
> >
> >
> > root@LEDE:~# mmcli -m 0 --set-allowed-modes=4g
> > error: couldn't set current modes:
> > 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Unsupported:
> > Cannot
> > change modes: only one combination supported'
>
> Is this in MBIM mode? There isn't any support for mode/capabilities
> changing in plain MBIM mode. If this is in QMI mode, try
> --set-current-capabilities=lte instead. ModemManager only exposes the
> list of mode combinations that are allowed by the modem in the
> current
> capability. See
> https://sigquit.wordpress.com/2013/06/03/changing-modes-and-capabilit
> ies-in-modemmanager/
>
> > root@LEDE:~# mmcli -m 0 --set-preferred-mode=4g
> > error: setting preferred mode requires list of allowed modes
>
> --preferred-mode must be given with --allowed-modes. E.g. there may
> be
> a combination saying "allowed 2G, 3G and 4G" but preferred "4G".

It's probably Russ's 7455 in QMI mode?

For QMI MM doesn't allow specific mode selection/enablement either, see
the QMI implementation of modem_load_supported_modes().  If the modem
supports NAS >= 1.21 (or slightly earlier) then with
NASSystemSelectionPreference we could use the ordered radio interface
list to pass to TLV 0x1E (AcquisitionOrder).

libqmi doesn't support that, but I just did a patch for it.  However, I
can't quite figure out the relationship between "Mode Preference" and
the radio interface order array for the TLV I added.  Maybe somebody
else can test and find out?

Dan

Yes it's the mc7455 in qmi mode.  I locked it in using an at command.
After this it showed only 4g in mmcli.  It still didn't solve my problem so
back to the drawing board.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel