tony.chamberlain at lemko.com
2010-Apr-11 22:57 UTC
[CentOS] Yum/WGET/HTTP sourceforge etc.
I am having a problem with 5.4 that I did not have with 4.5. The problem happens only sometimes but in specific instances. Basically a summary of the problem is that certain network transactions timeout. The specfic instances are with wget, rpm, http. The problem usually, but not always, occurs with pptp stuff. (NOT running pptp but getting pptp stuff). For instance, the following command, which finishes in seconds on non-5.4 OS's: wget http://pptpclient.sourceforge.net/yum/stable/rhel4/pptp-release-current.noarch.rpm downloads about 20% then gets stuck. About 5 minutes later it downloads another 20% and then gets stuck, etc. The same thing with rpm: rpm -ivh http://pptpclient.sourceforge.net/yum/stable/rhel4/pptp-release-current.noarch.rpm waits about 3 minutes and then gives an error. I think it does the same thing as the wget but wget will keep trying, while rpm gives up. The error from rpm: Retrieving http://pptpclient.sourceforge.net/yum/stable/rhel4/pptp-release-current.noarch.rpm ..five minutes later: error: /var/tmp/rpm-xfer.DYY9e0: headerRead failed: hdr blob(7456): BAD, read returned 3568 error: /var/tmp/rpm-xfer.DYY9e0 cannot be installed I can wget the above as I mentioned before and install it that way. Before I do it, yum works fine. Afterwards, yum exhibits the same behavior of timing out (because it is using the pptp repository). Also visiting the pptp web site from Firefox times out on certain pages. I originally thought it was some problem with the pptp site, but I notice that log into hotmail.com does the same thin (fine on other operating systems). A view with Wireshark on the wget (pptp) shows the my machine receiving a reassembled TCPPDU from 216.34.181.96 (Sourceforge), sending an ack, receiving a reassembled PDU, sending an ack, receiving, sending followed by the 5 minutes or whatever of nothing. Then sourceforge sends an RST and a SYN and the process is repeated. Here is what I tried. When I put the machine directly on an AT&T IP connection (12.147.X.Y) everything worked fine. Same with Comcast on a direct link. The times I am having problems is when our router is hooked up to a Comcast IP (70.88.X.Y) and assigns 192.168.5.X addresses to our machines. So when I was doing the above from 192.168.5.27 going through the router through Comcast is when I had the problem. So it is probably something with the router, but it is hard to figure out since CentOS 4.5 and Fedora do not exhibit this behavior, nor does 5.4 on most sites (mail.yahoo.com for instance). I did verify, at least from what I could, that ICMP type 3 and 4 are not being blocked. If they were, the same problem would happen on other op systems. And I was able to ping, albeit just locally, but we looked at the router settings and ping was not blocked. Anyone else have this problem / know what might be wrong?
On Apr 11, 2010, at 6:57 PM, tony.chamberlain at lemko.com wrote:> > I am having a problem with 5.4 that I did not have with 4.5. The > problem happens only sometimes but in specific > instances. Basically a summary of the problem is that certain > network transactions timeout. The specfic instances > are with wget, rpm, http. The problem usually, but not always, > occurs with pptp stuff. (NOT running pptp but getting pptp stuff). > > For instance, the following command, which finishes in seconds on > non-5.4 OS's: > > wget http://pptpclient.sourceforge.net/yum/stable/rhel4/pptp-release-current.noarch.rpm > > downloads about 20% then gets stuck. About 5 minutes later it > downloads another 20% and > then gets stuck, etc. The same thing with rpm: > > rpm -ivh http://pptpclient.sourceforge.net/yum/stable/rhel4/pptp-release-current.noarch.rpm > > waits about 3 minutes and then gives an error. I think it does the > same thing as the wget but > wget will keep trying, while rpm gives up. The error from rpm: > > Retrieving http://pptpclient.sourceforge.net/yum/stable/rhel4/pptp-release-current.noarch.rpm > ..five minutes later: > error: /var/tmp/rpm-xfer.DYY9e0: headerRead failed: hdr blob(7456): > BAD, read returned 3568 > error: /var/tmp/rpm-xfer.DYY9e0 cannot be installed > > I can wget the above as I mentioned before and install it that way. > Before I do it, yum works fine. > Afterwards, yum exhibits the same behavior of timing out (because it > is using the pptp repository). > Also visiting the pptp web site from Firefox times out on certain > pages. > > I originally thought it was some problem with the pptp site, but I > notice that log into hotmail.com > does the same thin (fine on other operating systems). A view with > Wireshark on the wget (pptp) > shows the my machine receiving a reassembled TCPPDU from > 216.34.181.96 (Sourceforge), sending an ack, receiving a > reassembled PDU, sending an ack, receiving, sending followed by the > 5 minutes or whatever of nothing. Then sourceforge > sends an RST and a SYN and the process is repeated. > > Here is what I tried. When I put the machine directly on an AT&T IP > connection (12.147.X.Y) everything worked fine. > Same with Comcast on a direct link. The times I am having problems > is when our router is hooked up to a Comcast > IP (70.88.X.Y) and assigns 192.168.5.X addresses to our machines. So > when I was doing the above from 192.168.5.27 > going through the router through Comcast is when I had the problem. > > So it is probably something with the router, but it is hard to > figure out since CentOS 4.5 and Fedora do not exhibit this > behavior, nor does 5.4 on most sites (mail.yahoo.com for instance). > I did verify, at least from what I could, that ICMP > type 3 and 4 are not being blocked. If they were, the same problem > would happen on other op systems. And I was able > to ping, albeit just locally, but we looked at the router settings > and ping was not blocked. > > Anyone else have this problem / know what might be wrong? >Is this due to comcast doing a selective block on certain traffic? Apparently the FCC was prevented from checking or preventing cable companies from selectively shapping traffic. May be nothing. Just a thought.> > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos
On Sun, 2010-04-11 at 22:57 +0000, tony.chamberlain at lemko.com wrote:> Here is what I tried. When I put the machine directly on an AT&T IP connection (12.147.X.Y) everything worked fine. > Same with Comcast on a direct link. The times I am having problems is when our router is hooked up to a Comcast > IP (70.88.X.Y) and assigns 192.168.5.X addresses to our machines. So when I was doing the above from 192.168.5.27 > going through the router through Comcast is when I had the problem. >--- Try this: For the NIC on your Comcast router set its ip to one that the dhcp in the router gives out + DFG + 2 DNS entries. In order to have it static. I see lots of routers with your problem. John