From owner-freebsd-questions@freebsd.org Wed Dec 11 16:34:44 2019 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 65EE31DA648 for ; Wed, 11 Dec 2019 16:34:44 +0000 (UTC) (envelope-from ml-ktk@netlabs.org) Received: from r2-d2.netlabs.org (r2-d2.netlabs.org [213.238.45.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47Y2Zq2kphz4K1F for ; Wed, 11 Dec 2019 16:34:43 +0000 (UTC) (envelope-from ml-ktk@netlabs.org) Received: (qmail 39692 invoked by uid 89); 11 Dec 2019 16:34:40 -0000 Received: by simscan 1.4.0 ppid: 39682, pid: 39690, t: 0.4074s scanners:none Received: from unknown (HELO eternal.glodok.netlabs.org) (ml-ktk@netlabs.org@114.124.167.158) by 0 with ESMTPA; 11 Dec 2019 16:34:39 -0000 Subject: Re: u3g Sierra Wireless LTE device disconnects ppp after 2-3MB of outgoing traffic To: mike tancsa , freebsd-questions@freebsd.org References: <972e8912-0ed7-63c8-d079-c11b12f8c9ad@netlabs.org> <6e6176d5-c9c5-b38a-0fe6-8b21c9c33824@sentex.net> <6d5e9963-bdfe-81b3-73be-6ee349f9091e@netlabs.org> <56eb59b2-6cbb-cfb0-4594-46644aee7164@sentex.net> From: Adrian Gschwend Message-ID: <8d25dd77-7c71-5a4a-2f2e-78c541e3fb9c@netlabs.org> Date: Wed, 11 Dec 2019 23:34:36 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <56eb59b2-6cbb-cfb0-4594-46644aee7164@sentex.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 47Y2Zq2kphz4K1F X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ml-ktk@netlabs.org has no SPF policy when checking 213.238.45.90) smtp.mailfrom=ml-ktk@netlabs.org X-Spamd-Result: default: False [4.18 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[netlabs.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.61)[0.609,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[90.45.238.213.list.dnswl.org : 127.0.10.0]; NEURAL_SPAM_LONG(0.93)[0.928,0]; R_SPF_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[90.45.238.213.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:9211, ipnet:213.238.32.0/20, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(1.74)[ipnet: 213.238.32.0/20(4.88), asn: 9211(3.85), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 16:34:44 -0000 On 11.12.19 21:24, mike tancsa wrote: > Do you have LQR/ech enabled ?  Here is the ppp.conf section I use yeah, it's pretty much based on what you proposed, main change was APN. Later I did add set reconnect 3 5 Hoping that this adds something but apparently it does not. > Depending on your modem, some Sierra's dont allow the GSTATUS command > from the management port, just signal info. Eg. port /dev/cuaU0.3 is my > data port to make my ppp connection on, I can connect to cuaU1.4 to ask > some basic info like signal.  Sierra should have a pretty good AT > command set manual free to download so you can see what is exactly > available. yes I have that one. > % cu -l /dev/cuaU1.4 > Connected > Sierra Wireless, Incorporated > MC7700 > APP1 > > OK > +CSQ: 21,99 > OK That does not work on mine, on 2 I get "all ports are connected" but that's where PPP is running on. On the others I get "connected" but never any output (and also no echo) > for whatever reason, ate1 is not respected, so my commands dont show. > the above is the output of entering ati and at+csq I've seen that too >  set lqrperiod 10 >  enable lqr >  enable echo > > should allow ppp to reconnect should ppp disconnect. unfortunately it doesn't. The link seems still up but absolutely nothing goes through anymore. The only thing I can do is kill ppp and restart it, then I have a link again immediately. > you should in your logs see > >  ppp[3416]: tun10: LCP: deflink: SendEchoRequest(80560) state = Opened >  ppp[3416]: tun10: LCP: deflink: RecvEchoReply(176) state = Opened jep: ppp[57554]: tun0: LCP: deflink: RecvEchoReq: magic 0x245182f7 is wrong, expecting 0x6745dd7e ppp[57554]: tun0: LCP: deflink: SendEchoReply(217) state = Opened ppp[57554]: tun0: LCP: deflink: RecvEchoReply(217) state = Opened ppp[57554]: tun0: LCP: deflink: SendEchoRequest(986) state = Opened not sure what's going on with the wrong magic. Maybe that link is simply really unreliable. regards Adrian