On Tue, 21 Oct 2014, vDev wrote:
> I am unable to post a pcap file at this point but here is an ASCII
> output. The last ACK (ID: 6200) was considered invalid due to III
> evaluating to 0 and res=0 in the earlier trace.
That cannot be the last ACK, because it's a FIN, ACK packet:
> Linux_Router.1026 > REMOTE_SERVER.63001: Flags [F.], cksum 0xf632
> (correct), seq 31, ack 20, win 1500, length 0
> 16:39:35.328857 IP (tos 0x0, ttl 52, id 6200, offset 0, flags [DF],
> proto TCP (6), length 40)
However, this is still not enough. The debug lines corresponding to the
captured packets are required too. Moreover, previously there were packets
skipping the window checking in the debug log, without enough debug data
to identify them:
> <7>[ 2238.870000] tcp_conntracks:
> <7>[ 2238.870000] syn=0 ack=1 fin=0 rst=0 old=3 new=3
> <7>[ 2238.870000] tcp_conntracks:
> <7>[ 2238.870000] syn=0 ack=1 fin=1 rst=0 old=3 new=4
So please apply this small patch, which adds the missing debug info:
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index 44d1ea3..655170f 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -830,12 +830,16 @@ static int tcp_packet(struct nf_conn *ct,
th = skb_header_pointer(skb, dataoff, sizeof(_tcph), &_tcph);
BUG_ON(th == NULL);
+ pr_debug("tcp_packet: ");
spin_lock_bh(&ct->lock);
old_state = ct->proto.tcp.state;
dir = CTINFO2DIR(ctinfo);
index = get_conntrack_index(th);
new_state = tcp_conntracks[dir][index][old_state];
tuple = &ct->tuplehash[dir].tuple;
+ pr_debug("dir=%u, seq=%u ack=%u win=%u end=%u\n",
+ dir, ntohl(th->seq), ntohl(th->ack_seq), ntohs(th->window),
+ segment_seq_plus_len(ntohl(th->seq), skb->len, dataoff, th));
switch (new_state) {
case TCP_CONNTRACK_SYN_SENT:
and send me the kernel debug messages and the tcpdump recording of the
packet flow. If you must send the tcpdump in ascii, then print absolute
and not relative TCP sequence numbers.
At the moment the only thing I see about the packet flow is that the first
reply packet answering the first FIN does not ack the FIN flag itself.
However the TCP conntrack state table advances the state to CLOSE_WAIT,
instead of keeping the FIN_WAIT state. But that's still not a problem
in handling the next packets.
Best regards,
Jozsef
-
E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
--
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
