Re: diff: fix bpf problem of pipex (was Re: diff: fix LCP keepalive failures on L2TP.)

2012-04-04 Thread Claudio Jeker
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.)

2012-04-04 Thread mxb

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.)

2012-04-03 Thread YASUOKA Masahiko
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();