From owner-freebsd-stable@freebsd.org Mon Apr 3 08:30:21 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02976D2C831
for <freebsd-stable@mailman.ysv.freebsd.org>;
Mon, 3 Apr 2017 08:30:21 +0000 (UTC)
(envelope-from marko.cupac@mimar.rs)
Received: from mail.mimar.rs (mail1.mimar.rs [193.53.106.128])
(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 AC9B92F
for <freebsd-stable@freebsd.org>; Mon, 3 Apr 2017 08:30:19 +0000 (UTC)
(envelope-from marko.cupac@mimar.rs)
Received: from mail1.mimar.rs (localhost [127.0.1.128])
by mail.mimar.rs (Postfix) with ESMTP id D1A919FA8B68
for <freebsd-stable@freebsd.org>; Mon, 3 Apr 2017 10:23:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mimar.rs; h=
content-transfer-encoding:content-type:content-type:mime-version
:x-mailer:organization:message-id:subject:subject:from:from:date
:date:received:received; s=mimar-0901; t=1491207823; x=
1493022224; bh=MrVLDMA+1L08ZCIpyDXVbPslvtyqBqGBwj/LM7gAzWU=; b=G
a6u2XKiPL83hidR9SKP+N8olYJU4S+79P8JM0OaFlxLBzwm0sn2BP48IsQZA7a2k
WaMgCn6wbsvrxwwW/+ttImxyHwQCWpPGRk5juSuy+Jfc25pYNhoglLz+IYXAjzaf
b5RWEASiJctzTd260FdsOHQPGZj9v7trydL8vQkip0=
X-Virus-Scanned: amavisd-new at mimar.rs
Received: from mail.mimar.rs ([127.0.1.128])
by mail1.mimar.rs (amavis.mimar.rs [127.0.1.128]) (amavisd-new, port 10026)
with LMTP id 24LqBa-3BiAa for <freebsd-stable@freebsd.org>;
Mon, 3 Apr 2017 10:23:43 +0200 (CEST)
Received: from efreet-freebsd.kappastar.com (nat-nat.kappastar.com
[193.53.106.34])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested) (Authenticated sender: marko.cupac)
by mail.mimar.rs (Postfix) with ESMTPSA id DA21A9FA8B66
for <freebsd-stable@freebsd.org>; Mon, 3 Apr 2017 10:23:42 +0200 (CEST)
Date: Mon, 3 Apr 2017 10:23:42 +0200
From: Marko =?UTF-8?B?Q3VwYcSH?= <marko.cupac@mimar.rs>
To: freebsd-stable@freebsd.org
Subject: freebsd-update: 11.0 approaching EOL?
Message-ID: <20170403102342.715db73d@efreet-freebsd.kappastar.com>
Organization: Mimar
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Apr 2017 08:30:21 -0000
Hi,
I just got the following message after running freebsd-update:
...
WARNING: FreeBSD 11.0-RELEASE-p8 is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.
I guess this should be fixed.
--=20
Before enlightenment - chop wood, draw water.
After enlightenment - chop wood, draw water.
Marko Cupa=C4=87
https://www.mimar.rs/
From owner-freebsd-stable@freebsd.org Mon Apr 3 14:16:56 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF151D2B979
for <freebsd-stable@mailman.ysv.freebsd.org>;
Mon, 3 Apr 2017 14:16: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 mx1.freebsd.org (Postfix) with ESMTPS id CEAC13E6
for <freebsd-stable@FreeBSD.org>; Mon, 3 Apr 2017 14:16:56 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v33EGtqp064171
for <freebsd-stable@FreeBSD.org>; Mon, 3 Apr 2017 14:16:56 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-stable@FreeBSD.org
Subject: [Bug 213903] Kernel crashes from turnstile_broadcast
(/usr/src/sys/kern/subr_turnstile.c:837)
Date: Mon, 03 Apr 2017 14:16:56 +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: crash
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: mjg@FreeBSD.org
X-Bugzilla-Status: Open
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-213903-8075-PBOTvSbmUw@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-213903-8075@https.bugs.freebsd.org/bugzilla/>
References: <bug-213903-8075@https.bugs.freebsd.org/bugzilla/>
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-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Apr 2017 14:16:57 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903
--- Comment #26 from Mateusz Guzik <mjg@FreeBSD.org> ---
So, can I please get confirmation that the problem is still present in curr=
ent
and still present in stable/11 past r315395? There were several changes whi=
ch
could have make the apparent cpu problem stop manifesting itself.
If so, I'll simply merge them to stable/10 as well.
--=20
You are receiving this mail because:
You are on the CC list for the bug.=
From owner-freebsd-stable@freebsd.org Mon Apr 3 14:34:36 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEDF3D2C334
for <freebsd-stable@mailman.ysv.freebsd.org>;
Mon, 3 Apr 2017 14:34:36 +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 mx1.freebsd.org (Postfix) with ESMTPS id CE5FA252
for <freebsd-stable@FreeBSD.org>; Mon, 3 Apr 2017 14:34:36 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v33EYamJ005602
for <freebsd-stable@FreeBSD.org>; Mon, 3 Apr 2017 14:34:36 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-stable@FreeBSD.org
Subject: [Bug 213903] Kernel crashes from turnstile_broadcast
(/usr/src/sys/kern/subr_turnstile.c:837)
Date: Mon, 03 Apr 2017 14:34:36 +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: crash
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: peixoto.cassiano@gmail.com
X-Bugzilla-Status: Open
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-213903-8075-elt4bKU3Md@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-213903-8075@https.bugs.freebsd.org/bugzilla/>
References: <bug-213903-8075@https.bugs.freebsd.org/bugzilla/>
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-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Apr 2017 14:34:37 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903
--- Comment #27 from Cassiano Peixoto <peixoto.cassiano@gmail.com> ---
(In reply to Mateusz Guzik from comment #26)
Hi Mateuz, i can confirm only on stable/10. Maybe someone else can confirm =
it
to you. After the patch is running 13 days without crash. Thanks.
--=20
You are receiving this mail because:
You are on the CC list for the bug.=
From owner-freebsd-stable@freebsd.org Mon Apr 3 16:10:06 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3CCDD2C51E
for <freebsd-stable@mailman.ysv.freebsd.org>;
Mon, 3 Apr 2017 16:10:06 +0000 (UTC) (envelope-from slw@zxy.spb.ru)
Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98])
(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 9A3AEC0
for <freebsd-stable@freebsd.org>; Mon, 3 Apr 2017 16:10:06 +0000 (UTC)
(envelope-from slw@zxy.spb.ru)
Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD))
(envelope-from <slw@zxy.spb.ru>) id 1cv4YI-0008uw-20
for freebsd-stable@freebsd.org; Mon, 03 Apr 2017 19:09:58 +0300
Date: Mon, 3 Apr 2017 19:09:58 +0300
From: Slawa Olhovchenkov <slw@zxy.spb.ru>
To: freebsd-stable@freebsd.org
Subject: /dev/dri registration
Message-ID: <20170403160957.GA20974@zxy.spb.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: slw@zxy.spb.ru
X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Apr 2017 16:10:06 -0000
I am have strange issuse on stable/10:
# devinfo -v
nexus0
apic0
ram0
acpi0
[...]
pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0
pci0
hostb0 pnpinfo vendor=0x8086 device=0xd130 subvendor=0x1014 subdevice=0x03ce class=0x060000 at slot=0 function=0 dbsf=pci0:0:0:0
pcib1 pnpinfo vendor=0x8086 device=0xd138 subvendor=0x1014 subdevice=0x03ce class=0x060400 at slot=3 function=0 dbsf=pci0:0:3:0 handle=\_SB_.PCI0.P0P2
pci1
vgapci0 pnpinfo vendor=0x10de device=0x0a20 subvendor=0x1458 subdevice=0x34d6 class=0x030000 at slot=0 function=0 dbsf=pci0:1:0:0
drm0
drmn0
nvidia0
But /dev/dri don't exist!
# kldstat
Id Refs Address Size Name
1 80 0xffffffff80200000 17e87f8 kernel
2 1 0xffffffff819e9000 309780 zfs.ko
3 2 0xffffffff81cf3000 6040 opensolaris.ko
4 1 0xffffffff81cfa000 7aa58 if_em.ko
5 1 0xffffffff81d75000 29bd0 drm.ko
6 1 0xffffffff81d9f000 82898 drm2.ko
7 2 0xffffffff81e22000 6298 iicbus.ko
8 1 0xffffffff81e29000 1c650 uart.ko
9 1 0xffffffff82011000 56f3 fdescfs.ko
10 1 0xffffffff82017000 a681 linprocfs.ko
11 3 0xffffffff82022000 7522 linux_common.ko
12 1 0xffffffff8202a000 5673 linsysfs.ko
13 1 0xffffffff82030000 364c ums.ko
14 1 0xffffffff82034000 10226 snd_uaudio.ko
15 1 0xffffffff82045000 2ba8 uhid.ko
16 3 0xffffffff82048000 4e626 vboxdrv.ko
17 2 0xffffffff82097000 2b82 vboxnetflt.ko
18 2 0xffffffff8209a000 ba2f netgraph.ko
19 1 0xffffffff820a6000 414f ng_ether.ko
20 1 0xffffffff820ab000 3fd4 vboxnetadp.ko
21 2 0xffffffff820af000 3d5da linux.ko
22 1 0xffffffff820ed000 964496 nvidia.ko
What is wrong in may setup?
From owner-freebsd-stable@freebsd.org Mon Apr 3 22:08:43 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98692D2D4B4;
Mon, 3 Apr 2017 22:08:43 +0000 (UTC) (envelope-from mike@sentex.net)
Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50])
(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
(Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 63606117;
Mon, 3 Apr 2017 22:08:42 +0000 (UTC) (envelope-from mike@sentex.net)
Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11])
by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id v33Le4d9042846
(version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
Mon, 3 Apr 2017 17:40:05 -0400 (EDT) (envelope-from mike@sentex.net)
Received: from [IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c]
([IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c])
by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id v33Le2N4020047;
Mon, 3 Apr 2017 17:40:02 -0400 (EDT) (envelope-from mike@sentex.net)
Subject: Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec
sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf
sys/libkern
sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/ne...
To: "Andrey V. Elsukov" <ae@FreeBSD.org>,
FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>,
svn-src-stable-11@freebsd.org
References: <201703182204.v2IM4Kfj060263@repo.freebsd.org>
From: Mike Tancsa <mike@sentex.net>
Organization: Sentex Communications
Message-ID: <7738349f-e89a-d37d-e36f-0a5e18dc4249@sentex.net>
Date: Mon, 3 Apr 2017 17:39:52 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <201703182204.v2IM4Kfj060263@repo.freebsd.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.78
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Apr 2017 22:08:43 -0000
Hi,
I ran into a strange problem when migrating a box that makes use of tcp
md5 signatures. Having these two policies that have IPs which happen to
be 128 octets apart get rejected
add 10.50.34.158 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.30 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;
Similarly, if I have the entries
add 10.50.34.159 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.31 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;
it errors out as well
# setkey -F ; setkey -FP ; setkey -F ; setkey -f test.ipsec.2
The result of line 2: File exists.
The result of line 4: File exists.
# cat test.ipsec.2
add 10.50.34.158 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.30 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;
add 10.50.34.159 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.31 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;
But if the IPs are not 128 apart, its fine
# cat test.ipsec.3
add 10.50.34.157 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.30 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;
add 10.50.34.160 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.31 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;
# setkey -F ; setkey -FP ; setkey -F ; setkey -f test.ipsec.3
#
On 3/18/2017 6:04 PM, Andrey V. Elsukov wrote:
> Author: ae
> Date: Sat Mar 18 22:04:20 2017
> New Revision: 315514
> URL: https://svnweb.freebsd.org/changeset/base/315514
>
> Log:
> MFC r304572 (by bz):
> Remove the kernel optoion for IPSEC_FILTERTUNNEL, which was deprecated
> more than 7 years ago in favour of a sysctl in r192648.
>
> MFC r305122:
> Remove redundant sanity checks from ipsec[46]_common_input_cb().
>
> This check already has been done in the each protocol callback.
>
> MFC r309144,309174,309201 (by fabient):
> IPsec RFC6479 support for replay window sizes up to 2^32 - 32 packets.
>
> Since the previous algorithm, based on bit shifting, does not scale
> with large replay windows, the algorithm used here is based on
> RFC 6479: IPsec Anti-Replay Algorithm without Bit Shifting.
> The replay window will be fast to be updated, but will cost as many bits
> in RAM as its size.
>
> The previous implementation did not provide a lock on the replay window,
> which may lead to replay issues.
>
> Obtained from: emeric.poupon@stormshield.eu
> Sponsored by: Stormshield
> Differential Revision: https://reviews.freebsd.org/D8468
>
> MFC r309143,309146 (by fabient):
> In a dual processor system (2*6 cores) during IPSec throughput tests,
> we see a lot of contention on the arc4 lock, used to generate the IV
> of the ESP output packets.
>
> The idea of this patch is to split this mutex in order to reduce the
> contention on this lock.
>
> Update r309143 to prevent false sharing.
>
> Reviewed by: delphij, markm, ache
> Approved by: so
> Obtained from: emeric.poupon@stormshield.eu
> Sponsored by: Stormshield
> Differential Revision: https://reviews.freebsd.org/D8130
>
> MFC r313330:
> Merge projects/ipsec into head/.
>
> Small summary
> -------------
>
> o Almost all IPsec releated code was moved into sys/netipsec.
> o New kernel modules added: ipsec.ko and tcpmd5.ko. New kernel
> option IPSEC_SUPPORT added. It enables support for loading
> and unloading of ipsec.ko and tcpmd5.ko kernel modules.
> o IPSEC_NAT_T option was removed. Now NAT-T support is enabled by
> default. The UDP_ENCAP_ESPINUDP_NON_IKE encapsulation type
> support was removed. Added TCP/UDP checksum handling for
> inbound packets that were decapsulated by transport mode SAs.
> setkey(8) modified to show run-time NAT-T configuration of SA.
> o New network pseudo interface if_ipsec(4) added. For now it is
> build as part of ipsec.ko module (or with IPSEC kernel).
> It implements IPsec virtual tunnels to create route-based VPNs.
> o The network stack now invokes IPsec functions using special
> methods. The only one header file <netipsec/ipsec_support.h>
> should be included to declare all the needed things to work
> with IPsec.
> o All IPsec protocols handlers (ESP/AH/IPCOMP protosw) were removed.
> Now these protocols are handled directly via IPsec methods.
> o TCP_SIGNATURE support was reworked to be more close to RFC.
> o PF_KEY SADB was reworked:
> - now all security associations stored in the single SPI namespace,
> and all SAs MUST have unique SPI.
> - several hash tables added to speed up lookups in SADB.
> - SADB now uses rmlock to protect access, and concurrent threads
> can do SA lookups in the same time.
> - many PF_KEY message handlers were reworked to reflect changes
> in SADB.
> - SADB_UPDATE message was extended to support new PF_KEY headers:
> SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST. They
> can be used by IKE daemon to change SA addresses.
> o ipsecrequest and secpolicy structures were cardinally changed to
> avoid locking protection for ipsecrequest. Now we support
> only limited number (4) of bundled SAs, but they are supported
> for both INET and INET6.
> o INPCB security policy cache was introduced. Each PCB now caches
> used security policies to avoid SP lookup for each packet.
> o For inbound security policies added the mode, when the kernel does
> check for full history of applied IPsec transforms.
> o References counting rules for security policies and security
> associations were changed. The proper SA locking added into xform
> code.
> o xform code was also changed. Now it is possible to unregister xforms.
> tdb_xxx structures were changed and renamed to reflect changes in
> SADB/SPDB, and changed rules for locking and refcounting.
>
> Obtained from: Yandex LLC
> Relnotes: yes
> Sponsored by: Yandex LLC
> Differential Revision: https://reviews.freebsd.org/D9352
>
> MFC r313331:
> Add removed headers into the ObsoleteFiles.inc.
>
> MFC r313561 (by glebius):
> Move tcp_fields_to_net() static inline into tcp_var.h, just below its
> friend tcp_fields_to_host(). There is third party code that also uses
> this inline.
>
> MFC r313697:
> Remove IPsec related PCB code from SCTP.
>
> The inpcb structure has inp_sp pointer that is initialized by
> ipsec_init_pcbpolicy() function. This pointer keeps strorage for IPsec
> security policies associated with a specific socket.
> An application can use IP_IPSEC_POLICY and IPV6_IPSEC_POLICY socket
> options to configure these security policies. Then ip[6]_output()
> uses inpcb pointer to specify that an outgoing packet is associated
> with some socket. And IPSEC_OUTPUT() method can use a security policy
> stored in the inp_sp. For inbound packet the protocol-specific input
> routine uses IPSEC_CHECK_POLICY() method to check that a packet conforms
> to inbound security policy configured in the inpcb.
>
> SCTP protocol doesn't specify inpcb for ip[6]_output() when it sends
> packets. Thus IPSEC_OUTPUT() method does not consider such packets as
> associated with some socket and can not apply security policies
> from inpcb, even if they are configured. Since IPSEC_CHECK_POLICY()
> method is called from protocol-specific input routine, it can specify
> inpcb pointer and associated with socket inbound policy will be
> checked. But there are two problems:
> 1. Such check is asymmetric, becasue we can not apply security policy
> from inpcb for outgoing packet.
> 2. IPSEC_CHECK_POLICY() expects that caller holds INPCB lock and
> access to inp_sp is protected. But for SCTP this is not correct,
> becasue SCTP uses own locks to protect inpcb.
>
> To fix these problems remove IPsec related PCB code from SCTP.
> This imply that IP_IPSEC_POLICY and IPV6_IPSEC_POLICY socket options
> will be not applicable to SCTP sockets. To be able correctly check
> inbound security policies for SCTP, mark its protocol header with
> the PR_LASTHDR flag.
>
> Differential Revision: https://reviews.freebsd.org/D9538
>
> MFC r313746:
> Add missing check to fix the build with IPSEC_SUPPORT and without MAC.
>
> MFC r313805:
> Fix LINT build for powerpc.
>
> Build kernel modules support only when both IPSEC and TCP_SIGNATURE
> are not defined.
>
> MFC r313922:
> For translated packets do not adjust UDP checksum if it is zero.
>
> In case when decrypted and decapsulated packet is an UDP datagram,
> check that its checksum is not zero before doing incremental checksum
> adjustment.
>
> MFC r314339:
> Document that the size of AH ICV for HMAC-SHA2-NNN should be half of
> NNN bits as described in RFC4868.
>
> PR: 215978
>
> MFC r314812:
> Introduce the concept of IPsec security policies scope.
>
> Currently are defined three scopes: global, ifnet, and pcb.
> Generic security policies that IKE daemon can add via PF_KEY interface
> or an administrator creates with setkey(8) utility have GLOBAL scope.
> Such policies can be applied by the kernel to outgoing packets and checked
> agains inbound packets after IPsec processing.
> Security policies created by if_ipsec(4) interfaces have IFNET scope.
> Such policies are applied to packets that are passed through if_ipsec(4)
> interface.
> And security policies created by application using setsockopt()
> IP_IPSEC_POLICY option have PCB scope. Such policies are applied to
> packets related to specific socket. Currently there is no way to list
> PCB policies via setkey(8) utility.
>
> Modify setkey(8) and libipsec(3) to be able distinguish the scope of
> security policies in the `setkey -DP` listing. Add two optional flags:
> '-t' to list only policies related to virtual *tunneling* interfaces,
> i.e. policies with IFNET scope, and '-g' to list only policies with GLOBAL
> scope. By default policies from all scopes are listed.
>
> To implement this PF_KEY's sadb_x_policy structure was modified.
> sadb_x_policy_reserved field is used to pass the policy scope from the
> kernel to userland. SADB_SPDDUMP message extended to support filtering
> by scope: sadb_msg_satype field is used to specify bit mask of requested
> scopes.
>
> For IFNET policies the sadb_x_policy_priority field of struct sadb_x_policy
> is used to pass if_ipsec's interface if_index to the userland. For GLOBAL
> policies sadb_x_policy_priority is used only to manage order of security
> policies in the SPDB. For IFNET policies it is not used, so it can be used
> to keep if_index.
>
> After this change the output of `setkey -DP` now looks like:
> # setkey -DPt
> 0.0.0.0/0[any] 0.0.0.0/0[any] any
> in ipsec
> esp/tunnel/87.250.242.144-87.250.242.145/unique:145
> spid=7 seq=3 pid=58025 scope=ifnet ifname=ipsec0
> refcnt=1
> # setkey -DPg
> ::/0 ::/0 icmp6 135,0
> out none
> spid=5 seq=1 pid=872 scope=global
> refcnt=1
>
> Obtained from: Yandex LLC
> Sponsored by: Yandex LLC
> Differential Revision: https://reviews.freebsd.org/D9805
>
> PR: 212018
> Relnotes: yes
> Sponsored by: Yandex LLC
>
> Added:
> stable/11/sbin/ifconfig/ifipsec.c
> - copied unchanged from r313330, head/sbin/ifconfig/ifipsec.c
> stable/11/share/man/man4/if_ipsec.4
> - copied unchanged from r313330, head/share/man/man4/if_ipsec.4
> stable/11/sys/modules/ipsec/
> - copied from r313330, head/sys/modules/ipsec/
> stable/11/sys/modules/tcp/tcpmd5/
> - copied from r313330, head/sys/modules/tcp/tcpmd5/
> stable/11/sys/net/if_ipsec.c
> - copied, changed from r313330, head/sys/net/if_ipsec.c
> stable/11/sys/net/if_ipsec.h
> - copied unchanged from r313330, head/sys/net/if_ipsec.h
> stable/11/sys/netipsec/ipsec_mod.c
> - copied unchanged from r313330, head/sys/netipsec/ipsec_mod.c
> stable/11/sys/netipsec/ipsec_pcb.c
> - copied unchanged from r313330, head/sys/netipsec/ipsec_pcb.c
> stable/11/sys/netipsec/ipsec_support.h
> - copied unchanged from r313330, head/sys/netipsec/ipsec_support.h
> stable/11/sys/netipsec/subr_ipsec.c
> - copied, changed from r313330, head/sys/netipsec/subr_ipsec.c
> stable/11/sys/netipsec/udpencap.c
> - copied, changed from r313330, head/sys/netipsec/udpencap.c
> Deleted:
> stable/11/sys/netinet/ip_ipsec.c
> stable/11/sys/netinet/ip_ipsec.h
> stable/11/sys/netinet6/ip6_ipsec.c
> stable/11/sys/netinet6/ip6_ipsec.h
> Modified:
> stable/11/ObsoleteFiles.inc
> stable/11/contrib/netcat/netcat.c
> stable/11/lib/libipsec/pfkey.c
> stable/11/lib/libipsec/pfkey_dump.c
> stable/11/sbin/ifconfig/Makefile
> stable/11/sbin/ipfw/ipfw.8
> stable/11/sbin/setkey/setkey.8
> stable/11/sbin/setkey/setkey.c
> stable/11/share/man/man4/Makefile
> stable/11/share/man/man4/ipsec.4
> stable/11/share/man/man4/tcp.4
> stable/11/share/man/man4/udp.4
> stable/11/sys/conf/NOTES
> stable/11/sys/conf/files
> stable/11/sys/conf/files.amd64
> stable/11/sys/conf/files.arm
> stable/11/sys/conf/files.arm64
> stable/11/sys/conf/files.i386
> stable/11/sys/conf/files.mips
> stable/11/sys/conf/files.pc98
> stable/11/sys/conf/files.powerpc
> stable/11/sys/conf/files.riscv
> stable/11/sys/conf/files.sparc64
> stable/11/sys/conf/kern.opts.mk
> stable/11/sys/conf/options
> stable/11/sys/libkern/arc4random.c
> stable/11/sys/modules/Makefile
> stable/11/sys/net/pfkeyv2.h
> stable/11/sys/netinet/in_pcb.c
> stable/11/sys/netinet/in_proto.c
> stable/11/sys/netinet/ip_input.c
> stable/11/sys/netinet/ip_output.c
> stable/11/sys/netinet/raw_ip.c
> stable/11/sys/netinet/sctp_input.c
> stable/11/sys/netinet/sctp_os_bsd.h
> stable/11/sys/netinet/sctp_pcb.c
> stable/11/sys/netinet/tcp_input.c
> stable/11/sys/netinet/tcp_output.c
> stable/11/sys/netinet/tcp_stacks/fastpath.c
> stable/11/sys/netinet/tcp_subr.c
> stable/11/sys/netinet/tcp_syncache.c
> stable/11/sys/netinet/tcp_usrreq.c
> stable/11/sys/netinet/tcp_var.h
> stable/11/sys/netinet/udp.h
> stable/11/sys/netinet/udp_usrreq.c
> stable/11/sys/netinet6/in6.h
> stable/11/sys/netinet6/in6_proto.c
> stable/11/sys/netinet6/ip6_forward.c
> stable/11/sys/netinet6/ip6_input.c
> stable/11/sys/netinet6/ip6_output.c
> stable/11/sys/netinet6/raw_ip6.c
> stable/11/sys/netinet6/sctp6_usrreq.c
> stable/11/sys/netinet6/udp6_usrreq.c
> stable/11/sys/netipsec/ipsec.c
> stable/11/sys/netipsec/ipsec.h
> stable/11/sys/netipsec/ipsec6.h
> stable/11/sys/netipsec/ipsec_input.c
> stable/11/sys/netipsec/ipsec_mbuf.c
> stable/11/sys/netipsec/ipsec_output.c
> stable/11/sys/netipsec/key.c
> stable/11/sys/netipsec/key.h
> stable/11/sys/netipsec/key_debug.c
> stable/11/sys/netipsec/key_debug.h
> stable/11/sys/netipsec/keydb.h
> stable/11/sys/netipsec/keysock.c
> stable/11/sys/netipsec/xform.h
> stable/11/sys/netipsec/xform_ah.c
> stable/11/sys/netipsec/xform_esp.c
> stable/11/sys/netipsec/xform_ipcomp.c
> stable/11/sys/netipsec/xform_tcp.c
> stable/11/usr.bin/netstat/inet.c
> Directory Properties:
> stable/11/ (props changed)
>
> Modified: stable/11/ObsoleteFiles.inc
> ==============================================================================
> --- stable/11/ObsoleteFiles.inc Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/ObsoleteFiles.inc Sat Mar 18 22:04:20 2017 (r315514)
> @@ -45,6 +45,9 @@ OLD_FILES+=usr/tests/sys/geom/class/gate
> OLD_FILES+=usr/tests/sys/geom/class/gate/conf.sh
> # 20170211: libarchive ACL pax test renamed to test_acl_pax_posix1e.tar.uu
> OLD_FILES+=usr/tests/lib/libarchive/test_acl_pax.tar.uu
> +# 20170206: merged projects/ipsec
> +OLD_FILES+=usr/include/netinet/ip_ipsec.h
> +OLD_FILES+=usr/include/netinet6/ip6_ipsec.h
> # 20170103: libbsnmptools.so made into an INTERNALLIB
> OLD_FILES+=usr/lib/libbsnmptools.a
> OLD_FILES+=usr/lib/libbsnmptools_p.a
>
> Modified: stable/11/contrib/netcat/netcat.c
> ==============================================================================
> --- stable/11/contrib/netcat/netcat.c Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/contrib/netcat/netcat.c Sat Mar 18 22:04:20 2017 (r315514)
> @@ -131,7 +131,7 @@ ssize_t drainbuf(int, unsigned char *, s
> ssize_t fillbuf(int, unsigned char *, size_t *);
>
> #ifdef IPSEC
> -void add_ipsec_policy(int, char *);
> +void add_ipsec_policy(int, int, char *);
>
> char *ipsec_policy[2];
> #endif
> @@ -642,12 +642,6 @@ remote_connect(const char *host, const c
> if ((s = socket(res0->ai_family, res0->ai_socktype,
> res0->ai_protocol)) < 0)
> continue;
> -#ifdef IPSEC
> - if (ipsec_policy[0] != NULL)
> - add_ipsec_policy(s, ipsec_policy[0]);
> - if (ipsec_policy[1] != NULL)
> - add_ipsec_policy(s, ipsec_policy[1]);
> -#endif
>
> if (rtableid >= 0 && (setsockopt(s, SOL_SOCKET, SO_SETFIB,
> &rtableid, sizeof(rtableid)) == -1))
> @@ -765,12 +759,7 @@ local_listen(char *host, char *port, str
> ret = setsockopt(s, SOL_SOCKET, SO_REUSEPORT, &x, sizeof(x));
> if (ret == -1)
> err(1, NULL);
> -#ifdef IPSEC
> - if (ipsec_policy[0] != NULL)
> - add_ipsec_policy(s, ipsec_policy[0]);
> - if (ipsec_policy[1] != NULL)
> - add_ipsec_policy(s, ipsec_policy[1]);
> -#endif
> +
> if (FreeBSD_Oflag) {
> if (setsockopt(s, IPPROTO_TCP, TCP_NOOPT,
> &FreeBSD_Oflag, sizeof(FreeBSD_Oflag)) == -1)
> @@ -1235,6 +1224,12 @@ set_common_sockopts(int s, int af)
> &FreeBSD_Oflag, sizeof(FreeBSD_Oflag)) == -1)
> err(1, "disable TCP options");
> }
> +#ifdef IPSEC
> + if (ipsec_policy[0] != NULL)
> + add_ipsec_policy(s, af, ipsec_policy[0]);
> + if (ipsec_policy[1] != NULL)
> + add_ipsec_policy(s, af, ipsec_policy[1]);
> +#endif
> }
>
> int
> @@ -1360,7 +1355,7 @@ help(void)
>
> #ifdef IPSEC
> void
> -add_ipsec_policy(int s, char *policy)
> +add_ipsec_policy(int s, int af, char *policy)
> {
> char *raw;
> int e;
> @@ -1369,8 +1364,12 @@ add_ipsec_policy(int s, char *policy)
> if (raw == NULL)
> errx(1, "ipsec_set_policy `%s': %s", policy,
> ipsec_strerror());
> - e = setsockopt(s, IPPROTO_IP, IP_IPSEC_POLICY, raw,
> - ipsec_get_policylen(raw));
> + if (af == AF_INET)
> + e = setsockopt(s, IPPROTO_IP, IP_IPSEC_POLICY, raw,
> + ipsec_get_policylen(raw));
> + if (af == AF_INET6)
> + e = setsockopt(s, IPPROTO_IPV6, IPV6_IPSEC_POLICY, raw,
> + ipsec_get_policylen(raw));
> if (e < 0)
> err(1, "ipsec policy cannot be configured");
> free(raw);
>
> Modified: stable/11/lib/libipsec/pfkey.c
> ==============================================================================
> --- stable/11/lib/libipsec/pfkey.c Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/lib/libipsec/pfkey.c Sat Mar 18 22:04:20 2017 (r315514)
> @@ -1776,20 +1776,17 @@ pfkey_align(msg, mhp)
> case SADB_EXT_SPIRANGE:
> case SADB_X_EXT_POLICY:
> case SADB_X_EXT_SA2:
> - mhp[ext->sadb_ext_type] = (caddr_t)ext;
> - break;
> case SADB_X_EXT_NAT_T_TYPE:
> case SADB_X_EXT_NAT_T_SPORT:
> case SADB_X_EXT_NAT_T_DPORT:
> - /* case SADB_X_EXT_NAT_T_OA: is OAI */
> case SADB_X_EXT_NAT_T_OAI:
> case SADB_X_EXT_NAT_T_OAR:
> case SADB_X_EXT_NAT_T_FRAG:
> - if (feature_present("ipsec_natt")) {
> - mhp[ext->sadb_ext_type] = (caddr_t)ext;
> - break;
> - }
> - /* FALLTHROUGH */
> + case SADB_X_EXT_SA_REPLAY:
> + case SADB_X_EXT_NEW_ADDRESS_SRC:
> + case SADB_X_EXT_NEW_ADDRESS_DST:
> + mhp[ext->sadb_ext_type] = (caddr_t)ext;
> + break;
> default:
> __ipsec_errcode = EIPSEC_INVAL_EXTTYPE;
> return -1;
>
> Modified: stable/11/lib/libipsec/pfkey_dump.c
> ==============================================================================
> --- stable/11/lib/libipsec/pfkey_dump.c Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/lib/libipsec/pfkey_dump.c Sat Mar 18 22:04:20 2017 (r315514)
> @@ -35,8 +35,9 @@ __FBSDID("$FreeBSD$");
> #include <sys/types.h>
> #include <sys/param.h>
> #include <sys/socket.h>
> -#include <netipsec/ipsec.h>
> +#include <net/if.h>
> #include <net/pfkeyv2.h>
> +#include <netipsec/ipsec.h>
> #include <netipsec/key_var.h>
> #include <netipsec/key_debug.h>
>
> @@ -204,6 +205,13 @@ static struct val2str str_alg_comp[] = {
> { -1, NULL, },
> };
>
> +static struct val2str str_sp_scope[] = {
> + { IPSEC_POLICYSCOPE_GLOBAL, "global" },
> + { IPSEC_POLICYSCOPE_IFNET, "ifnet" },
> + { IPSEC_POLICYSCOPE_PCB, "pcb"},
> + { -1, NULL },
> +};
> +
> /*
> * dump SADB_MSG formated. For debugging, you should use kdebug_sadb().
> */
> @@ -219,6 +227,10 @@ pfkey_sadump(m)
> struct sadb_key *m_auth, *m_enc;
> struct sadb_ident *m_sid, *m_did;
> struct sadb_sens *m_sens;
> + struct sadb_x_sa_replay *m_sa_replay;
> + struct sadb_x_nat_t_type *natt_type;
> + struct sadb_x_nat_t_port *natt_sport, *natt_dport;
> + struct sadb_address *natt_oai, *natt_oar;
>
> /* check pfkey message. */
> if (pfkey_align(m, mhp)) {
> @@ -243,33 +255,47 @@ pfkey_sadump(m)
> m_sid = (struct sadb_ident *)mhp[SADB_EXT_IDENTITY_SRC];
> m_did = (struct sadb_ident *)mhp[SADB_EXT_IDENTITY_DST];
> m_sens = (struct sadb_sens *)mhp[SADB_EXT_SENSITIVITY];
> + m_sa_replay = (struct sadb_x_sa_replay *)mhp[SADB_X_EXT_SA_REPLAY];
> + natt_type = (struct sadb_x_nat_t_type *)mhp[SADB_X_EXT_NAT_T_TYPE];
> + natt_sport = (struct sadb_x_nat_t_port *)mhp[SADB_X_EXT_NAT_T_SPORT];
> + natt_dport = (struct sadb_x_nat_t_port *)mhp[SADB_X_EXT_NAT_T_DPORT];
> + natt_oai = (struct sadb_address *)mhp[SADB_X_EXT_NAT_T_OAI];
> + natt_oar = (struct sadb_address *)mhp[SADB_X_EXT_NAT_T_OAR];
> +
>
> /* source address */
> if (m_saddr == NULL) {
> printf("no ADDRESS_SRC extension.\n");
> return;
> }
> - printf("%s ", str_ipaddr((struct sockaddr *)(m_saddr + 1)));
> + printf("%s", str_ipaddr((struct sockaddr *)(m_saddr + 1)));
> + if (natt_type != NULL && natt_sport != NULL)
> + printf("[%u]", ntohs(natt_sport->sadb_x_nat_t_port_port));
>
> /* destination address */
> if (m_daddr == NULL) {
> - printf("no ADDRESS_DST extension.\n");
> + printf("\nno ADDRESS_DST extension.\n");
> return;
> }
> - printf("%s ", str_ipaddr((struct sockaddr *)(m_daddr + 1)));
> + printf(" %s", str_ipaddr((struct sockaddr *)(m_daddr + 1)));
> + if (natt_type != NULL && natt_dport != NULL)
> + printf("[%u]", ntohs(natt_dport->sadb_x_nat_t_port_port));
>
> /* SA type */
> if (m_sa == NULL) {
> - printf("no SA extension.\n");
> + printf("\nno SA extension.\n");
> return;
> }
> if (m_sa2 == NULL) {
> - printf("no SA2 extension.\n");
> + printf("\nno SA2 extension.\n");
> return;
> }
> printf("\n\t");
>
> - GETMSGSTR(str_satype, m->sadb_msg_satype);
> + if (m->sadb_msg_satype == SADB_SATYPE_ESP && natt_type != NULL)
> + printf("esp-udp ");
> + else
> + GETMSGSTR(str_satype, m->sadb_msg_satype);
>
> printf("mode=");
> GETMSGSTR(str_mode, m_sa2->sadb_x_sa2_mode);
> @@ -280,6 +306,18 @@ pfkey_sadump(m)
> (u_int32_t)m_sa2->sadb_x_sa2_reqid,
> (u_int32_t)m_sa2->sadb_x_sa2_reqid);
>
> + /* other NAT-T information */
> + if (natt_type != NULL && (natt_oai != NULL || natt_oar != NULL)) {
> + printf("\tNAT:");
> + if (natt_oai != NULL)
> + printf(" OAI=%s",
> + str_ipaddr((struct sockaddr *)(natt_oai + 1)));
> + if (natt_oar != NULL)
> + printf(" OAR=%s",
> + str_ipaddr((struct sockaddr *)(natt_oar + 1)));
> + printf("\n");
> + }
> +
> /* encryption key */
> if (m->sadb_msg_satype == SADB_X_SATYPE_IPCOMP) {
> printf("\tC: ");
> @@ -306,7 +344,8 @@ pfkey_sadump(m)
> /* replay windoe size & flags */
> printf("\tseq=0x%08x replay=%u flags=0x%08x ",
> m_sa2->sadb_x_sa2_sequence,
> - m_sa->sadb_sa_replay,
> + m_sa_replay ? (m_sa_replay->sadb_x_sa_replay_replay >> 3) :
> + m_sa->sadb_sa_replay,
> m_sa->sadb_sa_flags);
>
> /* state */
> @@ -367,8 +406,7 @@ pfkey_sadump(m)
> }
>
> void
> -pfkey_spdump(m)
> - struct sadb_msg *m;
> +pfkey_spdump(struct sadb_msg *m)
> {
> char pbuf[NI_MAXSERV];
> caddr_t mhp[SADB_EXT_MAX + 1];
> @@ -476,10 +514,15 @@ pfkey_spdump(m)
> }
>
>
> - printf("\tspid=%ld seq=%ld pid=%ld\n",
> + printf("\tspid=%ld seq=%ld pid=%ld scope=",
> (u_long)m_xpl->sadb_x_policy_id,
> (u_long)m->sadb_msg_seq,
> (u_long)m->sadb_msg_pid);
> + GETMSGV2S(str_sp_scope, m_xpl->sadb_x_policy_scope);
> + if (m_xpl->sadb_x_policy_scope == IPSEC_POLICYSCOPE_IFNET &&
> + if_indextoname(m_xpl->sadb_x_policy_ifindex, pbuf) != NULL)
> + printf("ifname=%s", pbuf);
> + printf("\n");
>
> /* XXX TEST */
> printf("\trefcnt=%u\n", m->sadb_msg_reserved);
>
> Modified: stable/11/sbin/ifconfig/Makefile
> ==============================================================================
> --- stable/11/sbin/ifconfig/Makefile Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/sbin/ifconfig/Makefile Sat Mar 18 22:04:20 2017 (r315514)
> @@ -34,6 +34,7 @@ SRCS+= ifvlan.c # SIOC[GS]ETVLAN suppor
> SRCS+= ifvxlan.c # VXLAN support
> SRCS+= ifgre.c # GRE keys etc
> SRCS+= ifgif.c # GIF reversed header workaround
> +SRCS+= ifipsec.c # IPsec VTI
>
> SRCS+= sfp.c # SFP/SFP+ information
> LIBADD+= m
>
> Copied: stable/11/sbin/ifconfig/ifipsec.c (from r313330, head/sbin/ifconfig/ifipsec.c)
> ==============================================================================
> --- /dev/null 00:00:00 1970 (empty, because file is newly added)
> +++ stable/11/sbin/ifconfig/ifipsec.c Sat Mar 18 22:04:20 2017 (r315514, copy of r313330, head/sbin/ifconfig/ifipsec.c)
> @@ -0,0 +1,101 @@
> +/*-
> + * Copyright (c) 2016 Yandex LLC
> + * Copyright (c) 2016 Andrey V. Elsukov <ae@FreeBSD.org>
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + * 1. Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in the
> + * documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
> + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include <sys/cdefs.h>
> +__FBSDID("$FreeBSD$");
> +
> +#include <sys/param.h>
> +#include <sys/ioctl.h>
> +#include <sys/socket.h>
> +#include <sys/sockio.h>
> +#include <sys/stdint.h>
> +
> +#include <stdlib.h>
> +#include <unistd.h>
> +
> +#include <net/ethernet.h>
> +#include <net/if.h>
> +#include <net/if_ipsec.h>
> +#include <net/route.h>
> +
> +#include <ctype.h>
> +#include <stdio.h>
> +#include <string.h>
> +#include <err.h>
> +#include <errno.h>
> +
> +#include "ifconfig.h"
> +
> +static void
> +ipsec_status(int s)
> +{
> + uint32_t reqid;
> +
> + ifr.ifr_data = (caddr_t)&reqid;
> + if (ioctl(s, IPSECGREQID, &ifr) == -1)
> + return;
> + printf("\treqid: %u\n", reqid);
> +}
> +
> +static
> +DECL_CMD_FUNC(setreqid, val, arg)
> +{
> + char *ep;
> + uint32_t v;
> +
> + v = strtoul(val, &ep, 0);
> + if (*ep != '\0') {
> + warn("Invalid reqid value %s", val);
> + return;
> + }
> + ifr.ifr_data = (char *)&v;
> + if (ioctl(s, IPSECSREQID, &ifr) == -1) {
> + warn("ioctl(IPSECSREQID)");
> + return;
> + }
> +}
> +
> +static struct cmd ipsec_cmds[] = {
> + DEF_CMD_ARG("reqid", setreqid),
> +};
> +
> +static struct afswtch af_ipsec = {
> + .af_name = "af_ipsec",
> + .af_af = AF_UNSPEC,
> + .af_other_status = ipsec_status,
> +};
> +
> +static __constructor void
> +ipsec_ctor(void)
> +{
> + size_t i;
> +
> + for (i = 0; i < nitems(ipsec_cmds); i++)
> + cmd_register(&ipsec_cmds[i]);
> + af_register(&af_ipsec);
> +#undef N
> +}
>
> Modified: stable/11/sbin/ipfw/ipfw.8
> ==============================================================================
> --- stable/11/sbin/ipfw/ipfw.8 Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/sbin/ipfw/ipfw.8 Sat Mar 18 22:04:20 2017 (r315514)
> @@ -1518,8 +1518,7 @@ Matches IPv4 packets whose precedence fi
> .It Cm ipsec
> Matches packets that have IPSEC history associated with them
> (i.e., the packet comes encapsulated in IPSEC, the kernel
> -has IPSEC support and IPSEC_FILTERTUNNEL option, and can correctly
> -decapsulate it).
> +has IPSEC support, and can correctly decapsulate it).
> .Pp
> Note that specifying
> .Cm ipsec
>
> Modified: stable/11/sbin/setkey/setkey.8
> ==============================================================================
> --- stable/11/sbin/setkey/setkey.8 Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/sbin/setkey/setkey.8 Sat Mar 18 22:04:20 2017 (r315514)
> @@ -29,7 +29,7 @@
> .\"
> .\" $FreeBSD$
> .\"
> -.Dd October 3, 2016
> +.Dd March 7, 2017
> .Dt SETKEY 8
> .Os
> .\"
> @@ -45,7 +45,7 @@
> .Op Fl v
> .Fl f Ar filename
> .Nm
> -.Op Fl aPlv
> +.Op Fl Pgltv
> .Fl D
> .Nm
> .Op Fl Pv
> @@ -81,18 +81,21 @@ Flush the SAD entries.
> If with
> .Fl P ,
> the SPD entries are flushed.
> -.It Fl a
> -The
> -.Nm
> -utility
> -usually does not display dead SAD entries with
> -.Fl D .
> -If with
> -.Fl a ,
> -the dead SAD entries will be displayed as well.
> -A dead SAD entry means that
> -it has been expired but remains in the system
> -because it is referenced by some SPD entries.
> +.It Fl g
> +Only SPD entries with global scope are dumped with
> +.Fl D
> +and
> +.Fl P
> +flags.
> +.It Fl t
> +Only SPD entries with ifnet scope are dumped with
> +.Fl D
> +and
> +.Fl P
> +flags.
> +Such SPD entries are linked to the corresponding
> +.Xr if_ipsec 4
> +virtual tunneling interface.
> .It Fl h
> Add hexadecimal dump on
> .Fl x
> @@ -270,8 +273,6 @@ must be a decimal number, or a hexadecim
> prefix.
> SPI values between 0 and 255 are reserved for future use by IANA
> and they cannot be used.
> -TCP-MD5 associations must use 0x1000 and therefore only have per-host
> -granularity at this time.
> .\"
> .Pp
> .It Ar extensions
> @@ -595,12 +596,11 @@ keyed-md5 128 ah: 96bit ICV (no documen
> keyed-sha1 160 ah: 96bit ICV (no document)
> 160 ah-old: 128bit ICV (no document)
> null 0 to 2048 for debugging
> -hmac-sha2-256 256 ah: 96bit ICV
> - (draft-ietf-ipsec-ciph-sha-256-00)
> +hmac-sha2-256 256 ah: 128bit ICV (RFC4868)
> 256 ah-old: 128bit ICV (no document)
> -hmac-sha2-384 384 ah: 96bit ICV (no document)
> +hmac-sha2-384 384 ah: 192bit ICV (RFC4868)
> 384 ah-old: 128bit ICV (no document)
> -hmac-sha2-512 512 ah: 96bit ICV (no document)
> +hmac-sha2-512 512 ah: 256bit ICV (RFC4868)
> 512 ah-old: 128bit ICV (no document)
> hmac-ripemd160 160 ah: 96bit ICV (RFC2857)
> ah-old: 128bit ICV (no document)
> @@ -700,6 +700,7 @@ add 10.1.10.34 10.1.10.36 tcp 0x1000 -A
> .\"
> .Sh SEE ALSO
> .Xr ipsec_set_policy 3 ,
> +.Xr if_ipsec 4 ,
> .Xr racoon 8 ,
> .Xr sysctl 8
> .Rs
>
> Modified: stable/11/sbin/setkey/setkey.c
> ==============================================================================
> --- stable/11/sbin/setkey/setkey.c Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/sbin/setkey/setkey.c Sat Mar 18 22:04:20 2017 (r315514)
> @@ -56,7 +56,7 @@
> void usage(void);
> int main(int, char **);
> int get_supported(void);
> -void sendkeyshort(u_int);
> +void sendkeyshort(u_int, uint8_t);
> void promisc(void);
> int sendkeymsg(char *, size_t);
> int postproc(struct sadb_msg *, int);
> @@ -81,6 +81,7 @@ int f_cmddump = 0;
> int f_policy = 0;
> int f_hexdump = 0;
> int f_tflag = 0;
> +int f_scope = 0;
> static time_t thiszone;
>
> extern int lineno;
> @@ -93,7 +94,7 @@ usage()
>
> printf("usage: setkey [-v] -c\n");
> printf(" setkey [-v] -f filename\n");
> - printf(" setkey [-Palv] -D\n");
> + printf(" setkey [-Pagltv] -D\n");
> printf(" setkey [-Pv] -F\n");
> printf(" setkey [-h] -x\n");
> exit(1);
> @@ -114,7 +115,7 @@ main(ac, av)
>
> thiszone = gmt2local(0);
>
> - while ((c = getopt(ac, av, "acdf:hlvxDFP")) != -1) {
> + while ((c = getopt(ac, av, "acdf:ghltvxDFP")) != -1) {
> switch (c) {
> case 'c':
> f_mode = MODE_SCRIPT;
> @@ -149,6 +150,12 @@ main(ac, av)
> case 'P':
> f_policy = 1;
> break;
> + case 'g': /* global */
> + f_scope |= IPSEC_POLICYSCOPE_GLOBAL;
> + break;
> + case 't': /* tunnel */
> + f_scope |= IPSEC_POLICYSCOPE_IFNET;
> + break;
> case 'v':
> f_verbose = 1;
> break;
> @@ -166,10 +173,12 @@ main(ac, av)
>
> switch (f_mode) {
> case MODE_CMDDUMP:
> - sendkeyshort(f_policy ? SADB_X_SPDDUMP: SADB_DUMP);
> + sendkeyshort(f_policy ? SADB_X_SPDDUMP: SADB_DUMP,
> + f_policy ? f_scope: SADB_SATYPE_UNSPEC);
> break;
> case MODE_CMDFLUSH:
> - sendkeyshort(f_policy ? SADB_X_SPDFLUSH: SADB_FLUSH);
> + sendkeyshort(f_policy ? SADB_X_SPDFLUSH: SADB_FLUSH,
> + SADB_SATYPE_UNSPEC);
> break;
> case MODE_SCRIPT:
> if (get_supported() < 0) {
> @@ -204,15 +213,14 @@ get_supported()
> }
>
> void
> -sendkeyshort(type)
> - u_int type;
> +sendkeyshort(u_int type, uint8_t satype)
> {
> struct sadb_msg msg;
>
> msg.sadb_msg_version = PF_KEY_V2;
> msg.sadb_msg_type = type;
> msg.sadb_msg_errno = 0;
> - msg.sadb_msg_satype = SADB_SATYPE_UNSPEC;
> + msg.sadb_msg_satype = satype;
> msg.sadb_msg_len = PFKEY_UNIT64(sizeof(msg));
> msg.sadb_msg_reserved = 0;
> msg.sadb_msg_seq = 0;
>
> Modified: stable/11/share/man/man4/Makefile
> ==============================================================================
> --- stable/11/share/man/man4/Makefile Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/share/man/man4/Makefile Sat Mar 18 22:04:20 2017 (r315514)
> @@ -202,6 +202,7 @@ MAN= aac.4 \
> icmp.4 \
> icmp6.4 \
> ida.4 \
> + if_ipsec.4 \
> ifmib.4 \
> ig4.4 \
> igb.4 \
>
> Copied: stable/11/share/man/man4/if_ipsec.4 (from r313330, head/share/man/man4/if_ipsec.4)
> ==============================================================================
> --- /dev/null 00:00:00 1970 (empty, because file is newly added)
> +++ stable/11/share/man/man4/if_ipsec.4 Sat Mar 18 22:04:20 2017 (r315514, copy of r313330, head/share/man/man4/if_ipsec.4)
> @@ -0,0 +1,141 @@
> +.\" Copyright (c) 2017 Andrey V. Elsukov <ae@FreeBSD.org>
> +.\" All rights reserved.
> +.\"
> +.\" Redistribution and use in source and binary forms, with or without
> +.\" modification, are permitted provided that the following conditions
> +.\" are met:
> +.\" 1. Redistributions of source code must retain the above copyright
> +.\" notice, this list of conditions and the following disclaimer.
> +.\" 2. Redistributions in binary form must reproduce the above copyright
> +.\" notice, this list of conditions and the following disclaimer in the
> +.\" documentation and/or other materials provided with the distribution.
> +.\"
> +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND
> +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE
> +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> +.\" SUCH DAMAGE.
> +.\"
> +.\" $FreeBSD$
> +.\"
> +.Dd February 6, 2017
> +.Dt if_ipsec 4
> +.Os
> +.Sh NAME
> +.Nm if_ipsec
> +.Nd IPsec virtual tunneling interface
> +.Sh SYNOPSIS
> +The
> +.Cm if_ipsec
> +network interface is a part of the
> +.Fx
> +IPsec implementation.
> +To compile it into the kernel, place this line in the kernel
> +configuration file:
> +.Bd -ragged -offset indent
> +.Cd "options IPSEC"
> +.Ed
> +.Pp
> +It can also be loaded as part of the
> +.Cm ipsec
> +kernel module if the kernel was compiled with
> +.Bd -ragged -offset indent
> +.Cd "options IPSEC_SUPPORT"
> +.Ed
> +.Sh DESCRIPTION
> +The
> +.Nm
> +network interface is targeted for creating route-based VPNs.
> +It can tunnel IPv4 and IPv6 traffic over either IPv4 or IPv6 and secure
> +it with ESP.
> +.Pp
> +.Nm
> +interfaces are dynamically created and destroyed with the
> +.Xr ifconfig 8
> +.Cm create
> +and
> +.Cm destroy
> +subcommands.
> +The administrator must configure IPsec
> +.Cm tunnel
> +endpoint addresses.
> +These addresses will be used for the outer IP header of ESP packets.
> +The administrator can also configure the protocol and addresses for the inner
> +IP header with
> +.Xr ifconfig 8 ,
> +and modify the routing table to route the packets through the
> +.Nm
> +interface.
> +.Pp
> +When the
> +.Nm
> +interface is configured, it automatically creates special security policies.
> +These policies can be used to acquire security associations from the IKE daemon,
> +which are needed for establishing an IPsec tunnel.
> +It is also possible to create needed security associations manually with the
> +.Xr setkey 8
> +utility.
> +.Pp
> +Each
> +.Nm
> +interface has an additional numeric configuration option
> +.Cm reqid Ar id .
> +This
> +.Ar id
> +is used to distinguish traffic and security policies between several
> +.Nm
> +interfaces.
> +The
> +.Cm reqid
> +can be specified on interface creation and changed later.
> +If not specified, it is automatically assigned.
> +Note that changing
> +.Cm reqid
> +will lead to generation of new security policies, and this
> +may require creating new security associations.
> +.Sh EXAMPLES
> +The example below shows manual configuration of an IPsec tunnel
> +between two FreeBSD hosts.
> +Host A has the IP address 192.168.0.3, and host B has the IP address
> +192.168.0.5.
> +.Pp
> +On host A:
> +.Bd -literal -offset indent
> +ifconfig ipsec0 create reqid 100
> +ifconfig ipsec0 inet tunnel 192.168.0.3 192.168.0.5
> +ifconfig ipsec0 inet 172.16.0.3/16 172.16.0.5
> +setkey -c
> +add 192.168.0.3 192.168.0.5 esp 10000 -m tunnel -u 100 -E rijndael-cbc "VerySecureKey!!1";
> +add 192.168.0.5 192.168.0.3 esp 10001 -m tunnel -u 100 -E rijndael-cbc "VerySecureKey!!2";
> +^D
> +.Ed
> +.Pp
> +On host B:
> +.Bd -literal -offset indent
> +ifconfig ipsec0 create reqid 200
> +ifconfig ipsec0 inet tunnel 192.168.0.5 192.168.0.3
> +ifconfig ipsec0 inet 172.16.0.5/16 172.16.0.3
> +setkey -c
> +add 192.168.0.3 192.168.0.5 esp 10000 -m tunnel -u 200 -E rijndael-cbc "VerySecureKey!!1";
> +add 192.168.0.5 192.168.0.3 esp 10001 -m tunnel -u 200 -E rijndael-cbc "VerySecureKey!!2";
> +^D
> +.Ed
> +.Pp
> +Note the value 100 on host A and value 200 on host B are used as reqid.
> +The same value must be used as identifier of the policy entry in the
> +.Xr setkey 8
> +command.
> +.Sh SEE ALSO
> +.Xr gif 4 ,
> +.Xr gre 4 ,
> +.Xr ipsec 4 ,
> +.Xr ifconfig 8 ,
> +.Xr setkey 8
> +.Sh AUTHORS
> +.An Andrey V. Elsukov Aq Mt ae@FreeBSD.org
>
> Modified: stable/11/share/man/man4/ipsec.4
> ==============================================================================
> --- stable/11/share/man/man4/ipsec.4 Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/share/man/man4/ipsec.4 Sat Mar 18 22:04:20 2017 (r315514)
> @@ -29,7 +29,7 @@
> .\"
> .\" $FreeBSD$
> .\"
> -.Dd November 29, 2009
> +.Dd February 6, 2017
> .Dt IPSEC 4
> .Os
> .Sh NAME
> @@ -37,6 +37,7 @@
> .Nd Internet Protocol Security protocol
> .Sh SYNOPSIS
> .Cd "options IPSEC"
> +.Cd "options IPSEC_SUPPORT"
> .Cd "device crypto"
> .Pp
> .In sys/types.h
> @@ -151,6 +152,16 @@ Refer to
> .Xr setkey 8
> on how to use it.
> .Pp
> +Depending on the socket's address family, IPPROTO_IP or IPPROTO_IPV6
> +transport level and IP_IPSEC_POLICY or IPV6_IPSEC_POLICY socket options
> +may be used to configure per-socket security policies.
> +A properly-formed IPsec policy specification structure can be
> +created using
> +.Xr ipsec_set_policy 3
> +function and used as socket option value for the
> +.Xr setsockopt 2
> +call.
> +.Pp
> When setting policies using the
> .Xr setkey 8
> command, the
> @@ -228,6 +239,8 @@ for tweaking the kernel's IPsec behavior
> .It "net.inet.ipsec.dfbit integer yes"
> .It "net.inet.ipsec.ecn integer yes"
> .It "net.inet.ipsec.debug integer yes"
> +.It "net.inet.ipsec.natt_cksum_policy integer yes"
> +.It "net.inet.ipsec.check_policy_history integer yes"
> .It "net.inet6.ipsec6.ecn integer yes"
> .It "net.inet6.ipsec6.debug integer yes"
> .El
> @@ -270,6 +283,23 @@ talks more about the behavior.
> .It Li ipsec.debug
> If set to non-zero, debug messages will be generated via
> .Xr syslog 3 .
> +.It Li ipsec.natt_cksum_policy
> +Controls how the kernel handles TCP and UDP checksums when ESP in UDP
> +encapsulation is used for IPsec transport mode.
> +If set to a non-zero value, the kernel fully recomputes checksums for
> +inbound TCP segments and UDP datagrams after they are decapsulated and
> +decrypted.
> +If set to 0 and original addresses were configured for corresponding SA
> +by the IKE daemon, the kernel incrementally recomputes checksums for
> +inbound TCP segments and UDP datagrams.
> +If addresses were not configured, the checksums are ignored.
> +.It Li ipsec.check_policy_history
> +Enables strict policy checking for inbound packets.
> +By default, inbound security policies check that packets handled by IPsec
> +have been decrypted and authenticated.
> +If this variable is set to a non-zero value, each packet handled by IPsec
> +is checked against the history of IPsec security associations.
> +The IPsec security protocol, mode, and SA addresses must match.
> .El
> .Pp
> Variables under the
> @@ -305,6 +335,7 @@ routines from looking into the IP payloa
> .Xr ipsec_set_policy 3 ,
> .Xr crypto 4 ,
> .Xr enc 4 ,
> +.Xr if_ipsec 4 ,
> .Xr icmp6 4 ,
> .Xr intro 4 ,
> .Xr ip6 4 ,
>
> Modified: stable/11/share/man/man4/tcp.4
> ==============================================================================
> --- stable/11/share/man/man4/tcp.4 Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/share/man/man4/tcp.4 Sat Mar 18 22:04:20 2017 (r315514)
> @@ -34,7 +34,7 @@
> .\" From: @(#)tcp.4 8.1 (Berkeley) 6/5/93
> .\" $FreeBSD$
> .\"
> -.Dd October 21, 2016
> +.Dd February 6, 2017
> .Dt TCP 4
> .Os
> .Sh NAME
> @@ -272,33 +272,27 @@ or the internal send buffer is filled.
> This option enables the use of MD5 digests (also known as TCP-MD5)
> on writes to the specified socket.
> Outgoing traffic is digested;
> -digests on incoming traffic are verified if the
> -.Va net.inet.tcp.signature_verify_input
> -sysctl is nonzero.
> -The current default behavior for the system is to respond to a system
> -advertising this option with TCP-MD5; this may change.
> +digests on incoming traffic are verified.
> +When this option is enabled on a socket, all inbound and outgoing
> +TCP segments must be signed with MD5 digests.
> .Pp
> One common use for this in a
> .Fx
> router deployment is to enable
> based routers to interwork with Cisco equipment at peering points.
> Support for this feature conforms to RFC 2385.
> -Only IPv4
> -.Pq Dv AF_INET
> -sessions are supported.
> .Pp
> In order for this option to function correctly, it is necessary for the
> administrator to add a tcp-md5 key entry to the system's security
> associations database (SADB) using the
> .Xr setkey 8
> utility.
> -This entry must have an SPI of 0x1000 and can therefore only be specified
> -on a per-host basis at this time.
> +This entry can only be specified on a per-host basis at this time.
> .Pp
> -If an SADB entry cannot be found for the destination, the outgoing traffic
> -will have an invalid digest option prepended, and the following error message
> -will be visible on the system console:
> -.Em "tcp_signature_compute: SADB lookup failed for %d.%d.%d.%d" .
> +If an SADB entry cannot be found for the destination,
> +the system does not send any outgoing segments and drops any inbound segments.
> +.Pp
> +Each dropped segment is taken into account in the TCP protocol statistics.
> .El
> .Pp
> The option level for the
>
> Modified: stable/11/share/man/man4/udp.4
> ==============================================================================
> --- stable/11/share/man/man4/udp.4 Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/share/man/man4/udp.4 Sat Mar 18 22:04:20 2017 (r315514)
> @@ -28,7 +28,7 @@
> .\" @(#)udp.4 8.1 (Berkeley) 6/5/93
> .\" $FreeBSD$
> .\"
> -.Dd June 5, 1993
> +.Dd February 6, 2017
> .Dt UDP 4
> .Os
> .Sh NAME
> @@ -99,6 +99,17 @@ transport level may be used with
> .Tn UDP ;
> see
> .Xr ip 4 .
> +.Tn UDP_ENCAP
> +socket option may be used at the
> +.Tn IPPROTO_UDP
> +level to encapsulate
> +.Tn ESP
> +packets in
> +.Tn UDP .
> +Only one value is supported for this option:
> +.Tn UDP_ENCAP_ESPINUDP
> +from RFC 3948, defined in
> +.In netinet/udp.h .
> .Sh MIB VARIABLES
> The
> .Nm
> @@ -158,7 +169,8 @@ exists.
> .Xr blackhole 4 ,
> .Xr inet 4 ,
> .Xr intro 4 ,
> -.Xr ip 4
> +.Xr ip 4 ,
> +.Xr udplite 4
> .Sh HISTORY
> The
> .Nm
>
> Modified: stable/11/sys/conf/NOTES
> ==============================================================================
> --- stable/11/sys/conf/NOTES Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/sys/conf/NOTES Sat Mar 18 22:04:20 2017 (r315514)
> @@ -613,23 +613,12 @@ options TCP_OFFLOAD # TCP offload supp
> # In order to enable IPSEC you MUST also add device crypto to
> # your kernel configuration
> options IPSEC #IP security (requires device crypto)
> +
> +# Option IPSEC_SUPPORT does not enable IPsec, but makes it possible to
> +# load it as a kernel module. You still MUST add device crypto to your kernel
> +# configuration.
> +options IPSEC_SUPPORT
> #options IPSEC_DEBUG #debug for IP security
> -#
> -# #DEPRECATED#
> -# Set IPSEC_FILTERTUNNEL to change the default of the sysctl to force packets
> -# coming through a tunnel to be processed by any configured packet filtering
> -# twice. The default is that packets coming out of a tunnel are _not_ processed;
> -# they are assumed trusted.
> -#
> -# IPSEC history is preserved for such packets, and can be filtered
> -# using ipfw(8)'s 'ipsec' keyword, when this option is enabled.
> -#
> -#options IPSEC_FILTERTUNNEL #filter ipsec packets from a tunnel
> -#
> -# Set IPSEC_NAT_T to enable NAT-Traversal support. This enables
> -# optional UDP encapsulation of ESP packets.
> -#
> -options IPSEC_NAT_T #NAT-T support, UDP encap of ESP
>
> #
> # SMB/CIFS requester
> @@ -1015,7 +1004,8 @@ options ACCEPT_FILTER_HTTP
> # carried in TCP option 19. This option is commonly used to protect
> # TCP sessions (e.g. BGP) where IPSEC is not available nor desirable.
> # This is enabled on a per-socket basis using the TCP_MD5SIG socket option.
> -# This requires the use of 'device crypto' and 'options IPSEC'.
> +# This requires the use of 'device crypto' and either 'options IPSEC' or
> +# 'options IPSEC_SUPPORT'.
> options TCP_SIGNATURE #include support for RFC 2385
>
> # DUMMYNET enables the "dummynet" bandwidth limiter. You need IPFIREWALL
>
> Modified: stable/11/sys/conf/files
> ==============================================================================
> --- stable/11/sys/conf/files Sat Mar 18 21:44:42 2017 (r315513)
> +++ stable/11/sys/conf/files Sat Mar 18 22:04:20 2017 (r315514)
> @@ -574,22 +574,24 @@ contrib/ngatm/netnatm/sig/sig_unimsgcpy.
> compile-with "${NORMAL_C} -I$S/contrib/ngatm"
> contrib/ngatm/netnatm/sig/sig_verify.c optional ngatm_uni \
> compile-with "${NORMAL_C} -I$S/contrib/ngatm"
> -crypto/blowfish/bf_ecb.c optional ipsec
> -crypto/blowfish/bf_skey.c optional crypto | ipsec
> -crypto/camellia/camellia.c optional crypto | ipsec
> -crypto/camellia/camellia-api.c optional crypto | ipsec
> -crypto/des/des_ecb.c optional crypto | ipsec | netsmb
> -crypto/des/des_setkey.c optional crypto | ipsec | netsmb
> +crypto/blowfish/bf_ecb.c optional ipsec | ipsec_support
> +crypto/blowfish/bf_skey.c optional crypto | ipsec | ipsec_support
> +crypto/camellia/camellia.c optional crypto | ipsec | ipsec_support
> +crypto/camellia/camellia-api.c optional crypto | ipsec | ipsec_support
> +crypto/des/des_ecb.c optional crypto | ipsec | ipsec_support | netsmb
> +crypto/des/des_setkey.c optional crypto | ipsec | ipsec_support | netsmb
> crypto/rc4/rc4.c optional netgraph_mppc_encryption | kgssapi
> crypto/rijndael/rijndael-alg-fst.c optional crypto | geom_bde | \
> - ipsec | random !random_loadable | wlan_ccmp
> + ipsec | ipsec_support | random !random_loadable | wlan_ccmp
> crypto/rijndael/rijndael-api-fst.c optional geom_bde | random !random_loadable
> -crypto/rijndael/rijndael-api.c optional crypto | ipsec | wlan_ccmp
> +crypto/rijndael/rijndael-api.c optional crypto | ipsec | ipsec_support | \
> + wlan_ccmp
> crypto/sha1.c optional carp | crypto | ipsec | \
> - netgraph_mppc_encryption | sctp
> -crypto/sha2/sha256c.c optional crypto | geom_bde | ipsec | random !random_loadable | \
> - sctp | zfs
> -crypto/sha2/sha512c.c optional crypto | geom_bde | ipsec | zfs
> + ipsec_support | netgraph_mppc_encryption | sctp
> +crypto/sha2/sha256c.c optional crypto | geom_bde | ipsec | \
> + ipsec_support | random !random_loadable | sctp | zfs
> +crypto/sha2/sha512c.c optional crypto | geom_bde | ipsec | \
> + ipsec_support | zfs
> crypto/skein/skein.c optional crypto | zfs
> crypto/skein/skein_block.c optional crypto | zfs
> crypto/siphash/siphash.c optional inet | inet6
> @@ -3592,8 +3594,7 @@ libkern/strtouq.c standard
> libkern/strvalid.c standard
> libkern/timingsafe_bcmp.c standard
> libkern/zlib.c optional crypto | geom_uzip | ipsec | \
> - mxge | netgraph_deflate | \
> - ddb_ctf | gzio
> + ipsec_support | mxge | netgraph_deflate | ddb_ctf | gzio
> net/altq/altq_cbq.c optional altq
> net/altq/altq_cdnr.c optional altq
> net/altq/altq_codel.c optional altq
> @@ -3629,6 +3630,7 @@ net/if_fwsubr.c optional fwip
> net/if_gif.c optional gif inet | gif inet6 | \
> netgraph_gif inet | netgraph_gif inet6
> net/if_gre.c optional gre inet | gre inet6
> +net/if_ipsec.c optional inet ipsec | inet6 ipsec
> net/if_iso88025subr.c optional token
> net/if_lagg.c optional lagg
> net/if_loop.c optional loop
> @@ -3814,7 +3816,6 @@ netinet/ip_encap.c optional inet | inet
> netinet/ip_fastfwd.c optional inet
> netinet/ip_icmp.c optional inet | inet6
> netinet/ip_input.c optional inet
> -netinet/ip_ipsec.c optional inet ipsec
> netinet/ip_mroute.c optional mrouting inet
> netinet/ip_options.c optional inet
> netinet/ip_output.c optional inet
> @@ -3883,7 +3884,6 @@ netinet6/ip6_id.c optional inet6
> netinet6/ip6_input.c optional inet6
> netinet6/ip6_mroute.c optional mrouting inet6
> netinet6/ip6_output.c optional inet6
> -netinet6/ip6_ipsec.c optional inet6 ipsec
> netinet6/mld6.c optional inet6
> netinet6/nd6.c optional inet6
> netinet6/nd6_nbr.c optional inet6
> @@ -3896,15 +3896,25 @@ netinet6/udp6_usrreq.c optional inet6
> netipsec/ipsec.c optional ipsec inet | ipsec inet6
> netipsec/ipsec_input.c optional ipsec inet | ipsec inet6
> netipsec/ipsec_mbuf.c optional ipsec inet | ipsec inet6
>
> *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
> _______________________________________________
> svn-src-stable-11@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-stable-11
> To unsubscribe, send any mail to "svn-src-stable-11-unsubscribe@freebsd.org"
>
>
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
From owner-freebsd-stable@freebsd.org Tue Apr 4 06:23:37 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16575D2D8F6
for <freebsd-stable@mailman.ysv.freebsd.org>;
Tue, 4 Apr 2017 06:23:37 +0000 (UTC)
(envelope-from harrier@seiryu.id.hkg.ac.jp)
Received: from seiryu.id.hkg.ac.jp (seiryu.id.hkg.ac.jp [202.25.192.41])
by mx1.freebsd.org (Postfix) with ESMTP id D221EF99
for <freebsd-stable@freebsd.org>; Tue, 4 Apr 2017 06:23:36 +0000 (UTC)
(envelope-from harrier@seiryu.id.hkg.ac.jp)
Received: from seiryu.id.hkg.ac.jp (localhost [127.0.0.1])
by seiryu.id.hkg.ac.jp (Postfix) with SMTP id 665AE64283;
Tue, 4 Apr 2017 15:23:29 +0900 (JST)
Date: Tue, 4 Apr 2017 15:23:29 +0900
From: Hiroyuki Une <harrier@seiryu.id.hkg.ac.jp>
To: Trond =?UTF-8?B?RW5kcmVzdMO4bA==?= <Trond.Endrestol@fagskolen.gjovik.no>
Cc: freebsd-stable@freebsd.org, harrier@seiryu.id.hkg.ac.jp
Subject: Re: VirtualBox-ose kernel module crashes 10-stable
Message-Id: <20170404152329.cd3b040e89441e48560524a1@seiryu.id.hkg.ac.jp>
In-Reply-To: <alpine.BSF.2.20.1703311354370.533@mail.fig.ol.no>
References: <20170331200757.233b3826797acd61c66f03e7@seiryu.id.hkg.ac.jp>
<alpine.BSF.2.20.1703311354370.533@mail.fig.ol.no>
X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd10.3)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 06:23:37 -0000
On Fri, 31 Mar 2017 13:56:54 +0200 (CEST)
Trond Endrestøl <Trond.Endrestol@fagskolen.gjovik.no> wrote:
> On Fri, 31 Mar 2017 20:07+0900, Hiroyuki Une wrote:
>
> > Kernel Panic was caused on My 10.3-STABLE r316132
> > by VirtualBox-ose created by poudriere(8) on my box with DEBUG option.
> > However, when I was using 10.3-STABLE r315187,
> > VirtualBox-ose worked without any problem.
> >
> > Here is the output by kgdb:
> >
> > ------ start here (output by kgdb)
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for details.
> > This GDB was configured as "amd64-marcel-freebsd"...
> >
> > Unread portion of the kernel message buffer:
> >
> > !!Assertion Failed!!
> > Expression: RTThreadPreemptIsEnabled(NIL_RTTHREAD)
> > Location : /wrkdirs/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.1.18/out/freebsd.amd64/debug/bin/src/vboxdrv/r0drv/freebsd/spinlock-r0drv-freebsd.c(78) int RTSpinlockCreate(PRTSPINLOCK, uint32_t, const char *)
> >
> >
> > Fatal trap 3: breakpoint instruction fault while in kernel mode
> > cpuid = 3; apic id = 06
> > instruction pointer = 0x20:0xffffffff81dbb3de
> > stack pointer = 0x28:0xfffffe0464bfd490
> > frame pointer = 0x28:0xfffffe0464bfd4c0
> > code segment = base 0x0, limit 0xfffff, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags = interrupt enabled, IOPL = 0
> > current process = 46465 (VBoxSVC)
> > trap number = 3
> > panic: breakpoint instruction fault
> > cpuid = 3
> > KDB: stack backtrace:
> > #0 0xffffffff809bb360 at kdb_backtrace+0x60
> > #1 0xffffffff8097c1e6 at vpanic+0x126
> > #2 0xffffffff8097c0b3 at panic+0x43
> > #3 0xffffffff80d9ce2d at trap_fatal+0x35d
> > #4 0xffffffff80d9caaf at trap+0x79f
> > #5 0xffffffff80d81d4c at calltrap+0x8
> > #6 0xffffffff81d7d591 at supdrvCreateSession+0x91
> > #7 0xffffffff81d9355b at vboxdrvFreeBSDOpenCommon+0x2b
> > #8 0xffffffff80855a32 at devfs_open+0x122
> > #9 0xffffffff80ed8671 at VOP_OPEN_APV+0xa1
> > #10 0xffffffff80a3bc34 at vn_open_vnode+0x234
> > #11 0xffffffff80a3b803 at vn_open_cred+0x373
> > #12 0xffffffff80a348cf at kern_openat+0x26f
> > #13 0xffffffff80d9d862 at amd64_syscall+0x452
> > #14 0xffffffff80d8203b at Xfast_syscall+0xfb
> > Uptime: 16h16m43s
> > Dumping 3881 out of 16259 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
> > #0 doadump (textdump=<value optimized out>) at pcpu.h:219
> > 219 pcpu.h: No such file or directory.
> > in pcpu.h
> > (kgdb) bt
(snip)
> > As shown in the above, kernel panic was caused by
> > assertion RTThreadPreemptIsEnabled(NIL_RTTHREAD)
> > which tests the following expressions:
> >
> > 1. curthread->td_critnest is equal to 0, and
> > 2. IF (interrupt flag) on eflag (or rflag ?) is equal to 1.
> >
> > This assertion will be successful only if both of above are true.
> >
> > As I read the source of VirtualBox, RTThreadPreemptIsEnabled is
> > a part of test for preemtiveness which is used to create a spinlock.
> > However, I'm not sure why assertion RTThreadPreemptIsEnabled is required,
> > and this was failed on 10.3-STABLE r316132.
> >
> > I would appreciate any information. Thanks.
>
> emulators/virtualbox-ose needs access to the kernel sources during
> build. Maybe you should rebuild emulators/virtualbox-ose to match your
> current source tree.
Thank you for your advise. I create a new jail for poudriere with
the most recent 10.3-STABLE source tree, and then rebuild VirtualBox
and its kernel module by it. These worked fine.
However, this shows that there seems to be following problems
to maintain packages by pkg(8):
(a) STABLE users (both of 10 and 11) can't use kernel modules
if pkg.FreeBSD.org provides packages which were built with RELEASE source tree, or
(b) RELEASE users can't use kernel can't use kernel modules
if pkg.FreeBSD.org provides packages which were built with recent STABLE source tree.
At least, nvidia-driver caused kernel panic by almost same reason [1].
[1] https://lists.freebsd.org/pipermail/freebsd-stable/2017-March/087015.html
---
Hiroyuki Une: Hiroshima Kokusai Gakuin University
une@hkg.ac.jp / harrier@seiryu.id.hkg.ac.jp
From owner-freebsd-stable@freebsd.org Tue Apr 4 06:25:08 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD033D2DA87;
Tue, 4 Apr 2017 06:25:08 +0000 (UTC)
(envelope-from bu7cher@yandex.ru)
Received: from forward1o.cmail.yandex.net (forward1o.cmail.yandex.net
[IPv6:2a02:6b8:0:1a72::2a1])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 69FA2156;
Tue, 4 Apr 2017 06:25:08 +0000 (UTC)
(envelope-from bu7cher@yandex.ru)
Received: from smtp2p.mail.yandex.net (smtp2p.mail.yandex.net
[IPv6:2a02:6b8:0:1472:2741:0:8b6:7])
by forward1o.cmail.yandex.net (Yandex) with ESMTP id C6A25210D3;
Tue, 4 Apr 2017 09:25:04 +0300 (MSK)
Received: from smtp2p.mail.yandex.net (localhost.localdomain [127.0.0.1])
by smtp2p.mail.yandex.net (Yandex) with ESMTP id 99D971A80061;
Tue, 4 Apr 2017 09:25:02 +0300 (MSK)
Received: by smtp2p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id
C6fBS7kI6y-P1XGUetS; Tue, 04 Apr 2017 09:25:01 +0300
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client certificate not present)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
t=1491287101; bh=kpI/2Lpg5trY3felO5BeAGzUt+F2boCzNu0Z/6K9Bpw=;
h=Subject:To:References:From:Message-ID:Date:In-Reply-To;
b=H67R9epNWr3WWLIr6PUsJNcOUTsgOu0VIAc99v+BnQlb8WXZBPplF3KYqLB368F0i
RRHLmIlHqz+9OQiTldbT3oQSTLbj+iC1xcapV7/v9bpuFwjJ/avoZZszDlgF7Ip0Fe
ilR2r6ZHtQBvazxmmU0RP6yPBjB64eC9tGiyJUd0=
Authentication-Results: smtp2p.mail.yandex.net; dkim=pass header.i=@yandex.ru
X-Yandex-Suid-Status: 1 0,1 0,1 0
Subject: Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec
sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf
sys/libkern
sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/ne...
To: Mike Tancsa <mike@sentex.net>,
FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>,
svn-src-stable-11@freebsd.org
References: <201703182204.v2IM4Kfj060263@repo.freebsd.org>
<7738349f-e89a-d37d-e36f-0a5e18dc4249@sentex.net>
From: "Andrey V. Elsukov" <bu7cher@yandex.ru>
Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A
Message-ID: <cdff758c-e7d7-d22d-512e-2137ba70e78a@yandex.ru>
Date: Tue, 4 Apr 2017 09:24:19 +0300
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <7738349f-e89a-d37d-e36f-0a5e18dc4249@sentex.net>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="1DHHPkm5vrtC1A20XtJRL8wl2vj1kEBKn"
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 06:25:08 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--1DHHPkm5vrtC1A20XtJRL8wl2vj1kEBKn
Content-Type: multipart/mixed; boundary="sINK6MxKdnsg4mOk76UN1CQl8orjXGKtX";
protected-headers="v1"
From: "Andrey V. Elsukov" <bu7cher@yandex.ru>
To: Mike Tancsa <mike@sentex.net>,
FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>,
svn-src-stable-11@freebsd.org
Message-ID: <cdff758c-e7d7-d22d-512e-2137ba70e78a@yandex.ru>
Subject: Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec
sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf sys/libkern
sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/ne...
References: <201703182204.v2IM4Kfj060263@repo.freebsd.org>
<7738349f-e89a-d37d-e36f-0a5e18dc4249@sentex.net>
In-Reply-To: <7738349f-e89a-d37d-e36f-0a5e18dc4249@sentex.net>
--sINK6MxKdnsg4mOk76UN1CQl8orjXGKtX
Content-Type: multipart/mixed;
boundary="------------824A5776AE161D140B7137A1"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------824A5776AE161D140B7137A1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 04.04.2017 00:39, Mike Tancsa wrote:
> Hi,
> I ran into a strange problem when migrating a box that makes use of tc=
p
> md5 signatures. Having these two policies that have IPs which happen to=
> be 128 octets apart get rejected
It seems you have encrypted your config, because I don't see IP with 128
octets :)
One question, does this even worked before?
You have many SAs with the same destination address, it seems to me,
that this should not work with old IPsec code, because it uses SA
lookups using only destination address. So, if you have not the same
password for each SA, it should not work.
Can you try the attached patch?
--=20
WBR, Andrey V. Elsukov
--------------824A5776AE161D140B7137A1
Content-Type: text/x-patch;
name="key.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="key.diff"
Index: sys/netipsec/key.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- sys/netipsec/key.c (revision 316434)
+++ sys/netipsec/key.c (working copy)
@@ -863,7 +863,8 @@ key_allocsa_tcpmd5(struct secasindex *saidx)
kdebug_secash(sah, " "));
if (sah->saidx.proto !=3D IPPROTO_TCP)
continue;
- if (!key_sockaddrcmp(&saidx->dst.sa, &sah->saidx.dst.sa, 0))
+ if (!key_sockaddrcmp(&saidx->dst.sa, &sah->saidx.dst.sa, 0) &&
+ !key_sockaddrcmp(&saidx->src.sa, &sah->saidx.src.sa, 0))
break;
}
if (sah !=3D NULL) {
@@ -4962,7 +4963,8 @@ key_getsav_tcpmd5(struct secasindex *saidx, uint32
LIST_FOREACH(sah, SAHADDRHASH_HASH(saidx), addrhash) {
if (sah->saidx.proto !=3D IPPROTO_TCP)
continue;
- if (!key_sockaddrcmp(&saidx->dst.sa, &sah->saidx.dst.sa, 0))
+ if (!key_sockaddrcmp(&saidx->dst.sa, &sah->saidx.dst.sa, 0) &&
+ !key_sockaddrcmp(&saidx->src.sa, &sah->saidx.src.sa, 0))
break;
}
if (sah !=3D NULL) {
--------------824A5776AE161D140B7137A1--
--sINK6MxKdnsg4mOk76UN1CQl8orjXGKtX--
--1DHHPkm5vrtC1A20XtJRL8wl2vj1kEBKn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAljjPBMACgkQAcXqBBDI
oXqGfggAnrE7KqKxB5W5OvSc949/q5H61gnyFoPjxR1J/fJwj8z9Q0RuxCd4f8YI
z7NFFQk+QcovwilV0Lu4ovuvabBUfd3kgBJy3EixxrpcYJ8x28S43IOd4J8NsvjF
BN1hSLyPhNgXwDxIiN15YjJ/eHREJH5vYubW/MJo0BjEGqDz84MfefjeIWqScn6d
cSqAgGwScLZUAJ3U0DZHJIVxquarbgqvWgomRCAhybJpNVjLWvLWTKq3Oqq+sXlY
6+o1Spa+jqYfVGzh/O5cY3Jgz3j37D9I5zpS8yWC+XaH9cc9Nf3eNBZdMPps6O8h
nRxD4jPX5nRU20t51ktw3a1rpFsfEQ==
=nkkO
-----END PGP SIGNATURE-----
--1DHHPkm5vrtC1A20XtJRL8wl2vj1kEBKn--
From owner-freebsd-stable@freebsd.org Tue Apr 4 06:53:17 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E505D2D917
for <freebsd-stable@mailman.ysv.freebsd.org>;
Tue, 4 Apr 2017 06:53:17 +0000 (UTC) (envelope-from bsam@passap.ru)
Received: from forward3p.cmail.yandex.net (forward3p.cmail.yandex.net
[IPv6:2a02:6b8:0:1465::13])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 2A91D893
for <freebsd-stable@freebsd.org>; Tue, 4 Apr 2017 06:53:17 +0000 (UTC)
(envelope-from bsam@passap.ru)
Received: from smtp1o.mail.yandex.net (smtp1o.mail.yandex.net [37.140.190.26])
by forward3p.cmail.yandex.net (Yandex) with ESMTP id 7A75320F69;
Tue, 4 Apr 2017 09:53:05 +0300 (MSK)
Received: from smtp1o.mail.yandex.net (localhost.localdomain [127.0.0.1])
by smtp1o.mail.yandex.net (Yandex) with ESMTP id 9BA041300A29;
Tue, 4 Apr 2017 09:53:04 +0300 (MSK)
Received: by smtp1o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id
WAguJHS7xr-r3hG4LXX; Tue, 04 Apr 2017 09:53:03 +0300
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client certificate not present)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail;
t=1491288783; bh=MOTamdB2cQM00ZbSqtmcNEzT0KiYTY3uqsN9G+4KrJU=;
h=Subject:To:References:From:Message-ID:Date:In-Reply-To;
b=rb7zJOMl2CYA+I2RGGApufi5f4g+N36YZViINo7ONok5Qp+nACiyiPZ89e3zSp/Hp
7r5bFUeDKVl0KndGeVuXJI5PMYZwzYlC7sYnPiFVdToiMJdIjdyQMAv171CzQ4omDO
aXF/G0ZmbVNz/SEwOEeBAI7N2k3lQ50XKsQjfrOc=
Authentication-Results: smtp1o.mail.yandex.net; dkim=pass header.i=@passap.ru
X-Yandex-Suid-Status: 1 0,1 0
Subject: Re: /dev/dri registration
To: freebsd-stable@freebsd.org, Slawa Olhovchenkov <slw@zxy.spb.ru>
References: <20170403160957.GA20974@zxy.spb.ru>
From: Boris Samorodov <bsam@passap.ru>
Message-ID: <0c8820f7-0c79-11a4-c699-ace29b5ffa57@passap.ru>
Date: Tue, 4 Apr 2017 09:52:27 +0300
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <20170403160957.GA20974@zxy.spb.ru>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 06:53:17 -0000
Hi Slawa, All!
03.04.2017 19:09, Slawa Olhovchenkov пишет:
> I am have strange issuse on stable/10:
>
> # devinfo -v
> nexus0
> apic0
> ram0
> acpi0
> [...]
> pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0
> pci0
> hostb0 pnpinfo vendor=0x8086 device=0xd130 subvendor=0x1014 subdevice=0x03ce class=0x060000 at slot=0 function=0 dbsf=pci0:0:0:0
> pcib1 pnpinfo vendor=0x8086 device=0xd138 subvendor=0x1014 subdevice=0x03ce class=0x060400 at slot=3 function=0 dbsf=pci0:0:3:0 handle=\_SB_.PCI0.P0P2
> pci1
> vgapci0 pnpinfo vendor=0x10de device=0x0a20 subvendor=0x1458 subdevice=0x34d6 class=0x030000 at slot=0 function=0 dbsf=pci0:1:0:0
> drm0
> drmn0
> nvidia0
>
> But /dev/dri don't exist!
>
> # kldstat
> Id Refs Address Size Name
> 1 80 0xffffffff80200000 17e87f8 kernel
> 2 1 0xffffffff819e9000 309780 zfs.ko
> 3 2 0xffffffff81cf3000 6040 opensolaris.ko
> 4 1 0xffffffff81cfa000 7aa58 if_em.ko
> 5 1 0xffffffff81d75000 29bd0 drm.ko
> 6 1 0xffffffff81d9f000 82898 drm2.ko
I'm not sure about your original question, but at least that is
suspicious. I'd say that drm and drm2 modules should not be loaded
together.
> 7 2 0xffffffff81e22000 6298 iicbus.ko
> 8 1 0xffffffff81e29000 1c650 uart.ko
> 9 1 0xffffffff82011000 56f3 fdescfs.ko
> 10 1 0xffffffff82017000 a681 linprocfs.ko
> 11 3 0xffffffff82022000 7522 linux_common.ko
> 12 1 0xffffffff8202a000 5673 linsysfs.ko
> 13 1 0xffffffff82030000 364c ums.ko
> 14 1 0xffffffff82034000 10226 snd_uaudio.ko
> 15 1 0xffffffff82045000 2ba8 uhid.ko
> 16 3 0xffffffff82048000 4e626 vboxdrv.ko
> 17 2 0xffffffff82097000 2b82 vboxnetflt.ko
> 18 2 0xffffffff8209a000 ba2f netgraph.ko
> 19 1 0xffffffff820a6000 414f ng_ether.ko
> 20 1 0xffffffff820ab000 3fd4 vboxnetadp.ko
> 21 2 0xffffffff820af000 3d5da linux.ko
> 22 1 0xffffffff820ed000 964496 nvidia.ko
>
> What is wrong in may setup?
HTH
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
From owner-freebsd-stable@freebsd.org Tue Apr 4 09:18:28 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51BA7D2B1BF
for <freebsd-stable@mailman.ysv.freebsd.org>;
Tue, 4 Apr 2017 09:18:28 +0000 (UTC)
(envelope-from clbuisson@orange.fr)
Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr
[80.12.242.124])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(Client CN "Bizanga Labs SMTP Client Certificate",
Issuer "Bizanga Labs CA" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id C0777BC2
for <freebsd-stable@freebsd.org>; Tue, 4 Apr 2017 09:18:26 +0000 (UTC)
(envelope-from clbuisson@orange.fr)
Received: from localhost ([92.134.240.181]) by mwinf5d78 with ME
id 49JG1v00J3vXflY039JGzd; Tue, 04 Apr 2017 11:18:18 +0200
X-ME-Helo: localhost
X-ME-Auth: Y2xidWlzc29uQHdhbmFkb28uZnI=
X-ME-Date: Tue, 04 Apr 2017 11:18:18 +0200
X-ME-IP: 92.134.240.181
Subject: Re: /dev/dri registration
To: freebsd-stable@freebsd.org
References: <20170403160957.GA20974@zxy.spb.ru>
From: Claude Buisson <clbuisson@orange.fr>
Message-ID: <a5c4323d-10e5-7b0f-4843-271dba8a8d9f@orange.fr>
Date: Tue, 4 Apr 2017 11:18:16 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101
Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <20170403160957.GA20974@zxy.spb.ru>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 09:18:28 -0000
On 04/03/2017 18:09, Slawa Olhovchenkov wrote:
> I am have strange issuse on stable/10:
>
> # devinfo -v
> nexus0
> apic0
> ram0
> acpi0
> [...]
> pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0
> pci0
> hostb0 pnpinfo vendor=0x8086 device=0xd130 subvendor=0x1014 subdevice=0x03ce class=0x060000 at slot=0 function=0 dbsf=pci0:0:0:0
> pcib1 pnpinfo vendor=0x8086 device=0xd138 subvendor=0x1014 subdevice=0x03ce class=0x060400 at slot=3 function=0 dbsf=pci0:0:3:0 handle=\_SB_.PCI0.P0P2
> pci1
> vgapci0 pnpinfo vendor=0x10de device=0x0a20 subvendor=0x1458 subdevice=0x34d6 class=0x030000 at slot=0 function=0 dbsf=pci0:1:0:0
> drm0
> drmn0
> nvidia0
>
> But /dev/dri don't exist!
>
> # kldstat
> Id Refs Address Size Name
> 1 80 0xffffffff80200000 17e87f8 kernel
> 2 1 0xffffffff819e9000 309780 zfs.ko
> 3 2 0xffffffff81cf3000 6040 opensolaris.ko
> 4 1 0xffffffff81cfa000 7aa58 if_em.ko
> 5 1 0xffffffff81d75000 29bd0 drm.ko
> 6 1 0xffffffff81d9f000 82898 drm2.ko
> 7 2 0xffffffff81e22000 6298 iicbus.ko
> 8 1 0xffffffff81e29000 1c650 uart.ko
> 9 1 0xffffffff82011000 56f3 fdescfs.ko
> 10 1 0xffffffff82017000 a681 linprocfs.ko
> 11 3 0xffffffff82022000 7522 linux_common.ko
> 12 1 0xffffffff8202a000 5673 linsysfs.ko
> 13 1 0xffffffff82030000 364c ums.ko
> 14 1 0xffffffff82034000 10226 snd_uaudio.ko
> 15 1 0xffffffff82045000 2ba8 uhid.ko
> 16 3 0xffffffff82048000 4e626 vboxdrv.ko
> 17 2 0xffffffff82097000 2b82 vboxnetflt.ko
> 18 2 0xffffffff8209a000 ba2f netgraph.ko
> 19 1 0xffffffff820a6000 414f ng_ether.ko
> 20 1 0xffffffff820ab000 3fd4 vboxnetadp.ko
> 21 2 0xffffffff820af000 3d5da linux.ko
> 22 1 0xffffffff820ed000 964496 nvidia.ko
>
> What is wrong in may setup?
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
It seems that you are using the nvidia driver
I have presently 2 systems with this driver, and none of them have a
/dev/dri, and this have always been the case as far as I can recall.
Claude Buisson
From owner-freebsd-stable@freebsd.org Tue Apr 4 10:55:57 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 065A1D2D13A;
Tue, 4 Apr 2017 10:55:57 +0000 (UTC) (envelope-from mike@sentex.net)
Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50])
(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
(Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id B0D98BBF;
Tue, 4 Apr 2017 10:55:56 +0000 (UTC) (envelope-from mike@sentex.net)
Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11])
by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id v34Atnp8093112
(version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
Tue, 4 Apr 2017 06:55:49 -0400 (EDT) (envelope-from mike@sentex.net)
Received: from [IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c]
([IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c])
by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id v34Atmj3023123;
Tue, 4 Apr 2017 06:55:48 -0400 (EDT) (envelope-from mike@sentex.net)
Subject: Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec
sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf
sys/libkern
sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/ne...
To: "Andrey V. Elsukov" <bu7cher@yandex.ru>,
FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>,
svn-src-stable-11@freebsd.org
References: <201703182204.v2IM4Kfj060263@repo.freebsd.org>
<7738349f-e89a-d37d-e36f-0a5e18dc4249@sentex.net>
<cdff758c-e7d7-d22d-512e-2137ba70e78a@yandex.ru>
From: Mike Tancsa <mike@sentex.net>
Organization: Sentex Communications
Message-ID: <a3ee1736-ca0b-76dc-0561-6bd27dd79071@sentex.net>
Date: Tue, 4 Apr 2017 06:55:36 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <cdff758c-e7d7-d22d-512e-2137ba70e78a@yandex.ru>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.78
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 10:55:57 -0000
On 4/4/2017 2:24 AM, Andrey V. Elsukov wrote:
> On 04.04.2017 00:39, Mike Tancsa wrote:
> It seems you have encrypted your config, because I don't see IP with 128
> octets :)
:)
>
> One question, does this even worked before?
> You have many SAs with the same destination address, it seems to me,
> that this should not work with old IPsec code, because it uses SA
> lookups using only destination address. So, if you have not the same
> password for each SA, it should not work.
>
> Can you try the attached patch?
>
It did. In the past, inbound sigs I think just didnt work, but it was
uninteresting for the purpose of this app. In this case, it was for bgp
passwords. I was more concerned with sending the correct password to
the peer. So it was one source IP with many destination addresses (over
a dozen). For the old config I just had the policy in one direction as
well. It seems now with the new ipsec code, I must have the policy in
both directions ?
The man page for setkey implies I only need one entry.
Also, should the SPI always been the same, or unique ?
compiling the patch now.
---Mike
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
From owner-freebsd-stable@freebsd.org Tue Apr 4 11:19:27 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 440C2D2DF31;
Tue, 4 Apr 2017 11:19:27 +0000 (UTC)
(envelope-from bu7cher@yandex.ru)
Received: from forward5j.cmail.yandex.net (forward5j.cmail.yandex.net
[IPv6:2a02:6b8:0:1630::18])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id BF3288BD;
Tue, 4 Apr 2017 11:19:26 +0000 (UTC)
(envelope-from bu7cher@yandex.ru)
Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net
[IPv6:2a02:6b8:0:f05::117])
by forward5j.cmail.yandex.net (Yandex) with ESMTP id 8D0C020FEC;
Tue, 4 Apr 2017 14:19:12 +0300 (MSK)
Received: from smtp3h.mail.yandex.net (localhost.localdomain [127.0.0.1])
by smtp3h.mail.yandex.net (Yandex) with ESMTP id 219BF440E26;
Tue, 4 Apr 2017 14:19:09 +0300 (MSK)
Received: by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id
E8zq86UFvG-J8t0cs24; Tue, 04 Apr 2017 14:19:08 +0300
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client certificate not present)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
t=1491304748; bh=Wc4khLymdUT5mKHwAxtQ35LJuG89m+kKO9/Ug1KNNig=;
h=From:Subject:To:References:Message-ID:Date:In-Reply-To;
b=ZZgVHrvjfqHKDxB2uZZeSR4vkPmaOM6GoqXykqjKd9zEJYXsZi+Nku93ntbXPlnMj
hoIuUcsw5myowUrFANnMv5n8mIyQX5HAYcGrF2LjdH1v/QBVKBQEge9oAPmfz9AM5z
FiPveba5MaY6ycNYdKgu8bW2wsBxWTIB7vLVa/oQ=
Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru
X-Yandex-Suid-Status: 1 0,1 0,1 0
From: "Andrey V. Elsukov" <bu7cher@yandex.ru>
Subject: Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec
sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf
sys/libkern
sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/ne...
To: Mike Tancsa <mike@sentex.net>,
FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>,
svn-src-stable-11@freebsd.org
References: <201703182204.v2IM4Kfj060263@repo.freebsd.org>
<7738349f-e89a-d37d-e36f-0a5e18dc4249@sentex.net>
<cdff758c-e7d7-d22d-512e-2137ba70e78a@yandex.ru>
<a3ee1736-ca0b-76dc-0561-6bd27dd79071@sentex.net>
Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A
Message-ID: <2aa232b9-df57-3512-ae98-1d4b03bb00d4@yandex.ru>
Date: Tue, 4 Apr 2017 14:18:26 +0300
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <a3ee1736-ca0b-76dc-0561-6bd27dd79071@sentex.net>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="8AJ2JvJOBeuCxmImkMpEvWeTtATtD9WgK"
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 11:19:27 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--8AJ2JvJOBeuCxmImkMpEvWeTtATtD9WgK
Content-Type: multipart/mixed; boundary="M9vdqHIaHgHiwa5qCmhDX7swbdwaeveO2";
protected-headers="v1"
From: "Andrey V. Elsukov" <bu7cher@yandex.ru>
To: Mike Tancsa <mike@sentex.net>,
FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>,
svn-src-stable-11@freebsd.org
Message-ID: <2aa232b9-df57-3512-ae98-1d4b03bb00d4@yandex.ru>
Subject: Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec
sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf sys/libkern
sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/ne...
References: <201703182204.v2IM4Kfj060263@repo.freebsd.org>
<7738349f-e89a-d37d-e36f-0a5e18dc4249@sentex.net>
<cdff758c-e7d7-d22d-512e-2137ba70e78a@yandex.ru>
<a3ee1736-ca0b-76dc-0561-6bd27dd79071@sentex.net>
In-Reply-To: <a3ee1736-ca0b-76dc-0561-6bd27dd79071@sentex.net>
--M9vdqHIaHgHiwa5qCmhDX7swbdwaeveO2
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 04.04.2017 13:55, Mike Tancsa wrote:
>> You have many SAs with the same destination address, it seems to me,
>> that this should not work with old IPsec code, because it uses SA
>> lookups using only destination address. So, if you have not the same
>> password for each SA, it should not work.
>>
>> Can you try the attached patch?
>>
>=20
> It did. In the past, inbound sigs I think just didnt work, but it was
> uninteresting for the purpose of this app. In this case, it was for bg=
p
Yes, I checked stable/10 code, it seems TCP-MD5 always used one SA for
both inbound and outbound direction.
> passwords. I was more concerned with sending the correct password to
> the peer. So it was one source IP with many destination addresses (ove=
r
> a dozen). For the old config I just had the policy in one direction as
> well. It seems now with the new ipsec code, I must have the policy in
> both directions ?
Yes, you need SA for both directions.
> The man page for setkey implies I only need one entry.
>=20
> Also, should the SPI always been the same, or unique ?
SPI is not used by this code, it only needed for compatibility with
SADB. Better to use unique SPI for each SA, but for TCP-MD5 it will work
anyway. :)
--=20
WBR, Andrey V. Elsukov
--M9vdqHIaHgHiwa5qCmhDX7swbdwaeveO2--
--8AJ2JvJOBeuCxmImkMpEvWeTtATtD9WgK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAljjgQIACgkQAcXqBBDI
oXrMxAgAjPj2mz5kcuAE6Qa6142GMFpSI9urJsYoCdo4SqkY8L2IbjfEujpMIEji
BN49gGfcyg2trvLj2Zod7dSLedf9fwZns+Pi+w7AqToHOKHpVcWRQn7J3eFkgUvd
7k8psH3HDudb4Wn2upQ5HMo/uc+/qtXf8HgXshW1Bc/ZPFz6t6AySNoafy7gQi5m
dFaJT0KnMy9djEdS/h+EOiFTGIByPUgKNLq2EWlnswZbpmSg/nY6CxlQq8L/MZ/d
U6NjieQSCbRL+xHGUWqAj8DW+3L1aIOeoKzQaU6eJcSuD8WCuvLDtlXXAsciepnb
yojUuO51UNXOeg3lSjWUQjj7u6JjpQ==
=lv1Y
-----END PGP SIGNATURE-----
--8AJ2JvJOBeuCxmImkMpEvWeTtATtD9WgK--
From owner-freebsd-stable@freebsd.org Tue Apr 4 13:24:07 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41A49D2DAF2;
Tue, 4 Apr 2017 13:24:07 +0000 (UTC) (envelope-from mike@sentex.net)
Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50])
(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
(Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 0E4B66A9;
Tue, 4 Apr 2017 13:24:06 +0000 (UTC) (envelope-from mike@sentex.net)
Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11])
by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id v34DO0C6006976
(version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
Tue, 4 Apr 2017 09:24:00 -0400 (EDT) (envelope-from mike@sentex.net)
Received: from [IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c]
([IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c])
by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id v34DNxPc023432;
Tue, 4 Apr 2017 09:23:59 -0400 (EDT) (envelope-from mike@sentex.net)
Subject: Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec
sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf
sys/libkern
sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/ne...
To: "Andrey V. Elsukov" <bu7cher@yandex.ru>,
FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>,
svn-src-stable-11@freebsd.org
References: <201703182204.v2IM4Kfj060263@repo.freebsd.org>
<7738349f-e89a-d37d-e36f-0a5e18dc4249@sentex.net>
<cdff758c-e7d7-d22d-512e-2137ba70e78a@yandex.ru>
<a3ee1736-ca0b-76dc-0561-6bd27dd79071@sentex.net>
<2aa232b9-df57-3512-ae98-1d4b03bb00d4@yandex.ru>
From: Mike Tancsa <mike@sentex.net>
Organization: Sentex Communications
Message-ID: <6f65e093-cbcb-ff02-3e62-a0aac0c7f303@sentex.net>
Date: Tue, 4 Apr 2017 09:23:47 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <2aa232b9-df57-3512-ae98-1d4b03bb00d4@yandex.ru>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.78
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 13:24:07 -0000
On 4/4/2017 7:18 AM, Andrey V. Elsukov wrote:
> On 04.04.2017 13:55, Mike Tancsa wrote:
>>> You have many SAs with the same destination address, it seems to me,
>>> that this should not work with old IPsec code, because it uses SA
>>> lookups using only destination address. So, if you have not the same
>>> password for each SA, it should not work.
>>>
>>> Can you try the attached patch?
Thanks, the patch works! I am able to load all 42 rules now. I am
going to test them in the lab against a few VMs prior to deployment.
---Mike
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
From owner-freebsd-stable@freebsd.org Tue Apr 4 19:55:37 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id B488FD2F12F
for <freebsd-stable@mailman.ysv.freebsd.org>;
Tue, 4 Apr 2017 19:55:37 +0000 (UTC) (envelope-from mike@sentex.net)
Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50])
(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
(Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 5F8DF886
for <freebsd-stable@freebsd.org>; Tue, 4 Apr 2017 19:55:37 +0000 (UTC)
(envelope-from mike@sentex.net)
Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11])
by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id v34JtU4f060452
(version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO)
for <freebsd-stable@freebsd.org>; Tue, 4 Apr 2017 15:55:31 -0400 (EDT)
(envelope-from mike@sentex.net)
Received: from [IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c]
([IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c])
by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id v34JtSwi026040;
Tue, 4 Apr 2017 15:55:28 -0400 (EDT) (envelope-from mike@sentex.net)
Subject: Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec
sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf
sys/libkern
sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/ne...
To: "Andrey V. Elsukov" <bu7cher@yandex.ru>,
FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
References: <201703182204.v2IM4Kfj060263@repo.freebsd.org>
<7738349f-e89a-d37d-e36f-0a5e18dc4249@sentex.net>
<cdff758c-e7d7-d22d-512e-2137ba70e78a@yandex.ru>
<a3ee1736-ca0b-76dc-0561-6bd27dd79071@sentex.net>
<2aa232b9-df57-3512-ae98-1d4b03bb00d4@yandex.ru>
From: Mike Tancsa <mike@sentex.net>
Organization: Sentex Communications
Message-ID: <e722e690-a1c0-8718-84cc-d1913d3076ea@sentex.net>
Date: Tue, 4 Apr 2017 15:55:16 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <2aa232b9-df57-3512-ae98-1d4b03bb00d4@yandex.ru>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.78
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 19:55:37 -0000
On 4/4/2017 7:18 AM, Andrey V. Elsukov wrote:
> On 04.04.2017 13:55, Mike Tancsa wrote:
>
> Yes, you need SA for both directions.
>
>> The man page for setkey implies I only need one entry.
>>
>> Also, should the SPI always been the same, or unique ?
>
> SPI is not used by this code, it only needed for compatibility with
> SADB. Better to use unique SPI for each SA, but for TCP-MD5 it will work
> anyway. :)
>
Perhaps to the man pages, this small change ?
--- sbin/setkey/setkey.8.prev 2017-04-04 15:11:03.312911000 -0400
+++ sbin/setkey/setkey.8 2017-04-04 15:53:31.296152000 -0400
@@ -696,6 +696,7 @@
Use TCP MD5 between two numerically specified hosts:
.Bd -literal -offset indent
add 10.1.10.34 10.1.10.36 tcp 0x1000 -A tcp-md5 "TCP-MD5 BGP secret" ;
+add 10.1.10.36 10.1.10.34 tcp 0x1000 -A tcp-md5 "TCP-MD5 BGP secret" ;
.Ed
.\"
.Sh SEE ALSO
---Mike
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
From owner-freebsd-stable@freebsd.org Tue Apr 4 23:33:51 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63CA3D2F53C
for <freebsd-stable@mailman.ysv.freebsd.org>;
Tue, 4 Apr 2017 23:33:51 +0000 (UTC)
(envelope-from carpeddiem@gmail.com)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com
[IPv6:2607:f8b0:4001:c0b::22f])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 3F6CB127
for <freebsd-stable@freebsd.org>; Tue, 4 Apr 2017 23:33:51 +0000 (UTC)
(envelope-from carpeddiem@gmail.com)
Received: by mail-it0-x22f.google.com with SMTP id e75so73892127itd.1
for <freebsd-stable@freebsd.org>; Tue, 04 Apr 2017 16:33:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:from:date:message-id:subject:to;
bh=XNfeVqPPB8M5HueaOZlCW715J2h927iAbzMsQRQIL5g=;
b=jUGHD4fn23IuntwrT7hMe41RioXler4KabYcDXkD1+fEuiYpb57slWAwSHYy6kJouI
wWQW/NHRpdw8u1t240WfDIGzQEMl1EFISbkMGwZ+DIfNSOrRwnLXKydMm0e6In1LT4hR
3+uFpy0sgmLd4TBfZ0r8njNQGTgGrEgdfKQKBbh9bBP3T5B/lqTeX2tsS6z58x1qWBQ3
gMGB1RlDzzVrI3+3CA2xQIBnrVGMfjOeUFrSIfofFGoENoS8DR8e/k1GNVUgLlb2NTpD
zSS/TW6VjR7hSGb/ScQD/ZstObOOYieO9YfzQwPW0q/wt7I6NANAVQXLsuDCvS2IX6iy
iByA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:from:date:message-id:subject
:to; bh=XNfeVqPPB8M5HueaOZlCW715J2h927iAbzMsQRQIL5g=;
b=bI/mJKsbtgDcKukOluZNK1J15a1faQHsx8Jwzgb2sWVbVKuG3cRN6xAtnUzSStnELV
PA02o2cBXuSrV6E5OcDQWm2MJVInqmb4WnMlqo6reNvCOy0zTq210EP7hW+HjiGlRqk2
577NEoJHqUawEEAlQFo8DeCfvoWCGQFojTLom8uDP70UOmlEDwM42tc5F57d1gDqZitN
6ycSqoR96GGm4qoPYH2Ypi5vxLSZ+CK2KFemAIOFWUN8hYoGGlRtXFoZHuYnBoa+YjMx
5jaDS5sRXvGiWSjH+uLsIjwaNt4A6xsnYvPyxx8yIJZ2gSwpAtUnLjUy5LcCl2hqqzHw
8ojg==
X-Gm-Message-State: AFeK/H2JQs1NTXFI96cVvhYyacaSCib++74qYBkWqR4csADGGtmFTcZabojdlO+sQqmpn+v6ZEeIyk8JvyY5cg==
X-Received: by 10.36.31.213 with SMTP id d204mr10354660itd.4.1491348829926;
Tue, 04 Apr 2017 16:33:49 -0700 (PDT)
MIME-Version: 1.0
Sender: carpeddiem@gmail.com
Received: by 10.107.30.209 with HTTP; Tue, 4 Apr 2017 16:33:29 -0700 (PDT)
From: Ed Maste <emaste@freebsd.org>
Date: Tue, 4 Apr 2017 19:33:29 -0400
X-Google-Sender-Auth: zBqMwVCTmxwtuHwWdKutTvpkZc8
Message-ID: <CAPyFy2DVZqK6rPBLhj+uS=1hhL2TweV9W0SfeFoHsdGr7p-VdQ@mail.gmail.com>
Subject: FreeBSD-update incorrectly reporting that it is approaching End of
Life
To: freebsd-stable stable <freebsd-stable@freebsd.org>
Content-Type: text/plain; charset=UTF-8
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 23:33:51 -0000
FreeBSD-update has outdated release lifetime data, and is emitting a
false warning that the End-of-Life date for FreeBSD 11.0-RELEASE-p8 is
approaching.
| WARNING: FreeBSD 11.0-RELEASE-p8 is approaching its End-of-Life date.
| It is strongly recommended that you upgrade to a newer
| release within the next 2 months.
The warning should be ignored, and will be corrected as soon as possible.
From owner-freebsd-stable@freebsd.org Thu Apr 6 10:16:53 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6B00D2FE61
for <freebsd-stable@mailman.ysv.freebsd.org>;
Thu, 6 Apr 2017 10:16:53 +0000 (UTC)
(envelope-from kami@freebsd.org)
Received: from bsdforen.de (bsdforen.de [82.193.243.115])
by mx1.freebsd.org (Postfix) with ESMTP id 81A6BCAB
for <freebsd-stable@freebsd.org>; Thu, 6 Apr 2017 10:16:53 +0000 (UTC)
(envelope-from kami@freebsd.org)
Received: from localhost (iz-aix-213a.HS-Karlsruhe.DE [193.196.64.213])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by bsdforen.de (Postfix) with ESMTPSA id C0FF292E4B
for <freebsd-stable@freebsd.org>; Thu, 6 Apr 2017 12:16:45 +0200 (CEST)
Date: Thu, 6 Apr 2017 12:16:35 +0200
From: Dominic Fandrey <kami@freebsd.org>
To: freebsd-stable@freebsd.org
Subject: Unsupported USB BT device causes high interrupt load
Message-Id: <20170406121635.99a513360faaf2f40992fb8a@freebsd.org>
Organization: FreeBSD
X-Mailer: Sylpheed 3.5.1
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
micalg="PGP-SHA512";
boundary="Signature=_Thu__6_Apr_2017_12_16_37_+0200_Yjm8XMg2_01XfzjD"
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Apr 2017 10:16:53 -0000
--Signature=_Thu__6_Apr_2017_12_16_37_+0200_Yjm8XMg2_01XfzjD
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I have an Interrupt load of 2000 interrupts/s from xhci0.
As the culprit I have identified the following device:
ugen0.6: <vendor 0x8087 product 0x07dc> at usbus0, cfg=3D255 md=3DHOST spd=
=3DFULL (12Mbps) pwr=3DON (100mA)
The impression I have from googling this is that it's an unsupported
BT device sitting on board of my Intel Wireless AC 7260 card (I also
have an unsupported SD/MMC card reader sitting on the mainboard).
usbconfig -d 0.6 power_off
Ends the interrupt spree.
I'm running FreeBSD 11.0-STABLE #1 r316490 amd64.
--=20
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?=20
--Signature=_Thu__6_Apr_2017_12_16_37_+0200_Yjm8XMg2_01XfzjD
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
iQGTBAEBCgB9FiEEfYhGEP+7uobxe8A3b/BdaakqWdsFAljmFYVfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDdE
ODg0NjEwRkZCQkJBODZGMTdCQzAzNzZGRjA1RDY5QTkyQTU5REIACgkQb/Bdaakq
WduDrAgAp32pQ0LKDvud5PP7CJKRCH0Nqw4NDbriizj7VVC7xguOAtqnSROTOT+Z
9GF7gCWa9OEmBYyNQOccBBLDyjhhApx4slsTtel1QsKJsTAlNqqFX8X6XvK01lUF
qpeUCC1whI2FAe5xgWDKlRMJKw6WP/uTNnL6Ic93s0L3hyws/BIF+ClsCtbbQ09q
lbwXgPIO+hzYlGNhzCqYkeMYVEpHxB1bGWQJemDWs3EIvWGUKTiUjvciJMkY0a14
OaG4zRzkUTQrcuVdZOzTorTz/piAyH5ymD++aVLtC1/ziM/mMPp1Hx5LGxdhotp5
f4EYEgxJ5DLpatXdiVJyxHSLf4EtyA==
=KOsc
-----END PGP SIGNATURE-----
--Signature=_Thu__6_Apr_2017_12_16_37_+0200_Yjm8XMg2_01XfzjD--
From owner-freebsd-stable@freebsd.org Thu Apr 6 14:36:40 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30337D32586
for <freebsd-stable@mailman.ysv.freebsd.org>;
Thu, 6 Apr 2017 14:36:40 +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 mx1.freebsd.org (Postfix) with ESMTPS id 1FCFA2A1
for <freebsd-stable@FreeBSD.org>; Thu, 6 Apr 2017 14:36:40 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v36Eabef096441
for <freebsd-stable@FreeBSD.org>; Thu, 6 Apr 2017 14:36:39 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-stable@FreeBSD.org
Subject: [Bug 213903] Kernel crashes from turnstile_broadcast
(/usr/src/sys/kern/subr_turnstile.c:837)
Date: Thu, 06 Apr 2017 14:36:38 +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: crash
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: peixoto.cassiano@gmail.com
X-Bugzilla-Status: Open
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-213903-8075-8f6Crz6KIn@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-213903-8075@https.bugs.freebsd.org/bugzilla/>
References: <bug-213903-8075@https.bugs.freebsd.org/bugzilla/>
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-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Apr 2017 14:36:40 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903
--- Comment #28 from Cassiano Peixoto <peixoto.cassiano@gmail.com> ---
(In reply to Cassiano Peixoto from comment #27)
Hi Mateusz, any news about this issue?
--=20
You are receiving this mail because:
You are on the CC list for the bug.=
From owner-freebsd-stable@freebsd.org Thu Apr 6 21:35:26 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C3EFD32DC2
for <freebsd-stable@mailman.ysv.freebsd.org>;
Thu, 6 Apr 2017 21:35:26 +0000 (UTC)
(envelope-from julien@levieil.fr)
Received: from mail.levieil.fr (mail.levieil.fr [144.217.14.210])
(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 31031618
for <freebsd-stable@freebsd.org>; Thu, 6 Apr 2017 21:35:25 +0000 (UTC)
(envelope-from julien@levieil.fr)
Received: from localhost (localhost [127.0.0.1])
by mail.levieil.fr (Postfix) with ESMTP id 0622D1A16A09
for <freebsd-stable@freebsd.org>; Thu, 6 Apr 2017 17:28:31 -0400 (EDT)
Received: from mail.levieil.fr ([127.0.0.1])
by localhost (mail.levieil.fr [127.0.0.1]) (amavisd-new, port 10032)
with ESMTP id z0O3iya69KyE for <freebsd-stable@freebsd.org>;
Thu, 6 Apr 2017 17:28:30 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
by mail.levieil.fr (Postfix) with ESMTP id 4E0871A16A0C
for <freebsd-stable@freebsd.org>; Thu, 6 Apr 2017 17:28:30 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.levieil.fr 4E0871A16A0C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=levieil.fr;
s=4AA023DA-C348-11E6-BF6B-99F7250CFC9E; t=1491514110;
bh=qLsXk6vFuaEBTp7/r+1iwfJsLfRkroM5lwBhhKuuo2Q=;
h=Date:From:To:Message-ID:MIME-Version;
b=VM5iVEf0duBsa60r/MTOC/ndmElsCGf1sFTZbAHcXgLBZK88J9Qra9Jnrdi3d1r51
QXB52TKCN1fsCDrpxcO0ffb5sKY0R601gTZjNVzyu1AUGatHJ0QiRRL+AkDV1aqcr5
FJ85aJchydiF6SQd7PiXG8eK+5zGLJVGpMGC1jA8=
X-Virus-Scanned: amavisd-new at levieil.fr
Received: from mail.levieil.fr ([127.0.0.1])
by localhost (mail.levieil.fr [127.0.0.1]) (amavisd-new, port 10026)
with ESMTP id PSSUN03IorFI for <freebsd-stable@freebsd.org>;
Thu, 6 Apr 2017 17:28:30 -0400 (EDT)
Received: from mail.levieil.fr (mail.levieil.fr [144.217.14.210])
by mail.levieil.fr (Postfix) with ESMTP id 1493E1A16A09
for <freebsd-stable@freebsd.org>; Thu, 6 Apr 2017 17:28:30 -0400 (EDT)
Date: Thu, 6 Apr 2017 17:28:29 -0400 (EDT)
From: julien levieil <julien@levieil.fr>
To: freebsd-stable@freebsd.org
Message-ID: <2045203797.3766.1491514109923.JavaMail.zimbra@levieil.fr>
In-Reply-To: <mailman.15.1491480000.83981.freebsd-stable@freebsd.org>
References: <mailman.15.1491480000.83981.freebsd-stable@freebsd.org>
Subject: Re: freebsd-stable Digest, Vol 714, Issue 4
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [144.217.14.210]
X-Mailer: Zimbra 8.7.1_GA_1670 (ZimbraWebClient - FF52
([unknown])/8.7.1_GA_1670)
Thread-Topic: freebsd-stable Digest, Vol 714, Issue 4
Thread-Index: YZSC7XVycOl238bDN+Wf72OiketkcA==
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Apr 2017 21:35:26 -0000
Nan pose comme =C3=A7a c'est tr=C3=A8s bien !
Au pire premi=C3=A8re semaine d'Ao=C3=BCt jpourrai garder les loulou un peu=
t ;) enfin si tu veux bien :)
----- Mail original -----
De: freebsd-stable-request@freebsd.org
=C3=80: freebsd-stable@freebsd.org
Envoy=C3=A9: Jeudi 6 Avril 2017 23:00:00
Objet: freebsd-stable Digest, Vol 714, Issue 4
Send freebsd-stable mailing list submissions to
=09freebsd-stable@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
=09https://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body 'help' to
=09freebsd-stable-request@freebsd.org
You can reach the person managing the list at
=09freebsd-stable-owner@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-stable digest..."
Today's Topics:
1. Unsupported USB BT device causes high interrupt load
(Dominic Fandrey)
----------------------------------------------------------------------
Message: 1
Date: Thu, 6 Apr 2017 12:16:35 +0200
From: Dominic Fandrey <kami@freebsd.org>
To: freebsd-stable@freebsd.org
Subject: Unsupported USB BT device causes high interrupt load
Message-ID: <20170406121635.99a513360faaf2f40992fb8a@freebsd.org>
Content-Type: text/plain; charset=3D"us-ascii"
I have an Interrupt load of 2000 interrupts/s from xhci0.
As the culprit I have identified the following device:
ugen0.6: <vendor 0x8087 product 0x07dc> at usbus0, cfg=3D255 md=3DHOST spd=
=3DFULL (12Mbps) pwr=3DON (100mA)
The impression I have from googling this is that it's an unsupported
BT device sitting on board of my Intel Wireless AC 7260 card (I also
have an unsupported SD/MMC card reader sitting on the mainboard).
usbconfig -d 0.6 power_off
Ends the interrupt spree.
I'm running FreeBSD 11.0-STABLE #1 r316490 amd64.
--=20
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?=20
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/2017040=
6/975bb48d/attachment-0001.sig>
------------------------------
Subject: Digest Footer
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
------------------------------
End of freebsd-stable Digest, Vol 714, Issue 4
**********************************************
From owner-freebsd-stable@freebsd.org Thu Apr 6 23:57:55 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42767D32725;
Thu, 6 Apr 2017 23:57:55 +0000 (UTC)
(envelope-from brooks@spindle.one-eyed-alien.net)
Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net
[199.48.129.229])
(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 240C4653;
Thu, 6 Apr 2017 23:57:54 +0000 (UTC)
(envelope-from brooks@spindle.one-eyed-alien.net)
Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001)
id 8C1845A9F14; Thu, 6 Apr 2017 23:57:47 +0000 (UTC)
Date: Thu, 6 Apr 2017 23:57:47 +0000
From: Brooks Davis <brooks@freebsd.org>
To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org,
freebsd-atm@freebsd.org
Subject: Impending NATM removal
Message-ID: <20170406235747.GA8756@spindle.one-eyed-alien.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV"
Content-Disposition: inline
User-Agent: Mutt/1.7.2 (2016-11-26)
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Apr 2017 23:57:55 -0000
--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
As previously threatened, I plan to remove NATM support next week. This
includes the drivers en(4), fatm(4), hatm(4), and patm(4). None of
these devices have been manufactured in the last 20 years so it is time
to move on.
The planned commit can be seen at https://reviews.freebsd.org/D9883
-- Brooks
--HcAYCG3uE/tztfnV
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJY5tX6AAoJEKzQXbSebgfA9UoH/2jKQgdw6IoR7M7N8i7z70FX
PSk5WWqilBTy0szmGJxMGcV1h3euRxGvCHCtxhzunifOh2Ad1CQgHJCuK/4wer88
NQeNcWh6MfhyO2zKocbT/TRdK1e5qDFcMTh+CGC8DKvVYqpvHDpz1T33bp5slXhG
T8AaQrls5+iKHnmiszyQt9DqB62c9mMxKBAssD0auZZ9XdM1ZHa6F796dt89xgI2
oQGksru0M1kKK3rQxoWrhRHAsmTjoMldx9+4+Pmv1/psy80kXclu5elS+RafoQz3
Gqacuk4G/iEtOSGtWKA6Nlt7GUFX+hUjm8rMCb+EmAjC5A0QrU+tiH05jdR7gUM=
=SaZ7
-----END PGP SIGNATURE-----
--HcAYCG3uE/tztfnV--
From owner-freebsd-stable@freebsd.org Fri Apr 7 07:36:18 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F20CD314BA
for <freebsd-stable@mailman.ysv.freebsd.org>;
Fri, 7 Apr 2017 07:36:18 +0000 (UTC)
(envelope-from mendozadonaciano@outlook.com)
Received: from NAM04-SN1-obe.outbound.protection.outlook.com
(mail-sn1nam04olkn0803.outbound.protection.outlook.com
[IPv6:2a01:111:f400:fe4c::803])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
(Client CN "mail.protection.outlook.com",
Issuer "Microsoft IT SSL SHA2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id E81583E1
for <freebsd-stable@freebsd.org>; Fri, 7 Apr 2017 07:36:17 +0000 (UTC)
(envelope-from mendozadonaciano@outlook.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
bh=DxL+MbKMKjCDgM3R/gVJdGNmudopyXwwoQYg7jyjmuc=;
b=G5WBUh9+/amk7UNe4OFDwHC7naxIm+lhCVmgsPoXaDSqgAE7m6HSK4/BCC0STPhchtn9srQPQ7wuddbXtJK7CVQtROiYLPUxjXq3+Q9oRkZHC6EExnJC3vUh7grhdQADTNp+e2PrG7zJgmk7HlvjpneF+H6/WrDZquw6y5JSAiYcyjvTO2Rl6qp+cWNa8hHOqTKU7lirtd24KnmvlSd5pzgkuKzsLC3V0LkhxayXAP8GZJsp+4PmGudSjKs00s38s6S5Ye7qQvmuYkPXaEeqE1M5aue6GMpWlEELSvGC1Z/pqOZp9T5CG+8GcZC6JXZtQXN/ygkCywqdjUCMIPYjGQ==
Received: from BN3NAM04FT008.eop-NAM04.prod.protection.outlook.com
(10.152.92.55) by BN3NAM04HT062.eop-NAM04.prod.protection.outlook.com
(10.152.93.68) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1005.5; Fri, 7 Apr
2017 07:35:56 +0000
Received: from CY4PR2201MB1525.namprd22.prod.outlook.com (10.152.92.52) by
BN3NAM04FT008.mail.protection.outlook.com (10.152.92.168) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
15.1.1019.14 via Frontend Transport; Fri, 7 Apr 2017 07:35:56 +0000
Received: from CY4PR2201MB1525.namprd22.prod.outlook.com ([10.171.241.21]) by
CY4PR2201MB1525.namprd22.prod.outlook.com ([10.171.241.21]) with
mapi id 15.01.1005.019; Fri, 7 Apr 2017 07:35:56 +0000
From: Cancion Guitarra <mendozadonaciano@outlook.com>
To: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org>,
"memdozadonaciano@outloo.com" <memdozadonaciano@outloo.com>
Subject: Rv: Automatic reply: No se puede entregar: Hola
Thread-Topic: Automatic reply: No se puede entregar: Hola
Thread-Index: AQHSr3D9EkX/5uUm1UeqldAbD30h96G5gzuBgAABEhU=
Date: Fri, 7 Apr 2017 07:35:56 +0000
Message-ID: <CY4PR2201MB1525ADAE0539F941279C64EDC40C0@CY4PR2201MB1525.namprd22.prod.outlook.com>
References: <CY4PR2201MB15256E6BE6ACF15601FEDBA8C40C0@CY4PR2201MB1525.namprd22.prod.outlook.com>,
<16d3be7dc1874a548845ceee83e573ea@MWHPR09MB1440.namprd09.prod.outlook.com>
In-Reply-To: <16d3be7dc1874a548845ceee83e573ea@MWHPR09MB1440.namprd09.prod.outlook.com>
Accept-Language: es-MX, en-US
Content-Language: es-MX
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: freebsd.org; dkim=none (message not signed)
header.d=none;freebsd.org; dmarc=none action=none header.from=outlook.com;
x-incomingtopheadermarker: OriginalChecksum:1F7CD1667923B85A5C75213F883F5A49E2A93A6F626B95671434219759BBC6DF;
UpperCasedChecksum:25441A14D2DA05C55683F9AD39B256EE21F0B90445ADE4B31DE1426F68BCC40C;
SizeAsReceived:8342; Count:42
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [O4cfbwDLMnUHrpHPOFqJdxPbBEnfv/uVlmoJ0OlR1XU=]
x-microsoft-exchange-diagnostics: 1; BN3NAM04HT062;
5:mUQrQHt7/nPJ8P3T4qdVWp8o/7Tv52zGBKFmQNyMmwkvT2LvP/7ty0fpfAxJqxrGSQRjJB2nnvzrAKJSxZdFsoI52O2pQRoKZDnGqLggkZjtsjmNkOXb67dns3A0pkGWet00eEVfD06cYRmYMqHd/Q==;
24:ubFT/LAaFYD5Tzpt/kzmJoVZrz8/oZY+VCZsyleCPkNVtUmLIVjYhh53o60fUCxkMAN0MwiNxKgjNPo4J7uZn39T+pUmzRzpSYVc5S95KFE=;
7:ymY8zxYWZiR9Ezw0sZkj1azc+hUusHnTjJGihl8KXSsyx5jvLiOy9emjVlZ32Wuw3q09udYs9MpqhzexRmYzok0oAYqApJFHq3go0ytTJnbG3qKW2Zw8lUyb2LBsSgj68jj7EcZTtvyBQfnnFCM2pou0xpBlLLPQwFhe6wSxcvDtbrjlS3A0xv1u0mjoFRrEiPtLmfcvBh2auTWkilIENmPkNRCmEMzPUXjeAabsPffMAqo2O5/pFyBWuusq7TOgc9j8oZBIzJhI33bHfCz9UuaLXTloY79mO5JomSdf6b67KHPZ+3+vvgbbE2bAUm/B
x-incomingheadercount: 42
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004);
DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM04HT062;
H:CY4PR2201MB1525.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en;
x-ms-office365-filtering-correlation-id: f62987bf-e8d0-4114-056d-08d47d88ba89
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322274)(1603101448)(1601125374)(1701031045);
SRVR:BN3NAM04HT062;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
SRVR:BN3NAM04HT062; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM04HT062;
x-forefront-prvs: 0270ED2845
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2017 07:35:56.3117 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM04HT062
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
X-Content-Filtered-By: Mailman/MimeDel 2.1.23
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2017 07:36:18 -0000
DQoNClNlbnQgZnJvbSBteSBNZXRyb1BDUyA0RyBMVEUgQW5kcm9pZCBkZXZpY2UNCg0KDQotLS0t
LS0gTWVuc2FqZSBvcmlnaW5hbC0tLS0tLQ0KDQpEZXNkZTogV2FsdGVybWlyZSwgRGF2aWQgQS4g
KEZlZCkNCg0KRmVjaGE6IHZpZS4sIGFici4gNywgMjAxNyAxMjozMiBBTQ0KDQpQYXJhOiBDYW5j
aW9uIEd1aXRhcnJhOw0KDQpDYzoNCg0KQXN1bnRvOkF1dG9tYXRpYyByZXBseTogTm8gc2UgcHVl
ZGUgZW50cmVnYXI6IEhvbGENCg0KSSBhbSBvdXQgb2YgdGhlIG9mZmljZSBhbmQgYXdheSBmcm9t
IGVtYWlsIGFuZCB2b2ljZW1haWwgdW50aWwgQXByaWwgMTB0aCwgMjAxNy4gSWYgeW91IG5lZWQg
aW1tZWRpYXRlIGFzc2lzdGFuY2UsIHBsZWFzZSBjb250YWN0IExlZSBCYWRnZXIgYnkgZS1tYWls
IGF0IG1hcmsuYmFkZ2VyQG5pc3QuZ292LjxtYWlsdG86JTIwbWFyay5iYWRnZXJAbmlzdC5nb3Yu
Pg0KIElTTyAtIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRpb24N
Cg0KaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9tYXBzL2Qvdmlld2VyP21pZD0xX2MwSEpHQWt1Mjc5
OUc1OUJ4Yng5NHlXZGg0DQpTaW5jZXJlbHksDQpEYXZpZCBXYWx0ZXJtaXJlDQo=
From owner-freebsd-stable@freebsd.org Fri Apr 7 09:32:14 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id E796CD31137;
Fri, 7 Apr 2017 09:32:14 +0000 (UTC) (envelope-from rb@gid.co.uk)
Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250])
(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 6FC70268;
Fri, 7 Apr 2017 09:32:14 +0000 (UTC) (envelope-from rb@gid.co.uk)
Received: from [194.32.164.15] ([194.32.164.15])
by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id v379Sx7W087411;
Fri, 7 Apr 2017 10:29:00 +0100 (BST) (envelope-from rb@gid.co.uk)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Impending NATM removal
From: Bob Bishop <rb@gid.co.uk>
In-Reply-To: <20170406235747.GA8756@spindle.one-eyed-alien.net>
Date: Fri, 7 Apr 2017 10:28:59 +0100
Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org,
freebsd-atm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D097C8CF-7B7A-4B80-9061-91D8830730D5@gid.co.uk>
References: <20170406235747.GA8756@spindle.one-eyed-alien.net>
To: Brooks Davis <brooks@freebsd.org>
X-Mailer: Apple Mail (2.3124)
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2017 09:32:15 -0000
Hi,
> On 7 Apr 2017, at 00:57, Brooks Davis <brooks@freebsd.org> wrote:
>=20
> As previously threatened, I plan to remove NATM support next week. =
This
> includes the drivers en(4), fatm(4), hatm(4), and patm(4). None of
> these devices have been manufactured in the last 20 years so it is =
time
> to move on.
I don=E2=80=99t have a dog in this fight, but for instance ProSum =
PROATM-E155 (patm(4)) still appear to be available. See =
http://www.prosum.net/en/products/atm-adapters
> The planned commit can be seen at https://reviews.freebsd.org/D9883
>=20
> -- Brooks
--
Bob Bishop
rb@gid.co.uk
From owner-freebsd-stable@freebsd.org Fri Apr 7 12:03:51 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D8DCD2F3FB
for <freebsd-stable@mailman.ysv.freebsd.org>;
Fri, 7 Apr 2017 12:03:51 +0000 (UTC)
(envelope-from pblok@bsd4all.org)
Received: from smtpq2.tb.mail.iss.as9143.net (smtpq2.tb.mail.iss.as9143.net
[212.54.42.165])
(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 D1C079A7
for <freebsd-stable@freebsd.org>; Fri, 7 Apr 2017 12:03:50 +0000 (UTC)
(envelope-from pblok@bsd4all.org)
Received: from [212.54.42.134] (helo=smtp10.tb.mail.iss.as9143.net)
by smtpq2.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2)
(envelope-from <pblok@bsd4all.org>) id 1cwSG0-0005lX-4g
for freebsd-stable@freebsd.org; Fri, 07 Apr 2017 13:40:48 +0200
Received: from 5ed15678.cm-7-2b.dynamic.ziggo.nl ([94.209.86.120]
helo=wan0.bsd4all.org)
by smtp10.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2)
(envelope-from <pblok@bsd4all.org>) id 1cwSG0-0008Vl-0t
for freebsd-stable@freebsd.org; Fri, 07 Apr 2017 13:40:48 +0200
Received: from newnas (localhost [127.0.0.1])
by wan0.bsd4all.org (Postfix) with ESMTP id CB01C719E
for <freebsd-stable@freebsd.org>; Fri, 7 Apr 2017 13:40:47 +0200 (CEST)
X-Virus-Scanned: amavisd-new at bsd4all.org
Received: from wan0.bsd4all.org ([127.0.0.1])
by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id dEafFsJvdOEC for <freebsd-stable@freebsd.org>;
Fri, 7 Apr 2017 13:40:47 +0200 (CEST)
Received: from [192.168.1.64] (mm [192.168.1.64])
by wan0.bsd4all.org (Postfix) with ESMTPSA id 19B3B7193
for <freebsd-stable@freebsd.org>; Fri, 7 Apr 2017 13:40:47 +0200 (CEST)
From: Peter Blok <pblok@bsd4all.org>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: panic in pfcioctl
Message-Id: <86468517-69FF-4398-8FA9-0D7045CDD32B@bsd4all.org>
Date: Fri, 7 Apr 2017 13:40:46 +0200
To: freebsd-stable@freebsd.org
X-Mailer: Apple Mail (2.3273)
X-SourceIP: 94.209.86.120
X-Ziggo-spambar: /
X-Ziggo-spamscore: 0.0
X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=Yup/f8QX c=1 sm=1 tr=0
a=IkzOOneQUJP1+bAPekPvBg==:17 a=AzvcPWV-tVgA:10 a=VZgy4sajuSPyX5v6hS8A:9
a=gAzRF1EebyQqZOAd:21 a=7KVw9ZI5iXHqQYMN:21 a=QEXdDO2ut3YA:10
a=516TZ-q17AJPlmKMHRMA:9 a=E-tUg0QQAIHu88kl:21 a=_W_S_7VecoQA:10
none
X-Ziggo-Spam-Status: No
X-Spam-Status: No
X-Spam-Flag: No
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.23
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2017 12:03:51 -0000
Hi,
I=E2=80=99m running 11-STABLE rev 316522.
I recently had a panic while doing a pfctl -f /etc/pf.conf
The panic happens on LIST_REMOVE in keg_fetch_slab
static uma_slab_t
keg_fetch_slab(uma_keg_t keg, uma_zone_t zone, int flags)
{
uma_slab_t slab;
int reserve;
mtx_assert(&keg->uk_lock, MA_OWNED);
slab =3D NULL;
reserve =3D 0;
if ((flags & M_USE_RESERVE) =3D=3D 0)
reserve =3D keg->uk_reserve;
for (;;) {
/*
* Find a slab with some space. Prefer slabs that are =
partially
* used over those that are totally full. This helps to =
reduce
* fragmentation.
*/
if (keg->uk_free > reserve) {
if (!LIST_EMPTY(&keg->uk_part_slab)) {
slab =3D LIST_FIRST(&keg->uk_part_slab);
} else {
slab =3D LIST_FIRST(&keg->uk_free_slab);
LIST_REMOVE(slab, us_link);
LIST_INSERT_HEAD(&keg->uk_part_slab, =
slab,
us_link);
}
MPASS(slab->us_keg =3D=3D keg);
return (slab);
}
KDB: stack backtrace:
#0 0xffffffff805df0e7 at kdb_backtrace+0x67
#1 0xffffffff8059d176 at vpanic+0x186
#2 0xffffffff8059cfe3 at panic+0x43
#3 0xffffffff808ebaa2 at trap_fatal+0x322
#4 0xffffffff808ebaf9 at trap_pfault+0x49
#5 0xffffffff808eb336 at trap+0x286
#6 0xffffffff808d1441 at calltrap+0x8
#7 0xffffffff808a871e at zone_fetch_slab+0x6e
#8 0xffffffff808a87cd at zone_import+0x4d
#9 0xffffffff808a4fc9 at uma_zalloc_arg+0x529
#10 0xffffffff80803214 at pfr_ina_define+0x584
#11 0xffffffff807f0734 at pfioctl+0x3364
#12 0xffffffff80469288 at devfs_ioctl_f+0x128
#13 0xffffffff805fa925 at kern_ioctl+0x255
#14 0xffffffff805fa65f at sys_ioctl+0x16f
#15 0xffffffff808ec604 at amd64_syscall+0x6c4
#16 0xffffffff808d172b at Xfast_syscall+0xfb
The panic is not reproducible.
So far the 1st time I stop a jail I get (numbers vary)
kernel: Freed UMA keg (pf table entries) was not empty (32 items). Lost =
-57 pages of memory.
Any tips on how to debug/avoid this?
Peter=
From owner-freebsd-stable@freebsd.org Fri Apr 7 13:26:36 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id D47DAD309F3;
Fri, 7 Apr 2017 13:26:36 +0000 (UTC)
(envelope-from tomek.cedro@gmail.com)
Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com
[IPv6:2607:f8b0:4003:c06::243])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 94CC4634;
Fri, 7 Apr 2017 13:26:36 +0000 (UTC)
(envelope-from tomek.cedro@gmail.com)
Received: by mail-oi0-x243.google.com with SMTP id f193so12038569oib.0;
Fri, 07 Apr 2017 06:26:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to; bh=Ksj7uyadpmIpRbL7hRaT8xPsoc+BBxK2z+SuYEr1hng=;
b=n03zqF2WPRRaoL5Gu31vglmu+lEMVQAi2cJHpmg++rSKb+dtA6jQTYGuhDzcni7PnC
WLlw7i1K0NrpMLgc/MJ89ER1QwS159kLJvv9LTvseeIUgvSJHZSRrBf9KwpZ+DE4VCe9
kul9NALqkQJtrNBfFRQZjmmrm+4QhE0VbruUC/sQsgp6VrcgjEKJGN0qk9dqJ2gCQM7u
zrHTySxJ1nK7Mw0jLieEun45AcJWuLaNWrQZcCIERTUsWHTESsYp4bqjR3mhyMQZ749O
cF9//VZKfe0cHvbKb581UfRizgOH0hS1aCWculT10lN//F4dqfj13M1BfzqBZLvaH14m
3aeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to;
bh=Ksj7uyadpmIpRbL7hRaT8xPsoc+BBxK2z+SuYEr1hng=;
b=kw4hYgg8u6T9FVQBywL5nzoyF2tPJb17ax0jOAWPkNynCfhshZn7kiDp4ofja0Fq6Q
7c7DTTuGaL6r+Jm9aANivhMgssbhV+wq2w5TkE3kJowpi2dD/OCGN6y5Czm2mhVAtBIy
/HzRierabdCSxMVXtAg0y5LTxsw6a+qsWsnuxlH8sfEBjw/HTpgsH1eXFAXWSs9SyxkH
KDO/ZO2iuu/Am3G/QydBwMwaETOcOof3d6KMPYDkqFuMQIoWJeaXvf7w0zOaAEDmoloK
nzTdPLONEvpwU+a8FgrxozsEp5p4UPnuVQvru4U2n7JOlwqa2T/QDcDZUefq7NCQwKmw
Bqtw==
X-Gm-Message-State: AN3rC/6AdLaCskVfp8oDY2Psk3CYZGVPYjDSokGCDkn4PUDDRFvF/KfKqFjoCsc9qbBZmIA77d3VdeJ8lhO0Cw==
X-Received: by 10.202.241.137 with SMTP id p131mr582394oih.159.1491571595713;
Fri, 07 Apr 2017 06:26:35 -0700 (PDT)
MIME-Version: 1.0
Sender: tomek.cedro@gmail.com
Received: by 10.157.38.70 with HTTP; Fri, 7 Apr 2017 06:26:35 -0700 (PDT)
Received: by 10.157.38.70 with HTTP; Fri, 7 Apr 2017 06:26:35 -0700 (PDT)
In-Reply-To: <CAFYkXjm7Z=VoKgkrsSfubK1kUMk_3WjgrDbk8tGM=4bKMotbKA@mail.gmail.com>
References: <CAFYkXjmpwHMzYv6FBDvY3yzKj5swg-aCWy0htQozQ-wp=tZdQA@mail.gmail.com>
<CAFYkXjnugPW8yEVzsBWJ2XP9BsQm869ygikair4+i_x41QhgGw@mail.gmail.com>
<CAFYkXjm6cjXg2hEVi=7h4xM-Z+=92kJ98himwjnG9gCzmW6DqA@mail.gmail.com>
<CAFYkXjnxBmXNHuhm-QGVKdOSH8_ctK29Rkh-y6tE40A_JC8Tng@mail.gmail.com>
<CAFYkXjkzCobuOyKSL+XFkG_WxWoksqYwWwuP-4VJK8OgVmD_EA@mail.gmail.com>
<CAFYkXj=N84ASjZoF8gzM8rAgLgqFE2iTVVUDAjyRrcfrVV9u+w@mail.gmail.com>
<CAFYkXjmWUVAhR=tuteftxuXE=tuZCHM6gMJAmMPONJGpEu6Gtg@mail.gmail.com>
<CAFYkXjmOLZhsQWtZD0VdJqcpftMgcgb8rztQ1KiTw7y6PXy8LA@mail.gmail.com>
<CAFYkXjm7Z=VoKgkrsSfubK1kUMk_3WjgrDbk8tGM=4bKMotbKA@mail.gmail.com>
From: Tomasz CEDRO <tomek@cedro.info>
Date: Fri, 7 Apr 2017 15:26:35 +0200
X-Google-Sender-Auth: 62AGvbXK-s-aOY0JSJ64th2pOKI
Message-ID: <CAFYkXj=o3=Qa58gTvBARBEsKoJca=gt+TkayYPK8B4vJiZwJKg@mail.gmail.com>
Subject: if_iwm crashes kernel when loaded from /boot/loader.conf
To: freebsd-wireless@freebsd.org, freebsd-hardware@freebsd.org,
FreeBSD Stable <freebsd-stable@freebsd.org>
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.23
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2017 13:26:36 -0000
Hello,
I noticed a problem when loading if_iwm from /boot/loader.conf kernel
crashes as it cannot load module firmware dead loop occurs. Adding
iwm8000Cfw before if_iwm does not help.
Loading if_iwm on a running system works fine and gives operational wifi.
Intel Corporation Wireless 8260 class=0x028000 card=0x10108086
chip=0x24f38086 rev=0x3a hdr=0x00
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
From owner-freebsd-stable@freebsd.org Fri Apr 7 14:38:52 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF27FD32795;
Fri, 7 Apr 2017 14:38:52 +0000 (UTC)
(envelope-from tommi.pernila@gmail.com)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com
[IPv6:2607:f8b0:400d:c0d::229])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 6FE4FA75;
Fri, 7 Apr 2017 14:38:52 +0000 (UTC)
(envelope-from tommi.pernila@gmail.com)
Received: by mail-qt0-x229.google.com with SMTP id v3so12594193qtd.3;
Fri, 07 Apr 2017 07:38: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;
bh=QmBoU0cuFXqAiA4VWpCG+m1MuFBM7/bLfU1rAY1R6Bo=;
b=XDa3B8oDCPkiRfEKScSaPBIjOBot04uyu+xEThkjIbkUoisURGz/amW7DFhBqPg+Yd
HvpIN/COG4s54/Ams6+nOoRXq3KbgJDNh6oxolWxu37jOXfozX6+u2Fzto7iGzhioPcd
nhkqU5jMTVL4L2vjgiu8dfXDNv7i0DLDsvrKPo/dupEI+/eKxlmCw0dYbkqP76Kpi4MN
LI96knTxi9r1esKXg+YoQIvCUtFhS/elHi6urkp/uDJRiPkig4n+2DGS51AppTDrc7cB
pZvKR6o62JnNBm6k8Kc54grl25J9EujUwryP4OhKj808SwOWfXv8IfFCdkv2DCzkhVW+
Sbkw==
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;
bh=QmBoU0cuFXqAiA4VWpCG+m1MuFBM7/bLfU1rAY1R6Bo=;
b=Nps0nVEaCQcnoAJTDs2hUkL26b+v0fqcFsrC4tm6obDsChD5pph5GR9yK/m+8emByW
OzrGQjCczHA5OJAUQzCRgwS8Iye/MEdMMkIlFajeJyKFN8UC8jAzg77YEwk9xJEtZ4Yd
BAC4OUsUCOgOF9n6bnKqa2cDr3K+9kBY5l42kuRfIYBW1Ag9HLRxKDwGQV2xmeM30n15
vYGRPvLqjXVLp/iHKFqnyWJl8PDezL+F1hVELKiieXFWI8iomMZBOauOIzP+8AVFXAeM
9OsFKrgVcmD++2B/1L3lwbxTIS3N6q88TQpXONxBHiJpwQGiTrRRPoxBLBD8EXyLcUuZ
dGAg==
X-Gm-Message-State: AFeK/H0lIDMwGWuu2HDSj/+6/wqpuRFPpVtHtWJApVjLhIeRic6CU+4vEx0Mzgkb6BSZckFqKH+PpxqhmmSBmQ==
X-Received: by 10.237.34.140 with SMTP id p12mr44223652qtc.111.1491575931437;
Fri, 07 Apr 2017 07:38:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAFYkXjmpwHMzYv6FBDvY3yzKj5swg-aCWy0htQozQ-wp=tZdQA@mail.gmail.com>
<CAFYkXjnugPW8yEVzsBWJ2XP9BsQm869ygikair4+i_x41QhgGw@mail.gmail.com>
<CAFYkXjm6cjXg2hEVi=7h4xM-Z+=92kJ98himwjnG9gCzmW6DqA@mail.gmail.com>
<CAFYkXjnxBmXNHuhm-QGVKdOSH8_ctK29Rkh-y6tE40A_JC8Tng@mail.gmail.com>
<CAFYkXjkzCobuOyKSL+XFkG_WxWoksqYwWwuP-4VJK8OgVmD_EA@mail.gmail.com>
<CAFYkXj=N84ASjZoF8gzM8rAgLgqFE2iTVVUDAjyRrcfrVV9u+w@mail.gmail.com>
<CAFYkXjmWUVAhR=tuteftxuXE=tuZCHM6gMJAmMPONJGpEu6Gtg@mail.gmail.com>
<CAFYkXjmOLZhsQWtZD0VdJqcpftMgcgb8rztQ1KiTw7y6PXy8LA@mail.gmail.com>
<CAFYkXjm7Z=VoKgkrsSfubK1kUMk_3WjgrDbk8tGM=4bKMotbKA@mail.gmail.com>
<CAFYkXj=o3=Qa58gTvBARBEsKoJca=gt+TkayYPK8B4vJiZwJKg@mail.gmail.com>
In-Reply-To: <CAFYkXj=o3=Qa58gTvBARBEsKoJca=gt+TkayYPK8B4vJiZwJKg@mail.gmail.com>
From: Tommi Pernila <tommi.pernila@gmail.com>
Date: Fri, 07 Apr 2017 14:38:40 +0000
Message-ID: <CABHD1wQPGT5TT8wSApTkePxtgkCo81ZmgTzLPCLVR=4zJvTNNg@mail.gmail.com>
Subject: Re: if_iwm crashes kernel when loaded from /boot/loader.conf
To: FreeBSD Stable <freebsd-stable@freebsd.org>,
Tomasz CEDRO <tomek@cedro.info>,
freebsd-hardware@freebsd.org, freebsd-wireless@freebsd.org
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.23
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2017 14:38:52 -0000
On Fri, 7 Apr 2017 at 16.27, Tomasz CEDRO <tomek@cedro.info> wrote:
> Hello,
>
> I noticed a problem when loading if_iwm from /boot/loader.conf kernel
> crashes as it cannot load module firmware dead loop occurs. Adding
> iwm8000Cfw before if_iwm does not help.
>
> Loading if_iwm on a running system works fine and gives operational wifi.
>
> Intel Corporation Wireless 8260 class=0x028000 card=0x10108086
> chip=0x24f38086 rev=0x3a hdr=0x00
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
This has been happening to my Intel 8260 as well.
It seems to be a known bug.
I circumvent it by manually loading the wifi modules after boot. This
doesn't crash the system.
As a dirty hack? You could add the loading as a script and automatically
load the modules when the FreeBSD is fully up and running.
Br,
Tommi
>
>
From owner-freebsd-stable@freebsd.org Fri Apr 7 14:41:58 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 517E6D32B1D;
Fri, 7 Apr 2017 14:41:58 +0000 (UTC)
(envelope-from eric@vangyzen.net)
Received: from smtp.vangyzen.net (hotblack.vangyzen.net
[IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f])
by mx1.freebsd.org (Postfix) with ESMTP id 3114A9E;
Fri, 7 Apr 2017 14:41:58 +0000 (UTC)
(envelope-from eric@vangyzen.net)
Received: from ford.home.vangyzen.net (unknown [76.164.15.242])
by smtp.vangyzen.net (Postfix) with ESMTPSA id 7DB495646B;
Fri, 7 Apr 2017 09:41:57 -0500 (CDT)
Subject: Re: if_iwm crashes kernel when loaded from /boot/loader.conf
To: Tommi Pernila <tommi.pernila@gmail.com>,
FreeBSD Stable <freebsd-stable@freebsd.org>, Tomasz CEDRO
<tomek@cedro.info>, freebsd-hardware@freebsd.org,
freebsd-wireless@freebsd.org
References: <CAFYkXjmpwHMzYv6FBDvY3yzKj5swg-aCWy0htQozQ-wp=tZdQA@mail.gmail.com>
<CAFYkXjnugPW8yEVzsBWJ2XP9BsQm869ygikair4+i_x41QhgGw@mail.gmail.com>
<CAFYkXjm6cjXg2hEVi=7h4xM-Z+=92kJ98himwjnG9gCzmW6DqA@mail.gmail.com>
<CAFYkXjnxBmXNHuhm-QGVKdOSH8_ctK29Rkh-y6tE40A_JC8Tng@mail.gmail.com>
<CAFYkXjkzCobuOyKSL+XFkG_WxWoksqYwWwuP-4VJK8OgVmD_EA@mail.gmail.com>
<CAFYkXj=N84ASjZoF8gzM8rAgLgqFE2iTVVUDAjyRrcfrVV9u+w@mail.gmail.com>
<CAFYkXjmWUVAhR=tuteftxuXE=tuZCHM6gMJAmMPONJGpEu6Gtg@mail.gmail.com>
<CAFYkXjmOLZhsQWtZD0VdJqcpftMgcgb8rztQ1KiTw7y6PXy8LA@mail.gmail.com>
<CAFYkXjm7Z=VoKgkrsSfubK1kUMk_3WjgrDbk8tGM=4bKMotbKA@mail.gmail.com>
<CAFYkXj=o3=Qa58gTvBARBEsKoJca=gt+TkayYPK8B4vJiZwJKg@mail.gmail.com>
<CABHD1wQPGT5TT8wSApTkePxtgkCo81ZmgTzLPCLVR=4zJvTNNg@mail.gmail.com>
From: Eric van Gyzen <eric@vangyzen.net>
Message-ID: <32c78973-2b73-3433-e30a-fb814af68eab@vangyzen.net>
Date: Fri, 7 Apr 2017 09:41:54 -0500
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <CABHD1wQPGT5TT8wSApTkePxtgkCo81ZmgTzLPCLVR=4zJvTNNg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2017 14:41:58 -0000
On 04/07/2017 09:38, Tommi Pernila wrote:
> On Fri, 7 Apr 2017 at 16.27, Tomasz CEDRO <tomek@cedro.info> wrote:
>
>> Hello,
>>
>> I noticed a problem when loading if_iwm from /boot/loader.conf kernel
>> crashes as it cannot load module firmware dead loop occurs. Adding
>> iwm8000Cfw before if_iwm does not help.
>>
>> Loading if_iwm on a running system works fine and gives operational wifi.
>>
>> Intel Corporation Wireless 8260 class=0x028000 card=0x10108086
>> chip=0x24f38086 rev=0x3a hdr=0x00
>>
>> --
>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
>
> This has been happening to my Intel 8260 as well.
> It seems to be a known bug.
>
> I circumvent it by manually loading the wifi modules after boot. This
> doesn't crash the system.
>
> As a dirty hack? You could add the loading as a script and automatically
> load the modules when the FreeBSD is fully up and running.
$ grep kld_list /etc/defaults/rc.conf
#kld_list="" # Kernel modules to load after local disks are mounted
Eric
From owner-freebsd-stable@freebsd.org Fri Apr 7 15:25:34 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B439D32ED0;
Fri, 7 Apr 2017 15:25:34 +0000 (UTC)
(envelope-from bsd-lists@bsdforge.com)
Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com
[24.113.41.81])
(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 72DA216;
Fri, 7 Apr 2017 15:25:33 +0000 (UTC)
(envelope-from bsd-lists@bsdforge.com)
Received: from ultimatedns.net (localhost [127.0.0.1])
by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v37FQjDr067406;
Fri, 7 Apr 2017 08:26:51 -0700 (PDT)
(envelope-from bsd-lists@bsdforge.com)
To: FreeBSD Stable <freebsd-stable@freebsd.org>, freebsd-hardware@freebsd.org,
<freebsd-wireless@freebsd.org>
In-Reply-To: <CABHD1wQPGT5TT8wSApTkePxtgkCo81ZmgTzLPCLVR=4zJvTNNg@mail.gmail.com>
References: <CAFYkXjmpwHMzYv6FBDvY3yzKj5swg-aCWy0htQozQ-wp=tZdQA@mail.gmail.com>
<CAFYkXjnugPW8yEVzsBWJ2XP9BsQm869ygikair4+i_x41QhgGw@mail.gmail.com>
<CAFYkXjm6cjXg2hEVi=7h4xM-Z+=92kJ98himwjnG9gCzmW6DqA@mail.gmail.com>
<CAFYkXjnxBmXNHuhm-QGVKdOSH8_ctK29Rkh-y6tE40A_JC8Tng@mail.gmail.com>
<CAFYkXjkzCobuOyKSL+XFkG_WxWoksqYwWwuP-4VJK8OgVmD_EA@mail.gmail.com>
<CAFYkXj=N84ASjZoF8gzM8rAgLgqFE2iTVVUDAjyRrcfrVV9u+w@mail.gmail.com>
<CAFYkXjmWUVAhR=tuteftxuXE=tuZCHM6gMJAmMPONJGpEu6Gtg@mail.gmail.com>
<CAFYkXjmOLZhsQWtZD0VdJqcpftMgcgb8rztQ1KiTw7y6PXy8LA@mail.gmail.com>
<CAFYkXjm7Z=VoKgkrsSfubK1kUMk_3WjgrDbk8tGM=4bKMotbKA@mail.gmail.com>
<CAFYkXj=o3=Qa58gTvBARBEsKoJca=gt+TkayYPK8B4vJiZwJKg@mail.gmail.com>,
<CABHD1wQPGT5TT8wSApTkePxtgkCo81ZmgTzLPCLVR=4zJvTNNg@mail.gmail.com>
From: "Chris H" <bsd-lists@bsdforge.com>
Subject: Re: if_iwm crashes kernel when loaded from /boot/loader.conf
Date: Fri, 07 Apr 2017 08:26:51 -0700
Content-Type: text/plain; charset=UTF-8; format=fixed
MIME-Version: 1.0
Message-id: <48fca113c89851fe1c44aa34227edca0@ultimatedns.net>
Content-Transfer-Encoding: 8bit
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2017 15:25:34 -0000
On Fri, 07 Apr 2017 14:38:40 +0000 Tommi Pernila <tommi.pernila@gmail.com>
wrote
> On Fri, 7 Apr 2017 at 16.27, Tomasz CEDRO <tomek@cedro.info> wrote:
>
> > Hello,
> >
> > I noticed a problem when loading if_iwm from /boot/loader.conf kernel
> > crashes as it cannot load module firmware dead loop occurs. Adding
> > iwm8000Cfw before if_iwm does not help.
> >
> > Loading if_iwm on a running system works fine and gives operational wifi.
> >
> > Intel Corporation Wireless 8260 class=0x028000 card=0x10108086
> > chip=0x24f38086 rev=0x3a hdr=0x00
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
>
> This has been happening to my Intel 8260 as well.
> It seems to be a known bug.
Has anyone opened a pr(1)?
At least that way, it would be recorded as a problem.
--Chris
>
> I circumvent it by manually loading the wifi modules after boot. This
> doesn't crash the system.
>
> As a dirty hack? You could add the loading as a script and automatically
> load the modules when the FreeBSD is fully up and running.
>
> Br,
>
> Tommi
>
From owner-freebsd-stable@freebsd.org Sat Apr 8 11:26:46 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B0CFD346E8
for <freebsd-stable@mailman.ysv.freebsd.org>;
Sat, 8 Apr 2017 11:26:46 +0000 (UTC)
(envelope-from etnapierala@gmail.com)
Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3])
by mx1.freebsd.org (Postfix) with ESMTP id 44330A82
for <freebsd-stable@freebsd.org>; Sat, 8 Apr 2017 11:26:46 +0000 (UTC)
(envelope-from etnapierala@gmail.com)
Received: by mailman.ysv.freebsd.org (Postfix)
id 439A0D346E5; Sat, 8 Apr 2017 11:26:46 +0000 (UTC)
Delivered-To: stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43403D346E4
for <stable@mailman.ysv.freebsd.org>; Sat, 8 Apr 2017 11:26:46 +0000 (UTC)
(envelope-from etnapierala@gmail.com)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com
[IPv6:2a00:1450:400c:c09::235])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id C7093A81;
Sat, 8 Apr 2017 11:26:45 +0000 (UTC)
(envelope-from etnapierala@gmail.com)
Received: by mail-wm0-x235.google.com with SMTP id u2so8158148wmu.0;
Sat, 08 Apr 2017 04:26:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=sender:date:from:to:cc:subject:message-id:mail-followup-to
:references:mime-version:content-disposition:in-reply-to:user-agent;
bh=Y20cqAHkbeo3WT8DuIPy52Jok4/T6KptKgXhtTYUTXA=;
b=RVi6qTxVgHvEtQ5/HapxZwLbXU/AyGHNiAGyt02VcnX+BwW310aqZkCzr2va1HHygJ
S2vQzf7lUh5n6/WKjNpSRDF0LO6BkDAgHPYnNC8Zhbv+HQP4mejWqqzoFmSCMhn8Enee
XLYJS49omzA9bMF+p0LrNizcm4YLgNeSmFanaCKnLkWW85oUyTQ1m7nYFO0PckmZbFvL
LpMM+LmXu4ceYyr9cuHhanXKXrJzo+dl9c8lCpqeu0gu6Tl7g+8wp7ovvpl3pQ78xmIz
JtC52N8gPrkpRTH9PU5GUpYVDdqq0UYtqDXq3/RAaT+flaNj7P95FgG6YijtTK9AkM4G
IoOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
:mail-followup-to:references:mime-version:content-disposition
:in-reply-to:user-agent;
bh=Y20cqAHkbeo3WT8DuIPy52Jok4/T6KptKgXhtTYUTXA=;
b=sGoSuNg4lXFfCDKyqEPUFl2nYVHCfNMwsSAKsjGNnDbVnMrRjs0V+7UsWGwJC9Wvhu
W1w0DlHh2gEEcXnvLUrAKuOS1Dco2Z6pb3EGV+TVDJL31jGqjLBnYd82U0BzbohimkeL
bByri3yzN7zG/JS1NmqFu5JvarmHk+SINt4xLRP3uS9Do8Wb5QfQiXQegxlMzBPM6pz2
LXhqAeTbOEtcUAAwVpLDs7pCKFILmOsF1rZG0JjPiVBl8Qxl/k0f6VRDSxMhrB3W3cqj
weJlJwzDltMjewPIl8grbW+iV3xVvq3gptTqjYWBU4W9b+TY5q8k5T+1mu4E4Wz3Kb9g
sc+w==
X-Gm-Message-State: AN3rC/7bFW/Kov7GAdaLpfLrqkUBJd2uG/+W0dioqPGoGCxLNaDSeKTSx76zIx148Y256A==
X-Received: by 10.28.6.213 with SMTP id 204mr3111628wmg.68.1491650804072;
Sat, 08 Apr 2017 04:26:44 -0700 (PDT)
Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net.
[82.9.227.167])
by smtp.gmail.com with ESMTPSA id w12sm9524378wra.21.2017.04.08.04.26.43
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 08 Apr 2017 04:26:43 -0700 (PDT)
Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= <etnapierala@gmail.com>
Date: Sat, 8 Apr 2017 11:59:00 +0100
From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org>
To: Warner Losh <imp@bsdimp.com>
Cc: Pete French <petefrench@ingresso.co.uk>, stable@freebsd.org,
Andriy Gapon <avg@freebsd.org>
Subject: Re: moutnroot failing on zpools in Azure after upgrade from 10 to 11
due to lack of waiting for da0
Message-ID: <20170408105900.GA14604@brick>
Mail-Followup-To: Warner Losh <imp@bsdimp.com>,
Pete French <petefrench@ingresso.co.uk>, stable@freebsd.org,
Andriy Gapon <avg@freebsd.org>
References: <6b397d83-e802-78ca-e24e-6d0713f07212@FreeBSD.org>
<E1coUAY-0000ou-8i@dilbert.ingresso.co.uk>
<CANCZdfpx7gO8O-+t41HwS5tkjakzMntw7WJ9N5pnR+88DzJL=Q@mail.gmail.com>
<CANCZdfpUa6GX2OVT70g4fCM2SwAcdN2ghMFO9UPeN+DC3Pa+6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANCZdfpUa6GX2OVT70g4fCM2SwAcdN2ghMFO9UPeN+DC3Pa+6Q@mail.gmail.com>
User-Agent: Mutt/1.8.0 (2017-02-23)
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Apr 2017 11:26:46 -0000
On 0316T1004, Warner Losh wrote:
> [[ stupid mouse ]]
>
> On Thu, Mar 16, 2017 at 10:01 AM, Warner Losh <imp@bsdimp.com> wrote:
> > On Thu, Mar 16, 2017 at 6:06 AM, Pete French <petefrench@ingresso.co.uk> wrote:
> >>> I don't like the delay and retry approach at all.
> >>
> >> Its not ideal, but it is what we do for UFS after all...
> >>
> >>> Imagine that you told the kernel that you want to mount your root from a ZFS
> >>> pool which is on a USB driver which you have already thrown out. Should the
> >>> kernel just keep waiting for that pool to appear?
> >>
> >> I'm not talking about an infinite loop here, just making it honour
> >> the 'vfs.mountroot.timeout' setting like it does ofr UFS. So it
> >> should wait for the timeout I have set and then proceed as it would if
> >> there had been no timeout. Default behaviout is for it to behave as it
> >> does now, its onyl when you need the retry that you enable it.
> >
> > Put another way: With UFS is keeps retrying until the timeout expires.
> > If the first try succeeds, the boot is immediate.
> >
> >> Right now this works for UFS, but not for ZFS, which is an inconsistency
> >> that I dont like, and also means I am being forced down a UFS root
> >> path if I require this.
> >
> > Yes. ZFS is special, but I don't think the assumptions behind its
> > specialness are quite right:
> >
> > /*
> > * In case of ZFS and NFS we don't have a way to wait for
> > * specific device. Also do the wait if the user forced that
> > * behaviour by setting vfs.root_mount_always_wait=1.
> > */
> > if (strcmp(fs, "zfs") == 0 || strstr(fs, "nfs") != NULL ||
> > dev[0] == '\0' || root_mount_always_wait != 0) {
> > vfs_mountroot_wait();
> > return (0);
> > }
> >
> > So you can make it always succeed by forcing the wait, but that's lame...
>
> Later we check to see if a device by a given name is present. Since
> ZFS doesn't present its pool names as devices to the rest of the
> system, that's not going to work quite right. That's the real reason
> that ZFS is special. It isn't that we can't wait for individual
> devices, it's that we can't wait for the 'mount token' that we use for
> what to mount to be 'ready'. NFS suffers from the same problem, but
> since its device is always ready since it's stateless, it isn't as
> noticeable.
Not sure what you mean. The problem we handle ZFS and NFS in
a different way (always waiting) is _exactly_ so that we don't
have a way to wait for the individual device, like we can for
eg UFS, and we have to fall back to mount tokens, which were
used unconditionally before 11.0.
From owner-freebsd-stable@freebsd.org Sat Apr 8 11:28:45 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id D44BBD348C8
for <freebsd-stable@mailman.ysv.freebsd.org>;
Sat, 8 Apr 2017 11:28:45 +0000 (UTC)
(envelope-from etnapierala@gmail.com)
Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3])
by mx1.freebsd.org (Postfix) with ESMTP id B0256C18
for <freebsd-stable@freebsd.org>; Sat, 8 Apr 2017 11:28:45 +0000 (UTC)
(envelope-from etnapierala@gmail.com)
Received: by mailman.ysv.freebsd.org (Postfix)
id AC8EBD348C6; Sat, 8 Apr 2017 11:28:45 +0000 (UTC)
Delivered-To: stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC1D4D348C5
for <stable@mailman.ysv.freebsd.org>; Sat, 8 Apr 2017 11:28:45 +0000 (UTC)
(envelope-from etnapierala@gmail.com)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com
[IPv6:2a00:1450:400c:c09::22c])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 54DC3C16
for <stable@freebsd.org>; Sat, 8 Apr 2017 11:28:45 +0000 (UTC)
(envelope-from etnapierala@gmail.com)
Received: by mail-wm0-x22c.google.com with SMTP id o81so8612981wmb.1
for <stable@freebsd.org>; Sat, 08 Apr 2017 04:28:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=sender:date:from:to:cc:subject:message-id:mail-followup-to
:references:mime-version:content-disposition:in-reply-to:user-agent;
bh=hbi5pGCbEZvmHCxZAIdx2qnr8Zq55UlH+KbeI/wVunw=;
b=nuJOR97RMJOsBOUEsFC6qOge05cAiQjbCu4qpgTeVqf3v+vJ7opFI05iqBsaLHejzb
p9og1OCc8lA4D6cU4uG6/To89abKTLLQ3BGDRwBv9VxhSmPa3ltZyGT6ARzSrxVVcrxP
Qfm0mrK9RcgZSLK3iPHFCCTCLLCYyP2nWA1evxyf8fwv8Wd+OPB+QFoLTpXQxAm6TVfA
duIbQZH96NHDRPHJVUuTa7QxtkzUfS6VMze8KArkHtK3fRlj66FQJmnaj2Px1cngxgw5
HKlxlMqK1HR3AFEojMKNNhNz6eUFhSCnwqXxK3vmqHCZli+rO8HlQ6XmiVBLAb5ve5VD
G6NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
:mail-followup-to:references:mime-version:content-disposition
:in-reply-to:user-agent;
bh=hbi5pGCbEZvmHCxZAIdx2qnr8Zq55UlH+KbeI/wVunw=;
b=maeKndvOUdIenZ+eLISU66RfhQ429AGiteSIoIzGPPhmQy5VUoYcM1DMsUrXYOOTEE
7t1JGJ/PBtJ8Jii16uIpZMRkFvL/VgZaXKdwY1wy0C41B4o+X4dXBAidjpQcHfmBwshT
MWQqRZ/dJoyjIfXi9/wzdH/OuAqI5LMC04gxPMBRRkpjdvdR5E0Mc6L7945h1y2vOU2h
JIb1FZ5XYVhORTL6iikX2qtk0naxU3g75E5jXXyP1GmJxLGbfwHDqsbrYYqi/D0NHn7U
5ke7gffc0qPoeeq12qpxGHmkiqVitV4bLaZrENfBAuwBvodmxAYNRYirJ3WDrXUiZ3kt
RDNw==
X-Gm-Message-State: AN3rC/4BHH7Do1dznPLFuhV34O4TWFkiBNF4c4age88JZYCk0JYEVoqOM6Np9I0GZb2Iyg==
X-Received: by 10.28.169.130 with SMTP id s124mr2850955wme.137.1491650923674;
Sat, 08 Apr 2017 04:28:43 -0700 (PDT)
Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net.
[82.9.227.167])
by smtp.gmail.com with ESMTPSA id z38sm9614436wrc.36.2017.04.08.04.28.42
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 08 Apr 2017 04:28:43 -0700 (PDT)
Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= <etnapierala@gmail.com>
Date: Sat, 8 Apr 2017 12:01:00 +0100
From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org>
To: Pete French <petefrench@ingresso.co.uk>
Cc: stable@freebsd.org
Subject: Re: moutnroot failing on zpools in Azure after upgrade from 10 to 11
due to lack of waiting for da0
Message-ID: <20170408110100.GB14604@brick>
Mail-Followup-To: Pete French <petefrench@ingresso.co.uk>, stable@freebsd.org
References: <E1cnOkS-0000oL-Ia@dilbert.ingresso.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1cnOkS-0000oL-Ia@dilbert.ingresso.co.uk>
User-Agent: Mutt/1.8.0 (2017-02-23)
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Apr 2017 11:28:45 -0000
On 0313T1206, Pete French wrote:
> I have a number of machines in Azure, all booting from ZFS and, until
> the weekend, running 10.3 perfectly happily.
>
> I started upgrading these to 11. The first went fine, the second would
> not boot. Looking at the boot diagnistics it is having problems finding the
> root pool to mount. I see this is the diagnostic output:
>
> storvsc0: <Hyper-V IDE Storage Interface> on vmbus0
> Solaris: NOTICE: Cannot find the pool label for 'rpool'
> Mounting from zfs:rpool/ROOT/default failed with error 5.
> Root mount waiting for: storvsc
> (probe0:blkvsc0:0:storvsc1: 0:<Hyper-V IDE Storage Interface>0): on vmbus0
> storvsc scsi_status = 2
> (da0:blkvsc0:0:0:0): UNMAPPED
> (probe1:blkvsc1:0:1:0): storvsc scsi_status = 2
> hvheartbeat0: <Hyper-V Heartbeat> on vmbus0
> da0 at blkvsc0 bus 0 scbus2 target 0 lun 0
>
> As you can see, the drive da0 only appears after it has tried, and failed,
> to mount the root pool.
Does the same problem still happen with recent 11-STABLE?
From owner-freebsd-stable@freebsd.org Sat Apr 8 20:55:52 2017
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51686D356A6
for <freebsd-stable@mailman.ysv.freebsd.org>;
Sat, 8 Apr 2017 20:55:52 +0000 (UTC)
(envelope-from kob6558@gmail.com)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com
[IPv6:2607:f8b0:400e:c00::233])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 1A931E27
for <freebsd-stable@freebsd.org>; Sat, 8 Apr 2017 20:55:52 +0000 (UTC)
(envelope-from kob6558@gmail.com)
Received: by mail-pf0-x233.google.com with SMTP id s16so17770096pfs.0
for <freebsd-stable@freebsd.org>; Sat, 08 Apr 2017 13:55:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:from:date:message-id:subject:to;
bh=BVcG2i/WiJBgVPhFGaXYIM1c56VsA6iz80aF+EdKdB4=;
b=csW3Ixntq/J5sR47uwz7MRIXkgcKCxrkFqFiDtYdmjLDIO0FAG2jRfMuVXNZ1Q6jG+
ildCmOMVRmdezAj2CW8nJK6DVQzYylmYI1z6IDRcwAzVlTYT78LEtXTRcyjYEiSv94rD
ymGwfmdfcIUOrqV36XgKFsvl6ZK6vtOm+MPTo8fLA82oODzJg3+Ou+9ltf2e0sqJWl/m
+BQqwMelaYOjDM9priXK2PcaIf81wPX7rW+DE1HxHYrBE0GWzchTmn5l1GzBAsei9m2a
nR5r1r5bIJChTOjcXi87PctXkZbMtRevEG2asNyTZWkP5bWPO2ozlw6mZJU07nG7s3LL
u9ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:from:date:message-id:subject
:to; bh=BVcG2i/WiJBgVPhFGaXYIM1c56VsA6iz80aF+EdKdB4=;
b=ZY1YX39HarjbWSsQPMhmVLvKgoSPenMhXs27FPCq5uRqKoV67gBrE9Nu7lqCDW8peK
4xHdUuAWEbe3QOkvvSnZpHYo/tQoYzpxSZZrFxhjcdVo5m4okDTKJqpnYdqMKZYTxKFM
Po712eRkBYYtorri7agiedD1Yc8KulvPVDZaxevHperG2fsrGoL9sr+bvxtq3H8w3wN9
rGPPU77RCNSqRakiHPKIUSX+vwfhOlsSNARZq9qxjCF0+tEi3syJPA3zs6PFn7vSLLzt
D4+Mu6iDNr2b8y0rla0c6PcPaQgqsgIhQgyidDK2NJ6UgcXm0JrM8tom5RRyf+Oo8PT6
13gg==
X-Gm-Message-State: AFeK/H3Ogw7x8pLFm8BXUcGHiYpwxWQ45ks6J8azQuf66jmBldmfHCKdgKlNpuaay3ZIByOvaw9qcneThFY2Jw==
X-Received: by 10.84.128.75 with SMTP id 69mr57310871pla.111.1491684951504;
Sat, 08 Apr 2017 13:55:51 -0700 (PDT)
MIME-Version: 1.0
Sender: kob6558@gmail.com
Received: by 10.100.181.165 with HTTP; Sat, 8 Apr 2017 13:55:51 -0700 (PDT)
From: Kevin Oberman <rkoberman@gmail.com>
Date: Sat, 8 Apr 2017 13:55:51 -0700
X-Google-Sender-Auth: Qj1Ik37VdJ6UJQZB39j_w4Q3AQM
Message-ID: <CAN6yY1sJhs-BoTfW+cvFKCrWC9Nc+5M=3hyzjY94Xh_92B5K3Q@mail.gmail.com>
Subject: No USB?
To: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.23
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Apr 2017 20:55:52 -0000
Today, for the first time in a couple of weeks, I plugged in a USB drive to
my 11-STABLE system (r316552). No device was created and usbconfig only
sees EHCI hubs:
ugen1.1: <Intel EHCI root HUB> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
ugen0.1: <Intel EHCI root HUB> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
Seems like I should be seeing UHCI stuff, too. Even internal devices like
my webcam don't show up.
I'm running a GENERIC kernel with the following exceptions:
nooptions SCHED_ULE # ULE scheduler
options SCHED_4BSD # 4BSD scheduler
options IEEE80211_DEBUG
I tried updating my system and that made no difference. I booted up Windows
and it sees the USB drive just fine.
Any things I should try or look at to try to figure out what is happening?
I really want to get an image of my system before moving in three days.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683