Re: aptitude/apt-get hangs during update (plus) on IPv6
Rick Thomas a écrit : My point is that by setting your MTU to 1280, you have done *your* part. By doing that you have just used a side effect of the MTU as a workaround to hide the problem originating at the other end, for TCP connections only. Nothing has been fixed. At least you can be assured that all your packets will get thru without fragmentation, Setting the MTU to the minimum value does not prevent fragmentation. Datagrams bigger that the path MTU will still need to be fragmented, and the lower you set the MTU, the more frequently fragmentation will happen. If the host on the other end sets its MTU to something larger and an intervening router doesn't do fragmentation IPv6 routers don't do fragmentation. Fragmentation is done by the sending host only. Intermediate routers must only generate ICMPv6 packet too big messages. That is similar to IPv4 when packets have the DF flag set. Anything that drops or ignore those ICMPv6 messages will break the path MTU discovery. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df4b955.7080...@plouf.fr.eu.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
Rick Thomas writes: On Jun 5, 2011, at 9:46 AM, Pascal Hambourg wrote: Rick Thomas a écrit : On Jun 3, 2011, at 10:46 AM, Jeffrey B. Green wrote: The RFCs say that any conforming implementation MUST handle an MTU of 1280, and may not necessarily handle anything larger. What is your point in mentionning this requirement? Do you mean that the server should not send packets bigger than 1280 bytes if it fails to handle properly path MTU discovery ? If so, I fully agree. My point is that by setting your MTU to 1280, you have done *your* part. At least you can be assured that all your packets will get thru without fragmentation, even if the host at the other end -- or some intervening router -- is improperly configured. If the host on the other end sets its MTU to something larger and an intervening router doesn't do fragmentation, they (or the admins of the router) need to fix that. An easy recommendation that you can make in this case (if the server admin on the other end is clueless but willing to help) is for them to set their MTU to 1280 as well. That will fix the problem regardless of intervening routers. Finding a (possible series of) mis-configured intermediate router(s) and convincing the respective router-admin(s) to fix their configuration is often difficult. It's easier if you have only one person to talk to, the server admin on the other end. In my case, I was able to explore some of the pitfalls of MTUs, in particular in crossing a firewall. I know that I was not able to easily take care of a decreasing MTU mismatch _across the firewall_ in the case of IPv4; so the internal lan-side MTU must match the wan-side MTU for our location. (Not sure at present if the MTU correction messages were not making it back or if some of the workstations were being obstinate in setting the MTU or if the firewall was killing the latter fragments.) And at present only the servers and a handful of workstations here are accessing the world by IPv6, and consequently any tunnel impact on MTU here was minimal. -jeff -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df0bc4f.1080...@kikisoso.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
Rick Thomas a écrit : On Jun 3, 2011, at 10:46 AM, Jeffrey B. Green wrote: The RFCs say that any conforming implementation MUST handle an MTU of 1280, and may not necessarily handle anything larger. Wha is your point in mentionning this requirement ? Do you mean that the server should not send packets bigger than 1280 bytes if it fails to handle properly path MTU discovery ? If so, I fully agree. So it makes sense (if you're going to go to the trouble of setting the MTU in the first place) to use that number. Lowering the MTU at the client side does not fix the problem that exists at the server side. It is just a workaround that works for TCP because it happens that TCP uses the *outgoing* MTU to calculate the advertised *incoming* MSS (how weird when you consider that internet routing is likely to be asymmetric). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4deb88c5.2050...@plouf.fr.eu.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
On Jun 5, 2011, at 9:46 AM, Pascal Hambourg wrote: Rick Thomas a écrit : On Jun 3, 2011, at 10:46 AM, Jeffrey B. Green wrote: The RFCs say that any conforming implementation MUST handle an MTU of 1280, and may not necessarily handle anything larger. What is your point in mentionning this requirement? Do you mean that the server should not send packets bigger than 1280 bytes if it fails to handle properly path MTU discovery ? If so, I fully agree. My point is that by setting your MTU to 1280, you have done *your* part. At least you can be assured that all your packets will get thru without fragmentation, even if the host at the other end -- or some intervening router -- is improperly configured. If the host on the other end sets its MTU to something larger and an intervening router doesn't do fragmentation, they (or the admins of the router) need to fix that. An easy recommendation that you can make in this case (if the server admin on the other end is clueless but willing to help) is for them to set their MTU to 1280 as well. That will fix the problem regardless of intervening routers. Finding a (possible series of) mis-configured intermediate router(s) and convincing the respective router-admin(s) to fix their configuration is often difficult. It's easier if you have only one person to talk to, the server admin on the other end. So it makes sense (if you're going to go to the trouble of setting the MTU in the first place) to use that number. Lowering the MTU at the client side does not fix the problem that exists at the server side. It is just a workaround that works for TCP because it happens that TCP uses the *outgoing* MTU to calculate the advertised *incoming* MSS (how weird when you consider that internet routing is likely to be asymmetric). In the particular case in hand -- aptitude/apt-get talking to schein.debian.org, that is: the ipv6 avitar of security.debian.org -- I have observed that setting your own MTU to 1280 is all that's necessary. Enjoy! Rick -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/eb0db985-c349-4108-a689-120c3c997...@pobox.com
Re: aptitude/apt-get hangs during update (plus) on IPv6
On Jun 3, 2011, at 10:46 AM, Jeffrey B. Green wrote: On Fri, 03 Jun 2011 09:42:49 +0200 Pascal Hambourg pascal.m...@plouf.fr.eu.org wrote: It could be an MTU/MSS issue. See the recent discussion in the debian-ipv6 list with subject schein.debian.org [2001:4f8:8:36::6]. Many thanks. Changing the MTU to 1480 as suggested worked. Indeed as was mentioned my connection to the IPv6 network is via a tunnel and I'm assuming as a poster commented that someone on the path is not handling the packaging correctly. -jeff The RFCs say that any conforming implementation MUST handle an MTU of 1280, and may not necessarily handle anything larger. So it makes sense (if you're going to go to the trouble of setting the MTU in the first place) to use that number. The difference in overhead between 1280 and 1400 is negligible. Rick -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e8a5248c-e882-455b-935b-a863eb2d7...@pobox.com
Re: aptitude/apt-get hangs during update (plus) on IPv6
Hello, Jeffrey B. Green a écrit : I'm seeing if there is an alternate answer here before filing a bug. (I believe) All of the servers here that have IPv6 configured hang while attempting an update on security.debian.org. If I turn off IPv6 by deconfiguring the IPv6 address, then the update goes through fine. It could be an MTU/MSS issue. See the recent discussion in the debian-ipv6 list with subject schein.debian.org [2001:4f8:8:36::6]. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4de89079.1000...@plouf.fr.eu.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
On Fri, 03 Jun 2011 09:42:49 +0200 Pascal Hambourg pascal.m...@plouf.fr.eu.org wrote: Hello, Jeffrey B. Green a écrit : I'm seeing if there is an alternate answer here before filing a bug. (I believe) All of the servers here that have IPv6 configured hang while attempting an update on security.debian.org. If I turn off IPv6 by deconfiguring the IPv6 address, then the update goes through fine. It could be an MTU/MSS issue. See the recent discussion in the debian-ipv6 list with subject schein.debian.org [2001:4f8:8:36::6]. Many thanks. Changing the MTU to 1480 as suggested worked. Indeed as was mentioned my connection to the IPv6 network is via a tunnel and I'm assuming as a poster commented that someone on the path is not handling the packaging correctly. -jeff -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110603104634.467a8...@naro.kikisoso.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
On Wed, 1 Jun 2011 10:00:17 -0400 Jeffrey B. Green j...@kikisoso.org wrote: Doing the update from the firewall works, a conversation of 29 packets in the captured pcap file. There are still 404s but none of the out of sequence/lost sequence messages. Hmmm, now to see which of the packets are being dropped... Okay, below is the flow graph from wireshark for the failed communication. If I let the app run, it eventually shifts to IPv4 and completes. The completion here is due to me killing the app with a ^C. |Time | ::::: | | | | 2001:4f8:8:36::6 | |0.000| SYN | |Seq = 0 Ack = 1879259867 | |(34859) -- (80) | |0.107| SYN, ACK | |Seq = 0 Ack = 1 | |(34859) -- (80) | |0.107| ACK | |Seq = 1 Ack = 1 | |(34859) -- (80) | |0.117| ACK - Len: 1408 |Seq = 1 Ack = 1 | |(34859) -- (80) | |0.119| PSH, ACK - Len: 288 |Seq = 1409 Ack = 1 | |(34859) -- (80) | |0.226| ACK | |Seq = 1 Ack = 1409 | |(34859) -- (80) | |0.227| ACK | |Seq = 1 Ack = 1697 | |(34859) -- (80) | |0.228| PSH, ACK - Len: 1107 |Seq = 1 Ack = 1697 | |(34859) -- (80) | |0.228| ACK | |Seq = 1697 Ack = 1108 | |(34859) -- (80) | |0.233| PSH, ACK - Len: 544 |Seq = 1108 Ack = 1697 | |(34859) -- (80) | |0.233| ACK | |Seq = 1697 Ack = 1652 | |(34859) -- (80) | |0.233| PSH, ACK - Len: 547 |Seq = 1652 Ack = 1697 | |(34859) -- (80) | |0.233| ACK | |Seq = 1697 Ack = 2199 | |(34859) -- (80) | |0.341| PSH, ACK - Len: 979 |Seq = 5055 Ack = 1697 | |(34859) -- (80) | |0.341| ACK | |Seq = 1697 Ack = 2199 | |(34859) -- (80) | |0.356| PSH, ACK - Len: 218 |Seq = 1697 Ack = 2199 | |(34859) -- (80) | |0.459| PSH, ACK - Len: 166 |Seq = 6034 Ack = 1915 | |(34859) -- (80) | |0.459| ACK | |Seq = 1915 Ack = 2199 | |(34859) -- (80) | |15.474 | FIN, ACK | |Seq = 6200 Ack = 1915 | |(34859) -- (80) | |15.474 | ACK | |Seq = 1915 Ack = 2199 | |(34859) -- (80) | |33.860 | FIN, ACK | |Seq = 1915 Ack = 2199 | |(34859) -- (80) | |33.973 | ACK | |Seq = 6201 Ack = 1916 | |(34859) -- (80) | -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110602145723.20908...@naro.kikisoso.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
Chris Brennan writes: On Tue, May 31, 2011 at 1:20 PM, Andrei Popescu andreimpope...@gmail.com wrote: On Ma, 31 mai 11, 09:50:48, Jeffrey B. Green wrote: So, if anyone knows what going on here or whether this looks like an official bug, then let me know. This sounds like you might want to contact debian-admin ;) I know. It's like you can never find a good admin around when you need one. [I'm somewhat emoticon ignorant and so will not attempt to insert the appropriate one here...just assume I'm giving a knowing smile...however not to assume that I indeed know.] The 404's you were getting, I got them as well on my Debian 6 VPS. No firewall in place on he VPS (yet, as I am still setting it up) but every time I run an update, I see the 404's against s.d.o ... the VPS is IPv4 only but the hosting provider may be doing IPv6 w/o my knowledge. It seems like it should be quickly solvable since the conversations are so short (20-22 packets) and that it works just fine for IPv4 but not IPv6. I'm just not knowledgeable enough about the protocol/processing followed here. [The dream is to have all revealed in /u/s/doc/whatever, e.g. aptitude in this case. But as always, code first, docs second, or possibly third, sometimes fourth, maybe...at times I'm thankful for what I do get. However, one's prerogative to grumble has a certain priority.] For my case, the firewall really does appear to be innocent, though until the solution appears, it is not totally off the hook. Also, the behavior that it works okay (in the past) for awhile and then does not seems to indicate something transient or at least changing somehow. -jeff -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4de63c19.60...@kikisoso.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
On Wed, 01 Jun 2011 09:18:17 -0400 Jeffrey B. Green j...@kikisoso.org wrote: Chris Brennan writes: The 404's you were getting, I got them as well on my Debian 6 VPS. No firewall in place on he VPS (yet, as I am still setting it up) but every time I run an update, I see the 404's against s.d.o ... the VPS is IPv4 only but the hosting provider may be doing IPv6 w/o my knowledge. For my case, the firewall really does appear to be innocent, though until the solution appears, it is not totally off the hook. Also, the behavior that it works okay (in the past) for awhile and then does not seems to indicate something transient or at least changing somehow. Doing the update from the firewall works, a conversation of 29 packets in the captured pcap file. There are still 404s but none of the out of sequence/lost sequence messages. Hmmm, now to see which of the packets are being dropped... -jeff -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110601100017.47eb0...@naro.kikisoso.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
On Wed, 1 Jun 2011 10:00:17 -0400 Jeffrey B. Green j...@kikisoso.org wrote: Doing the update from the firewall works, a conversation of 29 packets in the captured pcap file. There are still 404s but none of the out of sequence/lost sequence messages. Hmmm, now to see which of the packets are being dropped... [Succ: successful conversation; Fail: failed conversation] The first point of departure is at packet 8: Succ: HTTP/1.1 304 Not Modified Fail: HTTP/1.1 200 OK (text/plain) Both responses from debian.org Then at packet 14: Succ: GET /dists/squeeze/updates/Release HTTP/1.1 Fail: [TCP Previous segment lost] Continuation or non-HTTP traffic (text/html) The succ is a request from me; the fail is a debian.org response. The corresponding line on the fail seems to be at packet 16. Packet 15 is a dup ack in response to 14 (dup of 13). The debian.org response to packet 16 is: Fail: HTTP/1.1 304 Not Modified The failed conversation then ends with a dup-ack, a fin-ack, a dup-ack, a fin-ack, and a ack, in alternating directions exc. for 2nd fin-ack. [If I'm making gross misinterpretations that people see, then please let me know. Thanks.] -jeff -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110601115020.03d6e...@naro.kikisoso.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
On Tue, May 31, 2011 at 03:50:48PM CEST, Jeffrey B. Green j...@kikisoso.org said: Hi, I'm seeing if there is an alternate answer here before filing a bug. (I believe) All of the servers here that have IPv6 configured hang while attempting an update on security.debian.org. If I turn off IPv6 by deconfiguring the IPv6 address, then the update goes through fine. When I check with tcpdump to be sure the firewall isn't the culprit, I find that all of the packets that reach the firewall also make it to the server and a conversation of 20-22 packets occurs (20 on one server, 22 on a different one). [If anyone wants to provide me with a state transition diagram, or even a description, for the protocol aptitude follows in doing the update, then I'd be happy to track down where exactly in the process it hangs.] I can go back and forth with enabling and disabling IPv6, and IPv4 always seems to work (just tried it with one server). So, if anyone knows what going on here or whether this looks like an official bug, then let me know. thanks, -jeff It might be a routing/firewall problem on IPv6 the way between you and security.debian.org, since it works for me. Do you succeed in browsing http://security.debian.org with IPv6 activated ? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110531151306.gb20...@rail.eu.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
On Tue, 31 May 2011 09:50:48 -0400 Jeffrey B. Green j...@kikisoso.org wrote: When I check with tcpdump to be sure the firewall isn't the culprit, I find that all of the packets that reach the firewall also make it to the server and a conversation of 20-22 packets occurs (20 on one server, 22 on a different one). Doing a capture to file and examining with wireshark shows several 404 Not Found HTTP messages, in particular: The requested URL /dists/squeeze/updates/contrib/i18n/Translation-en_US.bz2 was not found on this server. -AND- The requested URL /dists/squeeze/updates/contrib/i18n/Translation-en.bz2 was not found on this server. I'm guessing the IPv4 and IPv6 security servers are not the same machine. -jeff -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011053513.62473...@naro.kikisoso.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
On Tue, 31 May 2011 09:50:48 -0400, Jeffrey B. Green wrote: I'm seeing if there is an alternate answer here before filing a bug. (I believe) All of the servers here that have IPv6 configured hang while attempting an update on security.debian.org. If I turn off IPv6 by deconfiguring the IPv6 address, then the update goes through fine. When I check with tcpdump to be sure the firewall isn't the culprit, I find that all of the packets that reach the firewall also make it to the server and a conversation of 20-22 packets occurs (20 on one server, 22 on a different one). [If anyone wants to provide me with a state transition diagram, or even a description, for the protocol aptitude follows in doing the update, then I'd be happy to track down where exactly in the process it hangs.] I can go back and forth with enabling and disabling IPv6, and IPv4 always seems to work (just tried it with one server). I think this also happened to me just a few days ago. I couldn't reach any of the security servers and suspected it was because apt tried to reach the ipv6 server which, thanks to my ISP (grrr!), is something I still can't do :-/ How I solved it? Retrying the update command until I finally got the ipv4 server address as response }:-) So, if anyone knows what going on here or whether this looks like an official bug, then let me know. There is a wishlist bug report to enable/disable ipv6 just for apt, which I think it should be something nice to have at least for this ipv4/ipv6 transtitional period that is coming... please give apt.conf.d option to disable ipv6 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611891 Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.05.31.15.33...@gmail.com
Re: Re: aptitude/apt-get hangs during update (plus) on IPv6
David Erwin writes: On Tue, May 31, 2011 at 03:50:48PM CEST, Jeffrey B. Green j...@kikisoso.org said: Hi, I'm seeing if there is an alternate answer here before filing a bug. (I believe) All of the servers here that have IPv6 configured hang while attempting an update on security.debian.org. If I turn off IPv6 by deconfiguring the IPv6 address, then the update goes through fine. It might be a routing/firewall problem on IPv6 the way between you and security.debian.org, since it works for me. Do you succeed in browsing http://security.debian.org with IPv6 activated ? Yes. I do a wget since it's a server without any windowing. Also, the updates/upgrades had been working just fine until this one. I tracked the conversation at the firewall to be sure the wget was going through IPv6 and it was. The Debian server it goes to is: 2001:4f8:8:36::6. -jeff -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4de509ca.3040...@kikisoso.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
On Tue, 31 May 2011 11:15:13 -0400 Jeffrey B. Green j...@kikisoso.org wrote: On Tue, 31 May 2011 09:50:48 -0400 Jeffrey B. Green j...@kikisoso.org wrote: When I check with tcpdump to be sure the firewall isn't the culprit, I find that all of the packets that reach the firewall also make it to the server and a conversation of 20-22 packets occurs (20 on one server, 22 on a different one). Doing a capture to file and examining with wireshark shows several 404 Not Found HTTP messages, in particular: Another tidbit: I did an update (IPv4) and then a safe-upgrade (IPv6) which hung. I got a tcpdump of that. There was a 404 in common with the previous IPv6 update plus a: 14 11:00:09.380965 2001:4f8:8:36::6 :::xx HTTP[TCP Previous segment lost] Continuation or non-HTTP traffic (text/html) That was in common across both. -jeff -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110531115856.2a32a...@naro.kikisoso.org
Re: aptitude/apt-get hangs during update (plus) on IPv6
On Ma, 31 mai 11, 09:50:48, Jeffrey B. Green wrote: So, if anyone knows what going on here or whether this looks like an official bug, then let me know. This sounds like you might want to contact debian-admin ;) Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: aptitude/apt-get hangs during update (plus) on IPv6
On Tue, May 31, 2011 at 1:20 PM, Andrei Popescu andreimpope...@gmail.com wrote: On Ma, 31 mai 11, 09:50:48, Jeffrey B. Green wrote: So, if anyone knows what going on here or whether this looks like an official bug, then let me know. This sounds like you might want to contact debian-admin ;) The 404's you were getting, I got them as well on my Debian 6 VPS. No firewall in place on he VPS (yet, as I am still setting it up) but every time I run an update, I see the 404's against s.d.o ... the VPS is IPv4 only but the hosting provider may be doing IPv6 w/o my knowledge. -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon?
