Pekka Pietikäinen <pp@xxxxxxxxxx> wrote: > On 24/10/13 16:29, Florian Westphal wrote: [ restored nf-devel cc ] > >I don't understand. The packet seen by xt_socket is arriving from > >a remote machine, right? > Virtual machine that's on virbr0 yep, and packet that used to match > should be a synack to a connection initiated from the host. Ah. Now the picture is clear. Underlying tun device in bridge, which uses a socket internally (this is why skb->sk->sk_state is TCP_CLOSE). > bridge-nf-call-iptables = 0 and your patch + bridge-nf-call-iptable > = 1 both made my test work with unmodified xt_socket (and adding > debug prints shows sk_state is now sane) > > Oh. Adding some more debug prints it's the > "inet_sk(sk)->inet_rcv_saddr == 0" part that triggered. > > Before 3.11 sk=nf_tproxy_get_sock_v4() was always done, so I suppose > it was always working on sane data. Yep. When called from bridge netfilter the skb is not orphaned properly, so the tun sk is still around by the time xt_socket is consulted. Thanks for reporting! -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
