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
