[00:28] LOL at this : [00:28] Mailing list subscription confirmation notice for mailing list [00:28] Gramps-users [00:28] We have received a request from 172.29.29.5 for subscription of your [00:28] email address, [00:28] pretty sure thats an RFC1918 address [00:48] lol yep it is. Perhaps the request was via proxy and the ip was passed in an X-Via header [01:00] possibly a load balancer or NAT type setup in front of the webserver that received the request [01:03] *** medum has quit IRC (Ping timeout: 250 seconds) [01:10] *** medum has joined #arpnetworks [01:31] yeah it is [01:31] 172.16 through 172.31 [01:32] well 172.16.0.0 to 172.31.255.255 [01:44] *** carvite has quit IRC (Ping timeout: 244 seconds) [01:49] *** carvite has joined #arpnetworks [04:03] *** fink has joined #arpnetworks [05:49] *** LT has joined #arpnetworks [08:59] *** LT has quit IRC (Quit: Leaving) [11:55] *** qbit has quit IRC (Quit: leaving) [11:55] *** qbit has joined #arpnetworks [11:56] *** qbit is now known as Guest31676 [11:56] *** Guest31676 is now known as qbit [15:23] *** jcv has quit IRC (Ping timeout: 240 seconds) [17:19] *** freedomcode has joined #arpnetworks [17:22] *** acf_ has quit IRC (Ping timeout: 244 seconds) [17:22] *** reardencode has quit IRC (Ping timeout: 244 seconds) [17:22] *** tooth has quit IRC (Ping timeout: 244 seconds) [17:22] *** tooth has joined #arpnetworks [17:26] *** acf_ has joined #arpnetworks [17:48] http://blog.streamingmedia.com/2014/11/cogent-now-admits-slowed-netflixs-traffic-creating-fast-lane-slow-lane.html [17:50] not likely to be balanced, but interesting none the less [18:13] *** tehfink has joined #arpnetworks [18:16] *** fink has quit IRC (Ping timeout: 258 seconds) [18:16] *** tehfink is now known as fink [19:53] *** freedomcode has quit IRC (Remote host closed the connection) [19:54] *** fink has quit IRC (Quit: fink) [20:58] Anybody else with a HE.net tunnel having problems with Google ipv6 traffic? At work and at home both (two different connections, same ipv6 POP) I've had lots of connection timeouts, but ping/mtr don't show any disruptions. [20:59] I've just now taken to forcing all google traffic over ipv4 and that's running smoothly, but it's certainly not much of a long-term solution [20:59] that happens to me over my ARP tunnel [20:59] are your machines MTU set to the tunnel mtu? [21:00] to be frank, I have no idea off hand. It may be a red herring, but everything has worked fine for years, I've made no changes at home or work, etc [21:00] * brycec is multitasking [21:00] a while ago (last month?) the issue began for me [21:01] Google had worked just fine over my tunnel with MTU 1500 until then [21:01] i see [21:03] did some debugging, determined that the ICMP PTB message was being sent properly, but the frames from Google were still too big [21:03] (I could still have a configuration error, idk what it is though) [21:08] If nothing else, it looks like I do have some fun mtu issues elsewhere... should be interesting [21:08] thanks for the tip, acf_ [21:10] HE says the tunnel mtu is 1480, yet the largest packet I can get through is 1432 (1432+40 = 1472 < 1480) Where are those 8 bytes going? hm [21:11] could be an extension header (and exactly one) i suppose [21:33] acf: tunnel mtus don't usually work with 1500? [21:34] tunnel mtu is typically 1480 [21:34] usually there's 60 bytes overhead on ipv6 i thought [21:34] well it's typically 1280 actually [21:34] mercutio: 40 bytes [21:34] ping is 8 bytes normally bryce [21:34] ping -s is X bytes :P [21:34] well udp is' i think ping has similar overhead [21:35] you sure [21:35] i think i can only do 1472 on ipv4 [21:35] # ping -s1472 www.google.com [21:35] PING www.google.com (74.125.237.212) 1472(1500) bytes of data. [21:35] 1480 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=1 ttl=53 time=68.7 ms [21:35] my gogole ping isn't actually working [21:36] i have no idea why [21:36] # ping -s1472 4.2.2.2 [21:36] PING 4.2.2.2 (4.2.2.2) 1472(1500) bytes of data. [21:36] 1480 bytes from 4.2.2.2: icmp_seq=1 ttl=54 time=137 ms [21:36] 1480 bytes from 4.2.2.2: icmp_seq=2 ttl=54 time=139 ms [21:37] # ping -s1442 www.google.com [21:37] PING www.google.com (74.125.237.211) 1442(1470) bytes of data. [21:37] 1450 bytes from syd01s19-in-f19.1e100.net (74.125.237.211): icmp_seq=1 ttl=56 time=24.6 ms [21:37] that took a while to find, with google i can only do up to 1442 [21:38] 1480 bytes from 74.125.237.211: icmp_req=1 ttl=57 time=138 ms [21:38] :P [21:38] (ARP to the IP you were hitting) [21:38] that's weird [21:39] i'm doing it to sydney [21:39] from auckland [21:39] I can't do it from my home connection though. [21:39] yeah i think google just has weird network [21:39] so i'd blame google over he.net [21:39] I'm blaming everybody :p [21:39] i've seen them capping mss on tcp before [21:44] Anyways, the specific issue I'm troubleshooting is a specific request to a specific IP (replaying an http GET). On my home gif0 I see the headers and then the connection goes silent, but that same request on ARP shows some very large responses (gzipped response, packets with length over 2000) that are apparently being silently dropped before making it back to my gif0. So... that suggests the issue is [21:44] remote from me, either Google network or HE. Anybody disagree with that theory? [21:47] (This is what it looks like for those curious http://sprunge.us/OGSG) [21:49] > packets with length over 2000 [21:49] isn't MTU still 1500? [21:49] yep [21:50] how do you have a 2000 byte packet going over a 1500 byte MTU Ethernet? [21:51] To be frank, I haven't quite figured that out yet. Best guess is the host is reconstructing transparently [21:51] ah [21:52] super strange that Google would be sending packets > 1500 bytes [21:52] given 1500 is the standard maximum Ethernet MTU [21:52] Nah, just normal strange... Spec lets packet length go to 65535 [21:52] Which means the packet would be broken up across frames [21:53] > I see the headers and then the connection goes silent [21:53] do you have access to the box at the other end of the tunnel? [21:54] No, that tunnel is HE [21:54] if you have MTUs in your part of the path that are greater than the tunnel MTU [21:55] well, really just the box doing the TCP I think [21:55] path MTU discovery will be done [21:55] Google will try sending a 1500 byte packet, and the HE box will send back a ICMP packet too big [21:56] the annoying part is that Google doesn't seem to honor those [21:58] I guess when you set the MTU on a Linux machine, it also affects the TCP MSS? [21:59] * brycec isn't sure [22:09] * brycec gives up for now, disables google ipv6 traffic and sails along [22:21] nah mtu doesn't chaneg tcp mss [22:21] unless you have a iptables rule to change to interface mtu