# Ethernet Layer Tools

The section here will cover tools which manipulate, display characteristics of or probe Ethernet devices. Because Ethernet is one of the most available and widely spread networking media in use today, we'll concentrate on Ethernet rather than other link layer protocols.

As with any networking stack, the lower layers must be functioning properly in order for the higher layer protocols to operate. The tools covered in this section will provide the resources you need to verify the proper operation of your linux machine in an Ethernet environment.

You probably knew before reading this that you can look at the link light on your Ethernet switch/hub and the link light on your Ethernet card to verify a good connection. Now you can use `mii-tool` to ask the Ethernet driver if it agrees. Once you have verified a good media connection, you may want to set other link layer characteristics on your Ethernet device. For this, `ip link` is the perfect tool.

To see if anybody is using an IP address already on the Ethernet to which you are connecting, you can use `arping` and if you want to play with the arp tables, the `arp` command is there to help you accomplish your objective.

## `arp`

An often overlooked tool, `arp` is used to view and manipulate the entries in the arp table. See for a fuller discussion of the arp table.

The most common uses for `arp` are to add an address for which to proxy arp, delete an address from the arp table or view the arp table itself.

In the simplest invocation, you simply want to see the current state of the arp table. Invoking `arp` with no options will provide you exactly the information you need. Typically, you may not trust DNS (or may not wish to wait for the DNS lookups), and you may wish to specify the arp table on a particular interface.

### Displaying the arp table with `arp`

    [root@masq-gw]# arp -n -i eth3
    Address                  HWtype  HWaddress           Flags Mask Iface
    192.168.100.1           ether   00:C0:7B:7D:00:C8   C                     eth3
    [root@masq-gw]# arp -n -i eth0
    Address                  HWtype  HWaddress           Flags Mask Iface
    192.168.100.17          ether   00:80:C8:E8:4B:8E   C                     eth0
    [root@masq-gw]# arp -a -n -i eth0
    ? (192.168.100.17) at 00:80:C8:E8:4B:8E [ether] on eth0

The MAC address in the third column is always a six part hexadecimal number. In practice, the MAC address (also known as the hardware address or the Ethernet address) is not normally needed for the majority of troubleshooting problems, however knowing how to retrieve the MAC address can help when tracking down problems in a network I know of one instance where some devices which used DHCP to join the network were suddenly and apparently inexplicably receiving addresses in an unexpected netblock. After some head-scratching and judicious use of `tcpdump` to record the Ethernet address of the DHCP server giving out the bogus IP information, the administrator was able to track down a device through the switch to a port on the LAN. It turned out to be a tiny (4-port) hub with an embedded DHCP server which was intended for home use! The knowledge of the Ethernet address of the rogue DHCP server was the key to physically locating the device. .

The `arp` command can also force a permament entry into the arp table. Let's look at an unusual networking need. Infrequently, a need arises to split a network into two parts, each part with the same network address and netmask. The router which joins the two networks is connected to both sets of media. See for more detail on when and how to do this.

The command to add arp table entries makes a static entry in the arp table. This is not recommended practice, and is probably only necessary in strange, experimental, hybrid, or pseudo-bridging situations.

### Adding arp table entries with `arp`

    [root@masq-gw]# arp -s 192.168.100.17 -i eth3 -D eth3 pub
    [root@masq-gw]# arp -n -i eth3
    Address                  HWtype  HWaddress           Flags Mask Iface
    192.168.100.1           ether   00:C0:7B:7D:00:C8   C                     eth3
    192.168.100.17          *       *                   MP                    eth3

After inserting an entry into the arp table on eth3, we will now respond for ARP requests on eth3 for the IP 192.168.100.17. If the service-router has a packet bound for 192.168.100.17, it will generate an ARP request to which we will respond with the Ethernet address of our eth3 interface.

Moments after you have added this arp table entry, you realize that you really do not wish service-router and isolde to exchange any IP packets. There is no reason for the isolde to initiate a telnet session with service-router and correspondingly, there are no services on isolde which should be accessible from the router.

Fortunately, it's quite easy to remove the entry.

### Deleting arp table entries with `arp`

    [root@masq-gw]# arp -i eth3 -d 192.168.100.17
    [root@masq-gw]# arp -n -i eth3
    Address                  HWtype  HWaddress           Flags Mask Iface
    192.168.100.1           ether   00:C0:7B:7D:00:C8   C                     eth3

`arp` is a small utility, but one which can prove extremely handy. One minor annoyance with the `arp` utility is option handling. Options seem to be handled differently based on order. If in doubt, try specifying the action as the first option.

## `arping`

An almost unknown command (mostly because it is not frequently necessary), the `arping` utility performs an action similar to `ping`, but at the Ethernet layer. Where `ping` tests the reachability of an IP address, `arping` reports the reachability and round-trip time of an IP address hosted on the local network.

There are several modes of operation for this utility. Under normal operation, `arping` displays the Ethernet and IP address of the target as well as the time elapsed between the arp request and the arp reply.

### Displaying reachability of an IP on the local Ethernet with `arping`

    [root@masq-gw]# arping -I eth0 -c 2 192.168.100.17
    ARPING 192.168.100.17 from 192.168.100.254 eth0
    Unicast reply from 192.168.100.17 [00:80:C8:E8:4B:8E]  8.419ms
    Unicast reply from 192.168.100.17 [00:80:C8:E8:4B:8E]  2.095ms
    Sent 2 probes (1 broadcast(s))
    Received 2 response(s)

Other options to the arping utility include the ability to send a broadcast arp using the `-U` option and the ability to send a gratuitous reply using the `-A` option. A kernel with support for non-local bind can be used with arping for the nefarious purpose of wreaking havoc on an otherwise properly configured Ethernet. By performing gratuitous arp and broadcasting incorrect arp information, arp tables in poorly designed IP stacks can become quite confused.

`arping` can detect if an IP address is currently in use on an Ethernet. Called duplicate address detection, this use of `arping` is increasingly common in networking scripts.

For a practical example, let's assume a laptop named dietrich is normally connected to a home network with the same IP address as tristan of our main office network. In the boot scripts, dietrich might make good use of `arping` by testing reachability of the IP it wants to use before bringing up the IP layer.

### Duplicate Address Detection with `arping`

    [root@dietrich]# arping -D -q -I eth0 -c 2 192.168.99.35
    [root@dietrich]# echo $?
    1
    [root@dietrich]# arping -D -q -I eth0 -c 2 192.168.99.36
    [root@dietrich]# echo $?
    0

First, dietrich tests reachability of its preferred IP (192.168.99.35). Because the IP address is in use by tristan, dietrich receives a response. Any response by a device on the Ethernet indicating that an IP address is in use will cause the `arping` command to exit with a non-zero exit code (specifically, exit code 1).

Note, that the Ethernet device must already be in an UP state (see ). If the Ethernet device has not been brought up, the `arping` utility will exit with a non-zero exit code (specifically, exit code 2).

## `ip link`

Part of the &iproute2; suite, `ip link` provides the ability to display link layer information, activate an interface, deactivate an interface, change link layer state flags, change MTU, the name of the interface, and even the hardware and Ethernet broadcast address.

The `ip link` tool provides the following two verbs: `ip link show` and `ip link set`.

### Displaying link layer characteristics with `ip link show`

To display link layer information, `ip link show` will fetch characteristics of the link layer devices currently available. Any networking device which has a driver loaded can be classified as an available device. It is immaterial to `ip link` whether the device is in use by any higher layer protocols (e.g., IP). You can specify which device you want to know more about with the `dev <interface>` option.

#### Using `ip link show`

    [root@tristan]# ip link show
    1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff

Here we see that the only devices with drivers loaded on tristan are `lo` and `eth0`. Note, as with `ip address show`, the `ip` utility will sequentially number the output. These numbers are dynamically calcualted, so should not be used to refer to the interfaces. It is far better (and more intuitive) to refer to the interfaces by name.

For each device, two lines will summarize the link state and characteristics. If you are familiar with `ifconfig` output, you should notice that these two lines are a terse summary of lines 1 and 3 of each `ifconfig` device entry.

The flags here are the same flags reported by `ifconfig`, although by contrast to `ifconfig`, `ip link show` seems to report the state of the device flags accurately.

Let's take a brief tour of the `ip link show` output. Line one summarizes the current name of the device, the flags set on the device, the maximum transmission unit (MTU) the active queueing mechanism (if any), and the queue size if there is a queue present. The second line will always indicate the type of link layer in use on the device, and link layer specific information. For Ethernet, the common case, the current hardware address and Ethernet broadcast address will be displayed.

### Changing link layer characteristics with `ip link set`

Frankly, with the exception of `ip link set up` and `ip link set down` I have not found need to use the `ip link set` command with any of the toggle flags Regardless, here's an example of the proper operation of the utility. Paranoid network administrators or those who wish to map Ethernet addresses manually should take special note of the `ip link set arp off` command.

#### Using `ip link set` to change device flags

    [root@tristan]# ip link set dev eth0 promisc on
    [root@tristan]# ip link show dev eth0
    2: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
    [root@tristan]# ip link set dev eth0 multicast off promisc off
    [root@tristan]# ip link show dev eth0
    2: eth0: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
    [root@tristan]# ip link set arp off
    Not enough of information: "dev" argument is required.
    [root@tristan]# ip link set arp off dev eth0
    [root@tristan]# ip link show dev eth0
    2: eth0: <BROADCAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
    [root@enclitic root]# ip link set dev eth0 arp on
    [root@tristan root]# ip link show dev eth0
    2: eth0: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff

Any of the below flags are valid on any device.

#### `ip link` link layer device states

Flag | Possible States
--- | ---
arp | on | off
promisc | on | off
allmulti | on | off
multicast | on | off
dynamic | on | off

Users who would like more information about flags on link layer devices and their meanings should refer to Alexey Kuznetsov's excellent &iproute2; reference. See the for further links.

### Deactivating a device with `ip link set`

In the same way that using the tool `ifconfig <interface> down` can summarily stop networking, `ip link set dev <interface> down` will have a number of side effects for higher networking layers which are bound to this device.

Let's look at the side effects of using `ip link` to bring an interface down.

#### Deactivating a link layer device with `ip link set`

    [root@tristan]# ip link show dev eth0
    2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
    [root@tristan]# ip route show
    192.168.99.0/24 dev eth0  proto kernel  scope link  src 192.168.99.35
    127.0.0.0/8 dev lo  scope link
    default via 192.168.99.254 dev eth0
    [root@tristan]# ip link set dev eth0 down
    [root@tristan]# ip address show dev eth0
    2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
        inet 192.168.99.35/24 brd 192.168.99.255 scope global eth0
    [root@tristan]# ip route show
    127.0.0.0/8 dev lo  scope link

In our first command, we are able to determine that the `eth0` is in an UP state. Naturally, `ip link` will not tell us if there is an IP bound to the device (use `ip address` to answer this question). Let's assume that tristan was operating normally on 192.168.199.35. If so, the routing table will appear exactly is it appears in .

Now when we down the link layer on `eth0`, we'll see that there is now no longer a flag UP in the link layer output of `ip address`. More interesting, though, all of our IP routes to destinations via `eth0` are now missing.

### Activating a device with `ip link set`

Before an interface can be bound to a device, the kernel needs to support the physical networking device (beyond the scope of this document) either as a module or as part of the monolithic kernel. If `ip link show` lists the device, then this condition has been satisfied, and `ip link set dev <interface>` can be used to activate the interface.

#### Activating a link layer device with `ip link set`

    [root@tristan]# ip link show dev eth0
    2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
    [root@tristan]# arping -D -I eth0 192.168.99.35
    Interface "eth0" is down
    [root@tristan]# ip link set dev eth0 up
    [root@tristan]# ip address show dev eth0
    2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
        inet 192.168.99.35/24 brd 192.168.99.255 scope global eth0
    [root@tristan]# ip route show
    192.168.99.0/24 dev eth0  proto kernel  scope link  src 192.168.99.35
    127.0.0.0/8 dev lo  scope link

Once the device itself has been activated, operations which require the ability to read data from the device or write data to the device will succeed. Refer to for a clear example of a network operation which does not require a functional IP layer but need access to a functioning link layer.

I'll suggest that the reader consider what other common networking device might not want to have a functional IP layer, but would need a functioning link layer. FIXME -- Why in the world does tcpdump work even though the link layer is down? -- FIXME

In , we are bringing up a device which already has IP address information bound to the device. Notice that as soon as the link layer is brought up, the network route to the local network is entered into the main routing table. By comparing and , we notice that when the link layer is brought up the default route is not returned! This is the most significant side effect of bringing down an interface through which other networks are reachable. There are several ways to repair the frightful missing default route condition: you can use `ip route add`, `route add`, or you can run the networking startup scripts again.

### Using `ip link set` to change the MTU

Changing the MTU on an interface is a classical example of an operation which, prior to the arrival of &iproute2; one could only accomplish with the `ifconfig` command. Since &iproute2; has separate utilities for managing the link layer, addressing, routing, and other IP-related objects, it becomes clear even with the command-line utilities that the MTU is really a function of the link layer protocol.

#### Using `ip link set` to change device flags

    [root@tristan]# ip link show dev eth0
    2: eth0: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
    [root@tristan]# # ip link set dev eth0 mtu 1412
    [root@tristan]# ip link show dev eth0
    2: eth0: <BROADCAST,UP> mtu 1412 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff

This simple example demonstrates exactly how to change the MTU. For a broader discussion of MTU, please consult . The remaining options to the `ip link` command cannot be used while the interface is in an UP state.

### Changing the device name with `ip link set`

For the occasional need to rename an interface from one name to another, the command `ip link set` provides the desired functionality. Though this command must be used when the device is not in an UP state, the command itself is quite simple. Let's name the interface `inside0`.

#### Changing the device name with `ip link set`

    [root@tristan]# ip link set dev eth0 mtu 1500
    [root@tristan]# ip link set dev eth0 name inside
    [root@tristan]# ip link show dev inside
    2: inside: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff

The convenience of being able to rename devices can be substantial when you are managing many machines and want to use the same name on many different machines, which may have different hardware. Of course, by changing the name of the device, you may foil any scripts which assume conventional device names (`eth0`, `eth1`, `ppp0`).

### Changing hardware or Ethernet broadcast address with `ip link set`

This command changes the hardware or broadcast address of a device as used on the media to which it is connected. Supposedly there can be name clashes between two different Ethernet cards sharing the same hardware address. I have yet to see this problem, so I suspect that changing the hardware address is more commonly used in vulnerabliity testing or even more nefarious purposes.

Alternatively, one can set the broadcast address to a different value, which as Alexey remarks as an aside in the &iproute2; manual will "break networking." Changing the Ethernet broadcast address implies that no conventionally configured host will answer broadcast ARP frames transmitted onto the Ethernet. Since conventional ARP requests are sent to the Ethernet broadcast of `ff:ff:ff:ff:ff:ff`, broadcast frames sent after changing the link layer broadcast address will not be received by other hosts on the segment. To echo Alexey's sentiments: if you are not sure what you are doing, don't change this. You'll break networking terribly.

#### Changing broadcast and hardware addresses with `ip link set`

    [root@tristan]# ip link set dev inside name eth0
    [root@tristan]# ip link set dev eth0 address 00:80:c8:f8:be:ef
    [root@tristan]# ip link show dev eth0
    2: eth0: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:be:ef brd ff:ff:ff:ff:ff:ff
    [root@tristan]# ip link set dev eth0 broadcast ff:ff:88:ff:ff:88
    [root@tristan]# ip link show dev eth0
    2: eth0: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
        link/ether 00:80:c8:f8:be:ef brd ff:ff:88:ff:ff:88
    [root@tristan]# ping -c 1 -n 192.168.99.254 >/dev/null 2>&1 &
    [root@tristan]# tcpdump -nnqtei eth0
    tcpdump: listening on eth0
    0:80:c8:f8:be:ef ff:ff:88:ff:ff:88 42: arp who-has 192.168.99.254 tell 192.168.99.35
    0:80:c8:f8:be:ef ff:ff:88:ff:ff:88 42: arp who-has 192.168.99.254 tell 192.168.99.35

This practical example demonstrates setting the hardware address and the broadcast address. Changing the hardware address, also known as the media access control (MAC) address, is not usually necessary. It is a simple operation without detrimental side effects, provided there is no address clash with an existing device.

Note, however, in the tcpdump output, the effect of changing the Ethernet broadcast address. As discussed in the paragraph above, changing the broadcast is probably not a good idea I refer the reader to an adage: Just because it can be done doesn't mean it should be done. .

As you can see, the `ip link` utility is a treasure trove of information and allows a great deal of control over the devices on a linux system.

## `ip neighbor`

Part of the &iproute2; command suite, `ip neighbor` provides a command line interface to display the neighbor table (ARP cache), insert permanent entries, remove specific entries and remove a large number of entries. For peculiarities and commonalities of the &iproute2; tools, refer to .

The more commonly used analog to `ip neighbor show`, `arp -n` displays the ARP cache in a possibly more recognizable format.

### Displaying the ARP cache with `ip neighbor show`

    [root@tristan]# ip neighbor show
    192.168.99.254 dev eth0 lladdr 00:80:c8:f8:5c:73 nud reachable

On routers and other machines with large ARP caches, you may find you wish to look at the ARP cache only on a particular interface. By specifying the interface on which you wish to see the neighbor table, you can limit the output.

### Displaying the ARP cache on an interface with `ip neighbor show`

    [root@wan-gw]# ip neighbor show dev eth0
    205.254.211.39 lladdr 00:02:b3:a1:b8:df nud delay
    205.254.211.54 lladdr 00:d0:b7:80:ce:ce nud delay
    205.254.211.179 lladdr 00:80:c8:f8:5c:72 nud reachable

Another way to limit the output is to specify the subnet in which you are interested. Simply append the subnet specification to the command.

### Displaying the ARP cache for a particular network with `ip neighbor show`

    [root@masq-gw]# ip neighbor show 192.168.100.0/24
    192.168.100.1 dev eth3 lladdr 00:c0:7b:7d:00:c8 nud stale
    192.168.100.17 dev eth0 lladdr 00:80:c8:e8:4b:8e nud reachable

Note that in the case of &masq-gw;, there are neighbor table entries for IPs on more than one interface, because &masq-gw; breaks the 192.168.100.0/24 network into two parts. This is an advanced technique described in fuller detail in .

In addition to displaying the neighbor table, it is possible to make static mappings. For paranoid systems administrators, who do not want to enable ARP on their networks or on particular links, the `ip neighbor add` command may prove useful. Refer to for a discussion of the ramifications of disabling ARP.

In , let's assume that the service router is incapable of correctly answering ARP requests. The administrator of &masq-gw; could make a permanent entry in the ARP cache mapping 192.168.100.1 to the link layer address of &service-router;.

### Entering a permanent entry into the ARP cache with `ip neighbor add`

    [root@masq-gw]# ip neighbor add 192.168.100.1 lladdr 00:c0:7b:7d:00:c8 dev eth3 nud permanent

This creates an entry in the neighbor table which maps 192.168.100.1 to link layer address 00:c0:7b:7d:00:c8. Subsequent IP packets bound for 192.168.100.1 will be encapsulated in Ethernet frames with 00:c0:7b:7d:00:c8 in the destination bytes. This permanent mapping cannot be overridden by ARP. It would need to be removed with `ip neighbor delete`.

For those who insist on such a thing, there is support for creating and deleting proxy ARP entries with `ip neighbor`, although this has been deprecated. For a long discussion of this topic, see this discussion on the kernel mailing list. Other tools should be used to create proxy ARP entries. Refer to , and .

### Entering a proxy ARP entry with `ip neighbor add proxy`

    # -- this is deprecated; use arp or kernel proxy_arp instead --#
    [root@masq-gw]# ip neighbor add proxy 192.168.100.1 dev eth0
    # -- this is deprecated; use arp or kernel proxy_arp instead --#

Strangely, the `ip neighbor show` command does not display any entries added and deleted with `ip neighbor add proxy`, so `arp` is required to view these entries. In short, don't use `ip neighbor add proxy`.

Entries can also be modified at any time. This allows learned entries to be replaced with static entries if there's already an entry in the ARP cache for a specified IP.

### Altering an entry in the ARP cache with `ip neighbor change`

    [root@tristan]# ip neighbor add 192.168.99.254 lladdr 00:80:c8:27:69:2d dev eth3
    RTNETLINK answers: File exists
    [root@tristan]# ip neighbor show 192.168.99.254
    192.168.99.254 dev eth0 lladdr 00:80:c8:f8:5c:73 nud reachable
    [root@tristan]# ip neighbor change 192.168.99.254 lladdr 00:80:c8:27:69:2d dev eth3
    [root@tristan]# ip neighbor show 192.168.99.254
    192.168.99.254 dev eth0 lladdr 00:80:c8:27:69:2d nud permanent

To remove the entry we added above in , we could run the following command. This invalidates the entry forcing the NUD of the entry into failed state.

### Removing an entry from the ARP cache with `ip neighbor del`

    [root@masq-gw]# ip neighbor del 192.168.100.1 dev eth3
    [root@masq-gw]# ip neighbor show dev eth3
    192.168.100.1  nud failed

Subsequent attempts to reach the IP address 192.168.100.1 will require the generation of a new ARP request, which (you hope!) returns the new or currently available link layer address.

While I have never found a good use for the `ip neighbor flush` command, it is provided, and accepts a destination network address as an argument. Without a destination network address, an interface specification is required.

### Removing learned entries from the ARP cache with `ip neighbor flush`

    [root@tristan]# ip neighbor flush dev eth3

Although it is not commonly required, the `ip neighbor` tool is a convenient tool for displaying and altering the ARP cache (neighbor table).

## `mii-tool`

A key tool for determining if you are connected to the Ethernet, and if so, at what speed. The `mii-tool` program does not support all Ethernet devices, as some Ethernet devices have their own vendor-supplied tools to report the same information. The `mii-tool` source code is based on a tool called `mii-diag` which provides slightly more information but is less user friendly.

The information reported by `mii-tool` is quite terse. The following table should clarify the meaning of the speeds you'll encounter in output from `mii-tool` There is a standard speed/Ethernet transmission style supported by `mii-tool` to which I have not referred. That is 100BaseT4. 100BaseT4 provides support for 100 megabit Ethernet networking over Category 3 rated cable. This is probably not a concern for most recently upgraded network infrastructure. The standard networking cable pulled in new construction and renovation is now Category 5 cable which supports 100Base-Tx-FD and possibly gigabit Ethernet. So, let's relegate 100BaseT4 to this footnote, and resume. .

### Ethernet Port Speed Abbreviations

Port Speed | Description
--- | ---
10baseT-HD | 10 megabit half duplex
10baseT-FD | 10 megabit full duplex
100baseTx-HD | 100 megabit half duplex
100baseTx-FD | 100 megabit full duplex

The raw number indicates the number of bits which can be exchanged between two Ethernet devices over the wire. So 10 megabit Ethernet can support the transmission of ten million bits per second. The suffix to each identifier indicates whether both hosts can send and receive simultaneously or not. Half duplex means that each device can either send or receive in the same instant. Full duplex means that both devices can send and receive simultaneously.

The simplest use of `mii-tool` reports the link status of all Ethernet devices on a system. Any argument to `mii-tool` is interpreted as an interface name to query for link status.

### Detecting link layer status with `mii-tool`

    [root@tristan]# mii-tool
    eth0: negotiated 100baseTx-FD, link ok
    [root@tristan]# mii-tool -v
    eth0: negotiated 100baseTx-FD, link ok
      product info: vendor 08:00:17, model 1 rev 0
      basic mode:   autonegotiation enabled
      basic status: autonegotiation complete, link ok
      capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
      advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
      link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

In the above example, we can infer that tristan has only one Ethernet device (or no Ethernet drivers loaded for any other present Ethernet devices). The first Ethernet device has successfully negotiated a 100 megabit full duplex connection with the device to which it is connected.

Although a great rarity, you may have occasion to dictate to the Ethernet interface the speed at which it should talk to the switch or hub. `mii-tool` supports a mode of operation under which you indicate supported modes for autonegotiation. Normally, two connected devices will negotiate the fastest possible commonly shared speed. You can select what speeds you want to support on an Ethernet interface by using `mii-tool`.

### Specifying Ethernet port speeds with `mii-tool --advertise`

    [root@tristan]# mii-tool mii-tool --advertise 10baseT-HD,10baseT-FD
    restarting autonegotiation...
    [root@tristan]# mii-tool
    eth0: negotiated 10baseT-FD, link ok

After we specified that we wished only to support 10baseT-HD and 10baseT-FD as acceptable speeds, mii-tool caused the Ethernet driver to renegotiate port speed with the attached device. Here we selected 10baseT-FD.

### Forcing Ethernet port speed with `mii-tool --force`

    [root@tristan]# mii-tool --force 10baseT-FD
    [root@tristan]# mii-tool
    eth0: 10 Mbit, full duplex, link ok
    [root@tristan]# mii-tool --restart
    restarting autonegotiation...
    [root@tristan]# mii-tool
    eth0: negotiated 100baseTx-FD, link ok

After manipulating the speed at which the Ethernet driver would communicate with the connected device on &tristan;, we chose to restart the autonegotiation process without forcing a particular speed or advertising a particular speed.

So, if you must know at what speed your linux machine is connected to another device, `mii-tool` comes to your rescue.