From owner-freebsd-net@freebsd.org Sun Jun 16 15:26:44 2019 Return-Path: Delivered-To: freebsd-net@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 574B715C1EAB for ; Sun, 16 Jun 2019 15:26:44 +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 E357D852A5 for ; Sun, 16 Jun 2019 15:26:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9DEA715C1EAA; Sun, 16 Jun 2019 15:26:43 +0000 (UTC) Delivered-To: net@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 791D315C1EA9 for ; Sun, 16 Jun 2019 15:26:43 +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 1357F852A2 for ; Sun, 16 Jun 2019 15:26:43 +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 4948819E35 for ; Sun, 16 Jun 2019 15:26:42 +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 x5GFQgEh045714 for ; Sun, 16 Jun 2019 15:26:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5GFQgJP045705 for net@FreeBSD.org; Sun, 16 Jun 2019 15:26:42 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: net@FreeBSD.org Subject: [Bug 235031] [em] em0: poor NFS performance, strange behavior Date: Sun, 16 Jun 2019 15:26:36 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2019 15:26:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235031 --- Comment #34 from commit-hook@freebsd.org --- A commit references this bug: Author: marius Date: Sun Jun 16 15:25:46 UTC 2019 New revision: 349112 URL: https://svnweb.freebsd.org/changeset/base/349112 Log: MFC: r347221, r347245 o Use iflib_fast_intr_rxtx() also for "legacy" interrupts, i. e. INTx and MSI. Unlike as with iflib_fast_intr_ctx(), the former will also enqueue _task_fn_tx() in addition to _task_fn_rx() if appropriate, bringing TCP TX throughput of EM-class devices on par with the MSI-X case and, thus, close to wirespeed/pre-iflib(4) times again. [1] Note that independently of the interrupt type, the UDP performance with these MACs still is abysmal and nowhere near to where it was before the conversion of em(4) to iflib(4). o In iflib_init_locked(), announce which free list failed to set up. o In _task_fn_tx() when running netmap(4), issue ifdi_intr_enable instead of the ifdi_tx_queue_intr_enable method in case of a "legacy" interrupt as the latter is valid with MSI-X only. o Instead of adding the missing - and apparently convoluted enough that a DBG_COUNTER_INC was put into a wrong spot in _task_fn_rx() - checks for ifdi_{r,t}x_queue_intr_enable being available in the MSI-X case also to iflib_fast_intr_rxtx(), factor these out to iflib_device_register() and make the checks fail gracefully rather than panic. This avoids invoking the checks at runtime over and over again in iflib_fast_intr_rxtx() and _task_fn_{r,t}x() - even if it's just in case of INVARIANTS - and makes these functions more readable. o In iflib_rx_structures_setup(), only initialize LRO resources if device and driver have LRO capability in order to not waste memory. Also, free the LRO resources again if setting them up fails for one of the queues. However, don't bother invoking iflib_rx_sds_free() in that case because iflib_rx_structures_setup() doesn't call iflib_rxsd_alloc() either (and iflib_{device,pseudo}_register() will issue iflib_rx_sds_free() in case of failure via iflib_rx_structures_free(), but there definitely is some asymmetry left to be fixed, though). o Similarly, free LRO resources again in iflib_rx_structures_free(). o In iflib_irq_set_affinity(), handle get_core_offset() errors gracefully instead of panicing (but only in case of INVARIANTS). This is a follow- up to r344132 (MFCed to stable/12 in r344163) as such bugs shouldn't be fatal. o Likewise, handle unknown iflib_intr_type_t in iflib_irq_alloc_generic() gracefully, too. o Bring yet more sanity to iflib_msix_init(): - If the device doesn't provide enough MSI-X vectors or not all vectors can be allocate so the expected number of queues in addition to admin interrupts can't be supported, try MSI next (and then INTx) as proper MSI-X vector distribution can't be assured in such cases. In essence, this change brings r254008 forward to iflib(4). Also, this is the fix alluded to in the commit message of r343934. - If the MSI-X allocation has failed, don't prematurely announce MSI is going to be used as the latter in fact may not be available either. - When falling back to MSI, only release the MSI-X table resource again if it was allocated in iflib_msix_init(), i. e. isn't supplied by the driver, in the first place. o In mp_ndesc_handler(), handle unknown type arguments gracefully, too. PR: 235031 (likely) [1] Reviewed by: shurd Differential Revision: https://reviews.freebsd.org/D20175 Changes: _U stable/12/ stable/12/sys/net/iflib.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Jun 16 16:57:38 2019 Return-Path: Delivered-To: freebsd-net@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 67D5415C40D0 for ; Sun, 16 Jun 2019 16:57:38 +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 F10EC88516 for ; Sun, 16 Jun 2019 16:57:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id B004B15C40CD; Sun, 16 Jun 2019 16:57:37 +0000 (UTC) Delivered-To: net@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 9BDA715C40CB for ; Sun, 16 Jun 2019 16:57:37 +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 2FA0B88515 for ; Sun, 16 Jun 2019 16:57:37 +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 7A28E1AB1D for ; Sun, 16 Jun 2019 16:57:36 +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 x5GGvano091657 for ; Sun, 16 Jun 2019 16:57:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5GGvaYl091648 for net@FreeBSD.org; Sun, 16 Jun 2019 16:57:36 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: net@FreeBSD.org Subject: [Bug 238411] [igb] wake on lan not working with Intel I210 Date: Sun, 16 Jun 2019 16:57:33 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking, needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2019 16:57:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238411 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |net@FreeBSD.org Keywords| |IntelNetworking --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Jun 16 21:03:07 2019 Return-Path: Delivered-To: freebsd-net@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 0AB5915C9C24 for ; Sun, 16 Jun 2019 21:03:07 +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 91C3B683EF for ; Sun, 16 Jun 2019 21:03:06 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4BEEA15C9C1F; Sun, 16 Jun 2019 21:03:06 +0000 (UTC) Delivered-To: net@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 24CD115C9C1E for ; Sun, 16 Jun 2019 21:03:06 +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 AC326683E7 for ; Sun, 16 Jun 2019 21:03:05 +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 CCA1E1CF3E for ; Sun, 16 Jun 2019 21:03:04 +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 x5GL34Ci065711 for ; Sun, 16 Jun 2019 21:03:04 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5GL34Zf065700 for net@FreeBSD.org; Sun, 16 Jun 2019 21:03:04 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201906162103.x5GL34Zf065700@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: net@FreeBSD.org Subject: Problem reports for net@FreeBSD.org that need special attention Date: Sun, 16 Jun 2019 21:03:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2019 21:03:07 -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 ------------+-----------+--------------------------------------------------- In Progress | 221146 | [ixgbe] Problem with second laggport In Progress | 235700 | oce(4) driver causes fatal trap 12 on boot with e New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 213410 | [carp] service netif restart causes hang only whe Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194485 | Userland cannot add IPv6 prefix routes Open | 200319 | Bridge+CARP crashes/freezes Open | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 222273 | igb(4): Kernel panic (fatal trap 12) due to netwo Open | 227720 | Kernel panic in ppp server Open | 233952 | jme NICs non functional after 11.2 to 12.0 upgrad Open | 236888 | ppp daemon: Allow MTU to be overridden for PPPoE Open | 236983 | bnxt(4) VLAN not operational unless explicit "ifc Open | 237072 | netgraph(4): performance issue [on HardenedBSD]? Open | 237391 | route get returns no result for network addresses Open | 237840 | Removed dummynet dependency on ipfw 17 problems total for which you should take action. From owner-freebsd-net@freebsd.org Mon Jun 17 07:31:26 2019 Return-Path: Delivered-To: freebsd-net@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 5D60F15AFF15 for ; Mon, 17 Jun 2019 07:31:26 +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 D82428364F for ; Mon, 17 Jun 2019 07:31:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9C4F515AFF13; Mon, 17 Jun 2019 07:31:25 +0000 (UTC) Delivered-To: net@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 8AE0B15AFF12 for ; Mon, 17 Jun 2019 07:31:25 +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 28E508364D for ; Mon, 17 Jun 2019 07:31:25 +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 791752A53 for ; Mon, 17 Jun 2019 07:31:24 +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 x5H7VN9D028332 for ; Mon, 17 Jun 2019 07:31:23 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5H7VMTC028295 for net@FreeBSD.org; Mon, 17 Jun 2019 07:31:22 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: net@FreeBSD.org Subject: [Bug 205706] Watchdog timeout on em driver under heavy traffic on a bridge configuration Date: Mon, 17 Jun 2019 07:31:10 +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: CURRENT X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sagarharish999@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 07:31:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205706 Pokemon999 changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sagarharish999@gmail.com --- Comment #9 from Pokemon999 --- Have to seen the batter site here https://setclockwindows.com and access the all setting for know how do i set clock in windows 10. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jun 17 15:16:24 2019 Return-Path: Delivered-To: freebsd-net@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 2648515BCBC3 for ; Mon, 17 Jun 2019 15:16:24 +0000 (UTC) (envelope-from buzsol@buzsol.com) Received: from sonic306-26.consmr.mail.sg3.yahoo.com (sonic306-26.consmr.mail.sg3.yahoo.com [106.10.241.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C57AB6E098 for ; Mon, 17 Jun 2019 15:16:22 +0000 (UTC) (envelope-from buzsol@buzsol.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1560784573; bh=mjZOyJYy92FtXlQs88+mI7HpVKpP77Hdgxdp0K89XWo=; h=From:To:References:In-Reply-To:Subject:Date:From:Subject; b=gIWAfD+15BW8QJkn+omJtuXy7uTX943kz6h2jo3yd2N8ma5Jz0mZvnF8Oh5t7DW15zltyzsShR2efVuFgvjjpdNTxnTuu+qE2vxe8EIaLm2H30b+olGQagCLCfNxMBeNyetnwh63RC3NBLec1pcOfX0WCK/rwu6fEIaigxiWfY210ObTCw/MfteF0U4F6QInNLBs75oCxgDXdzHoZ6kXo760IdI8d4a0ppAY6ywiw1A67GIHqpR7QWhC5/AsPmqbjV6gzZuI/f9m0EbqlYuhq6yt4vjaROHXzlMVS67Jklige+McbQPuu6G10u8k0bFruQ6DiBBuE4SfZ5R5iLzcNw== X-YMail-OSG: VgWWDsMVM1lOY90gaaVsCZDr7c2a27wmxrFz51ICfJIS5OWbm7n0SSp8a6ZfQI7 L3yo6Kp2MYslzOQROT9OwgFASQN3XFZmzXWgdEdr.oabbQ72m7JoIWptytfu.1ra7mBCvY97BS.Q 5wy2LcNfwQlIwUJQa4mvy9m4ivkDpGpqAruAn9CU8Qbz8OaekXGPo3.Mrt0riXUYTzKy60aPpIcl MczatNR_FHtkYDqC7RNojE4ar9wyz00VKMD.egFOB5LwzkPeDTomvuRQCr1b0Fyh7Y9m75XyrzST VGb7spMmfsvE91KUTxkE.Vq2L9FJE2nHS6oO6JnLVhqOrF1f_SBwauYgXIONjMay7mHWoxbdmm0A xd.8NcjlrP6swhzHExGy3OHr_Fj9LwVxPCfqArY5u_jHpVpYgkq3spWXiUfRJcvLh8lqCFLudE9j GpfcVVaMefo6L6mEZ0FFKc41nOp9pR5jbZfHMz2LmNfpF.xR4fx6MrCkng.JPU0_gHYYFqVYfht1 rD0ck.GDBRj01wyfVquqsIldTCYf4l8CWrImb.PsRQsqjliq9aow_bdFlB6OqUjD9pVaedUNrEIc 2DRD4.5InT.g.JnLtLItJhCDH_7UixJq0yyrCN6RBSX9.Ofx5s3Zroje2uppHhrego1WAO80J4V3 zQG45PW9AxKho3ZeU2sLXB.qyQwZSg.KG7skEd2FxsignDgBYYzrhXir5QKln3.078W8ivln2LGU _eM68sew7_jCyMGbfTpA3wUMRX0V2Ks9qpl6_zmBxdO4PIzb8XkzKw7Qxi5UE9ehyXT1NV_h_Eep wZBnbGyLzBeH6w0JWiGXLvORTSQOpREatoh8MoELNpBKI9gnY5TScMaLeStvvOatJsxbj3LwInPO 8TrUMcFt64pjGUr08VNZLZEAA8ygxkEMyW7RThs6m0LUaBZd3bePrGGVjk8fYae19V39n_mHAkTU 5OJM9zPRrQhKrpHBmkumEsdPvqVbXz57Yc9Oh_hObHS6Cbpdu3T5qNdZhGviVf8dze8WL0CPGoKP XyjBSrUQUHBVmxlNjSkbWm3mqv_rm2bJBdA8.xl18DImuyDHGbISLgL2yoSJuGgiTkTXWAskpCZs he3NGiJngMuLuepfAFPuEc1UezKonlJqXpB2eEqSMFaZXlSRi534JtAsTuF2fNFQ_6f.j8xm1aCq Fa2VgcVYlfgUhbZaZCBAIC02Ueejc5p18sY_L5ds78cpSle1GZ5lyLkl2P4n392LrQj8axn_NPCC qn4GA8AXZhLZglgbTi5jA Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.sg3.yahoo.com with HTTP; Mon, 17 Jun 2019 15:16:13 +0000 Received: from 175.100.149.111 (EHLO AdminPC) ([175.100.149.111]) by smtp427.mail.sg3.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7bb7663075fd943ef45c019515e449ee for ; Mon, 17 Jun 2019 15:05:59 +0000 (UTC) From: "Bonnie Bennett" To: References: In-Reply-To: Subject: RE: Updated OPT - IN Attendee List 2019 - Security Canada West Conference Date: Mon, 17 Jun 2019 08:05:58 -0700 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdUiGI5Cu2XzM8gqQmebUnm8WouTQwDBZzXQ Content-Language: en-us X-Rspamd-Queue-Id: C57AB6E098 X-Spamd-Bar: ++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gIWAfD+1 X-Spamd-Result: default: False [6.56 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mx-biz.mail.am0.yahoodns.net]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:56173, ipnet:106.10.224.0/19, country:SG]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[111.149.100.175.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; SUBJECT_ENDS_SPACES(0.50)[]; R_DKIM_ALLOW(0.00)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RECEIVED_SPAMHAUS_XBL(3.00)[111.149.100.175.zen.spamhaus.org : 127.0.0.4]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[buzsol.com]; NEURAL_SPAM_MEDIUM(0.99)[0.990,0]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; IP_SCORE(0.39)[ip: (-5.61), ipnet: 106.10.224.0/19(4.15), asn: 56173(3.32), country: SG(0.08)]; NEURAL_SPAM_SHORT(0.69)[0.689,0]; NEURAL_SPAM_LONG(1.00)[1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[146.241.10.106.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[] X-Spam: Yes Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 15:16:24 -0000 Hi, I am just doing a follow up with my previous email to check whether you are interested in our Attendees Lists. Could you please let me know your thoughts? In turn, I'll get back with Precise Counts and Pricing Details for your consideration. Thank you and I Look forward to hearing from you. Regards Bonnie Bennett - Event Attendees Specialist. From: Bonnie Bennett [mailto:buzsol@buzsol.com] Sent: Thursday, June 13, 2019 11:48 AM To: 'freebsd-net@freebsd.org' Subject: Updated OPT - IN Attendee List 2019 - Security Canada West Conference Dear Exhibitors May we wish you every success in the forthcoming exhibition. A key to success Security Canada West Conference & Exposition 2019 is maximum exposure to attendees. Whether your goal is branding, lead generation, market visibility or all three, you want to encourage attendees to visit your booth. We have OPT - IN Attendee profiles with their complete details ( Contact name, Company name, Job Title, Company Mailing address with Zip Code, Phone Number, Fax Number, SIC Code, Industry Classification, Website URL and contact person verified business email address and LinkedIn Profile ) Please let me know your thoughts so that I can send you the Exhibitor discounts costs & counts for your review. Looking back to hearing from you. Regards, Bonnie Bennett Security Canada West Conference & Exposition 2019 - Event Attendees Specialist. June 19, 2019 |Richmond, B.C From owner-freebsd-net@freebsd.org Mon Jun 17 20:15:31 2019 Return-Path: Delivered-To: freebsd-net@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 F3D9215C373D for ; Mon, 17 Jun 2019 20:15: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 B994980C29 for ; Mon, 17 Jun 2019 20:15:29 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 988914E654; Mon, 17 Jun 2019 13:15:22 -0700 (PDT) From: "Ronald F. Guilmette" cc: freebsd-net Subject: Re: localhost woes -- help requested In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4467.1560802522.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jun 2019 13:15:22 -0700 Message-ID: <4468.1560802522@segfault.tristatelogic.com> X-Rspamd-Queue-Id: B994980C29 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 [-3.78 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.73)[ip: (-7.19), ipnet: 69.62.128.0/17(-3.59), asn: 14051(-2.82), country: US(-0.06)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mx1.tristatelogic.com]; NEURAL_HAM_SHORT(-0.85)[-0.846,0]; MISSING_TO(2.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 20:15:31 -0000 In message , = Adam wrote: >On Sat, Jun 15, 2019 at 12:54 AM Ronald F. Guilmette >wrote: >> ... except for the browsers, and also one other thing (nmh outbound >> email handling). Now, both Firefox and Opera crash and burn, right >> out of the gate, when started from the command line. In both cases >> thet do so both with entirely cryptic failure messages. >> >> But here's the kicker... I futzed around with this awhile and found >> out that if I just change the default value of the DISPLAY environment >> variable from "localhost:0.0" to ":0.0" then both browsers *do* then >> start up successfully from the command line. >> >> So, um, what the bleep did I do wrong? >> >> Here's the output of the command "getent hosts localhost": >> >> ::1 localhost >> 127.0.0.1 localhost localhost.tristatelogic.com >> >> >> Any hints for how I can debug this mess would be appreciated. >> > >Do you have local_unbound running? It's probably caching the result. > >/etc/rc.d/local_unbound stop > >Then try your changes to /etc/hosts I have now rebooted the system multiple times, from a cold start, and this has had *no* effect on the output generated by "getent hosts localhos= t". That is *still* showing me that there exists a mapping from "localhost" to an IPv6 address, even though I commented that out in my /etc/hosts file. I really would like to understand why manual edits to /etc/hosts seem to have no effect whatosoever. And more importantly, I'd really still like to know whey X applications cannot seem to connect to the X server when and if DISPLAY is set to localhost:0.0 while they have no problem doing so when DISPLAY is instead set to :0.0 From owner-freebsd-net@freebsd.org Tue Jun 18 00:39:40 2019 Return-Path: Delivered-To: freebsd-net@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 C3B2C15C8F38 for ; Tue, 18 Jun 2019 00:39:40 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 789468976F for ; Tue, 18 Jun 2019 00:39:39 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id A49A1156E40C; Mon, 17 Jun 2019 17:39:17 -0700 (PDT) To: "Ronald F. Guilmette" cc: freebsd-net Subject: Re: localhost woes -- help requested In-reply-to: Your message of "Mon, 17 Jun 2019 13:15:22 -0700." <4468.1560802522@segfault.tristatelogic.com> References: <4468.1560802522@segfault.tristatelogic.com> Comments: In-reply-to "Ronald F. Guilmette" message dated "Mon, 17 Jun 2019 13:15:22 -0700." From: Bakul Shah MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <59492.1560818357.1@bitblocks.com> Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jun 2019 17:39:17 -0700 Message-Id: <20190618003925.A49A1156E40C@mail.bitblocks.com> X-Rspamd-Queue-Id: 789468976F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of bakul@bitblocks.com designates 173.228.5.8 as permitted sender) smtp.mailfrom=bakul@bitblocks.com X-Spamd-Result: default: False [-2.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.944,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:173.228.5.8/29]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bitblocks.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mail.bitblocks.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.68)[-0.681,0]; IP_SCORE(-0.15)[asn: 46375(-0.67), country: US(-0.06)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:46375, ipnet:173.228.0.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 00:39:41 -0000 On Mon, 17 Jun 2019 13:15:22 -0700 "Ronald F. Guilmette" wrote: Ronald F. Guilmette writes: > Adam wrote: > > >On Sat, Jun 15, 2019 at 12:54 AM Ronald F. Guilmette > >wrote: > >> ... except for the browsers, and also one other thing (nmh outbound > >> email handling). Now, both Firefox and Opera crash and burn, right > >> out of the gate, when started from the command line. In both cases > >> thet do so both with entirely cryptic failure messages. > >> > >> But here's the kicker... I futzed around with this awhile and found > >> out that if I just change the default value of the DISPLAY environmen= t > >> variable from "localhost:0.0" to ":0.0" then both browsers *do* then > >> start up successfully from the command line. > >> > >> So, um, what the bleep did I do wrong? > >> > >> Here's the output of the command "getent hosts localhost": > >> > >> ::1 localhost > >> 127.0.0.1 localhost localhost.tristatelogic.com > >> > >> > >> Any hints for how I can debug this mess would be appreciated. > >> > > > >Do you have local_unbound running? It's probably caching the result. > > > >/etc/rc.d/local_unbound stop > > > >Then try your changes to /etc/hosts > > I have now rebooted the system multiple times, from a cold start, and > this has had *no* effect on the output generated by "getent hosts localh= ost". > > That is *still* showing me that there exists a mapping from "localhost" > to an IPv6 address, even though I commented that out in my /etc/hosts > file. > > I really would like to understand why manual edits to /etc/hosts seem > to have no effect whatosoever. And more importantly, I'd really still > like to know whey X applications cannot seem to connect to the X server > when and if DISPLAY is set to localhost:0.0 while they have no problem > doing so when DISPLAY is instead set to :0.0 I ran into this as well. I tried tracing getent() through networking code in libc but this is quite a mess. And gdb doesn't work reliably either. No doubt there are some new switches I haven't explored. And threading. (gdb) where #0 0x080b127b in __vdso_clock_gettime (clock_id=3D12, ts=3D0xbfbfe100) at /usr/src/lib/libc/sys/__vdso_gettimeofday.c:149 #1 0x080a1a2e in __clock_gettime (clock_id=3D12, ts=3D0xbfbfe100) at /usr/src/lib/libc/sys/clock_gettime.c:46 #2 0x080dd47a in __res_state () at /usr/src/lib/libc/resolv/res_state.c:8= 2 #3 0x08097fdf in _ht_gethostbyname (rval=3D0xbfbfe698, cb_data=3D0x0, ap=3D0xbfbfe240 "T??\034") at /usr/src/lib/libc/net/gethostbyht.c:244 #4 0x08096f7f in _nsdispatch (retval=3D0xbfbfe698, disp_tab=3D0x80f6b30, database=3D, method_name=3D0x80f6b7c "gethostbyna= me2_r", defaults=3D0x80f6af4) at /usr/src/lib/libc/net/nsdispatch.c:704 #5 0x08095dba in gethostbyname_internal (name=3D0xbfbfe954 "localhost", a= f=3D28, hp=3D0x8107a00, buf=3D0x8107a14 "", buflen=3D8504, result=3D0xbfbfe698= , h_errnop=3D0xbfbfe694, statp=3D0x81128d4) at /usr/src/lib/libc/net/gethostnamadr.c:572 #6 0x08096539 in gethostbyname2 (name=3D0xbfbfe954 "localhost", af=3D28) at /usr/src/lib/libc/net/gethostnamadr.c:519 #7 0x08048b39 in hosts (argc=3D3, argv=3D0xbfbfe790) at getent.c:309 #8 0x08048402 in main (argc=3D3, argv=3D0xbfbfe790) at getent.c:112 Just manually s/localhost/127.0.0.1/g. From owner-freebsd-net@freebsd.org Tue Jun 18 01:08:12 2019 Return-Path: Delivered-To: freebsd-net@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 CDF0C15C993F for ; Tue, 18 Jun 2019 01:08:12 +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 B73ED8A9A1 for ; Tue, 18 Jun 2019 01:08:11 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id DE1464E64B; Mon, 17 Jun 2019 18:08:09 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-net Subject: Re: localhost woes -- help requested In-Reply-To: <20190618003925.A49A1156E40C@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6375.1560820089.1@segfault.tristatelogic.com> Date: Mon, 17 Jun 2019 18:08:09 -0700 Message-ID: <6376.1560820089@segfault.tristatelogic.com> X-Rspamd-Queue-Id: B73ED8A9A1 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.88 / 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]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.76)[ip: (-7.27), ipnet: 69.62.128.0/17(-3.63), asn: 14051(-2.86), country: US(-0.06)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; NEURAL_HAM_SHORT(-0.91)[-0.906,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 01:08:13 -0000 In message <20190618003925.A49A1156E40C@mail.bitblocks.com>, Bakul Shah wrote: >> I really would like to understand why manual edits to /etc/hosts seem >> to have no effect whatosoever. That's issue/question #1. >> And more importantly, I'd really still >> like to know whey X applications cannot seem to connect to the X server >> when and if DISPLAY is set to localhost:0.0 while they have no problem >> doing so when DISPLAY is instead set to :0.0 This is issue/questuon #2. >I ran into this as well. I tried tracing getent() through >networking code in libc but this is quite a mess. And gdb >doesn't work reliably either. No doubt there are some new >switches I haven't explored. And threading. Ok, I have an answer now on question #2. I asked some people who know way more about X than I do (which is actually almost eerybody), and as a result I found out the whole story. It seems that at some point it time, somebody decided that it would be Good if the default configuation(s) of the X server would no longer talk to clients, by default, using TCP. (I can only assume that this was most probably a very wise security improvement for the X server at the time.) So anyway, the other thing I learned is that if one has a hostname... i.e. *any* kind of a hostname... in one's DISPLAY environment variable value, then X clients will all try to connect to the server using TCP. And that will fail, as it should nowadays. Apparenttly this even includes "localhost", which is sort of a special kind of a hostname. My problem was that... unbeknownst to me... I had the following line, left over from ancient times, in one of my tcsh shell startup files: setenv DISPLAY localhost:0.0 I simply removed that, quit X, logged out, and logged back in again, and then started X again, and everything was perfect after that, most probably because all of my processes (after starting X) were now inheriting a proper and modern sort of value for DISPLAY, which is to say ":0". That's all there was to it. I'm still totally in the dark about Question #1 (above) however, but that is just a matter of idle curiosity now, now that I have all of my X clients working properly. Regards, rfg From owner-freebsd-net@freebsd.org Tue Jun 18 03:10:05 2019 Return-Path: Delivered-To: freebsd-net@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 7029215CCC9E; Tue, 18 Jun 2019 03:10:05 +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 9D1B38F055; Tue, 18 Jun 2019 03:10:04 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 78DE44E654; Mon, 17 Jun 2019 20:10:03 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: Eliminating IPv6 (?) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6974.1560827403.1@segfault.tristatelogic.com> Date: Mon, 17 Jun 2019 20:10:03 -0700 Message-ID: <6975.1560827403@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 9D1B38F055 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.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]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.81)[ip: (-7.39), ipnet: 69.62.128.0/17(-3.69), asn: 14051(-2.91), country: US(-0.06)]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.87)[-0.867,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 03:10:05 -0000 I do not wish to begin any religious war here. I understand that IPv6 can be a sensitive and sometimes even emotional issue for many people. Speaking only for myself, and only for the present moment, I can say that for me, IPv6 represents only an annoyance and a very sizable distraction. At present, I don't use it and have absolutely no need to do so. I would thus like to simplify my life by eliminating it from my (12.0-RELEASE) system, so that I won't even have to think about it, or wonder about it, e.g. when I am configuring my firewall, my daemons, etc. I have tried searching for instructions on how to do this online, but the suggestions and recommendations for how to do this vary widely. There does not seem to be any "standard" set of recommendations for how to simply turn off all IPv6 for a given system, short of rebuilding the kernel, from scratch, with proper options to eliminate IPv6 support in the kernel entirely. I finally settled on trying to add the following options to my /etc/rc.conf file: ipv6_network_interfaces="none" ip6addrctl_enable="NO" ip6addrctl_policy="ipv4_prefer" ipv6_activate_all_interfaces="NO" These seem to have worked only marginally. After a fresh reboot, my loopback interface (lo0) for example is still configured to have -both- IPv4 -and- IPv6 addresses... and routes... associated with it. How can I turn off IPv6 entirely without rebuilding the kernel? Regards, rfg P.S. Please, please, please, refrain from giving me a sermon about how I am an idiot and/or about how IPv6 is going to save mankind and/or the galaxy as we know it. I am pro choice, and I don't really wish to have IPv6 rammed down my throat before I am ready to swallow. I don't need it, don't use it, and for me, life is much simpler without it for now. From owner-freebsd-net@freebsd.org Tue Jun 18 03:36:55 2019 Return-Path: Delivered-To: freebsd-net@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 C975515CD749 for ; Tue, 18 Jun 2019 03:36:55 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 C2FA58FDFA for ; Tue, 18 Jun 2019 03:36:54 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-qt1-x834.google.com with SMTP id x47so13544599qtk.11 for ; Mon, 17 Jun 2019 20:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x9TZgraBpzomH+LoWGMCNyzUoXptads4KHowQPgWmec=; b=0sGu1GXbOb5Z8cktyinClfK7v4QzOGc/8mOamQQPvwyaIumIAl15r3z13yGU9Dqw/o PBj0HN0f6V+C22NorVcsqVuSfou5d/sfYmPAuRvrNkfgjE20VzPIcn0Z8RdQTH+cf808 +9lF/N5zSn3YET8jqEuZ0sD/kKVdHL46BZ3G6H876PaecGiiGPVBAHi0eQFi2bDB+TPd Fa6RKvuxGNcKo5zEohf5JsHq5zcH+Quk3b1MkH7mNQxCD7UPrsg8qoD3+zmTN0vuIAaG qP+d868voglwmUjCCDuRYyNGxV5XaLv8ErqzlynC9Af62OwbZRMI57s9pvtOJcxHo4C8 X/SQ== 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=x9TZgraBpzomH+LoWGMCNyzUoXptads4KHowQPgWmec=; b=S8wIsQd5hPdciarliVfT5ZdHlTvT7qSWpNHfiU6T0ATVDrKXVkrm7uFAYFjl5lN9d2 VE9kmUXFJFcj2+6hAnbHVRDTIVIfdy3qSTLYEwuiLaJ0bn7Q6rq3m9inunvszqv2WTXw ndiEELrnjj/9EtFww1MGoeb9JOMvZa5v+spWPtBekM3kPr3EfqdvFRN0dyGo5QPq2l4y cfB2uefIldcj1/rLcLcRKEASBfYuRbMf4t+7zhkMOZBU2E017dUd7APl/NLedxSWKWyr SV0ldS5Pdy91k+f+XUD5EQtS2yDasJHakoFexaKDqqy5SxMTJdIp4NUMNDTMr1WkwLzn XDTA== X-Gm-Message-State: APjAAAW09R7M5VnUnsYjohvFVG9NnCBKAW8irquvmS2m62rwR/PrKs47 DwHQ1hf+DhSM7xMxRcmEm0Tdw++L7psr+nOCvSXa9IaVzetWDA== X-Google-Smtp-Source: APXvYqyn0MV6B8T6sytH4zUQBVZVr2eUhgEiUio8z23Mcup134/rtN2WCK/NWGtCEplsJFHNw1mlnBlJlx5klngsPPM= X-Received: by 2002:ac8:2d08:: with SMTP id n8mr76466717qta.383.1560829013667; Mon, 17 Jun 2019 20:36:53 -0700 (PDT) MIME-Version: 1.0 References: <6975.1560827403@segfault.tristatelogic.com> In-Reply-To: <6975.1560827403@segfault.tristatelogic.com> From: Michael Sierchio Date: Mon, 17 Jun 2019 20:36:17 -0700 Message-ID: Subject: Re: Eliminating IPv6 (?) To: "Ronald F. Guilmette" Cc: FreeBSD Questions , "freebsd-net@freebsd.org" X-Rspamd-Queue-Id: C2FA58FDFA X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tenebras-com.20150623.gappssmtp.com header.s=20150623 header.b=0sGu1GXb X-Spamd-Result: default: False [-6.26 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[tenebras-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(-3.01)[ip: (-9.49), ipnet: 2607:f8b0::/32(-3.17), asn: 15169(-2.32), country: US(-0.06)]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[tenebras.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[tenebras-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[4.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]; NEURAL_HAM_SHORT(-0.95)[-0.947,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 03:36:56 -0000 On Mon, Jun 17, 2019 at 8:12 PM Ronald F. Guilmette wrote: > How can I turn off IPv6 entirely without rebuilding the kernel? Rebuild the kernel. One of the lovely things about FreeBSD is that you can build a monolithic kernel and don't have to build any kernel modules or permit them to be loaded. Insert one character in the GENERIC kernel conf and start from there #options INET6 # IPv6 communications protocols --=20 "Well," Brahm=C4=81 said, "even after ten thousand explanations, a fool is = no wiser, but an intelligent person requires only two thousand five hundred." - The Mah=C4=81bh=C4=81rata From owner-freebsd-net@freebsd.org Tue Jun 18 06:51:48 2019 Return-Path: Delivered-To: freebsd-net@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 CD67915D0DC7; Tue, 18 Jun 2019 06:51:48 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "eg.sd.rdtc.ru", Issuer "eg.sd.rdtc.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C717E9467C; Tue, 18 Jun 2019 06:51:37 +0000 (UTC) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-questions@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x5I6pKE3072322 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jun 2019 13:51:20 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Eliminating IPv6 (?) To: "Ronald F. Guilmette" , freebsd-questions@freebsd.org, freebsd-net@freebsd.org References: <6975.1560827403@segfault.tristatelogic.com> From: Eugene Grosbein Message-ID: Date: Tue, 18 Jun 2019 13:51:12 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6975.1560827403@segfault.tristatelogic.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: C717E9467C X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [0.67 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.42)[-0.415,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.25)[-0.247,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_SHORT(0.93)[0.928,0]; MX_INVALID(0.50)[greylisted]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; IP_SCORE(0.00)[country: RU(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29072, ipnet:2a03:3100::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 06:51:49 -0000 18.06.2019 10:10, Ronald F. Guilmette wrote: > How can I turn off IPv6 entirely without rebuilding the kernel? You cannot. GENERIC kernel specifically enables IPv6 support and you need to disable it at compile time. And if you do, you better rebuild the world too using WITHOUT_INET6=yes in the /etc/src.conf or else some utilities compiled with INET6 by default will query kernel for IPv6-specific data (like routing entries) and complain that your kernel does not know about it. World built WITHOUT_INET6 has no such rough edges. From owner-freebsd-net@freebsd.org Tue Jun 18 07:44:37 2019 Return-Path: Delivered-To: freebsd-net@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 975C815D2251; Tue, 18 Jun 2019 07:44:37 +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 1265396434; Tue, 18 Jun 2019 07:44:35 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id A4FC34E654; Tue, 18 Jun 2019 00:44:34 -0700 (PDT) From: "Ronald F. Guilmette" cc: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: Re: Eliminating IPv6 (?) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18747.1560843874.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jun 2019 00:44:34 -0700 Message-ID: <18748.1560843874@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 1265396434 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 [-3.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.977,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)[]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; IP_SCORE(-2.77)[ip: (-7.27), ipnet: 69.62.128.0/17(-3.64), asn: 14051(-2.86), country: US(-0.06)]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; RCPT_COUNT_TWO(0.00)[2]; MISSING_TO(2.00)[]; NEURAL_HAM_SHORT(-0.84)[-0.836,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 07:44:37 -0000 In message , = Eugene Grosbein wrote: >18.06.2019 10:10, Ronald F. Guilmette wrote: > >> How can I turn off IPv6 entirely without rebuilding the kernel? > >You cannot. GENERIC kernel specifically enables IPv6 support and you need= to >disable it at compile time. >And if you do, you better rebuild the world too using WITHOUT_INET6=3Dyes= in the >/etc/src.conf >or else some utilities compiled with INET6 by default will query kernel >for IPv6-specific data (like routing entries) and complain that your kern= el does = >not know about it. > >World built WITHOUT_INET6 has no such rough edges. OK, so I obviously expressed myself badly. Let me try again. IPv6 support is enabled in a the stock kernel. OK. Fine. But just becau= se that feature is present in the kernel, that does not imply that anything i= n userland -has- to actually make any use of it at all. *Something* is doing ifconfig on my loopback (lo0) interface. What is tha= t thing and how can I get it to stop doing that? As I have already learned, the /etc/rc.firewall script also assumes both t= he presence of, and the desirability of IPv6 support. And unless one edits t= hat file manually... which I have been effectively forced to do... there is no= way to get it to simply NOT create and install multiple IPv6-related ipfw rule= s, EVEN THOUGH in my particular situation... which is still the most common c= ase... those extra and entirely superfluous IPv6 ipfw filtering rules are serving no earthly purpose whatsoever and are only cluttering up my ipfw rule set, thus pointlessly making it harder for me to grok and maintain them all. Clearly, if doesn't have to be this way. Some maintainers just decided th= at I and all other IPv4-only users should get stuck dealing with a lot of use= less, unnecessary and distracting IPv6 stuff, whether I like it or not, and pres= umably for our own good. I really wish that maintainers would allow me a bit more freedom, and show me the courtesy and respect to allow me to decide for myself what is and w= hat isn't "for my own good". I can and will most certainly get down and grovel around in the various /etc/rc.d/ scripts and will comment out those parts that do things like ifconfig'ing my loopback interface for IPv6, whether I like it or not. But there ought to be some single /etc/rc.conf variable via which one coul= d simply select the "No, I don't want to have to deal with IPv6 at all right now" option. Is that really an unreasonable hope, expectation, and request? I understand that the kernel will still -offer- the IPv6 support. But if n= o -other- software on my system actually takes the kernel up on that offer, then the kernel's IPv6 support becomes like the tree that falls in the forrest when there is nobody around to hear it. It might as well be said that it makes no sound, and no difference to anything at all. It is clearly not necessary for me or anyone else to have to rebuild the kernel... *and* world... just in order to get rid of what are, for the majority of users here in 2019, still a bunch of utterly superfluous IPv6 "features" that (a) do not help us one iota and that (b) are all just a big and pointless distraction that muddles everything and unnecessarily complicates and complexifies ordinary system maintenance tasks. IPv6 is great and I'm sure I'll be using it someday. But today is not tha= t day... not for me, and also not for one hell of a lot of other users. The fact that I and others are effectively being forced to even think about it= , due to an absence of reasonable and easily accessible userland options, is actually a big turn-off, and leaves a bad taste in the mouth which will be remembered, in future, at every mention of IPv6. I hope that all of th= e IPv6 evanglists will take a moment to stop and think about that, and that they'll stop effectively forcing those of us who don't need it to both use IPv6 and to think about it, whether we like it or not, and before we are r= eady, willing, and able to do so. Regards, rfg P.S. In case I have again failed to be clear, I am proposing a new /etc/r= c.conf option. Something simple and intutive like: ipv6=3D"NO" That in turn should be checked -and- respected by all relevant /etc/rc,d/ scripts. I ask again, is this really such an unreasonable thing to hope for? From owner-freebsd-net@freebsd.org Tue Jun 18 07:55:34 2019 Return-Path: Delivered-To: freebsd-net@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 2DAD915D28D3; Tue, 18 Jun 2019 07:55:34 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (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 CF77496B86; Tue, 18 Jun 2019 07:55:27 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [217.29.44.10]) by gate2.intern.punkt.de with ESMTP id x5I7t63G031951; Tue, 18 Jun 2019 09:55:17 +0200 (CEST) Received: from [217.29.44.36] ([217.29.44.36]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id x5I7srkb056878; Tue, 18 Jun 2019 09:54:53 +0200 (CEST) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Eliminating IPv6 (?) From: "Patrick M. Hausen" In-Reply-To: <18748.1560843874@segfault.tristatelogic.com> Date: Tue, 18 Jun 2019 09:54:53 +0200 Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9AF5DF39-9B81-4270-B25C-D089C971E924@punkt.de> References: <18748.1560843874@segfault.tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: CF77496B86 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hausen@punkt.de designates 217.29.33.131 as permitted sender) smtp.mailfrom=hausen@punkt.de X-Spamd-Result: default: False [-2.21 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.967,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:217.29.32.0/20]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[punkt.de]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mailin.pluspunkthosting.de,mailin.pluspunkthosting.de]; NEURAL_HAM_SHORT(-0.23)[-0.228,0]; RCVD_IN_DNSWL_NONE(0.00)[131.33.29.217.list.dnswl.org : 127.0.10.0]; IP_SCORE(-0.21)[ipnet: 217.29.32.0/20(-0.57), asn: 16188(-0.46), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 07:55:34 -0000 Hi! > Am 18.06.2019 um 09:44 schrieb Ronald F. Guilmette = : > As I have already learned, the /etc/rc.firewall script also assumes = both the > presence of, and the desirability of IPv6 support. And unless one = edits that > file manually... which I have been effectively forced to do... there = is no way > to get it to simply NOT create and install multiple IPv6-related ipfw = rules, > EVEN THOUGH in my particular situation... which is still the most = common case... > those extra and entirely superfluous IPv6 ipfw filtering rules are = serving > no earthly purpose whatsoever and are only cluttering up my ipfw rule = set, > thus pointlessly making it harder for me to grok and maintain them = all. Instead of messing with the system provided file you could create a new one with only your own desired rules and then set this rc.conf variable: firewall_script=3D"/etc/rc.firewall" # Which script to run to = set up the firewall As for the rest of your request, yes, I find it unreasonably in 2019 but let=E2=80=99s not get into a fight about that. IPv6 is here to stay. If = you boot any Mac or Windows 10 desktop, IPv6 will be active and even necessary for service autodiscovery and similar things to work. Kind regards Patrick --=20 punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe info@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling From owner-freebsd-net@freebsd.org Tue Jun 18 08:09:20 2019 Return-Path: Delivered-To: freebsd-net@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 65BFC15AF0F4; Tue, 18 Jun 2019 08:09:20 +0000 (UTC) (envelope-from christian.baltini@gmail.com) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 89077972A7; Tue, 18 Jun 2019 08:09:19 +0000 (UTC) (envelope-from christian.baltini@gmail.com) Received: by mail-pf1-x441.google.com with SMTP id a186so7188879pfa.5; Tue, 18 Jun 2019 01:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G7npJ0WIttB0tRi8YGo6AeDCeK8BmfMleTkOb1ARzys=; b=PJxFmzzIp0ELEYjfNBK4L5dAC+Tex9lN9BWSnIWtPGxAdYH2cJ3ECYUOpJtOuWYlDA cV3OHdicIIzYTKmhrFezehX/3z9xgtrpKxcbbOfoGbxa43TsM45oR9duumfCc0K+45Uv XTIMpIRKpwFcpRZ7z+WLVfoRzuSzSKWsBjcJpS9+3HxelrBIgyFER79KlAzHPx2QJIu3 nkgTD8ZMFroDo/FQH+rR/4dEq+kRV2v0F+fMsKWOMlo1R6EENEA5EQ6R2uMEvnKMzbEu fDWpg6+RMdaEhV/ynIlBtzT39CkDU7y7VLnAz9NHjOMZ2dpRPyLg4YD00/WEPNmCmWQv UR5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G7npJ0WIttB0tRi8YGo6AeDCeK8BmfMleTkOb1ARzys=; b=f8EKPlZpBxnGCMQemGyxWK6rFrcocO8lkNW+fmJyoiETfx+IrHysvP6IrqDFcsmmrC AKSzABDnM+6spafiJhABmNNe5vqG4ydaP/07ZDSI5Bl4NQOg0EL08tMYAdZlC/wKgVvl PXF8Dp6wck1xPR/HbkAU79RV/NrvjqusZ7IxKnjsnv9OYuM/B65gTDKYPXoHRHBgk8+1 evDJzqTlJj/W6bX1CbfVoJ0SbSYKJZULEWGej0NrHI4p6OQPyjcm4fkMlBrT+K/yQ46q YYdIm8Go4j82vPlfggKrVBHxsKOeym9du1A+G2cA2WJV9x4DGdnHX+cbYCJtJCJ6msIb mxCg== X-Gm-Message-State: APjAAAX2g7Md1MmVGQAxNHifFXVvbJT9acXGRbw51lD6w+G0O9J7rhoW SAg7Q0aTKTw6hxx+l4an2BbwJbGX X-Google-Smtp-Source: APXvYqwgGk99UWJoUw5Icoc8DkzYXB47MQXUCLlY6F7YvZLc3DRvzcAOf3yw2u5DVLAdrU4cU0gHvg== X-Received: by 2002:a65:44c8:: with SMTP id g8mr1507377pgs.443.1560845358426; Tue, 18 Jun 2019 01:09:18 -0700 (PDT) Received: from [10.0.100.116] (71-84-34-209.dhcp.mtpk.ca.charter.com. [71.84.34.209]) by smtp.gmail.com with ESMTPSA id y22sm14065479pfm.70.2019.06.18.01.09.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jun 2019 01:09:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Eliminating IPv6 (?) From: christian russell In-Reply-To: <18748.1560843874@segfault.tristatelogic.com> Date: Tue, 18 Jun 2019 01:09:16 -0700 Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <18748.1560843874@segfault.tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 89077972A7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=PJxFmzzI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of christianbaltini@gmail.com designates 2607:f8b0:4864:20::441 as permitted sender) smtp.mailfrom=christianbaltini@gmail.com X-Spamd-Result: default: False [-4.51 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.96)[-0.958,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; 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]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.04)[ip: (0.36), ipnet: 2607:f8b0::/32(-3.17), asn: 15169(-2.32), country: US(-0.06)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.4.4.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] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 08:09:20 -0000 My opinion is that being able to practically ignore IPv6, without = operational detraction, is a reasonable degree of freedom. FreeBSD = isn=E2=80=99t pushing IPv6 any more or less than any other mainstream = OSes. Given a set number of developer hours I would prefer that IPv6 be fully = implemented and functionally "ignorable" as opposed to dev time being = spent allowing an essentially cosmetic opting out of IPv6 functionality. = Even more generally I would prefer any dev time time be spent on active = issues and new features. > I ask again, is this really such an unreasonable thing to hope for? If I were allocating work-hours on FreeBSD development my answer would = be: =E2=80=9Cyup" =C2=AF\_(=E3=83=84)_/=C2=AF Christian > On Jun 18, 2019, at 12:44 AM, Ronald F. Guilmette = wrote: >=20 > In message ,=20 > Eugene Grosbein wrote: >=20 >> 18.06.2019 10:10, Ronald F. Guilmette wrote: >>=20 >>> How can I turn off IPv6 entirely without rebuilding the kernel? >>=20 >> You cannot. GENERIC kernel specifically enables IPv6 support and you = need to >> disable it at compile time. >> And if you do, you better rebuild the world too using = WITHOUT_INET6=3Dyes in the >> /etc/src.conf >> or else some utilities compiled with INET6 by default will query = kernel >> for IPv6-specific data (like routing entries) and complain that your = kernel does=20 >> not know about it. >>=20 >> World built WITHOUT_INET6 has no such rough edges. >=20 > OK, so I obviously expressed myself badly. Let me try again. >=20 > IPv6 support is enabled in a the stock kernel. OK. Fine. But just = because > that feature is present in the kernel, that does not imply that = anything in > userland -has- to actually make any use of it at all. >=20 > *Something* is doing ifconfig on my loopback (lo0) interface. What is = that > thing and how can I get it to stop doing that? >=20 > As I have already learned, the /etc/rc.firewall script also assumes = both the > presence of, and the desirability of IPv6 support. And unless one = edits that > file manually... which I have been effectively forced to do... there = is no way > to get it to simply NOT create and install multiple IPv6-related ipfw = rules, > EVEN THOUGH in my particular situation... which is still the most = common case... > those extra and entirely superfluous IPv6 ipfw filtering rules are = serving > no earthly purpose whatsoever and are only cluttering up my ipfw rule = set, > thus pointlessly making it harder for me to grok and maintain them = all. >=20 > Clearly, if doesn't have to be this way. Some maintainers just = decided that > I and all other IPv4-only users should get stuck dealing with a lot of = useless, > unnecessary and distracting IPv6 stuff, whether I like it or not, and = presumably > for our own good. >=20 > I really wish that maintainers would allow me a bit more freedom, and = show > me the courtesy and respect to allow me to decide for myself what is = and what > isn't "for my own good". >=20 > I can and will most certainly get down and grovel around in the = various > /etc/rc.d/ scripts and will comment out those parts that do things = like > ifconfig'ing my loopback interface for IPv6, whether I like it or not. > But there ought to be some single /etc/rc.conf variable via which one = could > simply select the "No, I don't want to have to deal with IPv6 at all = right > now" option. >=20 > Is that really an unreasonable hope, expectation, and request? >=20 > I understand that the kernel will still -offer- the IPv6 support. But = if no > -other- software on my system actually takes the kernel up on that = offer, > then the kernel's IPv6 support becomes like the tree that falls in the > forrest when there is nobody around to hear it. It might as well be = said > that it makes no sound, and no difference to anything at all. >=20 > It is clearly not necessary for me or anyone else to have to rebuild = the > kernel... *and* world... just in order to get rid of what are, for the > majority of users here in 2019, still a bunch of utterly superfluous = IPv6 > "features" that (a) do not help us one iota and that (b) are all just = a > big and pointless distraction that muddles everything and = unnecessarily > complicates and complexifies ordinary system maintenance tasks. >=20 > IPv6 is great and I'm sure I'll be using it someday. But today is not = that > day... not for me, and also not for one hell of a lot of other users. = The > fact that I and others are effectively being forced to even think = about it, > due to an absence of reasonable and easily accessible userland = options, is > actually a big turn-off, and leaves a bad taste in the mouth which = will > be remembered, in future, at every mention of IPv6. I hope that all = of the > IPv6 evanglists will take a moment to stop and think about that, and = that > they'll stop effectively forcing those of us who don't need it to both = use > IPv6 and to think about it, whether we like it or not, and before we = are ready, > willing, and able to do so. >=20 >=20 > Regards, > rfg >=20 >=20 > P.S. In case I have again failed to be clear, I am proposing a new = /etc/rc.conf > option. Something simple and intutive like: >=20 > ipv6=3D"NO" >=20 > That in turn should be checked -and- respected by all relevant = /etc/rc,d/ > scripts. >=20 > I ask again, is this really such an unreasonable thing to hope for? > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Tue Jun 18 08:29:59 2019 Return-Path: Delivered-To: freebsd-net@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 6666715B01F2 for ; Tue, 18 Jun 2019 08:29:59 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D39A68136 for ; Tue, 18 Jun 2019 08:29:57 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 60B5D3936A9; Tue, 18 Jun 2019 04:29:51 -0400 (EDT) Date: Tue, 18 Jun 2019 04:29:51 -0400 From: Viktor Dukhovni To: freebsd-net@freebsd.org Subject: Re: Eliminating IPv6 (?) Message-ID: <20190618082951.GA84864@straasha.imrryr.org> References: <18748.1560843874@segfault.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: 1D39A68136 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of ietf-dane@dukhovni.org designates 100.2.39.101 as permitted sender) smtp.mailfrom=ietf-dane@dukhovni.org X-Spamd-Result: default: False [-2.06 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.50)[-0.503,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:100.2.39.101]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dukhovni.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.82)[-0.824,0]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[101.39.2.100.list.dnswl.org : 127.0.6.2]; MX_GOOD(-0.01)[smtp.dukhovni.org]; NEURAL_HAM_SHORT(-0.44)[-0.445,0]; IP_SCORE(0.22)[asn: 701(1.18), country: US(-0.06)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:100.2.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 08:29:59 -0000 On Tue, Jun 18, 2019 at 01:09:16AM -0700, christian russell wrote: > > I ask again, is this really such an unreasonable thing to hope for? > > If I were allocating work-hours on FreeBSD development my answer would be: “yup" ¯\_(ツ)_/¯ Agreed. I find it takes very little effort to not have IPv6 get in my way, and with that taken care of, it is then occasionally even useful. If this thread boils down to annoyance about localhost resolving to both "::1" and "127.0.0.1" then use "127.0.0.1" instead of "localhost" in any configuration files where that's what you mean. Though the draft has been dormant for a while, at some point "localhost" may indeed simply be hardwired into libraries, rather than delegated to name resolution mechanisms: https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02 The unbound resolver has a default "localhost" zone: localhost The IP4 and IP6 localhost information is given. NS and SOA records are provided for completeness and to satisfy some DNS update tools. Default content: local-zone: "localhost." redirect local-data: "localhost. 10800 IN NS localhost." local-data: "localhost. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800" local-data: "localhost. 10800 IN A 127.0.0.1" local-data: "localhost. 10800 IN AAAA ::1" With just the "IPv4" address for "localhost" in /etc/hosts, getaddrinfo() performs the AAAA lookup via DNS! But likely with a default domain appended. Therefore, additional local-data may be needed for "localhost.example.org." to authoritatively deny the existence of the IPv6 address. But all of that is much work for little gain. Far simpler to just make "::1" work, and/or use "127.0.0.1" instead of localhost as needed. -- Viktor. From owner-freebsd-net@freebsd.org Tue Jun 18 08:33:45 2019 Return-Path: Delivered-To: freebsd-net@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 E4ADB15B07F3; Tue, 18 Jun 2019 08:33:44 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3019269A93; Tue, 18 Jun 2019 08:33:43 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from bsdondell.lab.pwste.edu.pl ([IPv6:2001:678:618:3067:4d7c:5809:f7b3:c95f]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id x5I8XdAa059962 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 18 Jun 2019 10:33:39 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1560846820; bh=193YLTqEEij86qrqD0qKtyvf+cmdaXCWtIbfiExdG6s=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=DQmnypoxkVBpADC8t1z9MIFfsoZ1mOsCHN4eQl1wXI+qAGdqMTV3oDGT3iZsVRPTI 4T6eKiAow0ErkgF168180r081C7Jo8hzfRef81qIkNutZwuICZhDv/WF/DlTxrp0zx omz9QTADg1sILE1TNhn2ATWp33G/3yvJuzk740lvZAm3t5gYgtJy7TfRhAxZiJxVvf ZFE3MWFWazVj0l7t+TsLmGIzERvF4kw4sidArF9fNnj3jWXlKHx2m8lpxxWbyxit/O 02upUxgVnLr9WQtrtKdM8TsH5mwVgWaNcROVHPH1601VQiRo17RmdvFKRB74ewpJll CyxYV22BM4Byw== X-Authentication-Warning: plan-b.pwste.edu.pl: Host [IPv6:2001:678:618:3067:4d7c:5809:f7b3:c95f] claimed to be bsdondell.lab.pwste.edu.pl To: christian russell , "Ronald F. Guilmette" Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org References: <18748.1560843874@segfault.tristatelogic.com> From: Marek Zarychta Openpgp: preference=signencrypt Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= mQENBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAG0N01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD6JATcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgbkBDQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABiQEf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V65AQ0EV+OTdwEIAMxnGg7OO/ZAnSwiIiABA9lil1Lfa5BWTH3c l1rz4slz7Gw99G9J3bX3FiPA0vU89dgBZ2k0/UVk5cI5EsMAvwJN4bPwRsfBELQqjCKkVZr4 vUeGyvgQ2jnoK1fcEFOnCRdwFy4EJ6Y/fsZCTj4IfQpkM1W7C3KuSGPcjPDA9XCLDjjp8bbA Q9VgQ68MntAnYxMqK0S3CrHp5Pruvb0x4MfFLNwaKtWK+UnJGPT4umj8PMP6XLsFC3g+SGoP aWoYRDI297ZGx4IBWEaJq181oEC5iUQ6WREti9fNQ3TsAB3Q2CjNlkx1geSczIFJSyOHmyJZ RqAocw1sIuPopvhWtR0AEQEAAYkCRAQYAQgADwUCV+OTdwIbAgUJCWYBgAEpCRAdlby8gWmm gsBdIAQZAQgABgUCV+OTdwAKCRB1n+z//VKNLOETCAC3ggwAAQij4hkIxQFapnRuIVb5vq7D AwJ9+Ld5/zYHOj2Tfu+BPSNGzI2edqboz2w1t55UHEYzYDp2axxIfPrZrXsBV4DsjtGwzVV/ jZ9or5qTaYFDEStRkzL4mRpTyYhl/T7GgWpwOJWOih+cU7RWzjSOxiYMi4QSYlkpDUCcZew0 C3HfcxeFqpeL46zgysHC2ptjINXQ+xR2/F6dbed+l7OsvJAfkBqJoQ/48m+8ly1lbViKck7q gWw143ljaKn2qGIjZdb95zcI/CP4L45SXq8NOweACdx2NfUphLrIMbNCqLkMUJcrnruKfbnp C8OMjFJIqlu+PsW593NcZyOugEAH/0cBsDxlSauSVK4kp8ald26pcBI6igNnIMgjaxMiZBjn eoxBiKAOAO93sPnPr9/64CMMwv1T+0vU2lj8SMKOdHVrB9sW/ICGji5skE85xPEAtUkdAQN+ +c2clotujcaj9lBZKJdncKmSxY0SshEa66H+s76u+2Q3jGK6vOrdxakWYCvh2P0/l52Nd/t2 eazLFgwtk5rbo7O0MSC1GNXUsG07vtZ+zxJXFRx7PQ3ZIn0Y4HqwvXUvqgZ9EHiKy8F+ondz 9IS8/Fs81N5ieujHhSWqbaibapnpeDHvT/FWf8iXfJqWq+F7C8lGShSkmsS5AOhB4TNNH5/m ZzECJa1ql64= Subject: Re: Eliminating IPv6 (?) Message-ID: Date: Tue, 18 Jun 2019 10:33:26 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="y82voBVt9gqr51QdkbZu1xABDhKCgtYM6" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 08:33:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --y82voBVt9gqr51QdkbZu1xABDhKCgtYM6 Content-Type: multipart/mixed; boundary="BfDSwDzC7bR85rPfzkw1pWXvCEn7cc9TH"; protected-headers="v1" From: Marek Zarychta To: christian russell , "Ronald F. Guilmette" Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Message-ID: Subject: Re: Eliminating IPv6 (?) References: <18748.1560843874@segfault.tristatelogic.com> In-Reply-To: --BfDSwDzC7bR85rPfzkw1pWXvCEn7cc9TH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US W dniu 18.06.2019 o=C2=A010:09, christian russell pisze: > My opinion is that being able to practically ignore IPv6, without opera= tional detraction, is a reasonable degree of freedom. FreeBSD isn=E2=80=99= t pushing IPv6 any more or less than any other mainstream OSes. > > Given a set number of developer hours I would prefer that IPv6 be fully= implemented and functionally "ignorable" as opposed to dev time being sp= ent allowing an essentially cosmetic opting out of IPv6 functionality. E= ven more generally I would prefer any dev time time be spent on active is= sues and new features. > >> I ask again, is this really such an unreasonable thing to hope for? > If I were allocating work-hours on FreeBSD development my answer would = be: =E2=80=9Cyup" =C2=AF\_(=E3=83=84)_/=C2=AF > > Christian Dual stack support looks like a reasonable solution these days and works fine in 99% of network scenarios. From the other hand the ability to completely disable legacy IP should be considered as well. Some people consider IPv6 only network to be providing a sufficient degree of freedom but in 2019 we still lack DHCPv6 client in base. --=20 Marek Zarychta > >> On Jun 18, 2019, at 12:44 AM, Ronald F. Guilmette wrote: >> >> In message ,=20 >> Eugene Grosbein wrote: >> >>> 18.06.2019 10:10, Ronald F. Guilmette wrote: >>> >>>> How can I turn off IPv6 entirely without rebuilding the kernel? >>> You cannot. GENERIC kernel specifically enables IPv6 support and you = need to >>> disable it at compile time. >>> And if you do, you better rebuild the world too using WITHOUT_INET6=3D= yes in the >>> /etc/src.conf >>> or else some utilities compiled with INET6 by default will query kern= el >>> for IPv6-specific data (like routing entries) and complain that your = kernel does=20 >>> not know about it. >>> >>> World built WITHOUT_INET6 has no such rough edges. >> OK, so I obviously expressed myself badly. Let me try again. >> >> IPv6 support is enabled in a the stock kernel. OK. Fine. But just b= ecause >> that feature is present in the kernel, that does not imply that anythi= ng in >> userland -has- to actually make any use of it at all. >> >> *Something* is doing ifconfig on my loopback (lo0) interface. What is= that >> thing and how can I get it to stop doing that? >> >> As I have already learned, the /etc/rc.firewall script also assumes bo= th the >> presence of, and the desirability of IPv6 support. And unless one edi= ts that >> file manually... which I have been effectively forced to do... there i= s no way >> to get it to simply NOT create and install multiple IPv6-related ipfw = rules, >> EVEN THOUGH in my particular situation... which is still the most comm= on case... >> those extra and entirely superfluous IPv6 ipfw filtering rules are ser= ving >> no earthly purpose whatsoever and are only cluttering up my ipfw rule = set, >> thus pointlessly making it harder for me to grok and maintain them all= =2E >> >> Clearly, if doesn't have to be this way. Some maintainers just decide= d that >> I and all other IPv4-only users should get stuck dealing with a lot of= useless, >> unnecessary and distracting IPv6 stuff, whether I like it or not, and = presumably >> for our own good. >> >> I really wish that maintainers would allow me a bit more freedom, and = show >> me the courtesy and respect to allow me to decide for myself what is a= nd what >> isn't "for my own good". >> >> I can and will most certainly get down and grovel around in the variou= s >> /etc/rc.d/ scripts and will comment out those parts that do things lik= e >> ifconfig'ing my loopback interface for IPv6, whether I like it or not.= >> But there ought to be some single /etc/rc.conf variable via which one = could >> simply select the "No, I don't want to have to deal with IPv6 at all r= ight >> now" option. >> >> Is that really an unreasonable hope, expectation, and request? >> >> I understand that the kernel will still -offer- the IPv6 support. But = if no >> -other- software on my system actually takes the kernel up on that off= er, >> then the kernel's IPv6 support becomes like the tree that falls in the= >> forrest when there is nobody around to hear it. It might as well be s= aid >> that it makes no sound, and no difference to anything at all. >> >> It is clearly not necessary for me or anyone else to have to rebuild t= he >> kernel... *and* world... just in order to get rid of what are, for the= >> majority of users here in 2019, still a bunch of utterly superfluous I= Pv6 >> "features" that (a) do not help us one iota and that (b) are all just = a >> big and pointless distraction that muddles everything and unnecessaril= y >> complicates and complexifies ordinary system maintenance tasks. >> >> IPv6 is great and I'm sure I'll be using it someday. But today is not= that >> day... not for me, and also not for one hell of a lot of other users. = The >> fact that I and others are effectively being forced to even think abou= t it, >> due to an absence of reasonable and easily accessible userland options= , is >> actually a big turn-off, and leaves a bad taste in the mouth which wil= l >> be remembered, in future, at every mention of IPv6. I hope that all o= f the >> IPv6 evanglists will take a moment to stop and think about that, and t= hat >> they'll stop effectively forcing those of us who don't need it to both= use >> IPv6 and to think about it, whether we like it or not, and before we a= re ready, >> willing, and able to do so. >> >> >> Regards, >> rfg >> >> >> P.S. In case I have again failed to be clear, I am proposing a new /e= tc/rc.conf >> option. Something simple and intutive like: >> >> ipv6=3D"NO" >> >> That in turn should be checked -and- respected by all relevant /etc/rc= ,d/ >> scripts. >> >> I ask again, is this really such an unreasonable thing to hope for? >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"= > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --BfDSwDzC7bR85rPfzkw1pWXvCEn7cc9TH-- --y82voBVt9gqr51QdkbZu1xABDhKCgtYM6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAl0Iod0ACgkQdZ/s//1S jSwZvwf/agEmz2iZbmOJQGdC5jiR5/Gd3VXDj4XI2XtHXcc1btqowrmaPB4gEREn 6lMihXMMM3p4FWoO6W87AuoNcxiX3vnkdGre/K+m19tuPLybDryXl11C7FZOSXrS 0TYgPapR+uyhBhs3j4MLxOn2HLgWpwOFXfOUc/gb2LKTIFGySEllgbbv5iQL+tFC DVzwLyHGBp7anwK3DDWYICSyyxpoDR6onYU0sZeuGO/UN9FruJRQW3b8WoDKgAyh /FtSPSbE83R3Ut3c+LiF3nDBiPkqzxVmYHCYSBLAiLfZmKMw40mFSXAsWeWIrL1L bpaxFwRIf9kHu//dVGVafelanAWWDg== =qhLx -----END PGP SIGNATURE----- --y82voBVt9gqr51QdkbZu1xABDhKCgtYM6-- From owner-freebsd-net@freebsd.org Tue Jun 18 08:39:49 2019 Return-Path: Delivered-To: freebsd-net@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 6EDC315B0E73; Tue, 18 Jun 2019 08:39:49 +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 0055969E82; Tue, 18 Jun 2019 08:39:47 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id DC90B4E64B; Tue, 18 Jun 2019 01:39:46 -0700 (PDT) From: "Ronald F. Guilmette" cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Eliminating IPv6 (?) In-Reply-To: <9AF5DF39-9B81-4270-B25C-D089C971E924@punkt.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19573.1560847186.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jun 2019 01:39:46 -0700 Message-ID: <19574.1560847186@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 0055969E82 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 [-3.40 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.977,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)[]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; IP_SCORE(-2.72)[ip: (-7.16), ipnet: 69.62.128.0/17(-3.58), asn: 14051(-2.82), country: US(-0.06)]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; RCPT_COUNT_TWO(0.00)[2]; MISSING_TO(2.00)[]; NEURAL_HAM_SHORT(-0.49)[-0.487,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 08:39:49 -0000 In message <9AF5DF39-9B81-4270-B25C-D089C971E924@punkt.de>, = "Patrick M. Hausen" wrote: > Am 18.06.2019 um 09:44 schrieb Ronald F. Guilmette : >> As I have already learned, the /etc/rc.firewall script also assumes bot= h the >> presence of, and the desirability of IPv6 support. And unless one edit= s that >> file manually... which I have been effectively forced to do... there is= no way >> to get it to simply NOT create and install multiple IPv6-related ipfw r= ules, >> EVEN THOUGH in my particular situation... which is still the most commo= n case... >> those extra and entirely superfluous IPv6 ipfw filtering rules are serv= ing >> no earthly purpose whatsoever and are only cluttering up my ipfw rule s= et, >> thus pointlessly making it harder for me to grok and maintain them all. > >Instead of messing with the system provided file you could >create a new one with only your own desired rules and then set >this rc.conf variable: > > firewall_script=3D"/etc/rc.firewall" Actually, no, that's not how one is supposed to enable one's own set of ipfw ules. To do that, the Handbook (Sec. 30.4.1) says very clearly that one should do: firewall_enable=3D"YES" firewall_type=3D"path-to-my-rules-file" But I'm glad you brought it up. The funny thing is that even that doesn't work properly nowadays *or* like it used to in the past. I did that exact thing when putting together my shiny new 12.0-RELEASE system recently, as prescribed by the Handbook, just as I have done in the past on my prior FreeBSD systems. The result was no longer as expected. It seems that somwhere along the line, sometime between the last time I did a totally fresh install of FreeBSD (which I admit was some years ago now) and today, *somebody* apparently came to the conclusion that ordinary end lusers like me could not be fully trusted to supply 100% of their own ipfw rules, and thus, noadays, EVEN IF the user does exactly what you suggested, and tries (according to the guidance given in the Handbook) to supply his/her own set of ipfw rules, nowadays the /etc/rc.firewall script still gets invoked, and it *insists* on *adding* some ipfw rules to the set the user supplies in the named file. And to add insult to injury, some of those additional "whether you like it or not" ipfw rules specifically involve IPv6, which, as I have already said, I don't want, dont need, and which are just a pointless annoyance. Check it out for yourself if you don't believe me. (I have been debating with myself as to whether or not I should file a formal PR on this. I guess that I will. It is incredible but apparently true that even for those folks who want to write their own ipfw rule sets, 100%, *somebody* decided the we should not be allowed to do that 100% anymore. Apparently, I am not to be trusted to perform this task, for my own systems, all on my own anymore.) >As for the rest of your request, yes, I find it unreasonably in 2019 but >let's not get into a fight about that. IPv6 is here to stay. If you boot = any >Mac or Windows 10 desktop, IPv6 will be active and even necessary for >service autodiscovery and similar things to work. If true, I call that sloppy, careless, and lazy bad design. And that is being generous on my part. What services must be autodiscovered via IPv6 that could not be just as easily autodiscovered via IPv4 RFC1918 addresses... as had been done for at least a couple of decades already? (I have a printer right here next to me that has been successfully autodiscovered by Windows, by Linux, and by FreeBSD, all over an IPv4-only network.) I well and truly unxderstand that various entities have a clear financial interest in effectively forcing me... and hundreds of millions of others..= . to purchase all new equipmwent, but if what you said it true then that really takes the cake, because there is no compelling reason for it other than the commercial interests of various equipment vendors. There are two ways to induce people to do things that they otherwise would not do... carrots and sticks. For me, IPv6 right now is all sticks and no carrots. If I want to be abused, mistreated and forced to do things that I don't much feel like doing... well... I already have relatives for that. Regards, rfg From owner-freebsd-net@freebsd.org Tue Jun 18 08:52:58 2019 Return-Path: Delivered-To: freebsd-net@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 AA8A015B1973 for ; Tue, 18 Jun 2019 08:52:58 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 829B56A923 for ; Tue, 18 Jun 2019 08:52:57 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Received: by straasha.imrryr.org (Postfix, from userid 1001) id D7BAE3936F3; Tue, 18 Jun 2019 04:52:56 -0400 (EDT) Date: Tue, 18 Jun 2019 04:52:56 -0400 From: Viktor Dukhovni To: freebsd-net@freebsd.org Subject: Re: Eliminating IPv6 (?) Message-ID: <20190618085256.GB84864@straasha.imrryr.org> References: <9AF5DF39-9B81-4270-B25C-D089C971E924@punkt.de> <19574.1560847186@segfault.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19574.1560847186@segfault.tristatelogic.com> User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: 829B56A923 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of ietf-dane@dukhovni.org designates 100.2.39.101 as permitted sender) smtp.mailfrom=ietf-dane@dukhovni.org X-Spamd-Result: default: False [-0.77 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.32)[-0.322,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:100.2.39.101]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dukhovni.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.41)[-0.405,0]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.25)[0.247,0]; RCVD_IN_DNSWL_MED(-0.20)[101.39.2.100.list.dnswl.org : 127.0.6.2]; MX_GOOD(-0.01)[cached: smtp.dukhovni.org]; IP_SCORE(0.22)[asn: 701(1.17), country: US(-0.06)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:100.2.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 08:52:58 -0000 On Tue, Jun 18, 2019 at 01:39:46AM -0700, Ronald F. Guilmette wrote: > > > > firewall_script="/etc/rc.firewall" > > Actually, no, that's not how one is supposed to enable one's own set > of ipfw ules. To do that, the Handbook (Sec. 30.4.1) says very clearly > that one should do: > > firewall_enable="YES" > firewall_type="path-to-my-rules-file" Well, it works for me, and is likely sound practical advice, though for the record (don't recall why) I have both: firewall_enable="YES" firewall_script="/etc/rc.homenet" firewall_type="homenet" which yields precisely the rules I specified. I hear your frustration, but venting is unlikely to be a good way to motivate people to spend unpaid time to help. Short, neutral posts with concrete questions backed by specific details of your system, what you expected and what you got, would I think be more productive. Focus on what your negative experience is with IPv6 enabled, and someone may be able to help you get past any obstacles. Indignation about having IPv6 inflicted on you is I think a suboptimal strategy. -- Viktor. From owner-freebsd-net@freebsd.org Tue Jun 18 08:59:40 2019 Return-Path: Delivered-To: freebsd-net@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 4005515B1CC2 for ; Tue, 18 Jun 2019 08:59:40 +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 582336AB43 for ; Tue, 18 Jun 2019 08:59:39 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id EEE894E64B; Tue, 18 Jun 2019 01:59:37 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-net@freebsd.org Subject: Re: Eliminating IPv6 (?) In-Reply-To: <20190618082951.GA84864@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19733.1560848377.1@segfault.tristatelogic.com> Date: Tue, 18 Jun 2019 01:59:37 -0700 Message-ID: <19734.1560848377@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 582336AB43 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.94 / 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)[]; DMARC_NA(0.00)[tristatelogic.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.75)[ip: (-7.22), ipnet: 69.62.128.0/17(-3.61), asn: 14051(-2.84), country: US(-0.06)]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 08:59:40 -0000 In message <20190618082951.GA84864@straasha.imrryr.org>, Viktor Dukhovni wrote: >Agreed. I find it takes very little effort to not have IPv6 get >in my way, and with that taken care of, it is then occasionally >even useful. If this thread boils down to annoyance about localhost >resolving to both "::1" and "127.0.0.1" then use "127.0.0.1" instead >of "localhost" in any configuration files where that's what you >mean. I quite certainly have had, of late, and since my "upgrade" to 12.0, two specific and very annoying problems that both seemed at first to possibly derive from various applications mistakenly attempting to connect to "localhost" via its IPv6 address in preference to its IPv4 address. With a little help from my friends I've now resolved both issues, and as it turned out, neither problem had a single bloody thing to do with IPv6. So that's good news. But I didn't know that until the end. While the plot was still unfolding with respect to both of these issues, I was effectively forced to consider that all of this unwanted IPv6 stuff might be the source of these (originally rather mysterious) problems. As the old saying goes, I would rather have been sailing. Anyway, as I had previously mentioned, various suggestions and recommendations that I found online had suggest one or another subset of the following /etc/rc.conf lines as a way of eliminating IPv6 from the game board: ipv6_network_interfaces="none" ip6addrctl_enable="NO" ip6addrctl_policy="ipv4_prefer" ipv6_activate_all_interfaces="NO" Would it not be both easy and wise to have -one- thing that could be placed into /etc/rc.conf that would imply all of these others? That would require near zero engineering effort, yes? Regards, rfg From owner-freebsd-net@freebsd.org Tue Jun 18 09:29:38 2019 Return-Path: Delivered-To: freebsd-net@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 1F32E15B2F96; Tue, 18 Jun 2019 09:29:38 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "eg.sd.rdtc.ru", Issuer "eg.sd.rdtc.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D510E6BD1D; Tue, 18 Jun 2019 09:29:26 +0000 (UTC) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-net@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x5I9TA3J073466 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jun 2019 16:29:10 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Eliminating IPv6 (?) To: "Ronald F. Guilmette" References: <18748.1560843874@segfault.tristatelogic.com> Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org From: Eugene Grosbein Message-ID: Date: Tue, 18 Jun 2019 16:29:02 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <18748.1560843874@segfault.tristatelogic.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: D510E6BD1D X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.17 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.42)[-0.418,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.24)[-0.238,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_SHORT(0.08)[0.085,0]; MX_INVALID(0.50)[greylisted]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; IP_SCORE(0.00)[country: RU(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29072, ipnet:2a03:3100::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 09:29:38 -0000 18.06.2019 14:44, Ronald F. Guilmette wrote: >>> How can I turn off IPv6 entirely without rebuilding the kernel? >> You cannot. GENERIC kernel specifically enables IPv6 support and you need to >> disable it at compile time. >> And if you do, you better rebuild the world too using WITHOUT_INET6=yes in the >> /etc/src.conf >> or else some utilities compiled with INET6 by default will query kernel >> for IPv6-specific data (like routing entries) and complain that your kernel does >> not know about it. >> >> World built WITHOUT_INET6 has no such rough edges. > > OK, so I obviously expressed myself badly. Let me try again. > > IPv6 support is enabled in a the stock kernel. OK. Fine. But just because > that feature is present in the kernel, that does not imply that anything in > userland -has- to actually make any use of it at all. > > *Something* is doing ifconfig on my loopback (lo0) interface. What is that > thing and how can I get it to stop doing that? It is not userland. It is a kernel itself. IPv6 standards are very different comparing to IPv4. They mandate some level of actual usage of IPv6. Easiest (and sometimes only) way to get rid of this is to rebuilt the kernel. From owner-freebsd-net@freebsd.org Tue Jun 18 09:36:18 2019 Return-Path: Delivered-To: freebsd-net@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 236E815B3434; Tue, 18 Jun 2019 09:36:18 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) (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 6FDC76C226; Tue, 18 Jun 2019 09:36:17 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id x5I9aFlc057111; Tue, 18 Jun 2019 10:36:15 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id x5I9aFfm057110; Tue, 18 Jun 2019 10:36:15 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201906180936.x5I9aFfm057110@donotpassgo.dyslexicfish.net> Date: Tue, 18 Jun 2019 10:36:15 +0100 Organization: Dyslexic Fish To: rfg@tristatelogic.com Cc: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: Re: Eliminating IPv6 (?) References: <18748.1560843874@segfault.tristatelogic.com> In-Reply-To: <18748.1560843874@segfault.tristatelogic.com> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Tue, 18 Jun 2019 10:36:15 +0100 (BST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 09:36:18 -0000 "Ronald F. Guilmette" wrote: > As I have already learned, the /etc/rc.firewall script also assumes both the > presence of, and the desirability of IPv6 support. And unless one edits that > file manually... which I have been effectively forced to do... there is no way > to get it to simply NOT create and install multiple IPv6-related ipfw rules, I sympathise with your situation, and maybe /etc/rc.firewall could be a bit more intelligent about it, but when we had 2 seperate files, /etc/rc.firewall and /etc/rc.firewall6 it was a pain in the arse, and also made it more likely of mistakes/oversights occuring. To stop the clutter you mention, and to avoid making the file more complicated for us who do dual stack, maybe a wrapper could be made around ipfw to get it to act as a null-op if ip6 is disabled by your suggested rc.conf knob. I'd have it set rule 1 to something like "deny ip6 from any to any", and then ignore any further ip6 rules it encounters. But yes, I can see how the efforts to unify the 4/6 configurations have made things a bit more complicated for those who only use the one stack (and in the future, people may start getting similarly affected by inet4 stuff complicating their configs!) Cheers, Jamie From owner-freebsd-net@freebsd.org Tue Jun 18 12:15:18 2019 Return-Path: Delivered-To: freebsd-net@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 499E115B90E8 for ; Tue, 18 Jun 2019 12:15:18 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 B427C7174A for ; Tue, 18 Jun 2019 12:15:17 +0000 (UTC) (envelope-from roberthuff@rcn.com) DKIM-Signature: v=1; a=rsa-sha1; d=rcn.com; s=20180516; c=relaxed/simple; q=dns/txt; i=@rcn.com; t=1560858895; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=ZKok/liNMHM0a+6OGB0/BG152bE=; b=hR/7TIk/HZqVXyrIQT1juMtecoJUP0PDal7WO1/61Uq9X/VJ0a1GSViiZpGDVohK POvrSHnISIsMyY2rTn8VE6nRCzwW95pEFtzA5Fg5HmwLDLZymlBhkibxwVgsMgXc W9yOp3Y1/9PhILjmClQ76TYis91hPfGWiszsM74U6mWf2bsUhFnk+8pApTFATkwa 0YjKh3DqFHEPfxN4ewQ/8ouAdeF9blFL1V/qiz6xRBdAL7N14TIyAF+ZIOSD9rJa 1Xf/JA8EB9oIUoIzQMacwrMzhaKTNu+JssUexluO9w6CDu5Q8DCllm5eTsY1qESg c8i3HZFDXscl/eaNEm+jCQ==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=aKGykv1m c=1 sm=1 tr=0 a=9TgA2UwI6Wy+6BV4wQM/cQ==:117 a=9TgA2UwI6Wy+6BV4wQM/cQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=KGjhK52YXX0A:10 a=kj9zAlcOel0A:10 a=XRQyMpdBKAEA:10 a=dq6fvYVFJ5YA:10 a=48faUk6PgeAA:10 a=MtpRBOugqLg-rJsvyLMA:9 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Authentication-Results: smtp03.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=softfail Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.user=roberthuff; auth=pass (PLAIN) Received: from [209.6.230.48] ([209.6.230.48:43215] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=AES256-GCM-SHA384) id CD/21-13517-F01D80D5; Tue, 18 Jun 2019 07:54:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23816.53518.998090.665606@jerusalem.litteratus.org> Date: Tue, 18 Jun 2019 07:54:54 -0400 From: Robert Huff To: "Ronald F. Guilmette" Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Eliminating IPv6 (?) In-Reply-To: <19574.1560847186@segfault.tristatelogic.com> References: <9AF5DF39-9B81-4270-B25C-D089C971E924@punkt.de> <19574.1560847186@segfault.tristatelogic.com> X-Mailer: VM 8.2.0b under 26.2 (amd64-portbld-freebsd13.0) X-Rspamd-Queue-Id: B427C7174A X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rcn.com header.s=20180516 header.b=hR/7TIk/; dmarc=pass (policy=none) header.from=rcn.com; spf=pass (mx1.freebsd.org: domain of roberthuff@rcn.com designates 69.168.97.78 as permitted sender) smtp.mailfrom=roberthuff@rcn.com X-Spamd-Result: default: False [-7.83 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[rcn.com:s=20180516]; RCVD_IN_DNSWL_LOW(-0.10)[78.97.168.69.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:69.168.97.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; DWL_DNSWL_LOW(-1.00)[rcn.com.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[rcn.com:+]; DMARC_POLICY_ALLOW(-0.50)[rcn.com,none]; MX_GOOD(-0.01)[cached: mx.rcn.com]; NEURAL_HAM_SHORT(-0.98)[-0.975,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.75)[ip: (-9.25), ipnet: 69.168.97.0/24(-4.55), asn: 36271(0.13), country: US(-0.06)]; ASN(0.00)[asn:36271, ipnet:69.168.97.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 12:15:18 -0000 Ronald F. Guilmette writes: > >Instead of messing with the system provided file you could > >create a new one with only your own desired rules and then set > >this rc.conf variable: > > > > firewall_script="/etc/rc.firewall" > > Actually, no, that's not how one is supposed to enable one's own set > of ipfw ules. To do that, the Handbook (Sec. 30.4.1) says very clearly > that one should do: > > firewall_enable="YES" > firewall_type="path-to-my-rules-file" > > But I'm glad you brought it up. The funny thing is that even that > doesn't work properly nowadays *or* like it used to in the past. If this is true - haven't checked personally - then it's a bug. (And a non-trivial one, the fact you're the first to report it notwithstanding.) Can you please open a bug report? Respectfully, Robert Huff From owner-freebsd-net@freebsd.org Tue Jun 18 12:22:49 2019 Return-Path: Delivered-To: freebsd-net@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 2754915B97A7; Tue, 18 Jun 2019 12:22:49 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 E54F471D4D; Tue, 18 Jun 2019 12:22:47 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by mail-lj1-x236.google.com with SMTP id 16so12878990ljv.10; Tue, 18 Jun 2019 05:22:47 -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=A1oFqf5+72GTalmlLk1MKf0HNiPI8fHSB4INAHu7V/U=; b=ghN9daFMxuC0GoM2NtuzTw5muhyHParQ4rUsfFlVtVQZcBM8YatrhDQ7fIJUU9EU+v vir9sNXxpKZ+Aazqg+PygTyUDt2/XRvhQZwSEGRLQ8ygeWUhl7WKKbloYUF8BCDLLZC2 MjpyhdS0mnfqLDfXcD/7qryMLDib2TpPfPAm5RxuRfiU+dAMTuJhtVyg+9iQ4fAlvy04 odD/X4zmoUtFo4daogh8AcGIkMuBz2bjTdl10Wn1VFhlNUbidbisCGBD1eMbZ0a/Ue/p XvPpUPaH/kIyIrjxUo2FPXbplf7rkeYVzrri939oZrschB82/tK9gCiSHGE7gMsvdzGg YxYA== 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=A1oFqf5+72GTalmlLk1MKf0HNiPI8fHSB4INAHu7V/U=; b=owPiO2Iqi8OIETw7zmv31gAy0l8272alGk6tDVTfNKY8wO4Fl1yaMfFhwGRHLBb9jG svhizfbAQ7H/iauwoCQKzYXik1Xd2zYtzOS/6FVGO4+S3FgsicVzeCArQgjV7CoZrw3x +HWkSoEsk/duR7cE2jFoMiWLpmwkr7oRbz+f2YNJ9IBhTHE1vHRtUfqYMNlqQfdEn07J 8btJ5m3d2qhpsT9bSorOuOJFhRGIPp3CrXUb2QBdPCQUC+3c8uuLcKJYnmDosZI3/ynr jYGeWqn/UdX86mYH7AqocIlVg7qNpZvjwBDZNu3bv5VjClt8QdprGvCePRZqUJd1VPuT 4+Ug== X-Gm-Message-State: APjAAAXcMB0zzhmB6DTjCYxE3i5apOJMVIwVRrSa+HYKkc6pU106H+HF ybsmuoUwMiRtaNfLaPJzcdBb1u4wVuugsHtwQQBfwOu/JyA= X-Google-Smtp-Source: APXvYqxKlfOnJ12GNHJlyrd4hU4Xf75KICOLUX36v62PyrOuWqyWAEPYbIly1W7wtTK1rsH82hSPqQLqpoTQicvJBjg= X-Received: by 2002:a2e:5c6:: with SMTP id 189mr1806200ljf.22.1560860566121; Tue, 18 Jun 2019 05:22:46 -0700 (PDT) MIME-Version: 1.0 References: <9AF5DF39-9B81-4270-B25C-D089C971E924@punkt.de> <19574.1560847186@segfault.tristatelogic.com> <23816.53518.998090.665606@jerusalem.litteratus.org> In-Reply-To: <23816.53518.998090.665606@jerusalem.litteratus.org> From: Andreas Nilsson Date: Tue, 18 Jun 2019 14:22:32 +0200 Message-ID: Subject: Re: Eliminating IPv6 (?) To: Robert Huff Cc: "Ronald F. Guilmette" , FreeBSD Net , Mailinglists FreeBSD X-Rspamd-Queue-Id: E54F471D4D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ghN9daFM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of andrnils@gmail.com designates 2a00:1450:4864:20::236 as permitted sender) smtp.mailfrom=andrnils@gmail.com X-Spamd-Result: default: False [-6.79 / 15.00]; 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)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[6.3.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; IP_SCORE(-2.85)[ip: (-9.40), ipnet: 2a00:1450::/32(-2.49), asn: 15169(-2.32), country: US(-0.06)]; NEURAL_HAM_SHORT(-0.93)[-0.927,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 12:22:49 -0000 On Tue, Jun 18, 2019 at 2:16 PM Robert Huff wrote: > > Ronald F. Guilmette writes: > > > >Instead of messing with the system provided file you could > > >create a new one with only your own desired rules and then set > > >this rc.conf variable: > > > > > > firewall_script="/etc/rc.firewall" > > > > Actually, no, that's not how one is supposed to enable one's own set > > of ipfw ules. To do that, the Handbook (Sec. 30.4.1) says very clearly > > that one should do: > > > > firewall_enable="YES" > > firewall_type="path-to-my-rules-file" > > > > But I'm glad you brought it up. The funny thing is that even that > > doesn't work properly nowadays *or* like it used to in the past. > > If this is true - haven't checked personally - then it's a bug. > (And a non-trivial one, the fact you're the first to report it > notwithstanding.) > Can you please open a bug report? > > > Respectfully, > > > Robert Huff > The bug being that firewall_type is used to specify a type in the default /etc/rc.firewall file and firewall_script should be used to provide the path to ones own ipfw script, right? I have no ipv6 rules in ipfw when configuring rc.conf as: firewall_enable="YES" firewall_script="/etc/ipfw.rules". The man page for rc.conf states: firewall_script (str) This variable specifies the full path to the firewall script to run. The default is /etc/rc.firewall. firewall_type (str) Names the firewall type from the selection in /etc/rc.firewall, or the file which contains the local firewall ruleset. Valid selections from /etc/rc.firewall are: open unrestricted IP access closed all IP services disabled, except via "lo0" client basic protection for a workstation simple basic protection for a LAN. If a filename is specified, the full path must be given. Best regards Andreas From owner-freebsd-net@freebsd.org Tue Jun 18 12:35:05 2019 Return-Path: Delivered-To: freebsd-net@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 EC3F715BA29A; Tue, 18 Jun 2019 12:35:04 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (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 5DA017261C; Tue, 18 Jun 2019 12:35:03 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [217.29.44.10]) by gate2.intern.punkt.de with ESMTP id x5ICZ0eV038730; Tue, 18 Jun 2019 14:35:00 +0200 (CEST) Received: from [217.29.44.36] ([217.29.44.36]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id x5ICZ0hJ072373; Tue, 18 Jun 2019 14:35:00 +0200 (CEST) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Eliminating IPv6 (?) From: "Patrick M. Hausen" In-Reply-To: <23816.53518.998090.665606@jerusalem.litteratus.org> Date: Tue, 18 Jun 2019 14:35:00 +0200 Cc: "Ronald F. Guilmette" , Artem Viklenko via freebsd-net , freebsd-questions@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9AF5DF39-9B81-4270-B25C-D089C971E924@punkt.de> <19574.1560847186@segfault.tristatelogic.com> <23816.53518.998090.665606@jerusalem.litteratus.org> To: Robert Huff X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 5DA017261C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hausen@punkt.de designates 217.29.33.131 as permitted sender) smtp.mailfrom=hausen@punkt.de X-Spamd-Result: default: False [-2.84 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.967,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:217.29.32.0/20]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[punkt.de]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mailin.pluspunkthosting.de]; NEURAL_HAM_SHORT(-0.86)[-0.859,0]; RCVD_IN_DNSWL_NONE(0.00)[131.33.29.217.list.dnswl.org : 127.0.10.0]; IP_SCORE(-0.20)[ipnet: 217.29.32.0/20(-0.56), asn: 16188(-0.45), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 12:35:05 -0000 Hi all, > Am 18.06.2019 um 13:54 schrieb Robert Huff : >=20 > If this is true - haven't checked personally - then it's a bug. > (And a non-trivial one, the fact you're the first to report it > notwithstanding.) > Can you please open a bug report? I doubt it would qualify as a bug - possibly a bug in the docs, yes. Because the observed behaviour is definitely intentional. The flow of = statements in rc.firewall is: 0. flush all rules 1. setup_loopback 2. setup_ipv6_mandatory and no configuration is going to skip that - hence the only way is to = use firewall_script. Then it goes on: 3. is firewall_type one of the predefined =E2=80=9Eopen=E2=80=9C, = =E2=80=9Esimple=E2=80=9C, etc.? =E2=80=94> configure accordingly 4. if not and firewall_type points to a readable file, suck in = rules from there So, yes, there will always be mandatory IPv6 rules in place. That=E2=80=99= s why they are called mandatory, I figure ;-) Kind regards, Patrick --=20 punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe info@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling From owner-freebsd-net@freebsd.org Tue Jun 18 12:47:39 2019 Return-Path: Delivered-To: freebsd-net@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 5764815BAA3A for ; Tue, 18 Jun 2019 12:47:39 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 D27C773077 for ; Tue, 18 Jun 2019 12:47:38 +0000 (UTC) (envelope-from roberthuff@rcn.com) DKIM-Signature: v=1; a=rsa-sha1; d=rcn.com; s=20180516; c=relaxed/simple; q=dns/txt; i=@rcn.com; t=1560862057; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=FfbmjTWklmgeywkGpZt4Sh7y1/4=; b=V/AXsPWt1L+2wy+sfBHXy4MY/LL2srSb4AhGf41zzlYouDhJZh6jpn+dq8WzkOKh 5LO3aj5w2aP41u9PyAtjRJT75x8FkWvhIJSPDUskljsNaO6y8zlUe/1+ZW1Q3enm quYyghpgYLIepD0F4MkCLtEWtpo4fKE1M6l3qCC8JbVHMt2iDcb3RnbmGCkUUH7u 9VeirqaRxdEt2h2fazla7XOHjni9U0fyjNyrjDJWI3pXVD860x7gusF2yaIRqNuz 0h6QhIHLD5rwkYUhajvaSEtLppwpbUqcoZDMz2HVhDVj1nCaN3q+qBGE5+fIOz3i fAij+xYm7hwFXDHzeTaO9g==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=buYOPwSi c=1 sm=1 tr=0 a=9TgA2UwI6Wy+6BV4wQM/cQ==:117 a=9TgA2UwI6Wy+6BV4wQM/cQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=KGjhK52YXX0A:10 a=kj9zAlcOel0A:10 a=XRQyMpdBKAEA:10 a=dq6fvYVFJ5YA:10 a=48faUk6PgeAA:10 a=Otr1bSn4Gezn7tVTDtkA:9 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=roberthuff; auth=pass (PLAIN) Received: from [209.6.230.48] ([209.6.230.48:22475] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=AES256-GCM-SHA384) id 19/8C-36753-86DD80D5; Tue, 18 Jun 2019 08:47:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23816.56679.599665.973942@jerusalem.litteratus.org> Date: Tue, 18 Jun 2019 08:47:35 -0400 From: Robert Huff To: Andreas Nilsson Cc: Robert Huff , "Ronald F. Guilmette" , FreeBSD Net , Mailinglists FreeBSD Subject: Re: Eliminating IPv6 (?) In-Reply-To: References: <9AF5DF39-9B81-4270-B25C-D089C971E924@punkt.de> <19574.1560847186@segfault.tristatelogic.com> <23816.53518.998090.665606@jerusalem.litteratus.org> X-Mailer: VM 8.2.0b under 26.2 (amd64-portbld-freebsd13.0) X-Rspamd-Queue-Id: D27C773077 X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rcn.com header.s=20180516 header.b=V/AXsPWt; dmarc=pass (policy=none) header.from=rcn.com; spf=pass (mx1.freebsd.org: domain of roberthuff@rcn.com designates 69.168.97.78 as permitted sender) smtp.mailfrom=roberthuff@rcn.com X-Spamd-Result: default: False [-7.86 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[rcn.com:s=20180516]; RCVD_IN_DNSWL_LOW(-0.10)[78.97.168.69.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:69.168.97.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; DWL_DNSWL_LOW(-1.00)[rcn.com.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[rcn.com:+]; DMARC_POLICY_ALLOW(-0.50)[rcn.com,none]; MX_GOOD(-0.01)[cached: mx.rcn.com]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.76)[ip: (-9.27), ipnet: 69.168.97.0/24(-4.57), asn: 36271(0.11), country: US(-0.06)]; ASN(0.00)[asn:36271, ipnet:69.168.97.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 12:47:39 -0000 Andreas Nilsson writes: > > If this is true - haven't checked personally - then it's a bug. > > (And a non-trivial one, the fact you're the first to report it > > notwithstanding.) > > Can you please open a bug report? > > The bug being that firewall_type is used to specify a type in the default > /etc/rc.firewall file and firewall_script should be used to provide the > path to ones own ipfw script, right? The bug would be "documentation does not correctly describe behavior". :-) Respectfully, Robert Huff From owner-freebsd-net@freebsd.org Tue Jun 18 15:26:13 2019 Return-Path: Delivered-To: freebsd-net@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 CF30415C0C73; Tue, 18 Jun 2019 15:26:13 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 5FEEE8266B; Tue, 18 Jun 2019 15:26:12 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lf1-x141.google.com with SMTP id 136so9608787lfa.8; Tue, 18 Jun 2019 08:26:12 -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=l1ZRoA1PmSY/fX0T+5mHaAnQKS2D8/1f86pu/Ry1JOM=; b=QrheR4QH/X6NCgFkaxYj18JXeve+xzj+KMgrL+Pv87Yoe750N4ktRSDKAeoKwjD/l/ HDkmrwVgnWvSj6ydgsN2tYjEm9/3hil52yjkaljjZSxhnPR36wEgbPBSQaexWmnvcWjk 9kjHX4b18Xm6MPl2YG7Q8vej5ul4INeF22BMYS2MPdy0CHnCLPtRAefmcNb1F4k2TM+x ZYYHExKIzFrj6kPs9bKVPubZ6Ogw3J/mPJpX8OoVCVJ/B8CMLHpZspmzSizR+YDiyrl1 HdhdkETsbxpeZlyUyNj3BmVG+QwdVMXrMFNS9dApv5RU9vyv8/16fD5ULiTKapPHwEaV pkYw== 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=l1ZRoA1PmSY/fX0T+5mHaAnQKS2D8/1f86pu/Ry1JOM=; b=HBtwr75lxaph59S/xpXP+JSpymZ9Zxa/iZEafD31snH1evhLDhdCjvFZB2FnJx8GRc +KoPZyrB6c/rUsNsRTgSHW7w2+gmZyZLmObMC7C8zvRD7yFMey+9LYj1a59jCJfH+qv2 sZG3oE83Qc630MwNmmaUj0GqwrySYFaoCoEXjAomf3do7NBeUy7Iu/nvIH2ZZmsAv3Mq Cz32YaJknwa+qhf13lvZNBHV9ZuTTpMzaoOkI5d8UUItPdeOO1Niw0++cWGtHuI1uQwt pK9iYpLlxjBQNixxipMEInUXS58NRQu+vytToUvXWiQYNOYsSfd0iA66v/7p3w06WlPv r0Rw== X-Gm-Message-State: APjAAAUglbvNO6REDEfC9JfIMF8vyfdu6bFO7Nelhs7Feep4azBkF4hD rUg2a9ZkuawV7cNJPmZqQHssUhRL/oDEc+gymEuaww== X-Google-Smtp-Source: APXvYqw3bClyuRpcA4zlFYuUb+EG78yIgXvr+eSntwvLgM/LEXtbZAF2KGMNPm6zknxqTgbW7nCG8Rl8kJ/zUecLheA= X-Received: by 2002:ac2:5b05:: with SMTP id v5mr60012883lfn.38.1560871570167; Tue, 18 Jun 2019 08:26:10 -0700 (PDT) MIME-Version: 1.0 References: <18748.1560843874@segfault.tristatelogic.com> In-Reply-To: <18748.1560843874@segfault.tristatelogic.com> From: Freddie Cash Date: Tue, 18 Jun 2019 08:25:58 -0700 Message-ID: Subject: Re: Eliminating IPv6 (?) To: "Ronald F. Guilmette" Cc: freebsd-net , FreeBSD Questions Mailing List X-Rspamd-Queue-Id: 5FEEE8266B X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=QrheR4QH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of fjwcash@gmail.com designates 2a00:1450:4864:20::141 as permitted sender) smtp.mailfrom=fjwcash@gmail.com X-Spamd-Result: default: False [-4.34 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[1.4.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; IP_SCORE(-0.50)[ip: (2.38), ipnet: 2a00:1450::/32(-2.50), asn: 15169(-2.32), country: US(-0.06)]; NEURAL_HAM_SHORT(-0.84)[-0.836,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 15:26:14 -0000 On Tue, Jun 18, 2019 at 12:45 AM Ronald F. Guilmette wrote: > In message , > Eugene Grosbein wrote: > > >18.06.2019 10:10, Ronald F. Guilmette wrote: > > > >> How can I turn off IPv6 entirely without rebuilding the kernel? > > > >You cannot. GENERIC kernel specifically enables IPv6 support and you need > to > >disable it at compile time. > >And if you do, you better rebuild the world too using WITHOUT_INET6=yes > in the > >/etc/src.conf > >or else some utilities compiled with INET6 by default will query kernel > >for IPv6-specific data (like routing entries) and complain that your > kernel does > >not know about it. > > > >World built WITHOUT_INET6 has no such rough edges. > > OK, so I obviously expressed myself badly. Let me try again. > For someone who doesn't want to be preached to about the benefits of IPv6, you certainly do a lot of preaching about not wanting IPv6. :) You've been given the tools to do exactly what you want: - comment out IPv6 support in the kernel config file - add WITHOUT_IPV6=yes to /etc/src.conf - rebuild the world and kernel Voila! A version of FreeBSD made especially for you, without any traces of IPv6. Does exactly what you want. Why the long diatribe asking for something else once you've been shown how to do what you want? -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@freebsd.org Tue Jun 18 17:19:27 2019 Return-Path: Delivered-To: freebsd-net@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 C231A15C36E8 for ; Tue, 18 Jun 2019 17:19:27 +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 EB74486332 for ; Tue, 18 Jun 2019 17:19:16 +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 x5IHJ8A4014688; Tue, 18 Jun 2019 10:19:08 -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 x5IHJ8g0014687; Tue, 18 Jun 2019 10:19:08 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906181719.x5IHJ8g0014687@gndrsh.dnsmgr.net> Subject: Re: localhost woes -- help requested In-Reply-To: <4468.1560802522@segfault.tristatelogic.com> To: "Ronald F. Guilmette" Date: Tue, 18 Jun 2019 10:19:08 -0700 (PDT) CC: freebsd-net 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: EB74486332 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.52 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.54)[0.541,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.63)[0.628,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[gndrsh.dnsmgr.net,gndrsh.dnsmgr.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.42)[0.423,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.15), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 17:19:28 -0000 > In message , > Adam wrote: > > >On Sat, Jun 15, 2019 at 12:54 AM Ronald F. Guilmette > >wrote: > >> ... except for the browsers, and also one other thing (nmh outbound > >> email handling). Now, both Firefox and Opera crash and burn, right > >> out of the gate, when started from the command line. In both cases > >> thet do so both with entirely cryptic failure messages. > >> > >> But here's the kicker... I futzed around with this awhile and found > >> out that if I just change the default value of the DISPLAY environment > >> variable from "localhost:0.0" to ":0.0" then both browsers *do* then > >> start up successfully from the command line. > >> > >> So, um, what the bleep did I do wrong? > >> > >> Here's the output of the command "getent hosts localhost": > >> > >> ::1 localhost > >> 127.0.0.1 localhost localhost.tristatelogic.com > >> > >> > >> Any hints for how I can debug this mess would be appreciated. > >> > > > >Do you have local_unbound running? It's probably caching the result. > > > >/etc/rc.d/local_unbound stop > > > >Then try your changes to /etc/hosts > > I have now rebooted the system multiple times, from a cold start, and > this has had *no* effect on the output generated by "getent hosts localhost". > > That is *still* showing me that there exists a mapping from "localhost" > to an IPv6 address, even though I commented that out in my /etc/hosts > file. > > I really would like to understand why manual edits to /etc/hosts seem > to have no effect whatosoever. And more importantly, I'd really still > like to know whey X applications cannot seem to connect to the X server > when and if DISPLAY is set to localhost:0.0 while they have no problem > doing so when DISPLAY is instead set to :0.0 What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Tue Jun 18 18:59:47 2019 Return-Path: Delivered-To: freebsd-net@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 7510E15C58A0; Tue, 18 Jun 2019 18:59:47 +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 8631489CD9; Tue, 18 Jun 2019 18:59:46 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 1DE1B4E668; Tue, 18 Jun 2019 11:59:45 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Eliminating IPv6 (?) In-Reply-To: <23816.53518.998090.665606@jerusalem.litteratus.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23510.1560884384.1@segfault.tristatelogic.com> Date: Tue, 18 Jun 2019 11:59:45 -0700 Message-ID: <23511.1560884385@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 8631489CD9 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.90 / 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)[]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.77)[ip: (-7.28), ipnet: 69.62.128.0/17(-3.64), asn: 14051(-2.87), country: US(-0.06)]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.93)[-0.927,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 18:59:47 -0000 In message <23816.53518.998090.665606@jerusalem.litteratus.org>, Robert Huff wrote: >> Actually, no, that's not how one is supposed to enable one's own set >> of ipfw ules. To do that, the Handbook (Sec. 30.4.1) says very clearly >> that one should do: >> >> firewall_enable="YES" >> firewall_type="path-to-my-rules-file" >> >> But I'm glad you brought it up. The funny thing is that even that >> doesn't work properly nowadays *or* like it used to in the past. > > If this is true - haven't checked personally - then it's a bug. >(And a non-trivial one, the fact you're the first to report it >notwithstanding.) > Can you please open a bug report? I aim to please. As requested: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238694 Regards, rfg From owner-freebsd-net@freebsd.org Tue Jun 18 19:26:02 2019 Return-Path: Delivered-To: freebsd-net@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 C789E15C65EB; Tue, 18 Jun 2019 19:26:02 +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 038FB8AD77; Tue, 18 Jun 2019 19:26:01 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id A307E4E669; Tue, 18 Jun 2019 12:26:00 -0700 (PDT) From: "Ronald F. Guilmette" cc: FreeBSD Net , Mailinglists FreeBSD Subject: Re: Eliminating IPv6 (?) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23657.1560885960.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jun 2019 12:26:00 -0700 Message-ID: <23658.1560885960@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 038FB8AD77 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 [-3.03 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.987,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; IP_SCORE(-2.73)[ip: (-7.17), ipnet: 69.62.128.0/17(-3.59), asn: 14051(-2.83), country: US(-0.06)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; RCPT_COUNT_TWO(0.00)[2]; MISSING_TO(2.00)[]; NEURAL_HAM_SHORT(-0.11)[-0.113,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 19:26:03 -0000 In message Andreas Nilsson wrote: >I have no ipv6 rules in ipfw when configuring rc.conf as: > >firewall_enable=3D"YES" >firewall_script=3D"/etc/ipfw.rules". I don't know what to say, other than that this was not my experience. When I first noiced that /etc/rc.firewall was injecting rules into ipfw, prior to my own set of explicitly specified rules, I went into the script and edited it to try to cause it to stop doing at least some of this (unwanted) behavior. For example, please note the lines in the following function which have been commented out: setup_loopback() { ############ # Only in rare cases do you want to change these rules # ${fwcmd} add 100 pass all from any to any via lo0 # ${fwcmd} add 200 deny all from any to 127.0.0.0/8 # ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any # if [ $ipv6_available -eq 0 ]; then # ${fwcmd} add 400 deny all from any to ::1 # ${fwcmd} add 500 deny all from ::1 to any # fi } Commenting out the lines shown above (as commented out) *did* make a difference. To be crystal clear, I found that even when I was explicitly requesting that my own custom rule set be used, as per the instructions in the Handbook (and as I have been doing already for lo these many years) I found that "ipfw -a list" was showing that I was getting several additional rules (which I personally DID NOT specify in my rules file) and these additional rules were appearing in the output of "ipfw -a list" = AHEAD OF my own explicitly specified rules. I traced this down and quickly saw that these additional rules could only have come from the (now commented out) lines shown above. After I had commented those lines out of the /etc/rc.firewall script an rebooted the system, the rules in question no longer were visible in the output of "ipfw -a list". I also made one other local change to the /etc/rc.firewall script, which i= s illustrated by the following (locally revised) code snippet: afexists inet6 #ipv6_available=3D$? # disable creation of any/all IPv6 rules ipv6_available=3D1 I can't remember anymore now if this had the desired effect or not. It certainly didn't seem to hurt anything, at least from my personal perspective. (But please remember, I am striving to -not- use IPv6 at all.) Even with these multiple changes, the /etc/rc.firewall script is *still* injecting its own "pass all from any to any via lo0" rule ahead of my own explicitly specified rules. (See the setup_loopback() function above.= ) I do not have any objection to that perfectly sensible rule, so I did not comment out the specific line of /etc/rc.firewall where that is added, ahe= ad of all user-specified rules. But the point remains that /etc/rc.firewall *is* injecting its own rules, even when the user has followed the Handbook= 's prescription for how to take complete control of his/her own IPFW rule writing. Regards, rfg From owner-freebsd-net@freebsd.org Tue Jun 18 19:32:54 2019 Return-Path: Delivered-To: freebsd-net@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 C99E015C6A5D; Tue, 18 Jun 2019 19:32:53 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 7E9C38B316; Tue, 18 Jun 2019 19:32:52 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by mail-lj1-x242.google.com with SMTP id h10so774795ljg.0; Tue, 18 Jun 2019 12:32:52 -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=M0sFPlfv4Z/VGkh7qnp/sGyFrAW8U9le6yEm2UTAdvg=; b=PlvrXfqmghn2I7sgCSrr35t5E1na7U02Z8nSiHxZ7vavFOOjZJWr3Tg3vkInHb12fY Cv4OPkA9KukTrOSkLADvgU4a2mkBavHpYX/1a/tFdkPW7chyTGKsltlzYeuHaPBjR/LY cxaZh5uu1dAinV4BvtpRCvrGnolnS+3KZYed9nUcW6aR51vXE6WbYiUGZI8SUtuR7+ok 2jNdQqn+nYnqx8mJJW1zU4F3Wn8lI6os461yZQAAtpomdNu+b7RyIML0py+HYNi4Qs6h Xyn3bPyRn4ePYkRl17qU7PyNkG8S0ljR7vFVafcgK3CWeSKGc6ENn7n3t2KQiwbxG7du L/Yw== 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=M0sFPlfv4Z/VGkh7qnp/sGyFrAW8U9le6yEm2UTAdvg=; b=WWlZwkUZM86VoOIOVWk2G0sJb4cxaA9IiWXVj2x4YW50s8ckaTLgQq0GbqHp+SaQmt RtPFq38k3cBIy6nJCHtMKCsHH6kodAJ8Z4cCzpicaPrESBH36FZZkD/6XFL+ePLPL3GN 0k5VnHa15e7ztKrROIbfFs6Yx0F+/0tW1aSFboiLDrPMsIf9cs7ekpTJbWE7h3m0nfP4 ELepgdb2IwEigZ7WZGJJNYkYHojIrwHiVR4TV0OpOBzfg4RBhrhLWsUZvsBan4gwoWTS UXM6EhtEpmZCCKvAyG+ET8m3uXieRiur8r8F9FoeTA2JjQI2yfVNhvBVTHVxNZQVLXi1 CbxQ== X-Gm-Message-State: APjAAAUvchaCzKc+uX2MuTsw+o3KBMNuIsUpR0CSJZIo2YhOFa80bH/Z ptkXTChDcgKDk9ollQDdnpjoqdvfyRWv9RUzV1k= X-Google-Smtp-Source: APXvYqwZGuVoA9jBwOwTDM2yQoGKJsCahU9VemUp1UAzlTPV8u5GE+bLKfWFdMl3NVTTMBcj5Vf6xO0hVEV8zcYLI5c= X-Received: by 2002:a2e:124b:: with SMTP id t72mr55885055lje.143.1560886371001; Tue, 18 Jun 2019 12:32:51 -0700 (PDT) MIME-Version: 1.0 References: <23658.1560885960@segfault.tristatelogic.com> In-Reply-To: <23658.1560885960@segfault.tristatelogic.com> From: Andreas Nilsson Date: Tue, 18 Jun 2019 21:32:39 +0200 Message-ID: Subject: Re: Eliminating IPv6 (?) To: "Ronald F. Guilmette" Cc: FreeBSD Net , Mailinglists FreeBSD X-Rspamd-Queue-Id: 7E9C38B316 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=PlvrXfqm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of andrnils@gmail.com designates 2a00:1450:4864:20::242 as permitted sender) smtp.mailfrom=andrnils@gmail.com X-Spamd-Result: default: False [-3.14 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.75)[-0.747,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; SUBJECT_HAS_QUESTION(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE(-0.39)[ip: (2.93), ipnet: 2a00:1450::/32(-2.49), asn: 15169(-2.32), country: US(-0.06)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; HTTP_TO_IP(1.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 19:32:54 -0000 On Tue, Jun 18, 2019 at 9:27 PM Ronald F. Guilmette wrote: > In message P6ukXfA4ZThTRZWNXtpZi3BA@mail.gmail.com> > Andreas Nilsson wrote: > > >I have no ipv6 rules in ipfw when configuring rc.conf as: > > > >firewall_enable="YES" > >firewall_script="/etc/ipfw.rules". > > I don't know what to say, other than that this was not my experience. > > When I first noiced that /etc/rc.firewall was injecting rules into ipfw, > prior to my own set of explicitly specified rules, I went into the > script and edited it to try to cause it to stop doing at least some > of this (unwanted) behavior. For example, please note the lines in > the following function which have been commented out: > > setup_loopback() { > ############ > # Only in rare cases do you want to change these rules > # > ${fwcmd} add 100 pass all from any to any via lo0 > # ${fwcmd} add 200 deny all from any to 127.0.0.0/8 > # ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any > # if [ $ipv6_available -eq 0 ]; then > # ${fwcmd} add 400 deny all from any to ::1 > # ${fwcmd} add 500 deny all from ::1 to any > # fi > } > > Commenting out the lines shown above (as commented out) *did* make a > difference. > > To be crystal clear, I found that even when I was explicitly requesting > that my own custom rule set be used, as per the instructions in the > Handbook (and as I have been doing already for lo these many years) > I found that "ipfw -a list" was showing that I was getting several > additional rules (which I personally DID NOT specify in my rules file) > and these additional rules were appearing in the output of "ipfw -a list" > AHEAD OF my own explicitly specified rules. I traced this down and > quickly saw that these additional rules could only have come from the > (now commented out) lines shown above. After I had commented those > lines out of the /etc/rc.firewall script an rebooted the system, the > rules in question no longer were visible in the output of "ipfw -a list". > > I also made one other local change to the /etc/rc.firewall script, which is > illustrated by the following (locally revised) code snippet: > But why are you even running rc.firewall if it does not do what you want? Just set firewall_script="/path/to/script" and your good to go, no ipv6 anywhere to be found. > > afexists inet6 > #ipv6_available=$? > # disable creation of any/all IPv6 rules > ipv6_available=1 > > I can't remember anymore now if this had the desired effect or not. It > certainly didn't seem to hurt anything, at least from my personal > perspective. (But please remember, I am striving to -not- use IPv6 > at all.) > > Even with these multiple changes, the /etc/rc.firewall script is *still* > injecting its own "pass all from any to any via lo0" rule ahead of my > own explicitly specified rules. (See the setup_loopback() function above.) > > I do not have any objection to that perfectly sensible rule, so I did not > comment out the specific line of /etc/rc.firewall where that is added, > ahead > of all user-specified rules. But the point remains that /etc/rc.firewall > *is* injecting its own rules, even when the user has followed the > Handbook's > prescription for how to take complete control of his/her own IPFW rule > writing. > > > Regards, > rfg > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Tue Jun 18 20:57:40 2019 Return-Path: Delivered-To: freebsd-net@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 0176F15C8281; Tue, 18 Jun 2019 20:57:40 +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 A374B8D7C4; Tue, 18 Jun 2019 20:57:38 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id AEC134E668; Tue, 18 Jun 2019 13:57:31 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-net , FreeBSD Questions Mailing List Subject: Re: Eliminating IPv6 (?) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24169.1560891451.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jun 2019 13:57:31 -0700 Message-ID: <24170.1560891451@segfault.tristatelogic.com> X-Rspamd-Queue-Id: A374B8D7C4 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.94 / 15.00]; R_SPF_ALLOW(-0.20)[+mx]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mx1.tristatelogic.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.96)[-0.962,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; IP_SCORE(-2.77)[ip: (-7.28), ipnet: 69.62.128.0/17(-3.64), asn: 14051(-2.87), country: US(-0.06)]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 20:57:40 -0000 In message Freddie Cash wrote: >For someone who doesn't want to be preached to about the benefits of IPv6= , >you certainly do a lot of preaching about not wanting IPv6. :) Guilty as charged. >You've been given the tools to do exactly what you want: > - comment out IPv6 support in the kernel config file > - add WITHOUT_IPV6=3Dyes to /etc/src.conf > - rebuild the world and kernel > >Voila! A version of FreeBSD made especially for you, without any traces = of >IPv6. Does exactly what you want. Why the long diatribe asking for >something else once you've been shown how to do what you want? Rebuild kernel+world is not exactly a quick solution. And god only knows how much will break once I've done that. How many othe= r people have tested -all- of the resulting binaries, seriously, on actual production systems? (I may be the first one ever, at least for 12.0.) But this is all besides the point anyway. I am now resigned to my fate, and I am already up to the fifth stage of grief with respect to this issue= . https://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model Regards, rfg From owner-freebsd-net@freebsd.org Tue Jun 18 21:13:08 2019 Return-Path: Delivered-To: freebsd-net@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 D1E2C15C8CCB for ; Tue, 18 Jun 2019 21:13:08 +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 0AF3E8E4C6 for ; Tue, 18 Jun 2019 21:13:07 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id BD63C4E668; Tue, 18 Jun 2019 14:13:06 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-net Subject: Re: localhost woes -- help requested In-Reply-To: <201906181719.x5IHJ8g0014687@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24270.1560892386.1@segfault.tristatelogic.com> Date: Tue, 18 Jun 2019 14:13:06 -0700 Message-ID: <24271.1560892386@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 0AF3E8E4C6 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.98 / 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]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.79)[ip: (-7.33), ipnet: 69.62.128.0/17(-3.66), asn: 14051(-2.89), country: US(-0.06)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 21:13:09 -0000 In message <201906181719.x5IHJ8g0014687@gndrsh.dnsmgr.net>, "Rodney W. Grimes" wrote: >What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running? 1) https://pastebin.com/raw/wXTTgd9R 2) https://pastebin.com/raw/PiGpN0LU 3) Yes, local-unbound From owner-freebsd-net@freebsd.org Tue Jun 18 21:27:53 2019 Return-Path: Delivered-To: freebsd-net@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 7575815C908F; Tue, 18 Jun 2019 21:27:53 +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 933638E9D3; Tue, 18 Jun 2019 21:27:52 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 89C064E668; Tue, 18 Jun 2019 14:27:51 -0700 (PDT) From: "Ronald F. Guilmette" cc: FreeBSD Net , Mailinglists FreeBSD Subject: Re: Eliminating IPv6 (?) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24392.1560893271.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jun 2019 14:27:51 -0700 Message-ID: <24393.1560893271@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 933638E9D3 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 [-3.86 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; IP_SCORE(-2.75)[ip: (-7.23), ipnet: 69.62.128.0/17(-3.62), asn: 14051(-2.86), country: US(-0.06)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; RCPT_COUNT_TWO(0.00)[2]; MISSING_TO(2.00)[]; NEURAL_HAM_SHORT(-0.91)[-0.909,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 21:27:53 -0000 In message Andreas Nilsson wrote: >But why are you even running rc.firewall if it does not do what you want? You are asking me the very question that *I* have been asking myself since my "upgrade" to 12.0. Why is /etc/rc.firewall even being executed? I never explicitly asked for that, but that seems to just be a by-product of how things are arranged these days.... a by-product that I have no direct control over. >Just set firewall_script=3D"/path/to/script" and your good to go, no ipv6 >anywhere to be found. That is *not* what the Handbook says. Please read it. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipf= w.html The way that I am reading section 30.4.1 is that it is telling the user to put BOTH of these things into /etc/rc.conf: firewall_enable=3D"YES" firewall_type=3D"path-to-my-rules-file" And indeed, that is -exactly- what I have done on my prior FreeBSD systems= ... enable *and* configure. One or the other of those /etc/rc.conf lines nowadays apparently triggers /etc/rc.firewall to run. I never explicitly asked for that to run, but it did anyway. I am just going with the flow. Regards, rfg From owner-freebsd-net@freebsd.org Tue Jun 18 22:32:53 2019 Return-Path: Delivered-To: freebsd-net@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 930FC15CAC32 for ; Tue, 18 Jun 2019 22:32:53 +0000 (UTC) (envelope-from prvs=30724067e7=vkulkarni@marvell.com) 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 DF5F56A3B0 for ; Tue, 18 Jun 2019 22:32:52 +0000 (UTC) (envelope-from prvs=30724067e7=vkulkarni@marvell.com) Received: by mailman.ysv.freebsd.org (Postfix) id A2BF615CAC2F; Tue, 18 Jun 2019 22:32:52 +0000 (UTC) Delivered-To: net@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 6F69015CAC2D for ; Tue, 18 Jun 2019 22:32:52 +0000 (UTC) (envelope-from prvs=30724067e7=vkulkarni@marvell.com) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 DD8096A3AC for ; Tue, 18 Jun 2019 22:32:50 +0000 (UTC) (envelope-from prvs=30724067e7=vkulkarni@marvell.com) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5IMOXsV031450 for ; Tue, 18 Jun 2019 15:32:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : subject : date : message-id : content-type : mime-version; s=pfpt0818; bh=uWa9ajyh0HOb479PppGweI84fyZO1oqMBPT92NamyFA=; b=fNPQc2Y1yriZRTvov1rLh2X+T00lWSA5s61x59f63gdYE64qqyoOHGDPs1s6dr0BNfh+ 89lBNbPJ2EXljn0ZSujddJ/kGdHXylgFVQ/g9MPwSzWrL4/4ER5i+25/aogy5yXTSiQV 6Zf2HhjAgyQlkjrV6gB/ixWNz/C+U2WCVImvShbGJjLN+GLQ9WBH610YHSE42PJdNRR5 zn2V/ZnetVL3NksraarEy+Bt9Oim9F2uwnKSs7u7W7Wpg9IdGaJykgP6+aQSNIMsmNfZ s+rwakkE1WHYVCGjuKw8P90KjdrYHmD9rF1C65/gL8MdX4aLvC4EwsKR5P4quag+m4WS qA== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0a-0016f401.pphosted.com with ESMTP id 2t780u86t7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 18 Jun 2019 15:32:48 -0700 Received: from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 18 Jun 2019 15:32:48 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.59) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 18 Jun 2019 15:32:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uWa9ajyh0HOb479PppGweI84fyZO1oqMBPT92NamyFA=; b=Y+N7Z8B+kSAWm0ttLsu6iaMA3fVthb+I6Vh3bxrKajXqKaT9Qc0EbQh5RBVRJ+7INVBH4/v91Q9xrdYpHQ6+c0B7faDh+HTCCrhPE+ae/cOI4w7yS34x5BeOu3zvBttv90g5fIqYyZHZbEOMfo4zAz3sr9LK8Rp4qi7dzydZiQk= Received: from BYAPR18MB2952.namprd18.prod.outlook.com (20.179.59.156) by BYAPR18MB2935.namprd18.prod.outlook.com (20.179.59.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Tue, 18 Jun 2019 22:32:46 +0000 Received: from BYAPR18MB2952.namprd18.prod.outlook.com ([fe80::407e:4915:f4b8:8236]) by BYAPR18MB2952.namprd18.prod.outlook.com ([fe80::407e:4915:f4b8:8236%7]) with mapi id 15.20.1987.014; Tue, 18 Jun 2019 22:32:46 +0000 From: Vaishali Kulkarni To: "net@FreeBSD.org" Subject: bxe module patch Thread-Topic: bxe module patch Thread-Index: AdUmJIADo8nx17SESDO4p08miEqwVw== Date: Tue, 18 Jun 2019 22:32:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [199.233.58.37] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fffac323-0ff9-4d09-1d7a-08d6f43ce343 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:BYAPR18MB2935; x-ms-traffictypediagnostic: BYAPR18MB2935: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 007271867D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(366004)(376002)(346002)(189003)(199004)(790700001)(6306002)(9686003)(76116006)(478600001)(53936002)(476003)(558084003)(5640700003)(7736002)(74316002)(55016002)(2906002)(14454004)(54896002)(8676002)(81156014)(1730700003)(8936002)(86362001)(486006)(81166006)(6436002)(9326002)(3480700005)(71190400001)(33656002)(66616009)(2351001)(5660300002)(6916009)(26005)(2501003)(102836004)(52536014)(6506007)(66556008)(7116003)(66476007)(66946007)(66446008)(68736007)(64756008)(316002)(66066001)(73956011)(3846002)(99936001)(186003)(25786009)(14444005)(5024004)(6116002)(71200400001)(99286004)(256004)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2935; H:BYAPR18MB2952.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 14/G69x207tLgJXBz2iDxP0Gi7NjOEaZzN8G0dKdDnO9fw/M5+XwazGadNJYhsTFFt3gdF/ZPAbxiRrfXLB/chElZRrWamFMpvUXlb5HBY9UmrsMLSVGc7S4hfzKVuvuavfr0JyM8hgkV0O33NEpivxeddWyOjdvIFr2UpqbbkpO4StOdXqGjDgqLv0fuzEUc4xS1b3KaIql5N9rilCEZnopcT3Lex0pxcgJJHzoR3oNEkRdOj+pkez0nn74zvVqz8SLz2se5YBG2KCfpT5EbKoG6XMGTSqzlMueB6ylF/5dVxmIiiQwnGS97yVrZJ2hiWgGgizclfg7bgILY3ZiqefcsNyIN8hnJJaUv9fVcq6aXtl7jIy/AHM/CU4wscPrvkzHYfTpoHpfHuwILOAuW11bZnxDA84sezxkn2ymm6c= Content-Type: multipart/mixed; boundary="_004_BYAPR18MB29525851D26920401F0A9932A3EA0BYAPR18MB2952namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fffac323-0ff9-4d09-1d7a-08d6f43ce343 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2019 22:32:46.5776 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vkulkarni@marvell.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2935 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-18_11:, , signatures=0 X-Rspamd-Queue-Id: DD8096A3AC X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=marvell.com header.s=pfpt0818 header.b=fNPQc2Y1; dkim=pass header.d=marvell.onmicrosoft.com header.s=selector2-marvell-onmicrosoft-com header.b=Y+N7Z8B+; dmarc=pass (policy=none) header.from=marvell.com; spf=pass (mx1.freebsd.org: domain of prvs=30724067e7=vkulkarni@marvell.com designates 67.231.148.174 as permitted sender) smtp.mailfrom=prvs=30724067e7=vkulkarni@marvell.com X-Spamd-Result: default: False [-5.27 / 15.00]; HAS_XOIP(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:67.231.148.174]; ENVFROM_PRVS(0.00)[]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[marvell.com:+,marvell.onmicrosoft.com:+]; CTYPE_MIXED_BOGUS(1.00)[]; MIME_BASE64_TEXT(0.10)[]; MX_GOOD(-0.01)[mxb-0016f401.gslb.pphosted.com,mxa-0016f401.gslb.pphosted.com]; DMARC_POLICY_ALLOW(-0.50)[marvell.com,none]; FORGED_SENDER(0.00)[vkulkarni@marvell.com,prvs=30724067e7=vkulkarni@marvell.com]; RCVD_IN_DNSWL_LOW(-0.10)[174.148.231.67.list.dnswl.org : 127.0.3.1]; MIME_TRACE(0.00)[0:+,1:+,2:+,4:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:26211, ipnet:67.231.148.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[vkulkarni@marvell.com,prvs=30724067e7=vkulkarni@marvell.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[marvell.com:s=pfpt0818,marvell.onmicrosoft.com:s=selector2-marvell-onmicrosoft-com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[net@freebsd.org]; FORGED_SENDER_VERP_SRS(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_SHORT(-0.98)[-0.975,0]; IP_SCORE(-2.28)[ip: (-8.80), ipnet: 67.231.148.0/24(-2.46), asn: 26211(-0.09), country: US(-0.06)]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_COUNT_SEVEN(0.00)[7] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 22:32:53 -0000 --_004_BYAPR18MB29525851D26920401F0A9932A3EA0BYAPR18MB2952namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Can you please submit the bxe patch attached? Patch was created using bxe s= ources from upstream head branch. Fix for warning " lock order reversal: (sleepable after non-sleepable) se= en with bxe driver module. Name: Vaishali Kulkarni, email vkulkarni@marvell.com Thanks, Vaishali --_004_BYAPR18MB29525851D26920401F0A9932A3EA0BYAPR18MB2952namp_ Content-Type: text/plain; name="patch_bxe_lock_error.txt" Content-Description: patch_bxe_lock_error.txt Content-Disposition: attachment; filename="patch_bxe_lock_error.txt"; size=3890; creation-date="Tue, 18 Jun 2019 22:18:14 GMT"; modification-date="Tue, 18 Jun 2019 22:10:44 GMT" Content-Transfer-Encoding: base64 T25seSBpbiBsYXRlc3RieGVfaGVhZDI6IC5zdm4KZGlmZiAtdWFwIGxhdGVzdGJ4ZV9oZWFkMi9i eGUuYyBsYXRlc3RfYnhlX2hlYWRfcGF0Y2gvYnhlLmMKLS0tIGxhdGVzdGJ4ZV9oZWFkMi9ieGUu YwkyMDE5LTA2LTEyIDE1OjI1OjQ5LjI4Nzc2MDAwMCAtMDcwMAorKysgbGF0ZXN0X2J4ZV9oZWFk X3BhdGNoL2J4ZS5jCTIwMTktMDYtMTggMTU6MTA6MTQuNDUzMzA0MDAwIC0wNzAwCkBAIC03MDQs NiArNzA0LDggQEAgc3RhdGljIHZvaWQgICAgYnhlX2ZyZWVfZndfc3RhdHNfbWVtKHN0cgogc3Rh dGljIGludCAgICAgYnhlX2ludGVycnVwdF9hdHRhY2goc3RydWN0IGJ4ZV9zb2Z0YyAqc2MpOwog c3RhdGljIHZvaWQgICAgYnhlX2ludGVycnVwdF9kZXRhY2goc3RydWN0IGJ4ZV9zb2Z0YyAqc2Mp Owogc3RhdGljIHZvaWQgICAgYnhlX3NldF9yeF9tb2RlKHN0cnVjdCBieGVfc29mdGMgKnNjKTsK K3N0YXRpYyB2b2lkIGJ4ZV9zZXRfcnhfbW9kZV9zY2goc3RydWN0IGJ4ZV9zb2Z0YyAqc2MpOwor c3RhdGljIHZvaWQgYnhlX3NldF9yeF9tb2RlX3Rhc2sodm9pZCAqYXJnLCBpbnQgcGVuZGluZyk7 CiBzdGF0aWMgaW50ICAgICBieGVfaW5pdF9sb2NrZWQoc3RydWN0IGJ4ZV9zb2Z0YyAqc2MpOwog c3RhdGljIGludCAgICAgYnhlX3N0b3BfbG9ja2VkKHN0cnVjdCBieGVfc29mdGMgKnNjKTsKIHN0 YXRpYyB2b2lkICAgIGJ4ZV9zcF9lcnJfdGltZW91dF90YXNrKHZvaWQgKmFyZywgaW50IHBlbmRp bmcpOwpAQCAtNDUwNyw2ICs0NTA5LDIyIEBAIGJ4ZV9oYW5kbGVfY2hpcF90cSh2b2lkICpjb250 ZXh0LAogICAgICAgICBicmVhazsKICAgICB9CiB9CitzdGF0aWMgdm9pZAorYnhlX3NldF9yeF9t b2RlX3Rhc2sodm9pZCAqY29udGV4dCwgaW50IHBlbmRpbmcpCit7CisgICAgc3RydWN0IGJ4ZV9z b2Z0YyAqc2MgPSAoc3RydWN0IGJ4ZV9zb2Z0YyAqKWNvbnRleHQ7CisgICAgQlhFX0NPUkVfTE9D SyhzYyk7CisgICAgYnhlX3NldF9yeF9tb2RlKHNjKTsKKyAgICBCWEVfQ09SRV9VTkxPQ0soc2Mp OworfQorc3RhdGljIHZvaWQKK2J4ZV9zZXRfcnhfbW9kZV9zY2goc3RydWN0IGJ4ZV9zb2Z0YyAq c2MpCit7CisgICAgaWYgKGlmX2dldGRydmZsYWdzKHNjLT5pZnApICYgSUZGX0RSVl9SVU5OSU5H KSB7CisJdGFza3F1ZXVlX2VucXVldWUodGFza3F1ZXVlX3RocmVhZCwgJnNjLT5zZXRfcnhfbW9k ZSk7CisgICAgfQorfQorCiAKIC8qCiAgKiBIYW5kbGVzIGFueSBJT0NUTCBjYWxscyBmcm9tIHRo ZSBvcGVyYXRpbmcgc3lzdGVtLgpAQCAtNDU2MSwyNSArNDU3OSwzMCBAQCBieGVfaW9jdGwoaWZf dCBpZnAsCiAgICAgICAgIC8qIHRvZ2dsZSB0aGUgaW50ZXJmYWNlIHN0YXRlIHVwIG9yIGRvd24g Ki8KICAgICAgICAgQkxPR0Qoc2MsIERCR19JT0NUTCwgIlJlY2VpdmVkIFNJT0NTSUZGTEFHUyBp b2N0bFxuIik7CiAKKyAgICAgICAgaWYgKChpZl9nZXRmbGFncyhpZnApICYgSUZGX1VQKSAmJgor ICAgICAgICAgICAgKGlmX2dldGRydmZsYWdzKGlmcCkgJiBJRkZfRFJWX1JVTk5JTkcpKSB7Cisg ICAgICAgICAgICAgICAgYnhlX3NldF9yeF9tb2RlX3NjaChzYyk7CisgICAgICAgIH0KKworCiAJ QlhFX0NPUkVfTE9DSyhzYyk7CiAgICAgICAgIC8qIGNoZWNrIGlmIHRoZSBpbnRlcmZhY2UgaXMg dXAgKi8KICAgICAgICAgaWYgKGlmX2dldGZsYWdzKGlmcCkgJiBJRkZfVVApIHsKLSAgICAgICAg ICAgIGlmIChpZl9nZXRkcnZmbGFncyhpZnApICYgSUZGX0RSVl9SVU5OSU5HKSB7Ci0gICAgICAg ICAgICAgICAgLyogc2V0IHRoZSByZWNlaXZlIG1vZGUgZmxhZ3MgKi8KLSAgICAgICAgICAgICAg ICBieGVfc2V0X3J4X21vZGUoc2MpOwotICAgICAgICAgICAgfSBlbHNlIGlmKHNjLT5zdGF0ZSAh PSBCWEVfU1RBVEVfRElTQUJMRUQpIHsKLQkJYnhlX2luaXRfbG9ja2VkKHNjKTsKKyAgICAgICAg ICAgICBpZigoKGlmX2dldGRydmZsYWdzKGlmcCkgJiBJRkZfRFJWX1JVTk5JTkcpID09IDApICYm CisgICAgICAgICAgICAgICAgICAgICAgICAoc2MtPnN0YXRlICE9IEJYRV9TVEFURV9ESVNBQkxF RCkpIHsKKyAgICAgICAgICAgICAgICBieGVfaW5pdF9sb2NrZWQoc2MpOwogICAgICAgICAgICAg fQogICAgICAgICB9IGVsc2UgewogICAgICAgICAgICAgaWYgKGlmX2dldGRydmZsYWdzKGlmcCkg JiBJRkZfRFJWX1JVTk5JTkcpIHsKLQkJYnhlX3BlcmlvZGljX3N0b3Aoc2MpOwotCQlieGVfc3Rv cF9sb2NrZWQoc2MpOworICAgICAgICAgICAgICAgIGJ4ZV9wZXJpb2RpY19zdG9wKHNjKTsKKyAg ICAgICAgICAgICAgICBieGVfc3RvcF9sb2NrZWQoc2MpOwogICAgICAgICAgICAgfQogICAgICAg ICB9Ci0JQlhFX0NPUkVfVU5MT0NLKHNjKTsKKyAgICAgICAgQlhFX0NPUkVfVU5MT0NLKHNjKTsK IAogICAgICAgICBicmVhazsKIAorCQogICAgIGNhc2UgU0lPQ0FERE1VTFRJOgogICAgIGNhc2Ug U0lPQ0RFTE1VTFRJOgogICAgICAgICAvKiBhZGQvZGVsZXRlIG11bHRpY2FzdCBhZGRyZXNzZXMg Ki8KQEAgLTQ1ODgsOSArNDYxMSw3IEBAIGJ4ZV9pb2N0bChpZl90IGlmcCwKICAgICAgICAgLyog Y2hlY2sgaWYgdGhlIGludGVyZmFjZSBpcyB1cCAqLwogICAgICAgICBpZiAoaWZfZ2V0ZHJ2Zmxh Z3MoaWZwKSAmIElGRl9EUlZfUlVOTklORykgewogICAgICAgICAgICAgLyogc2V0IHRoZSByZWNl aXZlIG1vZGUgZmxhZ3MgKi8KLQkgICAgQlhFX0NPUkVfTE9DSyhzYyk7Ci0gICAgICAgICAgICBi eGVfc2V0X3J4X21vZGUoc2MpOwotCSAgICBCWEVfQ09SRV9VTkxPQ0soc2MpOyAKKyAgICAgICAg ICAgIGJ4ZV9zZXRfcnhfbW9kZV9zY2goc2MpOwogICAgICAgICB9CiAKICAgICAgICAgYnJlYWs7 CkBAIC0xNjM1Nyw2ICsxNjM3OCw4IEBAIGJ4ZV9hdHRhY2goZGV2aWNlX3QgZGV2KQogICAgIFRJ TUVPVVRfVEFTS19JTklUKHRhc2txdWV1ZV90aHJlYWQsCiAgICAgICAgICZzYy0+c3BfZXJyX3Rp bWVvdXRfdGFzaywgMCwgYnhlX3NwX2Vycl90aW1lb3V0X3Rhc2ssICBzYyk7CiAKKyAgICBUQVNL X0lOSVQoJnNjLT5zZXRfcnhfbW9kZSwgMCwgYnhlX3NldF9yeF9tb2RlX3Rhc2ssIHNjKTsKKwog CiAgICAgLyogZ2V0IGRldmljZSBpbmZvIGFuZCBzZXQgcGFyYW1zICovCiAgICAgaWYgKGJ4ZV9n ZXRfZGV2aWNlX2luZm8oc2MpICE9IDApIHsKQEAgLTE2NTM1LDYgKzE2NTU4LDcgQEAgYnhlX2Rl dGFjaChkZXZpY2VfdCBkZXYpCiAgICAgICAgIHNjLT5jaGlwX3RxID0gTlVMTDsKICAgICAgICAg dGFza3F1ZXVlX2RyYWluX3RpbWVvdXQodGFza3F1ZXVlX3RocmVhZCwKICAgICAgICAgICAgICZz Yy0+c3BfZXJyX3RpbWVvdXRfdGFzayk7CisJdGFza3F1ZXVlX2RyYWluKHRhc2txdWV1ZV90aHJl YWQsJnNjLT5zZXRfcnhfbW9kZSk7CiAgICAgfQogCiAgICAgLyogc3RvcCBhbmQgcmVzZXQgdGhl IGNvbnRyb2xsZXIgaWYgaXQgd2FzIG9wZW4gKi8KZGlmZiAtdWFwIGxhdGVzdGJ4ZV9oZWFkMi9i eGUuaCBsYXRlc3RfYnhlX2hlYWRfcGF0Y2gvYnhlLmgKLS0tIGxhdGVzdGJ4ZV9oZWFkMi9ieGUu aAkyMDE5LTA2LTEyIDE1OjI1OjQ5LjI4ODY4MTAwMCAtMDcwMAorKysgbGF0ZXN0X2J4ZV9oZWFk X3BhdGNoL2J4ZS5oCTIwMTktMDYtMTggMTQ6NTY6MDcuMTMzNDIwMDAwIC0wNzAwCkBAIC02NTQs NiArNjU0LDcgQEAgc3RydWN0IGJ4ZV9mYXN0cGF0aCB7CiAKICAgICBzdHJ1Y3QgdGFzayB0eF90 YXNrOwogICAgIHN0cnVjdCB0aW1lb3V0X3Rhc2sgdHhfdGltZW91dF90YXNrOworICAgIHN0cnVj dCB0YXNrICAgICAgICAgICAgc2V0X3J4X21vZGU7CiAKICAgICAvKiBldGhlcm5ldCBjbGllbnQg SUQgKGVhY2ggZmFzdHBhdGggc2V0IG9mIFJYL1RYL0NRRSBpcyBhIGNsaWVudCkgKi8KICAgICB1 aW50OF90IGNsX2lkOwo= --_004_BYAPR18MB29525851D26920401F0A9932A3EA0BYAPR18MB2952namp_-- From owner-freebsd-net@freebsd.org Wed Jun 19 04:42:45 2019 Return-Path: Delivered-To: freebsd-net@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 304BF15D1CB9; Wed, 19 Jun 2019 04:42:45 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "eg.sd.rdtc.ru", Issuer "eg.sd.rdtc.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B7EC7464B; Wed, 19 Jun 2019 04:42:33 +0000 (UTC) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-net@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x5J4gOXP081759 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jun 2019 11:42:24 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Eliminating IPv6 (?) To: "Ronald F. Guilmette" , freebsd-net , FreeBSD Questions Mailing List References: <24170.1560891451@segfault.tristatelogic.com> From: Eugene Grosbein Message-ID: <2cd79858-66a6-dedb-19b8-697d220c9986@grosbein.net> Date: Wed, 19 Jun 2019 11:42:15 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <24170.1560891451@segfault.tristatelogic.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0B7EC7464B X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [1.04 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.31)[-0.307,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MX_INVALID(0.50)[greylisted]; NEURAL_SPAM_SHORT(0.75)[0.755,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_SPAM_LONG(0.19)[0.186,0]; IP_SCORE(0.00)[country: RU(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29072, ipnet:2a03:3100::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 04:42:45 -0000 19.06.2019 3:57, Ronald F. Guilmette wrote: > And god only knows how much will break once I've done that. IPv6 will break only. > How many other > people have tested -all- of the resulting binaries, seriously, on actual > production systems? (I may be the first one ever, at least for 12.0.) I ran plenty of hosts with IPv6 disabled this way and no problems observed, but this pre-dates 12.0. From owner-freebsd-net@freebsd.org Wed Jun 19 05:18:00 2019 Return-Path: Delivered-To: freebsd-net@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 2179E15D279B for ; Wed, 19 Jun 2019 05:18:00 +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 AFE5A7552F for ; Wed, 19 Jun 2019 05:17:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7398815D279A; Wed, 19 Jun 2019 05:17:59 +0000 (UTC) Delivered-To: net@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 61E6515D2799 for ; Wed, 19 Jun 2019 05:17:59 +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 F406B7552D for ; Wed, 19 Jun 2019 05:17:58 +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 463B91B483 for ; Wed, 19 Jun 2019 05:17:58 +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 x5J5HwcG026983 for ; Wed, 19 Jun 2019 05:17:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5J5HwoC026982 for net@FreeBSD.org; Wed, 19 Jun 2019 05:17:58 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: net@FreeBSD.org Subject: [Bug 226217] if_qlxgb (QLogic cLOM8214) not working for me when configured via netif Date: Wed, 19 Jun 2019 05:17:58 +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.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bchow@newestech.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 05:18:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226217 bchow@newestech.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bchow@newestech.com --- Comment #1 from bchow@newestech.com --- I am seeing this exact behavior. If I unplug the interface, manually confi= gure the mtu using ifconfig and replug the device, it works just fine. However, when it's automatically configured, I am seeing the same error as the origi= nal bug report. Was there ever any resolution or work around? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jun 19 05:31:19 2019 Return-Path: Delivered-To: freebsd-net@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 48E2015D2D1D; Wed, 19 Jun 2019 05:31:19 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 54CCE75BB5; Wed, 19 Jun 2019 05:31:18 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ot1-x32b.google.com with SMTP id 43so901963otf.8; Tue, 18 Jun 2019 22:31:18 -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=0IGH+biRNaM4exiYnpbiUBbnN3JcJ4Stpjt98GABnVg=; b=LJVIaTeiu6bgNYcuzf7slcW/Z8/mBMLFKeoaKG1DWUxpLIIxnhnmKbLTFNo+eqR7OR GrOb4A8S2j80B2HWPmXBjTSUBvPfIml/Wm7Lb7bq6BDmeNPvoHnHH/VIMjVrvErhnlaE sKqS3x8ORolpBgul9AewuZg+h1lDqdQxQ8C2BsLoSBkOpeniwQcBf2RyOIIhHd0SgMk/ KPsX8l92oA6nky0wvugRgrvzAdV3gzF8Ohz0JEUTkoJSfkrbIxfBH2HDKnan3yAQuqC3 qm8FzU7uSOccmWu2LvokzBLKO2axPoijOFh7yFN1jMskGG3EOL+PKcLl1qthX3S75f3T pUHg== 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=0IGH+biRNaM4exiYnpbiUBbnN3JcJ4Stpjt98GABnVg=; b=Yp/B3X+OVAsKTMfnLFqCGV6zEAfCZb4HcqLBUw/zVb18w2d3N+FvyscWZXCPfEMJG7 oxRiP/bY/o9BKHvm8Lf5Y6hKknFMIzWVDLYxfuyLYkpx4U7qNj1eUQBnXeIv+p5qCKzp vtu3XqV4F4p3PNcwFTDYy9asoVgQs5GqB+MDMFZ76RHXI098oNQ7dQ1n//mNpJRrLXC8 4/QGLuHnCYEbPJHdUoUFbZG+dD1/mE1wkKx/T0nsfBWo0hdM7QReGnhiQ8O56m9trq1Q Xxsrezb5VXHkmSHsx0nKA8vju/bV423tZvGCCCZMOFXmkddh5Kzq9+zLVejd6jTdSKl4 nq2w== X-Gm-Message-State: APjAAAWVL623vzKtekNoBfC+ZnqvITgWdMDYKO2G98UO0Kkg2xo4qHdI RhIVjr5dmDkB0Zb4krCxufy/R5FBYAVg23D6nuPDao9A X-Google-Smtp-Source: APXvYqxnVKOzyUhqM5XbTdgWnrILJakPMaR1Q0N19w8CCZRbRO15pbnyHPrE9eoValRD0df4jfrotvNSwZHFVYwnbU4= X-Received: by 2002:a9d:7ad4:: with SMTP id m20mr7889058otn.93.1560922277455; Tue, 18 Jun 2019 22:31:17 -0700 (PDT) MIME-Version: 1.0 References: <24393.1560893271@segfault.tristatelogic.com> In-Reply-To: <24393.1560893271@segfault.tristatelogic.com> From: Kevin Oberman Date: Tue, 18 Jun 2019 22:31:00 -0700 Message-ID: Subject: Re: Eliminating IPv6 (?) To: "Ronald F. Guilmette" Cc: FreeBSD Net , Mailinglists FreeBSD X-Rspamd-Queue-Id: 54CCE75BB5 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=LJVIaTei; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::32b as permitted sender) smtp.mailfrom=kob6558@gmail.com X-Spamd-Result: default: False [-6.42 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.84)[-0.840,0]; FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com]; SUBJECT_HAS_QUESTION(0.00)[]; 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)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[b.2.3.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]; IP_SCORE(-2.87)[ip: (-8.81), ipnet: 2607:f8b0::/32(-3.16), asn: 15169(-2.32), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 05:31:19 -0000 On Tue, Jun 18, 2019 at 2:28 PM Ronald F. Guilmette wrote: > In message w@mail.gmail.com> > Andreas Nilsson wrote: > > >But why are you even running rc.firewall if it does not do what you want? > > You are asking me the very question that *I* have been asking myself > since my "upgrade" to 12.0. > > Why is /etc/rc.firewall even being executed? I never explicitly asked for > that, but that seems to just be a by-product of how things are arranged > these days.... a by-product that I have no direct control over. > > >Just set firewall_script="/path/to/script" and your good to go, no ipv6 > >anywhere to be found. > > That is *not* what the Handbook says. Please read it. > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html > > The way that I am reading section 30.4.1 is that it is telling the user to > put BOTH of these things into /etc/rc.conf: > > firewall_enable="YES" > firewall_type="path-to-my-rules-file" > > And indeed, that is -exactly- what I have done on my prior FreeBSD > systems... > enable *and* configure. > > One or the other of those /etc/rc.conf lines nowadays apparently triggers > /etc/rc.firewall to run. I never explicitly asked for that to run, but > it did anyway. I am just going with the flow. > > > Regards, > rfg I was hoping to avoid this as I have not worked with IPv6 since I retired 8 years ago and I worked on this back before then by a couple of years. My memory is not perfect, so excuse any minor errors. I do know that back when I ran CURRENT I ran into a problem booting the system after ipfw and ipfw6 were merged. It stopped while starting the network if I had IPv6 enabled. At that time, IPv6 was not This was because I used the default net.inet.ip.fw.default_to_accept=0, so an automatic "65535 deny ip from any to any" was placed in ipfw. (This has long been the case and provided precedence for further automatic rules.) The problem is that IPv6 could not start unless certain IPv6 packets are allowed. I know NDP is required and, generally, certain ICMPv6 types are also needed. Without those, rules, IPv6 startup would block, unable to perform SLAAC, the default addresss assignment method and DHCPv6, if used. The result was a set of rules that are required for IPv6 to come up was added to the rules set by default. I have never seen this clearly documented except in the code and it has been changed several times over the years. On at least one case, a change broke my rule set as, unlike the reject by default rule and default loopback rule, were assigned real numbers which might fall into places in a rule-set that caused incorrect behavior. (Note: I have not read the handbook section on this in a while, so it may be documented by now.) This really needs proper documentation but it is now assumed by most OSes including Windows, MacOS, Linux and FreeBSD that IPv6 and IPv4 will be enabled by default. As time goes on, it will likely be more and more likely that disabling IPv6 will become difficult if networks are used at all. It already really requires a custom kernel to completely remove it and, even then, some IPv6 code is still be in the kernel, but unreachable unless someone has spotted these and '#ifdef"ed them. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-net@freebsd.org Wed Jun 19 06:17:31 2019 Return-Path: Delivered-To: freebsd-net@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 AB6B115D3665 for ; Wed, 19 Jun 2019 06:17:31 +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 2E37A76DE3 for ; Wed, 19 Jun 2019 06:17:29 +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 x5J6HQGO016709; Tue, 18 Jun 2019 23:17:26 -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 x5J6HQmA016708; Tue, 18 Jun 2019 23:17:26 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906190617.x5J6HQmA016708@gndrsh.dnsmgr.net> Subject: Re: localhost woes -- help requested In-Reply-To: <24271.1560892386@segfault.tristatelogic.com> To: "Ronald F. Guilmette" Date: Tue, 18 Jun 2019 23:17:26 -0700 (PDT) CC: freebsd-net 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: 2E37A76DE3 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.83 / 15.00]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.92)[0.922,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.16)[0.155,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.82)[0.816,0]; R_SPF_NA(0.00)[]; IP_SCORE(0.04)[ip: (0.15), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 06:17:31 -0000 > In message <201906181719.x5IHJ8g0014687@gndrsh.dnsmgr.net>, > "Rodney W. Grimes" wrote: > > >What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running? > > > 1) https://pastebin.com/raw/wXTTgd9R This is /etc/hosts, not /etc/host.conf # cat /etc/host.conf # Auto-generated from nsswitch.conf hosts dns > 2) https://pastebin.com/raw/PiGpN0LU > > 3) Yes, local-unbound Ok, if you comment out ::1 from /etc/hosts then the lookup is going to fall through to DNS with the default /etc/host.conf file and you'll get what ever your dns is configured to return, which is usually the exact some thing as /etc/hosts has. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jun 19 06:23:33 2019 Return-Path: Delivered-To: freebsd-net@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 38ABA15D38AC for ; Wed, 19 Jun 2019 06:23:33 +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 244DD7716C for ; Wed, 19 Jun 2019 06:23:31 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id C1DEF4E669; Tue, 18 Jun 2019 23:23:30 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-net Subject: Re: localhost woes -- help requested In-Reply-To: <201906190617.x5J6HQmA016708@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26906.1560925410.1@segfault.tristatelogic.com> Date: Tue, 18 Jun 2019 23:23:30 -0700 Message-ID: <26907.1560925410@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 244DD7716C 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.78 / 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]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.77)[ip: (-7.28), ipnet: 69.62.128.0/17(-3.64), asn: 14051(-2.88), country: US(-0.06)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; NEURAL_HAM_SHORT(-0.80)[-0.795,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 06:23:33 -0000 In message <201906190617.x5J6HQmA016708@gndrsh.dnsmgr.net>, Rodney W. Grimes" wrote: >> In message <201906181719.x5IHJ8g0014687@gndrsh.dnsmgr.net>, >> "Rodney W. Grimes" wrote: >> >> >What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running? >> >> >> 1) https://pastebin.com/raw/wXTTgd9R >This is /etc/hosts, not /etc/host.conf ># cat /etc/host.conf ># Auto-generated from nsswitch.conf >hosts >dns > >> 2) https://pastebin.com/raw/PiGpN0LU >> >> 3) Yes, local-unbound > >Ok, if you comment out ::1 from /etc/hosts then the lookup is >going to fall through to DNS with the default /etc/host.conf file >and you'll get what ever your dns is configured to return, which >is usually the exact some thing as /etc/hosts has. So basically you're telling me that local-unbound has taken it upon itself to decide for me, regardless of what is or isn't in my /etc/hosts file, what addresses "localhost" should resolve to?? If so, that really is rather presumptive on its part. From owner-freebsd-net@freebsd.org Wed Jun 19 07:05:08 2019 Return-Path: Delivered-To: freebsd-net@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 268DA15D4384 for ; Wed, 19 Jun 2019 07:05:08 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (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 E98018051C for ; Wed, 19 Jun 2019 07:05:06 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [217.29.44.10]) by gate2.intern.punkt.de with ESMTP id x5J754Qq050596; Wed, 19 Jun 2019 09:05:04 +0200 (CEST) Received: from [217.29.44.36] ([217.29.44.36]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id x5J7540w000610; Wed, 19 Jun 2019 09:05:04 +0200 (CEST) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: localhost woes -- help requested From: "Patrick M. Hausen" In-Reply-To: <26907.1560925410@segfault.tristatelogic.com> Date: Wed, 19 Jun 2019 09:05:04 +0200 Cc: freebsd-net Content-Transfer-Encoding: 7bit Message-Id: <74B7CCF0-967F-40B1-9818-3417CD8D1D72@punkt.de> References: <26907.1560925410@segfault.tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: E98018051C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hausen@punkt.de designates 217.29.33.131 as permitted sender) smtp.mailfrom=hausen@punkt.de X-Spamd-Result: default: False [-2.45 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.29.32.0/20]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[punkt.de]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mailin.pluspunkthosting.de]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[131.33.29.217.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_SHORT(-0.46)[-0.457,0]; IP_SCORE(-0.20)[ipnet: 217.29.32.0/20(-0.55), asn: 16188(-0.44), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 07:05:08 -0000 Hi! > Am 19.06.2019 um 08:23 schrieb Ronald F. Guilmette : > So basically you're telling me that local-unbound has taken it upon > itself to decide for me, regardless of what is or isn't in my /etc/hosts > file, what addresses "localhost" should resolve to?? > > If so, that really is rather presumptive on its part. https://tools.ietf.org/html/rfc6761 Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe info@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling From owner-freebsd-net@freebsd.org Wed Jun 19 07:14:34 2019 Return-Path: Delivered-To: freebsd-net@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 CFA3415D4662; Wed, 19 Jun 2019 07:14:34 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 6EB9A809CF; Wed, 19 Jun 2019 07:14:33 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by mail-lf1-x129.google.com with SMTP id y198so11270069lfa.1; Wed, 19 Jun 2019 00:14:33 -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=U0syaAuiag1hNnR8xPtuq3gSJq0UXxY55VrHBi4Q9Vw=; b=F7vV/QEDc+kUFv52UCz/oePTpulfI11B/IXyY7IUbIJTi1gGTH0Qwhqsj/+03P6o/u S09HmMaXu/L6x+yzbF7jJdhbnKcFHOSNP6QbRjLAWViagFp2BfR5Hh5NFQuP2H3Sz0km Ttj8CoURJrospgBzuJSATj/8Fb0rCGg0EykuxjqLmfp3U6RQexHfMFwc8Jzi3I/ugJC2 5w8pi2K9eDTzW1a43B4SIzVuVUJUOj99K7679DPkz+3hhcB0DiU9mOTlrPoFt0YuZ1FV XzNJq13KLPtxv5zOy7SxnmMYIyyifdb+Clqkab/QDaDW2lT4ZuAHvHZvdsVw51mGIf7T C+Jg== 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=U0syaAuiag1hNnR8xPtuq3gSJq0UXxY55VrHBi4Q9Vw=; b=R3Ruse3r+wOUH5AbojsXYN97PNFhjToEoqWh6cDz6AGMg4VrobjYCy5kNfR6p9exZH kB0o+Li8i/bl5yEXlEgylmKr1mukZeIOLSgr1XmVZRxFp/0fWS0tfx9SZkd1dUCJgxP6 d6QUEbkWY1ADCrKWistNn3dMxBDB9I9O+uyAhJ06O/piFJeAI4iLgDESDpXwYiJMW0tM uu31lTPXP3d6fv2l1SMEPv0em/42WrFqI0jShVnqFofEny5mTrgN/mtB9D83e2RVqiwU 1PEL6GQRIeykGO/AIhvJS6CtTcK9DdsclKfdZkkW6EPEuye0TLf/PnErk3J4KHcLmfyM 4pVw== X-Gm-Message-State: APjAAAVHz85vOEsHvpOgmYMTE7IB8r46MeNY524UTbj/hIvplZczfh2D ugkegrpsrsPmB0a/IdoLTXkNwr48eEy6LkQMG+TCcj2h X-Google-Smtp-Source: APXvYqxp2pBSz2oWL4/H2YkzAMlK3+I3qu9Z4UC1BgqLkPhHDakOb+yIagJU9M6OhLSi2/V0Fiytyz3+9y7zyDPcZic= X-Received: by 2002:ac2:59c9:: with SMTP id x9mr3688873lfn.52.1560928471494; Wed, 19 Jun 2019 00:14:31 -0700 (PDT) MIME-Version: 1.0 References: <24393.1560893271@segfault.tristatelogic.com> In-Reply-To: <24393.1560893271@segfault.tristatelogic.com> From: Andreas Nilsson Date: Wed, 19 Jun 2019 09:14:19 +0200 Message-ID: Subject: Re: Eliminating IPv6 (?) To: "Ronald F. Guilmette" Cc: FreeBSD Net , Mailinglists FreeBSD X-Rspamd-Queue-Id: 6EB9A809CF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=F7vV/QED; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of andrnils@gmail.com designates 2a00:1450:4864:20::129 as permitted sender) smtp.mailfrom=andrnils@gmail.com X-Spamd-Result: default: False [-6.76 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.95)[-0.951,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_LAST(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; 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)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE(-2.80)[ip: (-9.15), ipnet: 2a00:1450::/32(-2.49), asn: 15169(-2.32), country: US(-0.06)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[9.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 07:14:35 -0000 On Tue, Jun 18, 2019, 23:28 Ronald F. Guilmette wrote: > In message w@mail.gmail.com> > Andreas Nilsson wrote: > > >But why are you even running rc.firewall if it does not do what you want? > > You are asking me the very question that *I* have been asking myself > since my "upgrade" to 12.0. > > Why is /etc/rc.firewall even being executed? I never explicitly asked for > that, but that seems to just be a by-product of how things are arranged > these days.... a by-product that I have no direct control over. > > >Just set firewall_script="/path/to/script" and your good to go, no ipv6 > >anywhere to be found. > > That is *not* what the Handbook says. Please read it. > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html > > Ok, so the handbook is wrong. It's a bug in the documentation. > The way that I am reading section 30.4.1 is that it is telling the user to > put BOTH of these things into /etc/rc.conf: > > firewall_enable="YES" > firewall_type="path-to-my-rules-file" > > And indeed, that is -exactly- what I have done on my prior FreeBSD > systems... > enable *and* configure. > > One or the other of those /etc/rc.conf lines nowadays apparently triggers > /etc/rc.firewall to run. I never explicitly asked for that to run, but > it did anyway. I am just going with the flow. > As soon as set firewall_script instead of firewall_type your problems will be solved. Just try it. The man page for rc.conf will tell you the same thing. > > > Regards, > rfg > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Wed Jun 19 07:25:32 2019 Return-Path: Delivered-To: freebsd-net@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 725D415D4A23; Wed, 19 Jun 2019 07:25:32 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (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 B9D4280EB4; Wed, 19 Jun 2019 07:25:31 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [217.29.44.10]) by gate2.intern.punkt.de with ESMTP id x5J7PU4X050911; Wed, 19 Jun 2019 09:25:30 +0200 (CEST) Received: from [217.29.44.36] ([217.29.44.36]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id x5J7PU45001719; Wed, 19 Jun 2019 09:25:30 +0200 (CEST) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Eliminating IPv6 (?) From: "Patrick M. Hausen" In-Reply-To: Date: Wed, 19 Jun 2019 09:25:29 +0200 Cc: "Ronald F. Guilmette" , FreeBSD Net , Mailinglists FreeBSD Content-Transfer-Encoding: 7bit Message-Id: <6FA15752-4AD6-41F3-BE41-FE3B0453D530@punkt.de> References: <24393.1560893271@segfault.tristatelogic.com> To: Andreas Nilsson X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: B9D4280EB4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hausen@punkt.de designates 217.29.33.131 as permitted sender) smtp.mailfrom=hausen@punkt.de X-Spamd-Result: default: False [-2.75 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.987,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:217.29.32.0/20]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[punkt.de]; NEURAL_HAM_LONG(-0.99)[-0.994,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mailin.pluspunkthosting.de]; NEURAL_HAM_SHORT(-0.76)[-0.761,0]; RCVD_IN_DNSWL_NONE(0.00)[131.33.29.217.list.dnswl.org : 127.0.10.0]; IP_SCORE(-0.19)[ipnet: 217.29.32.0/20(-0.54), asn: 16188(-0.43), country: DE(-0.01)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 07:25:32 -0000 Hi! > Am 19.06.2019 um 09:14 schrieb Andreas Nilsson : > As soon as set firewall_script instead of firewall_type your problems will > be solved. Just try it. The man page for rc.conf will tell you the same > thing. He will need to adjust his rule file, though. Setting firewall_type to an absolute path name implicitly calls ipfw with the file as an argument, so the file should contain only the rules. When using firewall_script you need to invoke ipfw explicitly in your file, since it is just executed as a shell script. Kind regards Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe info@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling From owner-freebsd-net@freebsd.org Wed Jun 19 15:27:00 2019 Return-Path: Delivered-To: freebsd-net@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 DFAFE15BBD60 for ; Wed, 19 Jun 2019 15:26:59 +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 2AB186AB9F for ; Wed, 19 Jun 2019 15:26:55 +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 x5JFQrti018681; Wed, 19 Jun 2019 08:26:53 -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 x5JFQrVT018680; Wed, 19 Jun 2019 08:26:53 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906191526.x5JFQrVT018680@gndrsh.dnsmgr.net> Subject: Re: localhost woes -- help requested In-Reply-To: <26907.1560925410@segfault.tristatelogic.com> To: "Ronald F. Guilmette" Date: Wed, 19 Jun 2019 08:26:53 -0700 (PDT) CC: freebsd-net 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: 2AB186AB9F X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.19 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.11)[0.114,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.27)[0.273,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.87)[0.870,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.15), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 15:27:00 -0000 > In message <201906190617.x5J6HQmA016708@gndrsh.dnsmgr.net>, > Rodney W. Grimes" wrote: > > >> In message <201906181719.x5IHJ8g0014687@gndrsh.dnsmgr.net>, > >> "Rodney W. Grimes" wrote: > >> > >> >What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running? > >> > >> > >> 1) https://pastebin.com/raw/wXTTgd9R > >This is /etc/hosts, not /etc/host.conf > ># cat /etc/host.conf > ># Auto-generated from nsswitch.conf > >hosts > >dns > > > >> 2) https://pastebin.com/raw/PiGpN0LU > >> > >> 3) Yes, local-unbound > > > >Ok, if you comment out ::1 from /etc/hosts then the lookup is > >going to fall through to DNS with the default /etc/host.conf file > >and you'll get what ever your dns is configured to return, which > >is usually the exact some thing as /etc/hosts has. > > So basically you're telling me that local-unbound has taken it upon > itself to decide for me, regardless of what is or isn't in my /etc/hosts > file, what addresses "localhost" should resolve to?? Yes, dns resolvers shipping for the last 5 decades have all shipped with default "localhost" values. Both "localhost" and 127.in-addr.arpa zones existed iirc in the very first version of bind. > > If so, that really is rather presumptive on its part. No, well defined by RFC. I would suggest a starting read at https://en.wikipedia.org/wiki/Localhost Specifically this detail: In the Domain Name System, the name localhost is reserved as a top-level domain name, originally set aside to avoid confusion with the hostname used for loopback purposes.[3] IETF standards prohibit domain name registrars from assigning the name localhost. And finally: https://tools.ietf.org/html/rfc2606#section-2 at The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. Regards, -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jun 19 15:31:03 2019 Return-Path: Delivered-To: freebsd-net@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 D723D15BBFFA for ; Wed, 19 Jun 2019 15:31:02 +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 DEA366AFFA for ; Wed, 19 Jun 2019 15:31:01 +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 x5JFV0jL018700; Wed, 19 Jun 2019 08:31:00 -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 x5JFV0Cf018699; Wed, 19 Jun 2019 08:31:00 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906191531.x5JFV0Cf018699@gndrsh.dnsmgr.net> Subject: Re: localhost woes -- help requested In-Reply-To: <201906191526.x5JFQrVT018680@gndrsh.dnsmgr.net> To: "Rodney W. Grimes" Date: Wed, 19 Jun 2019 08:31:00 -0700 (PDT) CC: "Ronald F. Guilmette" , freebsd-net 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: DEA366AFFA X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.18 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.11)[0.106,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.28)[0.277,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.86)[0.864,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.15), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 15:31:03 -0000 > > In message <201906190617.x5J6HQmA016708@gndrsh.dnsmgr.net>, > > Rodney W. Grimes" wrote: > > > > >> In message <201906181719.x5IHJ8g0014687@gndrsh.dnsmgr.net>, > > >> "Rodney W. Grimes" wrote: > > >> > > >> >What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running? > > >> > > >> > > >> 1) https://pastebin.com/raw/wXTTgd9R > > >This is /etc/hosts, not /etc/host.conf > > ># cat /etc/host.conf > > ># Auto-generated from nsswitch.conf > > >hosts > > >dns > > > > > >> 2) https://pastebin.com/raw/PiGpN0LU > > >> > > >> 3) Yes, local-unbound > > > > > >Ok, if you comment out ::1 from /etc/hosts then the lookup is > > >going to fall through to DNS with the default /etc/host.conf file > > >and you'll get what ever your dns is configured to return, which > > >is usually the exact some thing as /etc/hosts has. > > > > So basically you're telling me that local-unbound has taken it upon > > itself to decide for me, regardless of what is or isn't in my /etc/hosts > > file, what addresses "localhost" should resolve to?? > > Yes, dns resolvers shipping for the last 5 decades have all shipped Ooppps.. off by one calculation "near 4 decades" > with default "localhost" values. Both "localhost" and 127.in-addr.arpa > zones existed iirc in the very first version of bind. > > > > > If so, that really is rather presumptive on its part. > > No, well defined by RFC. > I would suggest a starting read at https://en.wikipedia.org/wiki/Localhost > > Specifically this detail: > In the Domain Name System, the name localhost is reserved as a > top-level domain name, originally set aside to avoid confusion > with the hostname used for loopback purposes.[3] IETF standards > prohibit domain name registrars from assigning the name localhost. > > > And finally: > https://tools.ietf.org/html/rfc2606#section-2 > at > The ".localhost" TLD has traditionally been statically defined in > host DNS implementations as having an A record pointing to the > loop back IP address and is reserved for such use. Any other use > would conflict with widely deployed code which assumes this use. > > Regards, > -- > Rod Grimes rgrimes@freebsd.org > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jun 19 15:35:27 2019 Return-Path: Delivered-To: freebsd-net@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 D127915BC351; Wed, 19 Jun 2019 15:35:26 +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 01AE26B3EA; Wed, 19 Jun 2019 15:35:25 +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 x5JFZNPX018746; Wed, 19 Jun 2019 08:35:23 -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 x5JFZNMo018745; Wed, 19 Jun 2019 08:35:23 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906191535.x5JFZNMo018745@gndrsh.dnsmgr.net> Subject: Re: Eliminating IPv6 (?) In-Reply-To: <6975.1560827403@segfault.tristatelogic.com> To: "Ronald F. Guilmette" Date: Wed, 19 Jun 2019 08:35:23 -0700 (PDT) CC: freebsd-questions@freebsd.org, freebsd-net@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: 01AE26B3EA X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.63 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; 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]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.55)[0.555,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.18)[0.179,0]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.97)[0.965,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 15:35:27 -0000 > I do not wish to begin any religious war here. I understand that IPv6 > can be a sensitive and sometimes even emotional issue for many people. > Speaking only for myself, and only for the present moment, I can say > that for me, IPv6 represents only an annoyance and a very sizable > distraction. At present, I don't use it and have absolutely no need > to do so. I would thus like to simplify my life by eliminating it from > my (12.0-RELEASE) system, so that I won't even have to think about it, > or wonder about it, e.g. when I am configuring my firewall, my daemons, > etc. > > I have tried searching for instructions on how to do this online, but > the suggestions and recommendations for how to do this vary widely. > There does not seem to be any "standard" set of recommendations for > how to simply turn off all IPv6 for a given system, short of rebuilding > the kernel, from scratch, with proper options to eliminate IPv6 support > in the kernel entirely. > > I finally settled on trying to add the following options to my /etc/rc.conf > file: > > ipv6_network_interfaces="none" > ip6addrctl_enable="NO" > ip6addrctl_policy="ipv4_prefer" > ipv6_activate_all_interfaces="NO" > > These seem to have worked only marginally. > > After a fresh reboot, my loopback interface (lo0) for example is still > configured to have -both- IPv4 -and- IPv6 addresses... and routes... > associated with it. > > How can I turn off IPv6 entirely without rebuilding the kernel? I too do not need IPv6 in many many many places, and this is the option I choose to disable it, a kernel recompile is the only complete and effective "knob" to get IPV6 out of your system. Once it is gone from the kernel all the other stuff recognises this and just deals with it without any other tweaking. > Regards, > rfg > > > P.S. Please, please, please, refrain from giving me a sermon about how > I am an idiot and/or about how IPv6 is going to save mankind and/or the > galaxy as we know it. I am pro choice, and I don't really wish to have > IPv6 rammed down my throat before I am ready to swallow. I don't need it, > don't use it, and for me, life is much simpler without it for now. No sermon here, I fully support your position, and am very glad to see that bz@ continues to assert that we need to maintain the INET and INET6 compile options (for some day we may be able to remove V4, but it also has the added benifit in that we can build V4 only, v6 only, or (insert your prefered higher power) forbid, no INET at all! -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jun 19 15:42:32 2019 Return-Path: Delivered-To: freebsd-net@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 C325E15BC879; Wed, 19 Jun 2019 15:42:32 +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 02BD46BA68; Wed, 19 Jun 2019 15:42:31 +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 x5JFgSIS018771; Wed, 19 Jun 2019 08:42:28 -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 x5JFgQQ2018770; Wed, 19 Jun 2019 08:42:26 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906191542.x5JFgQQ2018770@gndrsh.dnsmgr.net> Subject: Re: Eliminating IPv6 (?) In-Reply-To: To: Eugene Grosbein Date: Wed, 19 Jun 2019 08:42:26 -0700 (PDT) CC: "Ronald F. Guilmette" , freebsd-questions@freebsd.org, freebsd-net@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: 02BD46BA68 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.33 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; 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]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.54)[0.544,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.94)[0.942,0]; NEURAL_HAM_SHORT(-0.09)[-0.086,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 15:42:32 -0000 > 18.06.2019 10:10, Ronald F. Guilmette wrote: > > > How can I turn off IPv6 entirely without rebuilding the kernel? > > You cannot. GENERIC kernel specifically enables IPv6 support and you need to disable it at compile time. > And if you do, you better rebuild the world too using WITHOUT_INET6=yes in the /etc/src.conf > or else some utilities compiled with INET6 by default will query kernel > for IPv6-specific data (like routing entries) and complain that your kernel does not know about it. I have not seen these issues, can you give a specific example that fails? A netstat -rn on a v4 only kernel simple reports the v4 table, and iirc a netstat -rn6 returns a "Protocol not supported error" as should all other things. > World built WITHOUT_INET6 has no such rough edges. I find that actually causes me more issues, as then my netstat -rn6 returns a hard error due to: case '6': #ifdef INET6 af = AF_INET6; #else errx(1, "IPv6 support is not compiled in"); #endif -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jun 19 16:10:11 2019 Return-Path: Delivered-To: freebsd-net@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 3169215BD3DA; Wed, 19 Jun 2019 16:10:11 +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 4899D6C817; Wed, 19 Jun 2019 16:10:10 +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 x5JGA7jT018858; Wed, 19 Jun 2019 09:10:07 -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 x5JGA7Ep018857; Wed, 19 Jun 2019 09:10:07 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906191610.x5JGA7Ep018857@gndrsh.dnsmgr.net> Subject: Re: Eliminating IPv6 (?) In-Reply-To: <23511.1560884385@segfault.tristatelogic.com> To: "Ronald F. Guilmette" Date: Wed, 19 Jun 2019 09:10:07 -0700 (PDT) CC: freebsd-net@freebsd.org, freebsd-questions@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: 4899D6C817 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.57 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; 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]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.22)[0.216,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.54)[0.537,0]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.89)[0.887,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 16:10:11 -0000 > In message <23816.53518.998090.665606@jerusalem.litteratus.org>, > Robert Huff wrote: > > >> Actually, no, that's not how one is supposed to enable one's own set > >> of ipfw ules. To do that, the Handbook (Sec. 30.4.1) says very clearly > >> that one should do: > >> > >> firewall_enable="YES" > >> firewall_type="path-to-my-rules-file" > >> > >> But I'm glad you brought it up. The funny thing is that even that > >> doesn't work properly nowadays *or* like it used to in the past. > > > > If this is true - haven't checked personally - then it's a bug. > >(And a non-trivial one, the fact you're the first to report it > >notwithstanding.) > > Can you please open a bug report? > > I aim to please. As requested: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238694 Thank you. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jun 19 16:15:18 2019 Return-Path: Delivered-To: freebsd-net@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 5E4EB15BD916; Wed, 19 Jun 2019 16:15:18 +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 888EA6CE6D; Wed, 19 Jun 2019 16:15:17 +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 x5JGFFfJ018891; Wed, 19 Jun 2019 09:15:15 -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 x5JGFFt7018890; Wed, 19 Jun 2019 09:15:15 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906191615.x5JGFFt7018890@gndrsh.dnsmgr.net> Subject: Re: Eliminating IPv6 (?) In-Reply-To: <24170.1560891451@segfault.tristatelogic.com> To: "Ronald F. Guilmette" Date: Wed, 19 Jun 2019 09:15:15 -0700 (PDT) CC: freebsd-net , FreeBSD Questions Mailing List 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: 888EA6CE6D X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.60 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.53)[0.528,0]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.25)[0.246,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.90)[0.896,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 16:15:18 -0000 > In message > Freddie Cash wrote: > > >For someone who doesn't want to be preached to about the benefits of IPv6, > >you certainly do a lot of preaching about not wanting IPv6. :) > > Guilty as charged. > > >You've been given the tools to do exactly what you want: > > - comment out IPv6 support in the kernel config file > > - add WITHOUT_IPV6=yes to /etc/src.conf > > - rebuild the world and kernel > > > >Voila! A version of FreeBSD made especially for you, without any traces of > >IPv6. Does exactly what you want. Why the long diatribe asking for > >something else once you've been shown how to do what you want? > > Rebuild kernel+world is not exactly a quick solution. Agreed. And I only recommend rebuilding the kernel, one of my motivations for that is besides not needing the v6 on a log of stuff is it reduces both wasted code size, and some security concerns. > And god only knows how much will break once I've done that. How many other > people have tested -all- of the resulting binaries, seriously, on actual > production systems? (I may be the first one ever, at least for 12.0.) I also agree here, running a WITHOUT_IPV6 userland is both very painful to get built AND has issues that one does not need to face, like I showed in another thread about netstat -6. > But this is all besides the point anyway. I am now resigned to my fate, > and I am already up to the fifth stage of grief with respect to this issue. > > https://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model > > > Regards, > rfg -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jun 19 16:18:15 2019 Return-Path: Delivered-To: freebsd-net@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 B7D1415BDAEC; Wed, 19 Jun 2019 16:18:15 +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 E96206CFE6; Wed, 19 Jun 2019 16:18:14 +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 x5JGIDPV018901; Wed, 19 Jun 2019 09:18:13 -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 x5JGIDWa018900; Wed, 19 Jun 2019 09:18:13 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906191618.x5JGIDWa018900@gndrsh.dnsmgr.net> Subject: Re: Eliminating IPv6 (?) In-Reply-To: <2cd79858-66a6-dedb-19b8-697d220c9986@grosbein.net> To: Eugene Grosbein Date: Wed, 19 Jun 2019 09:18:13 -0700 (PDT) CC: "Ronald F. Guilmette" , freebsd-net , FreeBSD Questions Mailing List 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: E96206CFE6 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.81 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.39)[0.388,0]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.53)[0.533,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.96)[0.960,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 16:18:15 -0000 > 19.06.2019 3:57, Ronald F. Guilmette wrote: > > > And god only knows how much will break once I've done that. > > IPv6 will break only. That is incorrect, scripts that would silently do nothing can now infact fail, trust me, first hand experience. This can have consequences beyong "IPv6 will break only". > > How many other > > people have tested -all- of the resulting binaries, seriously, on actual > > production systems? (I may be the first one ever, at least for 12.0.) > > I ran plenty of hosts with IPv6 disabled this way and no problems observed, but this pre-dates 12.0. I've not run a userland without V6 in a long time once I started to have issues with some things. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jun 19 19:32:02 2019 Return-Path: Delivered-To: freebsd-net@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 0F56415C7A66 for ; Wed, 19 Jun 2019 19:32:02 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 77D5F770BD for ; Wed, 19 Jun 2019 19:32:01 +0000 (UTC) (envelope-from roberthuff@rcn.com) DKIM-Signature: v=1; a=rsa-sha1; d=rcn.com; s=20180516; c=relaxed/simple; q=dns/txt; i=@rcn.com; t=1560972714; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=lpikcxxBYFhoqZyK9+oyxwl4SFg=; b=MVRKKR3z6BJ8tlQBW1NtQTPPG+Up3MFXd2gt0V42HHNnyIkoSvKVxz4dMDkig6UW u4BLyxLVxOQ9l2bKkErc94u1jkK5O0fXbExfRAWEKO7qkUYasjZJ+5l85sGWKRoq bdR8GxYm3IuiBHhHNw4Kw93FurKo37m1y5bcvVAlR9tamq3h8ZzGo+a+FGnuOb0m mfHisOBuTMuKA4awaRpUJa+KXj6YTumXIe/KfJokQ1pHyXUMhynR+2LPgQoeJmfR wIJRVj6W6yGj6CTL9VNWTbtlGJCOQsCXU8P16N58i06FxfVehMHWKY46AdVEpeI6 qc7U6Odp8poWp3UTTl6jXQ==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=buYOPwSi c=1 sm=1 tr=0 a=9TgA2UwI6Wy+6BV4wQM/cQ==:117 a=9TgA2UwI6Wy+6BV4wQM/cQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=KGjhK52YXX0A:10 a=kj9zAlcOel0A:10 a=XRQyMpdBKAEA:10 a=dq6fvYVFJ5YA:10 a=48faUk6PgeAA:10 a=J0chH1O8E8NaSzgytHsA:9 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=softfail; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=roberthuff; auth=pass (PLAIN) Received: from [209.6.230.48] ([209.6.230.48:57221] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=AES256-GCM-SHA384) id C7/67-36753-AAD8A0D5; Wed, 19 Jun 2019 15:31:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23818.36263.312034.714296@jerusalem.litteratus.org> Date: Wed, 19 Jun 2019 15:31:51 -0400 From: Robert Huff To: "Rodney W. Grimes" Cc: "Ronald F. Guilmette" , freebsd-net , FreeBSD Questions Mailing List Subject: Re: Eliminating IPv6 (?) In-Reply-To: <201906191615.x5JGFFt7018890@gndrsh.dnsmgr.net> References: <24170.1560891451@segfault.tristatelogic.com> <201906191615.x5JGFFt7018890@gndrsh.dnsmgr.net> X-Mailer: VM 8.2.0b under 26.2 (amd64-portbld-freebsd13.0) X-Rspamd-Queue-Id: 77D5F770BD X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rcn.com header.s=20180516 header.b=MVRKKR3z; dmarc=pass (policy=none) header.from=rcn.com; spf=pass (mx1.freebsd.org: domain of roberthuff@rcn.com designates 69.168.97.78 as permitted sender) smtp.mailfrom=roberthuff@rcn.com X-Spamd-Result: default: False [-7.86 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[rcn.com:s=20180516]; RCVD_IN_DNSWL_LOW(-0.10)[78.97.168.69.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:69.168.97.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; DWL_DNSWL_LOW(-1.00)[rcn.com.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[rcn.com:+]; DMARC_POLICY_ALLOW(-0.50)[rcn.com,none]; MX_GOOD(-0.01)[cached: mx.rcn.com]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.77)[ip: (-9.30), ipnet: 69.168.97.0/24(-4.58), asn: 36271(0.09), country: US(-0.06)]; ASN(0.00)[asn:36271, ipnet:69.168.97.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 19:32:02 -0000 Rodney W. Grimes writes: > > And god only knows how much will break once I've done that. How many other > > people have tested -all- of the resulting binaries, seriously, on actual > > production systems? (I may be the first one ever, at least for 12.0.) > > I also agree here, running a WITHOUT_IPV6 userland is both very > painful to get built AND has issues that one does not need to face, > like I showed in another thread about netstat -6. Wider question: Say I'm running a system with both IPv4 and IPv6 enabled. Stuff Happens(tm) and I want to completely disable IPv6 for some indefinite but temporary period - not chamge any configuration settings or firewall rules, but just have the code finish processing current packets (or not) and then ignore further traffic. There will be consequences; I'm prepared to accept them. Is there a single master switch - a sysctl, perhaps, or something in /etc/rc.d - that lets me do that? Respectfully, Robert Huff From owner-freebsd-net@freebsd.org Wed Jun 19 20:39:50 2019 Return-Path: Delivered-To: freebsd-net@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 D982515C984A; Wed, 19 Jun 2019 20:39:50 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "eg.sd.rdtc.ru", Issuer "eg.sd.rdtc.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B5B7B81FBD; Wed, 19 Jun 2019 20:39:39 +0000 (UTC) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-net@freebsd.org Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x5JKdXgc093381 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jun 2019 03:39:33 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Eliminating IPv6 (?) To: "Rodney W. Grimes" References: <201906191618.x5JGIDWa018900@gndrsh.dnsmgr.net> Cc: freebsd-net , FreeBSD Questions Mailing List , "Ronald F. Guilmette" From: Eugene Grosbein Message-ID: <42461287-c282-697e-6a21-571212dff832@grosbein.net> Date: Thu, 20 Jun 2019 03:39:28 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <201906191618.x5JGIDWa018900@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B5B7B81FBD X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [0.60 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.58)[-0.584,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MX_INVALID(0.50)[greylisted]; NEURAL_SPAM_SHORT(0.62)[0.620,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_SPAM_LONG(0.16)[0.158,0]; IP_SCORE(0.00)[country: RU(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29072, ipnet:2a03:3100::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 20:39:51 -0000 19.06.2019 23:18, Rodney W. Grimes wrote: >> 19.06.2019 3:57, Ronald F. Guilmette wrote: >> >>> And god only knows how much will break once I've done that. >> >> IPv6 will break only. > > That is incorrect, scripts that would silently do nothing can > now infact fail, trust me, first hand experience. This can > have consequences beyong "IPv6 will break only". > >>> How many other >>> people have tested -all- of the resulting binaries, seriously, on actual >>> production systems? (I may be the first one ever, at least for 12.0.) >> >> I ran plenty of hosts with IPv6 disabled this way and no problems observed, but this pre-dates 12.0. > > I've not run a userland without V6 in a long time once I started to have > issues with some things. Can you give an example of such script in base system, please? If you have such script or binary not in our base, it's not our fault :-) From owner-freebsd-net@freebsd.org Wed Jun 19 20:51:16 2019 Return-Path: Delivered-To: freebsd-net@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 CCC2415C9DA6; Wed, 19 Jun 2019 20:51:16 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "eg.sd.rdtc.ru", Issuer "eg.sd.rdtc.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D415582663; Wed, 19 Jun 2019 20:51:15 +0000 (UTC) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-questions@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x5JKpAh6093581 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jun 2019 03:51:10 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Eliminating IPv6 (?) To: "Rodney W. Grimes" References: <201906191542.x5JFgQQ2018770@gndrsh.dnsmgr.net> Cc: "Ronald F. Guilmette" , freebsd-questions@freebsd.org, freebsd-net@freebsd.org From: Eugene Grosbein Message-ID: <1633b96e-15ba-9933-abea-46e7b4f0e6a2@grosbein.net> Date: Thu, 20 Jun 2019 03:51:01 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <201906191542.x5JFgQQ2018770@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: D415582663 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [0.63 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.60)[-0.599,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.62)[0.621,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; MX_INVALID(0.50)[cached]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_SPAM_LONG(0.20)[0.205,0]; IP_SCORE(0.00)[country: RU(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29072, ipnet:2a03:3100::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 20:51:17 -0000 19.06.2019 22:42, Rodney W. Grimes wrote: >> 18.06.2019 10:10, Ronald F. Guilmette wrote: >>> How can I turn off IPv6 entirely without rebuilding the kernel? >> You cannot. GENERIC kernel specifically enables IPv6 support and you need to disable it at compile time. >> And if you do, you better rebuild the world too using WITHOUT_INET6=yes in the /etc/src.conf >> or else some utilities compiled with INET6 by default will query kernel >> for IPv6-specific data (like routing entries) and complain that your kernel does not know about it. > I have not seen these issues, can you give a specific example that fails? Other than kernel/userland interaction (that may be not relevant anymore for modern FreeBSD), that's basically about making network connections (such as telnet etc.) to FQDNs resolved to IPv6 addresses supported by binaries (and resolver being userland beast) but not kernel/routing table. > A netstat -rn on a v4 only kernel simple reports the v4 table, and iirc a > netstat -rn6 returns a "Protocol not supported error" as should all other > things. >> World built WITHOUT_INET6 has no such rough edges. > I find that actually causes me more issues, as then my > netstat -rn6 returns a hard error due to: > case '6': > #ifdef INET6 > af = AF_INET6; > #else > errx(1, "IPv6 support is not compiled in"); > #endif Seems very logical to me. Do we have a script in base running "netstat -rn6" and breaking on this? From owner-freebsd-net@freebsd.org Wed Jun 19 20:52:24 2019 Return-Path: Delivered-To: freebsd-net@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 7D80D15C9E39 for ; Wed, 19 Jun 2019 20:52:24 +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 6FDD582919 for ; Wed, 19 Jun 2019 20:52:23 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id AEBB64E653; Wed, 19 Jun 2019 13:52:21 -0700 (PDT) From: "Ronald F. Guilmette" cc: freebsd-net Subject: Re: localhost woes -- help requested In-Reply-To: <74B7CCF0-967F-40B1-9818-3417CD8D1D72@punkt.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31009.1560977541.1@segfault.tristatelogic.com> Date: Wed, 19 Jun 2019 13:52:21 -0700 Message-ID: <31010.1560977541@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 6FDD582919 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 [-3.89 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.74)[ip: (-7.19), ipnet: 69.62.128.0/17(-3.60), asn: 14051(-2.84), country: US(-0.06)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; NEURAL_HAM_SHORT(-0.95)[-0.950,0]; MISSING_TO(2.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 20:52:24 -0000 In message <74B7CCF0-967F-40B1-9818-3417CD8D1D72@punkt.de>, "Patrick M. Hausen" wrote: >https://tools.ietf.org/html/rfc6761 Wow. Thanks for that. Quite certainly, 6.3 (part 1) is confirming that this is the way things are now, and have been, apparently since 2013. I really didn't know. Now I do. I'm not happy about it, but you can't fight City Hall. Regards, rfg From owner-freebsd-net@freebsd.org Wed Jun 19 21:01:00 2019 Return-Path: Delivered-To: freebsd-net@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 53E3815CA0E9; Wed, 19 Jun 2019 21:01:00 +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 64A8782C5E; Wed, 19 Jun 2019 21:00:59 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id E22524E653; Wed, 19 Jun 2019 14:00:52 -0700 (PDT) From: "Ronald F. Guilmette" To: FreeBSD Net , Mailinglists FreeBSD Subject: Re: Eliminating IPv6 (?) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31075.1560978052.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jun 2019 14:00:52 -0700 Message-ID: <31076.1560978052@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 64A8782C5E 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.90 / 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]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.76)[ip: (-7.24), ipnet: 69.62.128.0/17(-3.62), asn: 14051(-2.86), country: US(-0.06)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mx1.tristatelogic.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.93)[-0.935,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 21:01:00 -0000 In message Andreas Nilsson wrote: >> That is *not* what the Handbook says. Please read it. >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ip= fw.html >> >Ok, so the handbook is wrong. It's a bug in the documentation. ACK >As soon as set firewall_script instead of firewall_type your problems wil= l >be solved. Just try it. The man page for rc.conf will tell you the same >thing. ACK. Thank you for setting me straight. Regards, rfg From owner-freebsd-net@freebsd.org Wed Jun 19 23:23:05 2019 Return-Path: Delivered-To: freebsd-net@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 0848815CCE95; Wed, 19 Jun 2019 23:23:05 +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 CB79B87965; Wed, 19 Jun 2019 23:23:03 +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 x5JNMxvu020490; Wed, 19 Jun 2019 16:22:59 -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 x5JNMxpK020489; Wed, 19 Jun 2019 16:22:59 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906192322.x5JNMxpK020489@gndrsh.dnsmgr.net> Subject: Re: Eliminating IPv6 (?) In-Reply-To: <23818.36263.312034.714296@jerusalem.litteratus.org> To: Robert Huff Date: Wed, 19 Jun 2019 16:22:59 -0700 (PDT) CC: "Rodney W. Grimes" , freebsd-net , FreeBSD Questions Mailing List , "Ronald F. Guilmette" 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: CB79B87965 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.87 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.97)[0.968,0]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.96)[0.961,0]; NEURAL_SPAM_MEDIUM(0.01)[0.010,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 23:23:05 -0000 > Rodney W. Grimes writes: > > > > And god only knows how much will break once I've done that. How many other > > > people have tested -all- of the resulting binaries, seriously, on actual > > > production systems? (I may be the first one ever, at least for 12.0.) > > > > I also agree here, running a WITHOUT_IPV6 userland is both very > > painful to get built AND has issues that one does not need to face, > > like I showed in another thread about netstat -6. > > Wider question: > Say I'm running a system with both IPv4 and IPv6 enabled. > Stuff Happens(tm) and I want to completely disable IPv6 for some > indefinite but temporary period - not chamge any configuration > settings or firewall rules, but just have the code finish processing > current packets (or not) and then ignore further traffic. There will > be consequences; I'm prepared to accept them. > Is there a single master switch - a sysctl, perhaps, or something > in /etc/rc.d - that lets me do that? You do raise a very valid point. ipfw add 1 deny ipv6 from any to any That is about the only "master" switch I can think of that would be very effective. > Robert Huff -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jun 19 23:32:31 2019 Return-Path: Delivered-To: freebsd-net@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 8F18E15CD33C; Wed, 19 Jun 2019 23:32:31 +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 D14B4880CC; Wed, 19 Jun 2019 23:32:30 +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 x5JNWRQE020512; Wed, 19 Jun 2019 16:32:27 -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 x5JNWQxB020511; Wed, 19 Jun 2019 16:32:26 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906192332.x5JNWQxB020511@gndrsh.dnsmgr.net> Subject: Re: Eliminating IPv6 (?) In-Reply-To: <42461287-c282-697e-6a21-571212dff832@grosbein.net> To: Eugene Grosbein Date: Wed, 19 Jun 2019 16:32:26 -0700 (PDT) CC: "Rodney W. Grimes" , freebsd-net , FreeBSD Questions Mailing List , "Ronald F. Guilmette" 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: D14B4880CC X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.58 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.25)[-0.247,0]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.960,0]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.94)[0.937,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 23:32:31 -0000 > 19.06.2019 23:18, Rodney W. Grimes wrote: > > >> 19.06.2019 3:57, Ronald F. Guilmette wrote: > >> > >>> And god only knows how much will break once I've done that. > >> > >> IPv6 will break only. > > > > That is incorrect, scripts that would silently do nothing can > > now infact fail, trust me, first hand experience. This can > > have consequences beyong "IPv6 will break only". > > > >>> How many other > >>> people have tested -all- of the resulting binaries, seriously, on actual > >>> production systems? (I may be the first one ever, at least for 12.0.) > >> > >> I ran plenty of hosts with IPv6 disabled this way and no problems observed, but this pre-dates 12.0. > > > > I've not run a userland without V6 in a long time once I started to have > > issues with some things. > > Can you give an example of such script in base system, please? > > If you have such script or binary not in our base, it's not our fault :-) That is an extremly aragant position to take. Your basically saying that only the base system scripts have to function correctly and that any script not part of the base system has no need to be supported. Go tell this to the ports people... *sigh* -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jun 19 23:35:49 2019 Return-Path: Delivered-To: freebsd-net@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 8DB1615CD544; Wed, 19 Jun 2019 23:35:49 +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 9A7598837E; Wed, 19 Jun 2019 23:35:48 +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 x5JNZk6k020542; Wed, 19 Jun 2019 16:35:46 -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 x5JNZkBd020541; Wed, 19 Jun 2019 16:35:46 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906192335.x5JNZkBd020541@gndrsh.dnsmgr.net> Subject: Re: Eliminating IPv6 (?) In-Reply-To: <1633b96e-15ba-9933-abea-46e7b4f0e6a2@grosbein.net> To: Eugene Grosbein Date: Wed, 19 Jun 2019 16:35:46 -0700 (PDT) CC: "Rodney W. Grimes" , freebsd-net@freebsd.org, freebsd-questions@freebsd.org, "Ronald F. Guilmette" 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: 9A7598837E X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.87 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.97)[0.969,0]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.96)[0.962,0]; NEURAL_SPAM_MEDIUM(0.01)[0.012,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 23:35:49 -0000 > 19.06.2019 22:42, Rodney W. Grimes wrote: > > >> 18.06.2019 10:10, Ronald F. Guilmette wrote: > >>> How can I turn off IPv6 entirely without rebuilding the kernel? > >> You cannot. GENERIC kernel specifically enables IPv6 support and you need to disable it at compile time. > >> And if you do, you better rebuild the world too using WITHOUT_INET6=yes in the /etc/src.conf > >> or else some utilities compiled with INET6 by default will query kernel > >> for IPv6-specific data (like routing entries) and complain that your kernel does not know about it. > > I have not seen these issues, can you give a specific example that fails? > > Other than kernel/userland interaction (that may be not relevant anymore for modern FreeBSD), > that's basically about making network connections (such as telnet etc.) > to FQDNs resolved to IPv6 addresses supported by binaries (and resolver being userland beast) > but not kernel/routing table. > > > A netstat -rn on a v4 only kernel simple reports the v4 table, and iirc a > > netstat -rn6 returns a "Protocol not supported error" as should all other > > things. > >> World built WITHOUT_INET6 has no such rough edges. > > I find that actually causes me more issues, as then my > > netstat -rn6 returns a hard error due to: > > case '6': > > #ifdef INET6 > > af = AF_INET6; > > #else > > errx(1, "IPv6 support is not compiled in"); > > #endif > > Seems very logical to me. Do we have a script in base running "netstat -rn6" > and breaking on this? Again, why does it need to be in base? Since when was that the standard by which we measure proper function? Basically the above #else is probably not the best of ideas... silently ignoring the -6 would of been a more gracefull solution possibly. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jun 19 23:37:51 2019 Return-Path: Delivered-To: freebsd-net@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 7D95215CD696; Wed, 19 Jun 2019 23:37:51 +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 A9603884F2; Wed, 19 Jun 2019 23:37:50 +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 x5JNbm2C020559; Wed, 19 Jun 2019 16:37:48 -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 x5JNbmRi020558; Wed, 19 Jun 2019 16:37:48 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906192337.x5JNbmRi020558@gndrsh.dnsmgr.net> Subject: Re: Eliminating IPv6 (?) In-Reply-To: <31076.1560978052@segfault.tristatelogic.com> To: "Ronald F. Guilmette" Date: Wed, 19 Jun 2019 16:37:48 -0700 (PDT) CC: FreeBSD Net , Mailinglists FreeBSD 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: A9603884F2 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.18 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.59)[-0.594,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.96)[0.956,0]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.89)[0.888,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 23:37:51 -0000 > In message > Andreas Nilsson wrote: > > >> That is *not* what the Handbook says. Please read it. > >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html > >> > >Ok, so the handbook is wrong. It's a bug in the documentation. > > ACK Probably should just eliminate the firewall_type="/path/to/rules" thing, as that can be done with firewall_script and that does the right thing here. > >As soon as set firewall_script instead of firewall_type your problems will > >be solved. Just try it. The man page for rc.conf will tell you the same > >thing. > > ACK. Thank you for setting me straight. Your not wrong either. There are bugs here. > Regards, > rfg -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jun 19 23:39:34 2019 Return-Path: Delivered-To: freebsd-net@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 DA3FB15CD855; Wed, 19 Jun 2019 23:39:33 +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 1123288694; Wed, 19 Jun 2019 23:39:32 +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 x5JNdVfX020575; Wed, 19 Jun 2019 16:39:31 -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 x5JNdVYZ020574; Wed, 19 Jun 2019 16:39:31 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201906192339.x5JNdVYZ020574@gndrsh.dnsmgr.net> Subject: Re: Eliminating IPv6 (?) In-Reply-To: <1633b96e-15ba-9933-abea-46e7b4f0e6a2@grosbein.net> To: Eugene Grosbein Date: Wed, 19 Jun 2019 16:39:31 -0700 (PDT) CC: "Rodney W. Grimes" , "Ronald F. Guilmette" , freebsd-questions@freebsd.org, freebsd-net@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: 1123288694 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.84 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.02)[-0.019,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.97)[0.966,0]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.06)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.96)[0.958,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 23:39:34 -0000 [ Charset windows-1252 unsupported, converting... ] > 19.06.2019 22:42, Rodney W. Grimes wrote: > > >> 18.06.2019 10:10, Ronald F. Guilmette wrote: > >>> How can I turn off IPv6 entirely without rebuilding the kernel? > >> You cannot. GENERIC kernel specifically enables IPv6 support and you need to disable it at compile time. > >> And if you do, you better rebuild the world too using WITHOUT_INET6=yes in the /etc/src.conf > >> or else some utilities compiled with INET6 by default will query kernel > >> for IPv6-specific data (like routing entries) and complain that your kernel does not know about it. > > I have not seen these issues, can you give a specific example that fails? > > Other than kernel/userland interaction (that may be not relevant anymore for modern FreeBSD), > that's basically about making network connections (such as telnet etc.) > to FQDNs resolved to IPv6 addresses supported by binaries (and resolver being userland beast) > but not kernel/routing table. > > > A netstat -rn on a v4 only kernel simple reports the v4 table, and iirc a > > netstat -rn6 returns a "Protocol not supported error" as should all other > > things. > >> World built WITHOUT_INET6 has no such rough edges. > > I find that actually causes me more issues, as then my > > netstat -rn6 returns a hard error due to: > > case '6': > > #ifdef INET6 > > af = AF_INET6; > > #else > > errx(1, "IPv6 support is not compiled in"); > > #endif > > Seems very logical to me. Do we have a script in base running "netstat -rn6" > and breaking on this? Actually that would be more proper as: #ifdef INET6 case '6': af = AF_INET6; #endif With similiar adjustments to the usage message, if needed. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Thu Jun 20 02:58:08 2019 Return-Path: Delivered-To: freebsd-net@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 2BEB715D1BDB for ; Thu, 20 Jun 2019 02:58:08 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 A69948E392 for ; Thu, 20 Jun 2019 02:58:07 +0000 (UTC) (envelope-from roberthuff@rcn.com) DKIM-Signature: v=1; a=rsa-sha1; d=rcn.com; s=20180516; c=relaxed/simple; q=dns/txt; i=@rcn.com; t=1560999485; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=+5Ymq7hzRvugjRfCDROyMBRgByc=; b=a9d+h2nx2kRc6Gg3lLQrT54n8OcfW2lLAFS341KcmpnRrM5yCz05/7zOH4olpkdy YV1T/stcrvxNyikno8D5o+jRkOYB/ebjcdW1XtRPCmNuXJmjX8YLTCpV+XItpq1N 7WhG9G85oT8DEsuSx0A3+zTHSHXhaGsnKz/l/QXO4I+A+z4H2ojmpt5OIKneI9se ylP+ts2W5dhEKCNf9/wlCGFN4aB34vG+hz0JaWjFtmmTN1f6FNxDV4XbdICh2Xa6 +cZCle9LdvfpuBKIBCtFXSio5idWRosLxSpk8dHOLnBVPW+g+ZKX0wxbzzsY4abr 9kurmv+JJrX5UxW27bzRXA==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=aKGykv1m c=1 sm=1 tr=0 a=9TgA2UwI6Wy+6BV4wQM/cQ==:117 a=9TgA2UwI6Wy+6BV4wQM/cQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=KGjhK52YXX0A:10 a=kj9zAlcOel0A:10 a=XRQyMpdBKAEA:10 a=dq6fvYVFJ5YA:10 a=48faUk6PgeAA:10 a=TeW0tiTjp0bHKsuJq68A:9 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Authentication-Results: smtp03.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=softfail Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.user=roberthuff; auth=pass (PLAIN) Received: from [209.6.230.48] ([209.6.230.48:41368] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=AES256-GCM-SHA384) id B8/D6-13517-D36FA0D5; Wed, 19 Jun 2019 22:58:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23818.63036.888460.410557@jerusalem.litteratus.org> Date: Wed, 19 Jun 2019 22:58:04 -0400 From: Robert Huff To: "Rodney W. Grimes" Cc: Robert Huff , freebsd-net , FreeBSD Questions Mailing List , "Ronald F. Guilmette" Subject: Re: Eliminating IPv6 (?) In-Reply-To: <201906192322.x5JNMxpK020489@gndrsh.dnsmgr.net> References: <23818.36263.312034.714296@jerusalem.litteratus.org> <201906192322.x5JNMxpK020489@gndrsh.dnsmgr.net> X-Mailer: VM 8.2.0b under 26.2 (amd64-portbld-freebsd13.0) X-Rspamd-Queue-Id: A69948E392 X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rcn.com header.s=20180516 header.b=a9d+h2nx; dmarc=pass (policy=none) header.from=rcn.com; spf=pass (mx1.freebsd.org: domain of roberthuff@rcn.com designates 69.168.97.78 as permitted sender) smtp.mailfrom=roberthuff@rcn.com X-Spamd-Result: default: False [-7.88 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[rcn.com:s=20180516]; RCVD_IN_DNSWL_LOW(-0.10)[78.97.168.69.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:69.168.97.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; DWL_DNSWL_LOW(-1.00)[rcn.com.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[rcn.com:+]; DMARC_POLICY_ALLOW(-0.50)[rcn.com,none]; MX_GOOD(-0.01)[cached: mx.rcn.com]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.78)[ip: (-9.32), ipnet: 69.168.97.0/24(-4.60), asn: 36271(0.07), country: US(-0.06)]; ASN(0.00)[asn:36271, ipnet:69.168.97.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 02:58:08 -0000 Rodney W. Grimes writes: > > Wider question: > > Say I'm running a system with both IPv4 and IPv6 enabled. > > Stuff Happens(tm) and I want to completely disable IPv6 for some > > indefinite but temporary period - not chamge any configuration > > settings or firewall rules, but just have the code finish processing > > current packets (or not) and then ignore further traffic. There will > > be consequences; I'm prepared to accept them. > > Is there a single master switch - a sysctl, perhaps, or something > > in /etc/rc.d - that lets me do that? > > You do raise a very valid point. > > ipfw add 1 deny ipv6 from any to any > > That is about the only "master" switch I can think of that would > be very effective. Ywah ... but that violates the initial constraint. Respectfully, Robert Huff From owner-freebsd-net@freebsd.org Thu Jun 20 04:17:31 2019 Return-Path: Delivered-To: freebsd-net@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 CDD6515D33F8; Thu, 20 Jun 2019 04:17:31 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "eg.sd.rdtc.ru", Issuer "eg.sd.rdtc.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CCB9869EA3; Thu, 20 Jun 2019 04:17:20 +0000 (UTC) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-net@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x5K4H9Dr097525 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jun 2019 11:17:09 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Eliminating IPv6 (?) To: "Rodney W. Grimes" References: <201906192332.x5JNWQxB020511@gndrsh.dnsmgr.net> Cc: freebsd-net , FreeBSD Questions Mailing List , "Ronald F. Guilmette" From: Eugene Grosbein Message-ID: <94c95322-700e-422f-1358-19d577a8b15c@grosbein.net> Date: Thu, 20 Jun 2019 11:17:00 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <201906192332.x5JNWQxB020511@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: CCB9869EA3 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [0.74 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.57)[-0.575,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MX_INVALID(0.50)[greylisted]; NEURAL_SPAM_SHORT(0.74)[0.739,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_SPAM_LONG(0.17)[0.174,0]; IP_SCORE(0.00)[country: RU(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29072, ipnet:2a03:3100::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 04:17:32 -0000 20.06.2019 6:32, Rodney W. Grimes wrote: >>> I've not run a userland without V6 in a long time once I started to have >>> issues with some things. >> >> Can you give an example of such script in base system, please? >> >> If you have such script or binary not in our base, it's not our fault :-) > > That is an extremly aragant position to take. Your basically saying that > only the base system scripts have to function correctly and that any > script not part of the base system has no need to be supported. > > Go tell this to the ports people... *sigh* I'm saying that areas of responsibility should be denoted. If there is some script in the world written with bad assumptions, its author/maintainer is responsible in fixing it. FreeBSD already provides sysctls kern.features.inet and kern.features.inet6 to make it easier for scripts. From owner-freebsd-net@freebsd.org Thu Jun 20 07:56:01 2019 Return-Path: Delivered-To: freebsd-net@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 3DCE215D6A42 for ; Thu, 20 Jun 2019 07:56:01 +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 C4BCB6FBFB for ; Thu, 20 Jun 2019 07:56:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8687115D6A41; Thu, 20 Jun 2019 07:56:00 +0000 (UTC) Delivered-To: net@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 7457815D6A40 for ; Thu, 20 Jun 2019 07:56:00 +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 106246FBF9 for ; Thu, 20 Jun 2019 07:56:00 +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 63E829B2E for ; Thu, 20 Jun 2019 07:55:59 +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 x5K7tx4L035017 for ; Thu, 20 Jun 2019 07:55:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5K7txkF035016 for net@FreeBSD.org; Thu, 20 Jun 2019 07:55:59 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: net@FreeBSD.org Subject: [Bug 235959] DSACK not working Date: Thu, 20 Jun 2019 07:55:59 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: tuexen@freebsd.org X-Bugzilla-Flags: mfc-stable12+ X-Bugzilla-Changed-Fields: flagtypes.name bug_status resolution 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 07:56:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235959 Michael Tuexen changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |mfc-stable12+ Status|New |Closed Resolution|--- |FIXED --- Comment #1 from Michael Tuexen --- This is fixed by: https://svnweb.freebsd.org/changeset/base/347382 https://svnweb.freebsd.org/changeset/base/348728 and it was MFCed to stable/12 in https://svnweb.freebsd.org/changeset/base/347902 https://svnweb.freebsd.org/changeset/base/349226 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Thu Jun 20 09:54:27 2019 Return-Path: Delivered-To: freebsd-net@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 5287515B4111 for ; Thu, 20 Jun 2019 09:54:27 +0000 (UTC) (envelope-from christian.marcos@gmail.com) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 6A9D773132 for ; Thu, 20 Jun 2019 09:54:26 +0000 (UTC) (envelope-from christian.marcos@gmail.com) Received: by mail-io1-xd2d.google.com with SMTP id e5so528491iok.4 for ; Thu, 20 Jun 2019 02:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=e2a5ecMc5WDZgzASgIcd+J0miHHpTNzwufdsTiRLds0=; b=F5XNinhpquGAZxz5f2eG0P8zd3Y2Jt7DJM3QfGAwFj2g7yzg8XM7tTk6t8Dt48fFgj ES3xk+ok74XFe9J8tHSBK/PPbpDGNw1BhS1ddlWplWPA70WyaQMELxG0q0EsIb1Qo+cQ vfiHDvkqQEavrgAh8Akzv5xrffGRIX+uTjuWUZMXycTC5hNKGh4brR0/7TTPshf+bRwd 8CAeiM0/EKcHvJB/wDt543ARyJUC+OUxFrUuwNZMZ4xfSllQ/URgR1w6RzRhzCaucB7r RTlSXMwOm3NRuYUCkAi4zRjut/LIc1lKKuHL5e9ojR4qmPMYqryJLfnZAwGUm2tB/j8F MEMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=e2a5ecMc5WDZgzASgIcd+J0miHHpTNzwufdsTiRLds0=; b=PguJujsWI+Qb6F86M4f3gZ5Cziax+MhDQ+ND/41IFn9Rvzwn/juusdOk+N4Sy9hsiZ SOtPc3m68wV6bDlXRg49L5OdoxyNj3GcgJT5WdeDGn0A1rRKfz00QM3UY3p96BJe0l/k bUmLaCkS9caSi0hYgemKgivl/zIOcH9s2/Ic8jisOQrow/3DniDM5/eeYUkZuPhCWGXe CkN/cIuvXNotuydhBZ5WK7qOZMAFO/K9lIbo5wuoreG2ckKtwhlfilcmG1a94B5lCLHK xDmy6qzdOPnFYDOA6eksMZNuMzhRc9Q7asC3ahZ7kQ4nWciBBdLoFcMbAi9IN13Piw7e YA5Q== X-Gm-Message-State: APjAAAU56S7Wf8OpAm9fuYfCBwTDbdCaxifUc+hhgsySbcAN94LrLod2 RRfAmOKhcFK6rbLTgC+zpCQowukn6xhGIXS+Z6AHzPPK X-Google-Smtp-Source: APXvYqwDioRn5xTJCk4lh13thUbOnR7Ih7eD0HtlyjE7bdnBgjG2adXoQ73e9n4uQNUPlDZ8vIpGIFpDEYELchJjHTI= X-Received: by 2002:a6b:2cc7:: with SMTP id s190mr14664500ios.29.1561024465282; Thu, 20 Jun 2019 02:54:25 -0700 (PDT) MIME-Version: 1.0 From: Christian M Date: Thu, 20 Jun 2019 11:54:14 +0200 Message-ID: Subject: Very slow and inconsistent internal network speed (between VM's on the same host) for FreeBSD 11.0+ as guest on XCP-ng/XenServer To: freebsd-net@freebsd.org X-Rspamd-Queue-Id: 6A9D773132 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=F5XNinhp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of christianmarcos@gmail.com designates 2607:f8b0:4864:20::d2d as permitted sender) smtp.mailfrom=christianmarcos@gmail.com X-Spamd-Result: default: False [-6.93 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.96)[-0.964,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.95)[ip: (-9.26), ipnet: 2607:f8b0::/32(-3.14), asn: 15169(-2.31), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[d.2.d.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_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 09:54:27 -0000 Hi. I posted this on freebsd-xen also, but I begin to believe that list is more for Xen on FreeBSD, not FreeBSD on Xen. Anyway, I've noticed that networking speed between FreeBSD VM's on the same host (XCP-ng 7.6.0) for more recent FreeBSD-versions is very slow and inconsistent between FreeBSD versions. I've made some tests that show me that something happened from 10.4-RELEASE to 11.0-RELEASE that had a huge impact on network performance, and 12.0-RELEASE is even slower. My test setup: Host: XCP-ng 7.6.0, managed with XenOrchestra. Open source. Network: Internal Private Network on the host (not connected to a PIF). Each VM has only one VIF connected to this network. VM's: 2 x 12.0-RELEASE 2 x 11.0-RELEASE 2 x 10.4-RELEASE All clean identical installs from XenOrchestra, only installed iperf on each VM for testing. (xe-guest-utilities makes no difference in my tests, I've tried with and without). iperf -s on first server listed below, and iperf -c -r on the second to test speed back and forth: 12.0 <-> 12.0: 50Mbit as client and server 12.0 <-> 11.0: 800Mbit/s (11.0 as client), and 140Mbit/s (11.0 as server) 12.0 <-> 10.4: 2.76Gbit (10.4 as client), and 1.25Gbit (10.4 as server). 11.0 <-> 11.0: 219Mbit as client, 99Mbit as server 10.4 <-> 10.4: 11.2Gbit as client, 10.9Gbit as server As I side note, not sure if related, but I've noticed that I can't run iperf with -r flag on 10.4-RELEASE. I get this error message: iperf -c 172.31.16.122 -r ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ write failed: Broken pipe ------------------------------------------------------------ Client connecting to 172.31.16.122, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 5] local 172.31.16.121 port 19231 connected with 172.31.16.122 port 5001 [ ID] Interval Transfer Bandwidth [ 5] 0.0- 0.0 sec 0.00 Bytes 0.00 bits/sec I can run iperf -s fine, and iperf -c from the other 10.4 VM though: iperf -c 172.31.16.122 ------------------------------------------------------------ Client connecting to 172.31.16.122, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 172.31.16.121 port 22055 connected with 172.31.16.122 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 12.9 GBytes 11.1 Gbits/sec What have I tried to solve this? I've tried to disable checksum offloading for the 12.0-RELEASE VIF's via XCP-ng. Disabled basically everything without any difference in iperf results: other-config (MRW): ethtool-sg: off; ethtool-tso: off; ethtool-ufo: off; ethtool-gso: off; ethtool-rx: off; ethtool-tx: off Also tried disabling offloading in FreeBSD with ifconfig xn0 -txcsum -rxcsum -tso -lro and no difference here either. Any ideas of how to proceed now to find a solution for this? Regards, Christian From owner-freebsd-net@freebsd.org Thu Jun 20 13:37:41 2019 Return-Path: Delivered-To: freebsd-net@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 7A4ED15BBE90 for ; Thu, 20 Jun 2019 13:37:41 +0000 (UTC) (envelope-from prvs=30742a222d=akhoje@marvell.com) 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 CCAE481989 for ; Thu, 20 Jun 2019 13:37:40 +0000 (UTC) (envelope-from prvs=30742a222d=akhoje@marvell.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9028215BBE8F; Thu, 20 Jun 2019 13:37:40 +0000 (UTC) Delivered-To: net@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 5552115BBE8E for ; Thu, 20 Jun 2019 13:37:40 +0000 (UTC) (envelope-from prvs=30742a222d=akhoje@marvell.com) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 E3C6081988 for ; Thu, 20 Jun 2019 13:37:38 +0000 (UTC) (envelope-from prvs=30742a222d=akhoje@marvell.com) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5KDQGjD007819 for ; Thu, 20 Jun 2019 06:37:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : subject : date : message-id : content-type : mime-version; s=pfpt0818; bh=z7EEGZUJ6eMQ6H2YMOxj5p1WUBieWsaIZm7JZ4KBcTQ=; b=b7HgYm23ys7QAnaqhUB0Jx7RgZAFPzeBOk7RQGGZJaP+VWldj04V7fqZMIaCbT8Phg+P jt/kCE6MwwsvpuV0oDSYYUqOoeibm6F9NBhFdiR+4yxK1F9+qp7rkaLsDy5yv5zBC2r4 Rnya9vvvTQNhOuQGo8WWNbPTjMmd+H715TCY0RON44O7oNVWyKE+u85vgjCabMvEkZnk zhhmkSWInmUqEehlyEkWsER2RtmTiHJIFIcj3hgxEiIaFq0zIl6rEhirGMa4mqfhBbk6 io6Ik8IgzLM6eaXnXogMmmOniuRtf6t/nWj2OxCQ0ZtJvARzDPpUSvIz0sEx8qfmVVcn rg== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0a-0016f401.pphosted.com with ESMTP id 2t861v94cc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 20 Jun 2019 06:37:30 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 20 Jun 2019 06:37:29 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (104.47.34.58) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 20 Jun 2019 06:37:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z7EEGZUJ6eMQ6H2YMOxj5p1WUBieWsaIZm7JZ4KBcTQ=; b=wr1YcGPgwKn01zvB06DxlIzKo5Vh3Vay0yfAgNRkqtp3/KHJYr5p5sTpWIcQQx5FKtmAvT0nLKEg7SWGe++F75hDpCvoEgNRt1OBntTSKZfGI4Z3d5dvaOPXsUOWbvJemfV1OXFdpUiHjsKOmpJXRJ5/tSVqVMYYOdmoM+YAHdw= Received: from MN2PR18MB2925.namprd18.prod.outlook.com (20.179.20.17) by MN2PR18MB2863.namprd18.prod.outlook.com (20.179.21.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.12; Thu, 20 Jun 2019 13:37:25 +0000 Received: from MN2PR18MB2925.namprd18.prod.outlook.com ([fe80::b47b:e844:4d4a:c4d5]) by MN2PR18MB2925.namprd18.prod.outlook.com ([fe80::b47b:e844:4d4a:c4d5%6]) with mapi id 15.20.2008.007; Thu, 20 Jun 2019 13:37:24 +0000 From: Anand Khoje To: "net@FreeBSD.org" Subject: Qlogic FastLinq 45xxx driver Patch for upstream Thread-Topic: Qlogic FastLinq 45xxx driver Patch for upstream Thread-Index: AdUnK+M6F2luYYpkTyi8aYlAyA9luQ== Date: Thu, 20 Jun 2019 13:37:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [103.9.74.163] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 45de3c6e-a009-4c14-7e35-08d6f5846dee x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:MN2PR18MB2863; x-ms-traffictypediagnostic: MN2PR18MB2863: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0074BBE012 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(346002)(39850400004)(396003)(189003)(199004)(66066001)(7696005)(45080400002)(99286004)(14454004)(102836004)(6506007)(68736007)(256004)(5024004)(86362001)(478600001)(71200400001)(4744005)(5660300002)(52536014)(2351001)(6916009)(66616009)(6306002)(66476007)(66556008)(73956011)(64756008)(3846002)(6116002)(790700001)(66946007)(6436002)(55016002)(33656002)(486006)(476003)(316002)(9686003)(5640700003)(71190400001)(186003)(26005)(99936001)(74316002)(54896002)(8676002)(9326002)(1730700003)(81156014)(76116006)(66446008)(81166006)(25786009)(8936002)(2501003)(7736002)(53936002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB2863; H:MN2PR18MB2925.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AbuMmfwnooT0pY1Fn27zW4UJY0Fvbp9/ynIvrYGh3A5XRua3lezPAIQnLh/ZPh5qnkbM7Uv4JmLLoxkrgwNuyGruP+HseDIL0WTy6nDfExkgjg3hjmh4Ct+CCOTa3EJNme4ULAY7zGwJcnQrnID23terynupjjq0FIOwUQXbrZMoTc987T1aSqzwH1cA20UNphpusQXbkuWBEADHbTHPFz8fodR/zr/tIN3jt3G0NLpZisjTuuAZdz3riHSnFMTZxgOqnU9Qx0BJ6HFjs+yACk9tqjJ/w+Exxb1WtfcpEfcT2CFcltRGtXje+R/uBmAiqLKoset5u8yYBmg5ogA46PUThNTmllvm/O6zB9EyBObSpLTS2XH05JhOdm1C3OFiY3OnWVm9HfNmjafbGZQAyzFe1dIEoV1Edk0LQo3te18= Content-Type: multipart/mixed; boundary="_004_MN2PR18MB292562BE6514ED60A12F4CBFDAE40MN2PR18MB2925namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 45de3c6e-a009-4c14-7e35-08d6f5846dee X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2019 13:37:24.6899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: akhoje@marvell.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB2863 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-20_09:, , signatures=0 X-Rspamd-Queue-Id: E3C6081988 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=marvell.com header.s=pfpt0818 header.b=b7HgYm23; dkim=pass header.d=marvell.onmicrosoft.com header.s=selector2-marvell-onmicrosoft-com header.b=wr1YcGPg; dmarc=pass (policy=none) header.from=marvell.com; spf=pass (mx1.freebsd.org: domain of prvs=30742a222d=akhoje@marvell.com designates 67.231.148.174 as permitted sender) smtp.mailfrom=prvs=30742a222d=akhoje@marvell.com X-Spamd-Result: default: False [-6.41 / 15.00]; HAS_XOIP(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:67.231.148.174]; ENVFROM_PRVS(0.00)[]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[marvell.com:+,marvell.onmicrosoft.com:+]; MX_GOOD(-0.01)[mxb-0016f401.gslb.pphosted.com,mxa-0016f401.gslb.pphosted.com]; DMARC_POLICY_ALLOW(-0.50)[marvell.com,none]; NEURAL_HAM_SHORT(-0.98)[-0.975,0]; FORGED_SENDER(0.00)[akhoje@marvell.com,prvs=30742a222d=akhoje@marvell.com]; RCVD_IN_DNSWL_LOW(-0.10)[174.148.231.67.list.dnswl.org : 127.0.3.1]; IP_SCORE(-2.33)[ip: (-8.91), ipnet: 67.231.148.0/24(-2.57), asn: 26211(-0.10), country: US(-0.06)]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:26211, ipnet:67.231.148.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[akhoje@marvell.com,prvs=30742a222d=akhoje@marvell.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[marvell.com:s=pfpt0818,marvell.onmicrosoft.com:s=selector2-marvell-onmicrosoft-com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[net@freebsd.org]; FORGED_SENDER_VERP_SRS(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_COUNT_SEVEN(0.00)[7] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 13:37:41 -0000 --_004_MN2PR18MB292562BE6514ED60A12F4CBFDAE40MN2PR18MB2925namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have a patch with fix for an issue raised by Microsoft : "FreeBSD 11.2 - Kernel panic when flapping network interfaces on and off" . The issue was observed when the customer was trying to flap interface on an= d off in a loop more than 20 times. After investigation, it was found that = panic occurred due to a thread sleeping while holding a mutex after a calli= ng function pause(). I have attached the patch that has to be submitted upstream. Please let me = know if I need to add someone for reviewing it. Also, please let me know if= you have any questions. Thank you, Anand A. Khoje --_004_MN2PR18MB292562BE6514ED60A12F4CBFDAE40MN2PR18MB2925namp_ Content-Type: application/octet-stream; name="qlnx_v2.1.112_microsoft.patch" Content-Description: qlnx_v2.1.112_microsoft.patch Content-Disposition: attachment; filename="qlnx_v2.1.112_microsoft.patch"; size=863; creation-date="Thu, 20 Jun 2019 13:35:14 GMT"; modification-date="Thu, 20 Jun 2019 13:35:14 GMT" Content-Transfer-Encoding: base64 ZGlmZiAtdWFyIHFsbnhfdjIuMC4xMTIvcWxueGUvcWxueF9vcy5oIHFsbnhfdjIuMS4xMTIvcWxu eGUvcWxueF9vcy5oCi0tLSBxbG54X3YyLjAuMTEyL3FsbnhlL3Fsbnhfb3MuaAkyMDE4LTA3LTEz IDIwOjI1OjQ1LjAwMDAwMDAwMCArMDUzMAorKysgcWxueF92Mi4xLjExMi9xbG54ZS9xbG54X29z LmgJMjAxOS0wNC0wNCAwOTo0MDozNy41NDMwMTEwMDAgKzA1MzAKQEAgLTEzMSwxNCArMTMxLDgg QEAKIAogTUFMTE9DX0RFQ0xBUkUoTV9RTE5YQlVGKTsKIAotI2RlZmluZSBxbG54X21kZWxheShm biwgbXNlY3MpCVwKLQl7XAotCQlpZiAoY29sZCkgXAotCQkJREVMQVkoKG1zZWNzICogMTAwMCkp OyBcCi0JCWVsc2UgIFwKLQkJCXBhdXNlKGZuLCBxbG54X21zX3RvX2h6KG1zZWNzKSk7IFwKLQl9 Ci0JCisjZGVmaW5lIHFsbnhfbWRlbGF5KGZuLCBtc2VjcykJREVMQVkoKG1zZWNzICogMTAwMCkp OwkKKwogLyoKICAqIExvY2tzCiAgKi8KZGlmZiAtdWFyIHFsbnhfdjIuMC4xMTIvcWxueGUvcWxu eF92ZXIuaCBxbG54X3YyLjEuMTEyL3FsbnhlL3FsbnhfdmVyLmgKLS0tIHFsbnhfdjIuMC4xMTIv cWxueGUvcWxueF92ZXIuaAkyMDE4LTA3LTEzIDIwOjI1OjQ1LjAwMDAwMDAwMCArMDUzMAorKysg cWxueF92Mi4xLjExMi9xbG54ZS9xbG54X3Zlci5oCTIwMTktMDQtMDMgMjE6NTM6MDIuOTcxNDQ2 MDAwICswNTMwCkBAIC0zOCw2ICszOCw2IEBACiAgKi8KIAogI2RlZmluZSBRTE5YX1ZFUlNJT05f TUFKT1IgICAgICAyCi0jZGVmaW5lIFFMTlhfVkVSU0lPTl9NSU5PUiAgICAgIDAKKyNkZWZpbmUg UUxOWF9WRVJTSU9OX01JTk9SICAgICAgMQogI2RlZmluZSBRTE5YX1ZFUlNJT05fQlVJTEQgICAg ICAxMTIKIAo= --_004_MN2PR18MB292562BE6514ED60A12F4CBFDAE40MN2PR18MB2925namp_-- From owner-freebsd-net@freebsd.org Thu Jun 20 14:09:33 2019 Return-Path: Delivered-To: freebsd-net@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 87FB115BCCA9 for ; Thu, 20 Jun 2019 14:09:33 +0000 (UTC) (envelope-from asomers@gmail.com) 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 6C78E82D51 for ; Thu, 20 Jun 2019 14:09:32 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2A96D15BCCA8; Thu, 20 Jun 2019 14:09:32 +0000 (UTC) Delivered-To: net@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 17C6B15BCCA7 for ; Thu, 20 Jun 2019 14:09:32 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 755FA82D4F; Thu, 20 Jun 2019 14:09:31 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-x244.google.com with SMTP id i21so2851924ljj.3; Thu, 20 Jun 2019 07:09:31 -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=w62PgITocCT13FSaWhcnPqUdRV4JO3MONImk6y8RM0Y=; b=MyYraWYsmB68n4AdHlZr4pwfHl/uz/kDFFMRHbP7l/Fa645gjhYGL57BV1V4Mjt5p/ jXTWlj+AEAwMix45rtRJMlSmKYIDxij9XQC9eO40LDsQgE7vWyPWPVANkV5cNl0jOcGE wEm/mJis57qGSUC0V2JDjIu3/7Su96yD44uhNQDto7+mS1hy10dhv5gQQO6G9HKf5+hd VHFk6awMFMIfWd7zntTp597D05oaSy/j67oBuLnTrKQmdSrF3YBs3pfhA/iG08K3doU4 Kaf4nQuDqJho9xVs/1SnvsQuLDk9qXuVWEdpiZS3W8rIpKNM/8+9JzSZjs2Fh1A3iIt2 wpYw== 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=w62PgITocCT13FSaWhcnPqUdRV4JO3MONImk6y8RM0Y=; b=mYL2/Ok++8v6Qrw2jSO9u2SMCG0Cxf3lKsbYNZpUBFc3uUjjSyuHZOBPJQIHAYvrkX YoggzoFV3eTafSXhrKWg0Qf0viJbrDgFc8bgtFB4Af/P9owHMp6ec1vn/UYLP+PYaF0e vbi20OhGS/i2P1YUKrlQCV6VXDuJn77W08X86XBHL593Y8+CvfpTvN40MPeOGqKnZpn7 BvKQdPezBb3yryDj4XcDRppdxPYJ1575PSmNzUZ2gQuxWhpoAbo5lgFoe0SvHBbuMOkf UqSZ3zdFP5Wz/uuKIhHqyNOu9pvEO42zA5gNtpYSvB+hG1Cu4L9pKhnPD/3untllLOKc HzAg== X-Gm-Message-State: APjAAAX8NYnJn2BE3NIsYdtD57vx5yo+WEawCOISoxNEJEcth/QdlPFn WOcCe+FzrxWBK4tEU3rv4MDH4XgeqRAXlpSwqX13eyMp X-Google-Smtp-Source: APXvYqySaTGNPUzGvkciWfi49d64BFKNZn4xNZWoI9k89qOPm9nXHdqQV/F5JQkxl1YOslfKCqjZxbElb1x/AC/y1QU= X-Received: by 2002:a2e:6e0c:: with SMTP id j12mr46780408ljc.123.1561039769741; Thu, 20 Jun 2019 07:09:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: alan somers Date: Thu, 20 Jun 2019 08:09:18 -0600 Message-ID: Subject: Re: Qlogic FastLinq 45xxx driver Patch for upstream To: Anand Khoje Cc: "net@FreeBSD.org" , David C Somayajulu Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 755FA82D4F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.88 / 15.00]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.88)[-0.882,0]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 14:09:33 -0000 On Thu, Jun 20, 2019 at 7:38 AM Anand Khoje wrote: > > Hi, > > We have a patch with fix for an issue raised by Microsoft : > "FreeBSD 11.2 - Kernel panic when flapping network interfaces on and off" . > The issue was observed when the customer was trying to flap interface on and off in a loop more than 20 times. After investigation, it was found that panic occurred due to a thread sleeping while holding a mutex after a calling function pause(). > > I have attached the patch that has to be submitted upstream. Please let me know if I need to add someone for reviewing it. Also, please let me know if you have any questions. > > Thank you, > Anand A. Khoje CC davidcs@ . From owner-freebsd-net@freebsd.org Thu Jun 20 14:40:41 2019 Return-Path: Delivered-To: freebsd-net@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 693BF15BDCB5; Thu, 20 Jun 2019 14:40:41 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from esa5.hc3370-68.iphmx.com (esa5.hc3370-68.iphmx.com [216.71.155.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "esa5.hc3370-68.iphmx.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0CDC8451F; Thu, 20 Jun 2019 14:40:39 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender authenticity information available from domain of roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of roger.pau@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ~all" Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: fKXiAShAcOR0rMRt1LPcSiG3St2p6qwdURQf+k+WhowR9mRddnYpMNdpZQQ1+/qk/gWlL9+n3u jbmHYmAs/trgpkdDid9GjWO6s54TnfOVauxTS39T+kAmDZH4yKfEj1wGPSkniq62zwo0j/Di6w jY6f5gh+Y+tVgxaB24zV6N3Axj7HhL8v2OSw+k4vUUZPtRfO17upaezaAuxt4/696Imn+3Ivz+ WZb1VE9xvE3g0+JBT2Sn28phWJs5O0YDvEhjfMugLqaXT5csWmoh9KegMnjfOA3ZDeCu/rCJyd U1M= X-SBRS: 2.7 X-MesageID: 1996272 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.63,397,1557201600"; d="scan'208";a="1996272" Date: Thu, 20 Jun 2019 16:39:17 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Christian M CC: , Subject: Re: Very slow and inconsistent internal network speed (between VM's on the same host) for FreeBSD 11.0+ as guest on XCP-ng/XenServer Message-ID: <20190620143917.h4tq2xtgz4nbgkth@MacBook-Air-de-Roger.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-Rspamd-Queue-Id: D0CDC8451F X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of roger.pau@citrix.com designates 216.71.155.168 as permitted sender) smtp.mailfrom=roger.pau@citrix.com X-Spamd-Result: default: False [-4.08 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:216.71.155.168]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[citrix.com]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mx1.hc3370-68.iphmx.com,mx2.hc3370-68.iphmx.com,mx1.hc3370-68.iphmx.com,mx2.hc3370-68.iphmx.com,mx1.hc3370-68.iphmx.com,mx2.hc3370-68.iphmx.com,mx1.hc3370-68.iphmx.com,mx2.hc3370-68.iphmx.com,mx1.hc3370-68.iphmx.com,mx2.hc3370-68.iphmx.com,mx1.hc3370-68.iphmx.com,mx2.hc3370-68.iphmx.com,mx1.hc3370-68.iphmx.com,mx2.hc3370-68.iphmx.com,mx1.hc3370-68.iphmx.com,mx2.hc3370-68.iphmx.com,mx1.hc3370-68.iphmx.com,mx2.hc3370-68.iphmx.com,mx1.hc3370-68.iphmx.com,mx2.hc3370-68.iphmx.com]; NEURAL_HAM_SHORT(-0.90)[-0.897,0]; RCVD_IN_DNSWL_NONE(0.00)[168.155.71.216.list.dnswl.org : 127.0.3.0]; IP_SCORE(-0.87)[ip: (-1.54), ipnet: 216.71.154.0/23(-1.68), asn: 16417(-1.07), country: US(-0.06)]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16417, ipnet:216.71.154.0/23, country:US]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 14:40:41 -0000 Adding freebsd-net in case they can provide some feedback or tips about how to debug this. On Tue, Jun 18, 2019 at 04:03:00PM +0200, Christian M wrote: > I've noticed very slow networking speed between VM's with FreeBSD on the > same host (XCP-ng 7.6.0) for more recent FreeBSD-versions. Sadly inter-VM throughput has always been a problem for FreeBSD/Xen VMs. I'm not a network expert, so take my comments below with a pinch of salt. > > I've made some tests that show me that something happened from 10.4-RELEASE > to 11.0-RELEASE that had a huge impact on network performance, and > 12.0-RELEASE is even slower. I don't think there have been any major changes, the main one would be the re-write to add multiqueue support to netfront, but that change should have left the code more or less as it was, apart from adding multiqueue. > > My test setup: > > Host: XCP-ng 7.6.0, managed with XenOrchestra. Open source. > > Network: Internal Private Network on the host (not connected to a PIF). > Each VM has only one VIF connected to this network. > > VM's: > > 2 x 12.0-RELEASE > > 2 x 11.0-RELEASE > > 2 x 10.4-RELEASE > > > All clean identical installs from XenOrchestra, only installed iperf on > each VM for testing. (xe-guest-utilities makes no difference in my tests, > I've tried with and without). I think xe-guest-utilities is just needed in order to report suspend/resume capability to XCP, but there isn't anything specially helpful in there. > > iperf -s on first server listed below, and iperf -c -r on the second > to test speed back and forth: > > > 12.0 <-> 12.0: 50Mbit as client and server > > 12.0 <-> 11.0: 800Mbit/s (11.0 as client), and 140Mbit/s (11.0 as server) > > 12.0 <-> 10.4: 2.76Gbit (10.4 as client), and 1.25Gbit (10.4 as server). > > 11.0 <-> 11.0: 219Mbit as client, 99Mbit as server > > 10.4 <-> 10.4: 11.2Gbit as client, 10.9Gbit as server Do you see the same issues with external connections? Have you tested throughput between two FreeBSD 12.0 VM running on different hosts? > > > As I side note, not sure if related, but I've noticed that I can't run > iperf with -r flag on 10.4-RELEASE. I get this error message: > > > iperf -c 172.31.16.122 -r > > ------------------------------------------------------------ > > Server listening on TCP port 5001 > > TCP window size: 64.0 KByte (default) > > ------------------------------------------------------------ > > write failed: Broken pipe > > ------------------------------------------------------------ > > Client connecting to 172.31.16.122, TCP port 5001 > > TCP window size: 32.5 KByte (default) > > ------------------------------------------------------------ > > [ 5] local 172.31.16.121 port 19231 connected with 172.31.16.122 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 5] 0.0- 0.0 sec 0.00 Bytes 0.00 bits/sec Hm, OK that's weird, I don't think however it's related to Xen. Have you tried if the same happens on a bare-metal install of FreeBSD? Or when running on a different hypervisor? > > > > I can run iperf -s fine, and iperf -c from the other 10.4 VM though: > > > > iperf -c 172.31.16.122 > > ------------------------------------------------------------ > > Client connecting to 172.31.16.122, TCP port 5001 > > TCP window size: 32.5 KByte (default) > > ------------------------------------------------------------ > > [ 3] local 172.31.16.121 port 22055 connected with 172.31.16.122 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-10.0 sec 12.9 GBytes 11.1 Gbits/sec > > > > What have I tried to solve this? > > I've tried to disable checksum offloading for the 12.0-RELEASE VIF's via > XCP-ng. Disabled basically everything without any difference in iperf > results: other-config (MRW): ethtool-sg: off; ethtool-tso: off; > ethtool-ufo: off; ethtool-gso: off; ethtool-rx: off; ethtool-tx: off > > > Also tried disabling offloading in FreeBSD with ifconfig xn0 -txcsum > -rxcsum -tso -lro and no difference here either. Hm, disabling offloading would be my first suggestion, but you seem to have already done that. > > Any ideas of how to proceed now to find a solution for this? Maybe you can try to run wireshark/tcpdump or some other similar software in order to try to detect if there are errors on the transmitted packets? You could run the sniffer on the host and attach it to the backend interfaces (vifX.X) or the bridge if you are using bridged networking. The 12.0 <-> 12.0 case seems quite bad, so I would start with that one. Roger. From owner-freebsd-net@freebsd.org Thu Jun 20 20:33:01 2019 Return-Path: Delivered-To: freebsd-net@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 2AE1E15C745F for ; Thu, 20 Jun 2019 20:33:01 +0000 (UTC) (envelope-from marco@tols.org) Received: from tolstoy.tols.org (tolstoy-a1.tols.org [IPv6:2a02:898:57:3::1]) (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 0684395B4F for ; Thu, 20 Jun 2019 20:32:59 +0000 (UTC) (envelope-from marco@tols.org) Received: from 82-217-131-200.cable.dynamic.v4.ziggo.nl ([82.217.131.200] helo=[192.168.178.123]) by tolstoy.tols.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92 (FreeBSD)) (envelope-from ) id 1he3jr-0005M3-5v; Thu, 20 Jun 2019 22:32:56 +0200 From: Marco van Tol Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: net.inet.ip.stats - struct ipstat.ips_total - appears to be double the actual number Message-Id: <7861F570-6FD2-4BD0-B33B-D7F90BE44B77@tols.org> Date: Thu, 20 Jun 2019 22:32:49 +0200 Cc: Marco van Tol To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.3445.104.11) X-Tolsorg-Spam-Score: -1.0 (-) X-Rspamd-Queue-Id: 0684395B4F X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of marco@tols.org designates 2a02:898:57:3::1 as permitted sender) smtp.mailfrom=marco@tols.org X-Spamd-Result: default: False [-4.49 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:tolstoy-a1.tols.org]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tols.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mickey.tols.org]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.95)[-0.949,0]; IP_SCORE(-1.74)[ipnet: 2a02:898::/32(-4.84), asn: 8283(-3.85), country: NL(0.01)]; RECEIVED_SPAMHAUS_PBL(0.00)[200.131.217.82.zen.spamhaus.org : 127.0.0.11]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8283, ipnet:2a02:898::/32, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 20:33:01 -0000 Hi there, I'm trying to write a patch for collectd to generate trend graphs on = ipv4 and ipv6 statistics. I use the sysctls net.inet.ip.stats and net.inet6.ip6.stats for this. The structs I use to parse these sysctls are "struct ipstat" and "struct = ip6stat". While doing this, I keep running into the fact that the "struct = ipstat.ips_total" count seems to be twice the number of ipv4 packets = that actually got received on a host. Does this make any sense at all? So, in other words, if I call "sysctls net.inet.ip.stats", and do = another call 1 second later, I can deduce a per-second incoming ipv4 = packet rate. This seems to be twice as high as actually happening. The number reported in struct ip6stat.ip6s_total seems to be correct. Is there any reason for the ips_total to be twice the number of ipv4 = packets that actually got received? Another way to witness these counts is by doing: netstat -s -p ip, and = then checkout "total packets received" on a per-second basis. Thank you very much in advance! Marco van Tol= From owner-freebsd-net@freebsd.org Thu Jun 20 20:45:27 2019 Return-Path: Delivered-To: freebsd-net@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 6F1F615C776A for ; Thu, 20 Jun 2019 20:45:27 +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 0A1ED95FF3 for ; Thu, 20 Jun 2019 20:45:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C185015C7769; Thu, 20 Jun 2019 20:45:26 +0000 (UTC) Delivered-To: net@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 AFF6B15C7768 for ; Thu, 20 Jun 2019 20:45:26 +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 4F6DE95FF0 for ; Thu, 20 Jun 2019 20:45:26 +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 A42DB10A98 for ; Thu, 20 Jun 2019 20:45:25 +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 x5KKjPlQ090741 for ; Thu, 20 Jun 2019 20:45:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5KKjPOv090740 for net@FreeBSD.org; Thu, 20 Jun 2019 20:45:25 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: net@FreeBSD.org Subject: [Bug 236724] igb(4): Interfaces fail to switch active to inactive state Date: Thu, 20 Jun 2019 20:45:24 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking, needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ncrogers@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable12? 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 20:45:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236724 --- Comment #4 from ncrogers@gmail.com --- Curious if anyone else on the CC list is having the same problem or not? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jun 20 21:02:58 2019 Return-Path: Delivered-To: freebsd-net@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 0DF0715C7C7A for ; Thu, 20 Jun 2019 21:02:58 +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 9D480967C6 for ; Thu, 20 Jun 2019 21:02:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 606EA15C7C79; Thu, 20 Jun 2019 21:02:57 +0000 (UTC) Delivered-To: net@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 4D9B415C7C78 for ; Thu, 20 Jun 2019 21:02:57 +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 D9C2B967BD for ; Thu, 20 Jun 2019 21:02:56 +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 2D61710D75 for ; Thu, 20 Jun 2019 21:02:56 +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 x5KL2uYP005809 for ; Thu, 20 Jun 2019 21:02:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5KL2ufm005800 for net@FreeBSD.org; Thu, 20 Jun 2019 21:02:56 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: net@FreeBSD.org Subject: [Bug 236724] igb(4): Interfaces fail to switch active to inactive state Date: Thu, 20 Jun 2019 21:02:56 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking, needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: karl@denninger.net X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable12? 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 21:02:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236724 karl@denninger.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |karl@denninger.net --- Comment #5 from karl@denninger.net --- (In reply to ncrogers from comment #4) Maybe. I had a very odd thing happen the other day; my PCEngines gateway/firewall machine, which has two of these interfaces in it, "disappeared" off the net. I wasn't where the box was, so I couldn't physically check it from the cons= ole. I was forced to have an untrained person reset it, and it came right back = up. BUT -- if the interface flapped and the upper levels got it wrong, well..... guess what -- no packets for you, which is exactly what it looked like. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jun 20 21:03:26 2019 Return-Path: Delivered-To: freebsd-net@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 3D53F15C7C91 for ; Thu, 20 Jun 2019 21:03:26 +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 CA96796818 for ; Thu, 20 Jun 2019 21:03:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 887D315C7C90; Thu, 20 Jun 2019 21:03:25 +0000 (UTC) Delivered-To: net@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 7722615C7C8F for ; Thu, 20 Jun 2019 21:03:25 +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 16B6696813 for ; Thu, 20 Jun 2019 21:03:25 +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 62B0110D81 for ; Thu, 20 Jun 2019 21:03:24 +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 x5KL3Osr021216 for ; Thu, 20 Jun 2019 21:03:24 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5KL3OSV021210 for net@FreeBSD.org; Thu, 20 Jun 2019 21:03:24 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: net@FreeBSD.org Subject: [Bug 236724] igb(4): Interfaces fail to switch active to inactive state Date: Thu, 20 Jun 2019 21:03:23 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking, needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jboman@pathion.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable12? 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 21:03:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236724 --- Comment #6 from Jeff --- (In reply to ncrogers from comment #4) Yes, seing problem in FreeBSD 12.0-RELEASE-p5 (amd64) w/ I210 interface --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jun 20 21:04:38 2019 Return-Path: Delivered-To: freebsd-net@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 6176B15C7D43 for ; Thu, 20 Jun 2019 21:04:38 +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 EAA4196905 for ; Thu, 20 Jun 2019 21:04:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id ADF4915C7D3F; Thu, 20 Jun 2019 21:04:37 +0000 (UTC) Delivered-To: net@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 9B30015C7D3D for ; Thu, 20 Jun 2019 21:04:37 +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 3646F968FF for ; Thu, 20 Jun 2019 21:04:37 +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 8DA9110D85 for ; Thu, 20 Jun 2019 21:04:36 +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 x5KL4a0w058783 for ; Thu, 20 Jun 2019 21:04:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5KL4aOB058773 for net@FreeBSD.org; Thu, 20 Jun 2019 21:04:36 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: net@FreeBSD.org Subject: [Bug 236724] igb(4): Interfaces fail to switch active to inactive state Date: Thu, 20 Jun 2019 21:04:36 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking, needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: karl@denninger.net X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable12? 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 21:04:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236724 --- Comment #7 from karl@denninger.net --- BTW I've just updated the box (source build) to a pretty-current rev so we'= ll see if the problem is gone..... --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jun 21 02:31:17 2019 Return-Path: Delivered-To: freebsd-net@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 6B20D15CDC84 for ; Fri, 21 Jun 2019 02:31:17 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from dnvrco-cmomta02.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D5547160F for ; Fri, 21 Jun 2019 02:31:14 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from localhost ([96.28.161.151]) by cmsmtp with ESMTP id e9Hwhmi1eiYm2e9HyhoBnr; Fri, 21 Jun 2019 02:28:30 +0000 Date: Fri, 21 Jun 2019 02:28:14 +0000 From: "Thomas Mueller" To: freebsd-net@freebsd.org Subject: Working around unsupported Ethernet card with PXE or UEFI? X-CMAE-Envelope: MS4wfOJGGhSTDG55LB6oHkncA4QDQcq0X6eFHlgqms46/3UGBkZjGu5CFQFR/+bCqBoXJ4GPWdgSaAnJAelE4A/MBiKKrZUsq8THOcbUyH/Yw5Ww+dgF1dYS tWaqKfsPxSJEmyqdqgWnGUjywOnqhA1JydzprmymOvW7ApQVGTHDz13+ X-Rspamd-Queue-Id: 0D5547160F X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of mueller6722@twc.com designates 107.14.73.228 as permitted sender) smtp.mailfrom=mueller6722@twc.com X-Spamd-Result: default: False [-1.59 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988,0]; RECEIVED_SPAMHAUS_PBL(0.00)[151.161.28.96.zen.spamhaus.org : 127.0.0.10]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.14.73.0/24]; FREEMAIL_FROM(0.00)[twc.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[twc.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.967,0]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MX_GOOD(-0.01)[dnvrco-cmedge02.email.rr.com,dnvrco-cmedge01.email.rr.com]; MISSING_MID(2.50)[]; RCVD_IN_DNSWL_NONE(0.00)[228.73.14.107.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.63)[-0.633,0]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[twc.com]; ASN(0.00)[asn:7843, ipnet:107.14.73.0/24, country:US]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.20)[ip: (-4.36), ipnet: 107.14.73.0/24(-3.65), asn: 7843(-2.92), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 02:31:17 -0000 Is it possible to build and install FreeBSD so as to be bootable and access the internet with an Ethernet card that doesn't work in FreeBSD? Could Ethernet support be obtained through UEFI? Or could FreeBSD be installed on another computer or on a NAS NFS share? NAS would probably not have TFTP but would have NFS and iSCSI capability. Motherboard has PXE capability. Server OS for FreeBSD installation on other computer could be NetBSD, where the Ethernet (Realtek 8111E or 8168, re(4) driver) works well. Tom From owner-freebsd-net@freebsd.org Fri Jun 21 03:05:58 2019 Return-Path: Delivered-To: freebsd-net@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 759BD15CE8B6 for ; Fri, 21 Jun 2019 03:05:58 +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 991C172AAE for ; Fri, 21 Jun 2019 03:05:57 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 0C9494E654; Thu, 20 Jun 2019 20:05:56 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-net@freebsd.org Subject: Re: Working around unsupported Ethernet card with PXE or UEFI? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <39142.1561086355.1@segfault.tristatelogic.com> Date: Thu, 20 Jun 2019 20:05:56 -0700 Message-ID: <39143.1561086356@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 991C172AAE 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 [-3.40 / 15.00]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,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)[]; DMARC_NA(0.00)[tristatelogic.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; SUBJECT_ENDS_QUESTION(1.00)[]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; NEURAL_HAM_SHORT(-0.41)[-0.406,0]; IP_SCORE(-2.79)[ip: (-7.33), ipnet: 69.62.128.0/17(-3.66), asn: 14051(-2.90), country: US(-0.06)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 03:05:58 -0000 "Thomas Mueller" wrote: >Is it possible to build and install FreeBSD so as to be bootable and access >the internet with an Ethernet card that doesn't work in FreeBSD? You're question doesn't make a lot of sense on the face of it. Why on earth would you either WANT or NEED to install FreeBSD on a system with no ethernet adapter? If it's a matter of money, I have at least a half dozen old 10/100 cards lying around collecting dust. If you send me your address and if it is in North America, I'll send you one via snail-mail. Or you can probably get one faster off eBay for about a buck and a half. Regards, rfg P.S. Even if you're constrained by hardware... e.g. no PCIe slots... you can always get yourself some supported USB ethernet adapter. I don't know of anything worth owning that could run FreeBSD and that doesn't have at least a couple of USB ports. From owner-freebsd-net@freebsd.org Fri Jun 21 04:07:51 2019 Return-Path: Delivered-To: freebsd-net@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 A096A15CF836 for ; Fri, 21 Jun 2019 04:07:51 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 6FC8B748E2 for ; Fri, 21 Jun 2019 04:07:50 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-io1-xd32.google.com with SMTP id n5so667851ioc.7 for ; Thu, 20 Jun 2019 21:07:50 -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=l7jNVbqT9vl+VTr7pi/XFPIKxlC4GLkNQTQf3QlOMBw=; b=dU6nB8j0OepUbbTXFO9KaB/zeQft47SoKu2hfIs9en3ut8UpxAtqTxmEOpWY9N1hag q9X0FI+WCol3g55DhoDi3KsuTsjv1cy8+XuzcCo1fOyWa/SKGAowdlx1CxD8id3P4Rvy j9xx+iLNNdkJLHDNRaG5N7d5y4tjcHE9mVqOdK7UBTyBKVKakDedWXBq5y4A/0Iq/J/5 BwWzsyO6eQpE26QOHvVHUt2XoWK9+7mukvhST01l3DqIA+u8ZBEk133cvYCp8Q/b+P5e bOXzPjjpMVV0TIRipOztshY5gHbxq/8URQG3nfbLa0ydj2a52QpJxR5Fw34P7rqtS+/H G7Ng== 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=l7jNVbqT9vl+VTr7pi/XFPIKxlC4GLkNQTQf3QlOMBw=; b=EC68DJiZ3jLOLgqb3yuVZFiREYzIFAcEZJX9ErjxrTXh1fDWMj9f/1qLZWuB6W7ahg GHvt1mXBCC6WjClAT+JcD9CaAN5dEYPpAi0M3QEYjjkRPpc/QdYDHZM72vXp5zuvE6nO EbMSv/XdwAfeshdXlxlR5AOMQn0UJzjCInMpRRnniaQI+wIq2VuugkG1+zcTRiuJ2rSm 4yXLn8qcH3JDqWgykKrM1oa+oNFff5H4abi1AFWJm5x+8YuchO3BT1HLiXkWikGrDU0a GtiRc1MXiJrGoK1hOVgLuJD4Zh1Fg66vLoXXHDXtuSZho7RjF+yjguYc25r5byq+YHUc M3lA== X-Gm-Message-State: APjAAAVVaJ+b5cwBQC5zi6MFE754ZYp6B67fUSy9kbC+ZkwxgBb7pwxQ iYs12yNPaDHrG2/Oe9eCdKfHU+Nqt7vYuTfbL3GX X-Google-Smtp-Source: APXvYqxJmQEBYMcfjyJX8yjKZ2BWpCIywOgf6N1eH9rUMJnkGRJusgdhwEloUizTFweN1L58++3ZNC+OeX6uRvnHSpM= X-Received: by 2002:a5d:9a04:: with SMTP id s4mr44172592iol.19.1561090069655; Thu, 20 Jun 2019 21:07:49 -0700 (PDT) MIME-Version: 1.0 References: <39143.1561086356@segfault.tristatelogic.com> In-Reply-To: <39143.1561086356@segfault.tristatelogic.com> From: Zaphod Beeblebrox Date: Fri, 21 Jun 2019 00:07:38 -0400 Message-ID: Subject: Re: Working around unsupported Ethernet card with PXE or UEFI? To: "Ronald F. Guilmette" Cc: FreeBSD Net X-Rspamd-Queue-Id: 6FC8B748E2 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=dU6nB8j0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of zbeeble@gmail.com designates 2607:f8b0:4864:20::d32 as permitted sender) smtp.mailfrom=zbeeble@gmail.com X-Spamd-Result: default: False [-5.78 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; 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.98)[-0.984,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-2.79)[ip: (-8.42), ipnet: 2607:f8b0::/32(-3.15), asn: 15169(-2.32), 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-net@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.3.d.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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 04:07:52 -0000 I suppose he could be asking, in his way, about a type of universal driver (not unlike ndis used to be). Not knowing anything about the UEFI environment, but recalling that PXE requires one of the more restrictive processor modes ... would make that quite a challenge for a universal driver. ... but yeah... USB ports are pretty ubiquitous. On Thu, Jun 20, 2019 at 11:07 PM Ronald F. Guilmette wrote: > "Thomas Mueller" wrote: > > >Is it possible to build and install FreeBSD so as to be bootable and > access > >the internet with an Ethernet card that doesn't work in FreeBSD? > > You're question doesn't make a lot of sense on the face of it. > > Why on earth would you either WANT or NEED to install FreeBSD on a system > with no ethernet adapter? > > If it's a matter of money, I have at least a half dozen old 10/100 cards > lying around collecting dust. If you send me your address and if it is > in North America, I'll send you one via snail-mail. Or you can probably > get one faster off eBay for about a buck and a half. > > > Regards, > rfg > > > P.S. Even if you're constrained by hardware... e.g. no PCIe slots... > you can always get yourself some supported USB ethernet adapter. I don't > know of anything worth owning that could run FreeBSD and that doesn't > have at least a couple of USB ports. > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Fri Jun 21 08:19:50 2019 Return-Path: Delivered-To: freebsd-net@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 7E7AE15D4310 for ; Fri, 21 Jun 2019 08:19:50 +0000 (UTC) (envelope-from igor-fbsdnet@grinchenko.org) Received: from sun.grinchenko.org (sun.grinchenko.org [96.78.165.85]) (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 5873E85E82 for ; Fri, 21 Jun 2019 08:19:49 +0000 (UTC) (envelope-from igor-fbsdnet@grinchenko.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=grinchenko.org; s=myselector; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=45Rty42JVOQz4CL5LZn/8ktKAkM9gyswAocQ1tedIAI=; b=OaJZPleJrYzKq1qN41/NfOGcVs /W3smf93SWd3t/q9Cbj0QZYoPGqK6QNyxOfq7MuJTvKPrH6Pi6n624OW8zsUyAOu/pOS65Km+u8TF L7DYfA1hekri2ErF2/dhDZIcO; Received: from localhost ([127.0.0.1] helo=sun.grinchenko.org) by sun.grinchenko.org with esmtp (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1heElp-000PtN-1T for freebsd-net@freebsd.org; Fri, 21 Jun 2019 01:19:41 -0700 Date: Fri, 21 Jun 2019 01:19:41 -0700 From: Igor Grinchenko To: freebsd-net@freebsd.org Subject: unexpected TCP resets (RST) in 12.0-RELEASE Message-ID: <20190621081941.GM94573@sun.grinchenko.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 5873E85E82 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=grinchenko.org header.s=myselector header.b=OaJZPleJ; spf=pass (mx1.freebsd.org: domain of igor-fbsdnet@grinchenko.org designates 96.78.165.85 as permitted sender) smtp.mailfrom=igor-fbsdnet@grinchenko.org X-Spamd-Result: default: False [-4.15 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.995,0]; R_DKIM_ALLOW(-0.20)[grinchenko.org:s=myselector]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:96.78.165.85]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[grinchenko.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-0.73)[ipnet: 96.64.0.0/11(-3.64), asn: 7922(0.04), country: US(-0.06)]; DKIM_TRACE(0.00)[grinchenko.org:+]; MX_GOOD(-0.01)[sun.grinchenko.org]; NEURAL_HAM_SHORT(-0.92)[-0.915,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:7922, ipnet:96.64.0.0/11, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 08:19:50 -0000 Hello, I have been trying to debug several issues where a 12.0-RELEASE (all the way from p0 to p6) server would unexpectedly send RST packets to clients either some time after the initial 3-way handshake is completed or right after it gets the first SYN on an open port. I ran several tests and here are a few samples and scenarios and a way to replicate the problem. ### CASE 1 - RST after a SYN. this is when I noticed the issue after upgrading to 12.0-RELEASE. Port is open by an app with plenty of somaxconn and there is a lot of healthy traffic exchanging. Once every few minutes I would see this: No. Time Source Destination Protocol Length Info 14717 6.240595 10.0.0.81 10.0.0.60 TCP 74 60293 → 9000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=128 SACK_PERM=1 TSval=3108212602 TSecr=0 Frame 14717: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) Ethernet II, Src: IntelCor_f1:7f:8c (a0:36:9f:f1:7f:8c), Dst: IntelCor_d4:36:d0 (a0:36:9f:d4:36:d0) Internet Protocol Version 4, Src: 10.0.0.81, Dst: 10.0.0.60 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 60 Identification: 0x0000 (0) Flags: 0x4000, Don't fragment Time to live: 64 Protocol: TCP (6) Header checksum: 0x2630 [validation disabled] [Header checksum status: Unverified] Source: 10.0.0.81 Destination: 10.0.0.60 Transmission Control Protocol, Src Port: 60293, Dst Port: 9000, Seq: 0, Len: 0 Source Port: 60293 Destination Port: 9000 [Stream index: 1548] [TCP Segment Len: 0] Sequence number: 0 (relative sequence number) [Next sequence number: 0 (relative sequence number)] Acknowledgment number: 0 1010 .... = Header Length: 40 bytes (10) Flags: 0x002 (SYN) Window size value: 65535 [Calculated window size: 65535] Checksum: 0xa7f7 [unverified] [Checksum Status: Unverified] Urgent pointer: 0 Options: (20 bytes), Maximum segment size, No-Operation (NOP), Window scale, SACK permitted, Timestamps [Timestamps] No. Time Source Destination Protocol Length Info 14719 6.240617 10.0.0.60 10.0.0.81 TCP 54 9000 → 60293 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 Frame 14719: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) Ethernet II, Src: IntelCor_d4:36:d0 (a0:36:9f:d4:36:d0), Dst: IntelCor_f1:7f:8c (a0:36:9f:f1:7f:8c) Internet Protocol Version 4, Src: 10.0.0.60, Dst: 10.0.0.81 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 40 Identification: 0x0000 (0) Flags: 0x4000, Don't fragment Time to live: 64 Protocol: TCP (6) Header checksum: 0x0000 [validation disabled] [Header checksum status: Unverified] Source: 10.0.0.60 Destination: 10.0.0.81 Transmission Control Protocol, Src Port: 9000, Dst Port: 60293, Seq: 1, Ack: 1, Len: 0 Source Port: 9000 Destination Port: 60293 [Stream index: 1548] [TCP Segment Len: 0] Sequence number: 1 (relative sequence number) [Next sequence number: 1 (relative sequence number)] Acknowledgment number: 1 (relative ack number) 0101 .... = Header Length: 20 bytes (5) Flags: 0x014 (RST, ACK) Window size value: 0 [Calculated window size: 0] [Window size scaling factor: -1 (unknown)] Checksum: 0x14a7 [unverified] [Checksum Status: Unverified] Urgent pointer: 0 [SEQ/ACK analysis] [Timestamps] It doesn't seem to matter what app that is, doesn't matter what event mechanism is used (kqueue or select). TCP stack just refuses to handshake from time to time. The rate of these increases with the rate of incoming connections. 12.0-RELEASE-p6 seems to be producing fewer of these, it could be due to the fix in https://www.freebsd.org/security/advisories/FreeBSD-EN-19:11.net.asc . While my guess is not very scientific, it seems to be related to the new epoch(9) based synchronization. A 11.2-RELEASE host, serving the same exact traffic, which I kept for baselining is rock-solid and doesn't produce TCP resets like these. ### CASE 2 - packets processed out of order. and a simple way to replicate it. #setup: hostA(11.2-RELEASE with defaults) - switch - hostB(12.0-RELEASE with defaults) -install tcpkali from ports or via pkg on hostA. -start the tcpdump capture on any of the hosts: tcpdump -i em0 -n -v 'tcp[tcpflags] & (tcp-rst) != 0' and port 22 -run on hostA: tcpkali -c 100 --connect-rate 50 --channel-lifetime 1 hostB:22 -T 120 - wait up to 2 minutes. you will see sshd logging successful empty connections and then you will see resets returned to the client for some of the connections. Those same connections would not be logged by sshd. a fully captured pcap shows the following TCP stream which ends with resets. No. Time Source Destination Protocol Length Info 7023 76.041587 192.168.44.2 192.168.44.3 TCP 74 27697 → 22 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM=1 TSval=4283665081 TSecr=0 7024 76.041601 192.168.44.3 192.168.44.2 TCP 74 22 → 27697 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM=1 TSval=1662309011 TSecr=4283665081 7026 76.041919 192.168.44.2 192.168.44.3 TCP 66 27697 → 22 [ACK] Seq=1 Ack=1 Win=65664 Len=0 TSval=4283665081 TSecr=1662309011 7050 76.047586 192.168.44.2 192.168.44.3 TCP 66 27697 → 22 [FIN, ACK] Seq=1 Ack=1 Win=65664 Len=0 TSval=4283665086 TSecr=1662309011 7051 76.047590 192.168.44.3 192.168.44.2 TCP 66 22 → 27697 [ACK] Seq=1 Ack=2 Win=65664 Len=0 TSval=1662309017 TSecr=4283665086 7072 76.064230 192.168.44.3 192.168.44.2 TCP 104 22 → 27697 [PSH, ACK] Seq=1 Ack=2 Win=65664 Len=38 TSval=1662309033 TSecr=4283665086 7073 76.064415 192.168.44.3 192.168.44.2 TCP 66 22 → 27697 [FIN, ACK] Seq=39 Ack=2 Win=65664 Len=0 TSval=1662309034 TSecr=4283665086 7074 76.064538 192.168.44.2 192.168.44.3 TCP 60 27697 → 22 [RST] Seq=2 Win=0 Len=0 7075 76.064710 192.168.44.2 192.168.44.3 TCP 60 27697 → 22 [RST] Seq=2 Win=0 Len=0 it seems like the actual packet with the payload(#7072) is processed after the FIN is received and that is not the order they are sent by tcpkali running on hostA. this doesn't seem to be replicatable over lo0, there has to be physical exchange of packets via the NICs. I have not tried running it in bhyve. when the same tcpkali test is executed the other direction, 11.2-RELEASE doesn't produce a single reset like that. ## 11.2-RELEASE (any patch level) doesn't have any of these problems, so this must be a regression somewhere in the TCP stack. In all these cases OS was installed with all defaults untouched. NICs are either ix or em (tried stock drivers and intel-ix-kmod and intel-em-kmod, which didn't seem to matter). I can provide dmesgs, raw pcaps, etc, if necessary. I am curious why this hasn't been reported by now(checked mailing lists and open bugs) as it seems like a relatively serious issue. But then again, maybe I'm missing something obvious, in which case, I'd like to get educated. Regards, -- Igor From owner-freebsd-net@freebsd.org Fri Jun 21 10:26:52 2019 Return-Path: Delivered-To: freebsd-net@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 A4E8415D652F for ; Fri, 21 Jun 2019 10:26:52 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07AAB89F41 for ; Fri, 21 Jun 2019 10:26:51 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2a02:8109:1140:c3d:f82e:99f:942f:fc66] (unknown [IPv6:2a02:8109:1140:c3d:f82e:99f:942f:fc66]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id CEAB872106C12; Fri, 21 Jun 2019 12:26:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: unexpected TCP resets (RST) in 12.0-RELEASE From: Michael Tuexen In-Reply-To: <20190621081941.GM94573@sun.grinchenko.org> Date: Fri, 21 Jun 2019 12:26:46 +0200 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190621081941.GM94573@sun.grinchenko.org> To: Igor Grinchenko X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 07AAB89F41 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 10:26:52 -0000 > On 21. Jun 2019, at 10:19, Igor Grinchenko = wrote: >=20 > Hello, >=20 > I have been trying to debug several issues where a 12.0-RELEASE (all = the way from p0 to p6) server would unexpectedly send RST packets to = clients either some time after the initial 3-way handshake is completed = or right after it gets the first SYN on an open port. >=20 > I ran several tests and here are a few samples and scenarios and a way = to replicate the problem. >=20 > ### > CASE 1 - RST after a SYN. >=20 > this is when I noticed the issue after upgrading to 12.0-RELEASE. Port = is open by an app with plenty of somaxconn and there is a lot of healthy = traffic exchanging. Once every few minutes I would see this: >=20 > No. Time Source Destination = Protocol Length Info > 14717 6.240595 10.0.0.81 10.0.0.60 TCP = 74 60293 =E2=86=92 9000 [SYN] Seq=3D0 Win=3D65535 Len=3D0 = MSS=3D1460 WS=3D128 SACK_PERM=3D1 TSval=3D3108212602 TSecr=3D0 >=20 > Frame 14717: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) > Ethernet II, Src: IntelCor_f1:7f:8c (a0:36:9f:f1:7f:8c), Dst: = IntelCor_d4:36:d0 (a0:36:9f:d4:36:d0) > Internet Protocol Version 4, Src: 10.0.0.81, Dst: 10.0.0.60 > 0100 .... =3D Version: 4 > .... 0101 =3D Header Length: 20 bytes (5) > Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) > Total Length: 60 > Identification: 0x0000 (0) > Flags: 0x4000, Don't fragment > Time to live: 64 > Protocol: TCP (6) > Header checksum: 0x2630 [validation disabled] > [Header checksum status: Unverified] > Source: 10.0.0.81 > Destination: 10.0.0.60 > Transmission Control Protocol, Src Port: 60293, Dst Port: 9000, Seq: = 0, Len: 0 > Source Port: 60293 > Destination Port: 9000 > [Stream index: 1548] > [TCP Segment Len: 0] > Sequence number: 0 (relative sequence number) > [Next sequence number: 0 (relative sequence number)] > Acknowledgment number: 0 > 1010 .... =3D Header Length: 40 bytes (10) > Flags: 0x002 (SYN) > Window size value: 65535 > [Calculated window size: 65535] > Checksum: 0xa7f7 [unverified] > [Checksum Status: Unverified] > Urgent pointer: 0 > Options: (20 bytes), Maximum segment size, No-Operation (NOP), = Window scale, SACK permitted, Timestamps > [Timestamps] >=20 > No. Time Source Destination = Protocol Length Info > 14719 6.240617 10.0.0.60 10.0.0.81 TCP = 54 9000 =E2=86=92 60293 [RST, ACK] Seq=3D1 Ack=3D1 Win=3D0 Len=3D0= >=20 > Frame 14719: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) > Ethernet II, Src: IntelCor_d4:36:d0 (a0:36:9f:d4:36:d0), Dst: = IntelCor_f1:7f:8c (a0:36:9f:f1:7f:8c) > Internet Protocol Version 4, Src: 10.0.0.60, Dst: 10.0.0.81 > 0100 .... =3D Version: 4 > .... 0101 =3D Header Length: 20 bytes (5) > Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) > Total Length: 40 > Identification: 0x0000 (0) > Flags: 0x4000, Don't fragment > Time to live: 64 > Protocol: TCP (6) > Header checksum: 0x0000 [validation disabled] > [Header checksum status: Unverified] > Source: 10.0.0.60 > Destination: 10.0.0.81 > Transmission Control Protocol, Src Port: 9000, Dst Port: 60293, Seq: = 1, Ack: 1, Len: 0 > Source Port: 9000 > Destination Port: 60293 > [Stream index: 1548] > [TCP Segment Len: 0] > Sequence number: 1 (relative sequence number) > [Next sequence number: 1 (relative sequence number)] > Acknowledgment number: 1 (relative ack number) > 0101 .... =3D Header Length: 20 bytes (5) > Flags: 0x014 (RST, ACK) > Window size value: 0 > [Calculated window size: 0] > [Window size scaling factor: -1 (unknown)] > Checksum: 0x14a7 [unverified] > [Checksum Status: Unverified] > Urgent pointer: 0 > [SEQ/ACK analysis] > [Timestamps] >=20 > It doesn't seem to matter what app that is, doesn't matter what event = mechanism is used (kqueue or select). TCP stack just refuses to = handshake from time to time. The rate of these increases with the rate = of incoming connections. 12.0-RELEASE-p6 seems to be producing fewer of = these, it could be due to the fix in = https://www.freebsd.org/security/advisories/FreeBSD-EN-19:11.net.asc . = While my guess is not very scientific, it seems to be related to the new = epoch(9) based synchronization. A 11.2-RELEASE host, serving the same = exact traffic, which I kept for baselining is rock-solid and doesn't = produce TCP resets like these. Hi Igor, could you do sudo sysctl net.inet.tcp.log_debug=3D1 on the host sending the RST segments and see if you get some messages in = /var/log/messages. Do you see these messages? If yes, what is logged? Do you have a way to reproduce this issue? Best regards Michael >=20 > ### > CASE 2 - packets processed out of order. and a simple way to replicate = it. >=20 > #setup: hostA(11.2-RELEASE with defaults) - switch - = hostB(12.0-RELEASE with defaults) > -install tcpkali from ports or via pkg on hostA.=20 > -start the tcpdump capture on any of the hosts: tcpdump -i em0 -n = -v 'tcp[tcpflags] & (tcp-rst) !=3D 0' and port 22 > -run on hostA: tcpkali -c 100 --connect-rate 50 --channel-lifetime 1 = hostB:22 -T 120 > - wait up to 2 minutes. you will see sshd logging successful empty = connections and then you will see resets returned to the client for some = of the connections. Those same connections would not be logged by sshd. >=20 > a fully captured pcap shows the following TCP stream which ends with = resets. >=20 > No. Time Source Destination = Protocol Length Info > 7023 76.041587 192.168.44.2 192.168.44.3 TCP = 74 27697 =E2=86=92 22 [SYN] Seq=3D0 Win=3D65535 Len=3D0 MSS=3D1460= WS=3D64 SACK_PERM=3D1 TSval=3D4283665081 TSecr=3D0 > 7024 76.041601 192.168.44.3 192.168.44.2 TCP = 74 22 =E2=86=92 27697 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D65535 = Len=3D0 MSS=3D1460 WS=3D64 SACK_PERM=3D1 TSval=3D1662309011 = TSecr=3D4283665081 > 7026 76.041919 192.168.44.2 192.168.44.3 TCP = 66 27697 =E2=86=92 22 [ACK] Seq=3D1 Ack=3D1 Win=3D65664 Len=3D0 = TSval=3D4283665081 TSecr=3D1662309011 > 7050 76.047586 192.168.44.2 192.168.44.3 TCP = 66 27697 =E2=86=92 22 [FIN, ACK] Seq=3D1 Ack=3D1 Win=3D65664 = Len=3D0 TSval=3D4283665086 TSecr=3D1662309011 > 7051 76.047590 192.168.44.3 192.168.44.2 TCP = 66 22 =E2=86=92 27697 [ACK] Seq=3D1 Ack=3D2 Win=3D65664 Len=3D0 = TSval=3D1662309017 TSecr=3D4283665086 > 7072 76.064230 192.168.44.3 192.168.44.2 TCP = 104 22 =E2=86=92 27697 [PSH, ACK] Seq=3D1 Ack=3D2 Win=3D65664 = Len=3D38 TSval=3D1662309033 TSecr=3D4283665086 > 7073 76.064415 192.168.44.3 192.168.44.2 TCP = 66 22 =E2=86=92 27697 [FIN, ACK] Seq=3D39 Ack=3D2 Win=3D65664 = Len=3D0 TSval=3D1662309034 TSecr=3D4283665086 > 7074 76.064538 192.168.44.2 192.168.44.3 TCP = 60 27697 =E2=86=92 22 [RST] Seq=3D2 Win=3D0 Len=3D0 > 7075 76.064710 192.168.44.2 192.168.44.3 TCP = 60 27697 =E2=86=92 22 [RST] Seq=3D2 Win=3D0 Len=3D0 >=20 >=20 > it seems like the actual packet with the payload(#7072) is processed = after the FIN is received and that is not the order they are sent by = tcpkali running on hostA. > this doesn't seem to be replicatable over lo0, there has to be = physical exchange of packets via the NICs. I have not tried running it = in bhyve. >=20 > when the same tcpkali test is executed the other direction, = 11.2-RELEASE doesn't produce a single reset like that. > ## >=20 > 11.2-RELEASE (any patch level) doesn't have any of these problems, so = this must be a regression somewhere in the TCP stack. In all these cases = OS was installed with all defaults untouched. NICs are either ix or em = (tried stock drivers and intel-ix-kmod and intel-em-kmod, which didn't = seem to matter). >=20 > I can provide dmesgs, raw pcaps, etc, if necessary. I am curious why = this hasn't been reported by now(checked mailing lists and open bugs) as = it seems like a relatively serious issue. But then again, maybe I'm = missing something obvious, in which case, I'd like to get educated. >=20 > Regards, >=20 > --=20 > Igor >=20 >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Fri Jun 21 10:54:04 2019 Return-Path: Delivered-To: freebsd-net@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 9C75315D6B27 for ; Fri, 21 Jun 2019 10:54:04 +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 3753A8A9C1 for ; Fri, 21 Jun 2019 10:54:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id EBD1815D6B24; Fri, 21 Jun 2019 10:54:03 +0000 (UTC) Delivered-To: net@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 DA56915D6B23 for ; Fri, 21 Jun 2019 10:54:03 +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 7A6338A9BE for ; Fri, 21 Jun 2019 10:54:03 +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 D2370183E4 for ; Fri, 21 Jun 2019 10:54:02 +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 x5LAs2W4052541 for ; Fri, 21 Jun 2019 10:54:02 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5LAs2md052540 for net@FreeBSD.org; Fri, 21 Jun 2019 10:54:02 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: net@FreeBSD.org Subject: [Bug 238741] RACK tcpip stack causes connections to hang Date: Fri, 21 Jun 2019 10:54:02 +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: 12.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 10:54:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238741 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jun 21 21:23:58 2019 Return-Path: Delivered-To: freebsd-net@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 9226A15BF920 for ; Fri, 21 Jun 2019 21:23:58 +0000 (UTC) (envelope-from igor-fbsdnet@grinchenko.org) Received: from sun.grinchenko.org (sun.grinchenko.org [96.78.165.85]) (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 CC46681683; Fri, 21 Jun 2019 21:23:56 +0000 (UTC) (envelope-from igor-fbsdnet@grinchenko.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=grinchenko.org; s=myselector; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OKU7amMvdfCAcr7ZmnVP3NqseEXIMq/aiF12ZCCdsSQ=; b=bTK3J7LGGkj7jjxvDLhJCPZB6 VVc9FyVwJLhVyKz/OnvGEB+1IbfXC7Meh5mCLCOryflvniQFRth21XvMeL0nf91kRdPd40V8xaOoO EY+k7ExGHxXzez2OFoeMM4OzZj; Received: from localhost ([127.0.0.1] helo=sun.grinchenko.org) by sun.grinchenko.org with esmtp (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1heR0k-00017Y-6q; Fri, 21 Jun 2019 14:23:54 -0700 Date: Fri, 21 Jun 2019 14:23:54 -0700 From: Igor Grinchenko To: Michael Tuexen Cc: freebsd-net@freebsd.org Subject: Re: unexpected TCP resets (RST) in 12.0-RELEASE Message-ID: <20190621212354.GP94573@sun.grinchenko.org> References: <20190621081941.GM94573@sun.grinchenko.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: CC46681683 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=grinchenko.org header.s=myselector header.b=bTK3J7LG; spf=pass (mx1.freebsd.org: domain of igor-fbsdnet@grinchenko.org designates 96.78.165.85 as permitted sender) smtp.mailfrom=igor-fbsdnet@grinchenko.org X-Spamd-Result: default: False [-4.12 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; R_DKIM_ALLOW(-0.20)[grinchenko.org:s=myselector]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:96.78.165.85]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grinchenko.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-0.74)[ipnet: 96.64.0.0/11(-3.67), asn: 7922(0.03), country: US(-0.06)]; MX_GOOD(-0.01)[cached: sun.grinchenko.org]; DKIM_TRACE(0.00)[grinchenko.org:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.88)[-0.878,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:7922, ipnet:96.64.0.0/11, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 21:23:58 -0000 On Fri, Jun 21, 2019 at 12:26:46PM +0200, Michael Tuexen wrote: > > On 21. Jun 2019, at 10:19, Igor Grinchenko wrote: <..> > > > > It doesn't seem to matter what app that is, doesn't matter what event mechanism is used (kqueue or select). TCP stack just refuses to handshake from time to time. The rate of these increases with the rate of incoming connections. 12.0-RELEASE-p6 seems to be producing fewer of these, it could be due to the fix in https://www.freebsd.org/security/advisories/FreeBSD-EN-19:11.net.asc . While my guess is not very scientific, it seems to be related to the new epoch(9) based synchronization. A 11.2-RELEASE host, serving the same exact traffic, which I kept for baselining is rock-solid and doesn't produce TCP resets like these. > Hi Igor, > > could you do > sudo sysctl net.inet.tcp.log_debug=1 > on the host sending the RST segments and see if you get some messages in /var/log/messages. > Do you see these messages? If yes, what is logged? > > Do you have a way to reproduce this issue? > > Best regards > Michael > > Michael, first of all, thank you for the MIB pointer, very useful, it should really be promoted for bugreports/mailing list postings. Unfortunately, setting net.inet.tcp.log_debug=1 doesn't result in any log entries for this particular use case. I see logging about other legitimate resets but not that one. I have been trying to find an easy way to reproduce it, but haven't been able to do it yet. It is a moderately loaded server running FPM accepting and serving 300-500 requests(each on a new TCP connection) per second. It seems like I'm getting significantly fewer resets on more powerful hardware(Intel Gold 6140 vs E5-2670 v3), all other things being equal. Enabling net.inet.tcp.syncookies_only=1 doesn't seem to help, either. is there anything else I can run to get a better insight into what might be happening? -- Igor From owner-freebsd-net@freebsd.org Sat Jun 22 08:21:21 2019 Return-Path: Delivered-To: freebsd-net@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 F20A515CF918 for ; Sat, 22 Jun 2019 08:21:20 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from dnvrco-cmomta02.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E3066E7F1 for ; Sat, 22 Jun 2019 08:21:17 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from localhost ([96.28.161.151]) by cmsmtp with ESMTP id ebGlhCWwliYm2ebGnh2lZG; Sat, 22 Jun 2019 08:21:10 +0000 Date: Sat, 22 Jun 2019 08:20:54 +0000 From: "Thomas Mueller" To: freebsd-net@freebsd.org Subject: Re: Working around unsupported Ethernet card with PXE or UEFI? References: <20190621023301.CRCA7107.dnvrco-fep06.email.rr.com@dnvrco-cmimta20> <39143.1561086356@segfault.tristatelogic.com> X-CMAE-Envelope: MS4wfClppO9FVsVgNyg4AqgDOm1BGWKs0Zulrn/DtEWmGN66mAAhUqGiYEUwE4RDsoSjEGXSm3RCKuBIs5PtY6x9gOfPYdUc6evqzm3r9rDRr5O1j0ceV5bg PGcDa6kJhBcmbwvkqZIbUOLcf1fVd5+I4kTYWmIC6lsvBSFPOYRI/3Pv X-Rspamd-Queue-Id: 1E3066E7F1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of mueller6722@twc.com designates 107.14.73.231 as permitted sender) smtp.mailfrom=mueller6722@twc.com X-Spamd-Result: default: False [-2.52 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.987,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.14.73.0/24]; FREEMAIL_FROM(0.00)[twc.com]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.98)[-0.980,0]; MISSING_MID(2.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MX_GOOD(-0.01)[dnvrco-cmedge02.email.rr.com,dnvrco-cmedge01.email.rr.com]; NEURAL_HAM_SHORT(-0.84)[-0.840,0]; RCVD_IN_DNSWL_NONE(0.00)[231.73.14.107.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.91)[ip: (-7.90), ipnet: 107.14.73.0/24(-3.65), asn: 7843(-2.92), country: US(-0.06)]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[twc.com]; FROM_EQ_ENVFROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[151.161.28.96.zen.spamhaus.org : 127.0.0.10]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7843, ipnet:107.14.73.0/24, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[twc.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 08:21:21 -0000 from Ronald F. Guilmette: > "Thomas Mueller" wrote: > >Is it possible to build and install FreeBSD so as to be bootable and access > >the internet with an Ethernet card that doesn't work in FreeBSD? > You're question doesn't make a lot of sense on the face of it. > Why on earth would you either WANT or NEED to install FreeBSD on a system > with no ethernet adapter? > If it's a matter of money, I have at least a half dozen old 10/100 cards > lying around collecting dust. If you send me your address and if it is > in North America, I'll send you one via snail-mail. Or you can probably > get one faster off eBay for about a buck and a half. You should have read more carefully, system has an ethernet adapter that worked on some past installations of FreeBSD, and works on NetBSD, System Rescue CD (Linux) and Haiku R1Alpha4 from November 2012. I use subversion built on NetBSD from pkgsrc to update FreeBSD src, ports and doc trees. Using GPT, UFS and no traditional BSD disklabels, FreeBSD and NetBSD can read and write to each other's partitions. I managed to boot FreeBSD 12-stable on this computer in UEFI mode and apparently get internet access with "dhclient re0". Then "host news.individual.net" worked correctly. Running ifconfig re0 up ifconfig re0 inet 192.168.0.2/24 route add default 192.168.0.1 seemed to connect, but then "host news.individual.net" failed (strange). Now to try on FreeBSD-current with UEFI, using dhclient? from Zaphod Beeblebrox: > I suppose he could be asking, in his way, about a type of universal driver > (not unlike ndis used to be). Not knowing anything about the UEFI > environment, but recalling that PXE requires one of the more restrictive > processor modes ... would make that quite a challenge for a universal > driver. > ... but yeah... USB ports are pretty ubiquitous. PXE boot could be done in BIOS mode as well as UEFI mode, but if selected from boot menu, would figure to be in UEFI mode. Hopefully I would be using the motherboard's support for the onboard ethernet rather than FreeBSD's support. But I am not sure if it would work like that. Tom