Why does the MTS GPRS connection break in Ubuntu?

Question

linux

I just can’t overcome the reason for the disconnection in ubuntu when connected via a 3G / LTE modem Huawei E398 (this also happened with other modems).
In particular, the connection is broken due to "LCP terminated by peer".

Mar  3 05:37:25 ubuntu pppd[11997]: pppd 2.4.5 started by root, uid 0
Mar  3 05:37:25 ubuntu pppd[11997]: using channel 106
Mar  3 05:37:25 ubuntu pppd[11997]: Using interface ppp0
Mar  3 05:37:25 ubuntu pppd[11997]: Connect: ppp0 <--> /dev/ttyUSB0
Mar  3 05:37:25 ubuntu pppd[11997]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb585f1ec>]
Mar  3 05:37:25 ubuntu pppd[11997]: rcvd [LCP ConfReq id=0x21 <asyncmap 0x0> <auth chap MD5> <magic 0xf766a50e> <pcomp> <accomp>]
Mar  3 05:37:25 ubuntu pppd[11997]: sent [LCP ConfRej id=0x21 <pcomp> <accomp>]
Mar  3 05:37:25 ubuntu pppd[11997]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xb585f1ec>]
Mar  3 05:37:25 ubuntu pppd[11997]: rcvd [LCP ConfReq id=0x22 <asyncmap 0x0> <auth chap MD5> <magic 0xf766a50e>]
Mar  3 05:37:25 ubuntu pppd[11997]: sent [LCP ConfAck id=0x22 <asyncmap 0x0> <auth chap MD5> <magic 0xf766a50e>]
Mar  3 05:37:25 ubuntu pppd[11997]: sent [LCP EchoReq id=0x0 magic=0xb585f1ec]
Mar  3 05:37:25 ubuntu pppd[11997]: rcvd [LCP DiscReq id=0x23 magic=0xf766a50e]
Mar  3 05:37:25 ubuntu pppd[11997]: rcvd [CHAP Challenge id=0x1 <881b6bf79efcdc9878374dd42c147519>, name = "UMTS_CHAP_SRVR"]
Mar  3 05:37:25 ubuntu pppd[11997]: sent [CHAP Response id=0x1 <b3f8d28572193959e7ac04de11de9270>, name = "mts"]
Mar  3 05:37:25 ubuntu pppd[11997]: rcvd [LCP EchoRep id=0x0 magic=0xf766a50e b5 85 f1 ec]
Mar  3 05:37:25 ubuntu pppd[11997]: rcvd [CHAP Success id=0x1 ""]
Mar  3 05:37:25 ubuntu pppd[11997]: CHAP authentication succeeded
Mar  3 05:37:25 ubuntu pppd[11997]: CHAP authentication succeeded
Mar  3 05:37:25 ubuntu pppd[11997]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Mar  3 05:37:25 ubuntu pppd[11997]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Mar  3 05:37:25 ubuntu pppd[11997]: rcvd [LCP ProtRej id=0x24 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Mar  3 05:37:25 ubuntu pppd[11997]: Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
Mar  3 05:37:25 ubuntu pppd[11997]: rcvd [IPCP ConfReq id=0xe]
Mar  3 05:37:25 ubuntu pppd[11997]: sent [IPCP ConfNak id=0xe <addr 0.0.0.0>]
Mar  3 05:37:25 ubuntu pppd[11997]: rcvd [IPCP ConfNak id=0x1 <addr 10.131.74.192> <ms-dns1 213.87.1.1> <ms-dns2 213.87.0.1>]
Mar  3 05:37:25 ubuntu pppd[11997]: sent [IPCP ConfReq id=0x2 <addr 10.131.74.192> <ms-dns1 213.87.1.1> <ms-dns2 213.87.0.1>]
Mar  3 05:37:25 ubuntu pppd[11997]: rcvd [IPCP ConfReq id=0xf]
Mar  3 05:37:25 ubuntu pppd[11997]: sent [IPCP ConfAck id=0xf]
Mar  3 05:37:25 ubuntu pppd[11997]: rcvd [IPCP ConfAck id=0x2 <addr 10.131.74.192> <ms-dns1 213.87.1.1> <ms-dns2 213.87.0.1>]
Mar  3 05:37:25 ubuntu pppd[11997]: Could not determine remote IP address: defaulting to 10.64.64.64
Mar  3 05:37:25 ubuntu pppd[11997]: local  IP address 10.131.74.192
Mar  3 05:37:25 ubuntu pppd[11997]: remote IP address 10.64.64.64
Mar  3 05:37:25 ubuntu pppd[11997]: primary   DNS address 213.87.1.1
Mar  3 05:37:25 ubuntu pppd[11997]: secondary DNS address 213.87.0.1
Mar  3 05:37:25 ubuntu pppd[11997]: Script /etc/ppp/ip-up started (pid 12004)
Mar  3 05:37:25 ubuntu named[1259]: listening on IPv4 interface ppp0, 10.131.74.192#53
Mar  3 05:37:25 ubuntu pppd[11997]: Script /etc/ppp/ip-up finished (pid 12004), status = 0x0
Mar  3 05:38:19 ubuntu pppd[11997]: rcvd [LCP TermReq id=0x25]
Mar  3 05:38:19 ubuntu pppd[11997]: LCP terminated by peer
Mar  3 05:38:19 ubuntu pppd[11997]: Connect time 0.9 minutes.
Mar  3 05:38:19 ubuntu pppd[11997]: Sent 15341 bytes, received 1188 bytes.
Mar  3 05:38:19 ubuntu pppd[11997]: Script /etc/ppp/ip-down started (pid 12084)
Mar  3 05:38:19 ubuntu pppd[11997]: sent [LCP TermAck id=0x25]
Mar  3 05:38:19 ubuntu pppd[11997]: Script /etc/ppp/ip-down finished (pid 12084), status = 0x0
Mar  3 05:38:20 ubuntu pppd[11997]: Modem hangup
Mar  3 05:38:20 ubuntu pppd[11997]: Connection terminated.
Mar  3 05:38:20 ubuntu pppd[11997]: Exit.

I establish the connection using wvdial and its config:

[Dialer MTS]
Init1 = ATZ
Init2 = AT+CGDCONT=1,"IP","internet.mts.ru"
Modem Type = USB LTE Modem
Baud = 9600
New PPPD = yes
Modem = /dev/ttyUSB0
Phone = *99#
Password = mts
Username = mts
Stupid Mode = yes 
Dial Attempts = 0
Auto DNS = Off
Dial Timeout = 1

The modem is automatically translated by udev using usb_switchmode into the desired mode. But the connection still breaks.
I read somewhere that there is a difference between official software and establishing a connection using ppp, but somehow I can’t find what exactly is the difference and what to do.

Answer 1

In total, the problem is solved by changing the settings on the MTS side. When the MTS side saw "wrong packets" in the amount of 10 pieces, the connection was closed by the operator. Now this won't happen.
That is, the only solution on the part of the subscriber is "-A FORWARD -m state --state INVALID -j DROP". This greatly reduced the probability of closing the session, but did not completely eliminate it. Changing the parameters indicated above had little effect on the problem, because she was on the other side.
As for NDIS, I forgot a little, because. in general, the interface is quite good - you don't need crutches in the form of ppp, but at least it's quite difficult to keep the ndis connection in the console - the modem can freeze, you need to manually control the connection status, manually do the binding of obtaining an ip address, because after the wwan connection drops, the interface does not go down and you need to somehow understand that you need to get a new ip.

Answer 2

I almost figured out what the problem is. It turns out that in the first place the problem is in slipping ip-shniks past NAT in Linux. I don’t understand for what reasons this occurs, but the rule -A FORWARD -m state --state INVALID -j DROP
helps. The rule that sets a single ttl also helps, but I really haven’t figured out yet how much it helps. -t mangle -A POSTROUTING -o ppp0 -j TTL --ttl-set 64
I also lit up how to properly raise the NDIS interface and I might even write an article about this for posterity.
Let me remind you that all this kotovasiya is happening with the MTS operator. Maybe other carriers don't. I have access to techies from MTS, perhaps with them we will still try to understand why this is happening. I do not remember that they somehow specifically struggled with the installation of routers. Thanks everyone for the tips.

Answer 3

(I'll take it out of the comments, because this is also a possible answer to the question in a certain situation.)
In a similar way, the "features" of the Beeline modem may appear.
(I inserted an MTS SIM card and I thought: since the Internet is completely normal for 2.3 minutes, then the modem does not have some kind of beeline lock-in, and MTS, of course, does not care which modem, because there are a lot of mobile devices different).
But they write in homenet.beeline.ru/index.php?s=8e6979064f9c64a4156... :
Those. in principle, it doesn’t matter which SIM card you insert into such a modem, but if you use it from Ubuntu or another system without Beeline software, it turns out that it will not work fully. It is necessary to send some special at-commands to it or somehow solve the problem (change the firmware).
Here's how it works in Beeline modems -- alexkuklin.livejournal.com/820953.html?thread=5839... :

Well, gentoos - they seem to be not as dependent on FGM as bubuntushniks - read ru.gentoo-wiki.com/wiki/MF626
There is even cooler one, about computed code.
In the new version of the program, the commands are slightly different and a simple AT+ZOPERTE="beeline" is indispensable.
Code:
OUT: AT+CPBS="SM"\r\n
OUT: AT+CPMS="SM","SM",""\r\n
OUT: AT+ZOPRT=6\r\n
^^^^ ^ stop loop
OUT: AT+ZOPRT=5\r\n
^^^^^ start new loop
OUT: AT+ZSTART\r\n
^^^^^ apparently not necessary anymore
IN: +ZOPERTER: 0,XXXXXXXXXXXXXXXX \r\n
^^^^^ request from the modem. this request should be answered with
OUT: AT+ZOPERTE=1,
IN: +ZOPERTE: 1.1
^^^^^ and this modem said that we guessed right
(or 1.0 if we didn’t guess. in this case, the modem turns red
and stops working until the next restart of the cycle)
IN: +ZOPERTER: 1,XXXXXXXXXXXXXXXX \r\n
^^^^^ after ~2-3 minutes the modem asks the question again
If you answer all of them correctly and quickly (about 20 seconds) +ZOPERTER: then the modem works properly, if you don't answer at all, then the modem works about 3 minutes, asks the second question (he asks the first one immediately when the cycle starts), waits for 20 seconds for an answer, and then turns red, breaks the connection and that's it.
And now the most important thing: the algorithm by which this very YYYYYYYY is calculated. There is an algorithm. A week of torture by the disassembler of a new exe from Beeline has borne fruit. The code is still very raw, because. is a direct conversion from ASM to C ++ (just over 1000 lines) :) so I'll post it somewhere when I get it right. While the modem has been plowing for about an hour and everything is OK. If you have any suggestions, write to alex unnamed .tomsk.ru.
I don't know if this code exists yet.
The URL of the mentioned wiki has changed; see gentoo-wiki.vfose.ru/wiki/MF626 :
This program with a secret on the Internet could only be downloaded from the link from yanex.org/beeline-zte-mf170-v-linux (rotten in other places). For people, it even seemed to work (we run mf626-b09 and the dialer / pppd at the same time; for example, in my ALT ; in general, by query "mf626-b09" in google there are many examples of its use).
I can confirm: this program communicates with the modem and does not allow it to fall off after 2 minutes (seen by the green indicator, which used to turn red), i.e. the secret is unraveled correctly.
But on my system, pppd (running a dialer) cannot work with the /dev/ttyUSB32 device at the same time as this program (maybe in older linux it was possible and worked for people): Resource temporarily unavailable.
Unfortunately, as zerg was rightly indignant , the program is distributed without source codes, so it’s hard to combine the unraveled secret with the dialer so that they do not interfere with each other (I want, say, the dialer to communicate with the modem via mf626-b09).
For those who want to use this modem (or similar) in modern linux (I assume that earlier somehow two programs managed to simultaneously access the device, but now they don’t) there is still a way to change the firmware. I'll stop wasting time fiddling with it for now.
O! This NetworkManager turned out to be capricious (although I kind of saw people write that you can use it). I started pppd manually (I looked in /proc/NNNN/cmdline to see how NetworkManager did it):
/usr/sbin/pppd nodetach lock nodefaultroute ipv6 , user mts ttyUSB34 noipdefault noauth usepeerdns lcp-echo-failure 0 lcp-echo-interval 0 ipparam /org/freedesktop/NetworkManager/PPP/5 plugin /usr/lib64/pppd/2.4. 5/nm-pppd-plugin.so
and had to do it (apparently, NetworkManager itself adds the route, but I didn’t immediately realize that this was not in the pppd command):
ip route add to default via 10.64.64.64 dev ppp0
And now, the Internet works, I write through it.

Answer 4

Have you tried using netwerk manager?

Answer 5

Try adding to the PPP config:

lcp-echo-failure 0
lcp-echo-interval 0

If it does not help , try adding more:
PS Read
here . There, at the end of the page, one-line commands are presented that allow you to raise a PPPoE connection. PPS Baud = 9600 ... Somehow not enough. I think your modem will start up fine on 115200 as well.

Answer 6

Can transfer a piece of iron to the "only modem" mode?