Solved

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

Posted on 2006-11-09
36
2,116 Views
Last Modified: 2008-01-09
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        *                          255.255.255.0      U            0         0        0      eth0
169.254.0.0           *                          255.255.0.0         U            0         0        0      eth0
default                 aaa.bbb.ccc.1         0.0.0.0                 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?:
GATEWAY0=aaa.bbb.ccc.1
NETMASK0=255.255.255.0
ADDRESS0=aaa.bbb.ccc.19


   
0
Comment
Question by:GPrentice00
  • 13
  • 12
  • 7
  • +1
36 Comments
 
LVL 34

Accepted Solution

by:
Duncan Roe earned 250 total points
ID: 17909953
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 169.254.0.0 with netmask of 255.255.0.0?
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.
0
 
LVL 6

Author Comment

by:GPrentice00
ID: 17910050
I'll hit the man pages right now... but to answer what I can
I have no idea what the 169.254.0.0 netmask 255.255.0.0   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?
0
 
LVL 6

Author Comment

by:GPrentice00
ID: 17910238
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
169.24.0.0/16 dev eth0 scope link
default via aaa.bbb.ccc.1 dev eth0


I just tried now
ifup lo  
on a hunch, and the
route
table now has the lo assigned to 169.24.0.0  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.




0
 
LVL 5

Assisted Solution

by:kyle_in_taiwan
kyle_in_taiwan earned 250 total points
ID: 17912322
The lo interface should be pointing to 127.0.0.1, 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 169.254.0.0 entry pretty much guarantees you're not going to connect;  see here for more info:

http://www.redhat.com/archives/fedora-list/2004-April/msg03572.html
http://www.issociate.de/board/post/187145/169.254.0.0_and_Zone_Alarm.html

What i took away from the discussion is that 169.254.0.0 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):

DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.220.195
NETWORK=192.168.220.0
BROADCAST=192.168.220.255
NETMASK=255.255.255.0
GATEWAY=192.168.220.1
ONBOOT=yes
TYPE=Ethernet

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.

0
 
LVL 5

Expert Comment

by:kyle_in_taiwan
ID: 17912342
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?  
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 17912566
Do not emove the .0 entries! Any address ending .0 is a *network*, as distinct from a *host*.
Hunt down where 169.254.0.0/16 is, and replace it with 127.0.0.0/8 (it may be expressed as 169.254.0.0 netmask 255.255.0.0 or just 169.254.0.0). And in any case, it shouldn't be associated with eth0.
0
 
LVL 6

Author Comment

by:GPrentice00
ID: 17914255
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
0
 
LVL 5

Expert Comment

by:kyle_in_taiwan
ID: 17914405
Unless you've altered a configuration file, the loopback should get reset to 127.0.0.1 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 127.0.0.1 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:

/etc/sysconfig/network-scripts/ifcfg-lo

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

DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback


0
 
LVL 5

Expert Comment

by:kyle_in_taiwan
ID: 17914707
Whups.  Typed too quickly;   you should do this:

$ ifconfig lo down
$ ifconfig lo address 127.0.0.1 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 169.254.0.0 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.

First:
$ 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.


0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 17920527
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
0
 
LVL 6

Author Comment

by:GPrentice00
ID: 17931670
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: 255.255.255.0
       inet6addr: <stuff>  Scope:Link
       UP BROADCAST RUNNING MULTICAST  MTU: 1500  Metric:1
        etc

lo    Link encap: Local loopback
      inet addr: 127.0.0.1  Mask: 255.0.0.0
      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:

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=aaa.bbb.ccc.19
NETMASK=255.255.255.0
GATEWAY=aaa.bbb.ccc.1

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

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 255.255.255.0 gateway aaa.bbb.ccc.1
produces: address: Host name lookup failure

0
 
LVL 6

Author Comment

by:GPrentice00
ID: 17931681
man dhcpcd
No manual entry for dhcpcd
0
 
LVL 6

Author Comment

by:GPrentice00
ID: 17931722
ifconfig eth0 address aaa.bbb.ccc.19 netmask 255.255.255.0 gateway aaa.bbb.ccc.1 up
indeed, the up was typed when I did the test, just not in my previous-to-previous post
0
 
LVL 6

Author Comment

by:GPrentice00
ID: 17931957
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.

0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 17933848
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.
0
 
LVL 5

Expert Comment

by:kyle_in_taiwan
ID: 17935941
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 0.0.0.0, and try adding the "broacast" flag as 255.255.255.255.

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.

0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 5

Expert Comment

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

RED_DEV=eth1
RED_DRIVER=8139too
RED_DRIVER_OPTIONS=
RED_DISPLAYDRIVER=8139too
RED_DHCP_HOSTNAME=_
RED_ADDRESS=0.0.0.0
RED_NETMASK=0.0.0.0
RED_TYPE=PPPOE
RED_NETADDRESS=0.0.0.0
RED_BROADCAST=255.255.255.255
DNS1=168.95.192.1
DNS2=168.95.1.1
DEFAULT_GATEWAY=192.168.1.1


Again:  most of that you almost certainly don't need.  But perhaps it will give you some more ideas.
0
 
LVL 5

Expert Comment

by:kyle_in_taiwan
ID: 17935970
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?  
0
 
LVL 6

Author Comment

by:GPrentice00
ID: 17936050
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?



0
 
LVL 6

Author Comment

by:GPrentice00
ID: 17936062
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 255.255.255.0

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 ..
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 17936471
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.
0
 
LVL 5

Expert Comment

by:kyle_in_taiwan
ID: 17936687
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.

Basically:

* /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:

http://www.debian.org/doc/manuals/network-administrator/ch-tcpip.html

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

     # /sbin/route add -net 192.168.50.0
     # /sbin/route
     Kernel IP routing table
     Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
     127.0.0.0       *               255.0.0.0       U     0      0        2 lo
     192.168.50.0    *               255.255.255.0   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 192.158.50.0 netmask 255.255.255.192

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 192.168.50.1 on our network, which is a router for the network 172.20.0.0 (a class B network). The following options to the route command specify this:

     # route add -net 172.20.0.0 gw 192.168.50.1

Since our routing table already contains an entry telling us how to send information to 192.168.50.1 (it's on our local network), any traffic for the remote network 172.20.0.0 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 192.168.50.254 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 192.168.23.254

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
     127.0.0.0       *               255.0.0.0       U     0      0        2 lo
     192.168.50.0    *               255.255.255.0   U     0      0      137 eth0
     172.20.0.0      192.168.50.1    255.255.0.0     UG    1      0        7 eth0
     default         192.168.50.254  0.0.0.0         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 192.168.50.1, which is a router (or gateway) for that network

   4. Finally, we specify that the machine 192.168.50.254 will deal with all other IP traffic
0
 
LVL 5

Expert Comment

by:kyle_in_taiwan
ID: 17936747
So i *think* you're supposed to be doing this:

$ ifdown-eh0
$ ifconfig eth0 address aaa.bbb.ccc.19 netmask 255.255.255.0 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
     127.0.0.0       *               255.0.0.0       U     0      0        2 lo
     aaa.bbb.ccc.0    *               255.255.255.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.
0
 
LVL 6

Author Comment

by:GPrentice00
ID: 17950130
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)
127.0.0.1               aaa.bbb.ccc.17              localhost
aaa.bbb.ccc.17  

----------

when I execute the route  command in that version, I get the following output:
aaa.bbb.ccc.0          *                  255.255.255.0  u  0   0   0  eth0
default              aaa.bbb.ccc.1       0.0.0.0            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 255.255.255.0
         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
0
 
LVL 5

Expert Comment

by:kyle_in_taiwan
ID: 17953234
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.

0
 
LVL 5

Expert Comment

by:kyle_in_taiwan
ID: 17953246
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.
0
 
LVL 6

Author Comment

by:GPrentice00
ID: 17953328
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...

0
 
LVL 6

Author Comment

by:GPrentice00
ID: 17966031
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.

0
 
LVL 5

Expert Comment

by:kyle_in_taiwan
ID: 17970746
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.
0
 
LVL 6

Author Comment

by:GPrentice00
ID: 18085427
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?
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 18263101
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
0
 
LVL 25

Expert Comment

by:Cyclops3590
ID: 18360893
duncan_roe,

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.

Cyclops3590
EE Cleanup Volunteer
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 18360982
Having re-read them all, I think the first from each is as good as any.
0

Featured Post

How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

Join & Write a Comment

I have seen several blogs and forum entries elsewhere state that because NTFS volumes do not support linux ownership or permissions, they cannot be used for anonymous ftp upload through the vsftpd program.   IT can be done and here's how to get i…
Note: for this to work properly you need to use a Cross-Over network cable. 1. Connect both servers S1 and S2 on the second network slots respectively. Note that you can use the 1st slots but usually these would be occupied by the Service Provide…
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now