Networking with OS/2 - by Brian L. Juergensmeyer

elcome back everyone. This month, we are going to take a brief look at two programs, netstat and ifconfig. These two programs are used together to monitor and adjust the bare-bones TCP/IP configuration that your machine has with its server. Both of these programs are inherited, to some extent, from the Unix (or, in this case, AIX) world. (Note however, that at least some of the options available have been changed from a standard BSD (or GNU) distribution. As I do not have access to an AIX (or other server type OS) machine, I don't know if these commands are functionally identical across the spectrum of IBM's operating systems.)

In order to give a demonstration of the usefulness of these programs, we are going to start with a mythical system and a not-so-mythical problem. The problem will be the one that I described last month: your Warp Internet stuff is frustratingly close to working. You can browse the web all day long. You can read Usenet news. You can use Gopher and FTP. You can PING hosts with no problems. You can read e-mail.

You can not, however, send e-mail to anyone, nor can you post to Usenet. You have adhered to the instructions that your ISP gave you, and their tech support (such as it is) is left shaking its head. It is apparent that you have gotten all the help that you are going to get from them and it's now up to you and a few other folks from the Internet to diagnose the problem and solve it.

The first thing that you need to do is to quantify the problem. When does it happen?

We already answered that question above; it happens when you try to send mail or news. Does that suggest a pattern? To an experienced user, it may. However, we need to get a better grip on exactly what is going on. So, we start our TCP/IP connection and whip up an e-mail, try to send it and watch the behavior. Does an error come back immediately from the e-mail attempt? Does the request finally time out and die? (In this situation, let's say our request times out after about 5 minutes.)

After the request finally dies, we open up an OS/2 window and type netstat -?. This will bring up all the ways (and there are quite a few) in which netstat can be used. We use netstat -t.

If you look at the on-line help for TCP/IP in Warp 4, you will note that there is a fairly small (and modestly helpful) section on netstat. It's nested a couple of folders deep in the Assistance Center; look under "Information" and then "Reference and Commands". Below is an actual copy of the output received from running nestat -t on my own Warp 4 PC (in our hypothetical problem, some of these numbers would be greater than zero):

[C:\]netstat -t
TCP STATISTICS .... TYPE ANY KEY TO CONTINUE
connections initiated             0
connections accepted              0
connections established           0
connections dropped               0
embryonic connections dropped     0
conn. closed (includes drops)     0
segs where we tried to get rtt    0
times we succeeded                0
delayed acks sent                 0
conn. dropped in rxmt timeout     0
retransmit timeouts               0
persist timeouts                  0
keepalive timeouts                0
keepalive probes sent             0
connections dropped in keepalive  0
total packets sent                0
data packets sent                 0
data bytes sent                   0
data packets retransmitted        0
data bytes retransmitted          0
TYPE ANY KEY TO CONTINUE
ack-only packets sent             0
window probes sent                0
packets sent with URG only        0
window update-only packets sent   0
control (SYN|FIN|RST) packets sent0
RST packets sent                  0
total packets received            0
packets received in sequence      0
bytes received in sequence        0
packets received with ccksum errs 0
packets received with bad offset  0
packets received too short        0
duplicate-only packets received   0
duplicate-only bytes received     0
packets with some duplicate data  0
dup. bytes in part-dup. packets   0
out-of-order packets received     0
out-of-order bytes received       0
packets with data after window    0
bytes rcvd after window           0
packets rcvd after close          0
rcvd window probe packets         0
TYPE ANY KEY TO CONTINUE
rcvd duplicate acks               0
rcvd acks for unsent data         0
rcvd ack packets                  0
bytes acked by rcvd acks          0
rcvd window update packets        0

The three lines above that we want to look at are the 'retransmit timeouts", "data packets sent" and "data packets retransmitted".

In the case that we are playing detective with right now, let's assume that the numbers on the "data packets sent" and "data packets retransmitted" lines were very close to each other. This would be our first indication of real problems. What this says is that almost every packet sent was retransmitted due to retransmission errors.

In our hypothetical situation there were also a large number of retransmit timeouts. Retransmit timeouts occur because (wisely), the system will only attempt to retransmit a given packet a certain number of times. If a successful transmission of this packet has not occurred by the time the timeout limit has been reached, the system just gives up.

As an aside, you can see that there is a lot of information returned by netstat. Alternatively, typing netstat -u will give udp (instead of tcp) statistics. UDP and TCP (which stand for User Datagram Protocol and Transmission Control Protocol, respectively) are the two most common types of communication protocol found on the internet and they are quite the opposite of each other. For example, a TCP packet (which is used, for instance, by the FTP protocol) requires an acknowledgement (or "ack") when it is received, and the receiver must check whether or not it is intact or needs to be resent. You may think of sending a TCP packet as being like sending an important letter to a friend via registered mail.

UDP, on the other hand, is like sending a standard third-class letter. There is no return receipt (or ack) from the recipient, and if the UDP packet is garbled in transmit, the sending program will not know unless the receiving program (not the operating system or TCP/IP stack) is specifically told to send an error message to the sender.

Now, we know that there is a problem with the packets that we are sending to our server. For some reason, they are getting garbled. But there is one more piece of information that we require before we can put a cohesive picture of the problem together: when we request that a remote server send us some information, very few (if any) of the packets that we receive will be "full" packets. That is, while we have specified an MRU of 1500, very few of the incoming packets will be 1500 bytes. Most of the time, incoming packet size will be very small.

I can not say for certain that this is the reason, but common sense indicates that this is due to the multitasking nature of Internet servers; most Internet servers use an operating system (like OS/2) that is capable of preemptive, round-robin style multitasking. This means that our request to get info from the server gets a certain amount of data until the server preempts our task. When our task comes around again, the server will see the old packet waiting to be sent and will send it immediately. Then a new packet will be constructed.

However, when we send data to our servers, we fill complete packets. All the way up to the 1500 byte limit. So, if we have noisy lines, it is also common sense, given a constant percentage chance of a byte being garbled in transmit, that a packet of 1500 bytes will have at least one garbled byte (and one garbled byte is all it takes to screw up checksum calculations and cause a retransmit request).

Now, we have a hypothesis. What can we do to prove that this is the situation and then solve the problem? That is where ifconfig comes in. Ifconfig is a program that allows us to modify almost all of the parameters of a TCP/IP connection, from the command line. In our case, we will want to modify the MTU size of our ppp0 connection. Our syntax will be:

ifconfig ppp0 mtu 296

This allows us to shrink the size of our maximum transmissible unit from 1500 to 296, thus greatly increasing our chances of getting a packet through unscathed. I chose an MTU size of 296 to make it very small but not too small; OS/2 will not allow you to reduce the MTU below 256 and we want to pick a number slightly above that,just to be safe.

Ifconfig also allows us to modify our IP address by hand. Many of us have, at some point, been forced to rely on using a REXX script in conjunction with the Dial Other Internet Providers applet to connect with our ISPs, and are quite familiar with the ifconfig localhost remotehost statement in our REXX script. In addition to IP address and MTU, you can view a modest number of settings just by typing ifconfig ppp0 for a PPP connection or ifconfig sl0 for a SL/IP connection. By the way, ifconfig does not normally require that you reboot the system to make changes take effect. This can be very useful in troubleshooting or just plain tweaking systems where rebooting is not an option at the time. But be careful and use caution! With such power also comes the ability to make things worse if not used correctly.

The last thing that we need to do is to test this attempt at a solution. We can simply dial our ISP now and try to send an e-mail, or we can try to quantify our improvement in the transmission problem areas. To do this, we must first either reboot or write down the starting points with a call to netstat -t before we start our connection. This is because the netstat log is only reset on reboot.

I'm happy to report that in our (not so) hypothetical case, the mystery was solved, the guilty punished, and I received a commendation from the Chief Detective.

Brian L. Juergensmeyer is a programmer at the VA hospital in Topeka, Kansas. He annoys his IS manager by trying get him to convert from NT/WfW 3.11 to Warp Connect/Warp Server.