Welcome to Linux Forums! With a comprehensive Linux Forum, information on various types of Linux software and many Linux Reviews articles, we have all the knowledge you need a click away, or accessible via our knowledgeable members.
Find the answer to your Linux question:
Site Navigation
Linux Forums
Linux Articles
Product Showcase
Linux Downloads
Linux Hosting
Free Magazines
Job Board
IRC Chat
RSS Feeds
Free Publications

Dr. UN*X gets an email from Adrian saying that he recently added a second DSL line and he wants remote sites to be able to connect to his system using either DSL lines.Read on and see Dr. UN*X's answer to Adrian.
Two networks = twice as much fun Dear Dr. UN*X,

I am currently using my Linux box as a server on the Internet, and it's all working fine. The installer program configured the network interface for me. I am currently using a single DSL line but now I have added a second line and I want remote sites to be able to connect to my system using either DSL line.

I have already installed a second network card, but the system does not see it. I checked the card maker's site and there are no Linux drivers for it!

I don't need to do anything fancy (yet) like load balancing, I just want to be able to support two outside IP addresses.

Where do I go from here?


Well Adrian,

You have three main issues to address here. First, you need to get the system to recognize your new hardware. Second, you need to configure the interface as a network connection. Third, (the hard part) you will need to use an advanced routing system call 'iproute2' to support the two lines correctly.

Working with iproute2 is fairly involved so I will deal with the basic hardware and network issues this time and save iproute2 for my column.

The hardware

Many distributions have a program that runs at boot time to detect new hardware; Redhat and its kin use 'kudzu'. Ubuntu and some other Debian derivatives use 'discover'. But since you are asking this question, I assume your system does not have any such support; we will figure it out ourselves. Other readers, I think you will find some of the tools presented here interesting even if your system has automatic detection.

Personally, I disable hardware detection on my servers for two reasons. I don't want the delay at boot, and I don't want the hardware configuration to change without my direct attention.

Though there are many hardware manufacturers who do provide Linux drivers these days, more frequently you will find they do not. This is not as bad as it would seem. There are hundreds of network cards out there, but there are only a few manufacturers of the chipsets that go on them. That means that your network card is almost certainly built with a chipset that your Linux distro already supports. It's possible that you have an oddball card with special unsupported features but unlikely, especially if it's relatively new.

The real trick here is figuring out which driver module to load.

Linux is based on a "monolithic kernel"; the kernel is the main program that stays in memory at all times to perform all basic operating system functions. Drivers for devices such as network cards are implemented as modules. Modules can be compiled right into the kernel, but modern general purpose Linux distributions come with the network drivers compiled as separate, loadable modules; these can be loaded (and unloaded) after the system has booted. By only loading the modules you need for your configuration, the system conserves memory space. No reboots are required to load or remove modules, so lots of kernel reconfiguration can happen seamlessly on running systems.

What chipset do you have?

If you know what you are looking for, you can read the data right off the chips themselve but since you are beginner this is probably the last thing you should try. Besides, the board is installed and your computer is running already, right?

Reading the description from the box the board came in would be a better path. You want the manufacturer name and the model number, such as "Netgear FA-311". Having this information lets you look up what you need online. But even if you got a bare board at a rummage sale you can still press ahead by asking the board to tell you about itself. Every PCI card has model information embedded in it.

Before we go any further, I should mention here that if you have installed a second card based on the same chipset as the first, they will share the same driver. You can stop now if this is the case. When the system booted up, it will have found the new card and written out a log message. Look for it now with this command:

dmesg | grep eth1

This command pipes output of command 'dmesg' into a 'grep' command which searches for the string 'eth1'. (The device name for the first card is eth0, the second is eth1, and so on.) If you are lucky you will see a line starting with 'eth1:', for instance

eth1: ADMtek Comet rev 17 at 0xf800, 00:02:2A:B8:23:D7, IRQ 10.

This means that a driver for the second ethernet interface (/dev/eth1) is already loaded and you can skip to the next section.

Using lspci

If your system has the 'pciutils' package installed (if not you should install it now) you can type "lspci". Output on one of my older servers with 2 network interfaces looks like this:

00:00.0 Host bridge: Intel Corp. 440LX/EX - 82443LX/EX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corp. 440LX/EX - 82443LX/EX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:0d.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01)
00:0e.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 model NC100 (rev 11)
00:10.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 02)

The last two lines tell me this server has a Linksys card and an Intel Ethernet Pro 100.

Behind the scenes, lspci reads a table maintained by the kernel called /proc/bus/pci/devices. You can dump out that file with 'cat /proc/bus/pci/devices'. There are bits of potentially useful information here in the last column if you don't have lspci.

Now that you have an idea of what kind of board you have, check the "Linux Ethernet Howto" available at "The Linux Documentation Project" or possibly the network page at Scyld. (Links are in the resources section below.) By the way, it's a good idea to read these docs before you buy new hardware! You can learn what to look for to get the best card for your application.

You will probably find an entry for your card; if not, there is additional information in the "howto" on identifying PCI cards too. Let's say that I want to set up the Linksys card in this server. Based on the entry in the "howto" my guess is that it is a 'tulip'-based card.

Now, Linux is wonderful, but I should mention that you could lock up your system by messing around with loading and unloading kernel modules, so you probably want to proceed with caution here. Don't do this when the server is being used to print your paycheck.

{mospagebreak title=Chipset revealed}

Chipset revealed

Using the command 'lsmod', you can see what modules are already loaded.

Here is output from lsmod on my sample system

# lsmod
Module Size Used by Not tainted
sd_mod 10316 0 (autoclean) (unused)
scsi_mod 86068 1 (autoclean) [sd_mod]
i2c-dev 3492 0 (unused)
i2c-core 12228 0 [i2c-dev]
ipt_state 504 3 (autoclean)
ip_conntrack 19044 0 (autoclean) [ipt_state]
iptable_filter 1644 1 (autoclean)
ip_tables 11776 2 [ipt_state iptable_filter]
8139too 12776 1
crc32 2848 0 [tulip 8139too]
eepro100 18548 1
mii 2144 0 [8139too eepro100]
raid1 12688 3

To load the 'tulip' module, type the command 'modprobe tulip'. In classic UNIX fashion, this command gives no feedback if it works, only if it fails.

Trying to load a module for which there is no network card installed does not hurt anything (in my experience). Modprobe will load the module, the module will look for hardware, and if it does not find anything it will exit with an error like "init_module: No such device".

Success just gives you another command line prompt, but some useful output will be written to the kernel log file, which you can list by typing 'dmesg'; the last few lines of output are the interesting ones; on my system after loading the tulip driver I see this:

Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
PCI: Found IRQ 10 for device 00:0e.0
tulip0: MII transceiver #1 config 3100 status 7849 advertising 05e1.
tulip0: MII transceiver #2 config 1000 status 7849 advertising 05e1.
tulip0: MII transceiver #3 config 1000 status 7849 advertising 05e1.
tulip0: MII transceiver #4 config 1000 status 7849 advertising 05e1.
eth1: ADMtek Comet rev 17 at 0xf800, 00:02:2A:B8:23:D7, IRQ 10.

The first line identifies the module itself and the subsequent ones are the output it generated as it probed for ethernet cards and initialized itself. The good news is the line starting with 'eth1'. This means the card is now available as network device /dev/eth1. Success!

Once you have figured out which driver you need to have loaded, you have to arrange for it to load every time it is needed after you reboot the system. You do this by adding line(s) to the modprobe configuration file (Alas, this config file goes by different names on different distributions and sometimes even different releases of the same distro. A common name is /etc/modprobe.conf, and /etc/modules.conf is another one. On Debian-based systems, look in the /etc/modutils/ directory.)

In my example, I'd see the eepro100 line for the Intel EtherPro card and add another after it, like this:

alias eth0 eepro100
alias eth1 tulip

Each 'alias' line associates a device (in this case /dev/eth0 and /dev/eth1) with a particular driver, so that when the system tries to configure a given device using its device name, the module system will be able to automatically find the right driver and load it.

Using the module loader, on reboot the system won't automatically load the unless you reference it from your network configuration. That's your next step. (You can force loading of modules at boot but that is another story. You don't need to do that for network drivers.)

Now we configure the network interface

Now that you have configured your system to load the right driver for your card, you have to configure the network interface.

Distros vary a lot in how they support configuration of a network interface. Most have some kind of text- or desktop-based control panel for doing network configuration. But again, it's more instructive to lift the hood and look inside. If you learn what's going on inside, you can debug the system much more easily.

In your case you are adding a second interface using another DSL line, so what you want to do is copy the existing setup for the first interface and then edit it.

The systems that I have worked with fall into two camps, Redhat and Debian.

Redhat-like systems

This includes Mandriva and Trustix, among others. SuSe is similar.

The Redhat (and similar) systems keep things in /etc/sysconfig. The 'network' file defines the primary interface and gateway (usually Internet router). Then in /etc/sysconfig/network-scripts, you will find an individual file for each interface. As a starting point I'd suggest not touching /etc/sysconfig/network. Go into /etc/sysconfig/network-scripts and copy the eth0 file, and edit it to support your new interface. (SuSE uses the same idea but files are moved around. Can't have things to simple.)

This is what a typical network file looks like:

# cd /etc/sysconfig
# cat network

Here are commands to create and edit the file for your new interface:

cd /etc/sysconfig/network-scripts
cp ifcfg-eth0 ifcfg-eth1 # Copy the existing interface config file
gedit ifcfg-eth1 # (or use whatever text editor you want)

You have to change the file as appropriate for your needs; in your case, using a second DSL line, the interface should be able to get an IP address from the DSL gateway, so you can leave it set to dynamic addressing.

DEVICE=eth0 # All I'd have to do is change this line to read "eth1"

This includes Ubuntu, which is the desktop software I am using right now.

Debian-based systems keep all the networking settings in files in the directory /etc/network/. You will want to edit the interfaces file, and add a new block there to describe the new interface.

These are the commands to edit the file...

# cd /etc/network
# gedit interfaces

...and these are the lines in the file

# The primary network interface
iface eth0 inet dhcp

# Added these lines to activate second network interface on 20 Feb 2006
iface eth1 inet dhcp
Activating the new interface

Turning on and off just the new interface can be done with 'ifup eth1' and 'ifdown eth1' respectively. Output from these commands varies on different distros; mine gives lots of feedback, some give none. Either way after running either command, you can look at the current settings by running the command 'ifconfig eth1'. You will want to make sure the interface got an IP address from the DSL router after running 'ifup', so look for the 'inet addr' line. If the address line is missing, DHCP failed. Check cabling and make sure your new DSL provider actually uses DHCP to provide the address. More details than this are really beyond the scope of this column. See the resources section below for more info.

Here is the output for a functioning interface.

# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:04:75:C1:CB:4A
inet addr: Bcast: Mask:
inet6 addr: fe80::204:75ff:fec1:cb4a/64 Scope:Link
RX packets:1749454 errors:0 dropped:0 overruns:0 frame:0
TX packets:1185618 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1660257798 (1.5 GiB) TX bytes:364994034 (348.0 MiB)
Interrupt:11 Base address:0x1000
{mospagebreak title=Test the completed setup} Test the completed setup.

Without rebooting, you can shutdown and restart the complete networking subsystem with these commands from the console. (Doing the 'stop' will cut you off if you are logged in remotely! If you think this is blatantly obvious, you probably have not done it yet. Be careful.)

/etc/init.d/networking stop
/etc/init.d/networking start

You can the use 'ifconfig' by itself to see the state of all available network interfaces. You should see eth0, eth1, and lo. 'Lo' is used internally. If you don't see all three, recheck your configuration files and check the system console, the output of the 'dmesg' command and contents of the log file /var/log/messages for errors.

Once you have everything working here, it's a good idea to reboot the system to make sure everything comes up properly. There are other services that can be affected drastically by changing the state of the network, (for example, your firewall) and you can't really know if it will all come back online correctly without doing a reboot to test it.

Where does that leave us?

You want to have two connections to the Internet. At this point, you have two interfaces but the simple, default routing that is set up will still route all traffic between your system over the old interface on eth0.

Unfortunately, there is no simple one-liner configuration to make the second interface work the way you want it to. Linux will have set up direct routes for the eth1 address space so for example, you can ping your new DSL router if you know the right address.) But, packets coming in from the Internet on the new DSL line right now will come in on eth0 and then be routed out eth0. This is wrong and most often this will fail. You need to use iproute2. That's the topic for my next column.

Final notes: Finding all modules

Q. How can I tell exactly what network modules are available on my system?

A. You can use the command 'modprobe -l'. This lists the entire filenames; on my system that's 546 lines of output. You can 'grep' for things, for example, listing only network drivers with "modprobe -l |Howto|Howto| grep drivers/net
many more lines deleted

This output is from a system based on a 2.4 kernel; on a newer, 2.6 kernel the filenames end in '.ko' instead of '.o'. Either way when loading the module, you only use the short name with modprobe, that is, you will use 'modprobe tulip' not 'modprobe tulip.o' or or 'modprobe tulip.ko'.

Knowing the names of the modules, you could in theory load each one and then look at the output of dmesg ('dmesg | tail') each time to see if anything hopeful happened but it would probably be faster to install a hardware discovery system like 'kudzu' or 'discover'.

Note on superuser mode

To execute the critical commands in this article, you have to haves superuser-level permission.

On most systems, you can temporarily grant yourself superuser permissions by typing 'su' and then entering the superuser password when prompted; the prompt will change to a '#'.

On an Ubuntu system, instead of using 'su' mode, you prefix each command with 'sudo', for example when you want to start a network interface you type "sudo ifup eth1" instead of just "ifup eth1". {mospagebreak title=Resources}

Resources The Linux Documentation Project, where you will find:
Linux Hardware Compatibility Howto
Linux Ethernet Howto
Linux Network Administrators Guide

You can really geek out at http://www.scyld.com/network.html; Scyld was founded by Don Becker, who wrote most of the Linux ethernet drivers.

For the impatient, the source for information on iproute2: Linux Advanced Routing and Traffic Control where you will find the
Rate This Article: poor excellent
Comments about this article
minor improvement regarding the test of
writen by: izolan on 2006-03-06 02:42:42
snippet from the article: Test the completed setup. Without rebooting, you can shutdown and restart the complete networking subsystem with these commands from the console. (Doing the 'stop' will cut you off if you are logged in remotely! If you think this is blatantly obvious, you probably have not done it yet. Be careful.) /etc/init.d/networking stop /etc/init.d/networking start ================= beter solution is ============= /etc/init.d/networking restart By doing it in this way, you can restart the networking on the REMOTE machine without a fear to be cut off
RE: minor improvement regarding the test of written by izolan:
Remotely Restarting Network Services
writen by: Ron on 2006-03-06 07:31:51
Please note I've only tested on a Fedora Core 3 system and I'm not guaranteeing this will work for everyone. On a fedora core based system you can issue the command: service network restart to stop and start the networking services. I tested that command from an ssh session and I didn't even get disconnected! you can also chain the commands together: #> /etc/init.d/networking stop; /etc/init.d/networking start I would recommend remotely logging in, starting a screen session and chaining the commands together so that even if you get disconnected when the network stops, the commands will complete by virtue of the screen session. As I say, its not a fully tested solution, please use at your own risk.
RE: Remotely Restarting Network Services written by Ron:
Strange Domain name
writen by: Allan Registos on 2006-05-06 22:59:40
Hello Dr. UN*X I have been using Fedora Core 4 for sometime now and got to learn a lot of its features. I am also investigating the features of CentOS and now im using it at the time of this writing. But before all this, we are using a Windows NT 4.0 sp6 server with Exchange 5.5 as an Internet sharing and Email server. The problem is our Windows has been sending a lot of Spams, I think it was infected as a ghost PC. This triggers me to use an alternative OS that is stable and more secure than windows. Aside from the spam generated by the NT server by using a fake address and real address by some employees here, it uses the name in the from field. When I tried to scan my our IP addresses here, the local IP registered this strange name: indus.cmie.ernet.in !!! .in shows that its from India. And when I run linux and run this command: netstat -tap I can still this domain as affiliated with my local/internal IP: tcp 0 0 indus.cmie.ernet.in:domain *:* LISTEN 4345/named tcp 0 0 *:* LISTEN 4345/named I am confused why this was so... Thank you in advance...
RE: Strange Domain name written by Allan Registos:
Reboot Linux Client on Network Disconnec
writen by: Iz on 2008-10-13 21:25:27
Question: Is there a way to force a reboot on a remote linux client when connection with the server is lost/broken? Background: Server sends IP Video to Linux client. When power is lost or network goes down, the Linux client continues broadcasting the last server transmission which is BAD. If I could restart the Linux client it would cease to transmit the outdated info and be ready to post updated data when power/network connectivity is restored. Iz
RE: Reboot Linux Client on Network Disconnec written by Iz:
load balance!!
writen by: juder on 2008-10-14 05:23:36
hello friends i need your assistance! my network is going down always. Am monitoring the network on a server installled on with kubuntu-unix as the operating system. These are my troubles. 1: How can i reduce the size of the /var/log folder its showing that its 100% 2:i want to delete /var contents and copy them to another location its also showing that its 100% Please i will be happy to hear from you this work is urgent
RE: load balance!! written by juder:

Comment title: * please do not put your response text here