Debugging a failing pop mail connection

A user at the remote site of a dedicated T1 connection complained that intermittently he could not send or receive mail. The machine was current with Microsoft patches and his connection to the main office otherwise worked, but mail was often a problem. This was usually blamed on Internet connectivity problems, but when we put in a SME Server at the main office and he still had the problem, it was obvious that something else was wrong.

I began by getting him to a command prompt and asking him to "ping mailserver". He got responses with no packet loss. I checked from the server side that I could ping him also. I then had him "telnet mailserver 110". This did not work, but it wasn't refused: he just could not connect. My suspicion was that he was being blocked at his end, so to confirm it I obtained his IP address and did

arp -d 10.1.1.92
 

to delete him from the arp cache. I then had him try the "telnet mailserver 110" again and noted that his machine did NOT appear in the arp cache (arp -an) . That means that the telnet was definitely blocked. As I said, I suspected his end, so I asked him to disable Norton Anti-Virus entirely and reboot. That instantly fixed it.

Turns out that NAV had expired. Whether that caused the problem or not I don't know, but I left him with the promise that he would download a new NAV. He also had very little memory (128 MB running Win2K), so I suggested that be increased also.

Arp can be very helpful in debugging problems like this.

Got something to add? Send me email.

More Articles by Tony Lawrence

Find me on Google+

© 2012-07-14 Tony Lawrence

"Arp can be very helpful in debugging problems like this."

Yes it can. arp can also be useful in "fixing" DHCP problems caused when machine A, which previously acquired an IP address from the local DHCP server, disappears from sight, and shortly thereafter, machine B goes on-line and gets assigned the same IP address that previously identified machine A. This condition can occur when the arp cache persistence is set very long and the lease time on IP addresses is set very short.

The ultimate problem, of course, is that the MAC address associated with the DHCP-assigned IP address actually belongs to machine A, not B. So even though everything appears to be okay, the IP address is a dead-end. An arp -d of the offending IP address is all that is required to get the kernel to correctly relate to machine B's MAC address.

--BigDumbDinosaur

Actually, that was my very first thought. But since he could ping, that couldn't have been it.

--TonyLawrence

---

Printer Friendly Version

Site map     |      Disclaimer

Debugging a failing pop mail connection Copyright © January 2004 Tony Lawrence

Have you tried Searching this site?

Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version