Has ping / tracert been blocked on 5g network?

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.

I am in east TN with the Nokia gateway and I ran a quick test with a Macbook Pro and a Linux client. With the Macbook Pro the pings have a significant delay where several request time out messages were reported prior to an actual response typically 140+ ms between responses. I went to a Linux client and did a forced ipv6 ping based upon a prior test. I get a similar response performing IPv6 and IPv4. Both have extreme delay times and are not very useful Of the forced 23 ipv6 ping packets 5 were received with a ~78% loss. So, yes it appears T-Mobile has jacked up the use of ICMP as a trouble shooting tool. 

Based upon the two tests I ran it appears pings with IPv4 fail much worse than IPv6 pings but the use of pings now is pretty much useless.

I fail to see why they feel this would be positive for users. Make it more difficult for users to identify potential issues so they are totally blind. It just makes calls to TMO support less productive when users with such basic knowledge cannot tell support what they do not see. 

I can understand that. Another user was using the T-Mobile solution as a back up and doing a similar tactic with his negate firewall. In order to insure the failover could take place he had to disable the ping processing. When the Starlink fell it still transitioned to the backup. I don't mean to lessen the importance of being able to have ICMP packets passed. I have seen the excessive loss and latency of the ICMP responses to 150 ms or more so I get it. 

I just don't think T-Mobile will be invested in resolving it right away. It is hard to tell how extensive the behavior is but it is generating some noise. Maybe with lots more noise they will pay attention.

ShanStewart wrote:

Ok, i spoke to T-Mobile tech and they said they no longer support ping so that is interesting. 

FFS.

Since we'e picking & choosing cucial communication potocols now, I've decided to no longe suppot the lette 'r'.

Hi, I too wish T-Mobile would fix this, and that the issue deserves to be newsworthy!

I have been having major issues related to my T-Mobile home internet, primarily devices like home assistants and their accessories that rely on lower latency to fulfil requests. My Nest Mini now takes on average 10 full seconds to begin loading the response. Beyond that, issues with security since my cameras have increased lag making my doorbell camera less useful, and problems with my DNS not able to properly filter the web. I'm not the only one and neither are any of you:

 

https://community.t-mobile.com/tv-home-internet-7/dns-provider-for-home-internet-38694

Clearly this is an aggressive rollout of provisioning. To report my locale, I'm in the PNW but most of you are in the South/Midwest states like Texas. Well, location doesn't seem to matter IMO as I still have noticed many issues recently, to the timeframe given in this forum, in where my web filter has not been able to deny requests properly on one of my home computers. I believe ICMP details noted are related.

Sadly enough, I am JUST learning how to network in college, in my second year and taking classes related specifically to latency and ping... So just wanted to note that I am genuinely affected by this… My own learning material has me doing these types of ICMP ping requests in Windows, and some posts here are lining up with my college material, but while learning from other members here has been fun, it also means to realize that my learning just got a lot harder BECAUSE of my fervent interest in bleeding-edge wireless tech… It doesn't have to be this way!

When testing using Fast.com and other methods, I'm anywhere between 50ms and 1.2seconds loaded for latency. While that hasn't been an issue, what's different is that now never reporting the lower number. One second of latency means I can pretty much throw away my Xcloud membership LMAO I have much better results playing using my phone's mobile hotspot.

Other tests, like Edge's in-browser utility, no longer can report latency at all and therefore the program hangs. Just as another user said, it makes it harder for a given person who doesn't know what's going on understand what's happening. This issue is compounded when the customers end up calling staff who have no source of truth for information on ping/latency leading to no progress for either party.

All in all, this is snowballing quickly and the best action really is to roll back these changes or communicate the incoming fixes. At minimum, progress in this would feel like acknowledging that the official stance isn't that "ping isn't used anymore" by T-Mobile and instead the stance customers want to see would be closer to working on a solution to the existing latency and ICMP problem for T-Mobile Home Internet users Nationwide.

Thanks to other forum members here, I understand now that if I want to continue to effectively filter my web I now need an addition device, a VPN (a hardware solution akin to a PfSense router) between my modem and personal router… and I would rather configure my own hardware like the ASUS modem I had before, but T-Mobile Home Internet does not support other hardware even if I did try and use a hotspot or 3rd-Party 5G Modem. I really don't want a bunch of networking equipment at home, I'd wanna leave that for school lol... so it's horrible to see this provisioning and clearly it's basically "love it or leave it" unless we outcry. So I'd like to join you all in a big +1 @inductivesoul  @iTinkeralot @ShanStewart @Walkabt  and ask T-Mobile to sympathize with customers, geeks and nerdy students alike and cool it with the way their locking down these gateways.

Ping and Trace Route both leverage ICMP to function so it just makes sense that both fail. I would guess with a VPN open both would work fine. It is hard to say what T-Mobile will do next with their solution. I have been getting more apprehensive since the gateway has now transitioned from the n71 to the n41 frequency. I have seen so many reports of users on the n41 where the throttling T-Mobile does pretty much cripples the cell beyond use. The prioritization for mobile handsets over the home gateways and the extra client loading in the urban locations just seems to be a bad mess. On the bright side my speeds have doubled or better on downloads much of the time. 

Choking the ICMP traffic as they have makes no sense to me. Bad move. I used ports 8080 and 443 pinging and it still behaves the same. It looks like they just throttled ICMP to death. For users that do much more than check email, browser the web, or stream a few select services they will eventually jump ship and get another solution that is more reliable and capable.

BugPlusWont wrote:

Hi, I too wish T-Mobile would fix this, and that the issue deserves to be newsworthy!
 

https://community.t-mobile.com/tv-home-internet-7/dns-provider-for-home-internet-38694

Please call T-MOBILE and have them escalate this issue. 

Same here in Littlerock AR.  I am a Citrix Admin (Working remote 100% of the time); I always have the end user ping our NetScaler gateway to see that the response time is when they say their remote session is sluggish.

Now even I cannot get a reliable ping response, but I am still able to work remotely.

Seems like ICMP has been throttled.

Not good.

Might have to go back to SuddenLink.

Cannot use this connection if I cannot even ping a remote site.

On the bright side, a new ISP is coming to my area with fiber, still under construction but fingers crossed they are better than SuddenLink and Century Link

Ejemplo:

Pinging google.com [142.250.72.46] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 142.250.72.46: bytes=32 time=117ms TTL=110
Request timed out.
Request timed out.
Request timed out.

With all the Request time outs, my Internet is fine.

If I RDP into a computer at work and ping a remote site, I get great ping responses.

I noticed about 4 days ago that most pings now fail.  If I do a continuous ping(-t) roughly 1 in 20 gets a response, and all are over 100 ms.  Using pinginfoview, I can set the port it uses, and they work.

TMobile needs to fix this.  Lots of people use ping to check connectivity, and it's just going to make them look bad.

Testing with a Garuda Linux client with a verbose ping to 8.8.8.8 currently it runs with roughly 100 ms latency but out of 43 packets sent 13 received responses so roughly 70% packet loss. Running a speedtest I am still obtaining 275-300 down and meh… 21 mbps upload so the bandwidth is there but the ICMP traffic is impaired or throttled. I sort of suspect it has something to do with throttling for one reason or another. I suppose it may be related to changes with the CGNAT solution but probably a throttling of the traffic. Testing with a MacBook Pro via a thunderbolt to ethernet adapter the response times are worse than with either of the Linux clients I have used but still bad either way. 

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

1  www.webgui.nokiawifi.com (192.168.12.1)  2.145 ms  0.376 ms  0.279 ms

2  192.0.0.1 (192.0.0.1)  0.533 ms  0.698 ms  0.449 ms

3  * 192.0.0.1 (192.0.0.1)  27.721 ms  29.890 ms

4  * * 192.0.0.1 (192.0.0.1)  35.968 ms

5  192.0.0.1 (192.0.0.1)  30.243 ms *  46.172 ms

6  * * *

7  * * *

8  * * *

9  * * *

10  10.164.162.176 (10.164.162.176)  509.603 ms * *

11  * * *

12  * * *

13  * * *

14  * * *

15  * * *

16  *^C

Pretty clear it is useless without using a VPN.