There were several "ack storms" on local network, and on services would mean
no gain for anyone to hijack, and apart from that, there were no further
signs of malicious activity (which could have been missed, though).
I was lucky to catch one storm's beginning, and the analysis showed me --
nothing really. I ain't no tcp-internals master, so I don't see the reason of
this ack'ing, or changing the seq/ack expected.
Topology. There is router1 (ip not shown), a local host 1.2.3.4
and a remote host 9.8.7.6, which can be seen through router2 (ip not shown).
Router is 2.0.38, lhost is 2.2.11, router2 (probably irrelevant) 2.0.35. lhost
was dumb enough not to accept redirects so all his outgoing traffic goes to
router1 -> router2 -> rhost, and incoming back -> router2 -> lhost.
Default static routes go thru router1.
The dump was created on router1, so there is only the half part we see, from
router1 to router2. (There was significant other traffic on the segment
which was cut but available if anyone desires). For some reason every packet
is doubled in the dump, either I am lame and messed up something, or it was
duplicated for reason unknown to me. Here is the relevant part, the hosts are
avg. 7ms away:
(i'm commenting for the lazy)
# syn+ack, rhost opened the connection and we ack it
20:18:08.446414 0800 60: 1.2.3.4.80 > 9.8.7.6.3354: S 208054258:208054258(0) ack 729722746 win 32120 <mss 1460> (DF)
20:18:08.446414 0800 58: 1.2.3.4.80 > 9.8.7.6.3354: S 208054258:208054258(0) ack 729722746 win 32120 <mss 1460> (DF)
# normal traffic it seems
20:18:08.866414 0800 60: 1.2.3.4.80 > 9.8.7.6.3354: . ack 331 win 32120 (DF)
20:18:08.866414 0800 54: 1.2.3.4.80 > 9.8.7.6.3354: . ack 331 win 32120 (DF)
20:18:08.866414 0800 1212: 1.2.3.4.80 > 9.8.7.6.3354: P 1:1159(1158) ack 331 win 32120 (DF)
20:18:08.866414 0800 1212: 1.2.3.4.80 > 9.8.7.6.3354: P 1:1159(1158) ack 331 win 32120 (DF)
# 17 sec passed.. other side fin, we ack
20:18:25.845104 0800 60: 1.2.3.4.80 > 9.8.7.6.3354: F 1159:1159(0) ack 331 win 32120 (DF)
20:18:25.845104 0800 54: 1.2.3.4.80 > 9.8.7.6.3354: F 1159:1159(0) ack 331 win 32120 (DF)
# 3 sec passed, and we start to ask for insane sequence numbers...
# and likely the other side, too
20:18:28.494873 0800 60: 1.2.3.4.80 > 9.8.7.6.3354: . ack 2586955442 win 0
20:18:28.494873 0800 54: 1.2.3.4.80 > 9.8.7.6.3354: . ack 2586955442 win 0
20:18:28.504873 0800 60: 1.2.3.4.80 > 9.8.7.6.3354: . ack 2586955442 win 0
20:18:28.504873 0800 54: 1.2.3.4.80 > 9.8.7.6.3354: . ack 2586955442 win 0
20:18:28.514873 0800 60: 1.2.3.4.80 > 9.8.7.6.3354: . ack 2586955442 win 0
20:18:28.514873 0800 54: 1.2.3.4.80 > 9.8.7.6.3354: . ack 2586955442 win 0
20:18:28.534873 0800 60: 1.2.3.4.80 > 9.8.7.6.3354: . ack 2586955442 win 0
20:18:28.534873 0800 54: 1.2.3.4.80 > 9.8.7.6.3354: . ack 2586955442 win 0
20:18:28.544873 0800 60: 1.2.3.4.80 > 9.8.7.6.3354: . ack 2586955442 win 0
20:18:28.544873 0800 54: 1.2.3.4.80 > 9.8.7.6.3354: . ack 2586955442 win 0
20:18:28.554873 0800 60: 1.2.3.4.80 > 9.8.7.6.3354: . ack 2586955442 win 0
# ...ad infinitum...
I changed all hosts to accept redirects (so they would learn to use the correct
router) but I *believe* this is not about routers or redirects, because one
storm was actually between router1 and lhost.... path was straightforward.
If I screwed up somthing obvious please tell me, and forgive me for wasting
the bit pool.
regards,
peter
ps: ip numbers changed for protect the dunnowhat.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/