About blocking the Yota mobile application by MTS
Hi, Habr. As you know, on August 13, we started to issue Yota SIM cards from pre-order . It took a little more than a week from that moment - first on Twitter, then on other social media, and then in calls to our support service, similar complaints from users began to appear - they reported that the Yota mobile application was not working. As a result of the analysis, it turned out that problems arose only among MTS subscribers who were trying to launch the Yota application, and precisely when connected to the mobile Internet. When connected via Wi-Fi, the application worked without any complaints. Also, MTS subscribers did not open the Voice section on the yota.ru website.
We assumed that MTS blocked the operation of our application in its network. And soon our guesses were confirmed. But first things first.
Using the Yota application, any smartphone user can order, activate the Yota SIM card and select the required service package. This approach is non-standard for the Russian market - the application allows you to order a new Yota SIM card, or go to us with your current number from another operator.
The first messages about the problem with the Yota mobile app appeared on August 19, one of the MTS subscribers wrote about it in his microblog on Twitter. The application was successfully downloaded and installed, but it hung on the first screen. Experienced, the user found out that this behavior of the application is observed only when using the mobile Internet in the MTS network, when connecting via Wi-Fi everything began to work correctly.
')
After receiving this information, we checked the operation of our application in the networks of other mobile operators. In all cases, except for the MTS network, the application worked correctly. That is, the problem described by the user was indeed reproduced when using the SIM card by our testers.
After a decent amount of complaints from users, our experts turned to MTS support service. On the website mts.ru, according to all the rules, there was a problem with access to certain resources and a request to solve it.
We also duplicated our complaint to the MTS contact center. From the second time, after a long wait for the operator’s response, after several switchings to different specialists, I managed to get an answer that they would take up the question. A few days later the bell rang: they called from the contact center, asked if the problem was resolved. A Yota employee replied that she did not dare. The caller promised to transfer the application to another specialist. More MTS support service did not take any action, we did not receive a written response to our request, or calls.
By the time of our contacting the support service, there were already many messages from other MTS users in the network who were faced with the fact of blocking. This situation even managed to attract the attention of journalists . However, the operator every time denied the fact of blocking, and the head of their press service, in response, accused Yota of “impudent lies” and attempts to “hand out feils for the evil will of a competitor operator” .
In parallel with the attempts to reach the MTS, we studied how blocking is performed. It was clear that this is being done much more thinly than the full circumcision of traffic, since all IP addresses respond without problems. It also turned out that the reason for the inoperability of the application and the Voice section on the site is the following: for their correct operation, access to the service resources static.yota.ru and wa.yota.ru is necessary. When packets are exchanged with them to establish a session, nothing prevents this process. In our case, all subsequent data packets are “cut.” That is, a formal connection is established, but the exchange of “useful” data with a remote resource is immediately blocked.
Since we did not receive a response from MTS, and the blocking continued, we sent an official letter to their management. The very fact of blocking was certified by a notary. We also turned to the independent expert company SPIIRAN, which conducted its own analysis and issued a multi-page official conclusion confirming our “discoveries”. The total volume of the document was more than 100 pages, so we present only the tasks and conclusions made during the study:
Baseline Study / Extended Study
Objective: to confirm or refute the fact that there are problems with the performance of the mobile application and the Yota site from the subscriber’s point of view when using SIM cards and the MTS network, and identify the sources of problems with the performance of the mobile application and the Yota section of the voice, using the MTS network .
Scenario :
1. Turn off the phone
2. Place the SIM card in the phone
3. Turn on the phone, connect to the network operator
4. To fix the service provider to which the connection was established and the connection conditions
5. Check the functionality of the data transfer service: open the websites yandex.ru, google.ru, lenta.ru through the standard browser of the operating system
6. Check the absence of access through a proxy server - go to the 2ip.ru website, fix the external IP address, make sure that the IP address belongs to the operator to which you are connected via the IP address database
7. Measure the data transfer speed using the Speedtest application.
8. Install Yota mobile app on your mobile device.
9. Perform basic checks of the mobile application Yota
10. Open the website section yota.ru/voice through the standard browser of the operating system.
11. Record results
The script must be executed on each phone and with each SIM card used for the current study.
Conclusions : the results of the study confirm the existence of problems with the performance of the mobile application and the Yota site section / voice from the subscriber's point of view when using all the MTS SIM cards purchased for the research and the MTS network of the carrier. At the same time, it is confirmed that when using an alternative telecom operator Beeline, the operability of the Yota mobile application corresponds to the stated behavior, the Yota section of the site is opened by regular means of the operating system.
The results of the extended study showed that for all SIM-cards of MTS, all devices used in the study and for all problematic scenarios, one problem is relevant, with symptoms inherent in all client connections to Yota servers with IP addresses 94.25.232.254, 94.25.232.127. When using an alternative carrier, Beeline, the problem of connecting to these IP addresses is not reproduced, all network connections are established correctly. The problem is that after a correct TCP connection is established, further network communication is interrupted due to the lack of a server response to the TCP client request.
Determining the cause of problems
Purpose : by carrying out an in-depth study to determine the causes of the problem of network interruption when MTS subscribers access Yota servers with IP addresses 94.25.232.254, 94.25.232.127.
To conduct an in-depth study, specialized software was developed that emulates various stages of a TCP connection. The specialized software was launched from the side of the test computer (2) connected to the test phone (1) via the Wi-Fi interface.
In order to further analyze the interim results of the study, these network connections were removed from the Wi-Fi interface of the test computer (2) using the WIRESHARK software package. At the same time, from the servers of Yota, TCPDUMP was also used to remove these network connections with the utility.
Scenario :
1. Turn off the mobile device (1)
2. Place the SIM card in a mobile device (1)
3. Turn on the mobile device (1), connect to the carrier network
4. To fix the service provider to which the connection was made, as well as the connection conditions
5. Perform basic checks of data services
6. Connect the test computer (2) to the Wi-Fi interface of the mobile device (1)
7. Conduct basic checks of the availability of IP addresses and routing to IP addresses via ICMP using the TRACEROUTE and PING standard tools.
8. Record and analyze intermediate results.
9. Carry out a specialized test according to the developed method (see the description of the method below) by passing a TCP packet along the network route to the IP addresses of the Yota servers.
10. Record and analyze the results.
The script must be carried out on each SIM-card MTS.
Methods of specialized research : The method consists in emulating a TCP connection to the Yota server and sequentially changing the TTL TCP packets with a request for data from the client to the server by analogy with the ICMP route determination method (TRACEROUTE command).
When determining the route to the server, the client sends ICMP Echo Request packets with a packet lifetime from TTL = 1 to TTL = (route length). Each network node, having received a packet, reduces it by one and passes further along the route. After receiving an IP packet with TTL = 1, if it is not the destination node of the packet, the network node drops the packet and sends an ICMP Time-to-live exceeded packet to the sender, indicating to the sender that the packet was not forwarded further. If the receiving node is an end node, then it responds to the request with an ICMP Echo Reply packet. By analyzing the headers of the received packets, the client can determine the complete route to the destination node. It is also possible to track potential filtering of IP and ICMP packets on network equipment using this method.
The methodology of the current study repeats the algorithm for determining the route to the receiving node, except that the study does not use the ICMP protocol, but the TCP protocol. In this case, the client first establishes the correct TCP connection, and then sends a TCP packet to request data to the server with the specified TTL. By increasing the TCP packet lifetime from TTL = 1 to TTL = (route length), it is possible to check the presence of filtering of TCP packets on the network equipment, provided that the same equipment does not have ICMP Echo Request / Reply and ICMP Time-to-live filtering Exceeded.
Scenario study :
1. Determination of the "length" of the route to the server. For this information is used from the results of the TRACEROUTE command.
2. Emulated TCP connection establishment (TCP handshake)
3. Send a TCP packet with a given TTL
4. Waiting for a response from the hardware (server).
The script repeats the number of times, according to the length of the route, until a host is found on which the ICMP response to the packet does not arrive, provided there is an ICMP response during the determination of the length of the route. The script is carried out on each SIM card MTS. If filtering of network packets is present on any of the network nodes, then the response to the test packet will not come from this equipment. The carrier that filters packets on the route path is determined by the IP address of the equipment that does not respond to the test packet.
Results : based on the results, it can be concluded that the servers are available via IP, routing is functioning correctly - the distance to the Yota IP addresses is 15 network nodes, including a test phone, IP packets are delivered to the server, responses come from the server, average server response time is 90 ms.
Checking the passage of IP-packets ICMP Echo Request to the IP-addresses of servers Yota was successful. Checking the passage of ICMP Echo Request packets and ICMP Time-to-live exceeded packets with an incremental change in TTL packets revealed partial filtering of ICMP packets at the stage between IP addresses 37.29.4.162 and 94.25.208.193. At the same time, filtering affects only ICMP responses, regardless of whether this type of filtering is available, the request packets reach the Yota IP addresses.
Conclusions : the results of the in-depth study show that the cause of the problem, due to which the client’s mobile device, after sending a TCP data packet, does not receive a response from the server, is the filtering of TCP data packets on the MTS operator’s side in the network equipment area, which is the first network layer equipment that receives traffic from subscriber devices.
The result of the TRACERT command for the server static.yota.ru
Delivery of IP-packets and routing packets from and to the IP-addresses of Yota servers are made correctly. IP service packet filtering was detected that does not affect the final connection establishment and data transfer in the case of using the TCP protocol of the transport layer with guaranteed packet delivery.
An in-depth study on a specially developed method of passing a TCP packet data request with different TTL values ​​showed the presence of TCP packet filtering on the MTS equipment with IP address 10.25.132.90, which is the first network layer equipment that receives traffic from subscriber devices.
The result of sending a TCP packet with TTL = 1 for the server static.yota.ru
The result of the TCP packet transmission with TTL = 2 for the server static.yota.ru
The result of the TCP packet transmission with TTL = 3 for the server static.yota.ru
The result of the TRACERT command for wa.yota.ru server
The result of sending a TCP packet with TTL = 14 for wa.yota.ru server
The result of sending a TCP packet with TTL = 15 for wa.yota.ru server
So, according to the results of the examination, the blocking of auxiliary resources that ensure the performance of the application and the section of the site was confirmed - 94.25.232.254 (wa.yota.ru) and 94.25.232.127 (static.yota.ru). This was observed on all MTS SIM cards used during testing. In networks of other operators, the application and the Voice section on the yota.ru website work correctly.
The expertise confirmed that the network equipment MTS, which receives traffic from subscriber devices, is selectively filtering network packets of data requests. And the filtering was carried out not from the IP addresses of our servers, but to them. At the same time, service packets intended for the correct establishment and termination of the connection are not filtered.
As a result, the mobile application established a connection with the server, sent requests for data for some time, but without waiting, closed the connection. All this led to the fact that “the user observed a very characteristic behavior of the application - a long“ hang ”and lack of response to user actions, which can be regarded as errors and incorrect operation of the application itself”. As a result, users could not use any functions of the application, including ordering a Yota SIM card.
It is worth noting that such selective filtering is misleading technical specialists when trying to analyze network problems, since it is not possible to detect such filtering using regular network failure analysis tools.
MTS actions indirectly damaged our reputation, because users blame Yota for the application’s inoperability. This is not to mention the time, effort and money we spent on the above described investigation.
Since August 21, we have repeatedly appealed to MTS representatives at different levels with the requirement to unlock the Yota application. No action was taken by them. Today, according to the results of tests and feedback from MTS customers who have previously experienced problems with the application, we confirm that the application has started to work correctly. We attribute this to the fact that today the general public has become aware of our preparation of a statement to the FAS , and MTS promptly took steps to unlock Yota. Despite the solution to the problem, we will still file a complaint.
We assumed that MTS blocked the operation of our application in its network. And soon our guesses were confirmed. But first things first.
A few words about the application
Using the Yota application, any smartphone user can order, activate the Yota SIM card and select the required service package. This approach is non-standard for the Russian market - the application allows you to order a new Yota SIM card, or go to us with your current number from another operator.
Outset
The first messages about the problem with the Yota mobile app appeared on August 19, one of the MTS subscribers wrote about it in his microblog on Twitter. The application was successfully downloaded and installed, but it hung on the first screen. Experienced, the user found out that this behavior of the application is observed only when using the mobile Internet in the MTS network, when connecting via Wi-Fi everything began to work correctly.
')
After receiving this information, we checked the operation of our application in the networks of other mobile operators. In all cases, except for the MTS network, the application worked correctly. That is, the problem described by the user was indeed reproduced when using the SIM card by our testers.
First act
After a decent amount of complaints from users, our experts turned to MTS support service. On the website mts.ru, according to all the rules, there was a problem with access to certain resources and a request to solve it.
We also duplicated our complaint to the MTS contact center. From the second time, after a long wait for the operator’s response, after several switchings to different specialists, I managed to get an answer that they would take up the question. A few days later the bell rang: they called from the contact center, asked if the problem was resolved. A Yota employee replied that she did not dare. The caller promised to transfer the application to another specialist. More MTS support service did not take any action, we did not receive a written response to our request, or calls.
By the time of our contacting the support service, there were already many messages from other MTS users in the network who were faced with the fact of blocking. This situation even managed to attract the attention of journalists . However, the operator every time denied the fact of blocking, and the head of their press service, in response, accused Yota of “impudent lies” and attempts to “hand out feils for the evil will of a competitor operator” .
Second act
In parallel with the attempts to reach the MTS, we studied how blocking is performed. It was clear that this is being done much more thinly than the full circumcision of traffic, since all IP addresses respond without problems. It also turned out that the reason for the inoperability of the application and the Voice section on the site is the following: for their correct operation, access to the service resources static.yota.ru and wa.yota.ru is necessary. When packets are exchanged with them to establish a session, nothing prevents this process. In our case, all subsequent data packets are “cut.” That is, a formal connection is established, but the exchange of “useful” data with a remote resource is immediately blocked.
Third act
Since we did not receive a response from MTS, and the blocking continued, we sent an official letter to their management. The very fact of blocking was certified by a notary. We also turned to the independent expert company SPIIRAN, which conducted its own analysis and issued a multi-page official conclusion confirming our “discoveries”. The total volume of the document was more than 100 pages, so we present only the tasks and conclusions made during the study:
Baseline Study / Extended Study
Objective: to confirm or refute the fact that there are problems with the performance of the mobile application and the Yota site from the subscriber’s point of view when using SIM cards and the MTS network, and identify the sources of problems with the performance of the mobile application and the Yota section of the voice, using the MTS network .
Scenario :
1. Turn off the phone
2. Place the SIM card in the phone
3. Turn on the phone, connect to the network operator
4. To fix the service provider to which the connection was established and the connection conditions
5. Check the functionality of the data transfer service: open the websites yandex.ru, google.ru, lenta.ru through the standard browser of the operating system
6. Check the absence of access through a proxy server - go to the 2ip.ru website, fix the external IP address, make sure that the IP address belongs to the operator to which you are connected via the IP address database
7. Measure the data transfer speed using the Speedtest application.
8. Install Yota mobile app on your mobile device.
9. Perform basic checks of the mobile application Yota
10. Open the website section yota.ru/voice through the standard browser of the operating system.
11. Record results
The script must be executed on each phone and with each SIM card used for the current study.
Conclusions : the results of the study confirm the existence of problems with the performance of the mobile application and the Yota site section / voice from the subscriber's point of view when using all the MTS SIM cards purchased for the research and the MTS network of the carrier. At the same time, it is confirmed that when using an alternative telecom operator Beeline, the operability of the Yota mobile application corresponds to the stated behavior, the Yota section of the site is opened by regular means of the operating system.
The results of the extended study showed that for all SIM-cards of MTS, all devices used in the study and for all problematic scenarios, one problem is relevant, with symptoms inherent in all client connections to Yota servers with IP addresses 94.25.232.254, 94.25.232.127. When using an alternative carrier, Beeline, the problem of connecting to these IP addresses is not reproduced, all network connections are established correctly. The problem is that after a correct TCP connection is established, further network communication is interrupted due to the lack of a server response to the TCP client request.
Determining the cause of problems
Purpose : by carrying out an in-depth study to determine the causes of the problem of network interruption when MTS subscribers access Yota servers with IP addresses 94.25.232.254, 94.25.232.127.
To conduct an in-depth study, specialized software was developed that emulates various stages of a TCP connection. The specialized software was launched from the side of the test computer (2) connected to the test phone (1) via the Wi-Fi interface.
In order to further analyze the interim results of the study, these network connections were removed from the Wi-Fi interface of the test computer (2) using the WIRESHARK software package. At the same time, from the servers of Yota, TCPDUMP was also used to remove these network connections with the utility.
Scenario :
1. Turn off the mobile device (1)
2. Place the SIM card in a mobile device (1)
3. Turn on the mobile device (1), connect to the carrier network
4. To fix the service provider to which the connection was made, as well as the connection conditions
5. Perform basic checks of data services
6. Connect the test computer (2) to the Wi-Fi interface of the mobile device (1)
7. Conduct basic checks of the availability of IP addresses and routing to IP addresses via ICMP using the TRACEROUTE and PING standard tools.
8. Record and analyze intermediate results.
9. Carry out a specialized test according to the developed method (see the description of the method below) by passing a TCP packet along the network route to the IP addresses of the Yota servers.
10. Record and analyze the results.
The script must be carried out on each SIM-card MTS.
Methods of specialized research : The method consists in emulating a TCP connection to the Yota server and sequentially changing the TTL TCP packets with a request for data from the client to the server by analogy with the ICMP route determination method (TRACEROUTE command).
When determining the route to the server, the client sends ICMP Echo Request packets with a packet lifetime from TTL = 1 to TTL = (route length). Each network node, having received a packet, reduces it by one and passes further along the route. After receiving an IP packet with TTL = 1, if it is not the destination node of the packet, the network node drops the packet and sends an ICMP Time-to-live exceeded packet to the sender, indicating to the sender that the packet was not forwarded further. If the receiving node is an end node, then it responds to the request with an ICMP Echo Reply packet. By analyzing the headers of the received packets, the client can determine the complete route to the destination node. It is also possible to track potential filtering of IP and ICMP packets on network equipment using this method.
The methodology of the current study repeats the algorithm for determining the route to the receiving node, except that the study does not use the ICMP protocol, but the TCP protocol. In this case, the client first establishes the correct TCP connection, and then sends a TCP packet to request data to the server with the specified TTL. By increasing the TCP packet lifetime from TTL = 1 to TTL = (route length), it is possible to check the presence of filtering of TCP packets on the network equipment, provided that the same equipment does not have ICMP Echo Request / Reply and ICMP Time-to-live filtering Exceeded.
Scenario study :
1. Determination of the "length" of the route to the server. For this information is used from the results of the TRACEROUTE command.
2. Emulated TCP connection establishment (TCP handshake)
3. Send a TCP packet with a given TTL
4. Waiting for a response from the hardware (server).
The script repeats the number of times, according to the length of the route, until a host is found on which the ICMP response to the packet does not arrive, provided there is an ICMP response during the determination of the length of the route. The script is carried out on each SIM card MTS. If filtering of network packets is present on any of the network nodes, then the response to the test packet will not come from this equipment. The carrier that filters packets on the route path is determined by the IP address of the equipment that does not respond to the test packet.
Results : based on the results, it can be concluded that the servers are available via IP, routing is functioning correctly - the distance to the Yota IP addresses is 15 network nodes, including a test phone, IP packets are delivered to the server, responses come from the server, average server response time is 90 ms.
Checking the passage of IP-packets ICMP Echo Request to the IP-addresses of servers Yota was successful. Checking the passage of ICMP Echo Request packets and ICMP Time-to-live exceeded packets with an incremental change in TTL packets revealed partial filtering of ICMP packets at the stage between IP addresses 37.29.4.162 and 94.25.208.193. At the same time, filtering affects only ICMP responses, regardless of whether this type of filtering is available, the request packets reach the Yota IP addresses.
Conclusions : the results of the in-depth study show that the cause of the problem, due to which the client’s mobile device, after sending a TCP data packet, does not receive a response from the server, is the filtering of TCP data packets on the MTS operator’s side in the network equipment area, which is the first network layer equipment that receives traffic from subscriber devices.
The result of the TRACERT command for the server static.yota.ru
Delivery of IP-packets and routing packets from and to the IP-addresses of Yota servers are made correctly. IP service packet filtering was detected that does not affect the final connection establishment and data transfer in the case of using the TCP protocol of the transport layer with guaranteed packet delivery.
An in-depth study on a specially developed method of passing a TCP packet data request with different TTL values ​​showed the presence of TCP packet filtering on the MTS equipment with IP address 10.25.132.90, which is the first network layer equipment that receives traffic from subscriber devices.
The result of sending a TCP packet with TTL = 1 for the server static.yota.ru
The result of the TCP packet transmission with TTL = 2 for the server static.yota.ru
The result of the TCP packet transmission with TTL = 3 for the server static.yota.ru
The result of the TRACERT command for wa.yota.ru server
The result of sending a TCP packet with TTL = 14 for wa.yota.ru server
The result of sending a TCP packet with TTL = 15 for wa.yota.ru server
Conclusion
So, according to the results of the examination, the blocking of auxiliary resources that ensure the performance of the application and the section of the site was confirmed - 94.25.232.254 (wa.yota.ru) and 94.25.232.127 (static.yota.ru). This was observed on all MTS SIM cards used during testing. In networks of other operators, the application and the Voice section on the yota.ru website work correctly.
The expertise confirmed that the network equipment MTS, which receives traffic from subscriber devices, is selectively filtering network packets of data requests. And the filtering was carried out not from the IP addresses of our servers, but to them. At the same time, service packets intended for the correct establishment and termination of the connection are not filtered.
As a result, the mobile application established a connection with the server, sent requests for data for some time, but without waiting, closed the connection. All this led to the fact that “the user observed a very characteristic behavior of the application - a long“ hang ”and lack of response to user actions, which can be regarded as errors and incorrect operation of the application itself”. As a result, users could not use any functions of the application, including ordering a Yota SIM card.
It is worth noting that such selective filtering is misleading technical specialists when trying to analyze network problems, since it is not possible to detect such filtering using regular network failure analysis tools.
MTS actions indirectly damaged our reputation, because users blame Yota for the application’s inoperability. This is not to mention the time, effort and money we spent on the above described investigation.
The climax (or not yet?)
Since August 21, we have repeatedly appealed to MTS representatives at different levels with the requirement to unlock the Yota application. No action was taken by them. Today, according to the results of tests and feedback from MTS customers who have previously experienced problems with the application, we confirm that the application has started to work correctly. We attribute this to the fact that today the general public has become aware of our preparation of a statement to the FAS , and MTS promptly took steps to unlock Yota. Despite the solution to the problem, we will still file a complaint.
Source: https://habr.com/ru/post/236515/
All Articles