I have tried using HTTP but the results are pretty much the same. I also don’t get ‘packet too big’ when connecting to this site, in fact I only see that on downloads…
I get pretty consistent results using mtupath but it does, as noted above, differ with tracepath under linux.
E:\Software\AppSW\Network\Network Diags>mtupath -6 help.comodo.com
MTU path scan to help.comodo.com (2a02:1788:4fd:cd::c742:cde6), ttl=64, limit=48
# 16 processing - best MSS 1332 (estimated MTU 1380) [uUUUUuUuUUuuUUuu]
# 08 nearest minimum MTU on 2001:470:1f14:1a37::1 (2 hops away)
#1 MSS IN RANGE 1 <== 1331 ==> 1332
#2 MSS EXCEEDED 1333 <== 15051 ==> 16384
E:\Software\AppSW\Network\Network Diags>mtupath -6 help.comodo.com
MTU path scan to help.comodo.com (2a02:1788:4fd:cd::c742:cde6), ttl=64, limit=48
# 16 processing - best MSS 1332 (estimated MTU 1380) [uUUUUuUuUUuuUUuu]
# 08 nearest minimum MTU on 2001:470:1f14:1a37::1 (2 hops away)
#1 MSS IN RANGE 1 <== 1331 ==> 1332
#2 MSS EXCEEDED 1333 <== 15051 ==> 16384
Which broker are you using?
Hurricane Electric
Does Downloads.comodo.com work ok for you via ipv6?
For example can you download the latest setup file for Comodo Internet security?
I am using native ipv6 by the way…
I forced my pc to use ipv4 for help.comodo.com and downloads.comodo.com by changing the hosts file configuration to resolve the problem temporarily, but i believe the problem is not on my side…
No it doesn’t, I can only retrieve ‘small’ data packets, it seems to revolve around MTU sizes.
How do you force this in Firefox specific to a domain, is that add-on feature?
There are two settings in about:config that play a part in how firefox deals with IPv6.:
network.dns.disableIPv6
network.dns.ipv4OnlyDomains
network.dns.disableIPv6 - If you change this to true it will disable IPv6 resolving, so all connections will be over Ipv4. However, if you leave it on false, you can use network.dns.ipv4OnlyDomains with a comma separated list of domains you resolved as IPv4.
thanks
I no longer have issues with either http://help.comodo.com or http://downloads.comodo.com.
My problem appeared to be a Cisco Bug in ipv6 inspect, If I run that on the tunnel interface it starts to drop packets because of some segment id issue.
If I removed the ipv6 inspect from the tunnel the problem is gone. My MTU on the tunnel is 1480.
salapis, can you please describe your exact network setup so we get a better understanding of your issue?
Is your MTU set statically? As I mentioned earlier, if I change my MTU to 1280, I can also use the comodo sites over IPv6. However, this doesn’t explain why this problem only occurs wit these sites.
On the tunnel interface, and on the Vlan1 interface so that router discovery packets contain it, from there the Win7 host takes that setting on the interface.
Which can by verified by the command ‘netsh interface ipv6 show subinterfaces’.
What’s the MSS on other servers you have no issues with? I notice that Comodo is sending 1440 and some others are using 1420.
I’ll need to take a proper look with wireshark tomorrow but a quick glance suggests I’m seeing the same values. What I don’t understand is why I don’t get a ‘packet too big’ from help.comodo but I do from downloads.comodo.
Interestingly, the destination of the packet is 2a02:1788:2fd::ab
Whereas, downloads.comodo is 2a02:1788:4fd::b2ff:5201
That was what is wondering me also, the packet-to-big should originate from the end node but it does not.
It also seems that IOS versions handled tunnel traffic differently the previous version I was running ended my traceroute requests with the routers IPv6 address.
After upgrading to a newer version it now traceroutes complete trough the tunnel towards the end-node…
Nothing complicated.
Just a Modem-router (Draytek Vigor 2710) with ipv6 enabled.(MTU set to 1442 on router’s configuration.)
My ISP provides dual stack connection, so I can browse using both ipv6 and ipv4 without tunneling.
Problem exists on all of my computers running Windows 7 or Windows 8 directly connectd to this router.
I may try a linux live cd later, but I don’t thing the problem is OS related.
Both belong to the same block/owner. I’ll see if I can get more info from Staff.
Can you run this in a command-box on the Win7 node and see which MTU the draytek advertises on the Ipv6 interface?
netsh interface ipv6 show subinterfaces
What’s the software version the Draytek is running?
Was the MTU provided/configured by the ISP?
Router advertises 1500 LAN MTU which is ok.
Latest available firmware 3.6.3.1
ISP suggests setting the MTU to 1492 for both IPv4 and Ipv6.(and PPP MRU 1492)
I tried these settings too, which are sligthly different from my router’s default configuration.Nothing changed regarding help.comodo.com and downloads.comodo.com problem.
*By the way my ISP says that in case of IPv6 tunneling MTU should be set to something lower like 1280.Otherwise ICMPv6 packets never arrive back.IT’s a PMTUD problem.
This may explain Radaghast problem but not mine.My ISP states that no tunneling is used.Anyway I tried setting my router’s MTU to 1280.
Problem is still there…
[attachment deleted by admin]
It seems only the isatap en Teredo interface pick up this setting.
Why are there bytes in/out on your Teredo interface? I wouldn’t expect this to be used in native IPv6.
It would be a good idea to disable the tunnelling interfaces to remove any potential conflicts. You can do this using:
netsh int teredo set state disabled
netsh int ipv6 isatap set state disabled
By the way my ISP says that in case of IPv6 tunneling MTU should be set to something lower like 1280.Otherwise ICMPv6 packets never arrive back.IT's a PMTUD problem. This may explain Radaghast problem but not mine.My ISP states that no tunneling is used.Anyway I tried setting my router's MTU to 1280. Problem is still there...
Your ISP has a point and PMTUD black hole detection is a problem. However, I have to wonder if Comodo are filtering ‘too big’ messages. As far as I’m aware, I only have this problem with Comodo and when I look at the wireshark captures, I’m sending a SYN with an MSS of 1420 but constantly getting back an ACK with an MSS of 1440, then nothing…
It seemed strange to me too.Another computer(PC2) reports it as “Local Area Connection *13”.
They only get 456 Bytes in and 660(or 624) Bytes out no matter if I am using my internet connection or not.
They are not actively used.
I disabled Teredo Tunneling Pseudo Interface in Device Manager (“Teredo Interface” on PC1 and “Local Area connection *13” on PC2 disappeared.I was also able to browser to ipv6 sites as usual.
Maybe these bytes are used for diagnostic purposes by the OS or sth.
They don’t.They are preconfigured by default to use 1280 MTU.
Wan MTU is set to 1492 as requested by my ISP.I cannot find a way to change LAN MTU using my router.
However I can change it using the command:
netsh interface ipv6 set subinterface "Ethernet" mtu=1492
By setting both WAN and LAN MTU to 1492 I am able to browse to help.comodo.com and download from downloads.comodo.com using ipv6!!
So it seems to me that LAN MTU should be less than or equal to WAN MTU, in order for help.comodo.com etc to work.
My questions are:
1.Why I don’t face the same problem with ipv4?
WAN MTU is 1492, LAN MTU for ipv4 remains 1500 but i can browse to help.comodo.com via ipv4 just perfect.
2.Why I don’t face the same problem with other Ipv6 enabled sites, like facebook.
They continue to work when WAN MTU is set to 1492 and LAN interface to 1500 (Which is Windows default setting).
Any ideas?