On Thursday 05 Sep 2013 14:17:14 Grant wrote: > > +1 on Alan's hunch. I have not used Squid to comment on the specifics > > and also Grant stated that another proxy gave him similar symptoms. > > From my limited knowledge a proxy could be stalling because of cache > > configuration problems, like running out fs space, or inodes and also > > running out of memory if it has to process simultaneous requests from > > too many clients at a time. If the problem also manifests when the > > clients are within the same subnet, then this is unlikely to be a > > network issue. > > Which hunch was that? I snipped a lot above but I couldn't find it in > there.
It was Alan's statement that this problem is not related to your AT&T router. > It's just one user (me) and I've fiddled with the cache (including > disabling it) and at least fs space and memory are good. OK, this points away from your proxy configuration then. I noticed you mentioning that the problem is manifested with a different proxy application, points to a network problem, unless the cache fs set up is exactly the same. As long as you have enough disk space and enough inodes, plus enough RAM, then all points to a network problem. > > If all other causes are eliminated then a network related problem could > > be associated with TCP Window Scaling - but this would primarily show up > > on the transmission of larger files. This is why I initially asked if > > the problem shows up on video/audio downloads rather than small web > > pages. I have to come back to this. I tried the www.google.com/nexus/ you mentioned and noticed that the page eats up 1.3MB to load fully, before it starts downloading a flash video. So seems to be a relatively large amount of data that brings up this problem and this could point to tcp window scaling. > I've tried all of these with no noticeable change: > > echo 0 > /proc/sys/net/ipv4/tcp_ecn > echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc This should be *disabled* (double negative). PMTU discovery is necessary if any nodes are using smaller than the default 1500 byte ethernet MTU value. So you better set it as: echo 0 > /proc/sys/net/ipv4/ip_no_pmtu_disc > echo 0 > /proc/sys/net/ipv4/tcp_window_scaling This is typically enabled, but if you notice that a connection stalls and then later on it works fine again, it could be related to a firewall/router not responding as it should to tcp_window_scaling. In this case disabling this would fix the problem when traversing problematic nodes. If you saw no difference, this suggests that window scaling is not an issue. > Not that anyone here should bother to read it, but here's a link to my > thread on the squid list where I tried all kinds of stuff: > > http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-3-5-hangs-the-en > tire-system-td4660893.html I read it and if the squid experts say it is a network problem, then it could well be - although the network problems can be more difficult to diagnose and resolve. > I think at this point I'm hoping that putting the server's > modem/router into bridged mode so it will respond to pings will clear > this up. Well, we don't *know* that the router is the cause of the problem - yet. Setting it up in fully bridged mode and exposing your desktop directly to the Internet will definitely eliminate the router, because it will only be dealing with ATM packet encapsulation. > I think that's conceivable if the modem/router is also > failing to return Fragmentation Needed since its MTU is 1492. Testing > the proxy from within the server's LAN as you suggested in my other > thread could also be informative. Please let me know if there's > anything else I should try. I would start with the simplest tests first, which involve isolating suspect system components one at a time. Trying to use the same laptop-desktop machines within the LAN, takes the router out the equation - full 1500 byte MTU will be used by both laptop and desktop. If that works as intended then setting the router into fully bridged mode will eliminate that node and any problems that it may have with tcp window extensions. Troubleshooting public nodes becomes more difficult, unless you happen to travel around and use networks that bypass the suspect nodes. For all we know it could be the particular hotel firewall/router that is causing the problem. ;-) -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
