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

[Gavin McCullagh]

Hi,

On Thu, 11 Dec 2008, Brian Foster wrote:

>   it's entirely possible the 'tcpdump' excerpt I previously
>  sent was done before Kmail hung.  I just tried again, but
>  this time didn't start the 'tcpdump' until the MUA clearly
>  hung.  I say "MUA" (instead of Kmail) because I've tried
>  several now (Claws, Thunderbird, and the server's WebMail
>  interface (twice, once FireFox2 and once Konqueror)).
>  *all* had problems with exactly the same e-mail message.

It would be good to be able to start the tcpdump to file, and then note the
time when you have the issue.  Then stop to the tcpdump and use tcpdump -r
to read it, snipping out the relevant time.

>  ( I've never used 'mutt' before, and when I tried it a
>   few minutes ago, did not understand the interface or
>   configuration ....  ;-\  )

mutt imaps://username@server

should moreorless get you there, but I'm sure thunderbird and claws are
adequate tests.

>   detail-wise, I inadvertently mislead slightly earlier:
>  both of the known problematic e-mails, whilst large (both
>  are c.10MiB, I *think*), are large because both have a
>  gigantic attachment.  (in both cases it's an archive; one
>  is a '.tar.gz' and the other a '.zip').  the attachment is
>  what I cannot (download-and-)open or download-and-save.
> 
>   Konqueror's download status display did clearly indicate
>  the *rate* of the download decreased (steadily?), from
>  an unknown starting rate north of 6MiB and dropping to,
>  ultimately, nil.
> 
>   in any case, below is a 'tcpdump' started after one of
>  the MUA's hung (I don't recall which MUA now).  except
>  for replacing the DNS-names with "{xx}" (where, as before,
>  "{ME}" is my workstation, &tc), this is complete and
>  unedited; i.e., all traffic's shown (c.100 packets,
>  c.90secs).
> 

>   it *is* correct there are *no* "{IT}" (IMAP server).
>  none of the numeric IP- or MAC-addresses are for my
>  workstation ("{ME}").  the server ("{IT}"), apparently
>  inside the DMZ, is not on the 193.168.x.x local intranet.

..... lots of tcpdump, mostly STP ....

> 15:19:32.323068 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 8001.00:19:2f:7f:91:80.8017, length 43
> 15:19:34.336196 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 8001.00:19:2f:7f:91:80.8017, length 43
> 15:19:36.352507 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 8001.00:19:2f:7f:91:80.8017, length 43
> 15:19:38.364571 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 8001.00:19:2f:7f:91:80.8017, length 43
> 15:19:40.378200 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 8001.00:19:2f:7f:91:80.8017, length 43
 
>  unfortunately, the above is all gibberish to me.  ;-\

For some reason, in the above, it appears you are seeing tonnes of Rapid
STP (Spanning Tree) frames.  This looks like the switch checking for
redundant paths in the network.  It looks to me like your network switch
has cut your link to the network.  The fact that no packets are coming to
you backs that up.  Why it went down I'm not sure, it might even be a
faulty network cable which dropped the link for a split second.  If they
have STP turned on on your switch and your port is not configured with
"portfast", the link could take a while to come back up (e.g. 1-2 minutes).

>   |[ ... ]
>   | The above looks normal to me.  Does it freeze at this point?
> 
>  I've no idea!  I *had* thought the previous 'tcpdump'
>  was after a hang, but  (a) based on your description;
>  and  (b) also on the above different known-to-be-after-
>  a-hang, I suspect it was during the downloading before
>  the hang?

It looked to be pretty functioning alright.  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.
 
>  careful!  I did *NOT* say that what the firewall is doing is protecting
>  against that specific DoS attack.  all I said is the admin said it's
>  protecting against *some* (unknown-to-me) attack.

Fair enough :-)

Gavin