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.

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-38694Clearly 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.

Has ping / tracert been blocked on 5g network?

iTinkeralot
Bandwidth Buff
Hace 3 años
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.
phinster
Newbie Caller
Hace 3 años
My primary beef (the only one actually) is the loss of ping packets.
We will be using these devices as failover internet connections.
What I’ve observed is up to 90% packet loss with ICMP.
At that rate, it will continue to see that as a loss of internet connectivity when it is actually fine.
iTinkeralot
Bandwidth Buff
Hace 3 años
It is doubtful you will find someone invested in that. Really serious users will use a VPN solution and avoid the port forwarding issues. Being able to use trace routing or the ping utility to troubleshoot is helpful but I guess T-Mobile is not after the serious technical users. It will just result in more calls to customer support which probably will provide little traction on the problems most of the time. If it garners a lot of negative press that might have an influence but the bulk of the users probably don't have a clue what ping or trace route is. As long as the solution is up and running properly it is not often I go there.
phinster
Newbie Caller
Hace 3 años
Other than phone call, which does not get anyone high enough up the technical food chain, is there another way to contact t-mobile to complain about blocking of ICMP?
iTinkeralot
Bandwidth Buff
Hace 3 años
That is assuming trace route is working in your location. Recently ping and trace route have been problematic for users in a number of locations over the T-Mobile CGNAT solution.
iTinkeralot
Bandwidth Buff
Hace 3 años
You should be able to trace route to it but not be able to ping it.
bb83
Network Novice
Hace 3 años
ICMP is not working in Appleton, WI either.

ping 1.1.1.1 -n 10
Pinging 1.1.1.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 1.1.1.1:
Packets: Sent = 10, Received = 0, Lost = 10 (100% loss),

This might be a deal breaker. Hopefully, T-Mobile gets this working again.
jlb123
Network Novice
Hace 3 años
ICMP is all but obliterated in Queen Creek AZ. Trace route and ping can't be used starting 10/17/22.
iTinkeralot
Bandwidth Buff
Hace 3 años
--- 142.250.72.238 ping statistics ---
55 packets transmitted, 4 packets received, 92.7% packet loss
round-trip min/avg/max/stddev = 129.473/154.139/168.004/14.654 ms
Pinging from terminal on MacBook Pro through the Nokia gateway via n41 frequency
B66 on primary and n41 on secondary
Traffic is heavier tonight so speeds are down a bit but not bad.
Not sure what is going on with the ICMP as it is pretty useless here.
iTinkeralot
Bandwidth Buff
Hace 3 años
So maybe in some locations it works but in others zip. You are among the fortunate. Nice download speed. You must be close in on an n41 frequency. I am on n41 but best I have seen is ~400 down.
ping google.com
PING google.com (108.177.122.138): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
64 bytes from 108.177.122.138: icmp_seq=5 ttl=102 time=146.403 ms
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
64 bytes from 108.177.122.138: icmp_seq=10 ttl=102 time=76.933 ms
64 bytes from 108.177.122.138: icmp_seq=11 ttl=102 time=114.437 ms
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
64 bytes from 108.177.122.138: icmp_seq=15 ttl=102 time=129.560 ms
Request timeout for icmp_seq 16
64 bytes from 108.177.122.138: icmp_seq=17 ttl=102 time=104.947 ms
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22…
--- google.com ping statistics ---
49 packets transmitted, 10 packets received, 79.6% packet loss
round-trip min/avg/max/stddev = 76.933/110.130/146.403/22.334 ms