Æ Øûóö Ò Ìóóð× ½

ÆeØÛÓÖkiÒg ÌÓÓÐ×

½ aÒd

℄

¾ ÄÇÇÃÍÈ ÌÇÇÄË: AÆD

℄

¾ ÄÓ ÓkÙÔ ÌÓÓÐ×: dig aÒd ÛhÓi×

¾ ÄÇÇÃÍÈ ÌÇÇÄË: AÆD

℄

¾ ÄÇÇÃÍÈ ÌÇÇÄË: AÆD

℄

¿ ÅEAËÍÊEÅEÆÌ ÌÇÇÄË: AÆD

℄

¿ Åea×ÙÖeÑeÒØ ÌÓÓÐ×: aÒd

¯ ÒÓØ

4 ÈEÊÄ

ÓÙØgÓiÒg

℄

4 ÈeÖÐ

Linux Network Administrators Guide

(Reference: http://www.faqs.org/docs/linux_network/index.html)

3.2. A Tour of Linux Network Devices The Linux kernel supports a number of hardware drivers for various types of equipment. This section gives a short overview of the driver families available and the interface names they use. There is a number of standard names for interfaces in Linux, which are listed here. Most drivers support more than one interface, in which case the interfaces are numbered, as in eth0 and eth1: lo

This is the local loopback interface. It is used for testing purposes, as well as a couple of network applications. It works like a closed circuit in that any datagram written to it will immediately be returned to the host's networking layer. There's always one loopback device present in the kernel, and there's little sense in having more. eth0, eth1, …

These are the Ethernet card interfaces. They are used for most Ethernet cards, including many of the parallel port Ethernet cards.

There are many other types of interfaces available for other network drivers. We've listed only the most common ones.

5.7. Interface Configuration for IP After setting up your hardware as explained in Chapter 4, you have to make these devices known to the kernel networking software. A couple of commands are used to configure the network interfaces and initialize the routing table. These tasks are usually performed from the network initialization script each time you boot the system. The basic tools for this process are called ifconfig (where “if ” stands for interface) and route. ifconfig is used to make an interface accessible to the kernel networking layer. This involves the assignment of an IP address and other parameters, and activation of the interface, also known as “bringing up” the interface. Being active here means that the kernel will send and receive IP datagrams through the interface. The simplest way to invoke it is with: ifconfig interface ip-address

This command assigns ip-address to interface and activates it. All other parameters are set to default values. For instance, the default network mask is derived from the network class of the IP address, such as 255.255.0.0 for a class B address. ifconfig is described in detail in the section Section 5.8.” route allows you to add or remove routes from the kernel routing table. It can be invoked as: route [add|del] [-net|-host] target [if]

The add and del arguments determine whether to add or delete the route to target. The -net and -host arguments tell the route command whether the target is a network or a host (a host is assumed if you don't specify). The if argument is again optional, and allows you to specify to which network interface the route should be directed—the Linux kernel makes a sensible guess if you don't supply this information. This topic will be explained in more detail in succeeding sections.

5.7.1. The Loopback Interface The very first interface to be activated is the loopback interface: # ifconfig lo 127.0.0.1

Occasionally, you will see the dummy hostname localhost being used instead of the IP address. ifconfig will look up the name in the hosts file, where an entry should declare it as the hostname for 127.0.0.1: # Sample /etc/hosts entry for localhost localhost 127.0.0.1

To view the configuration of an interface, you invoke ifconfig, giving it only the interface name as argument: $ ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 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

As you can see, the loopback interface has been assigned a netmask of 255.0.0.0, since 127.0.0.1 is a class A address. Now you can almost start playing with your mini-network. What is still missing is an entry in the routing table that tells IP that it may use this interface as a route to destination 127.0.0.1. This is accomplished by using: # route add 127.0.0.1

Again, you can use localhost instead of the IP address, provided you've entered it into your /etc/hosts. Next, you should check that everything works fine, for example by using ping. ping is the networking equivalent of a sonar device.[1] The command is used to verify that a given address is actually reachable, and to measure the delay that occurs when sending a datagram to it and back again. The time required for this process is often referred to as the “round-trip time”: # ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.4 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.4 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.4 ms ^C --- localhost ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.4/0.4/0.4 ms #

When you invoke ping as shown here, it will continue emitting packets forever, unless interrupted by the user. The ^C marks the place where we pressed Ctrl-C. The previous example shows that packets for 127.0.0.1 are properly delivered and a reply is returned to ping almost instantaneously. This shows that you have successfully set up your first network interface. If the output you get from ping does not resemble that shown in the previous example, you are in trouble. Check any errors if they indicate that some file hasn't been installed properly. Check that the ifconfig and route binaries you use are compatible with the kernel release you run, and above all, that the kernel has been compiled with networking enabled (you see this from the presence of the /proc/net directory). If you get an error message saying “Network unreachable,” you probably got the route command wrong. Make sure you use the same address you gave to ifconfig. The steps previously described are enough to use networking applications on a standalone host. After adding the lines mentioned earlier to your network initialization script and making sure it will be executed at boot time, you may reboot your machine and try out various applications. For instance, telnet localhost should establish a telnet connection to your host, giving you a login: prompt. However, the loopback interface is useful not only as an example in networking books, or as a test bed during development, but is actually used by some applications during normal operation.[2] Therefore, you always have to configure it, regardless of whether your machine is attached to a network or not.

5.7.2. Ethernet Interfaces Configuring an Ethernet interface is pretty much the same as the loopback interface; it just requires a few more parameters when you are using subnetting. At the Virtual Brewery, we have subnetted the IP network, which was originally a class B network, into class C subnetworks. To make the interface recognize this, the ifconfig incantation would look like this: # ifconfig eth0 vstout netmask 255.255.255.0

This command assigns the eth0 interface the IP address of vstout (172.16.1.2). If we omitted the netmask, ifconfig would deduce the netmask from the IP network class, which would result in an incorrect netmask of 255.255.0.0. Now a quick check shows: # ifconfig eth0 eth0 Link encap 10Mps Ethernet HWaddr 00:00:C0:90:B3:42 inet addr 172.16.1.2 Bcast 172.16.1.255 Mask 255.255.255.0 UP BROADCAST RUNNING MTU 1500 Metric 1 RX packets 0 errors 0 dropped 0 overrun 0 TX packets 0 errors 0 dropped 0 overrun 0

You can see that ifconfig automatically sets the broadcast address (the Bcast field) to the usual value, which is the host's network number with all the host bits set. Also, the maximum transmission unit (the maximum size of IP datagrams the kernel will generate for this interface) has been set to the maximum size of Ethernet packets: 1,500 bytes. The defaults are usually what you will use, but all these values can be overidden if required, with special options that will be described under Section 5.8”. Just as for the loopback interface, you now have to install a routing entry that informs the kernel about the network that can be reached through eth0. For the Virtual Brewery, you might invoke route as: # route add -net 172.16.1.0

At first this looks a little like magic, because it's not really clear how route detects which interface to route through. However, the trick is rather simple: the kernel checks all interfaces that have been configured so far and compares the destination address (172.16.1.0 in this case) to the network part of the interface address (that is, the bitwise AND of the interface address and the netmask). The only interface that matches is eth0. Now, what's that –net option for? This is used because route can handle both routes to networks and routes to single hosts (as you saw before with localhost). When given an address in dotted quad notation, route attempts to guess whether it is a network or a hostname by looking at the host part bits. If the address's host part is zero, route assumes it denotes a network; otherwise, route takes it as a host address. Therefore, route would think that 172.16.1.0 is a host address rather than a network number, because it cannot know that we use subnetting. We have to tell route explicitly that it denotes a network, so we give it the –net flag. Of course, the route command is a little tedious to type, and it's prone to spelling mistakes. A more convenient approach is to use the network names we defined in /etc/networks. This approach makes the command much more readable; even the –net flag can be omitted because route knows that 172.16.1.0 denotes a network: # route add brew-net

Now that you've finished the basic configuration steps, we want to make sure that your Ethernet interface is indeed running happily. Choose a host from your Ethernet, for instance vlager, and type: # ping vlager PING vlager: 64 byte packets 64 bytes from 172.16.1.1: icmp_seq=0. time=11. ms 64 bytes from 172.16.1.1: icmp_seq=1. time=7. ms 64 bytes from 172.16.1.1: icmp_seq=2. time=12. ms 64 bytes from 172.16.1.1: icmp_seq=3. time=3. ms ^C ----vstout.vbrew.com PING Statistics---- 4 packets transmitted, 4 packets received, 0 round-trip (ms) min/avg/max = 3/8/12

If you don't see similar output, something is broken. If you encounter unusual packet loss rates, this hints at a hardware problem, like bad or missing terminators. If you don't receive any replies at all, you should check the interface configuration with netstat described later in Section 5.9”. The packet statistics displayed by ifconfig should tell you whether any packets have been sent out on the interface at all. If you have access to the remote host too, you should go over to that machine and check the interface statistics. This way you can determine exactly where the packets got dropped. In addition, you should display the routing information with route to see if both hosts have the correct routing entry. route prints out the complete kernel routing table when invoked without any arguments (–n just makes it print addresses as dotted quad instead of using the hostname): # route -n Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.1 * 255.255.255.255 UH 1 0 112 lo 172.16.1.0 * 255.255.255.0 U 1 0 10 eth0

The detailed meaning of these fields is explained later in Section 5.9." The Flags column contains a list of flags set for each interface. U is always set for active interfaces, and H says the destination address denotes a host. If the H flag is set for a route that you meant to be a network route, you have to reissue the route command with the –net option. To check whether a route you have entered is used at all, check to see if the Use field in the second to last column increases between two invocations of ping.

5.7.3. Routing Through a Gateway In the previous section, we covered only the case of setting up a host on a single Ethernet. Quite frequently, however, one encounters networks connected to one another by gateways. These gateways may simply link two or more Ethernets, but may also provide a link to the outside world, such as the Internet. In order to use a gateway, you have to provide additional routing information to the networking layer. The Ethernets of the Virtual Brewery and the Virtual Winery are linked through such a gateway, namely the host vlager. Assuming that vlager has already been configured, we just have to add another entry to vstout's routing table that tells the kernel it can reach all hosts on the Winery's network through vlager. The appropriate incantation of route is shown below; the gw keyword tells it that the next argument denotes a gateway: # route add wine-net gw vlager

Of course, any host on the Winery network you wish to talk to must have a routing entry for the Brewery's network. Otherwise you would only be able to send data to the Winery network from the Brewery network, but the hosts on the Winery would be unable to reply. This example describes only a gateway that switches packets between two isolated Ethernets. Now assume that vlager also has a connection to the Internet (say, through an additional SLIP link). Then we would want datagrams to any destination network other than the Brewery to be handed to vlager. This action can be accomplished by making it the default gateway for vstout: # route add default gw vlager

The network name default is a shorthand for 0.0.0.0, which denotes the default route. The default route matches every destination and will be used if there is no more specific route that matches. You do not have to add this name to /etc/networks because it is built into route. If you see high packet loss rates when pinging a host behind one or more gateways, this may hint at a very congested network. Packet loss is not so much due to technical deficiencies as to temporary excess loads on forwarding hosts, which makes them delay or even drop incoming datagrams.

5.7.4. Configuring a Gateway Configuring a machine to switch packets between two Ethernets is pretty straightforward. Assume we're back at vlager, which is equipped with two Ethernet cards, each connected to one of the two networks. All you have to do is configure both interfaces separately, giving them their respective IP addresses and matching routes, and that's it. It is quite useful to add information on the two interfaces to the hosts file as shown in the following example, so we have handy names for them, too: 172.16.1.1 vlager.vbrew.com vlager vlager-if1 172.16.2.1 vlager-if2

The sequence of commands to set up the two interfaces is then: # ifconfig eth0 vlager-if1 # route add brew-net # ifconfig eth1 vlager-if2 # route add wine-net

If this sequence doesn't work, make sure your kernel has been compiled with support for IP forwarding enabled. One good way to do this is to ensure that the first number on the second line of /proc/net/snmp is set to 1.

5.7.8. IP Alias New kernels support a feature that can completely replace the dummy interface and serve other useful functions. IP Alias allows you to configure multiple IP addresses onto a physical device. In the simplest case, you could replicate the function of the dummy interface by configuring the host address as an alias onto the loopback interface and completely avoid using the dummy interface. In more complex uses, you could configure your host to look like many different hosts, each with its own IP address. This configuration is sometimes called “Virtual Hosting,” although technically it is also used for a variety of other techniques.[6] To configure an alias for an interface, you must first ensure that your kernel has been compiled with support for IP Alias (check that you have a /proc/net/ip_alias file; if not, you will have to recompile your kernel). Configuration of an IP alias is virtually identical to configuring a real network device; you use a special name to indicate it's an alias that you want. For example: # ifconfig lo:0 172.16.1.1

This command would produce an alias for the loopback interface with the address 172.16.1.1. IP aliases are referred to by appending :n to the actual network device, in which “n” is an integer. In our example, the network device we are creating the alias on is lo, and we are creating an alias numbered zero for it. This way, a single physical device may support a number of aliases. Each alias may be treated as though it is a separate device, and as far as the kernel IP software is concerned, it will be; however, it will be sharing its hardware with another interface.

5.8. All About ifconfig There are many more parameters to ifconfig than we have described so far. Its normal invocation is this: ifconfig interface [address [parameters]] interface is the interface name, and address is the IP address to be assigned to the interface. This may be either an IP address in dotted quad notation or a name that ifconfig will look up in /etc/hosts. If ifconfig is invoked with only the interface name, it displays that interface's configuration. When invoked without any parameters, it displays all interfaces you have configured so far; a –a option forces it to show the inactive ones as well. A sample invocation for the Ethernet interface eth0 may look like this: # ifconfig eth0 eth0 Link encap 10Mbps Ethernet HWaddr 00:00:C0:90:B3:42 inet addr 172.16.1.2 Bcast 172.16.1.255 Mask 255.255.255.0 UP BROADCAST RUNNING MTU 1500 Metric 0 RX packets 3136 errors 217 dropped 7 overrun 26 TX packets 1752 errors 25 dropped 0 overrun 0

The MTU and Metric fields show the current MTU and metric value for that interface. The metric value is traditionally used by some operating systems to compute the cost of a route. Linux doesn't use this value yet, but defines it for compatibility, nevertheless. The RX and TX lines show how many packets have been received or transmitted error free, how many errors occurred, how many packets were dropped (probably because of low memory), and how many were lost because of an overrun. Receiver overruns usually occur when packets come in faster than the kernel can service the last interrupt. The flag values printed by ifconfig roughly correspond to the names of its command-line options; they will be explained later. The following is a list of parameters recognized by ifconfig with the corresponding flag names. Options that simply turn on a feature also allow it to be turned off again by preceding the option name by a dash (–). up

This option makes an interface accessible to the IP layer. This option is implied when an address is given on the command line. It may also be used to reenable an interface that has been taken down temporarily using the down option.

This option corresponds to the flags UP and RUNNING. down

This option marks an interface inaccessible to the IP layer. This effectively disables any IP traffic through the interface. Note that this option will also automatically delete all routing entries that use this interface. netmask mask

This option assigns a subnet mask to be used by the interface. It may be given as either a 32- bit hexadecimal number preceded by 0x, or as a dotted quad of decimal numbers. While the dotted quad format is more common, the hexadecimal representation is often easier to work with. Netmasks are essentially binary, and it is easier to do binary-to-hexadecimal than binary-to-decimal conversion. pointopoint address

This option is used for point-to-point IP links that involve only two hosts. This option is needed to configure SLIP or PLIP interfaces, for example. If a point-to-point address has been set, ifconfig displays the POINTOPOINT flag. broadcast address

The broadcast address is usually made up from the network number by setting all bits of the host part. Some IP implementations (systems derived from BSD 4.2, for instance) use a different scheme in which all host part bits are cleared instead. The broadcast option adapts to these strange environments. If a broadcast address has been set, ifconfig displays the BROADCAST flag. irq

This option allows you to set the IRQ line used by certain devices. This is especially useful for PLIP, but may also be useful for certain Ethernet cards. metric number

This option may be used to assign a metric value to the routing table entry created for the interface. This metric is used by the Routing Information Protocol (RIP) to build routing tables for the network.[1] The default metric used by ifconfig is zero. If you don't run a RIP daemon, you don't need this option at all; if you do, you will rarely need to change the metric value. mtu bytes

This sets the Maximum Transmission Unit, which is the maximum number of octets the interface is able to handle in one transaction. For Ethernets, the MTU defaults to 1,500 (the largest allowable size of an Ethernet packet); for SLIP interfaces, it is 296. (There is no constraint on the MTU of SLIP links; this value is a good compromise.) arp

This is an option specific to broadcast networks such as Ethernets or packet radio. It enables the use of the Address Resolution Protocol (ARP) to detect the physical addresses of hosts attached to the network. For broadcast networks, it is on by default. If ARP is disabled, ifconfig displays the NOARP flag.

–arp

This option disables the use of ARP on this interface. promisc

This option puts the interface in promiscuous mode. On a broadcast network, this makes the interface receive all packets, regardless of whether they were destined for this host or not. This allows network traffic analysis using packet filters and such, also called Ethernet snooping. Usually, this is a good technique for hunting down network problems that are otherwise hard to detect. Tools such as tcpdump rely on this.

On the other hand, this option allows attackers to do nasty things, such as skim the traffic of your network for passwords. You can protect against this type of attack by prohibiting just anyone from plugging their computers into your Ethernet. You could also use secure authentication protocols, such as Kerberos or the secure shell login suite.[2] This option corresponds to the PROMISC flag.

–promisc

This option turns promiscuous mode off. allmulti

Multicast addresses are like Ethernet broadcast addresses, except that instead of automatically including everybody, the only people who receive packets sent to a multicast address are those programmed to listen to it. This is useful for applications like Ethernet-based videoconferencing or network audio, to which only those interested can listen. Multicast addressing is supported by most, but not all, Ethernet drivers. When this option is enabled, the interface receives and passes multicast packets for processing. This option corresponds to the ALLMULTI flag.

–allmulti

This option turns multicast addresses off.

5.9. The netstat Command netstat is a useful tool for checking your network configuration and activity. It is in fact a collection of several tools lumped together. We discuss each of its functions in the following sections.

5.9.1. Displaying the Routing Table When you invoke netstat with the –r flag, it displays the kernel routing table in the way we've been doing with route. On vstout, it produces: # netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 127.0.0.1 * 255.255.255.255 UH 0 0 0 lo 172.16.1.0 * 255.255.255.0 U 0 0 0 eth0 172.16.2.0 172.16.1.1 255.255.255.0 UG 0 0 0 eth0

The –n option makes netstat print addresses as dotted quad IP numbers rather than the symbolic host and network names. This option is especially useful when you want to avoid address lookups over the network (e.g., to a DNS or NIS server). The second column of netstat 's output shows the gateway to which the routing entry points. If no gateway is used, an asterisk is printed instead. The third column shows the “generality” of the route, i.e., the network mask for this route. When given an IP address to find a suitable route for, the kernel steps through each of the routing table entries, taking the bitwise AND of the address and the genmask before comparing it to the target of the route. The fourth column displays the following flags that describe the route: G

The route uses a gateway.

The interface to be used is up.

Only a single host can be reached through the route. For example, this is the case for the loopback entry 127.0.0.1.

This route is dynamically created. It is set if the table entry has been generated by a routing daemon like gated or by an ICMP redirect message (see the section Section 2.5” in Chapter 2).

This route is set if the table entry was modified by an ICMP redirect message.

The route is a reject route and datagrams will be dropped.

The next three columns show the MSS, Window and irtt that will be applied to TCP connections established via this route. The MSS is the Maximum Segment Size and is the size of the largest datagram the kernel will construct for transmission via this route. The Window is the maximum amount of data the system will accept in a single burst from a remote host. The acronym irtt stands for “initial round trip time.” The TCP protocol ensures that data is reliably delivered between hosts by retransmitting a datagram if it has been lost. The TCP protocol keeps a running count of how long it takes for a datagram to be delivered to the remote end, and an acknowledgement to be received so that it knows how long to wait before assuming a datagram needs to retransmitted; this process is called the round-trip time. The initial round-trip time is the value that the TCP protocol will use when a connection is first established. For most network types, the default value is okay, but for some slow networks, notably certain types of amateur packet radio networks, the time is too short and causes unnecessary retransmission. The irtt value can be set using the route command. Values of zero in these fields mean that the default is being used. Finally, the last field displays the network interface that this route will use.

5.9.2. Displaying Interface Statistics When invoked with the –i flag, netstat displays statistics for the network interfaces currently configured. If the –a option is also given, it prints all interfaces present in the kernel, not only those that have been configured currently. On vstout, the output from netstat will look like this: # netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags lo 0 0 3185 0 0 0 3185 0 0 0 BLRU eth0 1500 0 972633 17 20 120 628711 217 0 0 BRU

The MTU and Met fields show the current MTU and metric values for that interface. The RX and TX columns show how many packets have been received or transmitted error-free (RX-OK/TX-OK) or damaged (RX-ERR/TX-ERR); how many were dropped (RX-DRP/TX-DRP); and how many were lost because of an overrun (RX-OVR/TX-OVR). The last column shows the flags that have been set for this interface. These characters are one- character versions of the long flag names that are printed when you display the interface configuration with ifconfig: B A broadcast address has been set.

This interface is a loopback device.

All packets are received (promiscuous mode).

ARP is turned off for this interface.

This is a point-to-point connection.

Interface is running.

Interface is up.

5.9.3. Displaying Connections netstat supports a set of options to display active or passive sockets. The options –t, –u, –w, and – x show active TCP, UDP, RAW, or Unix socket connections. If you provide the –a flag in addition, sockets that are waiting for a connection (i.e., listening) are displayed as well. This display will give you a list of all servers that are currently running on your system. Invoking netstat -ta on vlager produces this output: $ netstat -ta Active Internet Connections Proto Recv-Q Send-Q Local Address Foreign Address (State) tcp 0 0 *:domain *:* LISTEN tcp 0 0 *:time *:* LISTEN tcp 0 0 *:smtp *:* LISTEN tcp 0 0 vlager:smtp vstout:1040 ESTABLISHED tcp 0 0 *:telnet *:* LISTEN tcp 0 0 localhost:1046 vbardolino:telnet ESTABLISHED tcp 0 0 *:chargen *:* LISTEN tcp 0 0 *:daytime *:* LISTEN tcp 0 0 *:discard *:* LISTEN tcp 0 0 *:echo *:* LISTEN tcp 0 0 *:shell *:* LISTEN tcp 0 0 *:login *:* LISTEN

This output shows most servers simply waiting for an incoming connection. However, the fourth line shows an incoming SMTP connection from vstout, and the sixth line tells you there is an outgoing telnet connection to vbardolino.[1] Using the –a flag by itself will display all sockets from all families.

Notes [1] You can tell whether a connection is outgoing from the port numbers. The port number shown for the calling host will always be a simple integer. On the host being called, a well-known service port will be in use for which netstat uses the symbolic name such as smtp, found in /etc/services.

5.10. Checking the ARP Tables On some occasions, it is useful to view or alter the contents of the kernel's ARP tables, for example when you suspect a duplicate Internet address is the cause for some intermittent network problem. The arp tool was made for situations like this. Its command-line options are: arp [-v] [-t hwtype] -a [hostname] arp [-v] [-t hwtype] -s hostname hwaddr arp [-v] -d hostname [hostname…]

All hostname arguments may be either symbolic hostnames or IP addresses in dotted quad notation. The first invocation displays the ARP entry for the IP address or host specified, or all hosts known if no hostname is given. For example, invoking arp on vlager may yield: # arp -a IP address HW type HW address 172.16.1.3 10Mbps Ethernet 00:00:C0:5A:42:C1 172.16.1.2 10Mbps Ethernet 00:00:C0:90:B3:42 172.16.2.4 10Mbps Ethernet 00:00:C0:04:69:AA which shows the Ethernet addresses of vlager, vstout and vale. You can limit the display to the hardware type specified using the –t option. This may be ether, ax25, or pronet, standing for 10 Mbps Ethernet; AMPR AX.25, and IEEE 802.5 token ring equipment, respectively. The –s option is used to permanently add hostname's Ethernet address to the ARP tables. The hwaddr argument specifies the hardware address, which is by default expected to be an Ethernet address specified as six hexadecimal bytes separated by colons. You may also set the hardware address for other types of hardware, using the –t option. For some reason, ARP queries for the remote host sometimes fail, for instance when its ARP driver is buggy or there is another host in the network that erroneously identifies itself with that host's IP address; this problem requires you to manually add an IP address to the ARP table. Hard-wiring IP addresses in the ARP table is also a (very drastic) measure to protect yourself from hosts on your Ethernet that pose as someone else. Invoking arp using the –d switch deletes all ARP entries relating to the given host. This switch may be used to force the interface to re-attempt obtaining the Ethernet address for the IP address in question. This is useful when a misconfigured system has broadcasted wrong ARP information (of course, you have to reconfigure the broken host first). The –s option may also be used to implement proxy ARP. This is a special technique through which a host, say gate, acts as a gateway to another host named fnord by pretending that both addresses refer to the same host, namely gate. It does so by publishing an ARP entry for fnord that points to its own Ethernet interface. Now when a host sends out an ARP query for fnord, gate will return a reply containing its own Ethernet address. The querying host will then send all datagrams to gate, which dutifully forwards them to fnord. These contortions may be necessary when you want to access fnord from a DOS machine with a broken TCP implementation that doesn't understand routing too well. When you use proxy ARP, it will appear to the DOS machine as if fnord was on the local subnet, so it doesn't have to know about how to route through a gateway. Another useful application of proxy ARP is when one of your hosts acts as a gateway to some other host only temporarily, for instance, through a dial-up link. In a previous example, we encountered the laptop vlite, which was connected to vlager through a PLIP link from time to time. Of course, this application will work only if the address of the host you want to provide proxy ARP for is on the same IP subnet as your gateway. vstout could proxy ARP for any host on the Brewery subnet (172.16.1.0), but never for a host on the Winery subnet (172.16.2.0). The proper invocation to provide proxy ARP for fnord is given below; of course, the given Ethernet address must be that of gate: # arp -s fnord 00:00:c0:a1:42:e0 pub

The proxy ARP entry may be removed again by invoking: # arp -d fnord TCPTRACE (Ref: http://www.tcptrace.org/) (Ref: http://masaka.cs.ohiou.edu/software/tcptrace/manual/ ) tcptrace is a tool written by Shawn Ostermann at Ohio University, for analysis of TCP dump files. It can take as input the files produced by several popular packet-capture programs, including tcpdump, snoop, etherpeek, HP Net Metrix, and WinDump. tcptrace can produce several different types of output containing information on each connection seen, such as elapsed time, bytes and segments sent and recieved, retransmissions, round trip times, window advertisements, throughput, and more. It can also produce a number of graphs for further analysis.

Using tcptrace tcptrace can be run on a network dumpfile trivially as in tcptrace dumpfile where dumpfile is a file containing traffic captured from the network. tcptrace understands various network dumpfile formats like tcpdump, snoop, etherpeek, netm, ns, nlanr, netscout. Dumpfiles in these formats can also be compressed in GnuZIP (gz), BZIP2 (bz2), or UNIX compress (Z) formats, as tcptrace can uncompress them on the fly. tcptrace can be passed multiple command-line options to perform various tasks as explained in subsequent chapters. If you want tcptrace to always start processing with certain command-line options, you may store them in .tcptracerc file in your home directory, or set the TCPTRACEOPTS environment variable with the options. tcptrace reads the .tcptracerc file and the TCPTRACEOPTS environment variable before processing options given in command-line. You may also use tcptrace -h to get brief descriptions of various command-line options.

Basic Usage When tcptrace is run trivially on a dumpfile, it generates output similar to the following : Beluga:/Users/mani> tcptrace tigris.dmp

1 arg remaining, starting with 'tigris.dmp' Ostermann's tcptrace -- version 6.4.5 -- Fri Jun 13, 2003

87 packets seen, 87 TCP packets traced elapsed wallclock time: 0:00:00.037900, 2295 pkts/sec analyzed trace file elapsed time: 0:00:12.180796 TCP connection info: 1: pride.cs.ohiou.edu:54735 - elephus.cs.ohiou.edu:ssh (a2b) 30> 30< (complete) 2: pride.cs.ohiou.edu:54736 - a17-112-152-32.apple.com:http (c2d) 12> 15< (complete)

In the above example, tcptrace is run on dumpfile tigris.dmp. The initial lines tell that the file tcptrace is processing currently is tigris.dmp, the version of tcptrace running, and when it was compiled. The next line tells that a total of 87 packets were seen in the dumpfile and all the 87 TCP packets (in this case) were traced. The next line tells that the elapsed wallclock time i.e., the time tcptrace took to process the dumpfile, and the average speed in packets per second taken for processing. The following line indicates the trace file elapsed time i.e., the duration of packet capture of the dumpfile calculated as the duration between the capture of the first and last packets. The subsequent lines indicate the two TCP connections traced from the dumpfile. The first connection was seen between machines pride.cs.ohiou.edu at TCP port 54735, and elephus.cs.ohiou.edu at TCP port ssh (22). Similarly the second connection was seen between machines pride.cs.ohiou.edu at TCP port 54736, and a17-112-152- 32.apple.com at TCP port http (80). tcptrace uses a labeling scheme to refer to individual connections traced. In the above example the two connections are labeled a2b and c2d respectively. For the first connection, 30 packets were seen in the a2b direction (pride.cs.ohiou.edu == > elephus.cs.ohiou.edu) and 30 packets were seen in the b2a direction (elephus.cs.ohiou.edu == > pride.cs.ohiou.edu). The two connections are reported as complete indicating that the entire TCP connection was traced i.e., SYN and FIN segments opening and closing the connection were traced. TCP connections may also be reported as reset if the connection was closed with an RST segment, or unidirectional if traffic was seen flowing in only one direction. The above brief output generated by tcptrace can also be generated with the -b option. In the above example, tcptrace looked up names (elephus.cs.ohiou.edu, for example) and service names (http, for example) involving a DNS name lookup operation. Such name and service lookups can be turned off with the -n option to make tcptrace process faster. If you need name lookups but would rather have the short names of machines (elephus instead of elephus.cs.ohiou.edu for example), use the -s option.

Detailed Usage Detailed Stats tcptrace can produce detailed statistics of TCP connections from dumpfiles when given the -l or the long output option. The -l option produces output similar to the one shown in this example. Beluga:/Users/mani> tcptrace -l malus.dmp.gz

1 arg remaining, starting with 'malus.dmp.gz' Ostermann's tcptrace -- version 6.4.6 -- Tue Jul 1, 2003

32 packets seen, 32 TCP packets traced elapsed wallclock time: 0:00:00.037948, 843 pkts/sec analyzed trace file elapsed time: 0:00:00.404427 TCP connection info: 1 TCP connection traced: TCP connection 1: host a: elephus.cs.ohiou.edu:59518 host b: a17-112-152-32.apple.com:http complete conn: yes first packet: Thu Jul 10 19:12:54.914101 2003 last packet: Thu Jul 10 19:12:55.318528 2003 elapsed time: 0:00:00.404427 total packets: 32 filename: malus.dmp.gz a->b: b->a: total packets: 16 total packets: 16 ack pkts sent: 15 ack pkts sent: 16 pure acks sent: 13 pure acks sent: 2 sack pkts sent: 0 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 0 max sack blks/ack: 0 unique bytes sent: 450 unique bytes sent: 18182 actual data pkts: 1 actual data pkts: 13 actual data bytes: 450 actual data bytes: 18182 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 1 pushed data pkts: 1 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y adv wind scale: 0 adv wind scale: 0 req sack: Y req sack: N sacks sent: 0 sacks sent: 0 urgent data pkts: 0 pkts urgent data pkts: 0 pkts urgent data bytes: 0 bytes urgent data bytes: 0 bytes mss requested: 1460 bytes mss requested: 1460 bytes max segm size: 450 bytes max segm size: 1448 bytes min segm size: 450 bytes min segm size: 806 bytes avg segm size: 449 bytes avg segm size: 1398 bytes max win adv: 40544 bytes max win adv: 33304 bytes min win adv: 5840 bytes min win adv: 33304 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 23174 bytes avg win adv: 33304 bytes initial window: 450 bytes initial window: 1448 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: 450 bytes ttl stream length: 18182 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 420 bytes truncated data: 17792 bytes truncated packets: 1 pkts truncated packets: 13 pkts data xmit time: 0.000 secs data xmit time: 0.149 secs idletime max: 103.7 ms idletime max: 99.9 ms throughput: 1113 Bps throughput: 44957 Bps

The initial lines of output are similar to the brief output explained in Chapter 3. The following lines indicate that the hosts involved in the connection and their TCP port numbers are: host a: elephus.cs.ohiou.edu:59518 host b: a17-112-152-32.apple.com:http

The following lines indicate that the connection was seen to be complete i.e., the connection was traced in its entirety with the SYN and FIN segments of the connection observed in the dumpfile. The time at which the first and last packets of the connection were captured is reported, followed by the lifetime of the connection, and the number of packets seen. Then, the filename currently being processed is listed, followed by the multiple TCP statistics for the forward (a2b) and the reverse (b2a) directions. We explain the TCP parameter statistics in the following, for the a2b direction. Similar explanation would hold for the b2a direction too. • total packets The total number of packets seen. • ack pkts sent The total number of ack packets seen (TCP segments seen with the ACK bit set). • pure acks sent The total number of ack packets seen that were not piggy-backed with data (just the TCP header and no TCP data payload) and did not have any of the SYN/FIN/RST flags set. • sack pkts sent The total number of ack packets seen carrying TCP SACK [4] blocks. • dsack pkts sent The total number of sack packets seen that carried duplicate SACK (D-SACK) [6] blocks. • max sack blks/ack The maximum number of sack blocks seen in any sack packet. • unique bytes sent The number of unique bytes sent, i.e., the total bytes of data sent excluding retransmitted bytes and any bytes sent doing window probing. • actual data pkts The count of all the packets with at least a byte of TCP data payload. • actual data bytes The total bytes of data seen. Note that this includes bytes from retransmissions / window probe packets if any. • rexmt data pkts The count of all the packets found to be retransmissions. • rexmt data bytes The total bytes of data found in the retransmitted packets. • zwnd probe pkts The count of all the window probe packets seen. (Window probe packets are typically sent by a sender when the receiver last advertised a zero receive window, to see if the window has opened up now). • zwnd probe bytes The total bytes of data sent in the window probe packets. • outoforder pkts The count of all the packets that were seen to arrive out of order. • pushed data pkts The count of all the packets seen with the PUSH bit set in the TCP header. • SYN/FIN pkts sent The count of all the packets seen with the SYN/FIN bits set in the TCP header respectively. • req 1323 ws/ts If the endpoint requested Window Scaling/Time Stamp options as specified in RFC 1323[9] a `Y' is printed on the respective field. If the option was not requested, an `N' is printed. For example, an ``N/Y'' in this field means that the window- scaling option was not specified, while the Time-stamp option was specified in the SYN segment. Note that since Window Scaling option is sent only in SYN packets, this field is meaningful only if the connection was captured fully in the dumpfile to include the SYN packets. • adv wind scale The window scaling factor used. Again, this field is valid only if the connection was captured fully to include the SYN packets. Since the connection would use window scaling if and only if both sides requested window scaling [9], this field is reset to 0 (even if a window scale was requested in the SYN packet for this direction), if the SYN packet in the reverse direction did not carry the window scale option. • req sack If the end-point sent a SACK permitted option in the SYN packet opening the connection, a `Y' is printed; otherwise `N' is printed. • sacks sent The total number of ACK packets seen carrying SACK information. • urgent data pkts The total number of packets with the URG bit turned on in the TCP header. • urgent data bytes The total bytes of urgent data sent. This field is calculated by summing the urgent pointer offset values found in packets having the URG bit set in the TCP header. • mss requested The Maximum Segment Size (MSS) requested as a TCP option in the SYN packet opening the connection. • max segm size The maximum segment size observed during the lifetime of the connection. • min segm size The minimum segment size observed during the lifetime of the connection. • avg segm size The average segment size observed during the lifetime of the connection calculated as the value reported in the actual data bytes field divided by the actual data pkts reported. • max win adv The maximum window advertisement seen. If the connection is using window scaling (both sides negotiated window scaling during the opening of the connection), this is the maximum window-scaled advertisement seen in the connection. For a connection using window scaling, both the SYN segments opening the connection have to be captured in the dumpfile for this and the following window statistics to be accurate. • min win adv The minimum window advertisement seen. This is the minimum window- scaled advertisement seen if both sides negotiated window scaling. • zero win adv The number of times a zero receive window was advertised. • avg win adv The average window advertisement seen, calculated as the sum of all window advertisements divided by the total number of packets seen. If the connection endpoints negotiated window scaling, this average is calculated as the sum of all window- scaled advertisements divided by the number of window-scaled packets seen. Note that in the window-scaled case, the window advertisements in the SYN packets are excluded since the SYN packets themselves cannot have their window advertisements scaled, as per RFC 1323[9]. • initial window The total number of bytes sent in the initial window i.e., the number of bytes seen in the initial flight of data before receiving the first ack packet from the other endpoint. Note that the ack packet from the other endpoint is the first ack acknowledging some data (the ACKs part of the 3-way handshake do not count), and any retransmitted packets in this stage are excluded. • initial window The total number of segments (packets) sent in the initial window as explained above. • ttl stream length The Theoretical Stream Length. This is calculated as the difference between the sequence numbers of the SYN and FIN packets, giving the length of the data stream seen. Note that this calculation is aware of sequence space wrap-arounds, and is printed only if the connection was complete (both the SYN and FIN packets were seen). • missed data The missed data, calculated as the difference between the ttl stream length and unique bytes sent. If the connection was not complete, this calculation is invalid and an ``NA'' (Not Available) is printed. • truncated data The truncated data, calculated as the total bytes of data truncated during packet capture. For example, with tcpdump, the snaplen option can be set to 64 (with -s option) so that just the headers of the packet (assuming there are no options) are captured, truncating most of the packet data. In an Ethernet with maximum segment size of 1500 bytes, this would amount to truncated data of 1500 - 64 = 1436 bytes for a packet. • truncated packets The total number of packets truncated as explained above. • data xmit time Total data transmit time, calculated as the difference between the times of capture of the first and last packets carrying non-zero TCP data payload. • idletime max Maximum idle time, calculated as the maximum time between consecutive packets seen in the direction. • throughput The average throughput calculated as the unique bytes sent divided by the elapsed time i.e., the value reported in the unique bytes sent field divided by the elapsed time (the time difference between the capture of the first and last packets in the direction).

RTT Stats RTT (Round-Trip Time) statistics are generated when the -r option is specified along with the -l option (Section 4.1). The following fields of output are produced along with the output generated by the -l option. surya:/home/mani/tcptrace-manual> tcptrace -lr indica.dmp.gz

1 arg remaining, starting with 'indica.dmp.gz' Ostermann's tcptrace -- version 6.4.5 -- Fri Jun 13, 2003

153 packets seen, 153 TCP packets traced elapsed wallclock time: 0:00:00.128422, 1191 pkts/sec analyzed trace file elapsed time: 0:00:19.092645 TCP connection info: 1 TCP connection traced: TCP connection 1: host a: 192.168.0.70:32791 host b: webco.ent.ohiou.edu:23 complete conn: yes first packet: Thu Aug 29 18:54:54.782937 2002 last packet: Thu Aug 29 18:55:13.875583 2002 elapsed time: 0:00:19.092645 total packets: 153 filename: indica.dmp.gz a->b: b->a: total packets: 91 total packets: 62 ...... throughput: 10 Bps throughput: 94 Bps

RTT samples: 48 RTT samples: 47 RTT min: 74.1 ms RTT min: 0.1 ms RTT max: 204.0 ms RTT max: 38.8 ms RTT avg: 108.6 ms RTT avg: 8.1 ms RTT stdev: 44.2 ms RTT stdev: 14.7 ms

RTT from 3WHS: 75.0 ms RTT from 3WHS: 0.1 ms RTT full_sz smpls: 1 RTT full_sz smpls: 1 RTT full_sz min: 79.5 ms RTT full_sz min: 0.1 ms RTT full_sz max: 79.5 ms RTT full_sz max: 0.1 ms RTT full_sz avg: 79.5 ms RTT full_sz avg: 0.1 ms RTT full_sz stdev: 0.0 ms RTT full_sz stdev: 0.0 ms

post-loss acks: 0 post-loss acks: 0

For the following 5 RTT statistics, only ACKs for multiply-transmitted segments (ambiguous ACKs) were considered. Times are taken from the last instance of a segment. ambiguous acks: 1 ambiguous acks: 0 RTT min (last): 76.3 ms RTT min (last): 0.0 ms RTT max (last): 76.3 ms RTT max (last): 0.0 ms RTT avg (last): 76.3 ms RTT avg (last): 0.0 ms RTT sdv (last): 0.0 ms RTT sdv (last): 0.0 ms segs cum acked: 0 segs cum acked: 0 duplicate acks: 0 duplicate acks: 0 triple dupacks: 0 triple dupacks: 0 max # retrans: 1 max # retrans: 0 min retr time: 380.2 ms min retr time: 0.0 ms max retr time: 380.2 ms max retr time: 0.0 ms avg retr time: 380.2 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms

• RTT samples The total number of Round-Trip Time (RTT) samples found. tcptrace is pretty smart about choosing only valid RTT samples. An RTT sample is found only if an ack packet is received from the other endpoint for a previously transmitted packet such that the acknowledgment value is 1 greater than the last sequence number of the packet. Further, it is required that the packet being acknowledged was not retransmitted, and that no packets that came before it in the sequence space were retransmitted after the packet was transmitted. Note : The former condition invalidates RTT samples due to the retransmission ambiguity problem, and the latter condition invalidates RTT samples since it could be the case that the ack packet could be cumulatively acknowledging the retransmitted packet, and not necessarily ack-ing the packet in question. • RTT min The minimum RTT sample seen. • RTT max The maximum RTT sample seen. • RTT avg The average value of RTT found, calculated straightforward-ly as the sum of all the RTT values found divided by the total number of RTT samples. • RTT stdev The standard deviation of the RTT samples. • RTT from 3WHS The RTT value calculated from the TCP 3-Way Hand-Shake (connection opening) [2], assuming that the SYN packets of the connection were captured. • RTT full_sz smpls The total number of full-size RTT samples, calculated from the RTT samples of full-size segments. Full-size segments are defined to be the segments of the largest size seen in the connection. • RTT full_sz min The minimum full-size RTT sample. • RTT full_sz max The maximum full-size RTT sample. • RTT full_sz avg The average full-size RTT sample. • RTT full_sz stdev The standard deviation of full-size RTT samples. • post-loss acks The total number of ack packets received after losses were detected and a retransmission occurred. More precisely, a post-loss ack is found to occur when an ack packet acknowledges a packet sent (acknowledgment value in the ack pkt is 1 greater than the packet's last sequence number), and at least one packet occurring before the packet acknowledged, was retransmitted later. In other words, the ack packet is received after we observed a (perceived) loss event and are recovering from it. • ambiguous acks, RTT min, RTT max, RTT avg, RTT sdv These fields are printed only if there was at least one ack received that was ambiguous due to the retransmission ambiguity problem i.e., the segment being ack-ed was retransmitted and it is impossible to determine if the ack is for the original or the retransmitted packet. Note that these samples are not considered in the RTT samples explained above. The statistics below are calculated from the time of capture of the last transmitted instance of the segment. • ambiguous acks is the total number of such ambiguous acks seen. The following RTT min, RTT max, RTT avg, RTT sdv fields represent the minimum, maximum, average, and standard deviation respectively of the RTT samples calculated from ambiguous acks. • segs cum acked The count of the number of segments that were cumulatively acknowledged and not directly acknowledged. • duplicate acks The total number of duplicate acknowledgments received. An ack packet is found to be a duplicate ack based on this definition used by 4.4 BSD Lite TCP Stack [10] : o The ack packet has the biggest ACK (acknowledgment number) ever seen. o The ack should be pure (carry zero tcp data payload). o The advertised window carried in the ack packet should not change from the last window advertisement. o There must be some outstanding data. Note : older versions of tcptrace (until version 6.4.2) used a legacy algorithm using just the first condition amongst the four listed above, to treat an ack as duplicate ack. This older behavior may be emulated (if necessary at all) with the --turn_off_BSD_dupack option. • triple dupacks The total number of triple duplicate acknowledgments received (three duplicate acknowledgments acknowledging the same segment), a condition commonly used to trigger the fast-retransmit/fast-recovery phase of TCP. • max # retrans The maximum number of retransmissions seen for any segment during the lifetime of the connection. • min retr time The minimum time seen between any two (re)transmissions of a segment amongst all the retransmissions seen. • max retr time The maximum time seen between any two (re)transmissions of a segment. • avg retr time The average time seen between any two (re)transmissions of a segment calculated from all the retransmissions. • sdv retr time The standard deviation of the retransmission-time samples obtained from all the retransmissions. The raw RTT samples found can also be dumped into data files with the -Z option as in tcptrace -Z file.dmp This generates files of the form a2b_rttraw.dat and b2a_rttraw.dat (for both directions of the first TCP connection traced), c2d_rttraw.dat and d2c_rttraw.dat (for the second TCP connection traced) etc. in the working directory. Each of the datafiles contain lines of the form : seq# rtt where seq# is the sequence number of the first byte of the segment being acknowledged (by the ack packet that contributed this RTT sample) and rtt is the RTT value in milli-seconds of the sample. Note that only valid RTT samples (as counted in the RTT Samples field listed above) are dumped.

CWND Stats tcptrace reports statistics on the estimated congestion window with the -W option when used in conjunction with the -l option. Since there is no direct way to determine the congestion window at the TCP sender, the outstanding unacknowledged data is used to estimate the congestion window. The 4 new statistics produced by the -W option in addition to the detailed statistics reported due to the -l option, are explained below. surya:/home/mani/tcptrace-manual> tcptrace -lW malus.dmp.gz

1 arg remaining, starting with 'malus.dmp.gz' Ostermann's tcptrace -- version 6.4.6 -- Tue Jul 1, 2003

32 packets seen, 32 TCP packets traced elapsed wallclock time: 0:00:00.026658, 1200 pkts/sec analyzed trace file elapsed time: 0:00:00.404427 TCP connection info: 1 TCP connection traced: TCP connection 1: host a: elephus.cs.ohiou.edu:59518 host b: A17-112-152-32.apple.com:80 complete conn: yes first packet: Thu Jul 10 19:12:54.914101 2003 last packet: Thu Jul 10 19:12:55.318528 2003 elapsed time: 0:00:00.404427 total packets: 32 filename: malus.dmp.gz a->b: b->a: total packets: 16 total packets: 16 ...... avg win adv: 22091 bytes avg win adv: 33304 bytes

max owin: 451 bytes max owin: 1449 bytes min non-zero owin: 1 bytes min non-zero owin: 1 bytes avg owin: 31 bytes avg owin: 1213 bytes wavg owin: 113 bytes wavg owin: 682 bytes

initial window: 450 bytes initial window: 1448 bytes ...... throughput: 1113 Bps throughput: 44957 Bps

• max owin The maximum outstanding unacknowledged data (in bytes) seen at any point in time in the lifetime of the connection. • min non-zero owin The minimum (non-zero) outstanding unacknowledged data (in bytes) seen. • avg owin The average outstanding unacknowledged data (in bytes), calculated from the sum of all the outstanding data byte samples (in bytes) divided by the total number of samples. • wavg owin The weighted average outstanding unacknowledged data seen. For example, if the outstanding data (odata) was 500 bytes for the first 0.1 seconds, 1000 bytes for the next 1 second, and 2000 bytes for the last 0.1 seconds of a connection that lasted 1.2 seconds, wavg owin= ((500 x 0.1) + (1000 x 1) + (2000 x 0.1)) / 1.2 = 1041.67 bytes an estimate closer to 1000 bytes which was the outstanding data for the most of the lifetime of the connection. Note that the straight-forward average reported in avg owin would have been (500+1000+2000)/1.2 = 2916.67 bytes, a value less indicative of the outstanding data observed during most of the connection's lifetime. ngrep - network grep (Ref: http://ngrep.sourceforge.net/usage.html)

Example: Basic Packet Sniffing Basic packet sniffing is easy with ngrep. It supports BPF filter logic, which means to say constraining what ngrep sees and displays is as easy as saying something like ``ngrep host foo.bar.com and port 25''. Following are a few examples of common invocations of ngrep to do basic packet sniffing. Please note the usage of ``any'' as the specified ethernet adaptor to attach to; in most recent UNIX libpcap implementations this will instruct ngrep to attach to all interfaces at once, local (lo) and all external interfaces that may be active. • ngrep -d any port 25

Monitor all activity crossing source or destination port 25 (SMTP). • ngrep -d any 'error' port syslog

Monitor any network-based syslog traffic for the occurrence of the word ``error''. ngrep knows how to convert service port names (on UNIX, located in ``/etc/services'') to port numbers. • ngrep -wi -d any 'user|pass' port 21

Monitor any traffic crossing source or destination port 21 (FTP), looking case-insensitively for the words ``user'' or ``pass'', matched as word-expressions (the match term(s) must have non-alphanumeric, delimiting characters surrounding them). Example: Debugging HTTP interactions In certain scenarios it is desirous to see how web browsers communicate with web servers, and to inspect the HTTP headers and possibly cookie values that they are exchanging. In this example, we run an ngrep on a webserver. Since it only has one interface, eth0, we omit specifying the interface manually on the command line and allow ngrep to choose the default interface for us, for convenience. # ngrep port 80 interface: eth0 (64.90.164.72/255.255.255.252) filter: ip and ( port 80 ) #### T 67.169.59.38:42167 -> 64.90.164.74:80 [AP] GET / HTTP/1.1..User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i 686) Opera 7.21 [en]..Host: www.darkridge.com..Accept: text/html, applicat ion/xml;q=0.9, application/xhtml+xml;q=0.9, image/png, image/jpeg, image/gi f, image/x-xbitmap, */*;q=0.1..Accept-Charset: iso-8859-1, utf-8, utf-16, * ;q=0.1..Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0..Cookie: SQ MSESSID=5272f9ae21c07eca4dfd75f9a3cda22e..Cookie2: $Version=1..Connection: Keep-Alive, TE..TE: deflate, gzip, chunked, identity, trailers.... ## T 64.90.164.74:80 -> 67.169.59.38:42167 [AP] HTTP/1.1 200 OK..Date: Mon, 29 Mar 2004 00:44:40 GMT..Server: Apache/2.0.49 (Unix)..Last-Modified: Tue, 04 Nov 2003 12:09:41 GMT..ETag: "210e23-326-f8 200b40"..Accept-Ranges: bytes..Vary: Accept-Encoding,User-Agent..Content-En coding: gzip..Content-Length: 476..Keep-Alive: timeout=15, max=100..Connect ion: Keep-Alive..Content-Type: text/html; charset=ISO-8859-1..Content-Langu age: en...... }S]..0.|...... H...8...... @..\....(.....Dw.%.,.. ;.k.....Y>q<...... d ...... 3.i..kdm.u@d{.Q..\[email protected]^..R...... X...... X..y...\.....,..(...... 1...g...... *...j..a.`[email protected].....?. .R.K.j..Y.....>...;kw*U.j.<...\0Tn.l.:...... >Fs....'....h.'...u.H4..'.6.vID I...... N.r.O...}...I.w. ...mX...L.s..{.L.R..-...e....~nu..t.3...H..#..J... .u.?..]....^..2.....e8v/gP.....].48...qD!...... #y...m}..>/?..#...... I ..I..4.P...... 2:...n8l...... !.Yr&... ##

As you can see, all headers and aspects of the HTTP transmission are exposed in their gory detail. It's a little hard to parse though, so let's see what happens when ``-W byline'' mode is used: # ngrep -W byline port 80 interface: eth0 (64.90.164.72/255.255.255.252) filter: ip and ( port 80 ) #### T 67.169.59.38:42177 -> 64.90.164.74:80 [AP] GET / HTTP/1.1. User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera ... Host: www.darkridge.com. Accept: text/html, application/xml;q=0.9, application/xhtml+xml;q=0.9 ... Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1. Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0. Cookie: SQMSESSID=5272f9ae21c07eca4dfd75f9a3cda22e. Cookie2: $Version=1. Cache-Control: no-cache. Connection: Keep-Alive, TE. TE: deflate, gzip, chunked, identity, trailers. .

## T 64.90.164.74:80 -> 67.169.59.38:42177 [AP] HTTP/1.1 200 OK. Date: Mon, 29 Mar 2004 00:47:25 GMT. Server: Apache/2.0.49 (Unix). Last-Modified: Tue, 04 Nov 2003 12:09:41 GMT. ETag: "210e23-326-f8200b40". Accept-Ranges: bytes. Vary: Accept-Encoding,User-Agent. Content-Encoding: gzip. Content-Length: 476. Keep-Alive: timeout=15, max=100. Connection: Keep-Alive. Content-Type: text/html; charset=ISO-8859-1. Content-Language: en...... }S]..0.|...... H...8...... @..\....(.....Dw.%.,..;.k...... ;kw*U.j.<...\0Tn.l.:...... >Fs....'....h.'...u.H4..'.6.vIDI...... N.r ... ..H..#..J....u.?..]....^..2.....e8v/gP.....].48...qD!...... #y...m ... ####

(Content visually truncated for display purposes.) ``-W byline'' mode tells ngrep to respect embedded line feeds when they occur. You'll note from the output above that there is still a trailing dot (``.'') on each line, which is the carriage-return portion of the CRLF pair. Using this mode, now the output has become much easier to visually parse. Example: Processing PCAP dump files, looking for patterns I had a friend who worked at Network Solutions and among the things he did was analyze huge 500M+ PCAP dump files of DNS traffic, looking for patterns and anomalies. ngrep was an invaluable tool for this purpose; it allowed him to take one instance of a network dump and search it quickly and repeatedly for patterns in the data packets. To save a PCAP dump file from ngrep is very easy; simply run ngrep as you normally would but add one more command line option: ``-O some.file.dump'' (the name of the file is largely irrelevant). To illustrate another feature of ngrep, we will use the ``-T'' option (print time differential information). # ngrep -O /tmp/dns.dump -d any -T port domain interface: any filter: ip and ( port domain ) output: /tmp/dns.dump # U +0.000000 203.115.225.24:53 -> 64.90.164.74:53 ...... m.razor2.cloudmark.com...... )...... # U +0.000281 64.90.164.74:53 -> 203.115.225.24:53 ...... m.razor2.cloudmark.com...... '.ns1...hostmaster..ws.. ..p...... :...... )...... # U +0.078184 195.113.155.7:2949 -> 64.90.164.74:53 ...... a.razor2.cloudmark.com..... # U +0.000351 64.90.164.74:53 -> 195.113.155.7:2949 ...... a.razor2.cloudmark.com...... agony...4...... B...... ns1...... ns2...... ns3...X...... @Z.J.j...... @Z...|...... B..; ^Cexit 6 received, 0 dropped

Note the ``output:'' indicator and timestamp information. Now we have a PCAP dump file, and so let's search it for some patterns: # ngrep -w 'm' -I /tmp/dns.dump input: /tmp/dns.dump match: ((^m\W)|(\Wm$)|(\Wm\W)) # U 203.115.225.24:53 -> 64.90.164.74:53 ...... m.razor2.cloudmark.com...... )...... # U 64.90.164.74:53 -> 203.115.225.24:53 ...... m.razor2.cloudmark.com...... '.ns1...hostmaster..ws.. ..p...... :...... )...... ##exit

Above we searched for the letter ``m'', matched as a word (``-w''). This yields two packets. # ngrep -tD ns3 -I /tmp/dns.dump input: /tmp/dns.dump match: ns3 #### U 2004/03/28 20:32:37.088525 64.90.164.74:53 -> 195.113.155.7:2949 ...... a.razor2.cloudmark.com...... agony...4...... B...... ns1...... ns2...... ns3...X...... @Z.J.j...... @Z...|...... B..; exit

Here we've added ``-t'' which means print the absolute timestamp on the packet, and ``-D'' which means replay the packets by the time interval at which they were recorded. The latter is a neat little feature for observing the traffic at the rates/times they originally seen, though in this example it's not terribly effective as there is only one packet being matched. # ngrep -I /tmp/dns.dump port 80 input: /tmp/dns.dump filter: ip and ( port 80 ) exit

There's no port 80 traffic in the dump, so of course the BPF filter yields us no results. Example: Observing binary being transferred across the wire One interesting feature of ngrep is its ability to take a hexademical (binary) expression and search for that in lieu of a regular expression. ngrep can also display the packets it observes in a hexadecimal format, which is more effective for inspecting binary content patterns. In this example, we will simply look for a binary pattern in a web stream, but the more obvious usage is to look for a DDoS Zombie's unique binary signature (say, from a command packet), or even a Worm/Virus being transferred across the wire as it propogates itself. For this test, let's assume we have a GIF on a web server that has the data pattern ``0xc5d5e5f55666768696a6b6c6d6e6'' (hexademical) in it. Once ``-X'' is specified, the expression will be interpreted as a hexademical pattern instead of a regular expression, and the ``0x'' prefix is optional. To see a packet like this cross the wire: # ngrep -xX '0xc5d5e5f55666768696a6b6c6d6e6' port 80 interface: eth0 (64.90.164.72/255.255.255.252) filter: ip and ( port 80 ) match: 0xc5d5e5f55666768696a6b6c6d6e6 ### T 64.90.164.74:80 -> 67.169.59.38:42306 [A] ff d8 ff e0 00 10 4a 46 49 46 00 01 02 01 00 48 ...... JFIF.....H 00 48 00 00 ff ed 13 ba 50 68 6f 74 6f 73 68 6f .H...... Photosho 70 20 33 2e 30 00 38 42 49 4d 03 ed 00 00 00 00 p 3.0.8BIM...... 00 10 00 48 00 00 00 01 00 01 00 48 00 00 00 01 ...H...... H.... 00 01 38 42 49 4d 04 0d 00 00 00 00 00 04 00 00 ..8BIM...... 00 78 38 42 49 4d 03 f3 00 00 00 00 00 08 00 00 .x8BIM...... 00 00 00 00 00 00 38 42 49 4d 04 0a 00 00 00 00 ...... 8BIM...... 00 01 00 00 38 42 49 4d 27 10 00 00 00 00 00 0a ....8BIM'...... 00 01 00 00 00 00 00 00 00 02 38 42 49 4d 03 f5 ...... 8BIM.. 00 00 00 00 00 48 00 2f 66 66 00 01 00 6c 66 66 .....H./ff...lff 00 06 00 00 00 00 00 01 00 2f 66 66 00 01 00 a1 ...... /ff.... 99 9a 00 06 00 00 00 00 00 01 00 32 00 00 00 01 ...... 2.... 00 5a 00 00 00 06 00 00 00 00 00 01 00 35 00 00 .Z...... 5.. 00 01 00 2d 00 00 00 06 00 00 00 00 00 01 38 42 ...-...... 8B 49 4d 03 f8 00 00 00 00 00 70 00 00 ff ff ff ff IM...... p...... ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ...... ff ff 03 e8 00 00 00 00 ff ff ff ff ff ff ff ff ...... ff ff ff ff ff ff ff ff ff ff ff ff ff ff 03 e8 ...... 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ...... ff ff ff ff ff ff ff ff ff ff 03 e8 00 00 00 00 ...... ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ...... ff ff ff ff ff ff 03 e8 00 00 38 42 49 4d 04 08 ...... 8BIM.. 00 00 00 00 00 10 00 00 00 01 00 00 02 40 00 00 ...... @.. 02 40 00 00 00 00 38 42 49 4d 04 14 00 00 00 00 [email protected]...... 00 04 00 00 00 06 38 42 49 4d 04 0c 00 00 00 00 ...... 8BIM...... 12 2a 00 00 00 01 00 00 00 70 00 00 00 57 00 00 .*...... p...W.. 01 50 00 00 72 30 00 00 12 0e 00 18 00 01 ff d8 .P..r0...... ff e0 00 10 4a 46 49 46 00 01 02 01 00 48 00 48 ....JFIF.....H.H 00 00 ff fe 00 26 46 69 6c 65 20 77 72 69 74 74 .....&File writt 65 6e 20 62 79 20 41 64 6f 62 65 20 50 68 6f 74 en by Adobe Phot 6f 73 68 6f 70 a8 20 35 2e 30 ff ee 00 0e 41 64 oshop. 5.0....Ad 6f 62 65 00 64 80 00 00 00 01 ff db 00 84 00 0c obe.d...... 08 08 08 09 08 0c 09 09 0c 11 0b 0a 0b 11 15 0f ...... 0c 0c 0f 15 18 13 13 15 13 13 18 11 0c 0c 0c 0c ...... 0c 0c 11 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c ...... 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 01 ...... 0d 0b 0b 0d 0e 0d 10 0e 0e 10 14 0e 0e 0e 14 14 ...... 0e 0e 0e 0e 14 11 0c 0c 0c 0c 0c 11 11 0c 0c 0c ...... 0c 0c 0c 11 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c ...... 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c ...... ff c0 00 11 08 00 57 00 70 03 01 22 00 02 11 01 ...... W.p..".... 03 11 01 ff dd 00 04 00 07 ff c4 01 3f 00 00 01 ...... ?... 05 01 01 01 01 01 01 00 00 00 00 00 00 00 03 00 ...... 01 02 04 05 06 07 08 09 0a 0b 01 00 01 05 01 01 ...... 01 01 01 01 00 00 00 00 00 00 00 01 00 02 03 04 ...... 05 06 07 08 09 0a 0b 10 00 01 04 01 03 02 04 02 ...... 05 07 06 08 05 03 0c 33 01 00 02 11 03 04 21 12 ...... 3...... !. 31 05 41 51 61 13 22 71 81 32 06 14 91 a1 b1 42 1.AQa."q.2.....B 23 24 15 52 c1 62 33 34 72 82 d1 43 07 25 92 53 #$.R.b34r..C.%.S f0 e1 f1 63 73 35 16 a2 b2 83 26 44 93 54 64 45 ...cs5....&D.TdE c2 a3 74 36 17 d2 55 e2 65 f2 b3 84 c3 d3 75 e3 ..t6..U.e.....u. f3 46 27 94 a4 85 b4 95 c4 d4 e4 f4 a5 b5 c5 d5 .F'...... e5 f5 56 66 76 86 96 a6 b6 c6 d6 e6 f6 37 47 57 ..Vfv...... 7GW 67 77 87 97 a7 b7 c7 d7 e7 f7 11 00 02 02 01 02 gw...... 04 04 03 04 05 06 07 07 06 05 35 01 00 02 11 03 ...... 5..... 21 31 12 04 41 51 61 71 22 13 05 32 81 91 14 a1 !1..AQaq"..2.... b1 42 23 c1 52 d1 f0 33 24 62 e1 72 82 92 43 53 .B#.R..3$b.r..CS 15 63 73 34 f1 25 06 16 a2 b2 83 07 26 35 c2 d2 .cs4.%...... &5.. 44 93 54 a3 17 64 45 55 36 74 65 e2 f2 b3 84 c3 D.T..dEU6te..... d3 75 e3 f3 46 94 a4 85 b4 95 c4 d4 e4 f4 a5 b5 .u..F...... c5 d5 e5 f5 56 66 76 86 96 a6 b6 c6 d6 e6 f6 27 ....Vfv...... ' 37 47 57 67 77 87 97 a7 b7 c7 ff da 00 0c 03 01 7GWgw...... 00 02 11 03 11 00 3f 00 f2 a5 3a ad 35 ba 40 0e ...... ?...:.5.@. 04 16 90 78 20 a8 25 07 94 aa d3 19 18 90 41 a2 ...x .%...... A. 13 9a 4b 9b b9 a0 91 c8 3d c8 ef a7 f2 14 46 35 ..K.....=.....F5 af fe 6c 6f f8 73 e3 3b 7e 92 6a ad 2c 30 75 64 ..lo.s.;~.j.,0ud 82 47 fd f9 a7 f3 5c 8a ec d7 b5 e4 d2 4b 79 0d .G....\...... Ky. 73 a0 ba 3f f2 49 87 8b 61 4d 88 fd de 40 4a 66 s..?.I..aM...@Jf 51 fd e8 c7 e6 ff 00 03 f4 5a ee 63 d8 76 bd a5 Q...... Z.c.v.. a4 76 22 13 29 d9 75 b6 99 b1 ee 7c 71 b8 ca 82 .v".).u....|q... 78 be ad 79 70 f1 1e 1b e1 e9 c5 f3 29 24 92 49 x..yp...... )$.I 0a 49 24 92 52 92 45 c7 c4 bf 25 c5 b4 b7 76 d1 .I$.R.E...%...v. 2e 3c 00 3f 94 ef a2 d5 6f 33 a3 64 e1 63 7a f9 .<.?....o3.d.cz. 0f a9 85 c5 bb 29 f5 18 eb 1c 1c 1d b9 e2 ba 9c .....)...... ff 00 63 36 fe 7a 69 c9 00 44 4c 87 11 da 3d 57 ..c6.zi..DL...=W 8c 59 0c 4c c4 4f 08 fd 2e 8d 3a da e7 1d 8d 11 .Y.L.O....:..... 22 75 47 ca fb 35 78 d5 d2 c2 1f 7c 87 58 f6 ea "uG..5x....|.X.. 06 91 e9 ef fc e4 1b 5f 4c 33 d1 05 a7 68 0f 27 ...... _L3...h.' b9 fc e8 42 4a ac 83 a8 ae 8c 9e e0 84 65 00 23 ...BJ...... e.# 23 21 5c 7f 37 0c 7e 6f 47 f5 9f ff d0 f2 ae ca #!\.7.~oG...... 62 36 c1 3a 1f c0 84 cd 69 71 81 c9 47 a6 f6 e3 b6.:....iq..G... 3f 75 41 af 78 e1 ef 12 27 fe 0d bf f9 24 f1 3e ?uA.x...'....$.> 0d 40 e2 24 55 7f 15 f0 80 91 1c 52 e0 85 eb 2a .@.$U...... R...* e2 ff 00 16 3f a4 c2 fc 5c 8a 1a c7 da c2 c6 d9 ....?...\...... f4 67 c9 05 5f ca ea 37 3c fa 77 1a b2 1b e2 01 .g.._..7<.w..... 81 3d 83 bd 8a 2e a8 67 39 b5 e0 63 90 e6 34 9b .=.....g9..c..4. 00 20 ff 00 68 f1 ec 67 ef a8 63 29 50 e3 00 5f . ..h..g..c)P.._ 51 f2 b3 f3 18 79 70 66 70 e5 26 30 e1 a8 65 1f Q....ypfp.&0..e. ad 9c bf 4e 8e 3e 2c 5f f3 d8 62 f4 dc ac a6 ef ...N.>,_..b..... a8 02 c0 40 73 8b 86 93 fb df 9c b6 3a 66 36 0d ...@s...... :f6. 6c 73 18 45 b7 6a 2c de ls.E.j,. #########

Above we specified ``-X'' to tell ngrep to treat the match expression as hexadecimal, and ``-x'' to tell ngrep to print out the patterns it matches in hexadecimal form. As it turns out, several other packets also matched this pattern, but this should give the prospective user a good idea of how to use hexadecimal patterns and the hex output mode.