Question

Has ping / tracert been blocked on 5g network?

  • 18 October 2022
  • 79 replies
  • 3927 views

Badge

Before yesterday (10/17/2022), I’ve always had a command prompt window (MS Windows) up running a constant ping at 3 second interval - so I can tell when the network starts to degrade or just stops responding (which has become very frequent in the last few months).

As of yesterday morning, both ping and tracert commands consistently fail.  As in no longer any response.  So it appears the ports used for those commands are now being blocked on the 5g network?  

I have a 5g phone on Tmobile, and I see the same result.  On 5g with hotspot turned on, with computer connected, ping and tracert fail 100%.  If I force the phone to use LTE and stay off 5g, ping and tracert start working again.  Don’t really understand why Tmobile would block such a basic network analysis command.

This is in downtown Scottsdale AZ.  As a sidenote, service on the 5g network degrades consistently  every day after about 8am, and usually is consistently bad all weekend long.  Works great before 8am most days.


79 replies

I use pingplotter (pingplotter.com) and it has always been working for me.

Userlevel 7
Badge +8

The blocking/failure of using the ping utility seems to vary from one location to another. Here in east TN we had a period of time when it was failing to work but now it does. More than likely there is a configuration parameter in place to block ping packets. T-Mobile can run it down if they are motivated to do so. They may not be aware of the behavior in that location. Once they had enough complaints here they addressed the behavior and now it seems to be resolved. Well, it works here. You might try doing an IPv6 ping vs the IPv4 ping and see if there is a difference in behavior from one to the other. It might take a call to T-Mobile support to possibly get headway.

Oh, I also have the T-Mobile home internet router and ping is blocked for wired and wireless devices connected to the router. 

I have been battling with this for months in the Phoenix AZ area. My other phone is AT&T and they are also blocking ping/trace. 

This has been a problem for me off and on since its inception and through multiple TMHI gateways.  IPV4 ICMP pings just randomly fail sometimes for days.  Or latency just varies dramatically.  Rebooting the gateway works sometimes and other times not so much.  Not sure what is causing this exactly BUT IPV6 seems to work every time.  So it could be related to their CGNAT implementation or a combination of that and the gateway firmware.  I use a dual WAN OPNSense setup and need to monitor WAN quality to pick the best ISP.  Right now I have just disabled monitoring on that interface to get by but I may have to try to get IPV6 working on WAN interface to fix this permanently.  But that’s a big bunch of complexity that I really don’t want to undertake.  I don’t have any wired ISP’s in my area so I am stuck with TMO and ATT until Verizon offers their wireless internet in my area.   If anyone comes up with a solution please let us know here.  Thanks.   

Userlevel 7
Badge +8

I ran a test here in East TN which our traffic routes out of Nashville and I can see the latency is up going to multiple targets. I saw similar times but no loss to the same target quad9 and latency roughly the same. I hit google.com, and cloudflare.com as well and see the same general impact. I ran a speed test and I am still getting ~300 MBs down and 44 MBs uploads so not an impact to flow is seems. 

Testing with speed.cloudflare.com results in 200 MBs down but different test. Ping latency with the Cloud Flare test to Chicago from Nashville was not bad but different scenario so not apples for apples comparison. At least the ICMP traffic is not as extreme as last time. Downdetector.com reports no outages for T-Mobile so hard to say what is causing the delay. Blame it on cosmic radiation.

Same issue here in Savannah, GA area!! Ping time-out issues that started around May or so… Tech support was no help… 

 

 

Pings are working again in the Littlerock, AR area, but very slow all day

 

20:02:52.893 : Reply[3644] from google.com: bytes=32 time=504.5 ms TTL=114
20:02:54.442 : Reply[3645] from google.com: bytes=32 time=548.2 ms TTL=114
20:02:56.068 : Reply[3646] from google.com: bytes=32 time=623.7 ms TTL=114
20:02:58.070 : 142.250.72.46: request timed out
20:02:58.934 : Reply[3648] from google.com: bytes=32 time=864.4 ms TTL=114
20:03:00.427 : Reply[3649] from google.com: bytes=32 time=491.3 ms TTL=114
20:03:02.089 : Reply[3650] from google.com: bytes=32 time=660.5 ms TTL=114
20:03:03.645 : Reply[3651] from google.com: bytes=32 time=555.3 ms TTL=114
20:03:05.182 : Reply[3652] from google.com: bytes=32 time=536.5 ms TTL=114
20:03:06.765 : Reply[3653] from google.com: bytes=32 time=580.7 ms TTL=114
20:03:08.435 : Reply[3654] from google.com: bytes=32 time=669.0 ms TTL=114
20:03:10.257 : Reply[3655] from google.com: bytes=32 time=821.8 ms TTL=114
20:03:11.994 : Reply[3656] from google.com: bytes=32 time=735.7 ms TTL=114
20:03:13.547 : Reply[3657] from google.com: bytes=32 time=551.6 ms TTL=114
20:03:15.114 : Reply[3658] from google.com: bytes=32 time=564.9 ms TTL=114
20:03:16.925 : Reply[3659] from google.com: bytes=32 time=809.9 ms TTL=114

I am honestly surprised no tech blog or YouTube channel picked up T-Mobile blocking ping. You would think it would be newsworthy in the tech circle. 

Userlevel 7
Badge +16

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   I sometimes question some of the things they have decided to do but it is out of my control. I just focus on what I have control of. I had almost no options here and this provides a good balance between cost and functionality. I don’t have the needs I once had and my only other option with more functionality was Starlink and that is just more than I need to shell out. This solution is still 10X better than the DSL solution we had with our prior ISP in CA. That was a reboot the router at least once or twice a week. If it was wonky just reboot the router. Actually since the stood up the n41 cell over this location the bandwidth is more like 10-14X the speeds we had on DSL. Life in a rural area just has a few compromises for some things. In many other ways it is a big win. 

 

Comcast or other? where at in Ca?

If this was a conscious business decision by T-Mobile, shame on you. Have you updated your terms of service to list the blocking of common network monitoring and management protocols as a feature of your service? 
 

If it is an error - identify the root cause, fix it, and apologize.

Yours Truly,

A formerly happy, now very pissed off customer in North-Central Ohio…

 

Yeah that was my thought as well. This couldn't have been intentional, what ISP is going to block a foundational protocol. Ping is layer 3, it comes before transport, so TCP and UDP,  but getting their support to even understand the issue was impossible. I am guessing they eventually discovered the mistake on accident probably because a tech tried to use ping.

To others on this thread is ping working in your area?

Looks like T-Mobile is now allowing ping protocol in the Phoenix area again. 

Userlevel 7
Badge +8

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   I sometimes question some of the things they have decided to do but it is out of my control. I just focus on what I have control of. I had almost no options here and this provides a good balance between cost and functionality. I don’t have the needs I once had and my only other option with more functionality was Starlink and that is just more than I need to shell out. This solution is still 10X better than the DSL solution we had with our prior ISP in CA. That was a reboot the router at least once or twice a week. If it was wonky just reboot the router. Actually since the stood up the n41 cell over this location the bandwidth is more like 10-14X the speeds we had on DSL. Life in a rural area just has a few compromises for some things. In many other ways it is a big win. 

Userlevel 1

Aaand it's broken again.

 

This is making me think tmo doesn't really know how to isp. 

Having the same problem here. Started a few weeks ago. Makes my load balancing/failover setup useless. TMHI is supposed to be my backup internet. Useless at this point. Going to cancel if this isn’t fixed soon.

Yes, as of my post it seems T-Mobile is actively blocking Ping, Tracert, Traceroute and ICMP in addition if they do go through at all, they are deprioritized to the point that they are not effective to use in any capacity.

This sucks really bad... 

I use multiple uplinks and depending on the RTT, RTTSD, Loss it switches providers to balance connections across them… 

This behavior from the ISP breaks tons of functions as well as my link down failover automations. I hope T-Mobile realizes that ping and tracert/tracroute are 1000% necessary for proper network management and trouble shooting.

 

Verizon and AT&T don't have this problem of blocking pings, it is a T-Mobile specific issue and really makes the brand look cheap and the network mismanaged. 

You can have a secure network without blocking normal and essential network tools that have existed since before I was born.

^^^^ THIS RIGHT HERE!!! ^^^^
T-Mobile has a broken network or is actively breaking their network to the detriment of paying subscribers.

If this was a conscious business decision by T-Mobile, shame on you. Have you updated your terms of service to list the blocking of common network monitoring and management protocols as a feature of your service? 
 

If it is an error - identify the root cause, fix it, and apologize.

Yours Truly,

A formerly happy, now very pissed off customer in North-Central Ohio…

 

Userlevel 7
Badge +8

Here I can see via whatismyipaddress.com that it places me at coordinates in Nashville. I can still run pings and trace routing so it is working here still. Check and see where your IP actually presents in the map when using whatismyipaddress.com. Maybe where the external IP address is makes a difference. If you have not rebooted the gateway OR depending upon the gateway, it might have a pending firmware update and has not taken it so that might be part of the equation. It is hard to say. I am not saying the specific IP address as I have seen it change 4-5 times since I started watching it but the location where the map they have may have something to do with the routing operations or the CGNAT network environment. 

In West TN.  ICMP still not working.

Userlevel 1

Happy to report that ping loss is now down to 0% in OC NY. Haven't tested extensively yet; not sure if firmware was updated. 

 

Not sure what they did, but let's try to avoid it in future, hmm? 

Userlevel 7
Badge +8

Same over here in E TN. We had a week or so of the blocking/excessive throttling?

It appears to have been resolved a couple of days ago over here. I had to reboot my gateway to get it to work but that was a minor convenience. The loss was around 80-85% sometimes more. Frustrating.

Results just before the post:

--- google.com ping statistics ---

12 packets transmitted, 12 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 41.095/44.877/60.362/4.879 ms

So, hopefully the resolution for the problem will be deployed across all the affected regions.

Userlevel 7
Badge +8

Hopefully it is just a matter of time and not too much longer. 

Freshly rebooted Nokia here in Phoenix, AZ. ICMP still dropping. This is making it tough to work from home and will need to switch internet service soon if not resolved.

 

--- google.com ping statistics ---

369 packets transmitted, 19 packets received, 94.9% packet loss

round-trip min/avg/max/stddev = 53.732/146.891/223.265/45.335 ms

Userlevel 7
Badge +8

I had to reboot my gateway then it worked again. I tested before and after. It may take a bit before it is resolved all over. I hope they intend to fix it back all over. 

Userlevel 1

Heads up boys & girls!!

Its back or on the way.

Still no joy in OC NY. 

Userlevel 7
Badge +8

Heads up boys & girls!!

Its back or on the way. After the post from castrionfanatic I tested and my Nokia gateway was 27 days and some odd hours uptime and ICMP not passing. I decided to reboot the gateway and try again. Boom! It works. So, a reboot for you may also improve matters. I am in East Tennessee so locations may be different but it is much improved here. 

itinkeralot-MBP ~ % ping google.com

PING google.com (173.194.219.138): 56 data bytes

64 bytes from 173.194.219.138: icmp_seq=0 ttl=104 time=41.858 ms

64 bytes from 173.194.219.138: icmp_seq=1 ttl=104 time=47.267 ms

64 bytes from 173.194.219.138: icmp_seq=2 ttl=104 time=43.141 ms

64 bytes from 173.194.219.138: icmp_seq=3 ttl=104 time=53.151 ms

64 bytes from 173.194.219.138: icmp_seq=4 ttl=104 time=44.556 ms

64 bytes from 173.194.219.138: icmp_seq=5 ttl=104 time=49.542 ms

64 bytes from 173.194.219.138: icmp_seq=6 ttl=104 time=56.210 ms

64 bytes from 173.194.219.138: icmp_seq=7 ttl=104 time=41.839 ms

64 bytes from 173.194.219.138: icmp_seq=8 ttl=104 time=46.823 ms

64 bytes from 173.194.219.138: icmp_seq=9 ttl=104 time=45.199 ms

64 bytes from 173.194.219.138: icmp_seq=10 ttl=104 time=42.422 ms

64 bytes from 173.194.219.138: icmp_seq=11 ttl=104 time=46.108 ms

64 bytes from 173.194.219.138: icmp_seq=12 ttl=104 time=49.083 ms

64 bytes from 173.194.219.138: icmp_seq=13 ttl=104 time=41.708 ms

64 bytes from 173.194.219.138: icmp_seq=14 ttl=104 time=44.228 ms

64 bytes from 173.194.219.138: icmp_seq=15 ttl=104 time=45.096 ms

64 bytes from 173.194.219.138: icmp_seq=16 ttl=104 time=45.386 ms

64 bytes from 173.194.219.138: icmp_seq=17 ttl=104 time=46.104 ms

64 bytes from 173.194.219.138: icmp_seq=18 ttl=104 time=41.739 ms

64 bytes from 173.194.219.138: icmp_seq=19 ttl=104 time=42.638 ms

^C

--- google.com ping statistics ---

20 packets transmitted, 20 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 41.708/45.705/56.210/3.797 ms

Reply