How to issue an "ifup broadband" when this is logged

Sat Feb 18 15:38:25 UTC 2017

Do these logs, while using qmi, give any more info to the disconnects?

Sat Feb 18 00:15:34 2017 daemon.info [1227]: <info>  bearer call end reason
(1008): 'gsm-wcdma-regular-deactivation'
Sat Feb 18 00:15:34 2017 daemon.info [1227]: <info>  bearer verbose call
end reason (6,36): [3gpp] regular-deactivation
Sat Feb 18 00:15:55 2017 daemon.info [1227]: <info>  bearer call end reason
(1008): 'gsm-wcdma-regular-deactivation'
Sat Feb 18 00:15:55 2017 daemon.info [1227]: <info>  bearer verbose call
end reason (6,36): [3gpp] regular-deactivation
Sat Feb 18 00:16:37 2017 daemon.info [1227]: <info>  bearer call end reason
(1008): 'gsm-wcdma-regular-deactivation'
Sat Feb 18 00:16:37 2017 daemon.info [1227]: <info>  bearer verbose call
end reason (6,36): [3gpp] regular-deactivation
Sat Feb 18 00:17:46 2017 daemon.info [1227]: <info>  bearer call end reason
(1008): 'gsm-wcdma-regular-deactivation'
Sat Feb 18 00:17:46 2017 daemon.info [1227]: <info>  bearer verbose call
end reason (6,36): [3gpp] regular-deactivation
Sat Feb 18 00:19:55 2017 daemon.info [1227]: <info>  bearer call end reason
(1): 'generic-unspecified'
Sat Feb 18 00:19:55 2017 daemon.info [1227]: <info>  bearer verbose call
end reason (3,1028): [cm] (NULL)
Sat Feb 18 00:22:07 2017 daemon.info [1227]: <info>  bearer call end reason
(1): 'generic-unspecified'
Sat Feb 18 00:22:07 2017 daemon.info [1227]: <info>  bearer verbose call
end reason (3,1028): [cm] (NULL)
Sat Feb 18 00:23:17 2017 daemon.info odhcpd[873]: Initial RA router
lifetime 0, 1 address(es) available on br-lan
Sat Feb 18 00:24:16 2017 daemon.info [1227]: <info>  bearer call end reason
(1): 'generic-unspecified'
Sat Feb 18 00:24:16 2017 daemon.info [1227]: <info>  bearer verbose call
end reason (3,1028): [cm] (NULL)
Sat Feb 18 00:26:28 2017 daemon.info [1227]: <info>  bearer call end reason
(1): 'generic-unspecified'
Sat Feb 18 00:26:28 2017 daemon.info [1227]: <info>  bearer verbose call
end reason (3,1028): [cm] (NULL)
Sat Feb 18 00:28:38 2017 daemon.info [1227]: <info>  bearer call end reason
(1): 'generic-unspecified'
Sat Feb 18 00:28:38 2017 daemon.info [1227]: <info>  bearer verbose call
end reason (3,1028): [cm] (NULL)

On Wed, Feb 15, 2017 at 6:25 PM, Russ Westrem <lspwaterproofing at gmail.com>
wrote:

>
>
> On Feb 15, 2017 5:39 PM, "Dan Williams" <dcbw at redhat.com> wrote:
>
> On Wed, 2017-02-15 at 17:09 -0600, Russ Westrem wrote:
> > On Feb 15, 2017 4:37 PM, "Dan Williams" <dcbw at redhat.com> wrote:
> >
> > On Wed, 2017-02-15 at 21:14 +0100, Aleksander Morgado wrote:
> > > On Wed, Feb 15, 2017 at 9:00 PM, Russ Westrem
> > > <lspwaterproofing at gmail.com> 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 ignored, everything might work.
> > >
> > > You mean you want to totally ignore the modem-reported de-
> > > registration
> > > notifications to see what happens? I'm not sure that is easily
> > > decoupled from the logic; maybe you can try to avoid connecting the
> > > "serving-system" signal in
> > > common_setup_cleanup_unsolicited_registration_events() in
> > > mm-broadband-modem-qmi.c.
> >
> > That shouldn't have any effect though, really?  MM's logic on bearer
> > initiated disconnection just changes some state, but doesn't do
> > anything material to the WDS client.  The WDS client and packet data
> > handle are still there and haven't been cleaned up.  Whether you can
> > actually use them for anything is another question.
> >
> > But Russ, I don't quite understand why you'd want to ignore the
> > deregistration, unless it's just for testing.
> >
> > If it's not for testing, well, the network kicked you off, and your
> > packet bearer is likely gone (since the network has released
> > resources
> > for it when it kicked you off), and the IP details are gone too.
> > That's not the modem, that's the network.  The only thing you can
> > really do is request a new bearer.
> >
> > Dan
> >
> >
> >
> > I'm not sure either.  I just dont get why it holds a connection for
> > days on
> > Ubuntu 16.04 in the exact same spot using ModemManager and it never
> > looses
> > a single ping but when I do it on any router, mbim/qmi/4.4 kernel/4.9
> > kernel, it will last an hour and then drop the connection 10 times
> > every
> > hour after that.
> >
> > I will try your suggestion on requesting a new bearer but I don't
> > know if
> > that will solve my problem .   Also I'm just too new at all this to
> > figure
> > out how to make that script work for me on LEDE.
>
> I thought your problem was that the bearer wasn't getting reconnected
> automatically after it dropped?  The script I pasted should do that.
>
> One more question; is this the exact same device that works well on
> Ubuntu and drops on LEDE?  eg, the exact same card, not just the same
> model of card but different cards.
>
> Dan
>
> It's the exact same.  I remove the usb from the ubuntu machine and plug it
> into the router without moving anything or changing anything.
> And it's a two part problem I guess.  The ubuntu will run days and never
> drop a connection and still be on the same bearer.  I drop a connection
> every 5 or 10 min on LEDE.  I've used powered usb hubs with no help.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20170218/4b210e8c/attachment.html>