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