Re: [gentoo-user] Can't ping remote system

[Mick <michaelkintzios@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 4548 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]