FrameSeer Help: Problem Scenario

Problem Scenario

I can’t check my email!

It’s a common lament. When you think about what goes on when you click on the “Check Mail” button, it is amazing that the process is usually so reliable. Consider Figure 1 and assume that the Client needs to get mail from the Mail server.

The client may have a manual TCP/IP configuration, or it may get its setup dynamically via DHCP (another potential can of worms that we’ll ignore for now). We’ll assume that the client is configured as follows:

IP Address 192.168.1.100
Subnet Mask 255.255.255.0
Default Gateway 192.168.1.1
DNS Server 192.168.2.10

In addition, the mail client software (Apple’s Mail, Eudora, Outlook Express) is configured to fetch mail from a name like “mail-host.domain.com”, which the DNS server resolves to 192.168.2.11.

Before the email client software can open a POP3 connection to the mail server, it must first ask the DNS server the question, “what is the IP address for mail-host.domain.com?” The client already knows the IP address of the DNS server (from its TCP/IP configuration) so it can build the DNS query and hand it to IP for transmission.

The first question the client’s IP stack needs to ask is, “is the destination IP address of the DNS server on my local subnet?” It works this out by ANDing the subnet mask against both its own IP address, and the destination IP address. If the masked (“network”) portions are the same, the source and destination devices are on the same subnet.

If the masked portions are not the same, which is the case in our example, the destination device is on a different subnet and the packet must be sent to the router. The client already knows the IP address of its router (the default gateway) and, by definition, the router must be on the same subnet.

At this point, the Address Resolution Protocol (ARP) becomes involved. The client puts the DNS request to one side and creates an ARP request which it broadcasts through its Ethernet interface. The question asked is, “Would the device which has the IP address of 192.168.1.1 please tell me its Ethernet address.” The router will respond with its Ethernet address, which the client then stores in a cache so that it doesn’t have to keep asking the same question every time it sends a packet through the router.

Next, the DNS request is sent over the Ethernet to the router. The router consults its routing tables and sees that it needs to send the packet out of its 192.168.2.1 interface. The router now needs to know the Ethernet address of the DNS server, so it sends out an ARP asking “would 192.168.2.10 please tell me its Ethernet address”, caches the reply, and forwards the DNS request.

The DNS server creates a reply giving 192.168.2.11 as the answer to the client’s original question (“what is the IP address for the mail server?”). Just like the client, the DNS server’s IP stack determines that the reply is going to another subnet, so it issues an ARP to discover the Ethernet address of its router’s interface, caches the answer, and sends the reply to the router, which forwards it back to the client.

DNS requests and replies are transmitted inside UDP datagrams. UDP is often said to be “unreliable”. What that means is that the client has no way of knowing whether the server ever receives the original request. There is no explicit acknowledgement. If the client does not receive a reply, it has no way of knowing whether the problem lies with the server or some point in between.

Assuming the client receives the DNS reply, it now has the IP address of the mail server and can ask TCP to open a connection on the logical port for “POP3” (port 110). The process of opening a TCP “connection” involves a handshake of three packets. The first packet is sent by the client and includes the setting of a special flag called SYN meaning “synchronise sequence numbers”.

The initial SYN packet follows the same path as the DNS request. The client determines that the destination address of the POP3 server is not on the local subnet and sends the packet to the router. The router’s Ethernet address is already in the cache so it doesn’t have to ARP. The router may need to ARP to discover the POP3 server’s Ethernet address but will cache the reply and then forward the SYN packet.

The initial SYN packet arrives at the mail server. Assuming the mail-server software is running, the server will return a packet to the client with two flags called SYN and ACK set. The client reacts to that SYN+ACK packet by sending a packet with only the ACK bit set. The “connection” is now open and the email client software can begin to do its thing.

TCP is said to be “reliable”. The client knows that the server is up and accepting connections and every packet sent is explicitly acknowledged (with an ACK packet). The mere fact that a TCP “connection” can be established tells you a lot about the state of the network.

When a problem occurs, the user’s perception of what is wrong depends upon the how much information the email client software presents.

The user typically has three choices:

Ignore the problem and hope it will go away;
Call the Help Desk or friendly Network Administrator; or
Try to work out where the problem is.

FrameSeer helps with the third option. Even if you can’t fix the problem yourself, you will be in a better position to explain to the Help Desk exactly where the problem is occurring. The following lists some of the things that can go wrong:

Your Macintosh is using the wrong interface.	Check which physical interface FrameSeer selects by default when you open a new document. If it isn’t the interface you expect, then you should check your connections and your Network preferences.
Your interface is down or misconfigured.	Check the status message FrameSeer associates with the physical interface.
FrameSeer stays in “listening” state (no traffic).	You may be connected to your local hub or switch (which will cause Mac OS X to think the interface is up) but the upstream device may be down or disconnected. If you don’t see any traffic after a reasonable period, this is a good place to start.
No ARP request for the router’s MAC address is leaving the client.	If you don’t see the ARP request going out, open a terminal window and type “arp -a”. If you see the router’s IP address and MAC address, it means the MAC address is cached and no ARP is needed. If you think the MAC address is wrong, you can delete it (see [man arp] for details), which will force your Macintosh to re-ARP.
The client is not receiving an ARP reply containing the router’s MAC address.	If you see the ARP request going out but no reply coming back from the router, the router may be down. It may also indicate a misconfigured IP stack on either your client, or the router, or both.
No DNS request for the mail server’s IP address is leaving the client.	If you don’t see the DNS request going out, check your IP configuration. You may not have a DNS server configured.
The client is not receiving a DNS reply containing mail server’s IP address.	If you see the DNS request going out but no reply coming back, the DNS server may be down. It may also indicate that you have the wrong IP address for your DNS server (a fairly common problem when you manually configure your IP stack and the network administrators change the IP address of the DNS server).
You are receiving a DNS reply but it does not contain an answer, or the answer does not seem correct in the light of your experience.	If the DNS can’t translate the name of the mail server into an IP address, it may indicate that the name of the mail server has changed. It may also indicate that the DNS server has been restarted with a bad configuration file.
You see the DNS request going out but the router emits an ICMP packet with a “Destination Unreachable” code.	The router can’t find the route to the destination network. A link is down somewhere or someone has been fiddling with the router’s configuration and gotten it wrong.
You see the TCP SYN packet go out aimed at POP3 but no reply comes back.	In the absence of any other information, this suggests the mail server simply isn’t running.
You see the TCP SYN packet go out aimed at POP3 but the reply packet has the RST flag set.	The mail server is running but is not accepting POP3 connections. The administrator may have taken the service down or the daemon may have crashed and not have been restarted automatically.
You see the TCP handshake (SYN, SYN+ACK, ACK) but the connection is torn down (RST) shortly afterwards.	By inspecting the payload of the reply packets, you will be able to determine whether the mail server is saying “wrong password” or “try again later” or any other administrative message.