From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 15 11:06:15 2007 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5A5416A4E8 for ; Mon, 15 Oct 2007 11:06:15 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7D5FC13C4BB for ; Mon, 15 Oct 2007 11:06:15 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l9FB6FWk080463 for ; Mon, 15 Oct 2007 11:06:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l9FB6F2w080461 for freebsd-ipfw@FreeBSD.org; Mon, 15 Oct 2007 11:06:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Oct 2007 11:06:15 GMT Message-Id: <200710151106.l9FB6F2w080461@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 11:06:15 -0000 From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 15 17:47:11 2007 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BAF416A46E for ; Mon, 15 Oct 2007 17:47:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D6EC313C442 for ; Mon, 15 Oct 2007 17:47:09 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l9FHl9sw014982 for ; Mon, 15 Oct 2007 17:47:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l9FHl9cl014978 for freebsd-ipfw@FreeBSD.org; Mon, 15 Oct 2007 17:47:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Oct 2007 17:47:09 GMT Message-Id: <200710151747.l9FHl9cl014978@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 17:47:11 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] add a facility to modify DF bit of the o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet o kern/112708 ipfw ipfw is seems to be broken to limit number of connecti 13 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] ipfw dynamic rules lifetime feature o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o bin/50749 ipfw [ipfw] [patch] ipfw2 incorrectly parses ports and port o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/73276 ipfw [ipfw] [patch] ipfw2 vulnerability (parser error) o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] Add setnexthop and defaultroute feature o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/111713 ipfw [dummynet] Too few dummynet queue slots o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o bin/113803 ipfw [patch] bin/ipfw.8 - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from 28 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Oct 16 07:00:27 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BCEE16A418 for ; Tue, 16 Oct 2007 07:00:27 +0000 (UTC) (envelope-from john.w.court@nokia.com) Received: from mgw-ext12.nokia.com (smtp.nokia.com [131.228.20.171]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA4A13C467 for ; Tue, 16 Oct 2007 07:00:25 +0000 (UTC) (envelope-from john.w.court@nokia.com) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9G6hawg008247 for ; Tue, 16 Oct 2007 09:44:07 +0300 Received: from siebh102.NOE.Nokia.com ([172.30.195.29]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 09:44:00 +0300 Received: from siebe101.NOE.Nokia.com ([172.30.195.47]) by siebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 14:43:56 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Oct 2007 14:40:12 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Send_pkt() does it support IPV6 ? Thread-Index: AcgPv2cm6Yu+3jRDQVmduTdNmFNqag== From: To: X-OriginalArrivalTime: 16 Oct 2007 06:43:56.0019 (UTC) FILETIME=[EC730430:01C80FBF] X-Nokia-AV: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Send_pkt() does it support IPV6 ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 07:00:27 -0000 Hi, Sorry if I have missed something blindingly obvious, but I can't see how the send_pkt() routine in ip_fw2.c would create a valid ipv6 source and destination address. This is relevent due to its use in ipfw_tick(). Basically in an ipv6 configuration when ipfw_tick() goes off to send a keep-alive, I think send_pkt() would produce an erroneous IPV4 style packet due to its use of id->dst_ip and id->src_ip rather than dst_ip6 and src_ip6 ? Further, ipfw_tick() then calls ip_output() rather than any ip6_output() routine. =20 I am just checking before I make any modifications that I am not missing something fundamental that invalidates my analysis. Thanks John Court =20 From owner-freebsd-ipfw@FreeBSD.ORG Tue Oct 16 07:16:19 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8954816A41A for ; Tue, 16 Oct 2007 07:16:19 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 2E33B13C468 for ; Tue, 16 Oct 2007 07:16:18 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-037-127.pools.arcor-ip.net [88.66.37.127]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1Ihget2IFr-0006pe; Tue, 16 Oct 2007 09:16:18 +0200 From: Max Laier Organization: FreeBSD To: freebsd-ipfw@freebsd.org Date: Tue, 16 Oct 2007 09:15:40 +0200 User-Agent: KMail/1.9.7 References: In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8967889.SrkcK1VLGv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200710160916.05510.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/yYpilCeGGxgCdGq5LkZGaRolGxMXWq9otkcb 5yPj5FB9GpQhXutHHdTJV973d9J1Poeq2BfJu1qy2ESTpSOrJA 9JVhpEPIDQkZpRN+KvXwGwXee1mFIHntx/NgbN6Pns= Cc: john.w.court@nokia.com Subject: Re: Send_pkt() does it support IPV6 ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 07:16:19 -0000 --nextPart8967889.SrkcK1VLGv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 16 October 2007, john.w.court@nokia.com wrote: > Hi, > > Sorry if I have missed something blindingly obvious, but I can't see > how the send_pkt() routine in ip_fw2.c would create a valid ipv6 source > and destination address. This is relevent due to its use in > ipfw_tick(). Basically in an ipv6 configuration when ipfw_tick() goes > off to send a keep-alive, I think send_pkt() would produce an erroneous > IPV4 style packet due to its use of id->dst_ip and id->src_ip rather > than dst_ip6 and src_ip6 ? Further, ipfw_tick() then calls > ip_output() rather than any ip6_output() routine. > > I am just checking before I make any modifications that I am not > missing something fundamental that invalidates my analysis. I don't think you are missing something. IPv6 support in ipfw is still a=20 second class citizen (as is stateful filtering). I remember seeing a=20 mail with similar topic just recently, but can't recall on which list or=20 from whom. I don't see a PR for this - could you please create one so it's not=20 forgotten about? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart8967889.SrkcK1VLGv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHFGU1XyyEoT62BG0RAivIAJ9YlLfsIEWTekmD5lzNBTYEwgltxACePMX9 PPhJM/eTiGMeMtP0JOhK3so= =DCDz -----END PGP SIGNATURE----- --nextPart8967889.SrkcK1VLGv-- From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 19 12:51:28 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABF3116A46B for ; Fri, 19 Oct 2007 12:51:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id EB16913C467 for ; Fri, 19 Oct 2007 12:51:24 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-001-171.pools.arcor-ip.net [88.66.1.171]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1IirJZ2Uf6-0002Nk; Fri, 19 Oct 2007 14:51:18 +0200 From: Max Laier Organization: FreeBSD To: freebsd-ipfw@freebsd.org Date: Fri, 19 Oct 2007 14:50:49 +0200 User-Agent: KMail/1.9.7 References: <200710160916.05510.max@love2party.net> In-Reply-To: <200710160916.05510.max@love2party.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1730097.U4u31Cs6Nl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200710191450.56014.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+V78UAoB6wqXCy8/Sp1Gr72xS57jDxAulprmG 69FCKcfHSLmjZI3gSOdViLWB+uAqjAf2uu3nvp73lW8NHuDsEE EJrrP8pz4FSW+KgTEYlfh0cvlxkqKW+CWn9twUiW2s= Cc: john.w.court@nokia.com Subject: Re: Send_pkt() does it support IPV6 ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 12:51:28 -0000 --nextPart1730097.U4u31Cs6Nl Content-Type: multipart/mixed; boundary="Boundary-01=_qgKGHg+rBYy2qDj" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_qgKGHg+rBYy2qDj Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 16 October 2007, I wrote: > On Tuesday 16 October 2007, john.w.court@nokia.com wrote: > > Hi, > > > > Sorry if I have missed something blindingly obvious, but I can't see > > how the send_pkt() routine in ip_fw2.c would create a valid ipv6 > > source and destination address. This is relevent due to its use in > > ipfw_tick(). Basically in an ipv6 configuration when ipfw_tick() goes > > off to send a keep-alive, I think send_pkt() would produce an > > erroneous IPV4 style packet due to its use of id->dst_ip and > > id->src_ip rather than dst_ip6 and src_ip6 ? Further, ipfw_tick() > > then calls ip_output() rather than any ip6_output() routine. > > > > I am just checking before I make any modifications that I am not > > missing something fundamental that invalidates my analysis. > > I don't think you are missing something. IPv6 support in ipfw is still > a second class citizen (as is stateful filtering). I remember seeing a > mail with similar topic just recently, but can't recall on which list > or from whom. > > I don't see a PR for this - could you please create one so it's not > forgotten about? Here is a patch - completely untested as of yet. I just finished typing=20 and have to run out for a bit, if anyone would like to give it a spin or=20 review in the meantime, please let me know of your findings. BTW, the PR is kern/117234. I'll add this patch to the trail as soon as I= =20 had a chance to give it a try. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_qgKGHg+rBYy2qDj Content-Type: text/x-diff; charset="iso-8859-6"; name="ipfw_v6send.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ipfw_v6send.diff" Index: ip_fw2.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.175 diff -u -r1.175 ip_fw2.c =2D-- ip_fw2.c 7 Oct 2007 20:44:23 -0000 1.175 +++ ip_fw2.c 19 Oct 2007 12:38:16 -0000 @@ -98,6 +98,7 @@ #include #include #ifdef INET6 +#include #include #endif =20 @@ -241,6 +242,9 @@ #define IPFW_DYN_UNLOCK() mtx_unlock(&ipfw_dyn_mtx) #define IPFW_DYN_LOCK_ASSERT() mtx_assert(&ipfw_dyn_mtx, MA_OWNED) =20 +static struct mbuf *send_pkt(struct mbuf *, struct ipfw_flow_id *, + u_int32_t, u_int32_t, int); + /* * Timeouts for various events in handing dynamic rules. */ @@ -671,67 +675,25 @@ } =20 static void =2Dsend_reject6(struct ip_fw_args *args, int code, u_int hlen, struct ip6_h= dr *ip6) +send_reject6(struct ip_fw_args *args, int code, u_int hlen, + struct ip6_hdr *ip6) { struct mbuf *m; =20 m =3D args->m; if (code =3D=3D ICMP6_UNREACH_RST && args->f_id.proto =3D=3D IPPROTO_TCP)= { struct tcphdr *tcp; =2D tcp_seq ack, seq; =2D int flags; =2D struct { =2D struct ip6_hdr ip6; =2D struct tcphdr th; =2D } ti; tcp =3D (struct tcphdr *)((char *)ip6 + hlen); =20 =2D if ((tcp->th_flags & TH_RST) !=3D 0) { =2D m_freem(m); =2D args->m =3D NULL; =2D return; =2D } =2D =2D ti.ip6 =3D *ip6; =2D ti.th =3D *tcp; =2D ti.th.th_seq =3D ntohl(ti.th.th_seq); =2D ti.th.th_ack =3D ntohl(ti.th.th_ack); =2D ti.ip6.ip6_nxt =3D IPPROTO_TCP; =2D =2D if (ti.th.th_flags & TH_ACK) { =2D ack =3D 0; =2D seq =3D ti.th.th_ack; =2D flags =3D TH_RST; =2D } else { =2D ack =3D ti.th.th_seq; =2D if ((m->m_flags & M_PKTHDR) !=3D 0) { =2D /* =2D * total new data to ACK is: =2D * total packet length, =2D * minus the header length, =2D * minus the tcp header length. =2D */ =2D ack +=3D m->m_pkthdr.len - hlen =2D - (ti.th.th_off << 2); =2D } else if (ip6->ip6_plen) { =2D ack +=3D ntohs(ip6->ip6_plen) + sizeof(*ip6) - =2D hlen - (ti.th.th_off << 2); =2D } else { =2D m_freem(m); =2D return; =2D } =2D if (tcp->th_flags & TH_SYN) =2D ack++; =2D seq =3D 0; =2D flags =3D TH_RST|TH_ACK; + if ((tcp->th_flags & TH_RST) =3D=3D 0) { + struct mbuf *m0; + m0 =3D send_pkt(args->m, &(args->f_id), + ntohl(tcp->th_seq), ntohl(tcp->th_ack), + tcp->th_flags | TH_RST); + if (m0 !=3D NULL) + ip6_output(m0, NULL, NULL, 0, NULL, NULL, NULL); } =2D bcopy(&ti, ip6, sizeof(ti)); =2D /* =2D * m is only used to recycle the mbuf =2D * The data in it is never read so we don't need =2D * to correct the offsets or anything =2D */ =2D tcp_respond(NULL, ip6, tcp, m, ack, seq, flags); + m_freem(m); } else if (code !=3D ICMP6_UNREACH_RST) { /* Send an ICMPv6 unreach. */ #if 0 /* @@ -1609,13 +1571,16 @@ u_int32_t ack, int flags) { struct mbuf *m; =2D struct ip *ip; =2D struct tcphdr *tcp; + int len, dir; + struct ip *h =3D NULL; /* stupid compiler */ +#ifdef INET6 + struct ip6_hdr *h6 =3D NULL; +#endif + struct tcphdr *th =3D NULL; =20 MGETHDR(m, M_DONTWAIT, MT_DATA); =2D if (m =3D=3D 0) + if (m =3D=3D NULL) return (NULL); =2D m->m_pkthdr.rcvif =3D (struct ifnet *)0; =20 #ifdef MAC if (replyto !=3D NULL) @@ -1626,67 +1591,118 @@ (void)replyto; /* don't warn about unused arg */ #endif =20 =2D m->m_pkthdr.len =3D m->m_len =3D sizeof(struct ip) + sizeof(struct tcph= dr); + switch (id->addr_type) { + case 4: + len =3D sizeof(struct ip) + sizeof(struct tcphdr); + break; +#ifdef INET6 + case 6: + len =3D sizeof(struct ip6_hdr) + sizeof(struct tcphdr); + break; +#endif + default: + /* XXX: log me?!? */ + m_freem(m); + return (NULL); + } + dir =3D ((flags & (TH_SYN | TH_RST)) =3D=3D TH_SYN); + m->m_data +=3D max_linkhdr; + m->m_flags |=3D M_SKIP_FIREWALL; + m->m_pkthdr.len =3D m->m_len =3D len; + m->m_pkthdr.rcvif =3D NULL; + bzero(m->m_data, len); + + switch (id->addr_type) { + case 4: + h =3D mtod(m, struct ip *); + + /* prepare for checksum */ + h->ip_p =3D IPPROTO_TCP; + h->ip_len =3D htons(sizeof(struct tcphdr)); + if (dir) { + h->ip_src.s_addr =3D htonl(id->src_ip); + h->ip_dst.s_addr =3D htonl(id->dst_ip); + } else { + h->ip_src.s_addr =3D htonl(id->dst_ip); + h->ip_dst.s_addr =3D htonl(id->src_ip); + } =20 =2D ip =3D mtod(m, struct ip *); =2D bzero(ip, m->m_len); =2D tcp =3D (struct tcphdr *)(ip + 1); /* no IP options */ =2D ip->ip_p =3D IPPROTO_TCP; =2D tcp->th_off =3D 5; =2D /* =2D * Assume we are sending a RST (or a keepalive in the reverse =2D * direction), swap src and destination addresses and ports. =2D */ =2D ip->ip_src.s_addr =3D htonl(id->dst_ip); =2D ip->ip_dst.s_addr =3D htonl(id->src_ip); =2D tcp->th_sport =3D htons(id->dst_port); =2D tcp->th_dport =3D htons(id->src_port); =2D if (flags & TH_RST) { /* we are sending a RST */ + th =3D (struct tcphdr *)(h + 1); + break; +#ifdef INET6 + case 6: + h6 =3D mtod(m, struct ip6_hdr *); + + /* prepare for checksum */ + h6->ip6_nxt =3D IPPROTO_TCP; + h6->ip6_plen =3D htons(sizeof(struct tcphdr)); + if (dir) { + h6->ip6_src =3D id->src_ip6; + h6->ip6_dst =3D id->dst_ip6; + } else { + h6->ip6_src =3D id->dst_ip6; + h6->ip6_dst =3D id->src_ip6; + } + + th =3D (struct tcphdr *)(h6 + 1); + break; +#endif + } + + if (dir) { + th->th_sport =3D id->src_port; + th->th_dport =3D id->dst_port; + } else { + th->th_sport =3D id->dst_port; + th->th_dport =3D id->src_port; + } + th->th_off =3D sizeof(struct tcphdr) >> 2; + + if (flags & TH_RST) { if (flags & TH_ACK) { =2D tcp->th_seq =3D htonl(ack); =2D tcp->th_ack =3D htonl(0); =2D tcp->th_flags =3D TH_RST; + th->th_seq =3D htonl(ack); + th->th_flags =3D TH_RST; } else { if (flags & TH_SYN) seq++; =2D tcp->th_seq =3D htonl(0); =2D tcp->th_ack =3D htonl(seq); =2D tcp->th_flags =3D TH_RST | TH_ACK; + th->th_ack =3D htonl(seq); + th->th_flags =3D TH_RST | TH_ACK; } } else { /* =2D * We are sending a keepalive. flags & TH_SYN determines =2D * the direction, forward if set, reverse if clear. =2D * NOTE: seq and ack are always assumed to be correct =2D * as set by the caller. This may be confusing... + * Keepalive - use caller provided sequence numbers */ =2D if (flags & TH_SYN) { =2D /* =2D * we have to rewrite the correct addresses! =2D */ =2D ip->ip_dst.s_addr =3D htonl(id->dst_ip); =2D ip->ip_src.s_addr =3D htonl(id->src_ip); =2D tcp->th_dport =3D htons(id->dst_port); =2D tcp->th_sport =3D htons(id->src_port); =2D } =2D tcp->th_seq =3D htonl(seq); =2D tcp->th_ack =3D htonl(ack); =2D tcp->th_flags =3D TH_ACK; + th->th_seq =3D htonl(seq); + th->th_ack =3D htonl(ack); + th->th_flags =3D TH_ACK; + } + + switch (id->addr_type) { + case 4: + th->th_sum =3D in_cksum(m, len); + + /* finish the ip header */ + h->ip_v =3D 4; + h->ip_hl =3D sizeof(*h) >> 2; + h->ip_tos =3D IPTOS_LOWDELAY; + h->ip_off =3D 0; + h->ip_len =3D len; + h->ip_ttl =3D ip_defttl; + h->ip_sum =3D 0; + break; +#ifdef INET6 + case 6: + th->th_sum =3D in6_cksum(m, IPPROTO_TCP, sizeof(*h6), + sizeof(struct tcphdr)); + + /* finish the ip6 header */ + h6->ip6_vfc |=3D IPV6_VERSION; + h6->ip6_hlim =3D IPV6_DEFHLIM; + break; +#endif } =2D /* =2D * set ip_len to the payload size so we can compute =2D * the tcp checksum on the pseudoheader =2D * XXX check this, could save a couple of words ? =2D */ =2D ip->ip_len =3D htons(sizeof(struct tcphdr)); =2D tcp->th_sum =3D in_cksum(m, m->m_pkthdr.len); =2D /* =2D * now fill fields left out earlier =2D */ =2D ip->ip_ttl =3D ip_defttl; =2D ip->ip_len =3D m->m_pkthdr.len; =2D m->m_flags |=3D M_SKIP_FIREWALL; + return (m); } =20 @@ -4860,6 +4876,9 @@ ipfw_tick(void * __unused unused) { struct mbuf *m0, *m, *mnext, **mtailp; +#ifdef INET6 + struct mbuf *m6, **m6_tailp; +#endif int i; ipfw_dyn_rule *q; =20 @@ -4874,6 +4893,10 @@ */ m0 =3D NULL; mtailp =3D &m0; +#ifdef INET6 + m6 =3D NULL; + m6_tailp =3D &m6; +#endif IPFW_DYN_LOCK(); for (i =3D 0 ; i < curr_dyn_buckets ; i++) { for (q =3D ipfw_dyn_v[i] ; q ; q =3D q->next ) { @@ -4889,14 +4912,37 @@ if (TIME_LEQ(q->expire, time_uptime)) continue; /* too late, rule expired */ =20 =2D *mtailp =3D send_pkt(NULL, &(q->id), q->ack_rev - 1, + m =3D send_pkt(NULL, &(q->id), q->ack_rev - 1, q->ack_fwd, TH_SYN); =2D if (*mtailp !=3D NULL) =2D mtailp =3D &(*mtailp)->m_nextpkt; =2D *mtailp =3D send_pkt(NULL, &(q->id), q->ack_fwd - 1, + mnext =3D send_pkt(NULL, &(q->id), q->ack_fwd - 1, q->ack_rev, 0); =2D if (*mtailp !=3D NULL) =2D mtailp =3D &(*mtailp)->m_nextpkt; + + switch (q->id.addr_type) { + case 4: + if (m !=3D NULL) { + *mtailp =3D m; + mtailp =3D &(*mtailp)->m_nextpkt; + } + if (mnext !=3D NULL) { + *mtailp =3D mnext; + mtailp =3D &(*mtailp)->m_nextpkt; + } + break; +#ifdef INET6 + case 6: + if (m !=3D NULL) { + *m6_tailp =3D m; + m6_tailp =3D &(*m6_tailp)->m_nextpkt; + } + if (mnext !=3D NULL) { + *m6_tailp =3D mnext; + m6_tailp =3D &(*m6_tailp)->m_nextpkt; + } + break; +#endif + } + + m =3D mnext =3D NULL; } } IPFW_DYN_UNLOCK(); @@ -4905,6 +4951,13 @@ m->m_nextpkt =3D NULL; ip_output(m, NULL, NULL, 0, NULL, NULL); } +#ifdef INET6 + for (m =3D mnext =3D m6; m !=3D NULL; m =3D mnext) { + mnext =3D m->m_nextpkt; + m->m_nextpkt =3D NULL; + ip6_output(m, NULL, NULL, 0, NULL, NULL, NULL); + } +#endif done: callout_reset(&ipfw_timeout, dyn_keepalive_period*hz, ipfw_tick, NULL); } --Boundary-01=_qgKGHg+rBYy2qDj-- --nextPart1730097.U4u31Cs6Nl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHGKgvXyyEoT62BG0RAqkAAJ9n2TO+LpayNJ1DHDIZ6kqssV0LAgCeMUT3 nXk/2aLyPGbZu/y7re5qNJY= =fXDh -----END PGP SIGNATURE----- --nextPart1730097.U4u31Cs6Nl--