/sbin/ip route add ..... is tossing error, keeping me off-line

Have finally (unsure how) got network card active, but am having a problem with network configuration that prevents it properly executing.  
Linux Redhat : Enterprise Linux Desktop Release 4  {cat /etc/redhat-release}
2.6.9-5.EL {uname -r}

New install, haven't gotten do do anything fun with it yet other than try to activate the network card, so its not a box that has been changed from a previous working state, upgraded, etc.  But since the system failed to pick up the network cards from the get-go, I fear there may be 'residue' somewhere in the system that is intefering, or a file missing that should have been set as part of its autoconfiguration at install.

I'm trying the static IP assignment because it at least runs through a bit more, but would be perfectly happy to see either static or dynamic IP work now.

ifup eth0  has been returning
RTNETLINK answers: Invalid argument

so I stuck some echo statments into the ifup, which pointed to ifup-post, which pointed to ifup-routes, where it has been isolated to be thrown at this command:

/sbin/ip route add $line

and at the time of tossing, $line is equal to
aaa.bbb.ccc.19/24 via aaa.bbb.ccc.1 dev eth0

route  dumps out

destination             gateway                genmask             flags        metric   ref    use   iface
aaa.bbb.ccc.0        *                      U            0         0        0      eth0           *                         U            0         0        0      eth0
default                 aaa.bbb.ccc.1                 UG         0         0       0       eth0

all computers on my floor of the building are aaa.bbb.ccc.#, and I have aaa.bbb.ccc.19 reserved for this use as a static ip; the gateway is aaa.bbb.ccc.1    dhcp server is  aaa.bbb.ppp.10  dns server is  aaa.bbb.ppp.10 and aaa.bbb.qqq.11 according to windows networks

It looks pretty clear to me (now) that the problem is trying to add info to the routing file, it doesn't like the format of the command issued.  Is there something syntaxtically incorrect about that add string to make it think a parameter is missing or formatted wrong?  Is the information it is pulling from the files it is reading (The error occurs when reading in the file  /etc/sysconfig/network-scripts/route-eth0   ) incorrect in some way, due to a fubar earlier that isn't changing back?

Is the script missing the insertion of quotes around something?  I am pretty content having narrowed it down to this point after this time, but just as stuck as ever (although, still googling at 90 miles-per-hour and trying to take a stab at it)

route-eth0 file contents, in case I can manually modify to make correct?:

Who is Participating?

Improve company productivity with a Business Account.Sign Up

Duncan RoeConnect With a Mentor Software DeveloperCommented:
Well done with the echoes, you're on the right track. Instead of  echo statements, you can put "set -x" as the first command in the script. Then it will echo each command as it executes. anyway, you're down to troubleshooting the /sbin/ip invocation. "route" as I advised is the old way. Type "man 8 ip" to read about how to invoke ip which can do pretty-much all network management actions, replacing the old "route" & "ifconfig" commands. Actually it's a full bnf description of the args to ip. You still need ifconfig to show packets received & sent though.
To see output in a format compatible with "ip route", instead of typing "route", type "ip route list" (assuming /sbin is in your PATH: put it there if it's not).
In your "ip route list", you should see an entry for the loopback interface, like

1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

I assume you just missed it out - if it's not there then that needs to be rectified.

route-eth0 isn't a script: it's a data file used by a script.
What is with netmask of
I think ip route add aaa.bbb.ccc.19/24 via aaa.bbb.ccc.1 dev eth0 fails because aaa.bbb.ccc.19/24 is not a network description. Looks to me like you injected your static IP in the wrong place. I suspect ADDRESS0 used to be aaa.bbb.ccc.0 and you should put it back to being that - that's a network address. Somehow it's found its way into the route table anyway. That begs the question of where you put your static address instead.
I have to go now - have a good read of that man page.
GPrentice00Author Commented:
I'll hit the man pages right now... but to answer what I can
I have no idea what the netmask   is doing there - I know that IP subnet is one that windows uses under various "found networking, but couldn't get an ip per-se, so.." scenarios.  Probably a hangover from all the other flipflop trials with getting the card recognized?  

The settings have come from the   netconfig   run where I specific the parameters in the prompts, but at this point, I'm willing to say that the program is evil and incorrect.

It seems like it would be worth trying to find where the route table entries are coming from and purge some of them out?  I don't know what aaa.bbb.ccc.0 as an ip address would be worth - is a 0 entry a non-real IP but a special marker?

I'm going to consider trying the same 'debugging' approach to paint things into a corner on the dynamic mode setup too, since it is bound to go through a different pathway but likely error due to a similar reason.

As you're almost confirming with your concern, it seems like there is crap leftover from incorrect settings that is getting in the way of correct settings being applied?
GPrentice00Author Commented:
loopback isn't in the output
ip route list

aaa.bbb.ccc.0/24 dev eth0  proto kernel scope link src aaa.bbb.ccc.19 dev eth0 scope link
default via aaa.bbb.ccc.1 dev eth0

I just tried now
ifup lo  
on a hunch, and the
table now has the lo assigned to  interface, the rest is the same

Hopefully that provides a hint to someone as to which files I need to manually modify, I'm running into brick walls trying to find them to play with, but will continue playing for a little while longer.  If I have files that are persisting bad data and at bootup / reload are contaminating things...  or persisting the wrong data.

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

kyle_in_taiwanConnect With a Mentor Commented:
The lo interface should be pointing to, and the only time i've ever seen it change to something different is when it was misconfigured by a user (i.e. -- me or my co-workers).  Without a question, you should change that back.

The entry pretty much guarantees you're not going to connect;  see here for more info:


What i took away from the discussion is that is an automatically assigned address, which means that you've got a dhcp-enabled device that can't connect to a server.  So what your routing table looks like is that a static address device -- configured improperly, so it can't connect to the network -- and then on top of that you've also got the same device looking for a dhcp server.  With that kind of conflict, my guess is that you're not going to get any connection at all until you eliminate one of those connection processes.

Regardless of whether my guess is right or wrong, this:

>>can't ping any sites in our local area that my laptop beside it is getting <2ms on thru windows, one being a hardware printerserver...

suggests specifically that the problem is an improperly configured network address, gateway, or netmask -- or all three.  Coupled with the rtnetlink error, my money says that you've got a configuration error in your /etc/sysconfig/network-scripts/if-eth0 file.  Mine looks like this (as you can see, for a static address):


That's a little overkill, there, but it works.  So far as your connection is concerned, that should have been the *only* file you edited to give the interface a static address.

Looking on the other thread, it seemed as if you had tried dhcp by simply going through the netconfig script, but automatic scripts are very conservative in what they do and don't change, and a manual misconfiguration somewhere means it's possible the process has been altered in ways netconfig can't help.

Finally, i've been hesitant to say anything, but -- did you enter "aaa.bbb.ccc.19" as the actual address?  And "aaa.bbb.ccc.1" as the actual gateway address?  

The aaa.bbb.ccc.# should be -- AFAIK (and if i learn something here i'll be happy to hear it), the entries in your config files should only ever be actual numbers between 0 and 255.  

I had presumed up until now that you were simply editing the files for security's sake, but after looking at your routing table up there it appears that you actually have the ifcfg-eth0 file configured with those letters in place of what should be IP addresses.  Am i wrong about that?  
Duncan RoeSoftware DeveloperCommented:
Do not emove the .0 entries! Any address ending .0 is a *network*, as distinct from a *host*.
Hunt down where is, and replace it with (it may be expressed as netmask or just And in any case, it shouldn't be associated with eth0.
GPrentice00Author Commented:
aaa.bbb.ccc    is not literal - it is my attempt to premask the real ip numbers that I know to be not part of the equations needed to solve the problems.
The numbers in those spots are real and correct.

And since I have had to TYPE everything on a different computer from the one that I am working on, I have been doing that aaa bbb replacement in real time, when reporting tables, file configs, etc...

Hunting down the 169.254.... stuff  is exactly what I had  been trying to do to no avail yesterady.  And I NEED HELP PLEASE in explaining HOW to fix the loopback-adapter thing, I _KNOW_ I need it restored but don't know how to go about doing that.  Its VERY evident that the network is misconfigured, but my experience in configuring linux networks is limited to this and the previous thread.  The only other time was an ubuntu test installation that zipped through everything automatically no problems out of the box, what kind of experience is that going to gain?

I don't know how much time I'll get to poke at this today when I get to work, but I'm going to try
Unless you've altered a configuration file, the loopback should get reset to with a simple reboot.  

If you *have* misconfigured it, then it'd be nice to know where you altered the entry.  ;-)

The ifconfig command is used to configure addresses and such on the fly:

$ ifconfig lo address up

should be what you need for an on-the-fly reconfiguration.  

The file where these things get set is in the same place as the eth0 config script -- here:


And it should look like this (cut-and-paste from my own):

# If you're having problems with gated making a martian,
# you can change this to something else (, for example)

Whups.  Typed too quickly;   you should do this:

$ ifconfig lo down
$ ifconfig lo address up

in order to re-address the loopback.  Sorry about that (and my confusing typos up above, as well).

Now, as i said above:

the is unimportant except as an error message telling you that your NIC is broadcasting but cannot find the network.  You should be trying to get it replaced with the proper address, not worrying about where it's going or how to preserve it.   It's either your static connection telling you that you've entered the wrong address/netmask/gateway info, or your dhcp daemon telling you that it can't find the server.  Regardless, it's an address reserved by the IANA (not Microsoft) for use when no network can be found (the links i gave you above explain that).  

If this is the first time you've ever seen it, then what's *probably* happening is you've got the NIC configured for a dhcp connection and it can't find the network that you've got it configured for;  the reason it can't find it is one of two things:  your static address is making it impossible to connect in kernel-space (i don't know anything at all about kernel internals, but knowing what i do about NIC configuration i feel pretty confident about the assertion), or you've got the address information misconfigured on both the dhcp and static config files, and thus neither can connect.

I wouldn't suggest using netconfig just because it's really not necessary and it's easier to troubleshoot and configure from the command line.  Also, if i'm right about the above guess, then it's not going to help you on this because its use would be what caused your NIC to get misconfigured for both static as well as dhcp.  

You need to crack open the ifcfg-eth0 file and tell us what's there;  as long as you don't post your password and user id, i really don't think you need to worry about security issues when discussing a local network.  Even if we know that information, we wouldn't be able to do much of anything with it unless we first cracked a server or client, by which time we'd already have it anyway.  i suggest you just post it here and let us look at it.  My guess -- again, just a guess -- is that the problem is currently found in that file.  

Regardless, there is a simple way to go about troubleshooting this:  just use the ifconfig command.

$ ifconfig -a

to see all the different connections your machine is attempting.  Next, i'd suggest this:

$ ifconfig eth0 down                 // as well as any eth1, 2, eth0:1 or whatever else you've got.

and then:
$ ifconfig eth0 address XXXXXXXX netmask XXXXXXXXXX gateway XXXXXXXX up

And then just change the addresses and such until you find the right combination.  In my experience these are the only three things needed for a static address (like i said:  my eth0 file up there is overkill). Still, if you're curious or suspicious or whatever -- and you want to play with more settings, like hardware addresses and the like -- then just check out the ifconfig man-page and pick what you think might be useful.

Duncan RoeSoftware DeveloperCommented:
You can try invoking dhcpcd from the command line and see what goes wrong (you'll need to be root). "man dhcpcd" gives you the options: you might want to ru it in test mode (-T) and you'll certainly want verbose logging (-d).
You can watch the action by running tcpdump
GPrentice00Author Commented:
ifconfig -a
indicates  eth0, lo and sit0

eth0 Link encap:Ethernet HWaddr:<stuff here>
       inet addr: aaa.bbb.ccc.19   bcase: aaa.bbb.ccc.255   mask:
       inet6addr: <stuff>  Scope:Link

lo    Link encap: Local loopback
      inet addr:  Mask:
      inetaddr : ::1/128 Scope:Host
       UP LOOPBACK RUNNING  MTUL16436  Metric :1
      rx/tx packets =same large number, 0 dropped, etc...
      rx/tx bytes 2.3MiB each...

The contents of my ifcfg-lo  match exactly that of ^^^^^^ above posted, the contents of my ifcfg-eth0 are:


I added
NETWORK=aaa.bbb.ccc.0     and
BROADCAST=aaa.bbb.ccc.255  and

just in case, again, aaa/bbb/ccc being real network numbers.
This is NOT a local network in the sense that my numbers are 192.168.x.x types, they are real exposed IPs when all is said and done.

the ifconfig eth0 down  then
ifconfig eth0 address aaa.bbb.ccc.19 netmask gateway aaa.bbb.ccc.1
produces: address: Host name lookup failure

GPrentice00Author Commented:
man dhcpcd
No manual entry for dhcpcd
GPrentice00Author Commented:
ifconfig eth0 address aaa.bbb.ccc.19 netmask gateway aaa.bbb.ccc.1 up
indeed, the up was typed when I did the test, just not in my previous-to-previous post
GPrentice00Author Commented:
okay, just taking a look at my bootlog after rebooting, something looks strange (it still has the string-dumps in it from my debugging echos) : it is trying to execute the command to add ip route using this string:

aaa.bbb.ccc.0/24 via aaa.bbb.ccc.19 dev eth0

that should be via my gateway address should it not?

Somewhere where there was an entry with =aaa.bbb.ccc.19 when I changed it to ..ccc.0 it switched the string from aaa.bbb.ccc.19/24 via aaa.bbb.ccc.1 dev eth0      My bootlogs show an abrupt change from that previous string to the new string, where both are changed simultaneously.

Duncan RoeSoftware DeveloperCommented:
man dhcpcd works for me, or I wouldn't have suggested it. But then I have Slackware, not RedHat. Just so you know, dhcpcd stands for Dynamic Host Configuration Protocol Daemon. It should have configured everything for you - network number, host number and route. Probably the server would have created a DNS entry for you as well. A Google for "dhcpcd man" produces heaps of pages advising you to "man dhcpcd" so RHE not providing it is a real deficiency (unless you asked it not to install man pages). Anyway you can read an HTML version at http://www.die.net/doc/linux/man/man8/dhcpcd.8.html.
Enterprise Linux Desktop is supposed to "just work" and is not friendly to fiddle with. If you have made configuration changes that you can no longer track down, (and I don't like to suggest this) you might be best off to reinstall and start from scratch. If it doesn't work, contact RHE support - someone's paying for it so why not use it. (Except, you'd maybe better check with whoever supplied you with RHE).
In the meantime, do experiment with dhcpcd.
I echo duncan's assessment, in that getting dhcpd to work would be a good means to troubleshoot the setup.  However, i'm of the opinion that you've either altered some config file somehwere and subsequently forgotten about it, or that your config files have gotten some badly configured lines that will affect any autoconfig scripts that you might use.

I do *not* think you need to do a re-install.  Regardless of how well RHE works out of the box, it's still a configurable and "fixable" system.  Moreover, we're just talking about configuring internet connections here, not taking apart binary scripts, or hacking kernel modules.

Finally, you've confused me:  are you trying to connect to a firewall-protected LAN, or not?

If not, then you should try the ifconfig command without the "netmask" parameter;  change it to, and try adding the "broacast" flag as

But i'm quite confused;  didn't you say you're on a university's local network?   At any rate, what the error message suggests -- "host name lookup failure" -- along with this line: UP BROADCAST RUNNING MULTICAST -- indicates that this is almost certainly a problem with the values you've entered in the eth0 configuration file.

Here's the config file from my firewall, which is also a Linux box.  It connects via ADSL to the local phone company:


Again:  most of that you almost certainly don't need.  But perhaps it will give you some more ideas.
One more thing:  you said above that your computer's IPTables were all disabled.  So are you saying that you're trying to connect the computer to an open internet connection without any firewall whatsoever?  
GPrentice00Author Commented:
glad I checked mail before heading to bed - gives me a shot to get some info out there and some more feedback...
working backwards, YES, NO FIREWALL setup YET on the system - we had no plans to be idiotic and foolish and leave it with no firewall, but given that sooo many things can go wrong with firewalll configurations to get in the way of having a working setup, the priority was on getting the network connection up first, THEN, activate a firewall.  Since we've never yet managed to get a network connection...

Before leaving work tonight, I tried a few more times to configure it for dynamic ip, but the system tosses a failure on bootup and disables the ethernet card, it seems to only partially like it with the nonfunctional static assignment.


Not trying to connect to firewall protected LAN.  University block is aaa.bbb.xxx.xxx  all IPs handed out on my floor of the building are aaa.bbb.ccc.xxx, with a handful of IPs reserved as static.  Although I had constantly tried pinging the aaa.bbb.ccc.19 address on my windows machines, just in case some arse stole my assigned IP (it has happened before, my printerserver ip has been stolen by other devices on the floor, and I was allowed to tear someone a new one), but its always been available (apparently) in my testings the past many days.

I'd love to get the dynamic IP working as well, just to be absolutely sure in case there IS some IP stealer out there hiding.


I found before I left that there was an entry in I think it was the route-eth0 file that had the gateway at .19 inatead of .1, and when I changed it, and rebooted, the log returned to the more expected aaa.bbb.ccc.0/24 via aaa.bbb.ccc.1 dev eth0, but no change.


I really do think, and fully agree, that it must be a contaminating setting left behind somewhere - I've tried to locate the various files involved in storing eth settings, hoping that it might be possible to just wipe all the data out of them completely, then run the various configuration programs again.  But running them when there is some crap entry left behind that doesn't get touched by a configurer...  

confg-eth0, route-eth0 ... help me find the others?

GPrentice00Author Commented:
As for all my numbers that I'm using for the network, I'm not only pulling them from  ipconfig /all on my windows machine next to the linux box Im working on, but also pulling them fully from memory, since I have configured many of the windows machines with dynamic configs easily enough, and also plugged in the static ips on a few others.  

Unless there is something obvious about linux that is different from windows, and the university is specifying the addr  aaa.bbb.ccc.1 as the gateway for windows machines, but everyone who uses linux KNOWS that the .1 must be a .254 for it to work...

The dchp for the windows machines is an  aaa.bbb.ppp.qqq  address.  Windows subnet mask is

The windows settings is all I have to go on, those windows numbers is all I have to go on.  If linux needs to use different numbers from the system in order to pull off the same thing, then I'll have a long wait trying to requisition those numbers from someone...

If linux is using the term "address" to where windows uses "network subnet", and "gateway" in linux is "dns server" in windows, then there is an issue - but if the terms from a windows  ipconfig   output mean the same in linux, we should be set.  Of course, where those values need to be set in the config files ..
Duncan RoeSoftware DeveloperCommented:
A dns server in linux is the same as in windows. Sometimes it is co-located with the dhcp server, that's for the net admin to choose. Linux uses whatever gateway you configure - at home I use .3.
I meant for you to run dhcpcd from an interactive command line, not reboot as you do seem to have a broken startup script somewhere.
The main difference between Linux and Windows terminology is that Linux conforms to standards and Windows' was invented for marketing purposes.  ;-)  Basically, though, they generally mean the same thing but with one big difference:  Linux is more precise, and so has more terms.  "Gateway" isn't exactly the same in Linux as it is in Windows, and i think this is where the problem lies.  So first --

--   try eliminating the "gateway" entry in your config file and see if you can bring your interface up onto the network and ping individual addresses (use "$ ifdown eth0 $ ifup eth0, since this flushes any prior configurations as well).   Your interface says it's up and connected, but if you have it directed to a gateway that isn't willing to serve your connection then you're not going to be able to connect to anything.

I'm still confused about your internet setup, though:  you say you're on a local subnet for your particular floor of the University, but it's not operating behind a firewall?  So is it the case that your local "subnet" is actually a direct connection to the internet?  So are you saying it's something like this:

WWW <==> Subnet Gateway aaa.bbb.ccc.1 <==> Local network // Your computer

I had presumed it's like this:

WWW <==> University Servers <==>  Subnet Servers  <==>  Local Network // Your Computer

What it seems to me is happening is that you have the wrong addresses for your local subnet, and haven't properly configured the necessary routing and gateway information.  So now that you've gone over the config files and re-checked your addresses, my suggestion is that you ask more detailed questions about your local subnet's configuration and specifically at what addresses you can find the subnet routers/gateways *and* the LAN gateways to the outside internet.


* /etc/resolv.conf is going to be where you place the nameserver addresses, but that's probably not the problem right now (and is usually automatically detected)
* you need a "gateway" address to specify every router on your local network;  this isn't always necessary with Windows machines because they love to make things "automagic" (even when it often breaks).
* you need to know the specific addresses for the machines which serve as routers;  usually these end in either XXX.XXX.XXX.1 ==OR== XXX.XXX.XXX.254.   It may be that your network's routers actually end in 254. You'll probably need to get the addresses from someone (and my guess is that this is the source of your problem)
* You don't necessarily need to add the "gateway" configuration to your local subnet router;  you can simply add the route into the routing tables and it should automatically take care of itself.  Because you've specified the "gateway" in your config script, my guess is that the routing table is looking in the wrong place and so you can't connect.

So here is a detailed explanation from the Debian pages;  look at the entry "Basic IP Routing", towards the middle:


Assuming we have set up our machine to be, with a default class C netmask, the following command will add a routing table entry for our local network:

     # /sbin/route add -net
     # /sbin/route
     Kernel IP routing table
     Destination     Gateway         Genmask         Flags Metric Ref    Use Iface       *            U     0      0        2 lo    *        U     0      0      137 eth0

If you are using a non-standard netmask, this can be specified as a command line option to the route command:

     /sbin/route add -net netmask

A command like one of the above would be sufficient if our TCP/IP network consisted of just a single network, not connected to anywhere else. However, normally a IP-based network consists of more than one network. In order to route IP packets from your machines to these other networks, you must specify gateway hosts (often called routers) which deal with sending information to these other networks. There are in general two possibilities.

The first possibility is that we want to route IP packets to a specific network, and we know the address of a gateway host or router which deals with information for that network. Suppose, for example, that there is a machine on our network, which is a router for the network (a class B network). The following options to the route command specify this:

     # route add -net gw

Since our routing table already contains an entry telling us how to send information to (it's on our local network), any traffic for the remote network is now sent to that machine, which deals with it appropriately.

The other possibility is that we use a certain gateway as a default route - a route used for all IP packets which don't match other rules in our routing table. If, for example, the machine with IP address is our router to the rest of the world (the Internet, for example), we use the route command as follows:

     # /sbin/route add default gw

At this stage, let's have another look at our routing table:

     # /sbin/route
     Kernel IP routing table
     Destination     Gateway         Genmask         Flags Metric Ref    Use Iface       *            U     0      0        2 lo    *        U     0      0      137 eth0     UG    1      0        7 eth0
     default         UG    1      0       36 eth0

Going through the above table one line at a time:

   1. We first specify a loopback address for all 127.*.*.* addresses

   2. Next, we specify how to reach all machines on our local network, identified as 192.168.50.*

   3. Next, we give a route to all machines on the network (172.20.*.*) connected to the machine, which is a router (or gateway) for that network

   4. Finally, we specify that the machine will deal with all other IP traffic
So i *think* you're supposed to be doing this:

$ ifdown-eh0
$ ifconfig eth0 address aaa.bbb.ccc.19 netmask broadcast aaa.bbb.ccc.255 up

1)  Then check the routing table, and it should look like this:
$ route                                                  
Kernel IP routing table
     Destination     Gateway         Genmask         Flags Metric Ref    Use Iface       *            U     0      0        2 lo
     aaa.bbb.ccc.0    *        U     0      0      137 eth0

2)  Next add the route to the greater LAN:

$ route add -net xxx.xxx.0.0 gw aaa.bbb.ccc.1  // <== should this be 254?  Something different?

...but you need to be sure about those addresses.

3)  Finally, you need to add the 'default' route -- which is what router is used when an address is called that doesn't match anything else in the routing table.  Do it like this:

$ route add default gw xxx.xxx.xxx.254       // <== Again, you need to ask for this address.

Step 2 might not be necessary.  Because you're on a LAN, step 3 is certainly necessary.  But the problem is that you appear to have gotten hold of the wrong addresses.
GPrentice00Author Commented:
haven't abandoned, just not been in the same area as the computer for a while, and have a few mins today to check in.

One of the 'problems' that still remains a problem is that if I do a route command, I STILL NEVER GET an  lo  entry
If this is somehow  a big cause of all the problems, I need to know how to get the lo entry to show up when I turn on the computer each time - - I would have expected loopback related stuff to be added initially, esp since the loopback stuff is all checked during boot before the network is.  If the absence of an lo entry there is a red herring, maybe...

I did manage to examine a neighboring lab (this floor) linux setup, which was using fixed ip addressing aaa.bbb.ccc.17 but its a very different flavor of linux setup, I couldn't find nearly any of the files from here.  A debian setup...  it has a lot of things wrong with it, but the network was working correctly.

I found one file I recognized to be networking related, and have masked the contents
resolve.conf file:

search myuniversitydomain.ca
nameserver aaa.bbb.ppp.11
nameserver aaa.bbb.qqq.10

those nameservers are the same as windows configurations use.

the hosts file looked like this (masked)               aaa.bbb.ccc.17              localhost


when I execute the route  command in that version, I get the following output:
aaa.bbb.ccc.0          *          u  0   0   0  eth0
default              aaa.bbb.ccc.1            ug  0   0  0  eth0

(note, no lo entry in their linux version either ...)  thats it, the whole output.

and, its ifconfig  dump loking at the eth0(grabbed primarily for showing its ip numbers, the rest just proves it works)

eth0  link encap: Ethernet   hwaddr xx:xx:xx:xx:xx:xx  
         inet addr: aaa.bbb.ccc.17  bcast aaa.bbb.ccc.255  mask
         up broadcast running multicast mtu:1500 metric:1
         rx packets (big number) 0 0 0 0 for rest of parameters
         tx packets (big number) 0 0 0 0 for rest of parameters
     collisions 0  txquelen 1000
    rx byetes (304mib) tx bytes xx (1.8gib)
     interrup: 17   memory: feafc000-0

Could not find any of the same types of files I was hoping to find, but hopefully the outputs from here help to cement and concrete something, clarify something, etc?  Can someone get enough information out of what I outputted to make sense of the network configuration I'm in - gateways, routing, etc?  Route output seems rather simple to me, and it works on that box
O.k. -- good.  

Debian setups use these files:  your /etc/sysconfig/ifcfg-eth0 file is going to be located in the /etc/network/interfaces file.  You can crack that open and you'll find exactly the settings you need listed according to each interface;  because the file contains all interfaces, the format is a little different.  But the tags used to identify each of the flags are all the same.

I don't have a loopback entry on any of my routing tables, either, so don't worry about that.

The file you posted above is the resolv.conf file, and that's nothing mroe than where your computer stores the dns server addresses.  It typically gets set automatically, so you shouldn't need to worry about it;  sometimes you need to edit it, though, but for now you can't even find a route to the network so forget about it.

Have you found the addresses to the routers (subnet gateway + internet gateway) you need?  Like i said above:  that seems to be the problem here.   You are working with the right files and the right tools, but you aren't putting in the proper addresses.

And the routing information you show -- returned by the "route" command, above -- is the same as mine, and my connection works fine.  Again, your problem is certainly that you don't have a route established to the right routers / gateways.
GPrentice00Author Commented:
considering I havent' gotten any reply from the guy who would be able to give me the specific information yet, its good to know that somewhere buried in that debian system the rest of the real numbers are there.  It was an exciting idea that I could steal their settings, then a smack to find virtually nothing in common with the filesystem and no idea what to look for
Doubt I'll have another crack at their system for a couple days, nor have an opportunity to work on mine anyways, so stay tuned for the next update...

GPrentice00Author Commented:
Interesting news - their debian system is going schitzo, no mouse recognized, keyboard
rrrrrrrrrrrrrrrrrrrrrrrrrreaccccccctttinnnggg liiiiiiiiiiiiikeeeee            ttttttttttttttttthis making it pretty hard to do things, but, on their system , cat interfaces outputs:

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
#the loopback interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

iface dsl-provider inet ppp
provider dsl-provider

thats it

Not exactly the information I was anticipating seeing in that file...

And now, with the risk that their system appears to be disintegrating (it was running a bit slow and strangely the other day when I was looking at the files the first time, they said, thinking nothing of it...) I sense the universe is out to get me

:D  now, I'm told, that while just sitting there on, their computer started typing a page of ~~~~~  all by itself, but they're not blaming me, thats good.

That's quite strange;  they've got it set up for dhcp over what looks like a dialup dsl connection;  while it's certainly possible that the bootscripts are set up to just skip the dsl and start probing the network for a dhcp assignment, it's quite clear that the machine is *not* set up for a static connection.

Of course, if you want to set your computer up for dhcp, then you just copy those settings into your ifcfg-eth0 file -- like duncan was suggesting above.  You can go ahead and try that, and you shouldn't need any other configuration files other than the ifcfg-eth0.

The routing tables off the Debian box also indicate a direct connection with the aaa.bbb.ccc.1 gateway, with no other routes listed, so that's obviously serving as their connection to the wider network.  Thus, all you should need is to get connected to that same gateway and be done with it.

I'm running out of ideas, but i did just remember something about my own setup from a long while back:  when i wanted to run a static connection through my own firewall, i needed to configure the server with the hardware address of my NIC in order to complete the connection.  It may be that you cannot connect because of server-side misconfiguration / rejection.
GPrentice00Author Commented:
Sorry Guys, forgot this was still open

We kinda put the computer on hold for a while, and have been focused on a different suite of tools on another machine - I'm planning on taking the machine home with me during our christmas break and try setting it up on my own, fully controlled network to find at least one working condition that I can have more control over, possibly with some alternate network cards, but until then, we don't have further time to look at it.

Someone propose a closure here - problem wasn't resolved, but all of the methods here would be worth others looking at?
Duncan RoeSoftware DeveloperCommented:
Suggest split kyle_in_taiwan  /  duncan_roe because we did all we could to help him, and our advice was sound. On that basis, it would be a shame to delete the Q - but if you do then I suggest no refund

Would be able to do me a favor and pick out which two you think should be accepted.  There were a lot of comments with a lot of good information, but am not really able to figure out which pertain most to the issue, thanks.

EE Cleanup Volunteer
Duncan RoeSoftware DeveloperCommented:
Having re-read them all, I think the first from each is as good as any.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.