On Fri, Oct 23, 2009 at 11:44 PM, Carl Michal <michal@xxxxxxxxxxxxxx> wrote: > Eegads, > > so logging the invalid packets (strangely setting ip_conntrack_log_invalid > to 1 didn't actually produce the logs, I had to bypass the check for > LOG_INVALID in nf_conntrack_proto_tcp.c and recompile...) gives: > > Oct 23 23:35:00 spider nf_ct_tcp: ACK is over the upper bound (ACKed data > not seen yet) IN= OUT= SRC=142.103.236.11 DST=142.103.235.177 LEN=52 > TOS=0x00 PREC=0x00 TTL=64 ID=10722 DF PROTO=TCP SPT=44574 DPT=22 > SEQ=3218503158 ACK=2892721343 WINDOW=24840 RES=0x00 ACK URGP=0 OPT > (0101050ACCFD9D1FCCFDA283) > Oct 23 23:35:00 spider nf_ct_tcp: ACK is over the upper bound (ACKed data > not seen yet) IN= OUT= SRC=142.103.236.11 DST=142.103.235.177 LEN=52 > TOS=0x00 PREC=0x00 TTL=64 ID=10723 DF PROTO=TCP SPT=44574 DPT=22 > SEQ=3218503158 ACK=2892721343 WINDOW=24840 RES=0x00 ACK URGP=0 OPT > (0101050ACCFD9D1FCCFDA7E7) > > but how can that be? in the dumps posted earlier, the data had gone > through? Hadn't it? > > Carl > > > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > To be honest im not sure, i didnt have much time to review your entire dump though i did see mass ack/push in the logs. I can spend some time this weekend but it really sounds like your packets are going to the wrong place/device or being dropped somewhere and thats why tcp is not being very reliable. have you tried looking at the network layer? look at your layer3 and see if there are any packet loss on either end during the time where ssh is breaking. btw, UBC? nice ... I went to BCIT ;) -- Payam Tarverdyan Chychi Network Security Specialist / Network Engineer -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
