Re: Socket options KPI

On Fri, 18 Jan 2008, Elad Efrat wrote:

> I have a patch to make a large portion of the network code use a new
> "struct sockopt" (inspired by similar work done in FreeBSD, with input
> from dyoung <at>  and yamt <at> ) instead of passing socket options in mbufs.
>
> The work is incomplete - although I think the majority of the code was
> covered.

I have been corresponding intermittently with Elad on this (he has run out
of time lately and I was busy last month), and the KPI has evolved to be
somewhat less complex.  I wrote a manpage (attached) and have uploaded the
(I think complete now) kernel patch to:

	http://www.netbsd.org/~plunky/sockopt-20080502a.diff

comments?
iain

(some code does still use mbufs, this to be addressed later)

(Elad has done most of the hard work, I've just shuffled around a bit of
whitespace to get credits)

.\"	$NetBSD: sockopt.9$
.\"
.\" Copyright (c) 2008 Iain Hibbert
.\" All rights reserved.

Re: checking m->m_pkthdr.csum_flags in ip_output()

Hi,

In message <20080415.203216.41648300.taca <at> back-street.net>
	on Tue, 15 Apr 2008 20:32:16 +0900 (JST),
	Takahiro Kambe <taca <at> back-street.net> wrote:
> Today, NetBSD 4.0_STABLE machine paniced in ip_output() when
> forwarding IPv4 multicast packet.  The packet was short (36 octets)
> UDP/IP pakcet.
...
> The kernel has DIAGNOSTIC option enabled and corresponding code
> fragments in ip_output().
> 
> #ifdef	DIAGNOSTIC
> 	if ((m->m_flags & M_PKTHDR) == 0)
> 		panic("ip_output: no HDR");
> 
> 	if ((m->m_pkthdr.csum_flags & (M_CSUM_TCPv6|M_CSUM_UDPv6)) != 0) {
> 		panic("ip_output: IPv6 checksum offload flags: %d",
> 		    m->m_pkthdr.csum_flags);
> 	}
> 
> 	if ((m->m_pkthdr.csum_flags & (M_CSUM_TCPv4|M_CSUM_UDPv4)) ==
> 	    (M_CSUM_TCPv4|M_CSUM_UDPv4)) {
> 		panic("ip_output: conflicting checksum offload flags: %d",
> 		    m->m_pkthdr.csum_flags);
> 	}
> #endif
> 
> It seems that this diagnostic code checking M_CSUM_TCPv4 and
> M_CSUM_UDPv4 are exclusive one.

panic: mbuf too short for IPv6 header

Hi,
on a recent -current (kernel sources as of yesterday), I've got several
panic: mbuf too short for IPv6 header

with the stack trace being:
0x0(0xf0c60500, 0x3a, 0x28, 0x169, 0xf2668dcc, 0x28) at netbsd:icmp6_input+0x78
icmp6_input(0xf0c60500, 0xf2668e70, 0x3a, 0xf2668e74, 0x6, 0x1) at netbsd:ip6_input+0x8ec
ip6_input(0x0, 0xe, 0x0, 0xf21474f0, 0x52e1474c, 0xf02ef580) at netbsd:ip6intr+0x68
ip6intr(0xf02ef400, 0xf2668edc, 0xf02ea400, 0x10, 0x44, 0x0) at netbsd:softint_thread+0x90
softint_thread(0xf212d170, 0xf2147980, 0xf02a8ac0, 0x0, 0x904010e1, 0x90401fe1) at netbsd:lwp_trampoline+0x8
End traceback...

I think it's related to running named on this box. Without named running,
the box had been up for several hours; with named the panic occurs in less
than one hour (tried 3 times).

Looking at the mail archives, it seems this issue has already been reported,
but I didn't find a definitive fix. The attached patch mimics code in
ipv4 icmp_input, and makes sure the related mbuf part is contigous and
writeable. With this patch, the box has been up for 13 hours with named
running, without problems. Does it look right ?

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

Index: icmp6.c
===================================================================

Re: panic: mbuf too short for IPv6 header

In article <20080504110028.GA6373 <at> antioche.eu.org>,
Manuel Bouyer  <bouyer <at> antioche.eu.org> wrote:
>-=-=-=-=-=-
>
>Hi,
>on a recent -current (kernel sources as of yesterday), I've got several
>panic: mbuf too short for IPv6 header
>
>with the stack trace being:
>0x0(0xf0c60500, 0x3a, 0x28, 0x169, 0xf2668dcc, 0x28) at netbsd:icmp6_input+0x78
>icmp6_input(0xf0c60500, 0xf2668e70, 0x3a, 0xf2668e74, 0x6, 0x1) at
>netbsd:ip6_input+0x8ec
>ip6_input(0x0, 0xe, 0x0, 0xf21474f0, 0x52e1474c, 0xf02ef580) at
>netbsd:ip6intr+0x68
>ip6intr(0xf02ef400, 0xf2668edc, 0xf02ea400, 0x10, 0x44, 0x0) at
>netbsd:softint_thread+0x90
>softint_thread(0xf212d170, 0xf2147980, 0xf02a8ac0, 0x0, 0x904010e1,
>0x90401fe1) at netbsd:lwp_trampoline+0x8
>End traceback...
>
>I think it's related to running named on this box. Without named running,
>the box had been up for several hours; with named the panic occurs in less
>than one hour (tried 3 times).
>
>Looking at the mail archives, it seems this issue has already been reported,
>but I didn't find a definitive fix. The attached patch mimics code in
>ipv4 icmp_input, and makes sure the related mbuf part is contigous and
>writeable. With this patch, the box has been up for 13 hours with named
>running, without problems. Does it look right ?
>

Clear m->m_pkthdr.csum_flags when forwarding packets!

On Sun, May 04, 2008 at 12:33:05PM +0900, Takahiro Kambe wrote:
> Hi,
> 
> In message <20080415.203216.41648300.taca <at> back-street.net>
> 	on Tue, 15 Apr 2008 20:32:16 +0900 (JST),
> 	Takahiro Kambe <taca <at> back-street.net> wrote:
> > Today, NetBSD 4.0_STABLE machine paniced in ip_output() when
> > forwarding IPv4 multicast packet.  The packet was short (36 octets)
> > UDP/IP pakcet.

This is a bug in the multicast forwarding code (it is related to a bug
I have been investigating in ipf, pf, and bridge).  Look at ip_forward()
and ip_flow(): on NetBSD, if you forward a packet using the same mbuf
in which it was received, you must set csum_flags to 0 before handing
that packet to ip_output.

This is because the same flags were used for "hardware checked checksum
on receive" and "hardware should insert checksum on transmit" which, in
my opinion, was a mistake.  The existing M_CSUM_DATA and M_CSUM_NO_PSEUDOHDR
would have been sufficient for receive, leaving M_CSUM_TCPv4 (etc.) for
transmit use.

As it is now, if you receive such a packet and forward it without looking
inside the UDP or TCP layer, you can in fact cause the hardware to stamp
a *good* checksum on a packet which had a *bad* one when received, because
you won't check for M_CSUM_TCPUDP_BAD, but will send the packet into
ip_output() with M_CSUM_TCPv4 or M_CSUM_UDPv4 set, because that's how it
was received.

Anyway, all code forwarding packets on NetBSD must explicitly set

Re: panic: mbuf too short for IPv6 header

On Sun, May 04, 2008 at 01:00:29PM +0200, Manuel Bouyer wrote:
> +	i = off + sizeof(*icmp6);
> +	if ((m->m_len < i || M_READONLY(m)) && (m = m_pullup(m, i)) == 0) {
> +		ICMP6_STATINC(ICMP6_STAT_TOOSHORT);
> +		icmp6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_error);
> +		goto freeit;
> +	}

You can write that more succinctly with M_UNWRITABLE().

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933 ext 24

Re: Layer 7 filtering

On Thursday 6. April 2006 04:41:29 Michael Richardson wrote:
> >>>>> "Marcin" == Marcin Jessa <lists <at> yazzy.org> writes:
>
>     Marcin> As many of you may know it's PITA to filter bittorrent
>     Marcin> traffic.  One of the most successful ways is to inspect
>
>   Don't. It won't work. People and programs are way too adaptable.

I both agree and disagree. I know of products which can filter at application 
level with success. There are always walk arounds but they're hard to figure 
for a "normal" user.

>     Marcin> layer 7 packets.  Is this possible with any of firewalling
>     Marcin> systems avaliable for NetBSD?
>
>   QoS the traffic that you care about to an appropriate level of
> service.

This is not doable without being able to match layer 7 traffic.
You cannot really do this for specific ports (80,443 etc.) as these ports can 
be (ab)used for something else than what's intended.

Cheers,
Marcin.

Re: panic: mbuf too short for IPv6 header

On Sun, 4 May 2008 13:00:29 +0200
Manuel Bouyer <bouyer <at> antioche.eu.org> wrote:

> Hi,
> on a recent -current (kernel sources as of yesterday), I've got
> several panic: mbuf too short for IPv6 header
> 
> with the stack trace being:
> 0x0(0xf0c60500, 0x3a, 0x28, 0x169, 0xf2668dcc, 0x28) at
> netbsd:icmp6_input+0x78 icmp6_input(0xf0c60500, 0xf2668e70, 0x3a,
> 0xf2668e74, 0x6, 0x1) at netbsd:ip6_input+0x8ec ip6_input(0x0, 0xe,
> 0x0, 0xf21474f0, 0x52e1474c, 0xf02ef580) at netbsd:ip6intr+0x68
> ip6intr(0xf02ef400, 0xf2668edc, 0xf02ea400, 0x10, 0x44, 0x0) at
> netbsd:softint_thread+0x90 softint_thread(0xf212d170, 0xf2147980,
> 0xf02a8ac0, 0x0, 0x904010e1, 0x90401fe1) at netbsd:lwp_trampoline+0x8
> End traceback...
> 
> I think it's related to running named on this box. Without named
> running, the box had been up for several hours; with named the panic
> occurs in less than one hour (tried 3 times).
> 
> Looking at the mail archives, it seems this issue has already been
> reported, but I didn't find a definitive fix. The attached patch
> mimics code in ipv4 icmp_input, and makes sure the related mbuf part
> is contigous and writeable. With this patch, the box has been up for
> 13 hours with named running, without problems. Does it look right ?
> 
Has this been committed?  I just got that panic on what I think is
up-to-date source.

Re: panic: mbuf too short for IPv6 header

On Tue, May 06, 2008 at 07:51:13PM +0000, Steven M. Bellovin wrote:
> On Sun, 4 May 2008 13:00:29 +0200
> Manuel Bouyer <bouyer <at> antioche.eu.org> wrote:
> 
> > Hi,
> > on a recent -current (kernel sources as of yesterday), I've got
> > several panic: mbuf too short for IPv6 header
> > 
> > with the stack trace being:
> > 0x0(0xf0c60500, 0x3a, 0x28, 0x169, 0xf2668dcc, 0x28) at
> > netbsd:icmp6_input+0x78 icmp6_input(0xf0c60500, 0xf2668e70, 0x3a,
> > 0xf2668e74, 0x6, 0x1) at netbsd:ip6_input+0x8ec ip6_input(0x0, 0xe,
> > 0x0, 0xf21474f0, 0x52e1474c, 0xf02ef580) at netbsd:ip6intr+0x68
> > ip6intr(0xf02ef400, 0xf2668edc, 0xf02ea400, 0x10, 0x44, 0x0) at
> > netbsd:softint_thread+0x90 softint_thread(0xf212d170, 0xf2147980,
> > 0xf02a8ac0, 0x0, 0x904010e1, 0x90401fe1) at netbsd:lwp_trampoline+0x8
> > End traceback...
> > 
> > I think it's related to running named on this box. Without named
> > running, the box had been up for several hours; with named the panic
> > occurs in less than one hour (tried 3 times).
> > 
> > Looking at the mail archives, it seems this issue has already been
> > reported, but I didn't find a definitive fix. The attached patch
> > mimics code in ipv4 icmp_input, and makes sure the related mbuf part
> > is contigous and writeable. With this patch, the box has been up for
> > 13 hours with named running, without problems. Does it look right ?
> > 
> Has this been committed? 

Re: panic: mbuf too short for IPv6 header

On Sun, May 04, 2008 at 01:00:29PM +0200, Manuel Bouyer wrote:
> Hi,
> on a recent -current (kernel sources as of yesterday), I've got several
> panic: mbuf too short for IPv6 header
> 
> with the stack trace being:
> 0x0(0xf0c60500, 0x3a, 0x28, 0x169, 0xf2668dcc, 0x28) at netbsd:icmp6_input+0x78
> icmp6_input(0xf0c60500, 0xf2668e70, 0x3a, 0xf2668e74, 0x6, 0x1) at netbsd:ip6_input+0x8ec
> ip6_input(0x0, 0xe, 0x0, 0xf21474f0, 0x52e1474c, 0xf02ef580) at netbsd:ip6intr+0x68
> ip6intr(0xf02ef400, 0xf2668edc, 0xf02ea400, 0x10, 0x44, 0x0) at netbsd:softint_thread+0x90
> softint_thread(0xf212d170, 0xf2147980, 0xf02a8ac0, 0x0, 0x904010e1, 0x90401fe1) at netbsd:lwp_trampoline+0x8
> End traceback...
> 
> I think it's related to running named on this box. Without named running,
> the box had been up for several hours; with named the panic occurs in less
> than one hour (tried 3 times).
> 
> Looking at the mail archives, it seems this issue has already been reported,
> but I didn't find a definitive fix. The attached patch mimics code in
> ipv4 icmp_input, and makes sure the related mbuf part is contigous and
> writeable. With this patch, the box has been up for 13 hours with named
> running, without problems. Does it look right ?

FYI, I commited this patch. I've been running with it for 3 days, without
apparent problems.

--

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer <at> lip6.fr
     NetBSD: 26 ans d'experience feront toujours la difference
--