Changing AdvLinkMTU when using NPt
-
Nope, vanilla windows 10 (tested on the host and in a VM with a fresh windows install)
I did attach 2 captures. In the first one, one can see the packet too big. And in the second you can see some errors beyond my basic understanding of wireshark.
I did filter the capture over traffic towards a web site (www.swisscom.ch) + icmpv6. Sadly the website I am having problem with uses SSL, so the capture is not that clear.
If I edit the services.inc to let radvd advertise a MTU of 1280 (or even 1480 - despite the 6RD being configured to use 1280) everything works fine.
 -
I haven't seen those errors before either, however it appears something might be corrupting the Ethernet frames. There's the malformed packet error, which means there was a problem somewhere causing bit errors in the frame. That might also be the cause of the segment errors. There's not enough info shown to know where the problem is coming from. Do other computers have the same problem? If only one has the problem, I'd suspect something like a defective NIC. The 1480 MTU shows PMTUD is working. What other equipment is there between the Windows computer and pfSense? Again those malformed packet, frame check sequence incorrect errors make me suspect hardware.
-
I just thought of something to. Is that the only site you have an issue with when you let it advertised a 1500 MTU. Because I noticed something from that site when I ran a certain test to it. I'll link and show it in a minute when I get a chance
-
I just thought of something to. Is that the only site you have an issue with when you let it advertised a 1500 MTU. Because I noticed something from that site when I ran a certain test to it. I'll link and show it in a minute when I get a chance
The site shouldn't cause Ethernet frame errors, as he appears to be getting.
-
I just thought of something to. Is that the only site you have an issue with when you let it advertised a 1500 MTU. Because I noticed something from that site when I ran a certain test to it. I'll link and show it in a minute when I get a chance
The site shouldn't cause Ethernet frame errors, as he appears to be getting.
Agreed. But I'm wondering if there's not two issues and while that is of course a problem maybe not the problem for that site.
See this
https://www.ipv6alizer.se?address=https://www.swisscom.ch
Vs
https://www.ipv6alizer.se?address=https://Www.facebook.com -
Wow, the "Output" on that site is impossible to read, with the faint green text. I had to cut 'n paste it into another app, to read it. Why do some people create sites that are unreadable?
-
Yep this is strange. I did some more testing, and I am also getting weird errors when I set router advertisement to 1280 (but traffic works, beside wireshark, everything is green)
I am unsure about bad hardware, as ipv4 works fine. Pretty much everything runs on VMs, on intel NICs. As IPv6 is not vital and that I do not see any easy way to get this sorted I might not invest too much effort in getting this working. In any case, I will report my findings here
In any case, thank everyone for the help.
-
Yep this is strange. I did some more testing, and I am also getting weird errors when I set router advertisement to 1280 (but traffic works, beside wireshark, everything is green)
I am unsure about bad hardware, as ipv4 works fine. Pretty much everything runs on VMs, on intel NICs. As IPv6 is not vital and that I do not see any easy way to get this sorted I might not invest too much effort in getting this working. In any case, I will report my findings here
In any case, thank everyone for the help.
You never mentioned if this effects any other site. Other then that one.
-
I am unsure about bad hardware, as ipv4 works fine.
If you're getting CRC errors, you have a hardware problem that has nothing to do with IP or web site. It could be a bad NIC, switch port, cable connection, etc., but something physical is causing that. Are you certain you don't see any similar errors with IPv4? You can try pinging with different size packets to test and you can also force either IPv4 or IPv6 when testing. Do you get similar errors if you use a different computer?
-
I know it old topic, but @JKnott test yourself https://meet.lync.com/ not adjusted at all
-
@dragoangel said in Changing AdvLinkMTU when using NPt:
I know it old topic, but @JKnott test yourself https://meet.lync.com/ not adjusted at all
What am I supposed to be looking for? All I see is an error message about not being allowed to enter the meeting. Wireshark doesn't show anything unusual either. I don't see any frame errors, as was described in the previous messages.
-
I'm alredy found answer on my question in https://answers.microsoft.com/en-us/msoffice/forum/msoffice_sfb-mso_mac-mso_o365b/skype-for-businesslync-services-dont-appear-to/c204b511-8b0b-4338-924e-729603627413?page=2 sorry =).
-
@dragoangel said in Changing AdvLinkMTU when using NPt:
I'm alredy found answer on my question
Tunnels always have a smaller MTU than the underlying network, to make room for their own header. I wouldn't experience that problem here, as I'm not using a tunnel. My MTU, on both sides of pfSense, is 1500.
I used to use a tunnel, with 1280 MTU.
It would appear the problem is with Microsoft software (Gee... What a surprise!!! ) not properly handling PMTUD. By reducing the local MTU, packets are no longer too big to pass through a link with the smaller MTU.
-
@JKnott Yes, I read it. They not go by RFC. And this is not first time I see it. I write them about HTTP/2 in IIS =). Same here... Lower down all LAN MTU only for some 2-3 host in Internet. Better rewrite DNS...
P.S. If configure MTU on GIF to tunnelbroker - this is ok. It really 1480. And configure Squid Proxy. PC by proxy will access lync.com. This acceptable workaround #2. But without proxy - of course with brokem PMTU on MS side it anyway fail -
@JKnott said in Changing AdvLinkMTU when using NPt:
@dragoangel said in Changing AdvLinkMTU when using NPt:
I'm alredy found answer on my question
Tunnels always have a smaller MTU than the underlying network, to make room for their own header. I wouldn't experience that problem here, as I'm not using a tunnel. My MTU, on both sides of pfSense, is 1500.
I used to use a tunnel, with 1280 MTU.
It would appear the problem is with Microsoft software (Gee... What a surprise!!! ) not properly handling PMTUD. By reducing the local MTU, packets are no longer too big to pass through a link with the smaller MTU.
And here is the "proof"
https://www.ipv6alizer.se?address=https://meet.lync.com -
@Napsterbater MS is so bad, they work on broken IPv4 too:
tbit from 130.217.250.115 to 52.113.64.150 server-mss 1460, result: pmtud-fail app: http, url: https://meet.lync.com/ [ 0.009] TX SYN 44 seq = 0:0 b7ef [ 0.136] RX SYN/ACK 44 seq = 0:1 2774 [ 0.136] TX 40 seq = 1:1 b7f0 [ 0.136] TX 369 seq = 1:1(329) b7f1 DF [ 0.268] RX 1500 seq = 1:330(1460) 277b DF [ 0.268] RX 1500 seq = 1461:330(1460) 277c DF [ 0.268] RX 1460 seq = 2921:330(1420) 277d DF [ 0.268] TX PTB 56 mtu = 1280 [ 0.693] RX 1500 seq = 1:330(1460) 2780 DF [ 0.693] TX PTB 56 mtu = 1280 [ 1.443] RX 1500 seq = 1:330(1460) 279e DF [ 1.443] TX PTB 56 mtu = 1280 [ 2.927] RX 1500 seq = 1:330(1460) 27f7 DF [ 2.928] TX PTB 56 mtu = 1280 [ 5.896] RX 1500 seq = 1:330(1460) 2834 DF tbit from 2001:df0:4:4000::1:115 to 2603:1047:0:2::e server-mss 1440, result: pmtud-fail app: http, url: https://meet.lync.com/ [ 0.009] TX SYN 64 seq = 0:0 [ 0.232] RX SYN/ACK 64 seq = 0:1 [ 0.232] TX 60 seq = 1:1 [ 0.232] TX 389 seq = 1:1(329) [ 0.459] RX 1500 seq = 1:330(1440) [ 0.459] RX 1500 seq = 1441:330(1440) [ 0.459] RX 1500 seq = 2881:330(1440) [ 0.459] RX 80 seq = 4321:330(20) [ 0.459] TX PTB 1280 mtu = 1280 [ 0.470] TX 60 seq = 330:1 [ 1.178] RX 1500 seq = 1:330(1440) [ 1.178] TX PTB 1280 mtu = 1280 [ 2.489] RX 1500 seq = 1:330(1440) [ 2.490] TX PTB 1280 mtu = 1280 [ 5.083] RX 1500 seq = 1:330(1440) [ 5.084] TX PTB 1280 mtu = 1280 [ 10.302] RX 1500 seq = 1:330(1440)
