[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: route table behind router [ solved ]



To recap:
It started with me thinking I had a problem with my routing table.
    The setup is like so:
cox cable-----NetGear router------------Windows box
                             \----------Debian box
    I can access the windows box through the router via smbclient.
Even with IPtables that are ACCEPT, ACCEPT, ACCEPT, ... neither lynx
or Firefox can access the inet though they can access the router.

On Thu, Feb 10, 2011 at 10:21:16AM +0100, Pascal Hambourg wrote:
> Web browers are poor tools when it comes to check IP connectivity.
> Try ping and traceroute instead, with both host names and numeric IP
> addresses as targets.
> What about /etc/resolv.conf ?

ping and traceroute both show I have access to the web though the output
of traceroute for several different addresses shows:
 1  router (192.168.1.1)  0.475 ms  0.405 ms  0.353 ms
 2  10.157.32.1 (10.157.32.1)  8.750 ms  7.200 ms  7.998 ms
Is the 10.157.32.1 address normal?
This demonstrated that /etc/resolv.conf was not the problem.

On Thu, Feb 10, 2011 at 05:59:15AM -0500, Paul Cartwright wrote:
> paulandcilla:/var/log# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
> 0.0.0.0         192.168.10.1    0.0.0.0         UG    0      0        0 eth0
> make sure it is using the gateway you think it is.

Which assured me the problem was not in my route table.

He also sent me his /etc/network/interfaces showing his uses a 
static IP address which inspired me to explore setting mine static
and doing away with dhclient. This worked and simplified my system.
It required configuring the router to assign the same IP address to
my computer based on Mac address of my ethernet card.

On Thu, 10 Feb 2011, Camale?n wrote:
> Some cable providers (at least in Spain) tweak their cable modems to
> allow only one computer to browse the web (by means of "filters" that
> restrict the access to only one MAC address). To avoid this, there are
> routers that can "clone" the MAC address so other computers in the
> network can access the web.

My Netgear router was setup to respond with the Windows PCs MAC.
I set it to use the Linux box's MAC and lost all inet access so set it
to the router's MAC then called Cox (the ISP) and got them to reset
on their end and got their assurance that I should be able to connect 
with either box.

On Thu, Feb 10, 2011 at 09:02:32PM +0200, Andrei Popescu wrote:
> No, but maybe the output of 'host google.com' and 'wget google.com' can
> help diagnose.

root@/deb40a:~> wget -v google.com
--16:28:14--  http://google.com/  => `google.com/index.html'
Resolving google.com... 74.125.227.20, 74.125.227.16, 74.125.227.17, ...
Connecting to google.com[74.125.227.20]:80... failed: Connection timed out.
Connecting to google.com[74.125.227.16]:80... failed: Connection timed out.
Connecting to google.com[74.125.227.17]:80... failed: Connection timed out.

On Thu, Feb 10, 2011 at 08:06:07PM +0100, Pascal Hambourg wrote:
> An HTTP proxy setting ?

I looked at both the Win2K system and the ppp setup but found no
evidence of proxy usage.
On Sat, 12 Feb 2011, Andrei Popescu wrote:
> Hmm, is the router using PPPoE to connect to your ISP? Try this:
> ifconfig eth0 mtu 1400

I tried this but no joy.
 
On Sat, Feb 12, 2011 at 12:45:39PM +0100, Pascal Hambourg wrote:
> MTU issues should only affect "big" packets containing data, not the
> establishement of the connection. But it is worth the try. Adapt the
> interface name to the one connected to the router.
> 
> At this point, I have two ideas : either a problem with TCP connections
> or specifically with HTTP connections. I would first try to connect to
> other TCP-based services such as SMTP, POP3, FTP... If it fails too,
> then the problem is with TCP, likely with some TCP option not supported
> by the router or the ISP. The usual suspects are window scaling,
> timestamps, ECN, SACK, which can be enabled or disabled via sysctl
> variables in /proc/sys/net/ipv4/. Try to enable and disable each of them
> and see what happens.
> 
> You can also use tcpdump to capture the packets on the interface while
> trying to connect.
> Another useful tool is tcptraceroute, it can help to see where something
> wrong happens.

root@/deb40a:~> echo 0 > /proc/sys/net/ipv4/tcp_ecn

Now fetchmail and exim work and I can get urls in lynx and firefox.
Problem solved.

My thanks to all who offered suggestions.

Mike
-- 
Satisfied user of Linux since 1997.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


Reply to: