(apologies for messing up the threading.)
| Date: Mon Dec 15 20:48:05 GMT 2008
| From: Gavin McCullagh gmccullagh at gmail.com
| On Mon, 15 Dec 2008, Brian Foster wrote:
| > > Do you think you could check what the MTU (mss+headers) is on
your PC and
| > > see what it is on others that don't have the issue? I doubt
| > > but when you mention packet fragmentation, I wonder.
| > I have no idea how to check my workstation's MTU, and
| > I've even less of an idea what an MSS is or whether or
| > not that mysterious acronym is part of (included in)
| > the MTU. [ ... ]
| ifconfig will tell you the MTU. [ ... ]
ah, right. Ok, thanks.
my workstation's MTU is the usual, 1500.
I neglected to check the server's.
I have no clew about the firewall's.
| The MSS is TCP's maximum segment size, which is effectively the MTU minus
| the ip header and is usually 1440B. You seem, in bulk transfer, to be
| using shorter packets, which is kind of odd. The guy mentioned packets
| being fragmented which might suggest this.
not quite. he *speculated* that the firewall's complaint
meant it was having to "remember" too many outstanding
|[ ... ]
| > > It's conceivable Linux might be doing path mtu discovery and windows
| > > might not, or something? You can disable that feature:
| > >
| > > echo 1 > proc/sys/net/ipv4/ip_no_pmtu_disc
| >[ ... ]
| Actually, it's the imap server sending to you which is sending short
| packets so I guess it's probably the one which has a curious idea of the
| MTU. I don't know much about path mtu, which should now be readily
neither I nor the admin had ever heard of this Path MTU
Discovery ("p-mtu-d") before. however, it does seem to
be (part of ?) the issue!
both my workstation and the IMAP/SMTP-server were doing
p-mtu-d. here are the results of our tests:
W = Workstation's .../ip_no_pmutu_disc setting (≡ ¬p-mtu-d).
S = IMAP/SMTP-Server's .... .
B = firewall Bypass (workstation whitelisted): Y(es) N(no).
R = Receiving e-mail (IMAP download): ✓ works, ✗ doesn't work.
T = Transmitting e-mail (SMTP upload): .... .
Tst W S B ⇒ R T Comments...
 ? ? N ✓ ✓ Historical situation until some unknown event.
 0 0 N ✗ ✓ "Original" situation that started all this.
 0 0 Y ✓ ✗
 1 0 Y ✓ ✓ Yeah!
 1 1 N ✗ ✓ WTF ?
obviously not a complete set of tests, and there may be
confounding(/confusing) variables we're not aware of or
have forgotten. nonetheless, it seems to point the
finger at MTU-related issue(s?).
whether or not it's the firewall is still a mystery.
the puzzler here is — and I didn't think of this test
until earlier today (apologies!) — is I'm also set up
to IMAP/SMTP with Gmail. that has always(?) worked.
since it clearly goes via "the firewall", we are still
baffled whether or not the firewall is "the" culprit.
I myself wonder if it's the IMAP/SMTP-server which is
at (partial?) fault: it doesn't respond to 'ping's
(I don't know about other forms of ICMP), and from
what I've been reading about p-mtu-d, ICMP with DF
(Don't Fragment) is the basic mechanism for p-mtu-d.
Gmail, in contrast, does respond to 'ping'.
N.b. I'm fairly certain the no-responding is a
server issue, NOT a firewall issue. (I can
always be mistaken, of course, but a test on
the server's own VLAN also didn't respond.)
( I have not hassled the admin about the no-'ping's
issue. the admin's understandably feeling rather
frustrated by the problem, so perhaps it'll be a
new year's hassle?
I also cannot recall whether or not it responded
before being the firewall was introduced; i.e., is
this an unknown/forgotten change on the server? )
|[ ... ]
| > I've no idea about the firewall [ running Linux ].
| > from the little I've seen of the Français interface
| > to the firewall, it looks windross-ish, but I really
| > have no idea.
| I can't say I've seen many windows-based firewalls, it might just be the
I haven't asked the admin, but the firewall's (interface
at least) is called "netasq". a few seconds spent with
Generalissimo Google™ confirms there are firewall-ish
things with that name.
| > [ ... ] today we wasted most of the day trying to grok
| > a problem with being on the whitelist: I now can_not_
| > *send* any e-mail! (SMTP is also handled by the same
| > machine which handles IMAP.)
CORRECTION (my mistake): I *could* send very small
e-mails. the cut-off size isn't clear, over 1KiB but
less than c.4KiB (putting it right in the MTU range in
question). and, I *think*, much smaller than the IMAP
|[ ... ]
| Could it be that you're only whitelisted for IMAP connections and now SMTP
| (another bulk tcp transfer) is now showing the same issue? The transfers
| are in the other direction.
reasonable question, but NO, the whitelist applies to
| > the admin did say the setup is one of those where you
| > have to be authenticated to the IMAP-server before you
| > can use the SMTP-server.
| > I *presume* the firewall is not involved in the SMTP,
| > but I do not know for assorted reasons.
| Perhaps not directly but it may be more involved than you think. [ ... ]
I'd love to do concurrent 'tcpdump's on both the workstation
and server, but I need the admin's co-operation (or at least
acquiescence) for that, which whilst obtainable, I haven't
tried too hard to obtain.
| > I had to leave before I could try a different MUA
| > (or trying to re-configure Claws) which doesn't use
| > IMAP for outgoing-backups. we didn't try spying on
| > what was going on.
| You could send a small email from the command line
| but this will be very little data, so it may not tickle the firewall in the
| right way.
thanks for the link. as I mentioned previously, that's
a trick I have done yonks ago but had since forgotten
most of the details. I tried it, and the results seemed
consistent with the MUAs (Ok for very small, and not Ok
|[ ... ]
| > the other thing we haven't tried yet is using a
| > different workstation. (the admin did suggest this,
| > so I presume that he won't refuse to do this test.)
| In case there's something wrong with your mail spool? I would have thought
| this would be reproduced by your using webmail, but maybe.
at the time the thinking was mostly it'd be a test of
the switch (the other known changed item in the path).
however, the switch was eliminated as a suspect by a
the obvious test.
a remaining puzzle is why just me?
I did learn (just today) there's another native Ubuntu
workstation, but which supposedly does not have the
problem despite using p-mtu-d. the obvious difference
is it's running a much later version (8.10 ? (32-bit))
whilst I'm running 7.10 (64-bit). I need to upgrade to
8.<something> before April (so as to continue to use a
supported Ubuntu version), and since the admin continues
to blame my TCP/IP stack, it seems the path of least
resistance to do the needed-anyways upgrade early in
the new year.
thanks for your help, advice, suggestions, and patience.
whilst we haven't root-caused the problem(s?), neither
the admin nor I am currently too inclined to continue
chasing the issue this year: we seem now, thanks to
one of your suggestions, a work-around the admin will
accept (albeit he'd prefer, and I concur, that I'd not
be on the whitelist).
on the other hand, if you (or anyone else) has some
ideas or suggestions, please feel free to let me know.
*I* would like to root-cause the problem(s?)!
"How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools." | http://www.stopesso.com
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!