trying to assess comcast email and I get a connection has timed out. I a can log on to my comcast account successfully. Clicking on the email Icon (https://connect.xfinity.com) it times out.
I remove my antivirus and disabled the firewall. Not using a VPN.
this all started on 1/27/2021. support could not find any issues.
anyone else having this issue.
I started haviong the same issue about 10 days ago. I can get emails fine on my Android phone but not through my email. I can login to my account with no problem but as soon as I click on the email Icon on xfinity site, it will time out that took too long to connect. Please help.
I had the same problem and tracked it down to MTU. Somthing changed arounf 1/27. Perhaps xfinity added "do not fragment" to the email servers SSL handshake.
I have windows 10.
I verified that the connection was failing using openssl and wireshark. I can send the wireshark file if anyone wants to analyze it.
I checked and changed MTU through the windows 10 power shell. To check MTU and determine the LAN name (IN POWERSHELL):
netsh int ipv4 show subinterface
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
4294967295 1 0 1694890 Loopback Pseudo-Interface 1
1504 1 1089714654 35479773 Local Area Connection
1504 5 0 0 Local Area Connection 2
1500 5 0 0 Local Area Connection 6
This showed MTU was set to 1504 on my active LAN connection which was "Local Area Connection".
I then executed the following command (in power shell)
netsh int ipv4 set subinterface "Local Area Connection" mtu=1500 store=persistent
BTW this was the result of DAYS of research and testing, and of course xfinity support was less than useless.
I would like to know what xfinity changed at that time. Did DF (don't fragment) get set? Did something get larger causing a framentation issue?
I wish I could edit my post. Please realize this is just what I did on my up uo date Windows 10 machine. It happened to work for me. Who knows what might happen on your machine.
One thing that might not be clear is that "Local Area Connection" in the command
netsh int ipv4 set subinterface "Local Area Connection" mtu=1500 store=persistent
was determined by looking at the results of the previous command and deciding that my active network was named "Local Area Connection". Your network may be different, so use the appropriate name for your system.
Also, there may be programs out there that do this through a GUI, but I have not (and won't) researched that.
Also, you may just decide to try to get xfinity to look into this and revert whatever they changed to cause this problem.
I have no idea how my MTU got to 1504, or whether that is a real issue. I've been running on the same machine since 2011 and don't remember half the crud I've done. It probably got set by some bandwidth optimization site like dslreports.com. Who knows.
I was having the exact same problem and was on a different post thread before Anon1532942 linked me to this thread. I've never used Powershell before but the steps suggested seemed worth a try. I got the same results -- the MTU (whatever that is) was 1504 on my Local Area Connection (just happed to be the same name as in the steps above). I executed the next command and crossed my fingers that I wouldn't kill my computer! It came back with "OK" so I closed Powershell and tried to comment to my Xfinity email. MAGIC! Connects just like it used to!
As an aside, I have a laptop running Windows 10 but it is connected via wifi and it did not have the Xfinity email connectivity problem. Just my desktop which is connected to the modem via ethernet was timing out. Weird.
Regarding the laptop working, but the desktop not working. My laptop (and my phone) also worked. But, the MTU was already set to 1500 on the laptop.
Two questions come to mind:
1. How did my desktop get MTU set to 1504 (doubt I will ever find out)?
2. What did xfinity change to cause MTU == 1504 to be a problem and will they change it back?
YES, YES ... YEEESSS!
Comcast/Xfinity has blown up my POP3 connectivity every six months or so over the course of many years. Calls to tech support are hopeless. Always the same line about assuring port numbers & etc are correct, but no real help. It's always something that changes on their end. Usually, the problem 'heals' itself Most often, the problem shows up as some sort of SSL/TLS error, often with error code 0x800CCC1A (encryption type issue), killing both send and receive. This started for me sometime on 25 January 21.
More recently, they managed to get the outbound (SMTP) fixed, but it was coming up with 0x8004210A (timed out waiting for POP3 server) where the receive was now an issue, and would just time out. What is bizarre is that the credential and SSL/TLS process is supposed to be identical for send/receive connections.
I'm hoping by posting both of those error codes above that searches for soluitions related to them point to your answer, as it resolved problems for both of those codes.
With their POP3 service failing (do NOT mention the acronym IMAP, please!), I was forced to their WebMail, which in turn, ALSO began to fail after a couple of days with timeouts at the same time as the send side of my POP3 started working again. Even their own mail web page (the page where the user views and sends mail) acknowledged the problem, popping up a "Server unreachable" message in a little box at the bottom of the WebMail interface.
My MTU was set to something on the order of 4700. I backed it down to the 'standard' 1500 that you used to resolve your problem, and amazingly enough, both WebMail and my POP3 Outlook mail are working again (not timing out).
Anyway, thanks VERY much for the work required to set us straight. What tipped you to idea of making the minor change in the max packet size? Yes, the Wireshark log would be fascinating to review if it doesn't disclose too much.
I messaged/sent you a link for the wireshark file.
Once I figured out it was failing SSL handshake, I searched for "SSL fails handshake at client hello".
I researched all over and came across a post about MTU and SSL. When I saw the wireshark seemed to have an incomplete transaction, I decided to go for it. That was after learning how to commect to pop3 with SSL. (openssl s_client -connect pop.gmail.com:995 -state -msg -debug <------working example) and how to use wireshark. I could connect via telnet (telnet pop3.comcast.net 110) I could connect to gmail, but not xfinity. I thought it might be certificate related, but that didn't make sense since xfinity seemmed to work otherwise. Also this site, that tests pop3, worked to comcast: https://www.wormly.com/test-pop3-mail-server/host/pop3.comcast.net/ssl/1/port/995/id/dTkCjuOR
Anyway, glad it worked. I hope Xfinity can tell us what changes to cause this to occur out of the blue.
I need to figure out how to pick up your PM. [Edit: Success on that]. Have never used Xfinity forum before. Will see if I can pick apart the Wireshark packets. As I'm sure you've seen, it's a fantastic tool, but the process itself can be quite tedious.
I doubt that we'll ever be able to make contact with anyone at Xfinity at a technical level capable of understanding the nature of the solution, much less back it up to isolating what was changed on the server that caused it. That's the sad part. I have two open tickets for which I've received no communication at all, one of them open since 1/27 when I realized that this wasn't going to 'heal' itself this time.
Anyway, I again want to express my appreciation for your tenacity. Intentionally tweaking MTU values in an attempt to improve throughput by avoiding fragmentation isn't all that uncommon among 'powerusers', and this is the first time I've ever heard of that technique breaking something, much less breaking it this profoundly. That yours had changed such a minor amount, and for unknown reasons, says that this problem may impact more Comcast/Xfinity users than the 'poweruser' group, and that Comcast/Xfinity really needs to understand what they did.
Just a warning to the 'poweruser' group. Your router may ALSO have the ability to have its MTU adjusted to match any experimentally deteremined number you may have previously computed for the PC. If the PC side is broken, be sure you hadn't also adjusted your router. Beware!
I guess the answer is obvious. Xfinity does not have technically proficient support personel.
I detected a problem, and posted a solution, and asked for help root causing the issue so it wouldn't happen again.
No one from xfinity felt it was worth responding to me.
I have been paying for internet service since 2000, but that means nothing to them. (home.com then attbi.com then comcast).
The problem and solution is here:
What does it take to get intelligent support? In the past it was lies and misinformation (regarding the neflix bandwith restrictions). Now it is just being ignored.
I pray for the day when I will have a choice!!
This is a public Community Forum, primarily customers helping customers. This is NOT a technical support Forum. Agents monitor posts, but are generally first level support.
What's annoying is that it's easy enough to find the IP address of the Xfinity mail server, but they've configured it to ignore pings. If one could ping that server, it would be possible to sort out whether a basic connectivity problem is the issue (if you can't even reach the server due to some upstream router problem, there's no point in doing anything else on the computer end), or whether there is a configuration issue on the computer that needs to be addressed (e.g., port numbers or whatever). That would have been (and no doubt will be again in the future) a super helpful tool in sorting out these issues. Basic rule of troubleshooting -- divide and conquer. Is the problem 'over here' or 'over there' made impossible due to lack of a simple ping response.
Further, if one could ping their server, it is possible to adjust the MTU of the ping with the -l nnnn switch added, making it possible to experiment quickly with different values to see what works and what does not.
Anon1532942, thank you so very much for posting the solution to reset the local area connection MTU value. I used Windows Powershell to view and then change the MTU value to 1500 from 1504, and amazingly, this solved my on-going problem! I am very grateful.
THE PROBLEM: On 1/25/2021, I stopped receiving emails on a Desktop PC with the Windows Professional 7 OS where I use Outlook 2016 for email management for two comcast.net email accounts. The last emails received were 5:07 PM CST and 5:57 PM CST on 1/25/21.
In addition, I could not access either email or voice online using Web browers on the Desktop PC. Using a Web browser (Chrome, Firefox, or Edge), I was able to log into the xFinity website and view my account billing and payments, but I could not access email or voice for either account. Web browsers gave a timeout error like this:
This site can’t be reached
connect.xfinity.com took too long to respond.
- Windows 10 laptop: I could receive and send email messages on my Windows 10 laptop using the mail utility. However, this was not a full solution for me, because I have not been using the Win 10 laptop to manage email.
- Cellphone: I could receive and send email messages on my Android Cellphone using xFinity Connect. However, this solution has limited capability; it is primarily a method to view messages.
- Desktop PC Mail Accounts Settings: I tried various Email Settings per xFinity's 'How To' documentation. All combinations failed.
- Desktop PC Partial Fix on 2/3/21: I was able to fix the send email problem after I disabled Windows Firewall.
- Rebooting the cable modem did not fix.
- Two Phone calls to xFinity customer service did not provide solutions: 1/27/21 and 2/4/21. During the 1/27 call, the rep reviewed the mail settings, did a test send, and suggested that I needed to update the operating system. During the 2/4/21 call, a ticket was opened, but I did not receive a call back on the ticket.
- Desktop PC: I updated Trend Micro Internet Security application on 2/10/21. I determined that this program was not the cause of the problem by turning it off and testing.
- Conducted numerous web searches on a variety of error messages. As examples, I searched for TLS timeout error, Outlook Error message 0x800CCC0E, and connect.xfinity.com.
- On 2/10/21, a search using the Edge Browser for "web browser timeout error" brought me to the xFinity forum where I found Anon1532942's posted solution.
THE SOLUTION: I used Windows Powershell (run as administrator) to view and then change the MTU value to 1500 from 1504 per the post by Anon1532942.
COMCAST XFINITY Please Note: My household is a long-term, 20-year-plus customer. This has not been a positive experience. My home office productivity was significantly and negatively impacted for two and a half weeks, because I could not utilize my usual workhorse PC with the Outlook email application for email management and subsequently home administration. Your only solution offered -- using the xFinity Connect email app on a cellphone -- did not replace the needed functionality.
I cannot thank you enough for the time and effort that you invested to resolve this issue. It has driven me crazy for days, and yes, Comcast was of zero assistance.
I was near ready to strip down my computer and do a complete reinstall when I was fortunate to have found your post.
Your solution worked like a charm.
Thank you again, and again!
We made some changes this morning that should resolve this issue. This one was a bit tricky to track down as an ethernet MTU setting above 1500 is a bit of an outlier. This is also why many would see the problem on some computers and not on others. The default for most Windows and Mac computers is 1500. This is why the problem wasn't happening to most email users and only on specific machines.
Although we have put in a fix on our side to handle the MTU setting, unless you have a specific reason, for the best experience across the internet I would recommend keeping the default of 1500. As we were testing this with a higher MTU we ran into some slowness and timeouts on various sites across the internet.
How can we tie your action to some process on your end to close open customer support tickets properly? Any 'bug number' or etc on your side to report to accomplish this?
Also, what changed on your end that caused the MTU length sensitivity in the first place? Many of us were operating just fine for years with higher MTUs until about 25 January 2021. Are you able to elaborate?