On Tue, Apr 10, 2018 at 7:30 PM, Matthew Starr wrote:
> For the TOBY-R2, LISA-R2, and LARA-R2, the only valid AT ports are
> ttyACM0, ttyACM1, and ttyACM2. All other ttyACM ports cause MM to
> wait 20-30 seconds probing the port on startup.
>
> Ignoring the non-AT ttyACM ports allows MM to not wa
On Sat, Apr 28, 2018 at 10:38 AM, Aleksander Morgado
wrote:
> The PDP contexts that are found with an empty APN configured are right
> now used as placeholders that can be overwritten with the user
> provided APN if no direct match is found.
>
> We want to keep that logic in pla
On Mon, Apr 30, 2018 at 1:11 PM, Aleksander Morgado
wrote:
> If the serial port timeout detection logic is enabled, warn whenever
> more than one consecutive command timeout happens, not just when the
> limit is reached.
> ---
This one pushed to git master already, for 1.8.
&g
If the serial port timeout detection logic is enabled, warn whenever
more than one consecutive command timeout happens, not just when the
limit is reached.
---
src/mm-base-modem.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/src/mm-base-m
A short series of patches to improve the detection of broken modems. In this
case, we try to detect modems that are still exposed in the USB layer but which
don't reply to any of our AT commands.
The first patch is a small cleanup that I wouldn't mind to get included right
away in git master. T
We have a maximum number of timeouts that could be enabled for TTY
modems, e.g. to detect whether the modem is available in the RS232
port or has been unplugged. This was required because RS232 modems
aren't notified via udev, so there was no other way to check presence
of the modem.
But, the same
On 28/04/18 20:51, Ben Chan wrote:
> ---
> src/mm-broadband-modem-qmi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
Pushed to git master, thanks.
> diff --git a/src/mm-broadband-modem-qmi.c b/src/mm-broadband-modem-qmi.c
> index d87c39aa..898906c8 100644
> --- a/src/mm-broadband-modem-qmi.c
> +
The PDP contexts that are found with an empty APN configured are right
now used as placeholders that can be overwritten with the user
provided APN if no direct match is found.
We want to keep that logic in place, but for the case where we do get
an empty APN requested by the user, we need to perfo
Hey,
Distributions have started to ship 1.8 RC1 and RC2 versions, and we
already have some reports about the strict filter not picking up some
ZTE and Huawei devices:
https://bugs.freedesktop.org/show_bug.cgi?id=106234
https://bugs.freedesktop.org/show_bug.cgi?id=106253
Those reports are actuall
On 25/04/18 02:18, Ben Chan wrote:
> Commit 708b00ae3 "modem: allow periodic signal check to be disabled"
> added a "iface-modem-periodic-signal-check-disabled" property in
> MMIfaceModem/MMBroadbandModem to indicate if the periodic signal check
> should be disabled. If the property is set to TRUE,
On Tue, Apr 24, 2018 at 1:24 AM, Ben Chan wrote:
> ModemManager currently relies on unsolicited MBIM_CID_SIGNAL_STATE
> notifications to obtain signal quality updates, and it doesn't query the
> initial signal quality. It's been observed that some MBIM modems issue a
> MBIM_CID_SIGNAL_STATE notifi
On Tue, Apr 24, 2018 at 1:24 AM, Ben Chan wrote:
> ModemManager decides to disable periodic signal check if either
> load_signal_quality is not implemented or load_signal_quality returns an
> unsupported error. However, in some cases, we want to use
> load_signal_quality to query the initial signa
>
> > > > Distributions wanting to use a different filter policy than the
> > > > DEFAULT one were advised to patch themselves the corresponding
> > > > init
> > > > files.
> > > >
> > > > We now allow doing this directly at configure time by using a new
> > > > `--with-filter-policy=[POLICY]' opti
Hey,
>
> I have a rule in place, but I'm having some trouble with this new build w/
> udev that I've implemented. Getting this undefined symbol error. Using nm
> I see that a number of the symbols in ModemManager are undefined. Was there
> something I missed during build?
>
> pi@raspberrypi:/ $
>
> Until the GPS support is added into the u-blox plugin or something like the
> ID_MM_GPS_PORT flag is added, could MM safely just ignore the GPS port like
> in this patch? Once support is added, the flagging of the GPS ports can be
> changed/removed. Right now there is a 20 second timeout p
> A number of plugins do this, like mbm or Cinterion. But unfortunately
> the ublox plugin doesn't support GPS yet, and it turns out we can't yet
> prevent those known GPS ports from being probed either since they get
> tagged during the "grab" phase after probing. So nevermind... (though
> woul
On Wed, Apr 11, 2018 at 4:10 AM, Dan Williams wrote:
> On Tue, 2018-04-10 at 15:08 +0200, Aleksander Morgado wrote:
>> Distributions wanting to use a different filter policy than the
>> DEFAULT one were advised to patch themselves the corresponding init
>> files.
>>
Distributions wanting to use a different filter policy than the
DEFAULT one were advised to patch themselves the corresponding init
files.
We now allow doing this directly at configure time by using a new
`--with-filter-policy=[POLICY]' option that accepts one of "default",
"strict", "paranoid" or
Hey!
> I added the "mmcli -m 0 -e" right after starting ModemManager, but in this
> case I got the message:
> error: couldn't find the ModemManager process in the bus
>
Like directly after starting MM? MM needs time to boot and expose
interfaces in DBus, you shouldn't be trying to enable a modem
On Tue, Apr 3, 2018 at 3:45 PM, Matthew Starr wrote:
> This patch fixed the issue. The u-blox LARA R204 modem now works without any
> issues. Thanks.
>
Pushed the fix to git master.
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing
The 'any' mode refers to the mode which includes most access
technologies and where none of them is preferred.
Fix the logic so that all combinations with one technology preferred
over the others are ignored, instead of the other way around.
Fixes assertion with the 4G-only LARA R204.
ModemM
Hey hey,
This 1.7.991 version, tagged as 1.8-rc2, is the second release candidate
version for the next 1.8.0 stable release, which will be the base for the next
stable 1.8.x series.
The changes w.r.t. the 1.8-rc1 version are:
* Added improvements and fixes in the MBIM bearer connection/discon
>
> mmcli -m 0 shows 'ttyUSB3; as primary whereas ttyUSB4 as part of ports as
> below. [Why two devices, I am not understanding. but I went ahead].
>
>
> System | device:
> '/sys/devices/pci:00/:00:16.0/usb1/1-1/1-1.1'
>|drivers: 'option1, huawei_cdc_ncm'
Hey,
> How do prevent MM from accessing one or all of the serial ports?
>
>
>
> I have tried adding udev rules for MM to ignore only the serial ports but
> this does not work
>
> KERNEL=="ttyACM*", ENV{ID_MM_DEVICE_IGNORE}="1"
>
Try with ID_MM_PORT_IGNORE.
And remember to re-trigger udev events
We shouldn't be limiting the power off state from a non-enabled one
only, in the same way we always allow doing a reset from any state.
---
src/mm-iface-modem.c | 53 +---
1 file changed, 21 insertions(+), 32 deletions(-)
diff --git a/src/mm-iface-m
On Tue, Mar 6, 2018 at 10:10 PM, Aleksander Morgado
wrote:
> On Tue, Mar 6, 2018 at 5:56 PM, Aleksander Morgado
> wrote:
>> We used ttyACM0 as secondary port until now, just because we had an
>> extra AT capable TTY around in addition to the main control ttyACM2
>> port
>> >> >| state: 'connected'
>> >> >|power state: 'on'
>> >> >|access tech: 'lte'
>> >> >| signal quality: '62' (recent)
>> >>
>> >> Well, that means you're connected in LTE :)
>> >
>> >
>> > That makes sense :-) I got confused by very
On Thu, Mar 8, 2018 at 12:19 AM, Henrique Ferreiro
wrote:
>> >| state: 'connected'
>> >|power state: 'on'
>> >|access tech: 'lte'
>> >| signal quality: '62' (recent)
>>
>> Well, that means you're connected in LTE :)
>
>
> That makes
>| state: 'connected'
>|power state: 'on'
>|access tech: 'lte'
>| signal quality: '62' (recent)
Well, that means you're connected in LTE :)
--
Aleksander
https://aleksander.es
___
ModemMa
On Tue, Mar 6, 2018 at 5:56 PM, Aleksander Morgado
wrote:
> We used ttyACM0 as secondary port until now, just because we had an
> extra AT capable TTY around in addition to the main control ttyACM2
> port.
>
> Turns out, using this ttyACM0 may actually break the connection setu
We used ttyACM0 as secondary port until now, just because we had an
extra AT capable TTY around in addition to the main control ttyACM2
port.
Turns out, using this ttyACM0 may actually break the connection setup
in the wwan interface in a bad way (e.g. not allowing DHCP setup).
The suggestion fro
>>> > > Was the wwan0 interface down while you executed simple-connect?
>>> >
>>> > wwan0 being up is the most likely cause. But seeing the debug logs
>>> > to
>>> > confirm this would be good.
>>> >
>>> > I started thinking about solving this in the driver, but ended up
>>> > falling back to the
>>
>> Was the wwan0 interface down while you executed simple-connect?
>
> wwan0 being up is the most likely cause. But seeing the debug logs to
> confirm this would be good.
>
> I started thinking about solving this in the driver, but ended up
> falling back to the original decision: The interface
Hey,
On Mon, Mar 5, 2018 at 12:03 AM, Henrique Ferreiro
wrote:
> Thanks everybody for all answers. I checked the dd-wrt wiki page and finally
> went for the D-Link DWM-222 (there weren't much more options to buy from
> local retailers).
>
> I have a few questions regarding ModemManager after test
Hey,
On Mon, Mar 5, 2018 at 2:55 AM, Steven P wrote:
> $ pacman -Qi libqmi libmbim linux modemmanager | grep -B 1 Version
> Name: libqmi
> Version : 1.20.0-1
> --
> Name: libmbim
> Version : 1.16.0-1
> --
> Name: linux
> Version : 4.15.6
Hey!
> Managed to figure it out - things only work if the interface is in raw_ip
> mode:
>
> sudo sh -c 'echo Y > /sys/class/net/wwan0/qmi/raw_ip'
>
> Would appreciate if there's a way to get ModemManager to set this
> automatically, and I'm sort of curious about the mode that the
> interface is
Hey,
> I have MM version 1.6.4 running on Linux and I am using it to communicate
> with a Telit LE910 V2 over MBIM and AT.
>
> Along with MM I have running my own process that sends and receives AT
> commands over one of the serial interfaces (ttyACM0).
>
> -
>
> Hard
On 22/02/18 17:55, Dan Williams wrote:
>> Releasing the port on the device looks benign but because it emits
>> a signal, it could call device_context_port_released and unref the
>> MMDevice in port_context_unref. This means the MMDevice might be
>> disposed before we get to the g_object_ref and th
On 21/02/18 22:49, Eric Caruso wrote:
> Releasing the port on the device looks benign but because it emits
> a signal, it could call device_context_port_released and unref the
> MMDevice in port_context_unref. This means the MMDevice might be
> disposed before we get to the g_object_ref and the sub
Hey!
On Wed, Feb 21, 2018 at 5:52 PM, Henrique Ferreiro
wrote:
> Thanks for the info. Actually, that manual is from my carrier's web page :-)
>
> I guess if no one can recommend a qmi/mbim modem I'll go for the ones with a
> Web UI.
>
I feel like I should really be suggesting you one, as I do al
On Wed, Feb 21, 2018 at 1:04 AM, Eric Caruso wrote:
> The hashtable is keyed on the UID of the MMDevice, and its hash
> function is g_str_hash. We shouldn't be passing a GObject into
> g_hash_table_remove because calling g_str_hash on an MMDevice is
> wrong.
> ---
> src/mm-base-manager.c | 2 +-
>
> That worked then had the same issues for libqmi. I updated libqmi to 1.20.0
> and then got the patch error. I then removed the libqmi patches as well.
Oh! Nice thing.
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemMan
On Tue, Feb 20, 2018 at 7:02 PM, Russ Westrem
wrote:
>
>
> On Tue, Feb 20, 2018 at 11:53 AM, Aleksander Morgado
> wrote:
>>
>> Hey!
>>
>> >> make[8]: Entering directory
>> >>
>> >> '/home/russ/MM/source/build_dir/target
Hey!
>> make[8]: Entering directory
>> '/home/russ/MM/source/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/libmbim-1.15.0-20161123/src/libmbim-glib'
>> CC libmbim_glib_core_la-mbim-device.lo
>> mbim-device.c: In function 'initable_init_async':
>> mbim-device.c:2168:15: error: assignment f
On Tue, Feb 20, 2018 at 1:29 AM, Russ Westrem
wrote:
>
> make[8]: Entering directory
> '/home/russ/MM/source/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/libmbim-1.15.0-20161123/src/libmbim-glib'
> CC libmbim_glib_core_la-mbim-device.lo
> mbim-device.c: In function 'initable_init_async'
Hey,
>
> Hi! https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/
> looks quite outdated. Can anyone here recommend any 4G USB dongle which works
> reasonably well on Linux?
>
Oh yea, that list was built for MM 1.0, quite a long time ago...
> In particular, does the Huawei
On Thu, Feb 8, 2018 at 6:55 PM, Dan Williams wrote:
> In mm_iface_modem_3gpp_register_in_network() when deciding whether to
> force automatic registration or not, check whether the modem is already
> registered in a network. Just checking whether we have a valid operator
> code is not sufficient,
>
> There is still an issue that exists where if the GSM connection in
> NetworkManager is setup for "connection.autoconnect yes". At boot it the GSM
> connection now takes 70-90 seconds to connect after the start of trying,
> which is 1.5 to 2 times as long as it used to be. It looks like
>
On Tue, Feb 6, 2018 at 5:31 AM, Ben Chan wrote:
> ---
> src/mm-broadband-modem.c | 64
> ++--
> 1 file changed, 29 insertions(+), 35 deletions(-)
>
Pushed to git master, thanks.
> diff --git a/src/mm-broadband-modem.c b/src/mm-broadband-modem.c
> ind
On Mon, Feb 5, 2018 at 5:37 PM, Dan Williams wrote:
> On Mon, 2018-02-05 at 09:53 +0100, Aleksander Morgado wrote:
>> We should only depend on GLib on the libmm-glib headers. Otherwise,
>> packages using just the core headers (e.g. ModemManagerQt) would also
>> need to build-
On Fri, Feb 2, 2018 at 4:30 PM, Dan Williams wrote:
> On Thu, 2018-02-01 at 14:39 +0100, Mbortolazzo wrote:
>> I have a problem with mmcli to control GPS nmea on two different
>> Modem: Sierra EM7455 and Huawei ME906S.
>
> GPS functionality is highly dependent on the modem model and firmware
> and
We should only depend on GLib on the libmm-glib headers. Otherwise,
packages using just the core headers (e.g. ModemManagerQt) would also
need to build-depend on GLib and we don't want to enforce that.
cd ~/buildroot/output/build/kde-modemmanager-qt-v5.36.0/src &&
~/buildroot/output/host/usr/
On Fri, Jan 26, 2018 at 11:25 PM, Ben Chan wrote:
>
> On Huawei ME936, the hex numbers in the response to AT^DHCP contain the 0x
> prefix, e.g.
>
> AT^DHCP?
>
> ^DHCP:
> 0xda7d0e0a,0xff00,0xdb7d0e0a,0xdb7d0e0a,0x01261aac,0x,1,5000
>
> This patch updates mm_huawei_pars
Hey hey,
This 1.7.990 version, tagged as 1.8-rc1, is the first release candidate version
for the next 1.8.0 stable release, which will be the base for the next stable
1.8.x series.
The following notes are directed to package maintainers.
* This version requires:
** GLib 2.36.0
** gettex
On 28/12/17 18:41, Aleksander Morgado wrote:
> The +CEMODE command is defined in 3GPP TS 27.007 (e.g. in section
> 10.1.28 in v11.0.0). This command allows querying or updating the
> current UE mode, as well as checking the supported modes.
>
> We implement support for loading t
On 28/12/17 18:41, Aleksander Morgado wrote:
> The UE modes of operation for LTE are defined in 3GPP TS 24.301 (e.g.
> section 4.3 in v10.3.0):
> * PS mode 1: EPS only, 'voice centric'
> * PS mode 2: EPS only, 'data centric'
> * CS/PS mode 1: EPS and non-EP
On Thu, Jan 18, 2018 at 6:07 PM, Dan Williams wrote:
> On Thu, 2018-01-18 at 16:33 +0100, Aleksander Morgado wrote:
>> As per USB-IF "Class definitions for Communication Devices 1.2" docs.
>
> LGTM.
>
Merged to git master, thanks for checking!
--
Alek
As per USB-IF "Class definitions for Communication Devices 1.2" docs.
Reported-by: Iván Sánchez Ortega
---
src/mm-filter.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/mm-filter.c b/src/mm-filter.c
index ca0241a0..6526cfaa 100644
--- a/src/mm-filt
On Thu, Jan 18, 2018 at 4:13 PM, Russ Westrem
wrote:
> I just ordered a em7565. Does modem manager work with this device?
>
Yeah
$ mmcli -m 2
/org/freedesktop/ModemManager1/Modem/2 (device id
'6d6932782c57502d0c37a650280b9a9f7b61520a')
-
Hardware | manufacturer: '
>> The following two patches implement support for loading and updating
>> the UE mode of operation for EPS, as defined by 3GPP TS 27.007 and
>> 3GPP TS 24.301.
>>
>> Comments?
>
> Patches look OK to me. I wonder what this knob is for QMI though...
>
Absolutely no idea how to configure this in QM
Hey!
>
> I just have a couple of questions regarding the operation of ModemManager and
> LuCI integration.
>
> 1. I have an interface configuration in /etc/config/network which reads very
> similarly to the one on the modemmanager-openwrt bitbucket readme file. Upon
> startup of my system, the
Hey hey,
>
> What is the meaning of lock status 'sim-pin2'? According to the
> specification: 'SIM requires the PIN2 code.'.
>
> Why is the modem then connected?
>
> Status | lock: 'sim-pin2'
>| unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10),
> sim-puk2 (10)'
>
Hey Kelvin,
>
> Is there a way to debug ModemManager's detection of a modem?
>
> I have built a kernel with support for the Telit LE910, enabling
> CONFIG_USB_SERIAL_OPTION and CONFIG_USB_NET_QMI_WWAN. The expected five
> /dev/ttyUSBx and one /dev/cdc-wdm0 devices are present. But when I run
> "mm
Hey!
>
> I discovered that the problem can be resolved by unloading some kernel
> modules and restarting modem manager.
>
> rmmod huawei_cdc_ncm
> rmmod cdc_mbim
> rmmod sierra
> rmmod sierra_net
> /etc/init.d/modemmanager restart
>
> mmcli -m 0 -d
> mmcli -m 0 -e
> mmcli -m 0 --simple-connect="a
Hoola Ana,
>
> is there a reason why my embedded MM 1.6.4-1 only grabs these two ports
> (wwan and cdc-wdm0) of the PHS8?
>
This is very likely because the kernel itself didn't expose the TTY
ports. Do you see the ttyUSBx interfaces in this setup? Which kernel
version are you using here?
>
> If
On Fri, Jan 12, 2018 at 8:47 AM, Ben Chan wrote:
> When a modem is being enabled, an initial registration check is
> scheduled to determine the current registration state and access
> technology. The initial registration check is performed asynchronously
> and may not complete before the modem sta
>> > ModemManager currently relies on unsolicited MBIM_CID_SIGNAL_STATE
>> > notification to obtain signal quality updates, and it doesn't query
>> > the
>> > initial signal quality. I've observed that some MBIM modems issue a
>> > MBIM_CID_SIGNAL_STATE
>> > notification only when there is a notabl
On Fri, Jan 5, 2018 at 12:02 PM, Carlo Lobrano wrote:
> On Jan 4 2018, at 2:05 pm, Carlo Lobrano wrote:
>
>> I'll have a look at that today or tomorrow at the most, thanks a lot!
>>
>
> I tested the patch on both LE910 and HE910 (just to test a modem that
> supports csim lock and one that does no
On Wed, Jan 3, 2018 at 4:49 PM, Dan Williams wrote:
> On Mon, 2017-12-25 at 20:02 +0100, Aleksander Morgado wrote:
>> The AT control TTYs in the u-blox modems may take some time to be
>> usable. In order to handle this issue, we configured some longer
>> timeouts during AT
The generic broadband modem provides a common method to load unlock
retries based on CSIM queries. We modify the Telit plugin to use the
generic method but keeping the CSIM locking/unlocking logic in place.
---
Hey Carlo & everyone,
The following patch tries to re-use the logic that loads unlock
On 30/12/17 15:23, Colin Helliwell wrote:
> plugins/cinterion/mm-broadband-modem-cinterion.c | 92
> 1 file changed, 55 insertions(+), 15 deletions(-)
>
> diff --git a/plugins/cinterion/mm-broadband-modem-cinterion.c
> b/plugins/cinterion/mm-broadband-modem-cinterion.c
>
On 30/12/17 14:19, Colin Helliwell wrote:
>
>> 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
>>>
On 30/12/17 11: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 method, the attached patch
&
>> > >> 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"
>> > >> (inv
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^SIND="simstatus",2' in after_sim_unlock(). I
>> have two Cinterion modems, neither of which - according to their AT Command
>> Set spec - suppo
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 the core code.
Could you generate the patch with "git format-patch"? i.e. with a
proper git commit head
>>
>> Are you up to drafting patches for this? :)
>>
>
> Hmmm, bit nervous tbh! I only have an embedded platform to work on, which
> makes building n trying out a bit laborious. I'm also totally clueless on
> anything beginning with a 'g'! ;)
Oh, well, that is the thing that should worry you the
Hey,
The following two patches implement support for loading and updating the UE
mode of operation for EPS, as defined by 3GPP TS 27.007 and 3GPP TS 24.301.
Comments?
[PATCH 1/2] modem-3gpp: allow loading and changing EPS UE mode of...
[PATCH 2/2] broadband-modem: implement support for the
The UE modes of operation for LTE are defined in 3GPP TS 24.301 (e.g.
section 4.3 in v10.3.0):
* PS mode 1: EPS only, 'voice centric'
* PS mode 2: EPS only, 'data centric'
* CS/PS mode 1: EPS and non-EPS, 'voice centric'
* CS/PS mode 2: EPS and non-EPS, 'data centric'
The mode specifies, a
The +CEMODE command is defined in 3GPP TS 27.007 (e.g. in section
10.1.28 in v11.0.0). This command allows querying or updating the
current UE mode, as well as checking the supported modes.
We implement support for loading the current mode and updating it. It
is assumed that the device does any ad
>> >> >> > > 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 before embarking on that.
>> >> >> > You'r
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 thought I'd enquire
>> >> > > before embarking on that.
>> >> > You're t
>
> It looks like there are plans(2017) to change the format of ISO/7812 allowing
> an 8 digit IIN at the expense of the account number. I suspect you'll need to
> get hold of that spec, though I don't beleive it's available for free. See
> https://en.wikipedia.org/wiki/ISO/IEC_7812 for an overv
>> > > 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 before
>> > > embarking on that.
>> > You're talking about the parallel e
Hey,
It looks like there are SIMs out there that report an ICCID that is
not read correctly by ModemManager:
[1514406745.769547] (ttyACM2): --> 'AT+CRSM=176,12258,0,0,10'
[1514406745.797843] (ttyACM2): <-- '+CRSM:
145,15,"9868200C214365870921"OK
[1514406745.798699] couldn't load SIM identi
Hey hey,
This is a new release in the ModemManager 1.6.x series.
Overview of changes in ModemManager 1.6.12
---
* Blacklist:
** Ignored Pycom devices.
** Added Microchip's VID to the greylist.
* QMI:
** Fixed connection state machine when built
On Mon, Dec 25, 2017 at 8:02 PM, Aleksander Morgado
wrote:
> The AT control TTYs in the u-blox modems may take some time to be
> usable. In order to handle this issue, we configured some longer
> timeouts during AT probing, but that may not be always enough.
>
> The u-blox T
The AT control TTYs in the u-blox modems may take some time to be
usable. In order to handle this issue, we configured some longer
timeouts during AT probing, but that may not be always enough.
The u-blox TTYs will report readiness via a "+AT: READY" URC, which
we can use during custom initializat
On Thu, Dec 21, 2017 at 2:41 PM, Aleksander Morgado
wrote:
>
>
>
> On Thu, Dec 21, 2017 at 2:15 PM, Piotr Figiel wrote:
>>
>> Hi,
>> I dug into the issue a little bit deeper and I think I found the
>> source of the problem.
>> The connection state
On Thu, Dec 21, 2017 at 2:15 PM, Piotr Figiel wrote:
> Hi,
> I dug into the issue a little bit deeper and I think I found the
> source of the problem.
> The connection state machine seem to enter a dead end in
> mm-bearer-qmi.c on CONNECT_STEP_ENABLE_INDICATIONS_IPV4 case for
> libqmi < 1.18.0.
On Fri, Dec 15, 2017 at 9:45 AM, Ben Chan wrote:
> Depsite 3GPP TS 23.038 specifies that Unicode SMS messages are encoded in
> UCS-2, UTF-16 encoding is commonly used instead on many modern platforms to
> allow encoding code points that fall outside the Basic Multilingual Plane
> (BMP), such as Em
On 13/12/17 19:17, Eric Caruso wrote:
> When in low-power mode, some modems will not dispatch unsolicited
> notifications, such as for SIM hot swapping. There is code in
> MMBroadbandModemTelit to handle this by checking the SIM identifier
> during modem power up against the identifier cached in th
Hey,
On Sat, Dec 16, 2017 at 3:03 AM, Ben Chan wrote:
> On Fri, Dec 15, 2017 at 1:16 AM Aleksander Morgado wrote: > > Probably a
> good change; will test it once I have a chance. > > But regarding the last
> fallback, why is it better to return an empty > string than
On Fri, Dec 15, 2017 at 9:45 AM, Ben Chan wrote:
> Depsite 3GPP TS 23.038 specifies that Unicode SMS messages are encoded in
> UCS-2, UTF-16 encoding is commonly used instead on many modern platforms to
> allow encoding code points that fall outside the Basic Multilingual Plane
> (BMP), such as Em
On Thu, Dec 14, 2017 at 11:35 AM, Marcel wrote:
> Sorry for the spam, I just have another question which I forgot before:
> Can I find all the AT-commands in the log?
>
> Because I was reading a lot there and I was not quite sure.. to me it looks
> like if there are also some commands without an '
Hey,
> I've been building for a few months on a particular git commit
> (3e15dc15efd118a2e7af8f60727afc7fbb7db3a3). I'm planning to try out the
> latest Master - hopefully in readiness of a tagged release occurring soon.
> In case I encounter 'brokenness' on my system, and need to track through
>
On Wed, Dec 13, 2017 at 6:54 PM, Eric Caruso wrote:
> Thanks for catching these!
>
> On Wed, Dec 13, 2017 at 1:20 AM, Aleksander Morgado
> wrote:
>> > +MM_IFACE_MODEM_GET_INTERFACE (self)->check_for_sim_swap_finish (self,
>> > res, &error);
>>
Hey Eric,
On 13/12/17 03:21, Eric Caruso wrote:
> When in low-power mode, some modems will not dispatch unsolicited
> notifications, such as for SIM hot swapping. There is code in
> MMBroadbandModemTelit to handle this by checking the SIM identifier
> during modem power up against the identifier c
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 finished before doing
> 1.8.0, which is the GTask migration and especi
Hey Eric,
See comments inline.
On Tue, Nov 28, 2017 at 2:39 AM, Eric Caruso wrote:
> When in low-power mode, some modems will not dispatch unsolicited
> notifications, such as for SIM hot swapping. There is code in
> MMBroadbandModemTelit to handle this by checking the SIM identifier
> during mo
1301 - 1400 of 2974 matches
Mail list logo
