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 handlers
[src/mm-port-serial.c:1347] _close_interna
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 13 February 2017 at 09:48 Aleksander Morgado
> wrote:
>
> 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_unso
> On 10 February 2017 at 17:47 Aleksander Morgado
> wrote:
>
> 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
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 10 February 2017 at 17:52 Aleksander Morgado
> wrote:
>
> 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 funct
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 Feb 12, 2017 3:59 AM, "Aleksander Morgado"
wrote:
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
> On 13 February 2017 at 11:46 Colin Helliwell
> wrote:
>
> > On 13 February 2017 at 09:48 Aleksander Morgado
> > wrote:
> >
> > 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 set
> On 13 February 2017 at 14:14 Aleksander Morgado
> wrote:
>
> 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), thoug
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)
thanks. lgtm. The g_signal_handler_is_connected check in clear_modem seems
unnecessary though?
On Mon, Feb 13, 2017 at 6:06 AM, Aleksander Morgado <
aleksan...@aleksander.es> wrote:
> Don't rely on the automatic disconnection of the signal as the last
> reference of the modem object may outlive
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 Feb 13, 2017 8:27 AM, "Russ Westrem" wrote:
On Feb 12, 2017 3:59 AM, "Aleksander Morgado"
wrote:
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 1
16 matches
Mail list logo