[ILUG] Re: [Q] Max number of TCP(?) packets without waiting for an ACK(?)

Tue Dec 16 13:23:10 GMT 2008

(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
it's relevant,
  | > > 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
 fragments.

  |[ ... ]
  | > > 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
  | apparent.

 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...
   [1]  ?  ?  N   ✓  ✓    Historical situation until some unknown event.
   [2]  0  0  N   ✗  ✓    "Original" situation that started all this.
   [3]  0  0  Y   ✓  ✗
   [4]  1  0  Y   ✓  ✓    Yeah!
   [5]  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 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
 download cutoff?

  |[ ... ]
  | 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
 everything.

  | >    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
  |
  | 	http://www.yuki-onna.co.uk/email/smtp.html
  |
  | 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
 for larger).

  |[ ... ]
  | >    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.

  | Gavin

 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?)!

cheers!
	-blf-

-- 
"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