I've made an initial attempt to alert Comcast to trouble. As my experience with their telephone help is that it is strongly oriented to first-level problems (customer to cable modem, to street line) I looked for another interface. I could find no email method, so tried to initiate a chat , and wrote a link to Christian Beer's post 149695 into my opening problem statement. After staring at a screen proclaiming "connecting to chat--your chat will being shortly" for twenty minutes, I decided that either I had a problem involving that chat interface, or perhaps they were overloaded with complaints stemming from the same or another problem.
I guess my main hope is that many other Comcast customers are affected, in which case their complaints or ordinary monitoring should lead Comcast to fix it. But I don't have much of a clue of the scope of the problem.
That makes no sense. If the tracert is showing a connection then the ping should show a connection too.
The problem getting a ping response from my host pinging the Hannover addresses is packet-length specific. AgentB found this during our collective investigation into the November 20, 2015 problem we eventually defined as a bad Kaspersky response to an Einstein configuration change. I had completely forgotten it.
Today, just now, pinging to einstein1.aei.uni-hannover.de with the -l switch parameter setting the "send buffer size" to values ranging from 31 to 42, all values report 100% success in tightly clustered times around 155 msecs except for size 32, which, according to AgentB back then, is the value Windows supplies when this switch is not employed.
I don't see an option to configure Tracert, but for WinMRT this is also configurable, and the default is 64. I'll speculate that 64 is also the tracert default, so the behavior of Hannover configuration in swallowing length 32 packets emitted by default ping is likely the source of our discrepancy between ping and tracert behavior. Quite possibly that has nothing whatever to do with my actual difficulty.
As it did roughly 13 hours ago, suddenly my download problem got completely better, with all four hosts clearing their entire (large) download backlog promptly on hitting the retry button.
I started up a new WinMRT session to see if anything looked different, and it did. In a five minute session (so 300 trials), there was only one single packet loss at any layer save the four layers which never return anything. Also the sequence of locations differed. Next up from the Albuquerque area stuff before were:
be-33654-cr01.1601milehigh.co.ibone.comcast.net
be-11719-cr02.denver.co.ibone.comcast.net
Whereas now those two slots are shown as:
be-33654-cr02.losangeles.ca.ibone.comcast.net
ae10.edge3.LosAngeles1.level3.net
I'd say this all fits Christian Beer's diagnosis of router trouble in the Comcast network. It also suggests the trouble is probably beyond my personal range of likely influence.
I ran some more tests from
)
I ran some more tests from different networks. It seems there is a problem within the comcast network.
Here is a mtr trace from AEI to your local comcast node:
7. cr-han2-te0-0-0-7-8.x-win.dfn.de 0.0% 81
8. cr-fra2-be12-7.x-win.dfn.de 0.0% 81
9. ae53.edge5.Frankfurt1.Level3.net 0.0% 81
10. ae-2-3601.ear1.Washington12.Level3.net 95.0% 81
11. be-200-cr02.ashburn.va.ibone.comcast.net 0.0% 81
12. be-10114-cr02.56marietta.ga.ibone.comcast.net 0.0% 81
13. be-11424-cr02.dallas.tx.ibone.comcast.net 0.0% 81
14. be-11724-cr02.denver.co.ibone.comcast.net 0.0% 81
15. be-11719-cr01.1601milehigh.co.ibone.comcast.net 49.4% 81
16. be-7922-ar01.albuquerque.nm.albuq.comcast.net 0.0% 81
17. be-1-sur01.sandia.nm.albuq.comcast.net 0.0% 81
18. te-0-0-0-ten04.sandia.nm.albuq.comcast.net 0.0% 81
te-0-0-1-ten04.sandia.nm.albuq.comcast.net
te-0-3-0-12-sur02.sandia.nm.albuq.comcast.net
19. te-0-3-0-12-sur02.sandia.nm.albuq.comcast.net 0.0% 81
Here is a mtr trace from a German server provider:
2. core13.hetzner.de 0.0% 613. juniper5.rz2.hetzner.de 0.0% 61
4. 2001:978:2:a::1 53.3% 60
5. te0-2-1-1.rcr21.nue01.atlas.cogentco.com 33.3% 60
6. be2270.ccr22.muc03.atlas.cogentco.com 25.0% 60
7. be2960.ccr42.fra03.atlas.cogentco.com 72.9% 60
8. be2814.ccr42.ams03.atlas.cogentco.com 61.0% 60
9. be12488.ccr42.lon13.atlas.cogentco.com 73.3% 60
10. be2983.ccr22.bos01.atlas.cogentco.com 35.0% 60
11. be-200-pe02.onesummer.ma.ibone.comcast.net 33.3% 60
12. be-10373-cr02.newyork.ny.ibone.comcast.net 26.7% 60
13. be-10305-cr02.350ecermak.il.ibone.comcast.net 25.0% 60
14. be-10517-cr02.denver.co.ibone.comcast.net 35.0% 60
15. be-11719-cr01.1601milehigh.co.ibone.comcast.net 0.0% 60
16. be-7922-ar01.albuquerque.nm.albuq.comcast.net 20.0% 60
17. be-1-sur01.sandia.nm.albuq.comcast.net 16.7% 60
18. te-0-0-0-ten04.sandia.nm.albuq.comcast.net 0.0% 60
19. te-0-3-0-12-sur02.sandia.nm.albuq.comcast.net 0.0% 60
Using a different host with the same provider I get a good connection through a different intermediate network:
2. core22.hetzner.de 0.0% 59
3. core12.hetzner.de 0.0% 59
4. juniper4.rz2.hetzner.de 0.0% 59
5. ae5-710.nbg40.core-backbone.com 0.0% 59
6. ae14-2002.fra10.core-backbone.com 0.0% 59
7. ffm-b4-link.telia.net 0.0% 59
8. ffm-bb4-link.telia.net 0.0% 59
9. ash-bb3-link.telia.net 0.0% 59
10. ash-b1-link.telia.net 0.0% 59
11. comcast-ic-318834-ash-b1.c.telia.net 0.0% 59
12. be-10142-cr02.ashburn.va.ibone.comcast.net 0.0% 59
13. be-10114-cr02.56marietta.ga.ibone.comcast.net 0.0% 59
14. be-11424-cr02.dallas.tx.ibone.comcast.net 0.0% 59
15. be-11724-cr02.denver.co.ibone.comcast.net 0.0% 59
16. be-11719-cr01.1601milehigh.co.ibone.comcast.net 0.0% 59
17. be-7922-ar01.albuquerque.nm.albuq.comcast.net 0.0% 59
18. be-1-sur01.sandia.nm.albuq.comcast.net 0.0% 59
19. te-0-3-0-12-sur02.sandia.nm.albuq.comcast.net 0.0% 58
So to me it looks like a routing issue with your ISP. Feel free to point them to this thread as they might need the traces.
Thanks, I've made an initial
)
Thanks,
I've made an initial attempt to alert Comcast to trouble. As my experience with their telephone help is that it is strongly oriented to first-level problems (customer to cable modem, to street line) I looked for another interface. I could find no email method, so tried to initiate a chat , and wrote a link to Christian Beer's post 149695 into my opening problem statement. After staring at a screen proclaiming "connecting to chat--your chat will being shortly" for twenty minutes, I decided that either I had a problem involving that chat interface, or perhaps they were overloaded with complaints stemming from the same or another problem.
I guess my main hope is that many other Comcast customers are affected, in which case their complaints or ordinary monitoring should lead Comcast to fix it. But I don't have much of a clue of the scope of the problem.
Christian Beer wrote:That
)
The problem getting a ping response from my host pinging the Hannover addresses is packet-length specific. AgentB found this during our collective investigation into the November 20, 2015 problem we eventually defined as a bad Kaspersky response to an Einstein configuration change. I had completely forgotten it.
Today, just now, pinging to einstein1.aei.uni-hannover.de with the -l switch parameter setting the "send buffer size" to values ranging from 31 to 42, all values report 100% success in tightly clustered times around 155 msecs except for size 32, which, according to AgentB back then, is the value Windows supplies when this switch is not employed.
I don't see an option to configure Tracert, but for WinMRT this is also configurable, and the default is 64. I'll speculate that 64 is also the tracert default, so the behavior of Hannover configuration in swallowing length 32 packets emitted by default ping is likely the source of our discrepancy between ping and tracert behavior. Quite possibly that has nothing whatever to do with my actual difficulty.
As it did roughly 13 hours
)
As it did roughly 13 hours ago, suddenly my download problem got completely better, with all four hosts clearing their entire (large) download backlog promptly on hitting the retry button.
I started up a new WinMRT session to see if anything looked different, and it did. In a five minute session (so 300 trials), there was only one single packet loss at any layer save the four layers which never return anything. Also the sequence of locations differed. Next up from the Albuquerque area stuff before were:
Whereas now those two slots are shown as:
I'd say this all fits Christian Beer's diagnosis of router trouble in the Comcast network. It also suggests the trouble is probably beyond my personal range of likely influence.