Even weirder… Although I can successfully ping at payload sizes up to 1432, I see another more troubling problem: there’s a “hole” where it works with payloads up to 1232, fails with payloads between 1233 and 1255 inclusive, then works again with payloads 1256 bytes and above. WTF????
-Adam Thompson <mailto:[email protected]> [email protected] Tel: (204) 291-7950 Fax: (204) 489-6515 From: [email protected] [mailto:[email protected]] On Behalf Of Adam Thompson Sent: Thursday, August 15, 2013 3:14 PM To: 'pfSense support and discussion' Subject: Re: [pfSense] IPv6 & HE.net tunnel - MTU problem confirmed My MTU size was 1280; since the patch applied to fix bug #2674, I can now override this to match the 1480 MTU on the HE side… I think. At least, on tunnelbroker.net, the MTU is set to 1480, and on my end, the MTU is set to 1480. Now I can pass ICMP with a payload of up to 1432 bytes. The root-cause-iest symptom now is that setting the DF bit has *no effect* on whether larger packets make it through or not. This makes me suspect that someone (Myself? HE? Corenap?) is dropping fragmented packets. I can observe the identical behaviour from the GIF endpoint (pfSense 2.1, build from two days ago IIRC) and from hosts on the LAN behind it. -Adam Thompson <mailto:[email protected]> [email protected] From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Adam Hunt Sent: Thursday, August 15, 2013 1:47 PM To: pfSense support and discussion Subject: Re: [pfSense] IPv6 & HE.net tunnel - MTU problem confirmed Have you tried the -m option with ping6? According to the FreeBSD man page it will suppress fragmentation of the ICMP packets. This might help find the MTU minimum for the path in question. On Thu, Aug 15, 2013 at 11:40 AM, Adam Hunt <[email protected] <mailto:[email protected]> > wrote: What do you have your MTUs and MSS set at on each of the interfaces? >From what I can tell the interfaces that might play a roll in this issue are the WAN link, the tunnel link, and the MTU on the Tunnel Broker site. I have to move some furniture for the next couple hours. After that I'll try to sit down and experiment with various sized packets using ping. Thanks for the help. On Thu, Aug 15, 2013 at 10:26 AM, Jim Thompson <[email protected] <mailto:[email protected]> > wrote: On Aug 15, 2013, at 12:13 PM, Adam Hunt <[email protected] <mailto:[email protected]> > wrote: Thanks for confirming this. I'm glad that I'm not the only one and/or I'm not completely inept. I'll sit down later today and play with the various MTU settings (WAN, HEv6 tunnel, and the setting on the "advanced tab" of Tunnel Broker's site) and see what, if anything, I can get to work consistently. I don't know what browser you use but I found a simple Chrome extension that has been helpful in determining what protocol (v4/v6) is being using used to connect to any specific site. It's called IPvFoo and is available in the webstore (http://goo.gl/kxKVhx). It adds a little 4 or 6 icon on the right of the URI bar that when clicked on shows what portions of the page were served using what protocol. Again, thanks for confirming this. At certain points I was beginning to doubt myself as things would work on second and break for seemingly no reason the next. --adam On Thu, Aug 15, 2013 at 9:51 AM, Adam Thompson <[email protected] <mailto:[email protected]> > wrote: I'm having the same problem as a recent reporter (whose email I already can't find). I've got a tunnel set up to HE.NET <http://he.net/> , and experience difficulty browsing to (e.g.) redmine.pfsense.org <http://redmine.pfsense.org/> . Testing shows that the largest ICMP payload I can exchange is 1232 bytes ("ping -l 1232 redmine.pfsense.org <http://redmine.pfsense.org/> " works, 1233 doesn't). If I stop and reload the page in my browser, everything works fine - I don't know yet if that's because the browser falls back to IPv4 or because the MTU problem suddenly fixes itself. -Adam Thompson [email protected] <mailto:[email protected]> Tel: (204) 291-7950 <tel:%28204%29%20291-7950> Fax: (204) 489-6515 <tel:%28204%29%20489-6515> Hi Adam (and Adam), Seems easy enough to reproduce, assuming that my substitution of '-s' for '-l' is legit. jims-mini:~ jim$ ping6 -s 1232 redmine.pfsense.org <http://redmine.pfsense.org> PING6(1280=40+8+1232 bytes) 2610:160:11:33:84b5:f958:6545:af1c --> 2610:160:11:3::100 1240 bytes from 2610:160:11:3::100, icmp_seq=0 hlim=62 time=1.625 ms ^C --- redmine.pfsense.org <http://redmine.pfsense.org> ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.625/1.625/1.625/0.000 ms jims-mini:~ jim$ ping6 -s 1233 redmine.pfsense.org <http://redmine.pfsense.org> PING6(1281=40+8+1233 bytes) 2610:160:11:33:84b5:f958:6545:af1c --> 2610:160:11:3::100 ^C --- redmine.pfsense.org <http://redmine.pfsense.org> ping6 statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss Note that I'm … "really close". jims-mini:~ jim$ traceroute6 redmine.pfsense.org <http://redmine.pfsense.org> traceroute6 to redmine.pfsense.org <http://redmine.pfsense.org> (2610:160:11:3::100) from 2610:160:11:33:84b5:f958:6545:af1c, 64 hops max, 12 byte packets 1 2610:160:11:33::2 1.888 ms 1.861 ms 1.461 ms 2 2610:160:11:12::2 1.984 ms 2.107 ms 2.303 ms 3 2610:160:11:3::100 2.172 ms 2.275 ms 2.250 ms jims-mini:~ jim$ Given same, it almost has to be the pfSense box, since once I'm on redmine, huge packets pass. jim@redmine:/home/jim % traceroute6 -n he.net <http://he.net> traceroute6 to he.net <http://he.net> (2001:470:0:76::2) from 2610:160:11:3::100, 64 hops max, 12 byte packets 1 2610:160:11:3::2 0.381 ms 0.336 ms 0.349 ms 2 2610:160:11::1 4.210 ms 1.249 ms 2.435 ms 3 2610:160:0:11::4 2.556 ms 2.611 ms 0.993 ms 4 2610:160:0:53::17 10.253 ms 10.212 ms 10.408 ms 5 2001:504:0:5::6939:1 12.735 ms 10.145 ms 15.192 ms 6 2001:470:0:258::1 32.502 ms 27.384 ms 27.439 ms 7 2001:470:0:24a::2 62.184 ms 43.638 ms 43.681 ms 8 2001:470:0:16a::1 53.841 ms 46.596 ms 53.421 ms 9 2001:470:0:2f::1 59.776 ms 2001:470:0:18d::1 46.394 ms 46.766 ms 10 2001:470:0:2d::1 55.180 ms 49.954 ms 49.308 ms 11 2001:470:0:76::2 50.513 ms 50.814 ms 50.959 ms jim@redmine:/home/jim % sudo ping6 -s 3500 redmine.pfsense.org <http://redmine.pfsense.org> PING6(3548=40+8+3500 bytes) 2610:160:11:3::100 --> 2610:160:11:3::100 3508 bytes from 2610:160:11:3::100, icmp_seq=0 hlim=64 time=0.106 ms 3508 bytes from 2610:160:11:3::100, icmp_seq=1 hlim=64 time=0.074 ms 3508 bytes from 2610:160:11:3::100, icmp_seq=2 hlim=64 time=0.076 ms 3508 bytes from 2610:160:11:3::100, icmp_seq=3 hlim=64 time=0.069 ms 3508 bytes from 2610:160:11:3::100, icmp_seq=4 hlim=64 time=0.074 ms ^C --- redmine.pfsense.org <http://redmine.pfsense.org> ping6 statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.069/0.080/0.106/0.013 ms jim@redmine:/home/jim % That said, I'm on redmine with IPvFoo loaded, and it's reporting that I'm hitting the IPv6 site, and I'm not having any issues. We'll look into it and get back to you. jim _______________________________________________ List mailing list [email protected] <mailto:[email protected]> http://lists.pfsense.org/mailman/listinfo/list
_______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
