From owner-freebsd-pf@FreeBSD.ORG Thu Sep 18 11:29:57 2014 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB2A78C7 for ; Thu, 18 Sep 2014 11:29:57 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B3A6399 for ; Thu, 18 Sep 2014 11:29:57 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8IBTvS1010570 for ; Thu, 18 Sep 2014 11:29:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 168190] [pf] panic when using pf and route-to (maybe: bad fragment handling?) Date: Thu, 18 Sep 2014 11:29:57 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: wwt@op.pl X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-pf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 11:29:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168190 Tomasz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wwt@op.pl --- Comment #24 from Tomasz --- Hello I have the same or similar problem with Dell R210 II kern/193452 I add patch http://www.benzedrine.cx/fbsd-byteorder.diff https://bugs.freebsd.org/bugzilla/attachment.cgi?id=124691&action=diff Index: sys/contrib/ipfilter/netinet/ip_fil_freebsd.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/ip_fil_freebsd.c,v retrieving revision 1.20.4.1 diff -u -r1.20.4.1 ip_fil_freebsd.c --- sys/contrib/ipfilter/netinet/ip_fil_freebsd.c 23 Sep 2011 00:51:37 -0000 1.20.4.1 +++ sys/contrib/ipfilter/netinet/ip_fil_freebsd.c 4 Jun 2012 10:19:04 -0000 @@ -182,8 +182,18 @@ static int fr_check_wrapper(void *arg, struct mbuf **mp, struct ifnet *ifp, int dir) { + int r; + struct ip *ip = mtod(*mp, struct ip *); - return fr_check(ip, ip->ip_hl << 2, ifp, (dir == PFIL_OUT), mp); + ASSERT_HOST_BYTE_ORDER(*mp); + r = fr_check(ip, ip->ip_hl << 2, ifp, (dir == PFIL_OUT), mp); + if (*mp != NULL && (*mp)->m_pkthdr.len >= sizeof(struct ip) && + (*mp)->m_len < sizeof(struct ip)) { + printf("fr_check_wrapper: m_len %d fixed\n", + (int)(*mp)->m_len); + *mp = m_pullup(*mp, sizeof(struct ip)); + } + return r; } # ifdef USE_INET6 For now system work correctly for 3 days without panic and its lot off log message Sep 18 12:50:47 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 12:52:09 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 12:55:50 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:03:26 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:07:53 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:07:56 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:11:13 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:11:36 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:11:36 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:12:01 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:13:07 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:14:24 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:15:45 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:15:49 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:17:16 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:17:55 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:18:35 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:18:57 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:19:23 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:19:30 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:19:34 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:19:43 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:19:56 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:19:56 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:20:02 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:20:08 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:20:24 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:20:24 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:20:33 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed Sep 18 13:25:27 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed 9.2-RELEASE-p10 FreeBSD 9.2-RELEASE-p10 Kernel is Generic with options DEVICE_POLLING options DUMMYNET options IPFILTER_LOG options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPFIREWALL options IPFILTER network card is bce in sysctl I found something strange dev.bce.0.%desc: Broadcom NetXtreme II BCM5716 1000Base-T (C0) dev.bce.1.%desc: Broadcom NetXtreme II BCM5716 1000Base-T (C0) dev.brgphy.0.%desc: BCM5709 10/100/1000baseT PHY dev.brgphy.1.%desc: BCM5709 10/100/1000baseT PHY Best Regards Tomek -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-pf@FreeBSD.ORG Fri Sep 19 00:26:38 2014 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 675752CD for ; Fri, 19 Sep 2014 00:26:38 +0000 (UTC) Received: from maildrop31.somerville.occnc.com (maildrop31.somerville.occnc.com [IPv6:2001:550:3800:203::3131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23C06BD9 for ; Fri, 19 Sep 2014 00:26:38 +0000 (UTC) Received: from harbor31.somerville.occnc.com (harbor31.somerville.occnc.com [IPv6:2001:550:3800:203::3231]) (authenticated bits=128) by maildrop31.somerville.occnc.com (8.14.9/8.14.9) with ESMTP id s8J0QYf8086871; Thu, 18 Sep 2014 20:26:34 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201409190026.s8J0QYf8086871@maildrop31.somerville.occnc.com> To: freebsd-pf@freebsd.org Reply-To: curtis@ipv6.occnc.com Subject: is it possible (practical) to add af-to From: Curtis Villamizar MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86427.1411084275.1@harbor31.somerville.occnc.com> Date: Thu, 18 Sep 2014 20:26:33 -0400 X-Spam-Status: No, score=-101.5 required=5.0 tests=ALL_TRUSTED,MISSING_MID, RP_MATCHES_RCVD,URIBL_BLOCKED,USER_IN_WHITELIST autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on maildrop31.somerville.occnc.com Cc: curtis@ipv6.occnc.com X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 00:26:38 -0000 Hi, NAT46 and NAT64 require af-to or equivalent. This may be naive on my part but it doesn't seem like it would be a lot of trouble to add af-to to the existing pf. That said, I am aware of the discussion of further diverging from the openbsd pf as discussed in the thread in the archives at http://lists.freebsd.org/pipermail/freebsd-pf/2014-July/007391.html I'm willing to contribute code if there is a chance anyone would be willing to take it as an interim until freebsd pf catches up to openbsd pf. Thoughts on this below. Curtis Currently the syntax of rdr and nat accept the following: nat-rule = [ "no" ] "nat" [ "pass" [ "log" [ "(" logopts ")" ] ] ] [ "on" ifspec ] [ af ] [ protospec ] hosts [ "tag" string ] [ "tagged" string ] [ "->" ( redirhost | "{" redirhost-list "}" ) [ portspec ] [ pooltype ] [ "static-port" ] ] rdr-rule = [ "no" ] "rdr" [ "pass" [ "log" [ "(" logopts ")" ] ] ] [ "on" ifspec ] [ af ] [ protospec ] hosts [ "tag" string ] [ "tagged" string ] [ "->" ( redirhost | "{" redirhost-list "}" ) [ portspec ] [ pooltype ] ] Both of these end in: [ "->" ( redirhost | "{" redirhost-list "}" ) [ portspec ] [ pooltype ] ] (with nat-rule having the optional [ "static-port" ]). Changing the syntax is no big deal and that would be the easy part. In sbin/pf/parse.y some change would be needed to the redirpool rule where the two forms are (yacc actions omitted): redirpool : | ARROW redirspec | ARROW redirspec PORT portstar to this (or to redirspec) we'd have to add an af_to which would be similar to the af rule but with the keywork af-to: af_to ; /* empty */ { $$ = 0; } | AF_TO INET { $$ = AF_INET; } | AF_TO INET6 { $$ = AF_INET6; } If this is added to the redirpool then af_to would appear after ARROW and $2 and $4 are bumped. It means adding sa_family_t af to the struct redirection. In the natrule rule if ((! $9->af) || (r.af == $9->af)), then nothing needs to be done, else an address family translation is needed. The following lines have to be changed, replacing r.af with $9->af adding a line before this to replace 0 with r.af if af_to was empty. remove_invalid_hosts(&$9->host, &r.af); if (invalid_redirect($9->host, r.af)) YYERROR; if (check_netmask($9->host, r.af)) YYERROR; At this point the rule can be one address family and all of the redirect addresses consistent with each other but not necissarily the same af as the rule. The next problem is that there is no way to pass this af to expand_rule. That's OK since $9->host ends up as the protos argument to expand_rule and the af is in each entry. On this case the af in proto won't match the af in src_hosts and the consistency checks (nat_consistent, rdr_consistent) don't check and its off to pfctl_add_rule. This gets us to a laer ioctl call of type DIOCADDRULE which puts us in the kernel code in pf_ioctl.c. In the case DIOCADDRULE code the checks of pr->rule.af are no longer enough. Similar checks are needed on the rule actions. Something along the lines of: #ifndef INET if (pr->rule.af == AF_INET) { error = EAFNOSUPPORT; break; } if ((pr->rule.action == PF_NAT) || (pr->rule.action == PF_RDR)) { if (rule_dst_has_af(pr->rule.dst.addr), AF_INET) { error = EAFNOSUPPORT; break: } } #endif /* INET */ Where rule_dst_has_af loops through the table and checks for instances of the af in the argument list. Where the real work would have to be done is in pf_test, pf_test_rule, pf_get_translation, pf_match_translation, and pf_create_state, and some functions they use, such as pf_map_addr where mixed af is not anticipated. This would definitely be the messy part of any attempt to make af-to work. There is no INET/INET6 specific code in pf_test_rule except for ICMP there is no INET/INET6 specific code and getting the packet length when dropping TCP and sending a RST. As a first cut, if ICMP from/to ICMP6 in NAT and RDR didn't work that would be OK. A FAIL would send back TCP RST using the source af, so that code should be OK. My understanding of this code is still very fuzzy after about a half day of looking at it. Perhaps looking at the openbsd pf would help (hopefully they still resemble each other). Any help would be appreciated, but for now I'd just like to know whether if I took the trouble to add af-to support the code would be picked up (after code review, testing, etc). I haven't yet decided whether this is something I want to take on in the first place. From owner-freebsd-pf@FreeBSD.ORG Fri Sep 19 08:22:03 2014 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6940AB4F for ; Fri, 19 Sep 2014 08:22:03 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D4E9B6A for ; Fri, 19 Sep 2014 08:22:03 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kq14so3385145pab.33 for ; Fri, 19 Sep 2014 01:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DTeVEdS2v8BDtC0kLBOLBzTeYQe6r4M50vTZqcAncck=; b=f2Kju6WiJDnjT8i72907ZwolEePdivBtAQCduQlifN+77fPBjNBFYAu7tQYwop2lcE ra3Q0aAlcda1kRo3BcdOgo746mfV5TP32DnnP7LGNwom4nEOGOJJEiRtYB6CVqhJUqGp UH7Mj6vtMvdgi0xm3tzi6wZfIaQxAsLpV5GhNEFHdLxGkxTzg+efD9x69hg8muAc7PlV 1rUAbSi/AgVq8dne5ckV6hBrZQKtZtSfpHRmvp93E+3XOHl8+zrc4XyrLGsx4m+JE22e yWFZmTAuLp6ESlimlAcKEvlhz6ahGs88Wc3/snQJDVItPayBSeMavwdibNZxINtr76cF HFXg== MIME-Version: 1.0 X-Received: by 10.68.134.72 with SMTP id pi8mr7236102pbb.86.1411114922617; Fri, 19 Sep 2014 01:22:02 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.70.102.80 with HTTP; Fri, 19 Sep 2014 01:22:02 -0700 (PDT) In-Reply-To: <201409190026.s8J0QYf8086871@maildrop31.somerville.occnc.com> References: <201409190026.s8J0QYf8086871@maildrop31.somerville.occnc.com> Date: Fri, 19 Sep 2014 10:22:02 +0200 X-Google-Sender-Auth: 3IVxcoIMf97q0l4h6EJQJbUr2Pw Message-ID: Subject: Re: is it possible (practical) to add af-to From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: curtis@ipv6.occnc.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-pf@freebsd.org" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 08:22:03 -0000 Hello Curtis, On Fri, Sep 19, 2014 at 2:26 AM, Curtis Villamizar wrote: > Hi, > > NAT46 and NAT64 require af-to or equivalent. > > This may be naive on my part but it doesn't seem like it would be a > lot of trouble to add af-to to the existing pf. > > That said, I am aware of the discussion of further diverging from the > openbsd pf as discussed in the thread in the archives at > http://lists.freebsd.org/pipermail/freebsd-pf/2014-July/007391.html > > I'm willing to contribute code if there is a chance anyone would be > willing to take it as an interim until freebsd pf catches up to > openbsd pf. > > Thoughts on this below. > I have interest on this. Though it would be necessary to pickup the IPv6 header parsing code together with this. It is related to both to be able to achive this at the end. My recommendation is to pickup that first and then proceed with this. If you have any code to share i can take care of reviewing it and probably glebius@ will be in the loop as well. > > Curtis > > > > Currently the syntax of rdr and nat accept the following: > > nat-rule = [ "no" ] "nat" [ "pass" [ "log" [ "(" logopts ")" ] ] ] > [ "on" ifspec ] [ af ] > [ protospec ] hosts [ "tag" string ] [ "tagged" string ] > [ "->" ( redirhost | "{" redirhost-list "}" ) > [ portspec ] [ pooltype ] [ "static-port" ] ] > > rdr-rule = [ "no" ] "rdr" [ "pass" [ "log" [ "(" logopts ")" ] ] ] > [ "on" ifspec ] [ af ] > [ protospec ] hosts [ "tag" string ] [ "tagged" string ] > [ "->" ( redirhost | "{" redirhost-list "}" ) > [ portspec ] [ pooltype ] ] > > Both of these end in: > > [ "->" ( redirhost | "{" redirhost-list "}" ) > [ portspec ] [ pooltype ] ] > > (with nat-rule having the optional [ "static-port" ]). > > Changing the syntax is no big deal and that would be the easy part. > > In sbin/pf/parse.y some change would be needed to the redirpool rule > where the two forms are (yacc actions omitted): > > redirpool : > | ARROW redirspec > | ARROW redirspec PORT portstar > > to this (or to redirspec) we'd have to add an af_to which would be > similar to the af rule but with the keywork af-to: > > af_to ; /* empty */ { $$ = 0; } > | AF_TO INET { $$ = AF_INET; } > | AF_TO INET6 { $$ = AF_INET6; } > > If this is added to the redirpool then af_to would appear after ARROW > and $2 and $4 are bumped. It means adding sa_family_t af to the > struct redirection. > > In the natrule rule if ((! $9->af) || (r.af == $9->af)), then nothing > needs to be done, else an address family translation is needed. The > following lines have to be changed, replacing r.af with $9->af adding > a line before this to replace 0 with r.af if af_to was empty. > > remove_invalid_hosts(&$9->host, &r.af); > if (invalid_redirect($9->host, r.af)) > YYERROR; > if (check_netmask($9->host, r.af)) > YYERROR; > > At this point the rule can be one address family and all of the > redirect addresses consistent with each other but not necissarily the > same af as the rule. The next problem is that there is no way to pass > this af to expand_rule. That's OK since $9->host ends up as the > protos argument to expand_rule and the af is in each entry. On this > case the af in proto won't match the af in src_hosts and the > consistency checks (nat_consistent, rdr_consistent) don't check and > its off to pfctl_add_rule. > > This gets us to a laer ioctl call of type DIOCADDRULE which puts us in > the kernel code in pf_ioctl.c. > > In the case DIOCADDRULE code the checks of pr->rule.af are no longer > enough. Similar checks are needed on the rule actions. Something > along the lines of: > > #ifndef INET > if (pr->rule.af == AF_INET) { > error = EAFNOSUPPORT; > break; > } > if ((pr->rule.action == PF_NAT) > || (pr->rule.action == PF_RDR)) { > if (rule_dst_has_af(pr->rule.dst.addr), AF_INET) { > error = EAFNOSUPPORT; > break: > } > } > #endif /* INET */ > > Where rule_dst_has_af loops through the table and checks for > instances of the af in the argument list. > > Where the real work would have to be done is in pf_test, pf_test_rule, > pf_get_translation, pf_match_translation, and pf_create_state, and > some functions they use, such as pf_map_addr where mixed af is not > anticipated. This would definitely be the messy part of any attempt > to make af-to work. > > There is no INET/INET6 specific code in pf_test_rule except for ICMP > there is no INET/INET6 specific code and getting the packet length > when dropping TCP and sending a RST. As a first cut, if ICMP from/to > ICMP6 in NAT and RDR didn't work that would be OK. A FAIL would send > back TCP RST using the source af, so that code should be OK. > > My understanding of this code is still very fuzzy after about a half > day of looking at it. Perhaps looking at the openbsd pf would help > (hopefully they still resemble each other). > > Any help would be appreciated, but for now I'd just like to know > whether if I took the trouble to add af-to support the code would be > picked up (after code review, testing, etc). I haven't yet decided > whether this is something I want to take on in the first place. > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > -- Ermal