Hi,
On Thu, 11 Dec 2008, Brian Foster wrote:
> | I sort of imagine this means 250 packets between consecutive ACKs.
>> that's also what I imagine the admin means.
I think you might need the admin to get a little more specific. You're not
even sending data, you're just sending ACKs, so I don't see how the above
could be right.
> | For this to be even remotely plausible you'd need to be sending at
> | a pretty high rate, so perhaps it wouldn't be too tough to replicate,
> | particularly if he/she can tell you the host you were talking with?
>> currently, it's easy enough to get this to happen: there's
> at least two e-mail messages in my IMAP-inbox, both large
> (multiple MiB's), which I cannot read: Kmail (1.9.6) hangs.
> ( I don't know what happens with other e-mail
> clients....? I'll try some after lunch! )
This doesn't make a lot of sense to me. If you were sending data packets
and they were not being ACKed, then the admin's description makes sense.
However, you are receiving data and sending ACKs. You're not sending data
at all in the trace below.
> where "{ME}" is my workstation, and "{IT}" is the server:
>> 12:14:38.133336 IP {ME}.50716 > {IT}.imap2: . ack 3327515 win 5545 <nop,nop,timestamp 126934478 3087447880>
You ACK data up to 3327515 (presumably sent earlier).
> 12:14:38.133578 IP {IT}.imap2 > {ME}.50716: . 3328803:3330091(1288) ack 122 win 143 <nop,nop,timestamp 3087447880 126934469>
> 12:14:38.133581 IP {IT}.imap2 > {ME}.50716: . 3330091:3331379(1288) ack 122 win 143 <nop,nop,timestamp 3087447880 126934469>
It sends you two packets.
> 12:14:38.133593 IP {ME}.50716 > {IT}.imap2: . ack 3330091 win 5545 <nop,nop,timestamp 126934478 3087447880>
You ACK the first of the two data packets above.
> 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>
Two more packets sent, you then ACK the prior one and one of these with a
single "delayed" ACK (perfectly normal, recommended behaviour).
> 12:14:38.134076 IP {IT}.imap2 > {ME}.50716: . 3333955:3335243(1288) ack 122 win 143 <nop,nop,timestamp 3087447880 126934470>
> 12:14:38.134080 IP {IT}.imap2 > {ME}.50716: . 3335243:3336531(1288) ack 122 win 143 <nop,nop,timestamp 3087447880 126934470>
> 12:14:38.134082 IP {IT}.imap2 > {ME}.50716: . 3336531:3337819(1288) ack 122 win 143 <nop,nop,timestamp 3087447880 126934470>
> 12:14:38.134095 IP {ME}.50716 > {IT}.imap2: . ack 3335243 win 5545 <nop,nop,timestamp 126934478 3087447880>
> 12:14:38.134099 IP {ME}.50716 > {IT}.imap2: . ack 3337819 win 5545 <nop,nop,timestamp 126934478 3087447880>
3 more packets (4 now unacked), followed by two ACKs from you, each for a
pair of packets.
> 12:14:38.134324 IP {IT}.imap2 > {ME}.50716: . 3337819:3339107(1288) ack 122 win 143 <nop,nop,timestamp 3087447881 126934470>
> 12:14:38.134328 IP {IT}.imap2 > {ME}.50716: . 3339107:3340395(1288) ack 122 win 143 <nop,nop,timestamp 3087447881 126934470>
Two more data packets from the server.
All the packets are in sequence, every other packet is ACKed. That's
pretty normal I'd say. Could you try with mutt or something else?
> i have absolutely no idea what the above means.
> eyeballing the dump, the above except seems to
> show (as seen from my workstation) what's going
> on once Kmail has hung.
The above looks normal to me. Does it freeze at this point?
> | > does this make sense?
> |
> | In principal, with delayed ACKing, during a bulk transfer, you should
> | generally get an ACK back for every other packet you send. However, this
> | isn't absolutely required. If, for example, some of the ACKs were being
> | lost, as long as an occasional ACK got back, things will proceed as normal.
> | This is arguably the basis of a nasty DoS attack:
> |
> | http://www.hamilton.ie/gavinmc/drop_dupack_attack/>> the admin did say it's a protection against some sort
> of attacks (he wasn't specific and I didn't ask).
The above attack seems not to be that widely known so I'm (pleasantly)
surprised to hear a firewall implements a defence against it. There are
proposals to fix it within TCP, but it's really messy.
Gavin
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!
