IMAP and protocol sniffing. My recent columns (here and here) about struggling with various combinations of the Treo 600, Notes, and Outlook using IMAP clients spurred some very practical reader feedback, a lot of it focused on my reference to protocol sniffing — something that perhaps shouldn't be a last resort as I described in my column:
The next step is setting up a protocol sniffer to see what's really going on at the lowest level, even though everyone knows that pulling out the protocol sniffer is the IT equivalent of the 99-yard Hail Mary pass with no time on the clock.
In my experience at least, command line protocol sniffers can be hard to use if you don't use them regularly (I've always struggled with ethereal and tcpdump for some reason). Bill Campbell of Celestial Systems turned me on to tcpflow, a protocol sniffer that can be used to debug IMAP and anything else that transmits data via a TCP connection. I found it to be immediately useful.
The tcpflow man page explains how it works:
tcpflow is a program that captures data transmitted as part of TCP connections (flows), and stores the data in a way that is convenient for protocol analysis or debugging. A program like tcpdump(4) shows a summary of packets seen on the wire, but usually doesn't store the data that's actually being transmitted. In contrast, tcpflow reconstructs the actual data streams and stores each flow in a separate file for later analysis. tcpflow understands TCP sequence numbers and will correctly reconstruct data streams regardless of retransmissions or out-of-order delivery.
I decided to run tcpflow on my Iaptop to see the IMAP conversation on port 143 (sniffing the wireless interface on my PowerBook) — very easy to read the output:
/usr/local/bin/tcpflow -i en1 -c port 143 [Chad Dickerson]