Tips & Tricks

How do I set the MTU for my network interface?

by Michael Kearey

The MTU can be set by editing the configuration file for the device. To see the devices you have use the ifconfig -a command. The output should look similar to the following:

eth0      Link encap:Ethernet  HWaddr 00:0D:61:93:55:3E
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:386423 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6490 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:203556104 (194.1 MiB)  TX bytes:787293 (768.8 KiB)
          Interrupt:209 Memory:fb000000-0

eth1      Link encap:Ethernet  HWaddr 00:40:F4:98:8E:43
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:185 Base address:0xa000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:36036 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36036 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:20683798 (19.7 MiB)  TX bytes:20683798 (19.7 MiB)

Alternatively, you can use the ip link list command with the following output:

1: lo:  mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0d:61:93:55:3e brd ff:ff:ff:ff:ff:ff
3: eth1:  mtu 1500 qdisc noop qlen 1000
    link/ether 00:40:f4:98:8e:43 brd ff:ff:ff:ff:ff:ff

The interface eth0 has an MTU set to 1500 bytes. To change the setting temporarily (to 1200 in this example) issue the following command as root:

ip link set dev eth0 mtu 1200

To make the setting permanent for eth0, edit the configuration file /etc/sysconfig/network-scripts/ifcfg-eth0 and add the line MTU=1200 as shown below:

DEVICE=eth0
MTU=1200
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet

Then, restart the interface (as root):

service network restart eth0

The output of netstat -nr shows the value 0 for the MSS. What is the meaning of this value?

by Michael Kearey

The output of the netstat -nr command usually shows something like this:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
0.0.0.0         192.168.0.254   0.0.0.0         UG        0 0          0 eth0

The Maximum Segment Size (MSS) value of 0 shown from the netstat command is intentionally wrong for any type of network and is ignored by the kernel when a network connection is established.

When the route MSS is zero, the MSS is determined by the kernel by looking at the MTU of the interface the packet is leaving on.

To view the settings for an interface use the ifconfig eth0 command:

eth0      Link encap:Ethernet  HWaddr 00:0D:61:93:55:3E
          inet addr:192.168.0.22  Bcast:172.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 ...

The MSS value is calculated based on the formula MSS = MTU - 40 bytes. So if a network interface has a MTU of 1500 bytes, the MSS will be calculated by the kernel as 1460 bytes. This is the advertised MSS value for the TCP connection and is used to tell the other end of the connection the preferred MSS we would like to receive. When a TCP connection is established, the MSS value is sent to the host we are connecting to in a SYN packet.

The route MSS (as shown in the netstat -rn command) can be used to override the advertised MSS value calculated by the kernel. For example, if I wanted to force the MSS to 1200 bytes for all connections to the network 192.168.1.0/24 I could use the ip command:

 
ip route add 192.168.1.0/24 dev eth0 advmss 1200

I can also set the MSS value for particular hosts:

ip route add 192.168.0.212 dev eth0 advmss 1200

Note that this only affects the packets received, not the packets transmitted — the MSS value is an advertised value used to inform the other end of the connection what the system is able to receive.

The packets we transmit may have their MSS negotiated in a similar fashion, although this is not always the case, as the advertised MSS is optional. While Red Hat Enterprise Linux does add the MSS value to SYN and SYN-ACK packets, other TCP/IP implementations may not.

In general, if there is no advisory MSS value received, then it defaults to the minimum value of 536 (MTU 576 - 40 bytes = 536).

Also note that in addition to the MTU and route MSS values, Red Hat Enterprise Linux implements path MTU discovery, a simple protocol that tries to automatically determine the ideal MTU for a TCP connection.

There is rarely any need to alter the interface MTU or the route MSS value if path MTU discovery is working correctly.

How can I lookup package updates by relevant Common Vulnerabilities and Exposures (CVE) numbers?

by Chris Evich

If you are aware of specific CVE or CAN designations and need to search for packages affected by them, you can lookup this information from Red Hat Network (RHN). After logging in, replace the URL with one in the following format:

http://rhn.redhat.com/cve/<CVE>.html

Where <CVE> is the designation you would like to find, followed by .html.

Note: You can not lookup CAN designations in this manner as they are only candidates and have not actually been verified. If or when a CAN designation turns into a CVE designation, then you will be able to look it up in this manner. You can also search for these designations on the CVE website. If you would like more information related to security and Red Hat Enterprise Linux please visit our security site.

What is LD_ASSUME_KERNEL and what does it affect?

by Eric Paris

Here are a few details which should enable everybody to understand and investigate the issue of LD_ASSUME_KERNEL more closely.

1. First, LD_ASSUME_KERNEL is handled by the dynamic linker.
2. The behavior of a specific value of LD_ASSUME_KERNEL is not hardcoded in the dynamic linker.
3. Every DSO (Dynamic Shared Object, aka shared library) can tell the dynamic linker in glibc which minimum OS ABI version is needed. Dynamic linkers other than glibc's do not have this feature. The information about the minimum OS ABI version is encoded in a ELF note section usually named .note.ABI-tag. This note section must be referenced by a PT_NOTE entry in the DSO's program header.

To examine the content of a DSO's note section use the readelf program from elfutils (the version from binutils is not capable enough). On a Red Hat system the binary is called eu-readelf. Using it on a Fedora Core 2 system shows the following:

 
eu-readelf -n /lib/tls/libc-2.3.3.so

Note segment of 32 bytes at offset 0x174:
  Owner          Data size  Type
  GNU                   16  VERSION
    OS: Linux, ABI: 2.4.20

This means the /lib/tls/libc-2.3.3.so DSO requires at least OS ABI version 2.4.20.

4. The specific ABI version requirements on Red Hat Linux 9 and Fedora Core 1 and 2 system are as follows (this implies IA-32 is the architecture):
   • DSOs in /lib/tls need ABI version 2.4.20.
   • DSOs in /lib/i686 need ABI version 2.4.1.
   • DSOs in /lib need ABI version 2.2.5.

   Thus, a LD_ASSUME_KERNEL setting requesting versions earlier than 2.2.5 will not work at all. Versions 2.2.5 to 2.4.0 will use the DSOs in /lib, versions from 2.4.1 to 2.4.19 will use the DSOs in /lib/i686, and versions 2.4.20 and younger will use the DSOs in /lib/tls.

   For the Red Hat releases, this layout was chosen to provide the maximum amount of backward compatibility for broken applications (correctly written applications have no problems anyway). The code in /lib consists of the very early LinuxThreads code which had fixed size threads which could not be placed by the application. The version in /lib/i686 is the LinuxThreads code which does away with this limitation (aka floating stacks). The code in /lib/tls is the new NPTL POSIX thread library.

5. The fact that a DSO has a more stringent version requirement does not mean it is automatically chosen. The dynamic only rejects loading DSOs based on the version information. It does not look for the best fit. The above description is true because the dynamic linker always looks in the directories /lib/tls, /lib/i686, and /lib in this order. Why this is the case is complicated and not explained here. Read the dynamic linker source code.
6. For architectures other than IA-32 the situation is similar, but less complicated. In Red Hat Enterprise Linux version 3 only two versions of glibc are needed, one using LinuxThreads and one using NPTL. The very old LinuxThreads code is not needed.

How do I add ethtool settings to a network device permanently?

by Michael Kearey

ethtool can be used to set options for many types of Ethernet devices. The /etc/sysconfig/network-scripts/ifcfg-ethX files can have the ethtool settings added to them so that the settings are saved and used every time the device is activated.

For example, the command:

ethtool speed 100 duplex full autoneg off

sets the eth0 device to 100Mbs, full duplex, with auto negotiation off. To have the initialization scripts set this every time the eth0 device is activated, add a line to the /etc/sysconfig/network-scripts/ifcfg-eth0 file:

 
ETHTOOL_OPTS="speed 100 duplex full autoneg off"

How can I quickly tell what file systems my current kernel can handle?

by Kent Baxley

The kernel provides a list of file system types it is able to mount via the /proc file system. To view the list, run the command cat /proc/filesystems. The output will look something like:

nodev    proc
         ext3
         ext2
         vfat
         iso9660
nodev    nfs
nodev    smbfs

In this output, the entry vfat means you can mount FAT/VFAT (Microsoft Windows) partitions. The entries ending with smbfs and nfs mean you can interact with file servers that use SMBFS (Microsoft's Server Message Block File System, accessed via Samba) or NFS (Sun's Network File System). The iso9660 indicates that you can mount standard CD-ROM file systems, and ext3 and ext2 indicate that you can mount those kinds of Linux file systems.

In the first column, nodev indicates that the file system is not associated with a physical device, like the /proc file system itself, which has information about state of the running kernel.

I downloaded an RPM to a Windows machine using Internet Explorer then transferred it to my Linux machine. When I try to install it with the RPM command, I immediately get a prompt back and it does not install. How can I fix this?

by Bradford Hinson

When downloading a file, Internet Explorer sometimes places square brackets in the resulting filename. When the rpm command is run on a file with square brackets, it fails with no error message and does not install the package. The square brackets are a part of the Linux bash shell and are reserved for a technique called file globbing.

To fix this, rename the RPM with the mv command. When specifying the filename of the RPM at a shell prompt, type the first few letters, then use the Tab key to autocomplete the name. This ensures that the brackets in the filename are properly delimited. Rename the file to so that it does not contain square brackets. For example:

mv kernel-2\[1\].4.21-20.EL.i686.rpm kernel-2.4.21-20.EL.i686.rpm

Alternatively, you can enclose the file in single quotes, like so:

 
mv 'kernel-2[1].4.21-20.EL.i686.rpm' kernel-2.4.21-20.EL.i686.rpm

After renaming the file, the rpm command can be used to install the package successfully.

This article is protected by the Open Publication License, V1.0 or later. Copyright © 2004 by Red Hat, Inc.