[sclug] Bizarre IMAP problem

[Roland Turner SCLUG]

Darren Davison wrote:


> I connected only a few minutes ago to my wireless LAN at home, made the
> VPN
> connection to the office and was able to retrieve all the mail via IMAP
> without any problem from that Exchange box.
>
> Having read your mail, I checked the MTU on my wlan0 interface and found
> it
> set to 1356.  So I downed the wireless interface and stuck a cat5 cable
> in the back and sure enough I had the same problem as I had from the
> office
> earlier.


OK, this is _very_ suggestive. PMTU is still sounding like a candidate. A
NIC driver is a remote possibility, but that it worked with WiFi at its
reuced MTU still argues for PMTU.


>  Unfortunately however, reconfiguring the mtu on eth0 down to
> 1200
> made no difference.  After making the VPN connection, it had changed
> again,
> down to 1056 (consistent with the wireless mtu drop) and still the IMAP
> issue
> persisted.


Alex's "mtu 576" suggestion is an interesting one, but note that to make
use of this (basically, if there's a 576 byte MTU link in the path
somewhere (shudder)) you need to reduce it by at least the VPN overhead.
TCP should still work down at the 100 byte mark, but there is also a
(remote) possibility that setting the client's interface MTU is not
actually enough. (Thinking aloud some more; if there is such a link, then
even WiFi wouldn't have been enough, but it was, so there most likely is
not.)


Here's what tweaking the interface MTU is supposed to do:


- When a TCP connection is established, the two parties (we call them
"client" and "server", but TCP does not much care) offer Maximum Segment
Size hints in their initial SYN messages.


- Typically, a host will set its offer by deducting link-, IP- and TCP-
header sizes from the MTU of the interface via which the SYN datagram
leaves. It's not perfect, but is often good enough.


- The "agreed" MSS is supposed to be the lesser of the two offers.


- Assuming that it is (but note that, e.g., iptables has a facility to
tamper with MSS offers, specifically to get around PMTU discovery
problems, but if misused will actually create/exacerbate them), the hosts
will each cut their outbound streams into segments that are no larger in
size than the agreed MSS. Additionally, TCP will never put two segments
into one IP datagram.


- As a result, shrinking the interface MTU on either party will often
cause TCP to keep the size of the datagrams that it sends to less than
whatever size it is that is causing problems with PMTU discovery, without
ever actually solving the underlying problem (which is usually in someone
else's equipment anyway).


The key word in that last paragraph is "often". There are enough broken
TCP implementations, broken firewalls and clue-challenged administrators
in the world to make tricks like this fail sometimes.


The next step will require an examination of the TCP stream (and
particularly the MSS options in the TCP headers and fragmentation bits in
the IP headers) itself. The ideal form is a PCAP dump, but given that
there is presumably a password being passed around, a "tethereal -V"
listing, with the password elided, will do.


Oh, there is one other test that springs to mind: are you able to get the
same host (as has the Exchange server) to feed you bulk TCP data some
other way? Perhaps a web/ftp server with some photographs? Does it have a
similar problem (connection establishent is OK, small control and
negotiation messages are OK, but large payload-shifting datagrams vanish
into the ether before reaching you)?


- Raz