Hey,
>>
>> I am a little bit surprised that the modem uses the ppp-interface in your
>> case. When I read your logfiles right, then you have a device which is sold
>> under the name "Speedsick LTE V" in Germany.
>
> How do you achieve non-PPP option in nm-applet? Whenever I select "Mobile
> broad
would start the
ball rolling to improve the docs.
>
> Aleksander Morgado wrote:
>> On Thu, Jan 12, 2017 at 3:49 PM, Martin MOKREJŠ wrote:
>>> # mmcli --connect -m /org/freedesktop/ModemManager1/Modem/0
>>> error: no bearer was specified
>>
>> --connect is a bea
Hey,
On Fri, Jan 13, 2017 at 9:42 PM, Martin MOKREJŠ wrote:
>>| supported: 'gsm-umts'
>>|current: 'gsm-umts'
>>| equipment id: '864346025664162'
>> -
>> System | device: '/sys/devices/pci:00/:00:1d.7/
On Fri, Jan 13, 2017 at 10:12 PM, Martin MOKREJŠ wrote:
> thank you Alexander for clarification, I infer there is something wrong
> with my cdc-wdm then. Isn't there anything interesting in the NM debug logs I
> sent to the list already?
This is the only interesting thing I found:
Jan 12 12:
On Sat, Jan 14, 2017 at 1:16 AM, Martin MOKREJŠ wrote:
> Anyway, there are a few lines about the cdc-wdm0 but does not seem to be
> much verbose. A few AT commands failed but on the ttyUSB1.
Yeah, no AT command was correctly replied in the cdc-wdm interface so
we couldn't use it :/
--
Aleksa
Hey,
On Mon, Jan 23, 2017 at 2:20 PM, Mark Wahlert wrote:
> Hello. I've built OpenWrt from trunk (Kernel 4.4.14) including ModemManager
> and its dependencies.
>
> With my mc7455 in QMI mode, PPP interface is established and the internet is
> accessible.
>
> With modem in MBIM mode, expected int
On Mon, Jan 23, 2017 at 3:10 PM, Aleksander Morgado
wrote:
> It would also be a good idea to retrieve ModemManager debug logs; you
> can modify the MM daemon init file and add --debug
> --log-file=/var/log/mm.log to get them.
I realize this may not be very clear. In the case of the p
On Mon, Jan 23, 2017 at 11:35 PM, Alex Pintilie wrote:
>
> if you can't help me with this no one can. I have a T460s Lenovo with Debian
> and this EM7455 thing that refuses to work.
>
> I posted all the info I could find here:
>
> http://pastebin.com/1yzvTzit
>
> I use only one SIM card, which wor
On 24/01/17 08:08, Ben Chan wrote:
> This patch fixes an uninitialized variable issue in
> mm_ublox_parse_ugcntrd_response_for_cid(), which uses an uninitialized
> `match_info' when `in_cid' is invalid.
Pushed to git master, thanks!
> ---
> plugins/ublox/mm-modem-helpers-ublox.c | 2 +-
> 1 file
On 24/01/17 08:07, Ben Chan wrote:
> This patch fixes a bug in packet_service_status_indication_cb(), which
> incorrectly treats the MMBearerStatus enum value returned by
> mm_base_bearer_get_status() as a MMBearerConnectionStatus enum value.
> MMBearerStatus and MMBearerConnectionStatus can't be u
Hey,
[1485259217.322211] [mm-bearer-mbim.c:319]
ip_configuration_query_ready(): IPv4 configuration available:
'address, gateway, dns, mtu'
[1485259217.322293] [mm-bearer-mbim.c:325]
ip_configuration_query_ready(): IP addresses (1)
[1485259217.322813] [mm-bearer-mbim.c:329]
ip_configuration_qu
On Tue, Jan 24, 2017 at 2:30 PM, Bjørn Mork wrote:
>> Aleksander - have you had the mc7455 working in OpenWrt in MBIM?
>
Yes; I had it working, although I should check which kernel version I
was running. Will do that later today.
> Just a side note: It might work without the "fix" I referred to,
On Wed, Jan 25, 2017 at 6:49 PM, Mark Wahlert wrote:
> Did you have an opportunity to check which kernel version you've had MBIM
> working with successfully?
I tested with 4.4.14. Maybe I was just lucky enough to be testing with
a slow system and I didn't hit the bug fixed by Bjørn's patch?
--
On Wed, Jan 25, 2017 at 5:22 PM, wrote:
> I have MM essentially running on my hardware, but I’m puzzled by a part of
> its behaviour:
>
> I can enable the modem with mmcli --enable, and in the debug output I see
> the signal quality being periodically refreshed. I can also, more or less,
> make a
On Thu, Jan 26, 2017 at 2:38 PM, Bjørn Mork wrote:
>> I built LEDE (kernel 4.4.42) with MM, and it is working in MBIM mode. wwan
>> interface is assigned an address as before, but, this time the internet is
>> reachable.
>
> Great! Thanks for testing this.
Nice!
--
Aleksander
https://aleksan
> Regarding the failing PPP:
> Your enhancement probably to prevent a race is still a good idea in general.
> However I've now experimented manually (with a terminal app), and I don't
> think it is the Sig Quality which is breaking PPP. What I was actually doing
> was waiting so long before star
On Tue, Jan 31, 2017 at 12:03 AM, Getz, Robin wrote:
>
> The company I work (Analog Devices) is in process of releasing a device that
> runs embedded Linux that supports gadget USB serial to provide a serial
> console, and uses the USB CDC-ACM interface which show up as /dev/ttyACMx on
> a Lin
On 03/02/17 01:45, Ben Chan wrote:
> g_type_init() has been deprecated (and also marked with the attribute
> 'deprecated') since glib 2.36 as the type system is automatically
> initialized. Since the minimum version of glib required by ModemManager
> is 2.36, calling g_type_init() isn't necessarily
On Fri, Feb 3, 2017 at 10:19 PM, Russ Westrem
wrote:
> QUESTION #2
>
> Am i doing this right? Im trying to blacklist the ttyUSB1 port so i can use
> at commands on my own while modemmanager makes the connection. I want to be
> able to see more signal info and modem temp that MM isn't giving me.
:
I put the rule in
/lib/udev/rules.d/77-mm-usb-device-blacklist.rule
Yes I rebooted the router after making the change.
In the logs it shows modem manager has failed to connect to ttyUSB1 but I
still can't use gcom correctly until modem manager is not connected. Once
modemmanager is disabled t
On Sun, Feb 5, 2017 at 1:45 PM, Alex Pintilie wrote:
>
> I have found a not elegant but working solution for my problem on this Lenovo
> T460s with Sierra EM7455 :
>
> The problem: Couldn't check if unlock required: 'SIM not inserted'
>
>
> The solution: Close the lid of the laptop. It will go in
Hey,
On Sat, Feb 4, 2017 at 3:27 PM, Mark Wahlert wrote:
> LEDE kernel 4.4.42
> mmcli 1.7.0
> mc7455
> tp-link archer c7
>
> config interface 'wwan'
> option device '/sys/devices/platform/ehci-platform.1/usb2/2-1'
> option proto'modemmanager'
> option apn 'x.x'
> option lowpower '0
On 04/02/17 21:23, Maksim Salau wrote:
> Signed-off-by: Maksim Salau
> ---
Thanks, pushed to git master, mm-1-6 and mm-1-4.
> src/77-mm-usb-device-blacklist.rules | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/77-mm-usb-device-blacklist.rules
> b/src/77-mm-usb-device-blackli
On Sun, Feb 5, 2017 at 8:55 PM, wrote:
> Can you help me understand how I can check this?
Did you use my openwrt feed without modifications? If so you're
probably building 0bf4db6561de9be61028eb6bc1792a3b7cc410b5:
https://bitbucket.org/aleksander0m/modemmanager-openwrt/src/a840e8174cfe2ba80e8914
On Sun, Feb 5, 2017 at 8:56 PM, wrote:
> Can the desired band to be used be specified in /etc/config/network on
> OpenWrt (LEDE) build of ModemManager?
>
> I'd like to lock the system to band 41.
Not yet, no. The only non-connection related extra setting I added in
the MM support for now was the
Hey,
>> > Can you help me understand how I can check this?
>>
>> Did you use my openwrt feed without modifications? If so you're
>> probably building 0bf4db6561de9be61028eb6bc1792a3b7cc410b5:
>>
>> https://bitbucket.org/aleksander0m/modemmanager-openwrt/src/a840e8174cfe2ba80e89147f92f48a718dc31a9c
On Mon, Feb 6, 2017 at 4:32 AM, matthew stanger wrote:
> If you see more than the 3gpp option then you should be able to run 'sudo
> mmcli -m 0 --location-enable-gps-raw'. This will setup the GPS but keep MM
> from grabbing the GPS stream.
That is not right. With GPS we have 3 sources that you ca
On Mon, Feb 6, 2017 at 4:48 AM, Adam Sherman wrote:
> On 2017-02-05 10:32 PM, matthew stanger wrote:
>> First check to make sure you can get GPS location and not just 3gpp
>> location, i.e. location from just the cell tower. Run 'mmcli -m 0
>> --location-status' and check capabilities. You'll want
On Mon, Feb 6, 2017 at 5:10 AM, Adam Sherman wrote:
> On 2017-02-05 10:32 PM, matthew stanger wrote:
>> First check to make sure you can get GPS location and not just 3gpp
>> location, i.e. location from just the cell tower.
>
> Building on my previous message, I restarted the system to see how it
On Mon, Feb 6, 2017 at 1:00 PM, Adam Sherman wrote:
> On 2017-02-06 04:21 AM, Aleksander Morgado wrote:
>>> The primary port was cdc-wdm0 in my previous message. What is changing?
>>> And I never seem to get the nice data I put in my previous messages.
>>>
>>
On Mon, Feb 6, 2017 at 1:24 PM, Adam Sherman wrote:
>>> So, am I understanding correctly that there is no way to get GPS data
>>> via a serial device, with this card?
>>>
>> No, there is a way to do that, enabling the GPS receiver with AT
>> commands and processing the NMEA traces received from an
On Mon, Feb 6, 2017 at 1:35 PM, Adam Sherman wrote:
> So, am I understanding correctly that there is no way to get GPS data
> via a serial device, with this card?
>
No, there is a way to do that, enabling the GPS receiver with AT
commands and processing the NMEA traces receiv
On Mon, Feb 6, 2017 at 5:19 PM, Adam Sherman wrote:
> Sorry for the flood of emails! I'm trying to convey information as it
> comes along.
> On 2017-02-06 10:54 AM, Adam Sherman wrote:
>>> Output of mmcli shows ports: 'ttyUSB0 (qcdm), ttyUSB2 (at), cdc-wdm0
>>> (qmi), wwp0s20u4i8 (net)'.
>> After
On Mon, Feb 6, 2017 at 8:51 PM, Adam Sherman wrote:
>> In this test, qmi-proxy did not deadlock. I rill try again right now.
>
> I think I can reproduce it by sending the AT command to start GPS to the
> TTY. Log of that, attached.
Looks like we may not be doing enough retries while probing the
On Tue, Feb 7, 2017 at 5:02 PM, Russ Westrem wrote:
> I asked this in someone else's e-mail but maybe i should have made my own so
> here it is.
> My goal is to issue an ifup broadband in LEDE whenever this line is logged
> from modemmanager.
>
> daemon.info [1035]: Modem /org/freedesktop/ModemM
On Tue, Feb 7, 2017 at 9:03 PM, Russ Westrem wrote:
> Ping scripts which I'm not very fond of. I dont want a ifup broadband going
> for every time a low priority packet gets dropped. Also it could take
> almost 10 to 15 seconds before a connection is reestablished. If i can
> somehow just get t
On Tue, Feb 7, 2017 at 10:49 PM, Russ Westrem
wrote:
> I suppose this could be somehow edited into the
> lib/netfid/proto/modemmanager.sh?
Not sure. How does the "ping" connectivity check work in the other
protocol handlers? Is it something done by the handler itself or out
of it?
--
Aleksander
On Tue, Feb 7, 2017 at 9:52 PM, Adam Sherman wrote:
> Moving this to a separate thread. Maybe it should be moved to the
> libqmi-devel list?
Move it to libqmi-devel if you can reproduce it, yes. Thanks
--
Aleksander
https://aleksander.es
___
ModemMana
On Tue, Feb 7, 2017 at 11:10 PM, Russ Westrem
wrote:
> Out of it from everything I know.
>
> I'm thinking of going the easy route and doing a tail of the logfile
Oh please no; don't do that.
If you can run a script, you could source the modemmanager.proto file and then:
# Load connected bearer
On Tue, Feb 7, 2017 at 11:32 PM, Mark Wahlert wrote:
> Russ and I have been fighting similar challenges. We both want to
> leverage MM, and we want to do everything possible to maintain a
> stable "always on" connection. Aleksander - did you notice anything
> in the debug logs I had provided in
On 08/02/17 16:55, colin.helliw...@ln-systems.com wrote:
> One thing I've picked up whilst reading about MM is that although it can set
> the modem into data mode, it doesn't take care of any of the PPP side of
> things - this is the responsibility of 'elsewhere'? I'm trying to figure
> out whethe
On 08/02/17 16:09, Piotr Figiel wrote:
> From: Piotr Figiel
>
> ---
> libmm-glib/mm-modem-simple.c | 1 +
> libmm-glib/mm-modem.c| 9 +++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/libmm-glib/mm-modem-simple.c b/libmm-glib/mm-modem-simple.c
> index 910f06b
So that we don't leak the port names allocated within each
MMModemPortInfo.
==261== 672 bytes in 84 blocks are definitely lost in loss record 7,314 of
7,383
==261== at 0x402C51E: malloc (vg_replace_malloc.c:299)
==261== by 0x4484878: g_malloc (gmem.c:94)
==261== by 0x449D51D: g_st
On Thu, Feb 9, 2017 at 4:52 AM, Mark Wahlert wrote:
>> No. In fact it's almost the exact opposite. It was up today for 11 hours
>> straight but this was with nothing connected to it. No pings no anything.
>> As soon as I connect a computer and start using it, it will go down anywhere
>> between
On Thu, Feb 9, 2017 at 3:54 PM, Piotr Figiel wrote:
> I tested your patch and the reported issue doesn't appear any longer.
> It all looks good and certainly better (more glib-style) than my initial
> implementation. Although I wonder if this doesn't ever collide with
> mm_modem_port_info_array_
On Thu, Feb 9, 2017 at 10:55 PM, lspwaterproofing
wrote:
> Also I'm using the same exact modem in the same location on Ubuntu 16.04
> using ModemManager with all the same settings and it stays up for hours with
> no interruptions. So its not a network issue.
Ok, the network disconnection happen
On Fri, Feb 10, 2017 at 3:39 PM, wrote:
> I’ve got two ports whitelisted for use by MM. What determines which one of
> them will be ‘Modem/0’ ?
>
Just the first modem that finishes first probing all ports.
> Is there a way to get MM to create/initialise 0 first, then 1 – as opposed
> to doing b
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 (BGS2 and EHS5), though they
> don’t have much of the functionality supported by the Cinterion plugin such
> as GPS.
>
> But because
On Fri, Feb 10, 2017 at 6:52 PM, Aleksander Morgado
wrote:
>> For simplicity, I’d begun my exploration of MM using the Generic plugin. My
>> design has a choice of two Cinterion modems (BGS2 and EHS5), though they
>> don’t have much of the functionality supported by the Cin
On Fri, Feb 10, 2017 at 3:40 PM, wrote:
> I’m digging into SMS reception, and trying understand how MM deals with it.
>
> I can see that it/mmcli reads the messages when the modem is enabled. When a
> new SMS is then received, I can see the modem sending a “+CIEV: message,1”
> [but only the first
On Fri, Feb 10, 2017 at 7:46 PM, Russ Westrem
wrote:
> Ok. So it seems I may have spoken a little too soon on the powered usb hub
> working. Here is something I have noticed.
>
> It works for hours and hours at a time on bearer 0. Once an ifup is issued
> to fix a downed connection the bearer ch
On Fri, Feb 10, 2017 at 9:11 PM, Russ Westrem
wrote:
> Should I set it to 0?
Unset or set to 0 should be the same.
Without rebooting MM, could you enable debug logs in the daemon (mmcli
--set-logging=DEBUG) and see if we can get what kind of connection
failure we get reported?
--
Aleksander
ht
On Fri, Feb 10, 2017 at 9:37 PM, Russ Westrem
wrote:
> Fri Feb 10 14:33:23 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Received
> message...
>>> RAW:
>>> length = 80
>>> data =
>>> 07:00:00:80:50:00:00:00:00:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C
You're getting error 0x24 (dec 36), and according to 3GPP 24008 that is:
Cause value = 36 Regular deactivation
This cause code is used to indicate a regular MS or network initiated
PDP context deactivation or a regular network initiated MBMS context
deactivation.
so the network is de-registering
On Fri, Feb 10, 2017 at 11:08 PM, Russ Westrem
wrote:
> OK. I think we're getting to the bottom of this. For some reason if I drop
> the connection for any reason the mc7455 tries to re-authenticate my
> connection. I am not authorized to use this device from Sprint so the work
> around is usin
On Fri, Feb 10, 2017 at 11:37 PM, Russ Westrem
wrote:
> And generic firmware on the mc7455 is what I'm referring to.
>
Oh, so with the Generic firmware you do get a good persistent
connection but not with the Sprint firnmware?
--
Aleksander
https://aleksander.es
On Sat, Feb 11, 2017 at 11:48 PM, Russ Westrem
wrote:
> Ok this looks a little different than the last debug. I had a ping going
> and logged "LTE Down" when pings stopped.
>
>
>
> Sat Feb 11 16:40:43 2017 daemon.debug [1049]: [/dev/cdc-wdm0] Received
> message...
>>> RAW:
>>> length =
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
> [src/mm-broadband-modem.c:5888] set_messaging_unsolicited_events_handlers():
> (ttyMux0) Setting messaging unsolicited events ha
On Mon, Feb 13, 2017 at 2:05 PM, Colin Helliwell
wrote:
>> > I’ve got two ports whitelisted for use by MM. What determines which one of
>> > them will be ‘Modem/0’ ?
>>
>> Just the first modem that finishes first probing all ports.
>>
>> > Is there a way to get MM to create/initialise 0 first, the
On Sat, Feb 11, 2017 at 1:07 AM, Ben Chan wrote:
> I encountered a crash in mm-device.c:modem_valid:345 where 'self->priv'
> seemed invalid, but 'modem' looked fine. As there is no code to clear the
> "notify::base-modem-valid" signal in MMDevice, I think MMDevice currently
> relies on auto discon
Don't rely on the automatic disconnection of the signal as the last
reference of the modem object may outlive the device object.
Also, setup a common clear_modem() function to dispose the internal
reference of the modem object, which will take care of the signal
disconnection when required.
https
On Mon, Feb 13, 2017 at 2:56 PM, Colin Helliwell
wrote:
>> > For simplicity, I’d begun my exploration of MM using the Generic plugin. My
>> > design has a choice of two Cinterion modems (BGS2 and EHS5), though they
>> > don’t have much of the functionality supported by the Cinterion plugin such
>>
On Mon, Feb 13, 2017 at 3:37 PM, Colin Helliwell
wrote:
>> >
>> > > All I'm seeing in the logs is "+CIEV: message,1".
>> > > Checking back through the logs for unsolicited event setups, I also see
>> > > [src/mm-broadband-modem.c:5888]
>> > > set_messaging_unsolicited_events_handlers(): (ttyMux0)
On Mon, Feb 13, 2017 at 7:05 PM, Ben Chan wrote:
> thanks. lgtm. The g_signal_handler_is_connected check in clear_modem seems
> unnecessary though?
Yeah, we don't really remove the signal handler in any other place, so
should be unnecessary. Will fix that before pushing.
Thanks for checking!
-
On Tue, Feb 14, 2017 at 9:11 AM, Colin Helliwell
wrote:
>> > All I'm seeing in the logs is "+CIEV: message,1".
>> > Checking back through the logs for unsolicited event setups, I also see
>> > [src/mm-broadband-modem.c:5888]
>> > set_messaging_unsolicited_events_handlers(): (ttyMux0) Setting messa
On Tue, Feb 14, 2017 at 10:10 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
>>
>>
On Tue, Feb 14, 2017 at 10:38 AM, Colin Helliwell
wrote:
> I'm currently pulling a source tarball (for Yocto environment) from
> http://www.freedesktop.org/software/ModemManager/
> I wonder if I should, whilst in development at least, keep in step with your
> git mm-1-6 instead - I guess this br
On Tue, Feb 14, 2017 at 11:39 AM, Colin Helliwell
wrote:
>> > Thanks. The question arises from needing to have monitoring & URCs etc on
>> > one port of my mux driver, and ppp on the other - I need to make sure that
>> > ppp doesn't get run on the 'monitoring' port i.e. the one that gets in
>>
On Tue, Feb 14, 2017 at 12:54 PM, Colin Helliwell
wrote:
>> > > > Thanks. The question arises from needing to have monitoring & URCs etc
>> > > > on one port of my mux driver, and ppp on the other - I need to make
>> > > > sure that ppp doesn't get run on the 'monitoring' port i.e. the one
>> >
e earlier build steps have created the relevant directory e.g.
> build/src.
Could you apply the attached patch and retry? It could just be the
order of the files generated, because the .c file depends on the .h
file and they were requested in the other way in BUILT_SOURCES.
--
Aleksander
http
On Tue, Feb 14, 2017 at 4:59 PM, Colin Helliwell
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 missing a bo
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 the .c file depends on the .h
> file and they were requested in the other way in BUILT_SOURCES.
Forget about this pat
On Tue, Feb 14, 2017 at 10:33 PM, Russ Westrem
wrote:
>> Ok, I'm using qmi in kernel 4.9 on LEDE now. So far 1 hour and no
>> disconects.
>
>
>
> Seems to have the same issue using LEDE kernel 4.9 in QMI it will stay up
> for an hour and then do this.
>
>
> Tue Feb 14 20:54:17 2017 daemon.info
nology act;
>>
>
> 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.
--
Aleksander
https://aleksander.es
From d118f14a67402bb17de5acdd8748856a5496c050 Mon Sep 17 00:00:00 2001
From:
Hey,
>> The issue is really related to the ublox subdir not existing before
>> calling glib-mkenums. In my setup, the directory is created before
>> glib-mkenums runs, though. What build tools are you using? i.e. which
>> automake version?
>>
>
> automake is version 1.15
> Possibly to do with para
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 patch?
--
Aleksander
https://aleksander.es
From 56d0c49dc80a66bb606b5ecea94c1ecdbb046ed6 Mon Sep 17 00:00:00 2001
F
On Wed, Feb 15, 2017 at 10:00 AM, Colin Helliwell
wrote:
>> On 14 February 2017 at 17:28 Dan Williams wrote:
>>
>> On Tue, 2017-02-14 at 15:16 +, Colin Helliwell wrote:
>>
>> > > On 14 February 2017 at 12:59 Aleksander Morgado > > > der.es> wro
On Wed, Feb 15, 2017 at 10:46 AM, Colin Helliwell
wrote:
>> > I get the feeling its written with nearly-but-not-quite up to date
>> > methods, or just different ones. Certainly it's not easy to compare
>> > against USB-based drivers. From what I can make out, the three virtual
>> > ports are cr
On Wed, Feb 15, 2017 at 4:16 PM, Colin Helliwell
wrote:
>> On 15 February 2017 at 15:07 Colin Helliwell
>> wrote:
>>
>> > On 15 February 2017 at 14:11 Aleksander Morgado
>> > wrote:
>> >
>> > Is the logic stopping there? the ID_MM_PHYS
On Wed, Feb 15, 2017 at 9:00 PM, Russ Westrem
wrote:
> Is there anything in the modemmanager scripts that I could change to have it
> ignore the deregistered modem and stop it from removing it from the bearer.
> I have a feeling these deregistrations happen often but very quickly and
> maybe if ig
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
>> > > > > respo
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
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 };
>
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
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: coul
On Sat, Feb 18, 2017 at 11:01 PM, Russ Westrem
wrote:
> I dont have 3g on this plan. Its a LTE only plan. Im starting to think
> this is the cause of the problems. It sounds like its trying to register me
> on 3GPP which I dont have.
3GPP is the family of protocols that include GSM, GPRS, UMTS
On Thu, Feb 23, 2017 at 8:45 PM, Ben Chan wrote:
> find_device_by_physdev_uid() expects a non-NULL UID of the physical
> device. However, mm_kernel_device_get_physdev_uid() could potentially
> return NULL on MMKernelDeviceUdev if find_physical_gudevdevice() in
> mm-kernel-device-udev.c fails to fi
On Thu, Feb 23, 2017 at 8:45 PM, Ben Chan wrote:
> ---
> src/kerneldevice/mm-kernel-device-udev.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
This one is probably ok; I'd add some more information in the commit
message, though (e.g. the explanation given in the cover letter in
On Fri, Feb 24, 2017 at 8:14 PM, Ben Chan wrote:
>> > find_device_by_physdev_uid() expects a non-NULL UID of the physical
>> > device. However, mm_kernel_device_get_physdev_uid() could potentially
>> > return NULL on MMKernelDeviceUdev if find_physical_gudevdevice() in
>> > mm-kernel-device-udev.c
On Fri, Feb 24, 2017 at 9:47 PM, Ben Chan wrote:
>>
>> * If user-provided UID via "self->priv->properties", return that one.
>> * Otherwise, if user-provided UID via "ID_MM_PHYSDEV_UID", return that
>> one.
>
>
> I believe that's what MMKernelDeviceGeneric currently does. However,
> MMKernelDevi
On Wed, Mar 1, 2017 at 3:59 AM, Ben Chan wrote:
> find_device_by_physdev_uid() expects a non-NULL UID of the physical
> device. However, mm_kernel_device_get_physdev_uid() could potentially
> return NULL on MMKernelDeviceUdev if find_physical_gudevdevice() in
> mm-kernel-device-udev.c fails to fin
On Thu, Mar 2, 2017 at 7:31 PM, Ben Chan wrote:
> I saw a few self->priv->device check in mm-kernel-device-udev.c, so I was
> wondering if there are cases where self->priv->device may be NULL. I'd keep
> the check here for now as I haven't ruled out that possibility.
I think the device will be NU
On 03/03/17 03:57, Ben Chan wrote:
> find_device_by_physdev_uid() expects a non-NULL UID of the physical
> device. However, mm_kernel_device_get_physdev_uid() could potentially
> return NULL on MMKernelDeviceUdev if find_physical_gudevdevice() in
> mm-kernel-device-udev.c fails to find the physical
On Fri, Mar 3, 2017 at 7:29 PM, Ben Chan wrote:
> clear_modem() can be invoked from set_property() and dispose(), where
> `self->priv->modem' may be NULL. This patch adds a null check on the
> modem object to make sure we don't run g_object_run_dispose() on a null
> modem object.
> ---
Yes, it ma
On 03/03/17 20:26, Aleksander Morgado wrote:
> On Fri, Mar 3, 2017 at 7:29 PM, Ben Chan wrote:
>> clear_modem() can be invoked from set_property() and dispose(), where
>> `self->priv->modem' may be NULL. This patch adds a null check on the
>> modem
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 parse?
>
>^SCFG: "Radio/Band",("1"-"147")
>
>
>
> (Which I take to pr
On Mon, Mar 6, 2017 at 10:13 PM, Russ Westrem
wrote:
> Ok. So I moved to a router with an onboard
> pci-e to eliminate any problems with usb cables. The issue of disconects
> are still there using qmi or mbim. This is only a 4.4 kernel lede build so
> qmi is a ppp connection. I am getting a st
Hey,
Looks like getting ID_VENDOR_ID and ID_MODEL_ID from the tty sysfs
path may give the serial controller vid:pid, instead of the actual
device vid:pid (which we get when getting the properties from the
physical device sysfs path instead of the tty sysfs path).
$ udevadm info -p
/sys/devices/pc
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 ModemManager[896]: [141125.484324]
>> [src/mm-port-serial.c:1294] mm_port_serial_open(): (ttyMux0) device open
>> count is
On Tue, Mar 7, 2017 at 3:46 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 ModemManager[896]: [141125.484324]
>> > > [src/mm-port-serial.c:1294] mm_port_serial_open(): (ttyMux0) device ope
601 - 700 of 1794 matches
Mail list logo
