<div dir="ltr">Do these logs, while using qmi, give any more info to the disconnects?<div><br></div><div><div>Sat Feb 18 00:15:34 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer call end reason (1008): 'gsm-wcdma-regular-deactivation'</div><div>Sat Feb 18 00:15:34 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer verbose call end reason (6,36): [3gpp] regular-deactivation</div><div>Sat Feb 18 00:15:55 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer call end reason (1008): 'gsm-wcdma-regular-deactivation'</div><div>Sat Feb 18 00:15:55 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer verbose call end reason (6,36): [3gpp] regular-deactivation</div><div>Sat Feb 18 00:16:37 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer call end reason (1008): 'gsm-wcdma-regular-deactivation'</div><div>Sat Feb 18 00:16:37 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer verbose call end reason (6,36): [3gpp] regular-deactivation</div><div>Sat Feb 18 00:17:46 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer call end reason (1008): 'gsm-wcdma-regular-deactivation'</div><div>Sat Feb 18 00:17:46 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer verbose call end reason (6,36): [3gpp] regular-deactivation</div><div>Sat Feb 18 00:19:55 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer call end reason (1): 'generic-unspecified'</div><div>Sat Feb 18 00:19:55 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer verbose call end reason (3,1028): [cm] (NULL)</div><div>Sat Feb 18 00:22:07 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer call end reason (1): 'generic-unspecified'</div><div>Sat Feb 18 00:22:07 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer verbose call end reason (3,1028): [cm] (NULL)</div><div>Sat Feb 18 00:23:17 2017 <a href="http://daemon.info">daemon.info</a> odhcpd[873]: Initial RA router lifetime 0, 1 address(es) available on br-lan</div><div>Sat Feb 18 00:24:16 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer call end reason (1): 'generic-unspecified'</div><div>Sat Feb 18 00:24:16 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer verbose call end reason (3,1028): [cm] (NULL)</div><div>Sat Feb 18 00:26:28 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer call end reason (1): 'generic-unspecified'</div><div>Sat Feb 18 00:26:28 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer verbose call end reason (3,1028): [cm] (NULL)</div><div>Sat Feb 18 00:28:38 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer call end reason (1): 'generic-unspecified'</div><div>Sat Feb 18 00:28:38 2017 <a href="http://daemon.info">daemon.info</a> [1227]: <info>  bearer verbose call end reason (3,1028): [cm] (NULL)</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 6:25 PM, Russ Westrem <span dir="ltr"><<a href="mailto:lspwaterproofing@gmail.com" target="_blank">lspwaterproofing@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Feb 15, 2017 5:39 PM, "Dan Williams" <<a href="mailto:dcbw@redhat.com" target="_blank">dcbw@redhat.com</a>> wrote:<br type="attribution"><blockquote class="m_8443678552769161552quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_8443678552769161552elided-text">On Wed, 2017-02-15 at 17:09 -0600, Russ Westrem wrote:<br>
> On Feb 15, 2017 4:37 PM, "Dan Williams" <<a href="mailto:dcbw@redhat.com" target="_blank">dcbw@redhat.com</a>> wrote:<br>
><br>
> On Wed, 2017-02-15 at 21:14 +0100, Aleksander Morgado wrote:<br>
> > On Wed, Feb 15, 2017 at 9:00 PM, Russ Westrem<br>
> > <<a href="mailto:lspwaterproofing@gmail.com" target="_blank">lspwaterproofing@gmail.com</a>> wrote:<br>
> > > Is there anything in the modemmanager scripts that I could change<br>
> > > to have it<br>
> > > ignore the deregistered modem and stop it from removing it from<br>
> > > the<br>
> > > bearer.<br>
> > > I have a feeling these deregistrations happen often but very<br>
> > > quickly and<br>
> > > maybe if ignored, everything might work.<br>
> ><br>
> > You mean you want to totally ignore the modem-reported de-<br>
> > registration<br>
> > notifications to see what happens? I'm not sure that is easily<br>
> > decoupled from the logic; maybe you can try to avoid connecting the<br>
> > "serving-system" signal in<br>
> > common_setup_cleanup_unsolicit<wbr>ed_registration_events() in<br>
> > mm-broadband-modem-qmi.c.<br>
><br>
> That shouldn't have any effect though, really?  MM's logic on bearer<br>
> initiated disconnection just changes some state, but doesn't do<br>
> anything material to the WDS client.  The WDS client and packet data<br>
> handle are still there and haven't been cleaned up.  Whether you can<br>
> actually use them for anything is another question.<br>
><br>
> But Russ, I don't quite understand why you'd want to ignore the<br>
> deregistration, unless it's just for testing.<br>
><br>
> If it's not for testing, well, the network kicked you off, and your<br>
> packet bearer is likely gone (since the network has released<br>
> resources<br>
> for it when it kicked you off), and the IP details are gone too.<br>
> That's not the modem, that's the network.  The only thing you can<br>
> really do is request a new bearer.<br>
><br>
> Dan<br>
><br>
><br>
><br>
> I'm not sure either.  I just dont get why it holds a connection for<br>
> days on<br>
> Ubuntu 16.04 in the exact same spot using ModemManager and it never<br>
> looses<br>
> a single ping but when I do it on any router, mbim/qmi/4.4 kernel/4.9<br>
> kernel, it will last an hour and then drop the connection 10 times<br>
> every<br>
> hour after that.<br>
><br>
> I will try your suggestion on requesting a new bearer but I don't<br>
> know if<br>
> that will solve my problem .   Also I'm just too new at all this to<br>
> figure<br>
> out how to make that script work for me on LEDE.<br>
<br>
</div>I thought your problem was that the bearer wasn't getting reconnected<br>
automatically after it dropped?  The script I pasted should do that.<br>
<br>
One more question; is this the exact same device that works well on<br>
Ubuntu and drops on LEDE?  eg, the exact same card, not just the same<br>
model of card but different cards.<br>
<font color="#888888"><br>
Dan<br>
</font></blockquote></div></div></div>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.  </div></div><div class="gmail_extra" dir="auto">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.  </div></div>
</blockquote></div><br></div>