> On 29 Dec 2014, at 21:03 , Nikolay Denev <nde...@gmail.com> wrote: > > No, no PR yet, but I will file one. I wanted to collect some more data > first. > > So, I've did some dtrace digging : > > [20:54][root@nas:~]#cat reset.d > #!/usr/sbin/dtrace -s > > fbt:kernel:tcp_dropwithreset:entry > { > printf("reason %d fib %d src_port %d dst_port %d", args[4], args[2] ? > args[2]->t_inpcb->inp_inc.inc_fibnum : -1, ntohs(args[1]->th_sport), > ntohs(args[1]->th_dport)); > /* stack(); */ > } > …
> The port numbers here match RST packets that I'm seeing with tcpdump in > another window. > reason 3 is BANDLIM_RST_CLOSEDPORT (from icmp_var.h) > Looking at tcp_input.c I see that there are cases where the INPCB does not > exists, and from what I see this is how the FIB gets determined. > Also here I see that tcp_dropwithreset() is called with tcpcb set to NULL, > so probably this is why the FIB is not found. > > Why this is happening, I have no idea yet. Could you also check for the mbuf *m and the fibnum from the pkthdr there? It might be even more interesting to see this for tcp_respond and the following ip_output as well, in case you want to keep state in the d script; otherwise just tcp_dropwithreset and/or tcp_respond should be fine. Usually I would expect for the tcp_dropwithreset case that inp will be NULL in tcp_respond, the mbuf *m and th will be valid and thus the FIB number from the incoming mbuf would be re-used as the mbuf will be re-used, but for that the mbuf needs to be properly tagged on receive. /bz — Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"