Tuesday, August 11, 2009

How to configure NFS


On Redhat systems

Create the configuration,
vi /etc/exports
for example,
/path/to *(ro,no_root_squash)
Apply,
service nfs start
Defenitely if you like,
chkconfig portmap on
chkconfig nfs on




################################################################################






HowTo configure NFS

1. Introduction

The Network File System is certainly one of the most widely used network services. Network file system (NFS) is based on the Remote procedure call. It allows the client to automount and therefore, transparently access the remote file systems on the network.

2. Scenario

In this scenario we are going to export the file system from the linuxconfig.org (IP address 10.1.1.200) host and mount it on linuxconfig.local(IP address 10.1.1.100).

3. Prerequisites

At this point, we assume that the NFS service daemon is already installed on your system, including portmap daemon on which NFS depends on. Moreover, your system needs to support the NFS file system.
$ cat /proc/filesystems 

NFS file system supported

NFS daemon should be listening on both standard ports 2049 and portmap on port 111.

NFS daemon port 2049 portmap port 111
Another way to check if NFS is functioning, is to use the rpcinfo command.

# rpcinfo -p

You should get a response/output similar to one below:

check if NFS is functioning

4. Server export file

All NFS server exports need to be defined in /etc/exports file.

4.1. Most common exports options

Here are a couple of the most common export techniques and options:
/home/nfs/ 10.1.1.100(rw,sync) export /home/nfs directory for host with IP 10.1.1.100 with read, write permissions, and synchronized mode
/home/nfs/ 10.1.1.0/24(ro,sync) export /home/nfs directory for network 10.1.1.0 netmask 255.255.255.0 with read only permissions and synchronized mode
/home/nfs/ 10.1.1.100(rw,sync) 10.1.1.10(ro,sync) export /home/nfs directory for host with IP 10.1.1.100 with read, write permissions, synchronized mode, and also export /home/nfs directory for hosts with IP 10.1.1.10 with read only permissions and synchronized mode
/home/nfs/ 10.1.1.100(rw,sync,no_root_squash) export /home/nfs directory for host with IP 10.1.1.100 with read, write permissions, synchronized mode and the remote root user will not be treated as a root but as a default nfs user.
/home/nfs/ *(ro,sync) export /home/nfs directory for any host with a read only permission and synchronized mode
/home/nfs/ *.linuxconfig.org(ro,sync) export /home/nfs directory for any host within linuxconfig.org domain with a read only permission and synchronized mode
/home/nfs/ foobar(rw,sync) export /home/nfs directory for hostname foobar with read, write permissions and synchronized mode

4.2. Edit exports file

Open up your favorite text editor, for example, vim and edit /etc/exports file and add line /home/nfs/ *(ro,sync) to export /home/nfs directory for any host with read only permissions. edit NFS exports file Be sure that the directory you export by NFS exists. You can also create a file inside the /home/nfs directory which will help you troubleshoot once you mount this file system remotely.
# touch /home/nfs/test_file 

4.3. Restart NFS daemon

Once you edit /etc/exports file you need to restart NFS daemon to apply changes in the /etc/exports file. Depending on your Linux distribution, the restarting of NFS may differ. Debian users:
# /etc/init.d/nfs-kernel-server restart 
Redhat users
# /etc/init.d/nfs restart 
If you would, later, decide to add more NFS exports to the /etc/exports file, you will need to either restart NFS daemon or run command exportfs:
# exportfs -ra 

5. Mount remote file system on client

First we need to create a mount point:
# mkdir /home/nfs_local 
If you are sure that the NFS client and mount point are ready, you can run the mount command to the mount exported NFS remote file system:
# mount 10.1.1.200:/home/nfs /home/nfs_local 
In case that you need to specify a type of the filesystem you can do this:
# mount -t nfs 10.1.1.200:/home/nfs /home/nfs_local 
You may get error message
mount: mount to NFS server failed: timed out (retrying). 
This may mean that your server supports higher versions of nfs you need to pass tone extra argument to you nfs client. In this example we use nfs version 3:
# mount -t nfs -o nfsvers=3 10.1.1.200:/home/nfs /home/nfs_local 

Mount remote file system on client

Now you should be able to see that the file system is mounted. Notice that the mount command reports that the filesystem is mounted as "read and write", although you can see that it provides a "read only" permission.

6. Configure automount

To make this completely transparent to end users, you can automount the NFS file system every time a user boots a PC, or you can also use PAM modules to mount, once a user logs in with a proper username and password. In this situation just edit /etc/fstab to mount system automatically during a system boot. You can use your favorite editor and create new line like this:
10.1.1.200:/home/nfs /home/nfs_local/ nfs defaults 0 0 
in /etc/fstab or
# echo "10.1.1.200:/home/nfs /home/nfs_local/ nfs defaults 0 0" >> /etc/fstab 
Configure NFS automount

7. Conclusion

The Network File System comes with tons of export options. What has been shown here, just barely scratches the surface of NFS. Please visit Linux NFS-HOWTO hosted by linux documentation project or NFS homepage for more details.

What is port map why is it required ?

What is port map why is it required ?

Linux uses a combination of kernel-level support and continuously running daemon processes to provide NFS file sharing, however, NFS support must be enabled in the Linux kernel in order to function. NFS uses Remote Procedure Calls (RPC) to route requests between clients and servers, meaning that the portmap service must be enabled and active at the proper runlevels for NFS communication to occur. Working with portmap, the following processes ensure that a given NFS connection is allowed and may proceed without error:

NFS and portmap

NFS relies upon remote procedure calls (RPC) to function. The portmap service is required to map RPC requests to the correct services. RPC processes notify portmap when they start, revealing the port number they are monitoring and the RPC program numbers they expect to serve. The client system then contacts portmap on the server with a particular RPC program number. portmap then redirects the client to the proper port number to communicate with its intended service.

Because RPC-based services rely on portmap to make all connections with incoming client requests, portmap must be available before any of these services start. If, for some reason, the portmap service unexpectedly quits, restart portmap and any services running when it was started.

The portmap service can be used with TCP wrappers' hosts access files (/etc/hosts.allow and /etc/hosts.deny) to control which remote systems are permitted to use RPC-based services on the server. See Chapter 15 TCP Wrappers and xinetd for more information. Access control rules for portmap will affect all RPC-based services. Alternatively, it is possible to specify each of the NFS RPC daemons to be affected by a particular access control rule. The man pages for rpc.mountd and rpc.statd contain information regarding the precise syntax for these rules.


The rpcinfo command shows each RPC-based service with its port number, RPC program number, version, and IP protocol type (TCP or UDP).


o make sure the proper NFS RPC-based services are enabled for portmap, use the rpcinfo -p command:

  program vers proto   port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 1024 status
100024 1 tcp 1024 status
100011 1 udp 819 rquotad
100011 2 udp 819 rquotad
100005 1 udp 1027 mountd
100005 1 tcp 1106 mountd
100005 2 udp 1027 mountd
100005 2 tcp 1106 mountd
100005 3 udp 1027 mountd
100005 3 tcp 1106 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 1028 nlockmgr
100021 3 udp 1028 nlockmgr
100021 4 udp 1028 nlockmgr

The -p option probes the portmapper on the specified host or defaults to localhost if no specific host is listed. Other options are available from the rpcinfo man page.

From this output, it is apparent that various NFS services are running. If one of the NFS services does not start up correctly, portmap will be unable to map RPC requests from clients for that service to the correct port. In many cases, restarting NFS as root (/sbin/service nfs restart) will cause those service to correctly register with portmap and begin working.

Changing Your MAC Address In Window XP/Vista, Linux And Mac OS X (Sometimes known as MAC spoofing)

Changing Your MAC Address In Window XP/Vista, Linux And Mac OS X
(Sometimes known as MAC spoofing)

First let me explain a few things about MAC addresses. MAC stands for Media Access Control and in a sense the MAC address is a computer's true name on a LAN. An Ethernet MAC address is a six byte number, usually expressed as a twelve digit hexadecimal number (Example: 1AB4C234AB1F).

IPs are translated to MAC address by a protocol called ARP (Address Resolution Protocol). Let's say a computer with and IP of 192.168.1.1 wants to send information to another computer on the LAN that has an IP of 192.168.1.2 . First 192.168.1.1 will send out a broadcast to all stations on the LAN asking who has the IP 192.168.1.2. Then the box that has 192.168.1.2 will respond to 192.168.1.1 with it's MAC address which is cached in 192.168.1.1's ARP table for later use. To put this in Socratic Dialog form (with just a touch of Stallone):

Host 1 (192.168.1.1): Yo everyone on the LAN (FF:FF:FF:FF:FF:FF), who has the IP 192.168.1.2? My MAC is DE:AD:BE:EF:CA:FE so you can respond back to me.

Host 2 (192.168.1.2): Hello DE:AD:BE:EF:CA:FE, I have IP 192.168.1.2 and my MAC address is 12:34:56:78:90:12 so you can send your IP packets to me.

You can see the ARP table of a box by dropping out to a command prompt and typing "arp –a" in Windows or just "arp" in Linux. ARP can also work the other way by a host on the LAN sending its MAC address to another machine on the LAN for preemptive caching unless the host is configured to not accept un-requested ARP replies.

A person might want to change the MAC address of a NIC for many reasons:

  1. To get past MAC address filtering on a router. Valid MAC addresses can be found by sniffing them and then the deviant user could assume the MAC of a valid host. Having two hosts on the same network can cause some network stability problems, but much of the time it's workable. This is one of the reasons why MIC Address filtering on a wireless router is pointless. An attacker can just sniff the MAC address out of the air while in monitor mode and set his WiFi NIC to use it. Interestingly, a lot of hotels use MAC filtering in their "pay to surf" schemes, so this method can be an instant in for cheap skate road warriors.
  2. Sniffing other connections on the network. By assuming another host's MAC as their own they may receive packets not meant for them. However, ARP poisoning is generally a better method than MAC spoofing to accomplish this task.
  3. So as to keep their burned in MAC address out of IDS and security logs, thus keeping deviant behavior from being connected to their hardware. For example, two of the main things a DHCP server logs when it leases an IP to a client is the MAC address and host name. If you have a wireless router look around on it's web interface for where it logs this info. Luckily there are tools to randomize this information (MadMACs).
  4. To pull off a denial of service attack, for instance assuming the MAC of the gateway to a sub net might cause traffic problems. Also, a lot of WiFi routers will lock up if a client tries to connect with the same MAC as the router's BSSID.

Linux

To change your MAC address in Linux (and most *nix system) is easy as pie. All it takes is two easy to script commands:

ifconfig eth0 down hw ether 00:00:00:00:00:01

ifconfig eth0 up

These two little commands would set your eth0 interface to use the MAC 00:00:00:00:00:01. Just plug in the NIC you want to set and the MAC address you want to use into the commands above and your done. Changing your MAC address is one of those things that is much easier to do in Linux then under Windows.

Using the Ethernet Drivers as Modules

Using the Ethernet Drivers as Modules

Most of the linux distributions now ship kernels that have very few drivers built-in. The drivers are instead supplied as a bunch of independent dynamically loadable modules. These modular drivers are typically loaded by the administrator with the modprobe(8) command, or in some cases they are automatically loaded by the kernel through `kerneld' (in 2.0) or `kmod' (in 2.1) which then calls modprobe.

Your particular distribution may offer nice graphical configuration tools for setting up ethernet modules. If possible you should try and use them first. The description that follows here gives information on what underlies any fancy configuration program, and what these programs change.

The information that controls what modules are to be used and what options are supplied to each module is usually stored in the file /etc/modules.conf. The two main options of interest (for ethernet cards) that will be used in this file are alias and options. The modprobe command consults this file for module information.

The actual modules themselves are typically stored in a directory named /lib/modules/`uname -r`/net where the uname -r command gives the kernel version (e.g. 2.0.34). You can look in there to see which module matches your card.

The first thing you need in your modules.conf file is something to tell modprobe what driver to use for the eth0 (and eth1 and...) network interface. You use the alias command for this. For example, if you have an ISA SMC EtherEZ card which uses the smc-ultra.o driver module, you need to alias this driver to eth0 by adding the line:

        alias eth0 smc-ultra

Important Note: The alias above is only used by the module utilities to translate a generic device name (e.g.eth0) into a hardware specific driver module name. When the driver loads, it never even sees this alias; instead it will simply choose the first free ethN (N=0,1,2,...) device name available. Thus, if more than one ethernet module is being loaded, the ethN assigned to the driver by the kernel may or may not be the same as the one given on the alias line, depending on the order in which the modules have been loaded. If you need to ensure that a particular card is given a particular IP address, then read the station address and assign your IP address based upon that. If you are writing your own shell scripts for this, you can just parse the ifconfig output; if using C, then you would use ioctl(ethfd, SIOCGIFHWADDR, &ifreq).

The other thing you may need is an options line indicating what options are to be used with a particular module (or module alias). Continuing with the above example, if you only used the single alias line with no options line, the kernel would warn you (see dmesg) that autoprobing for ISA cards is not a good idea. To get rid of this warning, you would add another line telling the module what I/O base the card is configured to, in this case say the hexidecimal address 0x280 for example.

        options smc-ultra io=0x280

Most ISA modules accept parameters like io=0x340 and irq=12 on the insmod command line. It is REQUIRED or at least STRONGLY ADVISED that you supply these parameters to avoid probing for the card. Unlike PCI and EISA devices, there is no real safe way to do auto-probing for most ISA devices, and so it should be avoided when using drivers as modules.

A list of all the options that each module accepts can be found in the file:

/usr/src/linux/Documentation/networking/net-modules.txt

It is recommended that you read that to find out what options you can use for your particular card. Note that some modules support comma separated value lists for modules that have the capability to handle multiple devices from a single module, such as all the 8390 based drivers, and the PLIP driver. For exmple:


        options 3c503 io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1

The above would have the one module controlling four 3c503 cards, with card 2 and 4 using external transcievers. Don't put spaces around the `=' or commas.

Also note that a busy module can't be removed. That means that you will have to ifconfig eth0 down (shut down the ethernet card) before you can remove the module(s).

The command lsmod will show you what modules are loaded, whether they are in use, and rmmod will remove them.

How do I tell Linux what driver to use?

How do I tell Linux what driver to use?

With most Linux distributions, the drivers exist as loadable modules, which are small binary files that are merged with the operating system at run time. A module gives the operating system (kernel) the information on how to control that particular ethernet card. The name of each module is listed in the heading of the section for each card in this document. Once you know the name of the module, you have to add it to the file /etc/modules.conf so Linux will know what module to load for your card. The syntax is typically as follows.

        alias eth0 module_name
options module_name option1=value1 option2=value2 ...

The options line is typically only needed for older ISA hardware. For multiple card systems, additional lines with eth1, eth2 and so on are usually required.

The module files typically live in the directory /lib/modules/ which is further subdivided by kernel version (use uname -r) and subsystem (in this case net). These are put there by the distribution builder, or by the individual user when they run make modules_install after building their own kernel and modules (see the kernel howto for more details on building your own stuff).

If you build your own kernel, you have the option of having all the drivers merged with the kernel right then and there, rather than existing as separate files. When this is done, the drivers will detect the hardware at boot up. Options to the drivers are supplied by the kernel command line prior to boot (see BootPrompt Howto for more details). The user chooses what drivers are used during the make config step of building the kernel (again see the kernel howto).

What do I need to to get ethernet working?

As a quick overview, you need to:

1) have a plug in ethernet card or motherboard that has ethernet support built in,
2) determine the brand or make and model of the ethernet card or on-board ethernet chip,
3) determine if a linux driver for this model of card/chip does exist,
4) locate and load this driver,
5) check driver output to verify it found your card,
6) set or configure network parameters for the newly detected network interface.

HELP - It doesn't work!

Okay, don't panic. This will lead you through the process of getting things working, even if you have no prior background in linux or ethernet hardware.

First thing you need to do is figure out what model your card is so you can determine if Linux has a driver for that particular card. Different cards typically have different ways of being controlled by the host computer, and the linux driver (if there is one) contains this control information in a format that allows linux to use the card.

If you don't have any manuals or anything of the sort that tell you anything about the card model, then you can try using the lspci utility for obtaining information on the PCI devices in your computer. Doing a cat /proc/pci gives similar (but less) information. For ISA cards, see the section on helping with mystery cards (reference section: Identifying an Unknown Card).

Now that you know what type of card you have, read through the details of your particular card in the card specific section (reference section: Vendor Specific...) which lists in alphabetical order, card manufacturers, individual model numbers and whether it has a linux driver or not. If it lists it as `Not Supported' you can pretty much give up here. If you can't find your card in that list, then check to see if your card manual lists it as being `compatible' with another known card type. For example there are hundreds, if not thousands of different cards made to be compatible with the original Novell NE2000 design.

Assuming you have found out that a linux driver exists for your card, you now have to find it and make use of it. Just because linux has a driver for your card does not mean that it is built into every kernel. (The kernel is the core operating system that is first loaded at boot, and contains drivers for various pieces of hardware, among other things.) Depending on who made the particular linux distribution you are using, there may be only a few pre-built kernels, and a whole bunch of drivers as smaller separate modules, or there may be a whole lot of kernels, covering a vast combination of built-in driver combinations.

Most linux distributions now ship with a bunch of small modules that are the various drivers. The required modules are typically loaded late in the boot process, or on-demand as a driver is needed to access a particualr device. You will need to attach this module to the kernel after it has booted up. See the information that came with your distribution on installing and using modules, along with the module section in this document. ( Using the Ethernet Drivers as Modules)

If you didn't find either a pre-built kernel with your driver, or a module form of the driver, chances are you have a typically uncommon card, and you will have to build your own kernel with that driver included. Once you have linux installed, building a custom kernel is not difficult at all. You essentially answer yes or no to what you want the kernel to contain, and then tell it to build it. There is a Kernel-HowTo that will help you along.

At this point you should have somehow managed to be booting a kernel with your driver built in, or be loading it as a module. About half of the problems people have are related to not having driver loaded one way or another, so you may find things work now.

If it still doesn't work, then you need to verify that the kernel is indeed detecting the card. To do this, you need to type dmesg | more when logged in after the system has booted and all modules have been loaded. This will allow you to review the boot messages that the kernel scrolled up the screen during the boot process. If the card has been detected, you should see somewhere in that list a message from your card's driver that starts with eth0, mentions the driver name and the hardware parameters (interrupt setting, input/output port address, etc) that the card is set for. (Note: At boot, linux lists all the PCI cards installed in the system, regardless of what drivers are available - do not mistake this for the driver detection which comes later!)


If you don't see a driver indentification message like this, then the driver didn't detect your card, and that is why things aren't working. See the FAQ ( The FAQ Section) for what to do if your card is not detected. If you have a NE2000 compatible, there is also some NE2000 specific tips on getting a card detected in the FAQ section as well.


If the card is detected, but the detection message reports some sort of error, like a resource conflict, then the driver probably won't have initialized properly and the card still wont be useable. Most common error messages of this sort are also listed in the FAQ section, along with a solution.


If the detection message seems okay, then double check the card resources reported by the driver against those that the card is physically set for (either by little black jumpers on the card, or by a software utility supplied by the card manufacturer.) These must match exactly. For example, if you have the card jumpered or configured to IRQ 15 and the driver reports IRQ 10 in the boot messages, things will not work. The FAQ section discusses the most common cases of drivers incorrectly detecting the configuration information of various cards.

At this point, you have managed to get you card detected with all the correct parameters, and hopefully everything is working. If not, then you either have a software configuration error, or a hardware configuration error. A software configuration error is not setting up the right network addresses for the ifconfig and route commands, and details of how to do that are fully described in the Network HowTo and the `Network Administrator's Guide' which both probably came on the CD-ROM you installed from.

A hardware configuration error is when some sort of resource conflict or mis-configuration (that the driver didn't detect at boot) stops the card from working properly. This typically can be observed in several different ways. (1) You get an error message when ifconfig tries to open the device for use, such as ``SIOCSFFLAGS: Try again''. (2) The driver reports eth0 error messages (viewed by dmesg | more) or strange inconsistencies for each time it tries to send or receive data. (3) Typing cat /proc/net/dev shows non-zero numbers in one of the errs, drop, fifo, frame or carrier columns for eth0. (4) Typing cat /proc/interrupts shows a zero interrupt count for the card. Most of the typical hardware configuration errors are also discussed in the FAQ section.

Well, if you have got to this point and things still aren't working, read the FAQ section of this document, read the vendor specific section detailing your particular card, and if it still doesn't work then you may have to resort to posting to an appropriate newsgroup for help. If you do post, please detail all relevant information in that post, such as the card brand, the kernel version, the driver boot messages, the output from cat /proc/net/dev, a clear description of the problem, and of course what you have already tried to do in an effort to get things to work.

You would be surprised at how many people post useless things like ``Can someone help me? My ethernet doesn't work.'' and nothing else. Readers of the newsgroups tend to ignore such silly posts, whereas a detailed and informational problem description may allow a `linux-guru' to spot your problem right away. Of course the same holds true when e-mailing a problem report - always provide as much information as possible.

Changing your Network Interface Speed, Duplex or Auto Negotiate settings on Red Hat Linux

Changing your Network Interface Speed, Duplex or Auto Negotiate settings on Red Hat Linux


To set the interface speed, duplex or auto negotiation on Linux system boot up (make settings permanent), you need edit /etc/sysconfig/network-scripts/ifcfg-eth0 file for eth0 interface. This file used by Red Hat enterprise Linux, Fedora core, Cent Os etc.

Open the file:
# vi /etc/sysconfig/network-scripts/ifcfg-eth0

Append following line:
ETHTOOL_OPTS="speed 100 duplex full autoneg off"

Save and close the system. It will set the eth0 device to 100Mbs, full duplex, with the auto negotiation off at boot time. You can simply restart the networking (it will disconnect all ssh or ftp session) or restart the server. Depend upon traffic and load it may take upto 1 minute to setup a new port speed:
# /etc/init.d/network restart

If you want 1000Mbs set line as follows:
ETHTOOL_OPTS="speed 1000 duplex full autoneg off"Update: if above command failed to work for 1000Mbps use following command (see below in comment sections for discussion) :ETHTOOL_OPTS="speed 1000 duplex full autoneg on"

Debian or Ubuntu Linux permanent settings

Under Debian or Ubuntu Linux just create a script as follows:
# vi /etc/init.d/100Mbs
OR
$ sudo vi /etc/init.d/100Mbs
Append following lines:
#!/bin/sh
ETHTOOL="/usr/sbin/ethtool"
DEV="eth0"
SPEED="100 duplex full"
case "$1" in
start)
echo -n "Setting eth0 speed 100 duplex full...";
$ETHTOOL -s $DEV speed $SPEED;
echo " done.";;
stop)
;;
esac
exit 0
Save and close the file. Setup executable permission:
# chmod +x /etc/init.d/100MbsOR$ sudo chmod +x /etc/init.d/100Mbs

Now run script when Debian or Ubuntu Linux boots up. Use update-rc.d command install System-V style init script links:# update-rc.d 100Mbs defaultsOR# sudo update-rc.d 100Mbs defaultsOutput:

 Adding system startup for /etc/init.d/100Mbs ...
/etc/rc0.d/K20100Mbs -> ../init.d/100Mbs
/etc/rc1.d/K20100Mbs -> ../init.d/100Mbs
/etc/rc6.d/K20100Mbs -> ../init.d/100Mbs
/etc/rc2.d/S20100Mbs -> ../init.d/100Mbs
/etc/rc3.d/S20100Mbs -> ../init.d/100Mbs
/etc/rc4.d/S20100Mbs -> ../init.d/100Mbs
/etc/rc5.d/S20100Mbs -> ../init.d/100Mbs

Reboot the system to take effect or just type scrit name:
# /etc/init.d/100Mbs startOR$ sudo /etc/init.d/100Mbs start

How do I change the speed, duplex on for my Ethernet card?

How do I change the speed, duplex on for my Ethernet card?

Linux change the speed and duplex settings of an Ethernet card


Under Linux use mii-tool or ethtool package which allows a Linux sys admin to modify/change and view the negotiated speed of network interface card (NIC) i.e. it is useful for forcing specific Ethernet speed and duplex settings.


Depending on which type of Ethernet card is installed on the system you need to use either mii-tool or ethtool. I recommend installing both and use one of the tool, which will work with your card.

Task: Install mii-tool and ethtool tools

If you are using Debian Linux you can install both of these package with following command:# apt-get install ethtool net-toolsIf you are using Red Hat Enterprise Linux you can install both of these package with following command:# up2date ethtool net-toolsIf you are using Fedora Core Linux you can install both of these package with following command:# yum install ethtool net-tools

Task: Get speed and other information for eth0

Type following command as root user:
# ethtool eth0Output:

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

Or use mii-tool command as follows:# mii-tool eth0Output:

eth0: negotiated 100baseTx-FD flow-control, link ok

Task: Change the speed and duplex settings

Setup eth0 negotiated speed with mii-tool
Disable autonegotiation, and force the MII to either 100baseTx-FD, 100baseTx-HD, 10baseT-FD, or 10baseT-HD:# mii-tool -F 100baseTx-HD
# mii-tool -F 10baseT-HD
Setup eth0 negotiated speed with ethtool# ethtool -s eth0 speed 100 duplex full
# ethtool -s eth0 speed 10 duplex half
To make these settings permanent you need to create a shell script and call from /etc/rc.local (Red Hat) or if you are using Debian create a script into the directory /etc/init.d/ directory and run update-rc.d command to update the script.

Read man page of mii-tool and ethtool for more information.

How to Convert Your Linux Server into a Simple Router

How to Convert Your Linux Server into a Simple Router


Configuring IP Forwarding


For your Linux server to become a router, you have to enable packet forwarding. In simple terms packet forwarding enables packets to flow through the Linux box from one network to another. The Linux kernel configuration parameter to activate this is named net.ipv4.ip_forward and can be found in the file /etc/sysctl.conf. Remove the "#" from the line related to packet forwarding.

Before:

# Disables packet forwarding
net.ipv4.ip_forward=0

After:

# Enables packet forwarding
net.ipv4.ip_forward=1

This enables packet forwarding only when you reboot at which time Linux will create a file in one of the subdirectories of the special RAM memory-based /proc filesystem. To activate the feature immediately you have to force Linux to read the /etc/sysctl.conf file with the sysctl command using the -p switch. Here is how it's done:

[root@bigboy tmp] sysctl -p
sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
kernel.sysrq = 0
kernel.core_uses_pid = 1
[root@bigboy tmp]#

Using ethtool

The ethtool command is slated to be the replacement for mii-tool in the near future and tends to be supported by newer NIC cards.

The command provides the status of the interface you provide as its argument. Here we see interface eth0 not doing autonegotiation and set to a speed of 100 Mbps, full duplex. A list of supported modes is also provided at the top of the output.

[root@bigboy tmp]# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: g
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes
[root@bigboy tmp]#

Setting Your NIC's Speed Parameters with ethtool

Unlike mii-tool, ethtool settings can be permanently set as part of the interface's configuration script with the ETHTOOL_OPTS variable. In our next example, the settings will be set to 100 Mbps, full duplex with no chance for auto-negotiation on the next reboot:


#
# File: /etc/sysconfig/network-scripts/ifcfg-eth0
#
DEVICE=eth0
IPADDR=192.168.1.100
NETMASK=255.255.255.0
BOOTPROTO=static
ONBOOT=yes
ETHTOOL_OPTS="speed 100 duplex full autoneg off"

You can test the application of these parameters by shutting down the interface and activating it again with the ifup and ifdown commands. These settings can also be changed from the command line using the -s switch followed by the interface name and its desired configuration parameters.

[root@bigboy tmp]# ethtool -s eth1 speed 100 duplex full autoneg off
[root@bigboy tmp]#

The Linux man pages give more details on other ethtool options, but you can get a quick guide by just entering the ethtool command alone, which provides a quicker summary.

[root@bigboy tmp]# ethtool
...
...
ethtool -s DEVNAME \
[ speed 10|100|1000 ] \
[ duplex half|full ] \
[ port tp|aui|bnc|mii|fibre ] \
...
...
[root@bigboy tmp]#

A Note About Duplex Settings

By default, Linux NICs negotiate their speed and duplex settings with the switch. This is done by exchanging electronic signals called Fast Link Pulses (FLP). When the speed and duplex are forced to a particular setting the FLPs are not sent. When a NIC is in auto-negotiation mode and detects a healthy, viable link but receives no FLPs, it errs on the side of caution and sets its duplex to half-duplex and sometimes it will also set its speed to the lowest configurable value. It is therefore possible to force a switch port to 100 Mbps full duplex, but have the auto-negotiating server NIC set itself to 100Mbps half-duplex which will result in errors. The same is true for the switch if the switch port is set to auto-negotiate and server NIC is set to 100 Mbps full duplex. It is best to either force both the switch port and server NIC to either auto-negotiate or the same forced speed and duplex values.

What needs to be done so that Linux can run two ethernet cards?

What needs to be done so that Linux can run two ethernet cards?

Using More than one Ethernet Card per Machine

The answer to this question depends on whether the driver(s) is/are being used as a loadable module or are compiled directly into the kernel. Most linux distributions use modular drivers now. This saves distributing lots of kernels, each with a different driver set built in. Instead a single basic kernel is used and the individual drivers that are need for a particular user's system are loaded once the system has booted far enough to access the driver module files (usually stored in /lib/modules/).

With the Driver as a Module: In the case of PCI drivers, the module will typically detect all of the installed cards of that brand model automatically. However, for ISA cards, probing for a card is not a safe operation, and hence you typically need to supply the I/O base address of the card so the module knows where to look. This information is stored in the file /etc/conf.modules.

As an example, consider a user that has two ISA NE2000 cards, one at 0x300 and one at 0x240 and what lines they would have in their /etc/conf.modules file:

        alias eth0 ne
alias eth1 ne
options ne io=0x240,0x300

What this does: This says that if the administrator (or the kernel) does a modprobe eth0 or a modprobe eth1 then the ne.o driver should be loaded for either eth0 or eth1. Furthermore, when the ne.o module is loaded, it should be loaded with the options io=0x240,0x300 so that the driver knows where to look for the cards. Note that the 0x is important - things like 300h as commonly used in the DOS world won't work. Switching the order of the 0x240 and the 0x300 will switch which physical card ends up as eth0 and eth1.

Most of the ISA module drivers can take multiple comma separated I/O values like this example to handle multiple cards. However, some (older?) drivers, such as the 3c501.o module are currently only able to handle one card per module load. In this case you can load the module twice to get both cards detected. The /etc/conf.modules file in this case would look like:

        alias eth0 3c501
alias eth1 3c501
options eth0 -o 3c501-0 io=0x280 irq=5
options eth1 -o 3c501-1 io=0x300 irq=7

In this example the -o option has been used to give each instance of the module a unique name, since you can't have two modules loaded with the same name. The irq= option has also been used to to specify the hardware IRQ setting of the card. (This method can also be used with modules that accept comma separated I/O values, but it is less efficient since the module ends up being loaded twice when it doesn't really need to be.)

As a final example, consider a user with one 3c503 card at 0x350 and one SMC Elite16 (wd8013) card at 0x280. They would have:

        alias eth0 wd
alias eth1 3c503
options wd io=0x280
options 3c503 io=0x350

For PCI cards, you typically only need the alias lines to correlate the ethN interfaces with the appropriate driver name, since the I/O base of a PCI card can be safely detected.

The available modules are typically stored in /lib/modules/`uname -r`/net where the uname -r command gives the kernel version (e.g. 2.0.34). You can look in there to see which one matches your card. Once you have the correct settings in your conf.modules file, you can test things out with:

        modprobe ethN
dmesg | tail

where `N' is the number of the ethernet interface you are testing.

With the Driver Compiled into the Kernel: If you have the driver compiled into the kernel, then the hooks for multiple ethercards are all there. However, note that at the moment only one ethercard is auto-probed for by default. This helps to avoid possible boot time hangs caused by probing sensitive cards.

(Note: As of late 2.1.x kernels, the boot probes have been sorted into safe and unsafe, so that all safe (e.g. PCI and EISA) probes will find all related cards automatically. Systems with more than one ethernet card with at least one of them being an ISA card will still need to do one of the following.)

There are two ways that you can enable auto-probing for the second (and third, and...) card. The easiest method is to pass boot-time arguments to the kernel, which is usually done by LILO. Probing for the second card can be achieved by using a boot-time argument as simple as ether=0,0,eth1. In this case eth0 and eth1 will be assigned in the order that the cards are found at boot. Say if you want the card at 0x300 to be eth0 and the card at 0x280 to be eth1 then you could use

LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1

The ether= command accepts more than the IRQ + I/O + name shown above. Please have a look at Passing Ethernet Arguments... for the full syntax, card specific parameters, and LILO tips.

These boot time arguments can be made permanent so that you don't have to re-enter them every time. See the LILO configuration option `append' in the LILO manual.

The second way (not recommended) is to edit the file Space.c and replace the 0xffe0 entry for the I/O address with a zero. The 0xffe0 entry tells it not to probe for that device -- replacing it with a zero will enable autoprobing for that device.

How can I change my default gateway in Linux?

How can I change my default gateway in Linux?


Your machine needs to have a single default gateway. DHCP servers will automatically assign a default gateway to DHCP configured NICs, but NICs with configured static IP addresses will need to have a manually configured default gateway. This can be done with a simple command.

[root@linux etc]# route add default gw 192.168.1.1 eth0

In this case, make sure that the router/firewall with IP address 192.168.1.1 is connected to the same network as interface eth0!

Once done, you’ll need to update your /etc/sysconfig/network file to reflect the change. This file is used to configure your default gateway each time Linux boots.

NETWORKING=yes
HOSTNAME=linux
GATEWAY=192.168.1.1

How to delete a route in Linux?

How to delete a route in Linux?



Here’s how to delete a route for the network 10.0.0.0/8 with a gateway of 192.168.1.254 connected to the interface eth0.

[root@linux etc]# route del -net 10.0.0.0 netmask 255.0.0.0 gw 192.168.1.254 eth0

The file /etc/sysconfig/network-scripts/route-eth0 will also have to be updated so that when you reboot the server will not reinsert the route. Delete the line that reads:

10.0.0.0/8 via 192.168.1.254

How can I enable or disable an Ethernet interface in Linux?

How can I enable or disable an Ethernet interface in Linux?


The ifup and ifdown commands can be used respectively to activate and deactivate a NIC interface. You must have an ifcfg file in the /etc/sysconfig/network-scripts directory for these commands to work.

Here is an example for interface eth0:

To shutdown eth0:
[root@linux etc]# ifdown eth0

To enable eth0:
[root@linux etc]# ifup eth0

To make the change permanent, modify the interface config in the /etc/sysconfig/network-scripts directory. It will be named ifcfg-[interface], i.e. ifcfg-eth0 for Ethernet 0.

Open the file in your favorite editor and change:

ONBOOT=yes

to

ONBOOT=no

 
Things You Should Know About Linux !!!