Is there a problem with the MTS mobile traffic in some regions, or the skis do not travel?

Hello, dear habrovchane. I lead a small project for monitoring motor transport, but this has nothing to do with business. The essence is the following - the equipment is equipped with SIM cards of the MTS company, WISMO 228 cellular modems are used. For several years everything went well, but recently, specifically from July 21, 2015 I began to notice oddities in the behavior of some objects:



At the entrance of the car in any of the regions - Tatarstan, Bashkortostan, Penza region, strange glitches with a connection begin, namely:



UDP packets from devices reach the server.

TCP packets from the devices reach the server (the server shows an open TCP connection).

In the opposite direction, the data do not reach.

')

Devices work with the server using the FTP protocol, and they cannot wait for the greeting from the FTP server to start authorization.

I tried to force authorization on FTP - in the server logs there is not even a mention of authorization attempts from such devices.



The following patterns are observed:



The majority of devices have an “external” IP address in the 213.87.xxx.xx range (Internet access gateway), while the buggy devices have the IP address 85.140.xxx, or 95.153.167.xx (Volgograd region). This address is assigned automatically, i.e. the device takes a PPN session when it picks up a session; it doesn’t invent anything by itself.



When leaving the buggy regions, the data exchange work is completely restored.

In other regions, such as the Far East, the device address is 80.83.237.xx, while the exchange is normal.

In Kazakhstan, it also works fine (with a Kazakhstan sim card).



For the sake of interest, I built a route to the IP address.



traceroute 85.140.0.87

traceroute to 85.140.0.87 (85.140.0.87), 64 hops max, 52 byte packets

1 gw.ispsystem.net (37.230.113.254) 0.318 ms 0.287 ms 0.286 ms

2 edge.webdc.ru (92.63.108.97) 14.326 ms 7.129 ms 0.579 ms

3 213.219.206.17 (213.219.206.17) 1.082 ms 1.235 ms 15.737 ms

4 vl–709.sr5.msk7.ip.di–net.ru (213.248.3.133) 0.969 ms 0.932 ms 0.835 ms

5 m9 –cr03–ae10.995.msk.stream–internet.net (212.188.60.173) 1.258 ms 1.241 ms 1.246 ms

6 bek–cr01–ae7.52.nnov.stream–internet.net (212.188.28.70) 8.423 ms 7.997 ms 7.996 ms

7 pgag–cr02–a5.52.nnov.stream–internet.net (195.34.59.97) 10.143 ms 7.984 ms 7.968 ms

eight * * *

9 * * *

ten * * *



This is a “buggy” IP. When I build a route to this address range, it always ends on the 7th line host. And it doesn’t matter where I’m trying to punch the route from the server from which the exchange is being performed, or from any other computer connected to other providers.



The track of a healthy person to a non-buggy device



~ traceroute 213.87.123.66

traceroute to 213.87.123.66 (213.87.123.66), 64 hops max, 52 byte packets

1 gw.ispsystem.net (37.230.113.254) 0.433 ms 0.401 ms 0.393 ms

2 edge.webdc.ru (92.63.108.97) 0.358 ms 0.386 ms 0.356 ms

3 213.219.206.17 (213.219.206.17) 5.998 ms * 130.690 ms

4 vl–709.sr5.msk7.ip.di–net.ru (213.248.3.133) 1.000 ms 0.899 ms 0.961 ms

5 m9 –cr03–a10.995.msk.stream–internet.net (212.188.60.173) 1.354 ms 1.374 ms 1.337 ms

6 m9 –cr05–a1.199.msk.stream–internet.net (195.34.53.49) 53.896 ms 53.863 ms 53.900 ms

7 psnmich–cr01– a4.62.rzn.stream–internet.net (212.188.42.70) 60.579 ms 128.957 ms

psnmich–cr01–ae6.62.rzn.stream–internet.net (212.188.29.194) 98.938 ms

8 pstamb–cr01–ae5.68.tam.stream–internet.net (212.188.28.202) 54.318 ms

pstamb –cr01–ae7.68.tam.stream–internet.net (212.188.29.186) 53.930 ms 54.087 ms

9 pspenz–cr01–ae4.58.pen.stream–internet.net (212.188.29.182) 54.744 ms

pspenz–cr01–ae3.58.pen.stream–internet.net (212.188.28.246) 54.070 ms 54.829 ms

10 psulnsk–cr01–ae2.73.uln.stream–internet.net (212.188.28.210) 63.088 ms 57.998 ms

psulnsk–cr01–ae5.73.uln.stream–internet.net (212.188.42.34) 54.026 ms

11 pskir–cr01– a1.63.sam.stream–internet.net (212.188.28.226) 54.266 ms 54.288 ms

pskir–cr01– a3.63.sam.stream–internet.net (212.188.42.30) 56.315 ms

12 psbek–cr01–ae4.2.ufa.stream–internet.net (212.188.42.82) 53.956 ms 66.351 ms

psbek–cr01–ae2.2.ufa.stream–internet.net (212.188.28.50) 53.901 ms

13 psshag–cr01–ae3.74.chel.stream–internet.net (212.188.42.98) 31.250 ms 31.555 ms 31.370 ms

14 psber–cr01–ae4.72.tum.stream–internet.net (212.188.29.226) 60.442 ms 54.279 ms 54.335 ms

15 pstav–cr01–ae5.55.omsk.stream–internet.net (212.188.28.162) 53.861 ms 63.988 ms 53.835 ms

16 psvost–cr01–ae6.54.nsk.stream–internet.net (212.188.28.158) 52.932 ms 53.157 ms 53.471 ms

17 stn–cr03–be3.54.nsk.stream–internet.net (212.188.29.133) 58.571 ms 57.156 ms 73.175 ms

18 mts –siberia.nsk.stream–internet.net (195.34.36.58) 81.223 ms 53.714 ms 53.786 ms

19 217.8.224.126 (217.8.224.126) 54.576 ms 54.527 ms 54.414 ms

20 * * *

21 213.87.117.245 (213.87.117.245) 56.088 ms 56.120 ms 55.998 ms

22 * * *



I have been torturing the support service for a week now, but they can only say that "the balance in your account is positive." There is no hope for them.

To techies are not allowed. I can not determine where the problem is.



Maybe someone from the community has the opportunity to help track the bug? Thank.



- Update of 08/06/2015 -

In general, this is the case - we managed to “catch” the machine on the approach to the problem region and copy the FTP config to another port.

I rewrote the FTP configuration on the server, replacing one value - the port number.



- Update from 08/07/2015 -

After writing the post, several people responded, including MTS specialists, the problem was solved. For which many thanks to them.