About blocking the Yota mobile application by MTS
Hello, Habr. As you know, on August 13, we started issuing Yota SIM cards from pre-order . A little more than a week has passed since that moment - and first on Twitter, then on other social media, and then in appeals to our support service, similar complaints from users began to appear - they reported a broken Yota mobile application. As a result of the analysis, it turned out that only MTS subscribers who tried to launch the Yota application encountered problems, and it was when they connected to the mobile Internet. When connected via Wi-Fi, the application worked flawlessly. Also, MTS subscribers did not open the Voice section on yota.ru.
We assumed that MTS blocked the operation of our application on its network. And soon our guesses were confirmed. But first things first.
Using the Yota application, any smartphone user can order, activate a Yota SIM card and select the necessary service package. This approach is non-standard for the Russian market - the application allows you to both order a new Yota SIM-card and go to us with your current number from another operator.
The first messages about the problem with the Yota mobile application appeared on August 19, one of the MTS subscribers wrote about this in his microblog on Twitter. The application successfully downloaded and installed, but it hung on the first screen. Empirically, the user found out that this behavior of the application is observed only when using mobile Internet in the MTS network, when connected via Wi-Fi everything started 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 really reproduced when using the SIM card by our testers.
After a decent amount of complaints from users, our specialists contacted the MTS support service. On the site mts.ru, by all rules, a problem was registered 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 an operator’s response, after several switchings to different specialists, it was possible to get an answer that they will deal with the issue. A few days later a call rang: they called from the contact center, asked if the problem had been resolved. A Yota employee replied that he did not dare. The caller promised to transfer the application to another specialist. The MTS support service took no further action; we did not receive a written response to our request or calls.
By the time we contacted the support service on the network, there were already many messages from other MTS users who encountered 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 "blatant lies" and attempts to "give out fails as the rival operator’s evil will . "
In parallel with attempts to reach MTS, we studied how blocking is carried out. It was clear that this was done much thinner than completely cutting off traffic, since all IP addresses pinged without any problems. It also turned out that the reason for the inoperability of the application and the Voice section on the site is as follows: for their correct operation, access to the service resources static.yota.ru and wa.yota.ru is required. 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, formally, a connection is established, however, 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 fact of blocking was certified by a notary. We also contacted the independent expert company SPIIRAN, which conducted its own analysis and issued a multi-page official report confirming our “discoveries”. The total volume of the document amounted to more than 100 pages, so we will only present the tasks and conclusions made during the study:
Basic research / advanced research
Purpose: to confirm or deny the fact that there are problems with the operability of the mobile application and the Yota website from the point of view of the subscriber when using SIM cards and the MTS network of the telecom operator, as well as to identify the sources of problems with the health of the mobile application and the / voice section of the Yota website when using the MTS network of the telecom operator .
Scenario :
1. Turn off the phone
2. Place the SIM card in the phone
3. Turn on the phone, connect to the network of the service provider
4. Fix the service provider to which the connection was established, and the connection conditions
5. Check the operation of the data transfer service: through the standard operating browser systems open sites yandex.ru, google.ru, lenta.ru
6. Check the lack of access through a proxy server - go to 2ip.ru, fix the external IP address, make sure that the IP address belongs to the operator you are connected to through the database of IP addresses
7. Measure the data transfer speed using Speedtest applications
8. Install the Yota
9 mobile application on the mobile device . Perform basic checks on the operation of the Yota
10 mobile application . Open the section of the site yota.ru/voice
11 using the standard operating system browser. Record the results
The script should be executed on each phone and with each SIM card used for the current study.
findings: the results of the study confirm the existence of problems with the operability of the mobile application and the / voice section of the Yota website from the point of view of the subscriber when using all MTS SIM-cards purchased for research and the network of the MTS telecom operator. At the same time, it is confirmed that when using the alternative Beeline telecommunications operator, the Yota mobile application's operability corresponds to the declared behavior, the / voice section of the Yota website opens using regular means of the operating system.
The results of an extended study showed that for all MTS SIM cards, all devices used in the study, and for all problematic scenarios, one problem is relevant, with symptoms common to all client connections to Yota servers with IP addresses 94.25.232.254, 94.25.232.127. When using the alternative Beeline telecommunications operator, the problem of connecting to these IP addresses is not reproduced, all network connections are established correctly. The problem is that after the correct TCP connection is established, further network communication is interrupted due to the lack of server response to the client’s TCP request.
Determining the cause of the problem
Purpose: by conducting an in-depth study, determine the causes of the problem of disruption of network interaction when MTS subscribers contact Yota servers with IP addresses 94.25.232.254, 94.25.232.127.
To conduct an in-depth study, specialized software was developed that emulated the various stages of a TCP connection. 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 intermediate results of the study, the data of 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 side of Yota servers, the removal of network connection data by TCPDUMP utility was also started.
Scenario:
1. Turn off the mobile device (1)
2. Place the SIM card in the mobile device (1)
3. Turn on the mobile device (1), connect to the network of the service provider
4. Fix the service provider to which you are connected, as well as the connection conditions
5. Perform basic checks on the operation of the data transfer service
6. Connect the test computer (2) to the Wi-Fi interface of the mobile device (1)
7. Perform basic checks on the availability of IP addresses and routing to IP addresses via ICMP using standard TRACEROUTE and PING tools .
8. Record and analyze intermediate results
9. Carry out a specialized test according to the developed methodology (see the description of the methodology below) on passing a TCP packet along a network route to the IP addresses of Yota
10 servers . Record and analyze the results.
The script must be conducted on each MTS SIM card.
Specialized research methodology: The technique consists in emulating a TCP connection with a Yota server and sequentially changing TTL TCP packets with requesting data from the client to the server, similar to the method for determining the route to the server using ICMP protocol (TRACEROUTE command).
When determining the route to the server, the client sends ICMP Echo Request packets with the packet lifetime from TTL = 1 to TTL = (route length). Each network node, having received a packet, reduces it by one and passes it further along the route. After receiving an IP packet with TTL = 1, if it is not the final packet receiving node, the network node discards the packet and sends an ICMP Time-to-live exceeded packet to the sender, indicating to the sender that the packet was not redirected further. If the destination node is the destination node, then it responds to the request with ICMP Echo Reply. By analyzing the headers of the received packets, the client can determine the full route to the receiving node. Also, using this method, it is possible to track the potential filtering of IP and ICMP packets on network equipment.
The methodology of the current study repeats the algorithm for determining the route to the recipient node, except that the study uses not the ICMP protocol, but the TCP protocol. In this case, the client first establishes the correct TCP connection, and then transmits the TCP packet of the data request 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 for filtering on the network equipment of TCP packets, provided that the same equipment does not filter ICMP packets Echo Request / Reply and ICMP Time-to-live Exceeded.
Research scenario :
1. Determining the "length" of the route to the server. For this, information from the results of the TRACEROUTE command is used.
2. Emulates the establishment of a TCP connection (TCP handshake)
3. Sending a TCP packet with the specified TTL
4. Waiting for a response from the equipment (server).
The script is repeated 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 that there is an ICMP response during the determination of the length of the route. The script is conducted on each MTS SIM card. 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 service provider that filters packets on the route path is determined by the IP address of equipment that does not respond to the test packet.
results: according to the results, we can conclude that the servers are accessible via IP protocol, routing works correctly - the distance to Yota IP addresses is 15 network nodes, including a test telephone, IP packets are delivered to the server, responses are received from the server, the average server response time is 90 ms
Verifying that ICMP Echo Request IP packets passed through to the IP addresses of Yota servers was successful. Checking the passage of ICMP Echo Request packets and ICMP Time-to-live exceeded packets when incrementally changing TTL packets revealed a partial filtering of ICMP packets between IP addresses 37.29.4.162 and 94.25.208.193. In this case, filtering affects only ICMP responses, regardless of the presence of this type of filtering, request packets reach IP addresses of Yota.
findings: the results of an in-depth study show that the cause of the problem due to which the client mobile device does not receive a response from the server after sending a TCP packet with data is the filtering of TCP packets with data on the side of the MTS telecom operator in the area of network equipment, which It is the first equipment at the network level, which receives traffic from subscriber devices.
The result of the TRACERT command execution for the static.yota.ru server
Delivery of IP packets and routing of packets from and to the IP addresses of Yota servers are performed correctly. IP service packet filtering was detected that does not affect the final connection and data transfer in the case of using the TCP protocol of the transport layer with guaranteed delivery of packets.
An in-depth study on a specially developed technique for passing a TCP packet for requesting data with various TTL values showed the presence of filtering for the TCP packet for the request on MTS equipment with IP address 10.25.132.90, which is the first network-level equipment that receives traffic from subscriber devices.
Result of transmitting a TCP packet with TTL = 1 for the server static.yota.ru
Result of transmitting a TCP packet with TTL = 1 for the server static.yota.ru
Result of transmitting a TCP packet with TTL = 3 for the server static.yota.ru
Result of the TRACERT command for server wa.yota.ru
Result of transmitting TCP packet with TTL = 14 for server wa.yota.ru
Result of transmitting TCP packet with TTL = 15 for server wa.yota.ru
So, according to the results of the examination, it was confirmed that auxiliary resources were blocked, which ensure the health of the application and the site section - 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 the networks of other operators, the application and the Voice section on yota.ru work correctly.
The examination confirmed that on the network equipment of MTS, which receives traffic from subscriber devices, there is a selective filtering of network packets of data requests. Moreover, 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" freeze "and lack of reaction to user actions, which can be regarded as errors and incorrect operation of the application itself." As a result, users could not use any of the application's features, including ordering a Yota SIM card.
It is especially worth noting that such selective filtering is misleading to technical specialists when trying to analyze network problems, since it is not possible to detect such filtering using regular means of analyzing network failures.
MTS’s actions indirectly damaged our reputation, as users accuse Yota of application inoperability. This is not to mention the time, effort and money spent by us on the above investigation.
Since August 21, we have repeatedly contacted MTS representatives at different levels with the requirement to unlock the Yota application. No measures were taken by them. Today, according to the results of tests and feedback from MTS clients who previously experienced problems with the application, we confirm that the application began 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 measures to unlock Yota. Despite resolving the issue, we will still file a complaint.
We assumed that MTS blocked the operation of our application on 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 a Yota SIM card and select the necessary service package. This approach is non-standard for the Russian market - the application allows you to both order a new Yota SIM-card and go to us with your current number from another operator.
Tie
The first messages about the problem with the Yota mobile application appeared on August 19, one of the MTS subscribers wrote about this in his microblog on Twitter. The application successfully downloaded and installed, but it hung on the first screen. Empirically, the user found out that this behavior of the application is observed only when using mobile Internet in the MTS network, when connected via Wi-Fi everything started 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 really reproduced when using the SIM card by our testers.
First act
After a decent amount of complaints from users, our specialists contacted the MTS support service. On the site mts.ru, by all rules, a problem was registered 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 an operator’s response, after several switchings to different specialists, it was possible to get an answer that they will deal with the issue. A few days later a call rang: they called from the contact center, asked if the problem had been resolved. A Yota employee replied that he did not dare. The caller promised to transfer the application to another specialist. The MTS support service took no further action; we did not receive a written response to our request or calls.
By the time we contacted the support service on the network, there were already many messages from other MTS users who encountered 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 "blatant lies" and attempts to "give out fails as the rival operator’s evil will . "
Second act
In parallel with attempts to reach MTS, we studied how blocking is carried out. It was clear that this was done much thinner than completely cutting off traffic, since all IP addresses pinged without any problems. It also turned out that the reason for the inoperability of the application and the Voice section on the site is as follows: for their correct operation, access to the service resources static.yota.ru and wa.yota.ru is required. 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, formally, a connection is established, however, 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 fact of blocking was certified by a notary. We also contacted the independent expert company SPIIRAN, which conducted its own analysis and issued a multi-page official report confirming our “discoveries”. The total volume of the document amounted to more than 100 pages, so we will only present the tasks and conclusions made during the study:
Basic research / advanced research
Purpose: to confirm or deny the fact that there are problems with the operability of the mobile application and the Yota website from the point of view of the subscriber when using SIM cards and the MTS network of the telecom operator, as well as to identify the sources of problems with the health of the mobile application and the / voice section of the Yota website when using the MTS network of the telecom operator .
Scenario :
1. Turn off the phone
2. Place the SIM card in the phone
3. Turn on the phone, connect to the network of the service provider
4. Fix the service provider to which the connection was established, and the connection conditions
5. Check the operation of the data transfer service: through the standard operating browser systems open sites yandex.ru, google.ru, lenta.ru
6. Check the lack of access through a proxy server - go to 2ip.ru, fix the external IP address, make sure that the IP address belongs to the operator you are connected to through the database of IP addresses
7. Measure the data transfer speed using Speedtest applications
8. Install the Yota
9 mobile application on the mobile device . Perform basic checks on the operation of the Yota
10 mobile application . Open the section of the site yota.ru/voice
11 using the standard operating system browser. Record the results
The script should be executed on each phone and with each SIM card used for the current study.
findings: the results of the study confirm the existence of problems with the operability of the mobile application and the / voice section of the Yota website from the point of view of the subscriber when using all MTS SIM-cards purchased for research and the network of the MTS telecom operator. At the same time, it is confirmed that when using the alternative Beeline telecommunications operator, the Yota mobile application's operability corresponds to the declared behavior, the / voice section of the Yota website opens using regular means of the operating system.
The results of an extended study showed that for all MTS SIM cards, all devices used in the study, and for all problematic scenarios, one problem is relevant, with symptoms common to all client connections to Yota servers with IP addresses 94.25.232.254, 94.25.232.127. When using the alternative Beeline telecommunications operator, the problem of connecting to these IP addresses is not reproduced, all network connections are established correctly. The problem is that after the correct TCP connection is established, further network communication is interrupted due to the lack of server response to the client’s TCP request.
Determining the cause of the problem
Purpose: by conducting an in-depth study, determine the causes of the problem of disruption of network interaction when MTS subscribers contact Yota servers with IP addresses 94.25.232.254, 94.25.232.127.
To conduct an in-depth study, specialized software was developed that emulated the various stages of a TCP connection. 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 intermediate results of the study, the data of 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 side of Yota servers, the removal of network connection data by TCPDUMP utility was also started.
Scenario:
1. Turn off the mobile device (1)
2. Place the SIM card in the mobile device (1)
3. Turn on the mobile device (1), connect to the network of the service provider
4. Fix the service provider to which you are connected, as well as the connection conditions
5. Perform basic checks on the operation of the data transfer service
6. Connect the test computer (2) to the Wi-Fi interface of the mobile device (1)
7. Perform basic checks on the availability of IP addresses and routing to IP addresses via ICMP using standard TRACEROUTE and PING tools .
8. Record and analyze intermediate results
9. Carry out a specialized test according to the developed methodology (see the description of the methodology below) on passing a TCP packet along a network route to the IP addresses of Yota
10 servers . Record and analyze the results.
The script must be conducted on each MTS SIM card.
Specialized research methodology: The technique consists in emulating a TCP connection with a Yota server and sequentially changing TTL TCP packets with requesting data from the client to the server, similar to the method for determining the route to the server using ICMP protocol (TRACEROUTE command).
When determining the route to the server, the client sends ICMP Echo Request packets with the packet lifetime from TTL = 1 to TTL = (route length). Each network node, having received a packet, reduces it by one and passes it further along the route. After receiving an IP packet with TTL = 1, if it is not the final packet receiving node, the network node discards the packet and sends an ICMP Time-to-live exceeded packet to the sender, indicating to the sender that the packet was not redirected further. If the destination node is the destination node, then it responds to the request with ICMP Echo Reply. By analyzing the headers of the received packets, the client can determine the full route to the receiving node. Also, using this method, it is possible to track the potential filtering of IP and ICMP packets on network equipment.
The methodology of the current study repeats the algorithm for determining the route to the recipient node, except that the study uses not the ICMP protocol, but the TCP protocol. In this case, the client first establishes the correct TCP connection, and then transmits the TCP packet of the data request 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 for filtering on the network equipment of TCP packets, provided that the same equipment does not filter ICMP packets Echo Request / Reply and ICMP Time-to-live Exceeded.
Research scenario :
1. Determining the "length" of the route to the server. For this, information from the results of the TRACEROUTE command is used.
2. Emulates the establishment of a TCP connection (TCP handshake)
3. Sending a TCP packet with the specified TTL
4. Waiting for a response from the equipment (server).
The script is repeated 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 that there is an ICMP response during the determination of the length of the route. The script is conducted on each MTS SIM card. 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 service provider that filters packets on the route path is determined by the IP address of equipment that does not respond to the test packet.
results: according to the results, we can conclude that the servers are accessible via IP protocol, routing works correctly - the distance to Yota IP addresses is 15 network nodes, including a test telephone, IP packets are delivered to the server, responses are received from the server, the average server response time is 90 ms
Verifying that ICMP Echo Request IP packets passed through to the IP addresses of Yota servers was successful. Checking the passage of ICMP Echo Request packets and ICMP Time-to-live exceeded packets when incrementally changing TTL packets revealed a partial filtering of ICMP packets between IP addresses 37.29.4.162 and 94.25.208.193. In this case, filtering affects only ICMP responses, regardless of the presence of this type of filtering, request packets reach IP addresses of Yota.
findings: the results of an in-depth study show that the cause of the problem due to which the client mobile device does not receive a response from the server after sending a TCP packet with data is the filtering of TCP packets with data on the side of the MTS telecom operator in the area of network equipment, which It is the first equipment at the network level, which receives traffic from subscriber devices.
The result of the TRACERT command execution for the static.yota.ru server
Delivery of IP packets and routing of packets from and to the IP addresses of Yota servers are performed correctly. IP service packet filtering was detected that does not affect the final connection and data transfer in the case of using the TCP protocol of the transport layer with guaranteed delivery of packets.
An in-depth study on a specially developed technique for passing a TCP packet for requesting data with various TTL values showed the presence of filtering for the TCP packet for the request on MTS equipment with IP address 10.25.132.90, which is the first network-level equipment that receives traffic from subscriber devices.
Result of transmitting a TCP packet with TTL = 1 for the server static.yota.ru
Result of transmitting a TCP packet with TTL = 1 for the server static.yota.ru
Result of transmitting a TCP packet with TTL = 3 for the server static.yota.ru
Result of the TRACERT command for server wa.yota.ru
Result of transmitting TCP packet with TTL = 14 for server wa.yota.ru
Result of transmitting TCP packet with TTL = 15 for server wa.yota.ru
Conclusion
So, according to the results of the examination, it was confirmed that auxiliary resources were blocked, which ensure the health of the application and the site section - 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 the networks of other operators, the application and the Voice section on yota.ru work correctly.
The examination confirmed that on the network equipment of MTS, which receives traffic from subscriber devices, there is a selective filtering of network packets of data requests. Moreover, 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" freeze "and lack of reaction to user actions, which can be regarded as errors and incorrect operation of the application itself." As a result, users could not use any of the application's features, including ordering a Yota SIM card.
It is especially worth noting that such selective filtering is misleading to technical specialists when trying to analyze network problems, since it is not possible to detect such filtering using regular means of analyzing network failures.
MTS’s actions indirectly damaged our reputation, as users accuse Yota of application inoperability. This is not to mention the time, effort and money spent by us on the above investigation.
Climax (or not yet?)
Since August 21, we have repeatedly contacted MTS representatives at different levels with the requirement to unlock the Yota application. No measures were taken by them. Today, according to the results of tests and feedback from MTS clients who previously experienced problems with the application, we confirm that the application began 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 measures to unlock Yota. Despite resolving the issue, we will still file a complaint.