With ipv6 enabled downloads.comodo.com resolves to 2a02:1788:4fd::b2ff:5201
which does not respond to the download request.
If you disable ipv6 (forcing your computer to use ipv4 only) downloads.comodo.com resolves to 178.255.82.1
which is working OK.
Windows prefer ipv6 by default and many ISP’s start supporting IPv6 .As a result, many clients are/will be unable to download or update Comodo products.
However, I cannot download anything hosted there.
The browsers (tried both Chrome and IE) are always “waiting for downloads.comodo.com” and the download never starts.
I have problems with IPv6 and the comodo sites - the only sites I have problems with - so much so that I force IPv4, for comodo.com, in firefox. However, I have found that adjusting your IPv6 MTU can help. You can use somethig like mtupath to ascertain the correct size.
I can only provide Microsoft Network Monitor capture.
You can find it here. (I’ll delete the link in 2-3 days for obvious reasons)
I used Comodo update, instead of using a browser to download from downloads.comodo.com
The problem is similar. (Comodo finds that there is an update but it downloads 0 bytes)
In short I am getting a “Moved temporarily” response from downloads.comodo.com (using ipv6)
Anyway, forcing Comodo to use http://178.255.82.1 for updates would solve the update problem for me I suppose.
*Oh by the way, if you choose to enable “Filter ipv6” on Comodo firewall you get fake tracert results for every ipv6 address.I suppose this is a known bug.
This is also seen using IPv4 but the correct URI is offered in the 302 message.
Anyway, forcing Comodo to use http://178.255.82.1 for updates would solve the update problem for me I suppose.
*Oh by the way, if you choose to enable “Filter ipv6” on Comodo firewall you get fake tracert results for every ipv6 address.I suppose this is a known bug.
Would yo mind expanding on that please, I’m not seeing any issues with tracert -6
Well I found out that the tracert problems appear only when Comodo Firewall is disabled and “Filter ipv6 traffic option” in comodo firewall is enabled.
Case 1. Comodo Firewall Enabled, Filter ipv6 disabled
Case 2. Comodo firewall Enabled, Filter ipv6 enabled.
Case 3. Comodo Firewall Disabled, Filter ipv6 enabled.
This is not related to downloads.comodo.com.It happens on every ipv6 tracert.
Ipv6 sites work ok in all cases.It’s just a minor tracert bug or sth.
Unfortunately, I’m not seeing any differences with or without the firewall/IPv6 filtering. Strictly speaking, if the firewall is disabled, the filtering option shouldn’t make any difference. What happens if you disable the Comodo firewall driver in device manager?
IPv6 PMTU is now the responsibility of the source/destination hosts, this trace is missing ICMPv6 traffic so I can’t see if there where Packet To Big packets send by routers in between.
It seems like there is to much packet loss on the communication, to many retransmits/segments lost on critical packets.
Can you please run a full capture with no filters (please close as many applications that can cause ‘noise’ on the capture)?
Did you verify your Routers firewall settings regarding IPv6, does it filter to much, e.g. ICMP error traffic etc?
Thanks for your answer. Here is a full capture
I took the capture with Router’s firewall and Comodo firewall disabled.
I tried using another Pc. Same problem.Cannot download from downloads.comodo.com.I also discovered that I cannot browse to help.comodo.com, which is ipv6 enabled, too.
I can browse to any other ipv6 enabled site.I tried many of them from http://look4ipv6.appspot.com/tools/random
and they worked.
Well 1442 is the max from my side.(Actually it’s my router’s default configuration.)
Most sites report 1442 as a result. http://www.ipv6tf.org/ has MAX MTU of 1280(I suppose that’s their MTU configuration or a configuration of a hop between me and the site) and work ok.
I have the same issue with http://help.comodo.com. (IPv6 tunnel via tunnelbroker).
It pings fine, but it won’t load in the browser, I see the 3-way handshake perfectly fine, but after the GET / request I receive an ACK to the request and then it goes dark.
Did you try http also Radaghast, and have you noticed the ‘packet-to-big’ messages in your capture?
Unless that’s your tunnel endpoint probably that would behave in this way?