Re: diff: fix bpf problem of pipex (was Re: diff: fix LCP keepalive failures on L2TP.)
On Wed, Apr 04, 2012 at 02:34:46PM +0900, Yasuoka Masahiko wrote: > On Tue, 31 Jan 2012 13:59:17 +0100 > "Sebastian Reitenbach" wrote: > > However, I noted with tcpdump, listening on tun0: > > > > # tcpdump -n -i tun0 > > tcpdump: listening on tun0, link-type LOOP > > 13:51:15.354776 > > tcpdump: WARNING: compensating for unaligned libpcap packets > > 13:51:15.354795 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) > > 13:51:16.334984 > > 13:51:16.334997 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) > > 13:51:17.355463 > (snip) > > The incoming packets look weird, and this is not only true for icmp, > > with tcp/udp its the same. > > Attached diff will fix the problem. > > bpf requires to use different byte order for DLT_LOOP and DLT_NULL on > address family header. pipex works with both pppx(DLT_NULL) and > tun(DLT_LOOP), so it should switch the byte order. > > ok? or comment? Since pppx(4) is only used by npppd/pipex shouldn't we change the DLT there so that we don't need any magic inside pipex? -- :wq Claudio
Re: diff: fix bpf problem of pipex (was Re: diff: fix LCP keepalive failures on L2TP.)
On 04/04/2012 07:34 AM, YASUOKA Masahiko wrote: On Tue, 31 Jan 2012 13:59:17 +0100 "Sebastian Reitenbach" wrote: However, I noted with tcpdump, listening on tun0: # tcpdump -n -i tun0 tcpdump: listening on tun0, link-type LOOP 13:51:15.354776 tcpdump: WARNING: compensating for unaligned libpcap packets 13:51:15.354795 10.66.66.1> 10.66.66.129: icmp: echo reply (DF) 13:51:16.334984 13:51:16.334997 10.66.66.1> 10.66.66.129: icmp: echo reply (DF) 13:51:17.355463 (snip) The incoming packets look weird, and this is not only true for icmp, with tcp/udp its the same. Attached diff will fix the problem. bpf requires to use different byte order for DLT_LOOP and DLT_NULL on address family header. pipex works with both pppx(DLT_NULL) and tun(DLT_LOOP), so it should switch the byte order. ok? or comment? Index: sys/net/pipex.c === RCS file: /cvs/src/sys/net/pipex.c,v retrieving revision 1.26 diff -u -p -r1.26 pipex.c --- sys/net/pipex.c 31 Jan 2012 12:04:20 - 1.26 +++ sys/net/pipex.c 8 Feb 2012 05:23:13 - @@ -1162,8 +1162,13 @@ pipex_ip_input(struct mbuf *m0, struct p len = m0->m_pkthdr.len; #if NBPFILTER> 0 - if (ifp->if_bpf) - bpf_mtap_af(ifp->if_bpf, AF_INET, m0, BPF_DIRECTION_IN); + if (ifp->if_bpf) { + if (ifp->if_type == IFT_TUNNEL) + bpf_mtap_af(ifp->if_bpf, htonl(AF_INET), m0, + BPF_DIRECTION_IN); + else + bpf_mtap_af(ifp->if_bpf, AF_INET, m0, BPF_DIRECTION_IN); + } #endif s = splnet(); @@ -1239,8 +1244,14 @@ pipex_ip6_input(struct mbuf *m0, struct len = m0->m_pkthdr.len; #if NBPFILTER> 0 - if (ifp->if_bpf) - bpf_mtap_af(ifp->if_bpf, AF_INET, m0, BPF_DIRECTION_IN); + if (ifp->if_bpf) { + if (ifp->if_type == IFT_TUNNEL) + bpf_mtap_af(ifp->if_bpf, htonl(AF_INET6), m0, + BPF_DIRECTION_IN); + else + bpf_mtap_af(ifp->if_bpf, AF_INET6, m0, + BPF_DIRECTION_IN); + } #endif s = splnet(); Breaks nothing for me so far. //maxim
diff: fix bpf problem of pipex (was Re: diff: fix LCP keepalive failures on L2TP.)
On Tue, 31 Jan 2012 13:59:17 +0100 "Sebastian Reitenbach" wrote: > However, I noted with tcpdump, listening on tun0: > > # tcpdump -n -i tun0 > tcpdump: listening on tun0, link-type LOOP > 13:51:15.354776 > tcpdump: WARNING: compensating for unaligned libpcap packets > 13:51:15.354795 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) > 13:51:16.334984 > 13:51:16.334997 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) > 13:51:17.355463 (snip) > The incoming packets look weird, and this is not only true for icmp, > with tcp/udp its the same. Attached diff will fix the problem. bpf requires to use different byte order for DLT_LOOP and DLT_NULL on address family header. pipex works with both pppx(DLT_NULL) and tun(DLT_LOOP), so it should switch the byte order. ok? or comment? Index: sys/net/pipex.c === RCS file: /cvs/src/sys/net/pipex.c,v retrieving revision 1.26 diff -u -p -r1.26 pipex.c --- sys/net/pipex.c 31 Jan 2012 12:04:20 - 1.26 +++ sys/net/pipex.c 8 Feb 2012 05:23:13 - @@ -1162,8 +1162,13 @@ pipex_ip_input(struct mbuf *m0, struct p len = m0->m_pkthdr.len; #if NBPFILTER > 0 - if (ifp->if_bpf) - bpf_mtap_af(ifp->if_bpf, AF_INET, m0, BPF_DIRECTION_IN); + if (ifp->if_bpf) { + if (ifp->if_type == IFT_TUNNEL) + bpf_mtap_af(ifp->if_bpf, htonl(AF_INET), m0, + BPF_DIRECTION_IN); + else + bpf_mtap_af(ifp->if_bpf, AF_INET, m0, BPF_DIRECTION_IN); + } #endif s = splnet(); @@ -1239,8 +1244,14 @@ pipex_ip6_input(struct mbuf *m0, struct len = m0->m_pkthdr.len; #if NBPFILTER > 0 - if (ifp->if_bpf) - bpf_mtap_af(ifp->if_bpf, AF_INET, m0, BPF_DIRECTION_IN); + if (ifp->if_bpf) { + if (ifp->if_type == IFT_TUNNEL) + bpf_mtap_af(ifp->if_bpf, htonl(AF_INET6), m0, + BPF_DIRECTION_IN); + else + bpf_mtap_af(ifp->if_bpf, AF_INET6, m0, + BPF_DIRECTION_IN); + } #endif s = splnet();