local forums are as dead as ever over here so pretty much i'm on my own.
pinging my home router from my offshore VPS worked fine, that website was just faulty...
1 Like
It is not about ping. It's the other types which are important. Tonight i can ckeck 2 which ones i have enabled
1 Like
I have these in the forward traffic rule(any zone to any zone) icmpv6 sub types (see under advanced tab if you edit the rule with luci) :
Bad header
Destination unreachable
Echo reply
Echo request
Fragmentation needed
Packet too big
Time exceeded
Ttl zero during reassembly
Ttl zero during transit
I think especially packet too big and Fragmentation needed are important with a smaller mtu
One other thing, is the clock set correctly, including timezone?
1 Like
Fragmentation needed, TTL zero during reassembly and transit were missing from mine, I added them in but doesn't seem to alleviate the issue.
Also yes my timezone is correctly set.
EDIT: Could you post your result here when testing using this website?
1 Like
The proper MTU size is independent of your desire.
It is what is.
You can leave it fragmented but why you would want to avoid the correct MTU escapes me.
I just wanted to know if this is something which would be resolved from my ISPs side rather than resorting to applying fixes from client side. Also could you share your results from the test-ipv6.rr website? I seem to get interesting results which sort of reflects my problem...
Honest;y, you kinda went off topic with MTU and, technically, I should have said nothing.
I do not think MTU is going to do anything with the topic of the thread.
I do not use IPv6. I find it too complicated and unneccessary where I live (US).
But not getting MTU dialed in is, can be, should be done. It is just basic tuning.
I guess people here assumed that I've been banned from a forum. I'm sure I haven't interacted with that forum at all nor even knew about it before until I started searching for problems with ipv6 and mtu.
this forum pointed out it was an issue from the isp's end: https://forum.netgate.com/topic/157817/problem-loading-web-pages-with-ipv6/15
I've confirmed that lowering my MTU to 1452 fixed the issue but I assumed that my ISP should've dialed in everything properly without messing up the mtu.
I tried mobile data with the same ISP (Etisalat) and this website seems to catch on as to what's exactly happening. I get the same result regardless of whether I'm on my home network or mobile data.
I'm not blurring my home IP address since people seem to get a false hope that I'm hiding something from someone here.
Maybe other have; I do not know you nor have I done any research of you.
For me to notice someone, beyond a single thread, they would have to of gone out of their way to mention I've replied to them before.
3 Likes
I score a 10/10 on that
On https://ipv6-test.com/ i score a 19/20 or 20/20 it seems to vary a bit. This is even if i use a wireguard tunnel to my house with smaller mtu.
So i don't think the mtu itself is the issue, its the connections not recognizing it via icmpv6 or otherwise that the mtu is smaller, then packets just end up in a black hole... Ipv4 uses other techniques to figure out the mtu i think.
The only thing i have left to suggest is disable ipv6 altogether if you don't need it. I also don't really need ipv6, i have a static ipv4, but i still have it enabled as it seems to give slightly lower latency...
Reducing the MTU from 1492 to 1452, I get a 10/10 on that website as well and IPv6 websites load in just fine.
EDIT: Also it looks like what @brada4 mentioned about me being blacklisted seems right. Probably blacklisted my IPv6 ASN which I'm not sure why but probably due to some abuse.
2 Likes
I would leave it at 1452 then. Somehow your downstream mtu becomes lower, this should be automatically corrected, by manually lowering it i guess you circumvented the issue to that test website, but it may not be a fix for everything if to another website the mtu is even lower.
And you could be blacklisted, but well why only ipv6?
It could be as well that this website is not properly configured, i.e. it is not accepting or sending the correct icmpv6.
What's odd is that when I use mobile data, it gives out the same error about a possible MTU related issue... I've only noticed this now and I'm not sure if my ISP is doing something behind the scenes or they are unaware of this.
I tried it with another mobile operator (Du) and they pass the test with 10/10.
Oh did you try the mtu ping check?
See e.g. https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router
Try with ipv4 and ipv6 ping. Check if different destinations have different mtu?
I've reverted my MTU to 1492 and did some tests.
Also I looked up in the technical info page. PMTUD issues..?
So ipv4 mtu is 1492. Try with ipv6 ping (i think ping -6 then add the rest of the options. If that does not work check the ping options)
1 Like
PS C:\Users\azuriye> ping -6 www.videolan.org -l 1400
Pinging www.videolan.org [2a01:e0d:1:3:58bf:fa02:c0de:5] with 1400 bytes of data:
Reply from 2a01:e0d:1:3:58bf:fa02:c0de:5: time=262ms
Reply from 2a01:e0d:1:3:58bf:fa02:c0de:5: time=260ms
Reply from 2a01:e0d:1:3:58bf:fa02:c0de:5: time=260ms
Reply from 2a01:e0d:1:3:58bf:fa02:c0de:5: time=260ms
Ping statistics for 2a01:e0d:1:3:58bf:fa02:c0de:5:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 260ms, Maximum = 262ms, Average = 260ms
anything higher than 1400 times me out.
I think that means 1428 mtu then to that website.
I think 1448: overhead of ipv6 is 8 for icmp v6 echo request and 40 for IPv6
1 Like
Ah yes i think you are right
1 Like