<div dir="auto"><div> <div class="gmail_extra"> <div class="gmail_quote">On Feb 15, 2017 5:39 PM, "Dan Williams" <<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>> wrote: <blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On Wed, 2017-02-15 at 17:09 -0600, Russ Westrem wrote: > On Feb 15, 2017 4:37 PM, "Dan Williams" <<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>> wrote: > > On Wed, 2017-02-15 at 21:14 +0100, Aleksander Morgado wrote: > > On Wed, Feb 15, 2017 at 9:00 PM, Russ Westrem > > <<a href="mailto:lspwaterproofing@gmail.com">lspwaterproofing@gmail.com</a>> 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. </div>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 </blockquote></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>