[sclug] Bizarre IMAP problem

[alan pearson]

I'd put money on the fact that's it's mismatched
duplex / speed settings on the interface.

If it's set to auto-negotiate, it doesn't always work.
I seen exactly the same problem with rsync and was
tearing my hair out. Surfing the web and all  other
normal low-capacity operations seemed to work.

But when I tried heavier traffic (rsync) it fell to
pieces.

Find what your switch is set to & make sure the 2
match.



AlanP

--- "Roland Turner (SCLUG)" <raz.fpyht.bet.hx at raz.cx>
wrote:

> 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
> 
> _______________________________________________
> sclug mailing list
> sclug at sclug.org.uk
> http://www.sclug.org.uk/mailman/listinfo/sclug
>