You were right. There was no route to the router. I added
/sbin/route add -host 207.234.111.65 dev eth0.
I still am not able to ping the gateway from the debian linux box, although
I can from a windows one, so have decided to do another debian 2.2
installation on yet another box, so I can know what has been done from the
beginning. In the meantime, I'll read up on the various man pages and get a
better grasp on what I'm doing. Thanks again for the help.
Jake
>From: Clayton Weaver <cgweav@eskimo.com>
>To: Jake Brooks <digimix@hotmail.com>
>Subject: Re: can't contact router
>Date: Tue, 4 Jul 2000 09:56:37 -0700 (PDT)
>
>
>Drilling down through the network boot scripts, just getting networking
>up, once the kernel finds your ethernet card at bootup and has the
>driver loaded for it, with non-defective card and cable, comes down
>to these commands for a non-dynamic-ip setup (no dhcp or bootp):
>
>#!/bin/sh
>
># add localhost and route for it; route command is directly from the
># route man page
>
>/sbin/ifconfig lo 127.0.0.1
>/sbin/route add -net 127.0.0.0
>
># examples below for NETMASK, etc match IPADDR example for host address
>
>IPADDR=[your host ip address] # example: 192.168.1.1
>NETMASK=[your netmask] # example: 255.255.255.0
>NETWORK=[your subnet network number] # example: 192.168.1.0
>BROADCAST=[broadcast address for your subnet] # example:192.1.168.255
>GATEWAY=[host ip address of router]
>
>/sbin/ifconfig eth0 ${IPADDR} broadcast ${BROADCAST} netmask ${NETMASK}
>
># route for your subnet
>
>/sbin/route add -net ${NETWORK} netmask ${NETMASK} dev eth0
>
># route to router
>
>/sbin/route add -host ${GATEWAY} dev eth0
>
># route for all other subnets (uses host route to router)
>
>/sbin/route add default gw ${GATEWAY} metric 1
>
>## end script
>
>That's all you need for a simple setup. Note: there is no ipchains
>firewall there, so you have no particular security beyond what tcpwrappers
>provides for programs compiled to use it or started from inetd.conf
>(inetd.conf uses tcpwrappers, /etc/hosts.deny and /etc/hosts.allow).
>Don't use this in place of your normal network boot script any longer
>than it takes to test the network.
>
>To figure out subnets, netmasks and broadcast addresses if you don't
>already know it at the bit level, get the 4 .pdf files at the
>following URL. The first one is the basics that you need to get
>host ip, subnet, netmask, and broadcast addresses to match, save
>the others for future reference (in case the URL ever disappears):
>
><http://www.3com.com/nsc/501302s.html>
>
>--
>
>Basic Bootup notes: with systems using sysvinit (the vast majority of
>linux systems), everything starts from /etc/inittab, which the init
>process (first process created by the kernel) reads and executes.
>
>man init
>man inittab
>
>The various network scripts, full-time persistent daemons like inetd,
>and login console interface handlers ("gettys"), maybe xdm or some
>equivalent system-wide X-windows server manager, and so on are started
>by init using the specifications in /etc/inittab.
>
>After you have inittab down, read these:
>
>man inetd
>man inetd.conf
>
>This is the "internet superserver", a daemon that listens on various ports
>and hands off an accepted connection to some other server program that
>handles that port (like a web server, smtp email server, etc). It's
>purpose is to not need every network service daemon to be suspended
>individually in memory all of the time, listening for connections.
>Instead, only the inetd process does the listening for a whole slew of
>network servers, starting each on demand to service connections on each
>server's assigned port number (port numbers from /etc/services).
>
>/etc/inetd.conf determines what ports inetd listens to and what program
>with what options it hands off the connection to. It has a helper program
>called "tcpd" (from tcpwrappers security package) that does the security
>check against /etc/hosts.allow, /etc/hosts.deny, and /etc/hosts.equiv,
>does a reverse dns query to see if the ip address and hostname of the
>remote system requesting the connection match, and so on. tcpd can be in
>the inetd.conf command for a particular server under as itself, with
>the real server name following as the next token on the inetd.conf line,
>or it can be renamed to "in.[server_name]", and it knows
>to call "server_name" after validating the connection by checking it's
>argv[0]. It has a compiled in path for where to find "server_name" (the
>real network server for a particular service) in that case.
>
>tcpd doesn't have to be there, inetd can run "server_name" directly
>without having tcpd do the security check in between inetd accepting
>the connection and running server_name. But if the line in /etc/inetd.conf
>for that server does not have "tcpd" but does have "in.[server_name]",
>then that "in.*" name is probably really tcpd renamed (a bizarre method to
>cut down the length of lines in inetd.conf, I guess).
>
>I always skip that and put both tcpd and the real daemon name right into
>the inetd.conf command for how to handle connections on a particular port
>(if called as itself, tcpd looks through the rest of it's arguments to
>find the real server filename), so it's not confusing what's going on if
>someone comes along later and looks at my /etc/inetd.conf file, and people
>don't wonder why all of these different "in.[server_name]" files in
>/usr/sbin are all the same size (i.e. why are the ftp daemon, the smtp
>daemon, and the telnet daemon the exact same file; "because those are
>actually all tcpd, and the real daemons are elsewhere in some
>subdirectory" is not a satisfactory explanation for *why* someone did
>this).
>
>--
>
>Re: original subject (router connect)
>
>There is one other possible problem that comes up on some networks
>even if your network config on your own host is correct, which
>is routers blocking icmp packets and breaking path mtu discovery
>(protocol packet size negotiation between hosts).
>
>Following is a post discussing it with a URL for a document with
>an in-depth explanation of the problem:
>
>---old message on problem with routers blocking icmp---
>
>From miquels@cistron.nl Thu May 18 14:04:40 2000
>From: Miquel van Smoorenburg <miquels@cistron.nl>
>Date: 18 May 2000 06:34:04 GMT
>To: linux-net@vger.rutgers.edu
>Subject: Re: Unbelievable HTTP!
>
>In article
><cistron.Pine.LNX.4.20.0005171932140.1226-100000@blackjesus.async.com.br>,
>Christian Robottom Reis <kiko@async.com.br> wrote:
>
> >I rather think now this isn't a masquerading problem at all. I have no
> >idea, actually what it is. From an internal (masqueraded) box, I issue:
>[...]
>
> >* Which means an HTTP HEAD is coming back fine. However, when I try and
> >issue a
>
> >GET / HTTP/1.0
> >Host: nfs.sourceforge.net
>
> >(... time passes)
>
> >* I'm left hung (left this on for minutes with nothing ever coming back),
> >for no reason. Nothing ever hits my incoming interface again.
>
>Sounds like Path MTU discovery problems. Did you enable
>/proc/sys/net/ipv4/ip_always_defrag on the NAT/masq host ?
>
>If that isnt' the problem some in-between gateway or router might be
>filtering ICMP packets. I've heard that even hotmail did/does this
>on their firewall, which is a bad, bad idea. See
>http://www.worldgate.com/~marcs/mtu/
>
>If that is the case, turning off path mtu discovery on the client
>is the only solution (through /proc/sys/net/ipv4/ip_no_pmtu_disc)
>
>Mike.
>-
>
>---end old message---
>
>
>Note: ping used icmp packets, too.
>
>Good luck,
>
>Clayton Weaver
><mailto:cgweav@eskimo.com>
>(Seattle)
>
>"Everybody's ignorant, just in different subjects." Will Rogers
>
>
>
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.rutgers.edu
