From owner-freebsd-ipfw@freebsd.org Sun Jun 9 21:00:48 2019 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A91AB15AB4A6 for ; Sun, 9 Jun 2019 21:00:48 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC43865C3 for ; Sun, 9 Jun 2019 21:00:48 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id E928715AB499; Sun, 9 Jun 2019 21:00:47 +0000 (UTC) Delivered-To: ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D688215AB48F for ; Sun, 9 Jun 2019 21:00:47 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71F84865B6 for ; Sun, 9 Jun 2019 21:00:47 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id A04D32516 for ; Sun, 9 Jun 2019 21:00:46 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x59L0kY9006398 for ; Sun, 9 Jun 2019 21:00:46 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x59L0kDA006397 for ipfw@FreeBSD.org; Sun, 9 Jun 2019 21:00:46 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201906092100.x59L0kDA006397@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: ipfw@FreeBSD.org Subject: Problem reports for ipfw@FreeBSD.org that need special attention Date: Sun, 9 Jun 2019 21:00:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2019 21:00:48 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 215875 | [ipfw] ipfw lookup tables do not support mbuf_tag New | 232764 | [ipfw] share/examples/ipfw/change_rules.sh: Suppo 2 problems total for which you should take action. From owner-freebsd-ipfw@freebsd.org Mon Jun 10 08:35:30 2019 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7563515B8DA0 for ; Mon, 10 Jun 2019 08:35:30 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id D91EA97EED for ; Mon, 10 Jun 2019 08:35:28 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 0C72F3AE87 for ; Mon, 10 Jun 2019 01:35:22 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-ipfw@freebsd.org Subject: ipwf firewall stock rule types ? Date: Mon, 10 Jun 2019 01:35:21 -0700 Message-ID: <74910.1560155721@segfault.tristatelogic.com> X-Rspamd-Queue-Id: D91EA97EED X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-5.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ipfw@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[tristatelogic.com]; MX_GOOD(-0.01)[mx1.tristatelogic.com]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; IP_SCORE(-3.10)[ip: (-8.17), ipnet: 69.62.128.0/17(-4.08), asn: 14051(-3.20), country: US(-0.06)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 08:35:30 -0000 I'm setting up a new server, from scratch, and I find that it's always best to review relevant sections of the Handbook when doing so, especially if one hasn't done this fopr a long time, which I haven't. This page has me a bit puzzled: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html This page says that the stock ipfw firewall rulesets are as follows: open: passes all traffic. client: protects only this machine. simple: protects the whole network. closed: entirely disables IP traffic except for the loopback interface. workstation: protects only this machine using stateful rules. UNKNOWN: disables the loading of firewall rules. ... I'd just like to know what the differences are between "client" and "simple". Can anyone explain that to me, briefly? From owner-freebsd-ipfw@freebsd.org Mon Jun 10 10:42:36 2019 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD49C15BBA8C for ; Mon, 10 Jun 2019 10:42:36 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 958E26D80A for ; Mon, 10 Jun 2019 10:42:35 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-qt1-x835.google.com with SMTP id x47so9915983qtk.11 for ; Mon, 10 Jun 2019 03:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tBRFKp05jv+XG3ar94vfTGM6mYZtmUWE2r7tBpWTQEg=; b=U0hSHcXdEc7BSJVzNAWy4dS/sz4gZwQUEkT+Vj3vgfvtrf5zqcYfbAdZD0mukAt961 7RWf6X1c+vcpX9TUXp4AQ8Ru2TSoiGj2eKTM6ZqbmS3rjo0gCRAEQ4wVOy+04FUgaPwC 5ISiiOULnhgA/lg45iMQgUe4FDZGQ+ZCFCONBk8iRWgmJT4XSVhOaw9xjwcd/JAef8X4 oMayK5awLSOIyLo/dd8Kn0t+KnP8QR5fojA9OFgfGH6eXpT4z3+fibacIRR4f4tX3FYF Pk/AWNpKXwpIXivXgaG7i0ccdgB1oTcQLu1l9W3bmR2gf0qSHa71Bw6elOLJECMATkil +EZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tBRFKp05jv+XG3ar94vfTGM6mYZtmUWE2r7tBpWTQEg=; b=E8a49RcuOyoR/c6uobX3zN0+FFLFt+R8g7m3czSIsUpXuBhzKz/k0AvXccoBtegGmE HULBBblqHzjP/svOFKFRqdUEs+FlFlYEQU48BDvhf+RMH0Vh4mMl+s36Np98tM/7iVCB rZU8ajUPgOjhimtf0KXIp5rxw0K8CGJlDwQkHJEm1sfKBr9663SeaZJQ8JzLQbmtPJpg 4tYQQnqN3/MBFhUibmCe4h9d22+tekQcHrcLgj8ZE3VY82GMvRMA5YX7wxpZs4OirzW6 kDdbiWmdDvV+UGz1t/lcWc7NwywaZNdUfXuMstYwj31SxtDEoVViph6AGk6yI0oKW5WF Tltw== X-Gm-Message-State: APjAAAXzJ+0WC6Wguw9pGVuCovps4BmVw1zpgmhDuU2bUjfdarovfvAC QQaGkCk8wiV5J5ww7gq1QdjKVUeOy9Gq3o8LgEM= X-Google-Smtp-Source: APXvYqyHgeh7009+28/pK7QS00F6bQmUkRtzC/2HdAzJzmCMXYT2/ogwDeFRK5puMUR/Ej+8n05Yi44EBg6kT/Ij6y0= X-Received: by 2002:aed:220e:: with SMTP id n14mr30798692qtc.388.1560163354689; Mon, 10 Jun 2019 03:42:34 -0700 (PDT) MIME-Version: 1.0 References: <74910.1560155721@segfault.tristatelogic.com> In-Reply-To: <74910.1560155721@segfault.tristatelogic.com> From: Ganbold Tsagaankhuu Date: Mon, 10 Jun 2019 18:42:23 +0800 Message-ID: Subject: Re: ipwf firewall stock rule types ? To: "Ronald F. Guilmette" Cc: freebsd-ipfw@freebsd.org X-Rspamd-Queue-Id: 958E26D80A X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=U0hSHcXd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ganbold@gmail.com designates 2607:f8b0:4864:20::835 as permitted sender) smtp.mailfrom=ganbold@gmail.com X-Spamd-Result: default: False [-5.92 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.92)[-0.916,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-2.99)[ip: (-9.45), ipnet: 2607:f8b0::/32(-3.18), asn: 15169(-2.28), country: US(-0.06)]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ipfw@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[5.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_ENDS_QUESTION(1.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 10:42:37 -0000 On Mon, Jun 10, 2019 at 4:36 PM Ronald F. Guilmette wrote: > > I'm setting up a new server, from scratch, and I find that it's always > best to review relevant sections of the Handbook when doing so, especially > if one hasn't done this fopr a long time, which I haven't. > > This page has me a bit puzzled: > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html > > This page says that the stock ipfw firewall rulesets are as follows: > > open: passes all traffic. > client: protects only this machine. > simple: protects the whole network. > closed: entirely disables IP traffic except for the loopback interface. > workstation: protects only this machine using stateful rules. > UNKNOWN: disables the loading of firewall rules. > ... > > I'd just like to know what the differences are between "client" and > "simple". > > Can anyone explain that to me, briefly? > You can quickly look at /etc/rc.firewall script. Ganbold > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@freebsd.org Mon Jun 10 13:43:35 2019 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DD7215BFD73 for ; Mon, 10 Jun 2019 13:43:35 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 1E40E73C19 for ; Mon, 10 Jun 2019 13:43:33 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x5ADhTNH078309; Mon, 10 Jun 2019 06:43:29 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x5ADhTVN078308; Mon, 10 Jun 2019 06:43:29 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906101343.x5ADhTVN078308@gndrsh.dnsmgr.net> Subject: Re: ipwf firewall stock rule types ? In-Reply-To: <74910.1560155721@segfault.tristatelogic.com> To: "Ronald F. Guilmette" Date: Mon, 10 Jun 2019 06:43:29 -0700 (PDT) CC: freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 1E40E73C19 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.21 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.12)[-0.123,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.01)[0.008,0]; IP_SCORE(0.04)[ip: (0.15), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.39)[0.391,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 13:43:35 -0000 > > I'm setting up a new server, from scratch, and I find that it's always > best to review relevant sections of the Handbook when doing so, especially > if one hasn't done this fopr a long time, which I haven't. > > This page has me a bit puzzled: > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html > > This page says that the stock ipfw firewall rulesets are as follows: > > open: passes all traffic. > client: protects only this machine. end node > simple: protects the whole network. router > closed: entirely disables IP traffic except for the loopback interface. > workstation: protects only this machine using stateful rules. > UNKNOWN: disables the loading of firewall rules. > ... > > I'd just like to know what the differences are between "client" and "simple". Someone could update the handbook to indicate that client is an end node, and that simple is for a router. > > Can anyone explain that to me, briefly? >From /etc/rc.firewall the comments on each of client and simple help to cover the difference: [Cc][Ll][Ii][Ee][Nn][Tt]) ############ # This is a prototype setup that will protect your system somewhat # against people from outside your own network. # # Configuration: # firewall_client_net: Network address of local IPv4 network. # firewall_client_net_ipv6: Network address of local IPv6 network. ############ [Ss][Ii][Mm][Pp][Ll][Ee]) ############ # This is a prototype setup for a simple firewall. Configure this # machine as a DNS and NTP server, and point all the machines # on the inside at this machine for those services. # # Configuration: # firewall_simple_iif: Inside IPv4 network interface. # firewall_simple_inet: Inside IPv4 network address. # firewall_simple_oif: Outside IPv4 network interface. # firewall_simple_onet: Outside IPv4 network address. # firewall_simple_iif_ipv6: Inside IPv6 network interface. # firewall_simple_inet_ipv6: Inside IPv6 network prefix. # firewall_simple_oif_ipv6: Outside IPv6 network interface. # firewall_simple_onet_ipv6: Outside IPv6 network prefix. ############ The MAJOR difference being that CLIENT is just an end node on a network, where as SIMPLE is actually a forwarding router setup with 2 interfaces. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-ipfw@freebsd.org Mon Jun 10 18:34:59 2019 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8807C15C612C for ; Mon, 10 Jun 2019 18:34:59 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 5024887DAF for ; Mon, 10 Jun 2019 18:34:58 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id C0B033AEFE for ; Mon, 10 Jun 2019 11:34:56 -0700 (PDT) From: "Ronald F. Guilmette" to: freebsd-ipfw@freebsd.org Subject: Re: ipwf firewall stock rule types ? In-Reply-To: Date: Mon, 10 Jun 2019 11:34:56 -0700 Message-ID: <77275.1560191696@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 5024887DAF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-4.89 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ipfw@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[tristatelogic.com]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; NEURAL_HAM_SHORT(-0.65)[-0.646,0]; IP_SCORE(-3.04)[ip: (-8.00), ipnet: 69.62.128.0/17(-4.00), asn: 14051(-3.13), country: US(-0.06)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 18:34:59 -0000 In message Ganbold Tsagaankhuu wrote: >> I'd just like to know what the differences are between "client" and >> "simple". >> >> Can anyone explain that to me, briefly? >> > >You can quickly look at /etc/rc.firewall script. I assumed that, but was hoping that someone would save me the trouble of trying to work out what the differences either are, or are intended to be. Regards, rfg From owner-freebsd-ipfw@freebsd.org Wed Jun 12 11:08:22 2019 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA12015B1B3B for ; Wed, 12 Jun 2019 11:08:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 50EDB7127A for ; Wed, 12 Jun 2019 11:08:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 14B4C15B1B3A; Wed, 12 Jun 2019 11:08:21 +0000 (UTC) Delivered-To: ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0089615B1B39 for ; Wed, 12 Jun 2019 11:08:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C52071273 for ; Wed, 12 Jun 2019 11:08:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id D19873F98 for ; Wed, 12 Jun 2019 11:08:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x5CB8J0c093243 for ; Wed, 12 Jun 2019 11:08:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5CB8JXw093242 for ipfw@FreeBSD.org; Wed, 12 Jun 2019 11:08:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 203585] update 235959 and 235961 breaks ipv6 layer 4 checksums in ipf Date: Wed, 12 Jun 2019 11:08:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bz@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 11:08:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203585 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: cy Date: Wed Jun 12 11:06:59 UTC 2019 New revision: 348987 URL: https://svnweb.freebsd.org/changeset/base/348987 Log: Resolve IPv6 checksum errors with stateful inspection. According to PR/203585 this appears to have been broken by r235959, which predates the ipfilter 5.1.2 import into FreeBSD. The IPv6 checksum calculation is incorrect. To resolve this we call in6_cksum() to do the the heavy lifting for us, through a new function ipf_pcksum6(). Should we need to revisit this area again, a DTrace probe is added to aid with future debugging. PR: 203275, 203585 MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D20583 Changes: head/sys/contrib/ipfilter/netinet/fil.c head/sys/contrib/ipfilter/netinet/ip_fil.h head/sys/contrib/ipfilter/netinet/ip_fil_freebsd.c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ipfw@freebsd.org Thu Jun 13 01:37:54 2019 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6B0915C762D for ; Thu, 13 Jun 2019 01:37:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 435C894AF3 for ; Thu, 13 Jun 2019 01:37:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 03DF415C762B; Thu, 13 Jun 2019 01:37:54 +0000 (UTC) Delivered-To: ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E67B915C762A for ; Thu, 13 Jun 2019 01:37:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8300D94AF0 for ; Thu, 13 Jun 2019 01:37:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 8C44ABB62 for ; Thu, 13 Jun 2019 01:37:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x5D1bqr2025231 for ; Thu, 13 Jun 2019 01:37:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5D1bq20025230 for ipfw@FreeBSD.org; Thu, 13 Jun 2019 01:37:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 233562] ipfw: limit for IPv4 keepalive queue is reached Date: Thu, 13 Jun 2019 01:37:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: chris@cretaforce.gr X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 01:37:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233562 chris@cretaforce.gr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@cretaforce.gr --- Comment #9 from chris@cretaforce.gr --- This patch is included only in 12-STABLE and not 12.0, right? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Fri Jun 14 17:13:15 2019 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18BC515AD07C for ; Fri, 14 Jun 2019 17:13:15 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CCF6721B2 for ; Fri, 14 Jun 2019 17:13:13 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.org (8.16.0.41/8.16.0.41) with ESMTPS id x5EHD4Wv084565 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 14 Jun 2019 19:13:05 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.16.0.41/8.16.0.41/Submit) with UUCP id x5EHD4JQ084564 for freebsd-ipfw@freebsd.org; Fri, 14 Jun 2019 19:13:04 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id x5EFXLdf005281 for ; Fri, 14 Jun 2019 17:33:21 +0200 (CEST) (envelope-from peter@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id x5EFX2Z8005274 for ; Fri, 14 Jun 2019 17:33:02 +0200 (CEST) (envelope-from peter@gate.oper.dinoex.org) Received: (from peter@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id x5EFX2RJ005273 for freebsd-ipfw@freebsd.org; Fri, 14 Jun 2019 17:33:02 +0200 (CEST) (envelope-from peter) Date: Fri, 14 Jun 2019 17:33:02 +0200 From: Peter To: freebsd-ipfw@freebsd.org Subject: ipfw: switching sets does stall the machine Message-ID: <20190614153302.GA4503@gate.oper.dinoex.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.org [194.45.71.2]); Fri, 14 Jun 2019 19:13:08 +0200 (CEST) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 17:13:15 -0000 Hi, I am trying to use two different configurations (production and test) loaded into different sets, and switch between them with # ipfw set disable ... enable ... When testing my script, this did work, except once the machine went into "swap_pager indefinite wait" and was lost. Then, after reboot (and automatically loading the production rules) I tried to load and switch to the test rules, and immediately got ATA COMMAND TIMEOUT and the machine was lost. I repeated this a few times, it is nicely reproducible: withing 3-5 seconds after the new rules are loaded, the machine locks up and is lost. I analyzed more closely by running "top -HPS" in rtprio, and found this: * loading the rules is no problem. * when switching sets, the command returns, but then within few seconds the machine gets unresponsive and stays so until watchdog hits. * The last thing seen in "top" (before it freezes) is this thread eating 85% CPU (and running with high priority): [irq12: uhci0 uhci1] It there a known workaround? Details: Machine : i386 OS : FreeBSD 11.2-RELEASE-p10 Command : ipfw set disable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 enable 16 17 18 19 20 21 22 23 24 25 26 27 28 29 From owner-freebsd-ipfw@freebsd.org Fri Jun 14 17:20:52 2019 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C74C615AD430 for ; Fri, 14 Jun 2019 17:20:52 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 2584E724FD for ; Fri, 14 Jun 2019 17:20:51 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id x5EHKIt2088600; Fri, 14 Jun 2019 17:20:18 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id x5EHKIOB088599; Fri, 14 Jun 2019 10:20:18 -0700 (PDT) (envelope-from david) Date: Fri, 14 Jun 2019 10:20:18 -0700 From: David Wolfskill To: Peter Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw: switching sets does stall the machine Message-ID: <20190614172018.GJ1219@albert.catwhisker.org> Reply-To: freebsd-ipfw@freebsd.org References: <20190614153302.GA4503@gate.oper.dinoex.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Aukwk0PYIw+XhFne" Content-Disposition: inline In-Reply-To: <20190614153302.GA4503@gate.oper.dinoex.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: 2584E724FD X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.969,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 17:20:53 -0000 --Aukwk0PYIw+XhFne Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 14, 2019 at 05:33:02PM +0200, Peter wrote: >=20 > Hi, > I am trying to use two different configurations (production and test) > loaded into different sets, and switch between them with >=20 > # ipfw set disable ... enable ... >=20 > When testing my script, this did work, except once the machine went > into "swap_pager indefinite wait" and was lost. IIRC, this message means that a command was sent to a disk controller and at least 20 seconds have elapsed with no response from that controller. That doesn't seem like an "ipfw" issue, per se. > Then, after reboot (and automatically loading the production rules) I > tried to load and switch to the test rules, and immediately got ATA > COMMAND TIMEOUT and the machine was lost. Again, that's a disk subsystem (apparently) doing Bad Things. > I repeated this a few times, it is nicely reproducible: withing 3-5 > seconds after the new rules are loaded, the machine locks up and is > lost. It's at least plausible that the catalyzing activity causes a certain disk I/O pattern that does the actual triggering (I expect). > I analyzed more closely by running "top -HPS" in rtprio, and found > this: > * loading the rules is no problem. > * when switching sets, the command returns, but then within few > seconds the machine gets unresponsive and stays so until watchdog > hits. > * The last thing seen in "top" (before it freezes) is this thread > eating 85% CPU (and running with high priority): > [irq12: uhci0 uhci1] >=20 >=20 > It there a known workaround? > .... My inclination is for you to check the disk drive(s), cabling, and controller(s) before much else. Peace, david --=20 David H. Wolfskill david@catwhisker.org Donald Trump advocated for the executions of five factually innocent young = men. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Aukwk0PYIw+XhFne Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl0D11JfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PckdEAf/YPtQtyqdxNIwBqabwEylzTYmbDvzIBb3NfznVA8rAoYovhuuhbjm+c/N XYwT8bo9k4WAMHkIWTzs7Qy18x3VkgmTTwAztaR5+DVT1e98bJ9KWoZSlwUsKygM L3oyFgs84uS713xn/pTXLVHDgRj2dhN6l2hMNwj/3fgzqUVf1ONy0STl0Vano2hE 5x9gBTIZYfBQpDkkeeUfZJP/gqntYRirXisFdZvDvtvKzAr9O0ZP1eVy/0Vu4vqi y/qtFpJRv2erJDJQ5YQ+AyBJHjQDQnjmsNFPYP8ThDr67PKgosZdvrS6ZSj8ahZL 50eLntfnhcRQWrJPdam/OwyFbjlM1A== =28XJ -----END PGP SIGNATURE----- --Aukwk0PYIw+XhFne-- From owner-freebsd-ipfw@freebsd.org Fri Jun 14 17:22:07 2019 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3417E15AD671 for ; Fri, 14 Jun 2019 17:22:07 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6653472784 for ; Fri, 14 Jun 2019 17:22:06 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lf1-x135.google.com with SMTP id z15so2224706lfh.13 for ; Fri, 14 Jun 2019 10:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BlR4WYiBCqziU0c9t1kUKti6ek/1Y1+llIs6xdgAFug=; b=T363iRrqN7QGJTtN1A1b93z50e7Ve/w3hBKatiFOXm7hfUd4oryuUTK4nawCroFXO0 Y8rXu8jBCbvmzGodtd4GbRxVlNZG3/0riXG6psK6ywfl2mkUI848nEti46G6Dv5Vtmkt uRR5e3W0ed8MckMcHK+v1++Qu5wJkO84aq1GfQ2Hu5AlzeIoZi+2oOzR0mysej9jnDWX jeRg1Ku9pzhdC393dm13hk+fSfWECqntaDYHCA30kkeI066yKiSircP5om4q+jGkq5cW X6k3qLJMwcggIEzjaVJnxsUgayeRau5yI85Q2KsdYsReEOjbyQbTxuFvS/pvtvBccLj5 z5Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BlR4WYiBCqziU0c9t1kUKti6ek/1Y1+llIs6xdgAFug=; b=Pkxbs6pyRF5VYNlpCC1Na3mwqX7bq3L6kqEbsJPDiVOECH8j8kjYeKTgxg9h0KcDS2 DqwjpHFz2WzgchxWuZ6s/beK/pVlNIwCgxhSrw3IgE4yqHTfs2Gwnoen2TAg8HSD5q+8 K+S1yGyuLAs5CR6MYKf7TQydv+mYSJoAOuzzL0k8vzfnXKgEt0+8Vv5fi2SHBh9P3kN+ /pRlqsZIqltyuUlhqjfSD9JsoUtwoE1qFl6ZWVOW6L+uMFAKQ1A7OocGyEySmtRcTbqw vTHqoOG2VoXRm5evblOgt0KPNLPjPwELfRgypQMrcYeyL42UTXKVnhrbeRSB4OYEcp3T jkxw== X-Gm-Message-State: APjAAAXEdfxghz1R5wJYm63yjXdwyDa5kjtWrN6Yy77+tzaTyYDDoYk3 00TmIh971SDHaEOmlImPuzIJqnEDV92AassgV/PW/w== X-Google-Smtp-Source: APXvYqzfEnkPQ8L2g2SgE7drGvrKnX84FDs/uKT+Kxt7jLGGqH5C2FQxAefPlM8jJTty2uq6jWIw3hB1QMFUo4l3u2A= X-Received: by 2002:ac2:5981:: with SMTP id w1mr27968992lfn.48.1560532924770; Fri, 14 Jun 2019 10:22:04 -0700 (PDT) MIME-Version: 1.0 References: <20190614153302.GA4503@gate.oper.dinoex.org> In-Reply-To: <20190614153302.GA4503@gate.oper.dinoex.org> From: Freddie Cash Date: Fri, 14 Jun 2019 10:21:52 -0700 Message-ID: Subject: Re: ipfw: switching sets does stall the machine To: Peter Cc: "freebsd-ipfw@freebsd.org" X-Rspamd-Queue-Id: 6653472784 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.957,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 17:22:07 -0000 On Fri, Jun 14, 2019 at 10:13 AM Peter wrote: > Hi, > I am trying to use two different configurations (production and test) > loaded into different sets, and switch between them with > > # ipfw set disable ... enable ... > > When testing my script, this did work, except once the machine went > into "swap_pager indefinite wait" and was lost. > > Then, after reboot (and automatically loading the production rules) I > tried to load and switch to the test rules, and immediately got ATA > COMMAND TIMEOUT and the machine was lost. > > I repeated this a few times, it is nicely reproducible: withing 3-5 > seconds after the new rules are loaded, the machine locks up and is > lost. > > I analyzed more closely by running "top -HPS" in rtprio, and found > this: > * loading the rules is no problem. > * when switching sets, the command returns, but then within few > seconds the machine gets unresponsive and stays so until watchdog > hits. > * The last thing seen in "top" (before it freezes) is this thread > eating 85% CPU (and running with high priority): > [irq12: uhci0 uhci1] > > > It there a known workaround? > > Details: > Machine : i386 > OS : FreeBSD 11.2-RELEASE-p10 > Command : ipfw set disable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 enable 16 > 17 18 19 20 21 22 23 24 25 26 27 28 29 > Can't speak to this specific lockup, but I'm curious to know if it works when you enable first, then disable (it's how we've used sets here at work). -- Freddie Cash fjwcash@gmail.com From owner-freebsd-ipfw@freebsd.org Fri Jun 14 19:13:19 2019 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C97515AF438 for ; Fri, 14 Jun 2019 19:13:19 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67FD775B56 for ; Fri, 14 Jun 2019 19:13:17 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.org (8.16.0.41/8.16.0.41) with ESMTPS id x5EJD4fu047755 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 14 Jun 2019 21:13:05 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.16.0.41/8.16.0.41/Submit) with UUCP id x5EJD4ep047754; Fri, 14 Jun 2019 21:13:04 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id x5EIk2Oi006335; Fri, 14 Jun 2019 20:46:02 +0200 (CEST) (envelope-from peter@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id x5EIjufI006274; Fri, 14 Jun 2019 20:45:56 +0200 (CEST) (envelope-from peter@gate.oper.dinoex.org) Received: (from peter@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id x5EIjuPA006273; Fri, 14 Jun 2019 20:45:56 +0200 (CEST) (envelope-from peter) Date: Fri, 14 Jun 2019 20:45:55 +0200 From: Peter To: Freddie Cash Cc: "freebsd-ipfw@freebsd.org" Subject: Re: ipfw: switching sets does stall the machine Message-ID: <20190614184555.GA5959@gate.oper.dinoex.org> References: <20190614153302.GA4503@gate.oper.dinoex.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.org [194.45.71.2]); Fri, 14 Jun 2019 21:13:08 +0200 (CEST) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 19:13:19 -0000 On Fri, Jun 14, 2019 at 10:21:52AM -0700, Freddie Cash wrote: ! > Details: ! > Machine : i386 ! > OS : FreeBSD 11.2-RELEASE-p10 ! > Command : ipfw set disable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 enable 16 ! > 17 18 19 20 21 22 23 24 25 26 27 28 29 ! > ! ! Can't speak to this specific lockup, but I'm curious to know if it works ! when you enable first, then disable (it's how we've used sets here at work). Tried that already, it doesn't make a difference. And since the operation is said to be atomically, it should not make a difference. But now I have an idea what might be the actual issue. One more try for proof, and I send this message out first as otherwise it will be lost... From owner-freebsd-ipfw@freebsd.org Fri Jun 14 21:13:23 2019 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5954315B1652 for ; Fri, 14 Jun 2019 21:13:23 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96A4381518 for ; Fri, 14 Jun 2019 21:13:22 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.org (8.16.0.41/8.16.0.41) with ESMTPS id x5ELD42X011621 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 14 Jun 2019 23:13:05 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.16.0.41/8.16.0.41/Submit) with UUCP id x5ELD4Xo011620 for freebsd-ipfw@freebsd.org; Fri, 14 Jun 2019 23:13:04 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id x5EKFiuq017457 for ; Fri, 14 Jun 2019 22:15:44 +0200 (CEST) (envelope-from peter@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id x5EKDHgD017159 for ; Fri, 14 Jun 2019 22:13:17 +0200 (CEST) (envelope-from peter@gate.oper.dinoex.org) Received: (from peter@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id x5EKDHv1017158 for freebsd-ipfw@freebsd.org; Fri, 14 Jun 2019 22:13:17 +0200 (CEST) (envelope-from peter) Date: Fri, 14 Jun 2019 22:13:17 +0200 From: Peter To: freebsd-ipfw@freebsd.org Subject: Re: ipfw: switching sets does stall the machine Message-ID: <20190614201317.GA8840@gate.oper.dinoex.org> References: <20190614153302.GA4503@gate.oper.dinoex.org> <20190614172018.GJ1219@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190614172018.GJ1219@albert.catwhisker.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.org [194.45.71.2]); Fri, 14 Jun 2019 23:13:08 +0200 (CEST) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 21:13:23 -0000 On Fri, Jun 14, 2019 at 10:20:18AM -0700, David Wolfskill wrote: ! On Fri, Jun 14, 2019 at 05:33:02PM +0200, Peter wrote: ! > ! > Hi, ! > I am trying to use two different configurations (production and test) ! > loaded into different sets, and switch between them with ! > ! > # ipfw set disable ... enable ... ! > ! > When testing my script, this did work, except once the machine went ! > into "swap_pager indefinite wait" and was lost. ! ! IIRC, this message means that a command was sent to a disk controller ! and at least 20 seconds have elapsed with no response from that ! controller. That doesn't seem like an "ipfw" issue, per se. Yes, it usually means that the disk controller has gone fishing, and that it is recommended to hit the reset button. ! > Then, after reboot (and automatically loading the production rules) I ! > tried to load and switch to the test rules, and immediately got ATA ! > COMMAND TIMEOUT and the machine was lost. ! ! Again, that's a disk subsystem (apparently) doing Bad Things. Yes. But not in this case. ! > I repeated this a few times, it is nicely reproducible: withing 3-5 ! > seconds after the new rules are loaded, the machine locks up and is ! > lost. ! ! It's at least plausible that the catalyzing activity causes a certain ! disk I/O pattern that does the actual triggering (I expect). No. The actual reason is an endless loop in the rule processing, and network interrupt should run at a higher priority than disk, and so the disks do not get serviced anymore. The machine is old and has only 2 CPU. ! My inclination is for you to check the disk drive(s), cabling, and ! controller(s) before much else. Yeah, been there tonight. Checked and resettled all cabling etc. But now it figures: 1. as usual the bug was sitting in front of the keyboard. 2. I now tried to immediately delete the old rules after their sets are disabled: problem solved, failure gone. Obviousely all the keep-stated open network sessions are also gone at that point, so this is not really what I wanted. What happens: 1. the production and test configurations are not exactly identical. Which is the whole point in it - if they had to be identical, there were no need for two of them. 2. There are dynamic rules involved. These do not disappear on a "set disable". They stay and continue to function - somehow. 3. When a packet successfully matches a check-state, it does NOT continue to be processed at the rule following that check-state. Instead, it does continue to be processed at the place after the parent keep-state rule that was originally matched! But what if that keep-state rule is now disabled, and the new rules do not line up in their numbering in the exact same way? Then this packet appears at some arbitrary place in the rule list and may go to whereever. Obviousely this is not an issue if you do keep-state with simple Allow or Deny rules - then the packets leave the system after matching. But such simple keep-state do not work with NAT. For NAT one needs a more elaborate approach, like tagging and branching and subroutine calling. So the outcome is: When switching sets with such a configuration that introduces branches and subroutines, the old and new rules need to precisely line up to each other, so that the old dynamic rules (which should be kept for the network sessions to persist) can reinsert their matched packets at places where correct further processing happens. Doesn't seem like an easy task...