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

[Gavin McCullagh]

Hi,

On Thu, 11 Dec 2008, Brian Foster wrote:

>   the admin and I looked at the firewall's diagnostic.
>  it's not too specific, and basically just means there
>  was more than 250 packets which needed some additional
>  processing (I don't recall now the Français term used).
>  the admin speculated that means either than there was
>  more than 250 un-ACK'ed packets, or there were badly
>  fragmented packet(s?).  in essence, the firewall was
>  using too many resources (having to remember too many
>  packets), exceeding its threshold of c.250.

One (probably irrelevant) thing I notice is that your TCP MSS (max segment
size) looks to be a little lower than usual (you get 1288, I see 1448).
Perhaps the fact that it's going through a VPN explains this?  I guess use
of IPv6 might either?

12:14:38.133825 IP {IT}.imap2 > {ME}.50716: . 3331379:3332667(1288) ack 122 win 143 <nop,nop,timestamp 3087447880 126934469>
12:14:38.133831 IP {IT}.imap2 > {ME}.50716: . 3332667:3333955(1288) ack 122 win 143 <nop,nop,timestamp 3087447880 126934469>
12:14:38.133835 IP {ME}.50716 > {IT}.imap2: . ack 3332667 win 5545 <nop,nop,timestamp 126934478 3087447880> 

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

Ideally, windump on windows would show you the MSS (1288 bytes above) which
the imap server is sending to it.

>   the admin also said I'm the only person with this
>  problem.  that probably doesn't mean much since I'm
>  one of the few who runs Linux natively rather than
>  via VMWare on windross.   on the other hand, I can
>  download (via the WebMail interface) the problematic
>  attachment over the internet to my home computer.

As it's not that unusual for this to cause a problem, you might try turning
off window scaling if it's on.

	echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

>   this problem has, as far as I know, has only showed
>  up relatively recently.  the only changes either of
>  us could recall happening was  (1) the replacement
>  of the switch my workstation (and other kit) connects
>  to;  and (2) the moving of the IMAP-server from the
>  local intranet to its own VPN accessed via the firewall
>  (thus creating a pseudo-DMZ containing the IMAP-server).

Sounds like [2] could be the issue and linux's tcp stack is irking the
firewall somehow.

>   the admin suggested trying IMAPS instead of IMAP,
>  but we ran out of time and had to leave before we
>  could conclude that test .....  ;-\ 

It still uses the same tcp stack, so this seems unlikely to matter, but who
knows.

>  ( we also tried to replicate the problem by copying
>   large files across the firewall, but everything
>   worked fine.  this remains an e-mail–only issue?

Was it across the same path of the firewall (ie that vpn) to the email
server?

>   according to the admin, the firewall stops allowing
>  that specific connection.  this seems to be broadly
>  correct, since *nothing*else* is obviously effected:
>  I can, e.g., ‘ping’ machines in the local intranet
>  (both connected to the same switch as my workstation
>  and also those connected elsewhere), and also outside
>  machines on the Wild Wild Web.

> >[ ... ]  The above trace is not functioning at all, apparently
> > not even a network link.  I'd guess you couldn't even ping
> > nearby machines during that period.
> 
>  NO.  *nothing* else behaved strangely during that
>  interval (or before, or after).

Ah, perhaps the STP stuff is normal enough (I'm used to seeing it prior to
a link coming up)  and just no data was tranferring.

Gavin