From dhartmei@insomnia.benzedrine.cx  Mon May 21 09:37:30 2012
Return-Path: <dhartmei@insomnia.benzedrine.cx>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 7623A106564A;
	Mon, 21 May 2012 09:37:30 +0000 (UTC)
	(envelope-from dhartmei@insomnia.benzedrine.cx)
Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106])
	by mx1.freebsd.org (Postfix) with ESMTP id D19948FC17;
	Mon, 21 May 2012 09:37:29 +0000 (UTC)
Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1])
	by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q4L9RoCY030555
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO);
	Mon, 21 May 2012 11:27:50 +0200 (MEST)
Received: (from dhartmei@localhost)
	by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q4L9Roep024167;
	Mon, 21 May 2012 11:27:50 +0200 (MEST)
Message-Id: <20120521092750.GA20007@insomnia.benzedrine.cx>
Date: Mon, 21 May 2012 11:27:50 +0200
From: Daniel Hartmeier <daniel@benzedrine.cx>
To: Joerg Pulz <Joerg.Pulz@frm2.tum.de>
Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-pf@freebsd.org
In-Reply-To: <201205210726.q4L7Q6m9064258@hades.admin.frm2>
Subject: Re: panic when using pf and route-to (maybe: bad fragment handling?)
References: <201205210726.q4L7Q6m9064258@hades.admin.frm2>

>Number:         168193
>Category:       kern
>Synopsis:       Re: [pf] panic when using pf and route-to (maybe: bad fragment handling?)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-pf
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon May 21 09:40:01 UTC 2012
>Closed-Date:    Tue May 22 02:04:23 UTC 2012
>Last-Modified:  Tue May 22 02:04:23 UTC 2012
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 It looks like the byte order of ip_len is wrong, htons(334) = 19969,
 triggering fragmentation (334 < if_mtu, but 19969 > if_mtu).
 
 The reason is most likely the recursive pf_route() call:
 
 > m_copym() at m_copym+0x280
 > ip_fragment() at ip_fragment+0x1e5
 > pf_route() at pf_route+0x75c
 > pf_test() at pf_test+0xc29
 > pf_route() at pf_route+0x30a
 > pf_test() at pf_test+0xc29
 > pf_check_out() at pf_check_out+0x3a
 > pfil_run_hooks() at pfil_run_hooks+0xd2
 > ip_output() at ip_output+0x655
 
 i.e. the packet is filtered when going out on some interface, matching a
 route-to rule.
 
 Now the packet is filtered again on the routed-to interface. So far ok,
 this is expected.
 
 But now it matches a route-to rule again, possibly the same one, because
 it doesn't restrict the interface.
 
 Usually, this is not intentional (double route-to), and can be fixed by
 checking the route-to rule(s) and making them more restrictive.
 
 Semantics of such route-to chains are not well defined. There's an mbuf
 tag to prevent endless loops, but obviously even short chains are not
 working properly. I'd try to avoid them.
 
 Daniel
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Tue May 22 02:03:44 UTC 2012 
State-Changed-Why:  
Misfiled followup to kern/168190; content migrated. 


Responsible-Changed-From-To: gnats-admin->freebsd-pf 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Tue May 22 02:03:44 UTC 2012 
Responsible-Changed-Why:  

http://www.freebsd.org/cgi/query-pr.cgi?pr=168193 
>Unformatted:
