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

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

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?

ASKER

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.

SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

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?

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.

ASKER

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 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

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.

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

ASKER

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

ASKER

man dhcpcd
No manual entry for dhcpcd

ASKER

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

ASKER

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.

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 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.

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.

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?

ASKER

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?

ASKER

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 ..

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.

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

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.

ASKER

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

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.

ASKER

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...

ASKER

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.

ASKER

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?

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

Cyclops3590

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