On Wed, 2017-02-08 at 14:46 +, colin.helliw...@ln-systems.com
wrote:
> I'm re-visiting this initial issue, of MM not spotting the 'NO
> CARRIER' when the modem times out of data mode. Because of aggro
> getting it working direct on the serial port, I'm back with my mux
> driver (which is what I
Hi Aleksander and Dan
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 disconnection of the signal when MMBaseMo
On Feb 10, 2017 4:40 PM, "Aleksander Morgado"
wrote:
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
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 Feb 10, 2017 4:33 PM, "Aleksander Morgado"
wrote:
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 u
On Feb 10, 2017 4:35 PM, "Russ Westrem" wrote:
On Feb 10, 2017 4:33 PM, "Aleksander Morgado"
wrote:
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-auth
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 Feb 10, 2017 3:24 PM, "Bjørn Mork" wrote:
Aleksander Morgado writes:
> You're getting error 0x24 (dec 36), and according to 3GPP 24008 that is:
>
> Cause value = 36 Regular deactivation
Oh, I didn't fint that. I guess this is in some other table there?
I'm glad I don't have to navigate th
Aleksander Morgado writes:
> You're getting error 0x24 (dec 36), and according to 3GPP 24008 that is:
>
> Cause value = 36 Regular deactivation
Oh, I didn't fint that. I guess this is in some other table there?
I'm glad I don't have to navigate these standards
Bjørn
_
Aleksander Morgado writes:
> 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:0
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
Sorry I meant remap =24 to be acceptable?
On Feb 10, 2017 2:58 PM, "Russ Westrem" wrote:
> Could we remap =23 to be acceptable?
>
> On Feb 10, 2017 2:56 PM, "Russ Westrem"
> wrote:
>
>> I am using a sprint plan in generic mode on the mc7455. Does this have
>> anything to do with it?
>>
>> On F
Could we remap =23 to be acceptable?
On Feb 10, 2017 2:56 PM, "Russ Westrem" wrote:
> I am using a sprint plan in generic mode on the mc7455. Does this have
> anything to do with it?
>
> On Feb 10, 2017 2:46 PM, "Aleksander Morgado"
> wrote:
>
> On Fri, Feb 10, 2017 at 9:37 PM, Russ Westrem
>
I am using a sprint plan in generic mode on the mc7455. Does this have
anything to do with it?
On Feb 10, 2017 2:46 PM, "Aleksander Morgado"
wrote:
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...
>>>
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
Fri Feb 10 14:33:07 2017 daemon.info [1042]: IPv4 configuration
available: 'address, gateway, dns, mtu'
Fri Feb 10 14:33:07 2017 daemon.info [1042]:IP addresses (1)
Fri Feb 10 14:33:07 2017 daemon.info [1042]: IP [0]: '
25.22.233.27/29'
Fri Feb 10 14:33:07 2017 daemon.info [1042]:Gate
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
Should I set it to 0?
On Feb 10, 2017 2:08 PM, "Russ Westrem" wrote:
> It's unset at the moment.
>
> On Feb 10, 2017 2:07 PM, "Aleksander Morgado"
> wrote:
>
>> 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
It's unset at the moment.
On Feb 10, 2017 2:07 PM, "Aleksander Morgado"
wrote:
> 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 an
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
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 changes to 1 then 2 and so on. On
these other bearers the discon
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 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 Cinterion plugin such
>> as
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 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
Hi Colin,
I'm not a core maintainer but I've recently done some work on the Cinterion
plugin. I've been actually hoping to do some more but have been overwhelmed
the last 2 months with person life oblations. Anyways the next patch I'll
be submitting in fact is for Cinterions updated GPS commands.
4 hours up using the usb powered hub.
Sent from my Sprint Samsung Galaxy Note5.
Original message From: Aleksander Morgado
Date: 2/10/17 3:34 AM (GMT-06:00) To:
lspwaterproofing Cc: Dan Williams
, Sebastian Sjoholm , Mark
Wahlert , ModemManager
Subject: Re: How to issue
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 of one command incompatibility (CMER) with the Gener
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 time, if the first message isn't then read?].
I
I've got two ports whitelisted for use by MM. What determines which one of
them will be 'Modem/0' ?
Is there a way to get MM to create/initialise 0 first, then 1 - as opposed
to doing both in *parallel*?
I'm getting MM to use the Cinterion plugin for my modem, by adding
ENV{ID_MM_PLATFOR
Yes. Only when using lede on a router. I just hooked it to a powered usb
hub. I am testing now. I will keep everyone posted.
The mc7455 on Ubuntu 16.04 with modemmanager went 24 hours with not a
single packet dropped while playing 2 hd videos at the same time.
On Feb 10, 2017 3:34 AM, "Aleksan
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 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_
33 matches
Mail list logo
