From owner-freebsd-net@freebsd.org Sun Nov 19 12:08:42 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 29B78DF39E7
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 12:08:42 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id 957E7760CA
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 12:08:40 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 39869687; Sun, 19 Nov 2017 18:03:52 +0600
Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id vAJC8atp082794;
Sun, 19 Nov 2017 19:08:38 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id vAJC8WP3082793;
Sun, 19 Nov 2017 19:08:32 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Sun, 19 Nov 2017 19:08:32 +0700
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: "Muenz, Michael" <m.muenz@spam-fetish.org>, Jim Thompson <jim@netgate.com>
Cc: freebsd-net@freebsd.org
Subject: Re: OpenVPN vs IPSec
Message-ID: <20171119120832.GA82727@admin.sibptus.transneft.ru>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
Organization: AO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 12:08:42 -0000
Muenz, Michael wrote:
> >
> > Is there any reason to prefer IPSec over OpenVPN for building VPNs
> > between FreeBSD hosts and routers (and others compatible with OpenVPN
> > like pfSense, OpenWRT etc)?
> >
> > I can see only advantages of OpenVPN (a single UDP port, a single
> > userland daemon, no kernel rebuild required, a standard PKI, an easy
> > way to push settings and routes to remote clients, nice monitoring
> > feature etc). But maybe there is some huge advantage of IPSec I've
> > skipped?
> >
> Hi,
>
> partners/customers with Cisco IOS or ASA wont be able to partner up
> without IPSEC.
Sure, that's why I wrote "and others compatible with OpenVPN
like pfSense, OpenWRT etc" in the first paragraph.
Jim Thompson wrote:
>
> Performance is better with IPsec.
Because it's in the kernel? But many use (and recommend) StrongSwan
which is a userland implementation.
> It's a standard, too.
IPsec in itself maybe a standard, but IKE does not seem to be much of
a standard, I get the impression that there's much incompatibility
between vendors (Cisco, racoon etc).
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
AS43859
From owner-freebsd-net@freebsd.org Sun Nov 19 12:32:32 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 B3382DF41CE
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 12:32:32 +0000 (UTC)
(envelope-from m.muenz@spam-fetish.org)
Received: from mailout-02.maxonline.de (mailout-02.maxonline.de [81.24.66.23])
(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 7504176CB7
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 12:32:32 +0000 (UTC)
(envelope-from m.muenz@spam-fetish.org)
Received: from web03-01.max-it.de (web03-01.max-it.de [81.24.64.215])
by mailout-02.maxonline.de (Postfix) with ESMTPS id C9B3F72
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 13:32:29 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by web03-01.max-it.de (Postfix) with ESMTP id B6F5028B83A
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 13:32:29 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at web03-01.max-it.de
Received: from web03-01.max-it.de ([127.0.0.1])
by localhost (web03-01.max-it.de [127.0.0.1]) (amavisd-new, port 10026)
with ESMTP id rdI2qBjSy1-k for <freebsd-net@freebsd.org>;
Sun, 19 Nov 2017 13:32:29 +0100 (CET)
Received: from [81.24.66.132] (unknown [81.24.66.132])
(Authenticated sender: m.muenz@spam-fetish.org)
by web03-01.max-it.de (Postfix) with ESMTPA id 7858928A017
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 13:32:29 +0100 (CET)
Subject: Re: OpenVPN vs IPSec
To: freebsd-net@freebsd.org
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
From: "Muenz, Michael" <m.muenz@spam-fetish.org>
Message-ID: <d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
Date: Sun, 19 Nov 2017 13:32:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171119120832.GA82727@admin.sibptus.transneft.ru>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 12:32:32 -0000
Am 19.11.2017 um 13:08 schrieb Victor Sudakov:
> Muenz, Michael wrote:
>>> Is there any reason to prefer IPSec over OpenVPN for building VPNs
>>> between FreeBSD hosts and routers (and others compatible with OpenVPN
>>> like pfSense, OpenWRT etc)?
>>>
>>> I can see only advantages of OpenVPN (a single UDP port, a single
>>> userland daemon, no kernel rebuild required, a standard PKI, an easy
>>> way to push settings and routes to remote clients, nice monitoring
>>> feature etc). But maybe there is some huge advantage of IPSec I've
>>> skipped?
>>>
>> Hi,
>>
>> partners/customers with Cisco IOS or ASA wont be able to partner up
>> without IPSEC.
> Sure, that's why I wrote "and others compatible with OpenVPN
> like pfSense, OpenWRT etc" in the first paragraph.
>
Are you just searching for arguments against IPSec or real life cases?
IMHO when you have both ends under control OpenVPN is just fine.
If you are planning to interconnect with many customers/vendors IPSec
fits best.
In the last 15 years I was never asked about a Site2Site VPN with OpenVPN
from any customer or partner of the firewalls I managed.
Michael
From owner-freebsd-net@freebsd.org Sun Nov 19 12:48:52 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 3E102DF496D
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 12:48:52 +0000 (UTC)
(envelope-from hm@hellmuth-michaelis.de)
Received: from mail.agsec.de (mail.kts.org [IPv6:2a00:14b0:f000:1::222])
(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 01C6A773E7
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 12:48:51 +0000 (UTC)
(envelope-from hm@hellmuth-michaelis.de)
Received: from hh01.agsec.de (localhost [127.0.0.1])
by mail.agsec.de (Postfix) with ESMTP id BCACF61F82
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 13:48:47 +0100 (CET)
X-Virus-Scanned-AGSEC: MailMurkxDeScraCxler at agsec.de
Received: from mail.agsec.de ([194.55.156.222])
by hh01.agsec.de (hh01.agsec.de [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id OWejxTHNPTSe for <freebsd-net@freebsd.org>;
Sun, 19 Nov 2017 13:48:45 +0100 (CET)
Received: from ernie.int.kts.org (port-57103.pppoe.wtnet.de [46.59.223.199])
(using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail.agsec.de (Postfix) with ESMTPSA id 8E37661F81
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 13:48:45 +0100 (CET)
X-Virus-Scanned-KTS: Mail-UnWroks-U-Laksler at KTS.ORG
Received: from frazzle.int.kts.org (frazzle.int.kts.org [172.31.42.11])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ernie.int.kts.org (Postfix) with ESMTPS id BEB1D8C9B06
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 13:48:42 +0100 (CET)
From: Hellmuth Michaelis <hm@hellmuth-michaelis.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: OpenVPN vs IPSec
Date: Sun, 19 Nov 2017 13:48:41 +0100
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
To: freebsd-net@freebsd.org
In-Reply-To: <20171119120832.GA82727@admin.sibptus.transneft.ru>
Message-Id: <07003E8F-6EF8-4D4B-8C0C-319F81AD2A73@hellmuth-michaelis.de>
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 12:48:52 -0000
>
> Am 19.11.2017 um 13:08 schrieb Victor Sudakov <vas@mpeks.tomsk.su>:
>
>> It's a standard, too.
>
> IPsec in itself maybe a standard, but IKE does not seem to be much of
> a standard, I get the impression that there's much incompatibility
> between vendors (Cisco, racoon etc).
https://tools.ietf.org/html/rfc2409
https://tools.ietf.org/html/rfc7296
-hm
From owner-freebsd-net@freebsd.org Sun Nov 19 13:33:42 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 EDEC4DF5C1D
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 13:33:42 +0000 (UTC)
(envelope-from SRS0=ABSt=CR=quip.cz=000.fbsd@elsa.codelab.cz)
Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4])
(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 B36EE7895E
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 13:33:42 +0000 (UTC)
(envelope-from SRS0=ABSt=CR=quip.cz=000.fbsd@elsa.codelab.cz)
Received: from elsa.codelab.cz (localhost [127.0.0.1])
by elsa.codelab.cz (Postfix) with ESMTP id 5B8EF28459;
Sun, 19 Nov 2017 14:33:34 +0100 (CET)
Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz
[86.49.16.209])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by elsa.codelab.cz (Postfix) with ESMTPSA id 8998928455;
Sun, 19 Nov 2017 14:33:33 +0100 (CET)
Subject: Re: OpenVPN vs IPSec
To: "Muenz, Michael" <m.muenz@spam-fetish.org>, freebsd-net@freebsd.org
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
From: Miroslav Lachman <000.fbsd@quip.cz>
Message-ID: <5A11882D.1050700@quip.cz>
Date: Sun, 19 Nov 2017 14:33:33 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101
Firefox/42.0 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 13:33:43 -0000
Muenz, Michael wrote on 2017/11/19 13:32:
> Am 19.11.2017 um 13:08 schrieb Victor Sudakov:
>> Muenz, Michael wrote:
>>>> Is there any reason to prefer IPSec over OpenVPN for building VPNs
>>>> between FreeBSD hosts and routers (and others compatible with OpenVPN
>>>> like pfSense, OpenWRT etc)?
>>>>
>>>> I can see only advantages of OpenVPN (a single UDP port, a single
>>>> userland daemon, no kernel rebuild required, a standard PKI, an easy
>>>> way to push settings and routes to remote clients, nice monitoring
>>>> feature etc). But maybe there is some huge advantage of IPSec I've
>>>> skipped?
>>>>
>>> Hi,
>>>
>>> partners/customers with Cisco IOS or ASA wont be able to partner up
>>> without IPSEC.
>> Sure, that's why I wrote "and others compatible with OpenVPN
>> like pfSense, OpenWRT etc" in the first paragraph.
>>
>
> Are you just searching for arguments against IPSec or real life cases?
> IMHO when you have both ends under control OpenVPN is just fine.
> If you are planning to interconnect with many customers/vendors IPSec
> fits best.
>
> In the last 15 years I was never asked about a Site2Site VPN with OpenVPN
> from any customer or partner of the firewalls I managed.
I have opposite experience. One customer needs IPSec and setting and
debugging was a pain because we don't have access to the other end.
On the other hand customers with OpenVPN works in a minute. Just send or
receive openvpn.conf, set some variables in rc.conf and VPN is up and
running. So I prefer OpenVPN whenever possible.
Miroslav Lachman
From owner-freebsd-net@freebsd.org Sun Nov 19 13:38:10 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 1B801DF5D9B
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 13:38:10 +0000 (UTC)
(envelope-from emss.mail@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 A11BE78A9A
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 13:38:09 +0000 (UTC)
(envelope-from emss.mail@gmail.com)
Received: by mail-wm0-x22c.google.com with SMTP id x63so1306754wmf.4
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 05:38:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=sender:from:to:cc:subject:in-reply-to:references:user-agent:date
:message-id:mime-version:content-transfer-encoding;
bh=2zLmUFpV/s0eOWyaL6ad6Js5FeWweyJOm/jo9T7SMpM=;
b=iCJCBAt6BapUCPuZwkeC/7/NzObq4f4EGifmsHDi+egRhfDXxGrq6sMpxAh2mtGutz
yxJC2lQ7GFg5auU96ap4dFQCXSWfMjBS8Zb68StsO0DHoiPtuG10BUF14WhCLL9+mYO0
biBJYFr23xft65ZumDDSBiaybUNR4N4gwFTrA9LSnpEzfkQS2iH+BuYNaoAN3gf0LHqF
Q5Jg39s9FDxWJs+Lc3GbaqLepgVqPJ2E11Gw4zfYebwtwWGqrbLB8I1IhT/p7M/pFtg4
UpdP39b/9yYu7952OtROeviD2YJt3Xk0hCc6y1IwsXjS2FHHI2ZpffkxPlKnPQmXdio6
k+UA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references
:user-agent:date:message-id:mime-version:content-transfer-encoding;
bh=2zLmUFpV/s0eOWyaL6ad6Js5FeWweyJOm/jo9T7SMpM=;
b=PGonTyMK4O+k2lQe28HLrLSv95Db9kJCu6RBxf5E0NywwQh19RB+dRR4kLWvCuj/So
9OrJMUqBcyz1bqP6hm8WqRS2tt/RXWXFeezZZH4YH2LMGLyDLDrVdUF5DQ2GW14p+Y/i
npKEjckpDpJ+kDVTlIbSSwGoTGwKB1y5G4zT6hVDutgOMxs305v/Ej2S9Fpqi7CSp/AR
o8VEEcV1EqnRuTcZM0/gaGTE5aZWKfqgBYGdVFoAblTi/FteMYSgVAgER9EU4EjV0iV4
JTJ3XD8q34M9cA7GQ/xBT1fkKwxUmrYfYBCsSMlwK+/V4Y/q9Z5OP8oisnsUFUxzlxCo
O/vA==
X-Gm-Message-State: AJaThX4hTEeBEhiXr3iGv/zhPB2+QgM54xHyFY5+HexF4GHCnjMq0A3T
semID2zLbVAMRsaTGRSwc+ruGQ==
X-Google-Smtp-Source: AGs4zMYVThqqKfOGo0jI4gqjRCEQ859dAuFfOqbIQSg162OMcMdREuq4z6fa/hLYUrDoNd9bUCR8rg==
X-Received: by 10.28.30.151 with SMTP id e145mr7500989wme.8.1511098687597;
Sun, 19 Nov 2017 05:38:07 -0800 (PST)
Received: from srvbsdfenssv.interne.associated-bears.org
(LStLambert-658-1-110-48.w217-128.abo.wanadoo.fr. [217.128.200.48])
by smtp.gmail.com with ESMTPSA id 128sm13838122wmi.28.2017.11.19.05.38.06
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 19 Nov 2017 05:38:06 -0800 (PST)
Sender: Eric Masson <emss.mail@gmail.com>
Received: from newsrv.interne.associated-bears.org (localhost [127.0.0.1])
by srvbsdfenssv.interne.associated-bears.org (Postfix) with ESMTP id E90BF260D;
Sun, 19 Nov 2017 14:38:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at interne.associated-bears.org
Received: from srvbsdfenssv.interne.associated-bears.org ([127.0.0.1])
by newsrv.interne.associated-bears.org (newsrv.interne.associated-bears.org
[127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id tTLJ4h01CcU4; Sun, 19 Nov 2017 14:38:05 +0100 (CET)
Received: by srvbsdfenssv.interne.associated-bears.org (Postfix,
from userid 1001) id 284B62608; Sun, 19 Nov 2017 14:38:05 +0100 (CET)
From: Eric Masson <emss@free.fr>
To: Victor Sudakov <vas@mpeks.tomsk.su>
Cc: "Muenz\, Michael" <m.muenz@spam-fetish.org>, Jim Thompson <jim@netgate.com>,
freebsd-net@freebsd.org
Subject: Re: OpenVPN vs IPSec
In-Reply-To: <20171119120832.GA82727@admin.sibptus.transneft.ru> (Victor
Sudakov's message of "Sun, 19 Nov 2017 19:08:32 +0700")
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix)
X-Operating-System: FreeBSD 11.1-STABLE amd64
Date: Sun, 19 Nov 2017 14:38:05 +0100
Message-ID: <86o9nytmma.fsf@newsrv.interne.associated-bears.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 13:38:10 -0000
Victor Sudakov <vas@mpeks.tomsk.su> writes:
Hi,
> Because it's in the kernel? But many use (and recommend) StrongSwan
> which is a userland implementation.
Key exchange (ike) is managed by a userland process, but, in FreeBSD,
ipsec transform is kernel domain.
> IPsec in itself maybe a standard, but IKE does not seem to be much of
> a standard, I get the impression that there's much incompatibility
> between vendors (Cisco, racoon etc).
In early 2000's there were some glitches (mostly about non standard auth
extensions added by cisco for example), nowadays most of the issues are
PEBKAC class and nothing that can't be solved.
Éric Masson
--
Rm : (Lance ResEdit ou Resorcerer ...)
PC : C'est fini tout ça, ils écrivent leurs trucs en binaire chinois
recompilé en martien.
-+- PC in Guide du Macounet Pervers : ResEdit a marche pu -+-
From owner-freebsd-net@freebsd.org Sun Nov 19 14:15:41 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 66D94DF65B0
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 14:15:41 +0000 (UTC)
(envelope-from karl@denninger.net)
Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196])
by mx1.freebsd.org (Postfix) with ESMTP id 3E66779A53
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 14:15:40 +0000 (UTC)
(envelope-from karl@denninger.net)
Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197])
by colo1.denninger.net (Postfix) with ESMTP id 0D38827334
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 09:15:40 -0500 (EST)
Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by denninger.net (Postfix) with ESMTPSA id CD5A039F926
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 08:15:38 -0600 (CST)
Subject: Re: OpenVPN vs IPSec
To: freebsd-net@freebsd.org
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
<5A11882D.1050700@quip.cz>
From: Karl Denninger <karl@denninger.net>
Message-ID: <ae7baceb-0aa9-3c76-d3d0-8cad09b6dc42@denninger.net>
Date: Sun, 19 Nov 2017 08:15:36 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <5A11882D.1050700@quip.cz>
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha-512; boundary="------------ms020608070103030109080809"
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 14:15:41 -0000
This is a cryptographically signed message in MIME format.
--------------ms020608070103030109080809
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 11/19/2017 07:33, Miroslav Lachman wrote:
> Muenz, Michael wrote on 2017/11/19 13:32:
>> Am 19.11.2017 um 13:08 schrieb Victor Sudakov:
>>> Muenz, Michael wrote:
>>>>> Is there any reason to prefer IPSec over OpenVPN for building VPNs
>>>>> between FreeBSD hosts and routers (and others compatible with OpenV=
PN
>>>>> like pfSense, OpenWRT etc)?
>>>>>
>>>>> I can see only advantages of OpenVPN (a single UDP port, a single
>>>>> userland daemon, no kernel rebuild required, a standard PKI, an eas=
y
>>>>> way to push settings and routes to remote clients, nice monitoring
>>>>> feature etc). But maybe there is some huge advantage of IPSec I've
>>>>> skipped?
>>>>>
>>>> Hi,
>>>>
>>>> partners/customers with Cisco IOS or ASA wont be able to partner up
>>>> without IPSEC.
>>> Sure, that's why I wrote "and others compatible with OpenVPN
>>> like pfSense, OpenWRT etc" in the first paragraph.
>>>
>>
>> Are you just searching for arguments against IPSec or real life cases?=
>> IMHO when you have both ends under control OpenVPN is just fine.
>> If you are planning to interconnect with many customers/vendors IPSec
>> fits best.
>>
>> In the last 15 years I was never asked about a Site2Site VPN with
>> OpenVPN
>> from any customer or partner of the firewalls I managed.
>
> I have opposite experience. One customer needs IPSec and setting and
> debugging was a pain because we don't have access to the other end.
> On the other hand customers with OpenVPN works in a minute. Just send
> or receive openvpn.conf, set some variables in rc.conf and VPN is up
> and running. So I prefer OpenVPN whenever possible.
>
> Miroslav Lachman
I run both here and at some client sites, but not really by choice.
The reason is Windows.=C2=A0 Microslug hasn't updated their client since =
at
least Windows 7 release (we're talking about over a decade now) and
their IKEv2 implementation doesn't support IKE fragmentation.=C2=A0 In
today's world this usually means IPSEC/IKEv2 won't connect at all
because someone in the middle drops UDP fragments on purpose.
I'd like to ram that up someone's chute out at Microslug, never mind
that their default proposals are intentionally insecure (gee, I wonder
if someone in the government "asked nicely" for that?)=C2=A0 That's fixab=
le
with a bit of registry editing, but the lack of IKEv2 frag support is a
killer and has basically forced me to support OpenVPN when there are
windows clients around and you have no control (at all) over the
networks in the middle between the client and server.
--=20
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------ms020608070103030109080809
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL
MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf
BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4
MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD
dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1
ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI
KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD
0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY
vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn
uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24
SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E
6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH
YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL
h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd
zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE
FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q
EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ
TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5
c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY
MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN
gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9
oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj
tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K
uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv
HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK
17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/
Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA
6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY
UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO
62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp
ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD
QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx
MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw
ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A
16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg
96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg
y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs
YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg
6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX
SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM
cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN
5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l
CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg
CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v
b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF
oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG
SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O
BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC
GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE
BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh
IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ
zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN
AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR
dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu
2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X
lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK
FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q
IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA
1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL
shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ
qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE
QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM
TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM
QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTE5MTQxNTM2
WjBPBgkqhkiG9w0BCQQxQgRAIDw5Z9cDTXqS60N8W0m+wSAapIwbiSZwYevof1GLhmY3J9kq
5L+VGmq72rNoInS4iwy/86ysOROijhUcTDPm8zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl
AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3
DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM
TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM
QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg
gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz
dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0
ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF
AASCAgAAJvfWWsVImS4LSisDDYAvppMjW35yLdHVYqOpQyHNmzQFGpleVr1UJwODfd+dbzPc
CxUzTFXqK2zP9TWKXMVb7YF0BeI3ujbG+RY04dAycUqjIwAFzVyeR+TEaokJhU2wMSP69reN
RpK2avHRZgOnrSptm0om3dTzsbfkI/h6+IrBSbAeL600Uzx9pLxHDku83e3GMZe5YOkvn7O0
UlXdN8I0lgK4oNNvAyiCbr+QxJX3JnWsAhamPh/gefkgo8p0l3UacATqtcdkpnaZnjzFrAwI
+eVIjBF3L2Tm7xiA5wwQUPY97y7OiZp1tXTepCwe6J2DSjDF90CWLe2LGyWt5RFXgXNjQXrD
BtR2dQeyoUq6xKvRke666Niw4QdayAhhTcRzQXEmu/6eRR630FNrHrja+eNe04JJmgUlyDNa
Be9TCTqiuy7Hxkx+tlkwDj7W+uT9EsQEb5dDNGVfzgKMFOeaRLgs2tPR4Z6MqP51/KXx8LNZ
/qToINrTX78CLPFWVCDfcgYG7wMSymIJb3NuHQh7s0437YmKBB6Ody7R4fgv0lZEUgjciFWO
t2n0Y05E4z3my7GXQAO36qMa9cWgxnnRDb+fQZM34FrGcz4ysAIvDDoCPzrf5OR1H31Uo3Ez
dK28EUFgVMN1TvEEgKpUb8h6hW+onvny94HvT9ZlzAAAAAAAAA==
--------------ms020608070103030109080809--
From owner-freebsd-net@freebsd.org Sun Nov 19 14:20:25 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 80C14DF668F
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 14:20:25 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id EC98979B67
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 14:20:24 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 39869783; Sun, 19 Nov 2017 20:15:36 +0600
Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id vAJEKK4u083808;
Sun, 19 Nov 2017 21:20:22 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id vAJEKGN7083805;
Sun, 19 Nov 2017 21:20:16 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Sun, 19 Nov 2017 21:20:16 +0700
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: Eugene Grosbein <eugen@grosbein.net>
Cc: freebsd-net@freebsd.org
Subject: Re: OpenVPN vs IPSec
Message-ID: <20171119142015.GB82727@admin.sibptus.transneft.ru>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<5A1073E9.5050503@grosbein.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5A1073E9.5050503@grosbein.net>
Organization: AO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 14:20:25 -0000
Eugene Grosbein wrote:
>
> > Is there any reason to prefer IPSec over OpenVPN for building VPNs
> > between FreeBSD hosts and routers (and others compatible with OpenVPN
> > like pfSense, OpenWRT etc)?
> >
> > I can see only advantages of OpenVPN (a single UDP port, a single
> > userland daemon, no kernel rebuild required, a standard PKI, an easy
> > way to push settings and routes to remote clients, nice monitoring
> > feature etc). But maybe there is some huge advantage of IPSec I've
> > skipped?
>
> OpenVPN may be fine for very simple setups.
I have noticed that it works very fine for me in hub-and-spoke and
road warrior configurations.
>
> It is unusable for demanding cases like parallel site-to-site VPN tunnels
> with dynamic routing for same network prefix between such primary/backup tunnel;
> for other setups that need distinct full-blown network interface for each tunnel
IPSec per se does not use or require interfaces, unless you first
configure gif/gre tunnels and then encrypt traffic between tunnel
endpoints in IPSec transport mode. I wonder if the same approach will
not work with OpenVPN's tap/tun interfaces (I have not tried, so maybe
not).
> to process with SNMP agent/routing daemon/packet filters etc. because
> distinct OpenVPN instances cannot share routing correctly in beetween.
IPSec is oblivious to routing too. It just encrypts/decrypts packets
according to the SPD.
>
> In short, OpenVPN just is not designed to play nice and standard-compiliant way
> with other parts of the system and sometimes that's unacceptable.
> And sometimes that's irrelevant.
When I had to setup a VPN with a Macintosh user (road warrior), I
found out that an IPSec VPN would be beyond my mental abilities as I
could not wrap my head around the correct racoon and mpd5
authentication setup between FreeBSD and Mac. That's for all the talk
about being standard-compliant. OpenVPN saved me.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
AS43859
From owner-freebsd-net@freebsd.org Sun Nov 19 14:24:40 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 32B3DDF68E5
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 14:24:40 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id BDB5C79EA2
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 14:24:39 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be
forged))
by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vAJEOYAO082085
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 19 Nov 2017 15:24:35 +0100 (CET)
(envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: 000.fbsd@quip.cz
Received: from [10.58.0.4] ([10.58.0.4])
by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vAJEOUCu041588
(version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Sun, 19 Nov 2017 21:24:30 +0700 (+07)
(envelope-from eugen@grosbein.net)
Subject: Re: OpenVPN vs IPSec
To: Miroslav Lachman <000.fbsd@quip.cz>,
"Muenz, Michael" <m.muenz@spam-fetish.org>, freebsd-net@freebsd.org
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
<5A11882D.1050700@quip.cz>
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <5A11941A.6040400@grosbein.net>
Date: Sun, 19 Nov 2017 21:24:26 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <5A11882D.1050700@quip.cz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE
autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000] * 2.6 LOCAL_FROM From my domains
* 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 14:24:40 -0000
19.11.2017 20:33, Miroslav Lachman wrote:
> I have opposite experience. One customer needs IPSec and setting
> and debugging was a pain because we don't have access to the other end.
> On the other hand customers with OpenVPN works in a minute.
> Just send or receive openvpn.conf, set some variables in rc.conf and VPN is up and running.
You was pretty lucky, too. Because OpenVPN may be incompatible with its own previous version.
Debugging IPSec connection may be pain because one has not been taught
to understand IKE daemon logs, or does not know how IKE works at all,
but access to the other end's config is not needed generally
to see why it does not pass through.
From owner-freebsd-net@freebsd.org Sun Nov 19 14:31:02 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 C5BABDF69F1
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 14:31:02 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id 3AC6F7A01C
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 14:31:01 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 39869787; Sun, 19 Nov 2017 20:26:14 +0600
Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id vAJEUvkd083890;
Sun, 19 Nov 2017 21:30:59 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id vAJEUsmf083887;
Sun, 19 Nov 2017 21:30:54 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Sun, 19 Nov 2017 21:30:54 +0700
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: "Muenz, Michael" <m.muenz@spam-fetish.org>
Cc: freebsd-net@freebsd.org
Subject: Re: OpenVPN vs IPSec
Message-ID: <20171119143054.GC82727@admin.sibptus.transneft.ru>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
Organization: AO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 14:31:02 -0000
Muenz, Michael wrote:
> Am 19.11.2017 um 13:08 schrieb Victor Sudakov:
> > Muenz, Michael wrote:
> >>> Is there any reason to prefer IPSec over OpenVPN for building VPNs
> >>> between FreeBSD hosts and routers (and others compatible with OpenVPN
> >>> like pfSense, OpenWRT etc)?
> >>>
> >>> I can see only advantages of OpenVPN (a single UDP port, a single
> >>> userland daemon, no kernel rebuild required, a standard PKI, an easy
> >>> way to push settings and routes to remote clients, nice monitoring
> >>> feature etc). But maybe there is some huge advantage of IPSec I've
> >>> skipped?
> >>>
> >> Hi,
> >>
> >> partners/customers with Cisco IOS or ASA wont be able to partner up
> >> without IPSEC.
> > Sure, that's why I wrote "and others compatible with OpenVPN
> > like pfSense, OpenWRT etc" in the first paragraph.
> >
>
> Are you just searching for arguments against IPSec or real life cases?
Actually, I' searching for arguments *for* IPSec.
> IMHO when you have both ends under control OpenVPN is just fine.
> If you are planning to interconnect with many customers/vendors IPSec
> fits best.
I have a personal success story of establishing transport mode IPSec
between Windows and FreeBSD/racoon. But when other OSes are involved,
I have the impression that there is no pure IPSec, it's usually
IPSec+L2TP, and that's where the FreeBSD part becomes complicated
(interaction between ipsec, mpd5 and racoon is required).
>
> In the last 15 years I was never asked about a Site2Site VPN with OpenVPN
> from any customer or partner of the firewalls I managed.
OK, thank you, I have now one argument: IPSec is multi-vendor.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
AS43859
From owner-freebsd-net@freebsd.org Sun Nov 19 14:34:00 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 00AABDF6BC6
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 14:33:59 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 849D67A367
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 14:33:58 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be
forged))
by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vAJEXpRq082157
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 19 Nov 2017 15:33:51 +0100 (CET)
(envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: karl@denninger.net
Received: from [10.58.0.4] ([10.58.0.4])
by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vAJEXlSj043561
(version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Sun, 19 Nov 2017 21:33:48 +0700 (+07)
(envelope-from eugen@grosbein.net)
Subject: Re: OpenVPN vs IPSec
To: Karl Denninger <karl@denninger.net>, freebsd-net@freebsd.org
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
<5A11882D.1050700@quip.cz>
<ae7baceb-0aa9-3c76-d3d0-8cad09b6dc42@denninger.net>
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <5A119648.4080707@grosbein.net>
Date: Sun, 19 Nov 2017 21:33:44 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <ae7baceb-0aa9-3c76-d3d0-8cad09b6dc42@denninger.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE
autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000] * 2.6 LOCAL_FROM From my domains
* 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 14:34:00 -0000
19.11.2017 21:15, Karl Denninger wrote:
> The reason is Windows. Microslug hasn't updated their client since at
> least Windows 7 release (we're talking about over a decade now) and
> their IKEv2 implementation doesn't support IKE fragmentation. In
> today's world this usually means IPSEC/IKEv2 won't connect at all
> because someone in the middle drops UDP fragments on purpose.
>
> I'd like to ram that up someone's chute out at Microslug, never mind
> that their default proposals are intentionally insecure (gee, I wonder
> if someone in the government "asked nicely" for that?) That's fixable
> with a bit of registry editing, but the lack of IKEv2 frag support is a
> killer and has basically forced me to support OpenVPN when there are
> windows clients around and you have no control (at all) over the
> networks in the middle between the client and server.
I was able to successfully connect Windows 8.1 client to FreeBSD 11.1 server
in the L2TP/IPSEC mode using ipsec-tools (racoon) plus mpd5.
You can use something like mtu=576 for L2TP ngX interface to avoid UDP fragmentation.
Have you tried that?
From owner-freebsd-net@freebsd.org Sun Nov 19 14:37:22 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 D43AEDF6D34
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 14:37:22 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 6D2C17A637
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 14:37:22 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be
forged))
by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vAJEbHaR082198
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 19 Nov 2017 15:37:18 +0100 (CET)
(envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: vas@mpeks.tomsk.su
Received: from [10.58.0.4] ([10.58.0.4])
by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vAJEbEOU044116
(version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Sun, 19 Nov 2017 21:37:14 +0700 (+07)
(envelope-from eugen@grosbein.net)
Subject: Re: OpenVPN vs IPSec
To: Victor Sudakov <vas@mpeks.tomsk.su>,
"Muenz, Michael" <m.muenz@spam-fetish.org>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
<20171119143054.GC82727@admin.sibptus.transneft.ru>
Cc: freebsd-net@freebsd.org
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <5A119716.5020307@grosbein.net>
Date: Sun, 19 Nov 2017 21:37:10 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20171119143054.GC82727@admin.sibptus.transneft.ru>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE
autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000] * 2.6 LOCAL_FROM From my domains
* 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 14:37:22 -0000
19.11.2017 21:30, Victor Sudakov wrote:
> I have a personal success story of establishing transport mode IPSec
> between Windows and FreeBSD/racoon. But when other OSes are involved,
> I have the impression that there is no pure IPSec, it's usually
> IPSec+L2TP, and that's where the FreeBSD part becomes complicated
> (interaction between ipsec, mpd5 and racoon is required).
No interaction between mpd5 and racoon is required to make IPSec+L2TP working.
In fact, mpd5 starts its part only when IKE/IPSEC part is already completed
and runs its unencrypted L2TP protocol over existing IPSec tunnel without knowning it.
From owner-freebsd-net@freebsd.org Sun Nov 19 14:40:06 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 E6A80DF6E20
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 14:40:06 +0000 (UTC)
(envelope-from hm@hellmuth-michaelis.de)
Received: from mail.agsec.de (mail.kts.org [IPv6:2a00:14b0:f000:1::222])
(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 9FBDC7A72F
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 14:40:06 +0000 (UTC)
(envelope-from hm@hellmuth-michaelis.de)
Received: from hh01.agsec.de (localhost [127.0.0.1])
by mail.agsec.de (Postfix) with ESMTP id C2E7761F8B
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:39:55 +0100 (CET)
X-Virus-Scanned-AGSEC: MailMurkxDeScraCxler at agsec.de
Received: from mail.agsec.de ([194.55.156.222])
by hh01.agsec.de (hh01.agsec.de [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id rZHBFgJ0NBa5 for <freebsd-net@freebsd.org>;
Sun, 19 Nov 2017 15:39:53 +0100 (CET)
Received: from ernie.int.kts.org (unknown
[IPv6:2a02:2028:531:6101:20d:b9ff:fe1e:cf00])
(using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail.agsec.de (Postfix) with ESMTPSA id 8A13261F81
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:39:53 +0100 (CET)
X-Virus-Scanned-KTS: Mail-UnWroks-U-Laksler at KTS.ORG
Received: from frazzle.int.kts.org (frazzle.int.kts.org [172.31.42.11])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ernie.int.kts.org (Postfix) with ESMTPS id 209498C9B4A
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:39:50 +0100 (CET)
From: Hellmuth Michaelis <hm@hellmuth-michaelis.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: OpenVPN vs IPSec
Date: Sun, 19 Nov 2017 15:39:49 +0100
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<5A1073E9.5050503@grosbein.net>
<20171119142015.GB82727@admin.sibptus.transneft.ru>
To: freebsd-net@freebsd.org
In-Reply-To: <20171119142015.GB82727@admin.sibptus.transneft.ru>
Message-Id: <3A168E23-5CB5-4D99-925A-E9688A24E502@hellmuth-michaelis.de>
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 14:40:07 -0000
> Am 19.11.2017 um 15:20 schrieb Victor Sudakov <vas@mpeks.tomsk.su>:
>=20
> When I had to setup a VPN with a Macintosh user (road warrior), I
> found out that an IPSec VPN would be beyond my mental abilities as I
> could not wrap my head around the correct racoon and mpd5
> authentication setup between FreeBSD and Mac. That's for all the talk
> about being standard-compliant. OpenVPN saved me.
Try this one on the Mac: http://www.lobotomo.com/products/IPSecuritas=20
it=E2=80=99s free, it works and it=E2=80=99s actively maintained.
-hm=
From owner-freebsd-net@freebsd.org Sun Nov 19 14:44:57 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 D8375D93435
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 14:44:57 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id 4EB227ACB7
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 14:44:56 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 39869811; Sun, 19 Nov 2017 20:40:09 +0600
Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id vAJEirZP083984;
Sun, 19 Nov 2017 21:44:55 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id vAJEio2q083983;
Sun, 19 Nov 2017 21:44:50 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Sun, 19 Nov 2017 21:44:50 +0700
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: Hellmuth Michaelis <hm@hellmuth-michaelis.de>
Cc: freebsd-net@freebsd.org
Subject: Re: OpenVPN vs IPSec
Message-ID: <20171119144450.GD82727@admin.sibptus.transneft.ru>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<07003E8F-6EF8-4D4B-8C0C-319F81AD2A73@hellmuth-michaelis.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <07003E8F-6EF8-4D4B-8C0C-319F81AD2A73@hellmuth-michaelis.de>
Organization: AO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 14:44:57 -0000
Hellmuth Michaelis wrote:
> >
> > Am 19.11.2017 um 13:08 schrieb Victor Sudakov <vas@mpeks.tomsk.su>:
> >
> >> It's a standard, too.
> >
> > IPsec in itself maybe a standard, but IKE does not seem to be much of
> > a standard, I get the impression that there's much incompatibility
> > between vendors (Cisco, racoon etc).
>
> https://tools.ietf.org/html/rfc2409
> https://tools.ietf.org/html/rfc7296
I don't doubt there being RFCs, but there are also some incompatible
vendor extensions. E.g. racoon announces Kerberos authentication
support (which is presently broken) etc.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
AS43859
From owner-freebsd-net@freebsd.org Sun Nov 19 14:51:24 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 A3E73D9374C
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 14:51:24 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id 1856A7AFC3
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 14:51:23 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 39869818; Sun, 19 Nov 2017 20:46:36 +0600
Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id vAJEpJM2084057;
Sun, 19 Nov 2017 21:51:19 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id vAJEpG2l084054;
Sun, 19 Nov 2017 21:51:16 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Sun, 19 Nov 2017 21:51:16 +0700
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: Eric Masson <emss@free.fr>
Cc: freebsd-net@freebsd.org, Jim Thompson <jim@netgate.com>,
"Muenz, Michael" <m.muenz@spam-fetish.org>
Subject: Re: OpenVPN vs IPSec
Message-ID: <20171119145116.GE82727@admin.sibptus.transneft.ru>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<86o9nytmma.fsf@newsrv.interne.associated-bears.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86o9nytmma.fsf@newsrv.interne.associated-bears.org>
Organization: AO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 14:51:24 -0000
Eric Masson wrote:
>
> > Because it's in the kernel? But many use (and recommend) StrongSwan
> > which is a userland implementation.
>
> Key exchange (ike) is managed by a userland process, but, in FreeBSD,
> ipsec transform is kernel domain.
That is, if you use kernel IPsec. But StrongSwan is completely
userland AFAIK.
And the kernel IPsec implementation has had problems with NAT
traveral. Does it stil have problems and requre extra patches for NAT
traveral?
So, if I go for IPsec, I would probably use StrongSwan.
>
> > IPsec in itself maybe a standard, but IKE does not seem to be much of
> > a standard, I get the impression that there's much incompatibility
> > between vendors (Cisco, racoon etc).
>
> In early 2000's there were some glitches (mostly about non standard auth
> extensions added by cisco for example), nowadays most of the issues are
> PEBKAC class and nothing that can't be solved.
Maybe I'm indeed the faulty layer between keyboard and chair, but
FreeBSD+IPsec+L2TP is still beyond me. Pure IPsec is fine more or
less with me.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
AS43859
From owner-freebsd-net@freebsd.org Sun Nov 19 14:57:20 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 D7120D938C6
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 14:57:20 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id 4A3B77B2D3
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 14:57:19 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 39869826; Sun, 19 Nov 2017 20:52:32 +0600
Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id vAJEvFYU084108;
Sun, 19 Nov 2017 21:57:17 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id vAJEvAa3084107;
Sun, 19 Nov 2017 21:57:10 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Sun, 19 Nov 2017 21:57:10 +0700
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: Eugene Grosbein <eugen@grosbein.net>
Cc: Karl Denninger <karl@denninger.net>, freebsd-net@freebsd.org
Subject: Re: OpenVPN vs IPSec
Message-ID: <20171119145710.GF82727@admin.sibptus.transneft.ru>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
<5A11882D.1050700@quip.cz>
<ae7baceb-0aa9-3c76-d3d0-8cad09b6dc42@denninger.net>
<5A119648.4080707@grosbein.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5A119648.4080707@grosbein.net>
Organization: AO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 14:57:20 -0000
Eugene Grosbein wrote:
> I was able to successfully connect Windows 8.1 client to FreeBSD 11.1 server
> in the L2TP/IPSEC mode using ipsec-tools (racoon) plus mpd5.
Could you please share the setup here or in LiveJournal? I'm most
interested in the L2TP/mpd5 part.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
AS43859
From owner-freebsd-net@freebsd.org Sun Nov 19 14:57:35 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 5B25BD9390D
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 14:57:35 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id CECBC7B36F
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 14:57:34 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be
forged))
by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vAJEvU75082341
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 19 Nov 2017 15:57:30 +0100 (CET)
(envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: vas@mpeks.tomsk.su
Received: from [10.58.0.4] ([10.58.0.4])
by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vAJEvQxt047286
(version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Sun, 19 Nov 2017 21:57:26 +0700 (+07)
(envelope-from eugen@grosbein.net)
Subject: Re: OpenVPN vs IPSec
To: Victor Sudakov <vas@mpeks.tomsk.su>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<5A1073E9.5050503@grosbein.net>
<20171119142015.GB82727@admin.sibptus.transneft.ru>
Cc: freebsd-net@freebsd.org
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <5A119BD2.7070703@grosbein.net>
Date: Sun, 19 Nov 2017 21:57:22 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20171119142015.GB82727@admin.sibptus.transneft.ru>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE
autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000] * 2.6 LOCAL_FROM From my domains
* 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 14:57:35 -0000
19.11.2017 21:20, Victor Sudakov wrote:
> IPSec per se does not use or require interfaces, unless you first
> configure gif/gre tunnels and then encrypt traffic between tunnel
> endpoints in IPSec transport mode.
There is also if_ipsec(4), too.
> I wonder if the same approach will not work with OpenVPN's tap/tun interfaces
> (I have not tried, so maybe not).
I tried and it won't work within single OpenVPN instance and that's unusually hard
and meaningless with multiple OpenVPN instances just because OpenVPN was not designed
to interact with other system parts.
>> to process with SNMP agent/routing daemon/packet filters etc. because
>> distinct OpenVPN instances cannot share routing correctly in beetween.
>
> IPSec is oblivious to routing too. It just encrypts/decrypts packets
> according to the SPD.
Yes, IPSec does not try to be the single combine for encryption, and to interface manipulation,
and to routing propagation. But it combines with additional subsystems just fine.
>> In short, OpenVPN just is not designed to play nice and standard-compiliant way
>> with other parts of the system and sometimes that's unacceptable.
>> And sometimes that's irrelevant.
>
> When I had to setup a VPN with a Macintosh user (road warrior), I
> found out that an IPSec VPN would be beyond my mental abilities as I
> could not wrap my head around the correct racoon and mpd5
> authentication setup between FreeBSD and Mac. That's for all the talk
> about being standard-compliant. OpenVPN saved me.
Hmm, I got no problems to make such setup. I use single IPSec shared secret
for whole group of roaming users to encrypt their initial fraffic
and distinct login/password pairs in the mpd.secret file for CHAP-based
authentication within L2TP tunnels before assignment of internal IP addresses.
You can find my letter to RU.UNIX.BSD of Juny 20 with subject "Re: STABLE+IPSEC"
describing this setup.
From owner-freebsd-net@freebsd.org Sun Nov 19 14:59:48 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 2B16FD93A0B
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 14:59:48 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id 94B587B48B
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 14:59:46 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 39869832; Sun, 19 Nov 2017 20:54:59 +0600
Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id vAJExhld084119;
Sun, 19 Nov 2017 21:59:45 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id vAJExeTQ084118;
Sun, 19 Nov 2017 21:59:40 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Sun, 19 Nov 2017 21:59:39 +0700
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: Eugene Grosbein <eugen@grosbein.net>
Cc: "Muenz, Michael" <m.muenz@spam-fetish.org>, freebsd-net@freebsd.org
Subject: Re: OpenVPN vs IPSec
Message-ID: <20171119145939.GG82727@admin.sibptus.transneft.ru>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
<20171119143054.GC82727@admin.sibptus.transneft.ru>
<5A119716.5020307@grosbein.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5A119716.5020307@grosbein.net>
Organization: AO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 14:59:48 -0000
Eugene Grosbein wrote:
>
> > I have a personal success story of establishing transport mode IPSec
> > between Windows and FreeBSD/racoon. But when other OSes are involved,
> > I have the impression that there is no pure IPSec, it's usually
> > IPSec+L2TP, and that's where the FreeBSD part becomes complicated
> > (interaction between ipsec, mpd5 and racoon is required).
>
> No interaction between mpd5 and racoon is required to make IPSec+L2TP working.
> In fact, mpd5 starts its part only when IKE/IPSEC part is already completed
> and runs its unencrypted L2TP protocol over existing IPSec tunnel without knowning it.
That's great but then you need 1) authentication in IKE/racoon and 2) authentication in mpd5?
How do you handle that (and how do you configure the Windows client for it)?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
AS43859
From owner-freebsd-net@freebsd.org Sun Nov 19 15:01:35 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 8E171D93C58
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 15:01:35 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id 056917B757
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:01:33 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 39869834; Sun, 19 Nov 2017 20:56:46 +0600
Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id vAJF1WDt084195;
Sun, 19 Nov 2017 22:01:32 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id vAJF1VMa084194;
Sun, 19 Nov 2017 22:01:31 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Sun, 19 Nov 2017 22:01:31 +0700
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: Hellmuth Michaelis <hm@hellmuth-michaelis.de>
Cc: freebsd-net@freebsd.org
Subject: Re: OpenVPN vs IPSec
Message-ID: <20171119150131.GH82727@admin.sibptus.transneft.ru>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<5A1073E9.5050503@grosbein.net>
<20171119142015.GB82727@admin.sibptus.transneft.ru>
<3A168E23-5CB5-4D99-925A-E9688A24E502@hellmuth-michaelis.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3A168E23-5CB5-4D99-925A-E9688A24E502@hellmuth-michaelis.de>
Organization: AO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 15:01:35 -0000
Hellmuth Michaelis wrote:
>
>
> >
> > When I had to setup a VPN with a Macintosh user (road warrior), I
> > found out that an IPSec VPN would be beyond my mental abilities as I
> > could not wrap my head around the correct racoon and mpd5
> > authentication setup between FreeBSD and Mac. That's for all the talk
> > about being standard-compliant. OpenVPN saved me.
>
> Try this one on the Mac: http://www.lobotomo.com/products/IPSecuritas
> it???s free, it works and it???s actively maintained.
Interesting. Why not the builtin IPSec implementation?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
AS43859
From owner-freebsd-net@freebsd.org Sun Nov 19 15:01:58 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 799C7D93CC7
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 15:01:58 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 122B77B843
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:01:57 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be
forged))
by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vAJF1p1d082408
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 19 Nov 2017 16:01:52 +0100 (CET)
(envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: vas@mpeks.tomsk.su
Received: from [10.58.0.4] ([10.58.0.4])
by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vAJF1lg1047918
(version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Sun, 19 Nov 2017 22:01:47 +0700 (+07)
(envelope-from eugen@grosbein.net)
Subject: Re: OpenVPN vs IPSec
To: Victor Sudakov <vas@mpeks.tomsk.su>,
Hellmuth Michaelis <hm@hellmuth-michaelis.de>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<07003E8F-6EF8-4D4B-8C0C-319F81AD2A73@hellmuth-michaelis.de>
<20171119144450.GD82727@admin.sibptus.transneft.ru>
Cc: freebsd-net@freebsd.org
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <5A119CD7.2020905@grosbein.net>
Date: Sun, 19 Nov 2017 22:01:43 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20171119144450.GD82727@admin.sibptus.transneft.ru>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE
autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000] * 2.6 LOCAL_FROM From my domains
* 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 15:01:58 -0000
19.11.2017 21:44, Victor Sudakov wrote:
>> https://tools.ietf.org/html/rfc2409
>> https://tools.ietf.org/html/rfc7296
>
> I don't doubt there being RFCs, but there are also some incompatible
> vendor extensions. E.g. racoon announces Kerberos authentication
> support (which is presently broken) etc.
racoon does not announce Kerberos authentication support in my case.
May be due to the fact I build security/ipsec-tools port with disabled option
for GSSAPI Security API support.
From owner-freebsd-net@freebsd.org Sun Nov 19 15:06:20 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 1A0BED93E26
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 15:06:20 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id A526E7B9EA
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:06:19 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be
forged))
by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vAJF6EC3082443
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 19 Nov 2017 16:06:14 +0100 (CET)
(envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: vas@mpeks.tomsk.su
Received: from [10.58.0.4] ([10.58.0.4])
by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vAJF6BEv048592
(version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Sun, 19 Nov 2017 22:06:11 +0700 (+07)
(envelope-from eugen@grosbein.net)
Subject: Re: OpenVPN vs IPSec
To: Victor Sudakov <vas@mpeks.tomsk.su>, Eric Masson <emss@free.fr>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<86o9nytmma.fsf@newsrv.interne.associated-bears.org>
<20171119145116.GE82727@admin.sibptus.transneft.ru>
Cc: freebsd-net@freebsd.org, Jim Thompson <jim@netgate.com>,
"Muenz, Michael" <m.muenz@spam-fetish.org>
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <5A119DDF.4090809@grosbein.net>
Date: Sun, 19 Nov 2017 22:06:07 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20171119145116.GE82727@admin.sibptus.transneft.ru>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE
autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000] * 2.6 LOCAL_FROM From my domains
* 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 15:06:20 -0000
19.11.2017 21:51, Victor Sudakov wrote:
> And the kernel IPsec implementation has had problems with NAT
> traveral. Does it stil have problems and requre extra patches for NAT
> traveral?
No, it has not after IPSec code overhaul in times of 11.0-STABLE.
NAT traversal works out-of-box these days not requiring extra patches.
It needs "nat_traversal on" in the racoon.conf, though.
From owner-freebsd-net@freebsd.org Sun Nov 19 15:14:25 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 67CB0D941EF
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 15:14:25 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id 981F87BE79
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:14:23 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 39869850; Sun, 19 Nov 2017 21:09:36 +0600
Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id vAJFEKXZ084286;
Sun, 19 Nov 2017 22:14:22 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id vAJFEGVX084283;
Sun, 19 Nov 2017 22:14:16 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Sun, 19 Nov 2017 22:14:16 +0700
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: Eugene Grosbein <eugen@grosbein.net>
Cc: freebsd-net@freebsd.org
Subject: Re: OpenVPN vs IPSec
Message-ID: <20171119151416.GI82727@admin.sibptus.transneft.ru>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<5A1073E9.5050503@grosbein.net>
<20171119142015.GB82727@admin.sibptus.transneft.ru>
<5A119BD2.7070703@grosbein.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5A119BD2.7070703@grosbein.net>
Organization: AO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 15:14:25 -0000
Eugene Grosbein wrote:
>
> > IPSec per se does not use or require interfaces, unless you first
> > configure gif/gre tunnels and then encrypt traffic between tunnel
> > endpoints in IPSec transport mode.
>
> There is also if_ipsec(4), too.
Oh, I forgot about this recent addition. It was a really good design
idea, thank you for reminding me.
I now even remember discussing it with Andrey in his LJ and suggesting
a small cosmetic feature which he implemented by my request.
Have you tried in in production? What does it do to the MTU?
>
> > I wonder if the same approach will not work with OpenVPN's tap/tun interfaces
> > (I have not tried, so maybe not).
>
> I tried and it won't work within single OpenVPN instance and that's unusually hard
> and meaningless with multiple OpenVPN instances just because OpenVPN was not designed
> to interact with other system parts.
Thanks, I will now know and avoid such configurations.
>
> >> to process with SNMP agent/routing daemon/packet filters etc. because
> >> distinct OpenVPN instances cannot share routing correctly in beetween.
> >
> > IPSec is oblivious to routing too. It just encrypts/decrypts packets
> > according to the SPD.
>
> Yes, IPSec does not try to be the single combine for encryption, and to interface manipulation,
> and to routing propagation. But it combines with additional subsystems just fine.
>
> >> In short, OpenVPN just is not designed to play nice and standard-compiliant way
> >> with other parts of the system and sometimes that's unacceptable.
> >> And sometimes that's irrelevant.
> >
> > When I had to setup a VPN with a Macintosh user (road warrior), I
> > found out that an IPSec VPN would be beyond my mental abilities as I
> > could not wrap my head around the correct racoon and mpd5
> > authentication setup between FreeBSD and Mac. That's for all the talk
> > about being standard-compliant. OpenVPN saved me.
>
> Hmm, I got no problems to make such setup. I use single IPSec shared secret
> for whole group of roaming users to encrypt their initial fraffic
> and distinct login/password pairs in the mpd.secret file for CHAP-based
> authentication within L2TP tunnels before assignment of internal IP addresses.
And what does it look like (both shared secret and login/password)
from the point of view of a Windows/Mac client?
>
> You can find my letter to RU.UNIX.BSD of Juny 20 with subject "Re: STABLE+IPSEC"
> describing this setup.
May I ask you kindly to publish a howto in your LJ?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
AS43859
From owner-freebsd-net@freebsd.org Sun Nov 19 15:15:51 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 EB040D942BB
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 15:15:51 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 822A77BF40
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:15:50 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be
forged))
by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vAJFFiVY082515
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 19 Nov 2017 16:15:45 +0100 (CET)
(envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: vas@mpeks.tomsk.su
Received: from [10.58.0.4] ([10.58.0.4])
by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vAJFFfot050467
(version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Sun, 19 Nov 2017 22:15:41 +0700 (+07)
(envelope-from eugen@grosbein.net)
Subject: Re: OpenVPN vs IPSec
To: Victor Sudakov <vas@mpeks.tomsk.su>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
<5A11882D.1050700@quip.cz>
<ae7baceb-0aa9-3c76-d3d0-8cad09b6dc42@denninger.net>
<5A119648.4080707@grosbein.net>
<20171119145710.GF82727@admin.sibptus.transneft.ru>
Cc: Karl Denninger <karl@denninger.net>, freebsd-net@freebsd.org
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <5A11A019.9090302@grosbein.net>
Date: Sun, 19 Nov 2017 22:15:37 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20171119145710.GF82727@admin.sibptus.transneft.ru>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE
autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000] * 2.6 LOCAL_FROM From my domains
* 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 15:15:52 -0000
19.11.2017 21:57, Victor Sudakov wrote:
>> I was able to successfully connect Windows 8.1 client to FreeBSD 11.1 server
>> in the L2TP/IPSEC mode using ipsec-tools (racoon) plus mpd5.
>
> Could you please share the setup here or in LiveJournal? I'm most
> interested in the L2TP/mpd5 part.
There is nothing special to share. Just take a look to its mpd.conf.sample.
You can use pptp_server part replacing pptp-specific commands (set pptp)
with l2tp-specific and, of course, change link type "pptp" with "l2tp".
You can even debug mpd5/l2tp part without engaging IPSec at all
by using unencrypted "L2TP without IPSEC" clients to begin with.
From owner-freebsd-net@freebsd.org Sun Nov 19 15:16:25 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 CEA67D94346
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 15:16:25 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id 451B17BFFF
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:16:25 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 39869854; Sun, 19 Nov 2017 21:11:38 +0600
Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id vAJFGLD7084326;
Sun, 19 Nov 2017 22:16:23 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id vAJFGIbI084323;
Sun, 19 Nov 2017 22:16:18 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Sun, 19 Nov 2017 22:16:18 +0700
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: Eugene Grosbein <eugen@grosbein.net>
Cc: Hellmuth Michaelis <hm@hellmuth-michaelis.de>, freebsd-net@freebsd.org
Subject: Re: OpenVPN vs IPSec
Message-ID: <20171119151618.GJ82727@admin.sibptus.transneft.ru>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<07003E8F-6EF8-4D4B-8C0C-319F81AD2A73@hellmuth-michaelis.de>
<20171119144450.GD82727@admin.sibptus.transneft.ru>
<5A119CD7.2020905@grosbein.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5A119CD7.2020905@grosbein.net>
Organization: AO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 15:16:25 -0000
Eugene Grosbein wrote:
>
> >> https://tools.ietf.org/html/rfc2409
> >> https://tools.ietf.org/html/rfc7296
> >
> > I don't doubt there being RFCs, but there are also some incompatible
> > vendor extensions. E.g. racoon announces Kerberos authentication
> > support (which is presently broken) etc.
>
> racoon does not announce Kerberos authentication support in my case.
> May be due to the fact I build security/ipsec-tools port with disabled option
> for GSSAPI Security API support.
So do I now, but when I tried to enable the option (because I grew
tired of shared secrets), it turned out broken.
Anyway, it is just an example of a non-standard extension.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
AS43859
From owner-freebsd-net@freebsd.org Sun Nov 19 15:19:17 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 422A7D9445C
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 15:19:17 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id CE6007C0FB
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:19:16 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be
forged))
by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vAJFJCBM082538
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 19 Nov 2017 16:19:12 +0100 (CET)
(envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: vas@mpeks.tomsk.su
Received: from [10.58.0.4] ([10.58.0.4])
by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vAJFJ8ct051092
(version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Sun, 19 Nov 2017 22:19:09 +0700 (+07)
(envelope-from eugen@grosbein.net)
Subject: Re: OpenVPN vs IPSec
To: Victor Sudakov <vas@mpeks.tomsk.su>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
<20171119143054.GC82727@admin.sibptus.transneft.ru>
<5A119716.5020307@grosbein.net>
<20171119145939.GG82727@admin.sibptus.transneft.ru>
Cc: freebsd-net@freebsd.org, "Muenz, Michael" <m.muenz@spam-fetish.org>
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <5A11A0E9.7030503@grosbein.net>
Date: Sun, 19 Nov 2017 22:19:05 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20171119145939.GG82727@admin.sibptus.transneft.ru>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE
autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000] * 2.6 LOCAL_FROM From my domains
* 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 15:19:17 -0000
19.11.2017 21:59, Victor Sudakov wrote:
>> No interaction between mpd5 and racoon is required to make IPSec+L2TP working.
>> In fact, mpd5 starts its part only when IKE/IPSEC part is already completed
>> and runs its unencrypted L2TP protocol over existing IPSec tunnel without knowning it.
>
> That's great but then you need 1) authentication in IKE/racoon
I use IPSec shared secret.
> and 2) authentication in mpd5?
Standard CHAP authentication with login/password.
> How do you handle that (and how do you configure the Windows client for it)?
No special configuration of Windows client required. Just "old good" VPN-connection
with L2TP/IPSec type, shared secret and login/password pair.
From owner-freebsd-net@freebsd.org Sun Nov 19 15:20:01 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 93C14D94502
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 15:20:01 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5])
by mx1.freebsd.org (Postfix) with ESMTP id 0372B7C1BC
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:20:00 +0000 (UTC)
(envelope-from vas@mpeks.tomsk.su)
X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru
Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru)
by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16)
with ESMTPS id 39869861; Sun, 19 Nov 2017 21:15:13 +0600
Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1])
by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id vAJFJwoQ084338;
Sun, 19 Nov 2017 22:19:58 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
Received: (from sudakov@localhost)
by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id vAJFJuRI084337;
Sun, 19 Nov 2017 22:19:56 +0700 (+07)
(envelope-from vas@mpeks.tomsk.su)
X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to
vas@mpeks.tomsk.su using -f
Date: Sun, 19 Nov 2017 22:19:56 +0700
From: Victor Sudakov <vas@mpeks.tomsk.su>
To: Eugene Grosbein <eugen@grosbein.net>
Cc: Eric Masson <emss@free.fr>, freebsd-net@freebsd.org,
Jim Thompson <jim@netgate.com>, "Muenz, Michael" <m.muenz@spam-fetish.org>
Subject: Re: OpenVPN vs IPSec
Message-ID: <20171119151956.GK82727@admin.sibptus.transneft.ru>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<86o9nytmma.fsf@newsrv.interne.associated-bears.org>
<20171119145116.GE82727@admin.sibptus.transneft.ru>
<5A119DDF.4090809@grosbein.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5A119DDF.4090809@grosbein.net>
Organization: AO "Svyaztransneft", SibPTUS
X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 15:20:01 -0000
Eugene Grosbein wrote:
>
> > And the kernel IPsec implementation has had problems with NAT
> > traveral. Does it stil have problems and requre extra patches for NAT
> > traveral?
>
> No, it has not after IPSec code overhaul in times of 11.0-STABLE.
> NAT traversal works out-of-box these days not requiring extra patches.
Glad to hear that. Also, in 11.x no kernel recompilation is needed to
enable IPSec.
So maybe when I eventually migrate all my hosts to the 11th branch, it
will be time for me to give IPSec a second chance, with all that nice
if_ipsec stuff.
>
> It needs "nat_traversal on" in the racoon.conf, though.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
AS43859
From owner-freebsd-net@freebsd.org Sun Nov 19 15:25:49 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 E6CA2D947D3
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 15:25:49 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 665107C523
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:25:48 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be
forged))
by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vAJFPhtL082610
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 19 Nov 2017 16:25:44 +0100 (CET)
(envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: vas@mpeks.tomsk.su
Received: from [10.58.0.4] ([10.58.0.4])
by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vAJFPdim052256
(version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Sun, 19 Nov 2017 22:25:39 +0700 (+07)
(envelope-from eugen@grosbein.net)
Subject: Re: OpenVPN vs IPSec
To: Victor Sudakov <vas@mpeks.tomsk.su>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<5A1073E9.5050503@grosbein.net>
<20171119142015.GB82727@admin.sibptus.transneft.ru>
<5A119BD2.7070703@grosbein.net>
<20171119151416.GI82727@admin.sibptus.transneft.ru>
Cc: freebsd-net@freebsd.org
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <5A11A270.60006@grosbein.net>
Date: Sun, 19 Nov 2017 22:25:36 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20171119151416.GI82727@admin.sibptus.transneft.ru>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE
autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000] * 2.6 LOCAL_FROM From my domains
* 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 15:25:50 -0000
19.11.2017 22:14, Victor Sudakov wrote:
>> There is also if_ipsec(4), too.
>
> Oh, I forgot about this recent addition. It was a really good design
> idea, thank you for reminding me.
>
> I now even remember discussing it with Andrey in his LJ and suggesting
> a small cosmetic feature which he implemented by my request.
>
> Have you tried in in production? What does it do to the MTU?
I've not tried if_ipsec yet. I'm still fine with older ways to "cook" IPSEC :-)
> And what does it look like (both shared secret and login/password)
> from the point of view of a Windows/Mac client?
They all have corresponding fields in their GUI to enter these parameters
and then it just works.
>> You can find my letter to RU.UNIX.BSD of Juny 20 with subject "Re: STABLE+IPSEC"
>> describing this setup.
>
> May I ask you kindly to publish a howto in your LJ?
I have some problems with LJ after they moved their servers, so do not expect that soon.
However, there is almost nothing special to share. Just use software in most simple way :-)
It finally works these days just how it supposed to do from the beginning.
From owner-freebsd-net@freebsd.org Sun Nov 19 15:27:24 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 647AED94925
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 15:27:24 +0000 (UTC)
(envelope-from hm@hellmuth-michaelis.de)
Received: from mail.agsec.de (mail.agsec.de [194.55.156.222])
(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 255187C638
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:27:23 +0000 (UTC)
(envelope-from hm@hellmuth-michaelis.de)
Received: from hh01.agsec.de (localhost [127.0.0.1])
by mail.agsec.de (Postfix) with ESMTP id A2C1061F8B
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 16:27:20 +0100 (CET)
X-Virus-Scanned-AGSEC: MailMurkxDeScraCxler at agsec.de
Received: from mail.agsec.de ([194.55.156.222])
by hh01.agsec.de (hh01.agsec.de [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Vt3mKrKrkung for <freebsd-net@freebsd.org>;
Sun, 19 Nov 2017 16:27:15 +0100 (CET)
Received: from ernie.int.kts.org (port-57103.pppoe.wtnet.de [46.59.223.199])
(using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail.agsec.de (Postfix) with ESMTPSA id 9B7F561F81
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 16:27:15 +0100 (CET)
X-Virus-Scanned-KTS: Mail-UnWroks-U-Laksler at KTS.ORG
Received: from frazzle.int.kts.org (frazzle.int.kts.org [172.31.42.11])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ernie.int.kts.org (Postfix) with ESMTPS id 8BE9F8C9B06
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 16:27:12 +0100 (CET)
From: Hellmuth Michaelis <hm@hellmuth-michaelis.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: OpenVPN vs IPSec
Date: Sun, 19 Nov 2017 16:27:12 +0100
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<5A1073E9.5050503@grosbein.net>
<20171119142015.GB82727@admin.sibptus.transneft.ru>
<3A168E23-5CB5-4D99-925A-E9688A24E502@hellmuth-michaelis.de>
<20171119150131.GH82727@admin.sibptus.transneft.ru>
To: freebsd-net@freebsd.org
In-Reply-To: <20171119150131.GH82727@admin.sibptus.transneft.ru>
Message-Id: <633E7984-727C-48D5-8F8D-6424F25B87E8@hellmuth-michaelis.de>
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 15:27:24 -0000
> Am 19.11.2017 um 16:01 schrieb Victor Sudakov <vas@mpeks.tomsk.su>:
>
> Hellmuth Michaelis wrote:
>>
>>
>>>
>>> When I had to setup a VPN with a Macintosh user (road warrior), I
>>> found out that an IPSec VPN would be beyond my mental abilities as I
>>> could not wrap my head around the correct racoon and mpd5
>>> authentication setup between FreeBSD and Mac. That's for all the talk
>>> about being standard-compliant. OpenVPN saved me.
>>
>> Try this one on the Mac: http://www.lobotomo.com/products/IPSecuritas
>> it???s free, it works and it???s actively maintained.
>
> Interesting. Why not the builtin IPSec implementation?
To get things done. ;-)
-hm
From owner-freebsd-net@freebsd.org Sun Nov 19 15:29:18 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 0CC6BD94A16
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 15:29:18 +0000 (UTC)
(envelope-from mad@madpilot.net)
Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38])
(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 C0D137C751
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 15:29:16 +0000 (UTC)
(envelope-from mad@madpilot.net)
Received: from mail (mail [192.168.254.3])
by mail.madpilot.net (Postfix) with ESMTP id 3yfwZs13XpzZqh;
Sun, 19 Nov 2017 16:22:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h=
content-transfer-encoding:content-language:content-type
:content-type:in-reply-to:mime-version:user-agent:date:date
:message-id:from:from:references:subject:subject:received
:received; s=mail; t=1511104963; x=1512919364; bh=cv/WhJBnwS7TJf
8uklhYHG9rU14SljI5v+2BlltdZEg=; b=gPEOKJzqjl294+Xw1Jb44K4D2IuLq9
mPGPo6wC+YLehbeTINB5L7CZkqLe2aJuMtDwD/WxWZEEpSjdb6qUDkWGzMlG6LTW
SF4HKLoP9S/sIFn+TH2IFS/83BcP3m8sJuoCAHUkvGatQA3/aOm5Kc/FtivMjAns
LqUg8Jv2PxJB0=
Received: from mail.madpilot.net ([192.168.254.3])
by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024)
with ESMTP id 7bIlX3Ja_pH8; Sun, 19 Nov 2017 16:22:43 +0100 (CET)
Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by mail.madpilot.net (Postfix) with ESMTPSA;
Sun, 19 Nov 2017 16:22:43 +0100 (CET)
Subject: Re: OpenVPN vs IPSec
To: Victor Sudakov <vas@mpeks.tomsk.su>, freebsd-net@freebsd.org
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
From: Guido Falsi <mad@madpilot.net>
Message-ID: <4b423f34-3717-b539-ca8c-4508f0caef3a@madpilot.net>
Date: Sun, 19 Nov 2017 16:22:42 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171118165842.GA73810@admin.sibptus.transneft.ru>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 15:29:18 -0000
On 11/18/2017 17:58, Victor Sudakov wrote:
> Dear Colleagues,
>
> Is there any reason to prefer IPSec over OpenVPN for building VPNs
> between FreeBSD hosts and routers (and others compatible with OpenVPN
> like pfSense, OpenWRT etc)?
I am personally using OpenVPN for my extremely modest needs, but a
friend with more complex needs found a good tool with softether
(available in ports as security/softether). I also suggested it to some
friends who are happy with it and reported it is easy to setup and use.
It would give you freedom of choice for proto/client.
Please note that I never used it myself although I plan to give it a
spin sometime.
This is just a suggestion from a more practical point of view, without
any consideration on which one is the superior protocol/tool.
--
Guido Falsi <mad@madpilot.net>
From owner-freebsd-net@freebsd.org Sun Nov 19 16:05:00 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 B639FDB8B4F
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 16:05:00 +0000 (UTC)
(envelope-from emss.mail@gmail.com)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com
[IPv6:2a00:1450:400c:c0c::232])
(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 3CCEF7D9C6
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 16:05:00 +0000 (UTC)
(envelope-from emss.mail@gmail.com)
Received: by mail-wr0-x232.google.com with SMTP id z75so4631115wrc.5
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 08:05:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=sender:from:to:cc:subject:in-reply-to:references:user-agent:date
:message-id:mime-version:content-transfer-encoding;
bh=hTYDbdxsDHM35gvsSHnR0YdUtLD2sOTGoCRg8uAYjMQ=;
b=PED6+4sRUn2yuxhkwhs2b28GKTTOLvHkXn3b/b7oAQTQoR95lOvxr69xN0vjNJZN1N
wGAlQFwKP+opj+XArilb0+HQqUFqabXIEBqfVyQSQ4O+uN8WTL+g7+0Z4KQYSEM1f/7A
kMSrzi0QyP1nZuYebSLnNoGDK0YM62wLvTCf2TTE0k3lpBDaNPlnrMUKPWGAyQu2f1Gd
WtoaAMGygbD3W6/0mtL+SzWUulMuKltLgvYCMgfThd49bO6ZVAABtJYdtPhKEIJ9yDHN
PF/yKELdh60/5Uuvdb5DSyVPdmROYWjnoJtiAq3cxIAMDoM9WIr5kBJRi0SZsnh9s2K+
iigQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references
:user-agent:date:message-id:mime-version:content-transfer-encoding;
bh=hTYDbdxsDHM35gvsSHnR0YdUtLD2sOTGoCRg8uAYjMQ=;
b=HoXWsIuhaZjInAah6hgLPnhDyWoWEr9XMTLZ3KfzOlpnmHha5hIqWxv6Aq5VT+beul
4IyEasW+6VSXC4qdBRixr0T/3QlcVM2sxGHX5Ydoan/9eslSDO6H3K/KZdC2+XFx3YII
oUszWE2caho+dw3WlkTVpheKMU8taEBKdhY+rDVNAj92psTn2hwTuDRvBh1UaXeLOEIg
4nfYwcjnTChcLGuYauXrg3J/pTsLvmX3TcOUYYeUZhDQ935tbBTWPBgYcahov/ncUh2z
rT3f9IQfDzf5eKcmQ/XvLF6BN6dm5ah6sGzAhgjR+coV3GoGQ9Nc0j5rbh8KZDCGokXl
c1ug==
X-Gm-Message-State: AJaThX6Aqa/Jy29XjGs0gfv981q5JGTCT7FWuRAKJDnwWDrwNLUviOD2
GJptQPeqSyxOGPKj0/BiZnZYrw==
X-Google-Smtp-Source: AGs4zMa/x0hwbj7KLzMGSnsm5Lma2Pk9meBotLVoKP33eAZiylTPhwvdPD3PS9WgvE+YHOUeo9dg9Q==
X-Received: by 10.223.199.70 with SMTP id b6mr204606wrh.25.1511107497459;
Sun, 19 Nov 2017 08:04:57 -0800 (PST)
Received: from srvbsdfenssv.interne.associated-bears.org
(LStLambert-658-1-110-48.w217-128.abo.wanadoo.fr. [217.128.200.48])
by smtp.gmail.com with ESMTPSA id f132sm383333wmf.17.2017.11.19.08.04.56
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 19 Nov 2017 08:04:56 -0800 (PST)
Sender: Eric Masson <emss.mail@gmail.com>
Received: from newsrv.interne.associated-bears.org (localhost [127.0.0.1])
by srvbsdfenssv.interne.associated-bears.org (Postfix) with ESMTP id BCFEF2795;
Sun, 19 Nov 2017 17:04:55 +0100 (CET)
X-Virus-Scanned: amavisd-new at interne.associated-bears.org
Received: from srvbsdfenssv.interne.associated-bears.org ([127.0.0.1])
by newsrv.interne.associated-bears.org (newsrv.interne.associated-bears.org
[127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 72o5AdJJOHAD; Sun, 19 Nov 2017 17:04:54 +0100 (CET)
Received: by srvbsdfenssv.interne.associated-bears.org (Postfix,
from userid 1001) id 6F0A82790; Sun, 19 Nov 2017 17:04:54 +0100 (CET)
From: Eric Masson <emss@free.fr>
To: Victor Sudakov <vas@mpeks.tomsk.su>
Cc: freebsd-net@freebsd.org, Jim Thompson <jim@netgate.com>, "Muenz\,
Michael" <m.muenz@spam-fetish.org>
Subject: Re: OpenVPN vs IPSec
In-Reply-To: <20171119145116.GE82727@admin.sibptus.transneft.ru> (Victor
Sudakov's message of "Sun, 19 Nov 2017 21:51:16 +0700")
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<86o9nytmma.fsf@newsrv.interne.associated-bears.org>
<20171119145116.GE82727@admin.sibptus.transneft.ru>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix)
X-Operating-System: FreeBSD 11.1-STABLE amd64
Date: Sun, 19 Nov 2017 17:04:54 +0100
Message-ID: <86k1ymtftl.fsf@newsrv.interne.associated-bears.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 16:05:00 -0000
Victor Sudakov <vas@mpeks.tomsk.su> writes:
Hi,
> That is, if you use kernel IPsec. But StrongSwan is completely
> userland AFAIK.
Nope, StrongSwan provides a userland ipsec stack but clearly states it's
not intended to be used on security gateways. Its typical use case is
when the kernel stack misses a required algorithm.
> And the kernel IPsec implementation has had problems with NAT
> traveral. Does it stil have problems and requre extra patches for NAT
> traveral?
Seems to me no patch has been required for a long time. ipsec is even
now enabled in GENERIC and has no performance impact when not used
(thanks to bz@).
> Maybe I'm indeed the faulty layer between keyboard and chair, but
> FreeBSD+IPsec+L2TP is still beyond me. Pure IPsec is fine more or
> less with me.
ipsec works fine, L2TP/ipsec is somewhat more convoluted. racoon needs 2
patches from what I've read here :
https://forums.freebsd.org/threads/26755/
As I've now switched my gateways to LEDE/OpenWRT, I no longer toy with
this kind of setup on FreeBSD.
--
Les L*n*x**ns sont par définition des nioubies, biscotte on
buvait déjà de la Guiness autour de trucs BSD alors que la pingouinade
n'était même pas une lueur lubrique dans le regard de Linus T.
-+- FYlG in <http://www.le-gnu.net> : Gouin gouin les pingouins -+-
From owner-freebsd-net@freebsd.org Sun Nov 19 16:09:08 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 B130DDB8C20
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 16:09:08 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 444FB7DAEF
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 16:09:07 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be
forged))
by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vAJG8xs9082877
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 19 Nov 2017 17:09:00 +0100 (CET)
(envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: emss@free.fr
Received: from [10.58.0.4] ([10.58.0.4])
by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vAJG8tDl061370
(version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Sun, 19 Nov 2017 23:08:55 +0700 (+07)
(envelope-from eugen@grosbein.net)
Subject: Re: OpenVPN vs IPSec
To: Eric Masson <emss@free.fr>, Victor Sudakov <vas@mpeks.tomsk.su>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<86o9nytmma.fsf@newsrv.interne.associated-bears.org>
<20171119145116.GE82727@admin.sibptus.transneft.ru>
<86k1ymtftl.fsf@newsrv.interne.associated-bears.org>
Cc: freebsd-net@freebsd.org, Jim Thompson <jim@netgate.com>,
"Muenz, Michael" <m.muenz@spam-fetish.org>
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <5A11AC93.50504@grosbein.net>
Date: Sun, 19 Nov 2017 23:08:51 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <86k1ymtftl.fsf@newsrv.interne.associated-bears.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE
autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000] * 2.6 LOCAL_FROM From my domains
* 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 16:09:08 -0000
19.11.2017 23:04, Eric Masson wrote:
> ipsec works fine, L2TP/ipsec is somewhat more convoluted. racoon needs 2
> patches from what I've read here :
> https://forums.freebsd.org/threads/26755/
That's way too outdated. No additional patches needed today.
From owner-freebsd-net@freebsd.org Sun Nov 19 16:27:12 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 E5612DB908B
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 16:27:12 +0000 (UTC)
(envelope-from emss.mail@gmail.com)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com
[IPv6:2a00:1450:400c:c09::22e])
(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 6AAFE7E1B1
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 16:27:12 +0000 (UTC)
(envelope-from emss.mail@gmail.com)
Received: by mail-wm0-x22e.google.com with SMTP id 9so14453541wme.4
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 08:27:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=sender:from:to:cc:subject:in-reply-to:references:user-agent:date
:message-id:mime-version:content-transfer-encoding;
bh=GrG7H3AE+8aQ/oyPPlnf380cJTUxWFHwzms6+tVgDGc=;
b=NrD0ggg8CojPe6syQMgY+dwyc01+l0gFo259bDA7MV3OY5xJZ/p3FPe9ZeIxsgOJTr
3tfmoH7zp2q2y3yVEYrY62HaMEezbMg05aAhYhFuu+KK4esVHUPqemd7Iq2ytslMmzTP
uudpSdnb04mezE5WVqhgkqAjEgujvc79aQ8au5qHzWwdXS1rIEloBqbqtDPWzokQEDhp
ENQplHhlgm/YDk9XVGKoxNRQY9NN49tVXgRUus1Dhr8ZMBf+Pfjbh3CnKYbGfNvMscOH
keXCoxCioDoX4I0SpOUE5+w71Lt387dg4VHfU6+GAOSTyqJ8xlmXIGDVQ4J/YHnScPVZ
Wt4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references
:user-agent:date:message-id:mime-version:content-transfer-encoding;
bh=GrG7H3AE+8aQ/oyPPlnf380cJTUxWFHwzms6+tVgDGc=;
b=Y2QXmNg6VMkRJWqS63To9PLaHOJgvX3DfsfDMsL9Lvr1kSPRzybZdKS9M2m9BM9kJP
UBc/SefX407AkTNNk2WaIyEN2ZHmOGLsTbRJrp+BHmP8F0lIk5fzH/dAtpFlSg7VGDu6
1zRLFAOBln0L1hoFtGgdQ3ug9w2Wjqb6A+1O8u+znpiXUA0WxbYzVKVl/Fa9LtjXIEQg
1YW+XSCFyX2r23wgOS6paBiwYA3i2gS9AU9IHaACeHf1OJUfn8zwTjGiGpaFbYm5Oxmi
OsExIp8PdaWFLNU8EgDX0afQFNpYBPlDIC+pAn+J93nkmXkHton//kytAK9Q61q8mAUs
0MNQ==
X-Gm-Message-State: AJaThX4IkcXpz1s/mEEUytkE1WKgQjz3vg6Ip1moocZK8n/eoWc/oYgk
JYK3Q13VX4/VUDtuke9XVFVyXQ==
X-Google-Smtp-Source: AGs4zMYWRfX2SXmSnDVDe76cWovo7RxQmLS5YZrXRm6weN0G9ybxdYayQq7rXxBW57lWCkv35p3C7A==
X-Received: by 10.28.74.213 with SMTP id n82mr9003615wmi.15.1511108830641;
Sun, 19 Nov 2017 08:27:10 -0800 (PST)
Received: from srvbsdfenssv.interne.associated-bears.org
(LStLambert-658-1-110-48.w217-128.abo.wanadoo.fr. [217.128.200.48])
by smtp.gmail.com with ESMTPSA id m187sm7861775wmg.18.2017.11.19.08.27.09
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 19 Nov 2017 08:27:10 -0800 (PST)
Sender: Eric Masson <emss.mail@gmail.com>
Received: from newsrv.interne.associated-bears.org (localhost [127.0.0.1])
by srvbsdfenssv.interne.associated-bears.org (Postfix) with ESMTP id 19B7527CD;
Sun, 19 Nov 2017 17:27:09 +0100 (CET)
X-Virus-Scanned: amavisd-new at interne.associated-bears.org
Received: from srvbsdfenssv.interne.associated-bears.org ([127.0.0.1])
by newsrv.interne.associated-bears.org (newsrv.interne.associated-bears.org
[127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 8evJps6r53RA; Sun, 19 Nov 2017 17:27:07 +0100 (CET)
Received: by srvbsdfenssv.interne.associated-bears.org (Postfix,
from userid 1001) id 984E427C7; Sun, 19 Nov 2017 17:27:07 +0100 (CET)
From: Eric Masson <emss@free.fr>
To: Eugene Grosbein <eugen@grosbein.net>
Cc: Victor Sudakov <vas@mpeks.tomsk.su>, freebsd-net@freebsd.org,
Jim Thompson <jim@netgate.com>, "Muenz\, Michael" <m.muenz@spam-fetish.org>
Subject: Re: OpenVPN vs IPSec
In-Reply-To: <5A11AC93.50504@grosbein.net> (Eugene Grosbein's message of "Sun,
19 Nov 2017 23:08:51 +0700")
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<86o9nytmma.fsf@newsrv.interne.associated-bears.org>
<20171119145116.GE82727@admin.sibptus.transneft.ru>
<86k1ymtftl.fsf@newsrv.interne.associated-bears.org>
<5A11AC93.50504@grosbein.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix)
X-Operating-System: FreeBSD 11.1-STABLE amd64
Date: Sun, 19 Nov 2017 17:27:07 +0100
Message-ID: <86fu9atesk.fsf@newsrv.interne.associated-bears.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 16:27:13 -0000
Eugene Grosbein <eugen@grosbein.net> writes:
Hi
> That's way too outdated. No additional patches needed today.
Good news
FreeBSD has usually really good docs, but those ipsec related have
always been somewhat out of standard (gif on tunnel mode in handbook for
example).
--
Il n'est pas nécessaire de me faire remarquer que j'en fais (des
fautes). Je le sais, et j'essaye de les limier autant que faire se
peut.
-+- J in Guide du Neuneu sur Usenet : Le limier manque de flair -+-
From owner-freebsd-net@freebsd.org Sun Nov 19 18:39:31 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 CA054DBAEB8
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 18:39:31 +0000 (UTC)
(envelope-from m.muenz@spam-fetish.org)
Received: from mailout-02.maxonline.de (mailout-02.maxonline.de [81.24.66.23])
(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 8AA6280EF3
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 18:39:31 +0000 (UTC)
(envelope-from m.muenz@spam-fetish.org)
Received: from web03-01.max-it.de (web03-01.max-it.de [81.24.64.215])
by mailout-02.maxonline.de (Postfix) with ESMTPS id 7ABDA72
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 19:39:23 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by web03-01.max-it.de (Postfix) with ESMTP id 6E5AE28B83A
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 19:39:23 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at web03-01.max-it.de
Received: from web03-01.max-it.de ([127.0.0.1])
by localhost (web03-01.max-it.de [127.0.0.1]) (amavisd-new, port 10026)
with ESMTP id ll5V7QoCqeYX for <freebsd-net@freebsd.org>;
Sun, 19 Nov 2017 19:39:23 +0100 (CET)
Received: from [81.24.66.132] (unknown [81.24.66.132])
(Authenticated sender: m.muenz@spam-fetish.org)
by web03-01.max-it.de (Postfix) with ESMTPA id 35B9028A017
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 19:39:23 +0100 (CET)
Subject: Re: OpenVPN vs IPSec
To: freebsd-net@freebsd.org
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
<20171119143054.GC82727@admin.sibptus.transneft.ru>
From: "Muenz, Michael" <m.muenz@spam-fetish.org>
Message-ID: <17c380fa-cdc8-38b5-f5bf-713f309afc94@spam-fetish.org>
Date: Sun, 19 Nov 2017 19:39:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171119143054.GC82727@admin.sibptus.transneft.ru>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 18:39:31 -0000
Am 19.11.2017 um 15:30 schrieb Victor Sudakov:
> Muenz, Michael wrote:
>> Am 19.11.2017 um 13:08 schrieb Victor Sudakov:
>>> Muenz, Michael wrote:
>>>>> Is there any reason to prefer IPSec over OpenVPN for building VPNs
>>>>> between FreeBSD hosts and routers (and others compatible with OpenV=
PN
>>>>> like pfSense, OpenWRT etc)?
>>>>>
>>>>> I can see only advantages of OpenVPN (a single UDP port, a single
>>>>> userland daemon, no kernel rebuild required, a standard PKI, an eas=
y
>>>>> way to push settings and routes to remote clients, nice monitoring
>>>>> feature etc). But maybe there is some huge advantage of IPSec I've
>>>>> skipped?
>>>>>
>>>> Hi,
>>>>
>>>> partners/customers with Cisco IOS or ASA wont be able to partner up
>>>> without IPSEC.
>>> Sure, that's why I wrote "and others compatible with OpenVPN
>>> like pfSense, OpenWRT etc" in the first paragraph.
>>>
>> Are you just searching for arguments against IPSec or real life cases?
> Actually, I' searching for arguments *for* IPSec.
>
>> IMHO when you have both ends under control OpenVPN is just fine.
>> If you are planning to interconnect with many customers/vendors IPSec
>> fits best.
> I have a personal success story of establishing transport mode IPSec
> between Windows and FreeBSD/racoon. But when other OSes are involved,
> I have the impression that there is no pure IPSec, it's usually
> IPSec+L2TP, and that's where the FreeBSD part becomes complicated
> (interaction between ipsec, mpd5 and racoon is required).
=C2=A0Victor, perhaps I misunderstood you. I was talking about Site2Site=
,=20
and only this.
I'm fully at your side that IPSec for Remote Access is horrible and I=20
also don't use it.
For RA we generally use OpenVPN or AnyConnect (*duck*).
Michael
From owner-freebsd-net@freebsd.org Sun Nov 19 18:42:53 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 00484DBB07D
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 18:42:53 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 714551262
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 18:42:52 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be
forged))
by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vAJIgeEh083720
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 19 Nov 2017 19:42:41 +0100 (CET)
(envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: vas@mpeks.tomsk.su
Received: from [10.58.0.4] ([10.58.0.4])
by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vAJIgaX4003118
(version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Mon, 20 Nov 2017 01:42:36 +0700 (+07)
(envelope-from eugen@grosbein.net)
Subject: Re: OpenVPN vs IPSec
To: Victor Sudakov <vas@mpeks.tomsk.su>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
<5A11882D.1050700@quip.cz>
<ae7baceb-0aa9-3c76-d3d0-8cad09b6dc42@denninger.net>
<5A119648.4080707@grosbein.net>
<20171119145710.GF82727@admin.sibptus.transneft.ru>
<5A11A019.9090302@grosbein.net>
Cc: freebsd-net@freebsd.org
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <5A11D098.5050102@grosbein.net>
Date: Mon, 20 Nov 2017 01:42:32 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <5A11A019.9090302@grosbein.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE
autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000] * 2.6 LOCAL_FROM From my domains
* 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 18:42:53 -0000
19.11.2017 22:15, Eugene Grosbein пишет:
> 19.11.2017 21:57, Victor Sudakov wrote:
>
>>> I was able to successfully connect Windows 8.1 client to FreeBSD 11.1 server
>>> in the L2TP/IPSEC mode using ipsec-tools (racoon) plus mpd5.
>>
>> Could you please share the setup here or in LiveJournal? I'm most
>> interested in the L2TP/mpd5 part.
>
> There is nothing special to share. Just take a look to its mpd.conf.sample.
> You can use pptp_server part replacing pptp-specific commands (set pptp)
> with l2tp-specific and, of course, change link type "pptp" with "l2tp".
>
> You can even debug mpd5/l2tp part without engaging IPSec at all
> by using unencrypted "L2TP without IPSEC" clients to begin with.
Actually, there are some points that worth to mention:
- by default, Windows 8.1 does not send its FQDN attribute within IKE,
so you need to use "my_identifier address" and "verify_identifier off"
inside remote {} section in the racoon.conf in case of Windows roaming user
(or find a way to reconfigure Windows to include FQDN attribute, if possible);
- Windows 8.1 needs proposal with encryption_algorithm aes, hash_algorithm sha1
and dh_group modp2048 (not to mention 3des + dh_group modp1024);
- Windows 8.1 does not like "l2tp hidden" mode that additionally
encrypts l2tp control packets, so do not use "set l2tp enable hidden/set l2tp secret"
commands in the mpd.conf and you will be fine.
From owner-freebsd-net@freebsd.org Sun Nov 19 18:46:06 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 25420DBB12F
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 18:46:06 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id AED961380
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 18:46:05 +0000 (UTC)
(envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be
forged))
by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vAJIk0rw083762
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 19 Nov 2017 19:46:01 +0100 (CET)
(envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: m.muenz@spam-fetish.org
Received: from [10.58.0.4] ([10.58.0.4])
by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vAJIjvMm004092
(version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Mon, 20 Nov 2017 01:45:57 +0700 (+07)
(envelope-from eugen@grosbein.net)
Subject: Re: OpenVPN vs IPSec
To: "Muenz, Michael" <m.muenz@spam-fetish.org>, freebsd-net@freebsd.org
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
<d92dff62-3baf-a22d-bfac-5a668b276259@spam-fetish.org>
<20171119143054.GC82727@admin.sibptus.transneft.ru>
<17c380fa-cdc8-38b5-f5bf-713f309afc94@spam-fetish.org>
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <5A11D161.5050104@grosbein.net>
Date: Mon, 20 Nov 2017 01:45:53 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <17c380fa-cdc8-38b5-f5bf-713f309afc94@spam-fetish.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE
autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000] * 2.6 LOCAL_FROM From my domains
* 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 18:46:06 -0000
20.11.2017 1:39, Muenz, Michael wrote:
> Victor, perhaps I misunderstood you. I was talking about Site2Site, and only this.
> I'm fully at your side that IPSec for Remote Access is horrible and I also don't use it.
In fact, FreeBSD 11.1 + mpd5 + ipsec-tools (racoon) works just fine (out-of-box)
as L2TP/IPSEC Remote Access server for roaming Android, iPhone, Windows and MacOS X users,
including transparent NAT Traversal. Earlier FreeBSD versions, indeed, had problems.
From owner-freebsd-net@freebsd.org Sun Nov 19 18:56:45 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 A0F7DDBB3B1
for <freebsd-net@mailman.ysv.freebsd.org>;
Sun, 19 Nov 2017 18:56:45 +0000 (UTC)
(envelope-from csalgau@users.sourceforge.net)
Received: from mx02.buh.bitdefender.com (mx02.bbu.dsd.mx.bitdefender.com
[91.199.104.133])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "*.mx.bitdefender.com", Issuer "thawte SSL CA - G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 1059B18E4
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 18:56:44 +0000 (UTC)
(envelope-from csalgau@users.sourceforge.net)
Received: (qmail 26492 invoked from network); 19 Nov 2017 20:50:00 +0200
Received: from mx01robo.bbu.dsd.mx.bitdefender.com (10.17.80.60)
by mx02.buh.bitdefender.com with AES128-GCM-SHA256 encrypted SMTP;
19 Nov 2017 20:50:00 +0200
Received: (qmail 29112 invoked from network); 19 Nov 2017 20:49:59 +0200
Received: from unknown (HELO ?10.210.20.54?) (10.210.20.54)
by mx01robo.bbu.dsd.mx.bitdefender.com with SMTP; 19 Nov 2017 20:49:59 +0200
To: freebsd-net@freebsd.org
From: Catalin Salgau <csalgau@users.sourceforge.net>
Subject: BPF packet pagesize limit
Openpgp: preference=signencrypt
Message-ID: <966f384c-10b4-d018-efb1-68a7064c9521@users.sourceforge.net>
Date: Sun, 19 Nov 2017 20:49:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101
Thunderbird/56.0
MIME-Version: 1.0
Content-Language: en-GB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 18:56:45 -0000
Hello,
I'm trying to address the limitation in (upstream) net/vblade that was
brought up in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205164
This is related to writes larger than hw.pagesize but smaller than the
configured MTU with BPF.
I traced this to sys/net/bpf.c where calls to bpfwrite() will use
bpf_movein() which in turn uses m_get2() to allocate a single mbuf. This
will fail if the requested mbuf size is larger than MJUMPAGESIZE
(defined as PAGE_SIZE on x86). I believe this should use m_getm2() and
populate multiple mbufs.
Code in NetBSD explicitly notes that they omit mbuf chaining, but this
is not documentated behaviour in the man page.
Any chance of having this fixed in a supported release, or getting a
usable/documented workaround?
Thanks.
From owner-freebsd-net@freebsd.org Mon Nov 20 01:02:45 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 B8BD7DDBF0D
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 20 Nov 2017 01:02:45 +0000 (UTC) (envelope-from jim@netgate.com)
Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com
[IPv6:2607:f8b0:4003:c0f::22b])
(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 829CF69F1E
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 01:02:45 +0000 (UTC)
(envelope-from jim@netgate.com)
Received: by mail-ot0-x22b.google.com with SMTP id u10so6359386otc.12
for <freebsd-net@freebsd.org>; Sun, 19 Nov 2017 17:02:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=gtsj4J56jknfqsUk58GsnPWzGsfsEEgqAKniMOqARj8=;
b=CpiA+PCcw5ZyLrqCxR9wLwNW6PG9gGa5HuxTKVHDZjS97Re7j0HDYohfOD+5jooAgs
Y+DIOBs41+KC9i6jtu1SWIab+7E40BnV/4dS5hFZUEKYEdyyrvHZPzKGyLfLykn40OhP
OVnidr3UFMUyyA8LsW4KAkjAVOlgGv5aGVSH0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=gtsj4J56jknfqsUk58GsnPWzGsfsEEgqAKniMOqARj8=;
b=DcRZm8csQZJf4PJ+pP86qhZzPAa8R4F89hemmcZPJKp9zxkx0LnOLSgqEiF9MEAvwP
ZsqdH7hp5U5bkzr+VyKUQRW069X8yKNCY2rGjt1zNXSBBJE8HvqYLQ/5+TjS7aQVNCgB
d1mTL0xEgbyG5FmMmCwDNa9vMir0rgurdb4pUUBoqdw3PvDu0D+fiUrLW0taCzWVIXHX
2+a3tYJneFMoOPdVwpkq0nANfYWFHxYh/n9JJxXhjBSO4xoOYjsPxLRtN7T3+mptXIPV
qu2QAqBVuCfVQD04ATJqTPVR1Nz4NdJ0o3aN6Xhf4l+KLBbDWMAVY0CihT4vWwaIDNhy
nfmA==
X-Gm-Message-State: AJaThX78nCiVR5CiBTizQYuqYo5eCT5KI8gmBUW00lT6ZQywbah1Xj+g
Dzr9AP9qJZSu7ECP5opM3ve6xKtPsPc=
X-Google-Smtp-Source: AGs4zMbnm6OEbZFZJchFoFm27sLTisMucjPRW2U9uWxlxXdN5LGeO6z7QCaaIxBXo34nsW46+VOqog==
X-Received: by 10.157.24.19 with SMTP id b19mr6544866ote.265.1511139764360;
Sun, 19 Nov 2017 17:02:44 -0800 (PST)
Received: from [172.21.0.169] (65-36-116-65.dyn.grandenetworks.net.
[65.36.116.65])
by smtp.gmail.com with ESMTPSA id y2sm1842358otg.51.2017.11.19.17.02.43
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 19 Nov 2017 17:02:43 -0800 (PST)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: OpenVPN vs IPSec
From: Jim Thompson <jim@netgate.com>
In-Reply-To: <20171119120832.GA82727@admin.sibptus.transneft.ru>
Date: Sun, 19 Nov 2017 19:02:42 -0600
Cc: "Muenz, Michael" <m.muenz@spam-fetish.org>,
FreeBSD Net <freebsd-net@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2472B38E-694E-4E3A-8234-DB231B532728@netgate.com>
References: <20171118165842.GA73810@admin.sibptus.transneft.ru>
<b96b449e-3dc1-6e75-e803-e6d6abefe88e@spam-fetish.org>
<20171119120832.GA82727@admin.sibptus.transneft.ru>
To: Victor Sudakov <vas@mpeks.tomsk.su>
X-Mailer: Apple Mail (2.3445.4.7)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 01:02:45 -0000
On Nov 19, 2017, at 6:08 AM, Victor Sudakov <vas@mpeks.tomsk.su> wrote:
> Muenz, Michael wrote:
>>>=20
>>> Is there any reason to prefer IPSec over OpenVPN for building VPNs
>>> between FreeBSD hosts and routers (and others compatible with =
OpenVPN
>>> like pfSense, OpenWRT etc)?
>>>=20
>>> I can see only advantages of OpenVPN (a single UDP port, a single
>>> userland daemon, no kernel rebuild required, a standard PKI, an easy
>>> way to push settings and routes to remote clients, nice monitoring
>>> feature etc). But maybe there is some huge advantage of IPSec I've
>>> skipped?
>>>=20
>> Hi,
>>=20
>> partners/customers with Cisco IOS or ASA wont be able to partner up=20=
>> without IPSEC.
>=20
> Sure, that's why I wrote "and others compatible with OpenVPN
> like pfSense, OpenWRT etc" in the first paragraph.
>=20
> Jim Thompson wrote:
>>=20
>> Performance is better with IPsec.
>=20
> Because it's in the kernel? But many use (and recommend) StrongSwan
> which is a userland implementation.
Yes, because it=E2=80=99s in the kernel. OpenVPN uses tun/tap and there =
is considerable performance overhead due to multiple copies per packet =
across the user-space / kernel boundary using these. This problem is =
compounded by handing relatively small packets to OpenSSL=E2=80=99s EVP =
layer for encrypt/decrypt and authentication. Here is a write-up from =
2011: https://homepages.staff.os3.nl/~delaat/rp/2010-2011/p09/report.pdf
As you can read in the paper, the normal recommendation to overcome =
these is to increase the MTU on the TAP interface, and disable =
OpenVPV=E2=80=99s fragmentation routines. This serves to decrease these =
overheads. See also: =
https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux Note =
that this write-up is a bit duplicitous as they=E2=80=99ve disabled =
encryption and increased the =E2=80=9CMTU=E2=80=9D to reduce the =
per-packet copy overhead and eliminate the encryption overhead.=20
More than once I=E2=80=99ve considered attempting to make OpenVPN work =
on top of netmap, just to see how much overhead could be negated via =
same. Use in a FreeBSD system would probably require VALE with a =
steering plugin to direct the OpenVPN frames to the OpenVPN processes, =
and the remainder to the kernel stack. On linux, one could use a SR-IOV =
VF with netmap and allow the rest of the NIC to be used for the system. =
Even with this, performance of OpenVPN will be constrained by the =
packet-at-a-time single thread of execution implementation inside =
OpenVPN=E2=80=99s code. While crypto can be offloaded, these can not. =
A rewrite will be needed to get to true 1gbps performance (or above).
To address another of your arguments: StrongSwan does, indeed, have a =
user-land implementation of IPsec, most consumers (including pfSense) =
use StrongSwan for IKE/IKEv2 keying of an in-kernel (FreeBSD, Linux) =
IPsec implementation. Even StrongSwan=E2=80=99s primary author says the =
userland IPsec has performance issues. =
https://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec
That said, we=E2=80=99ve benchmarked our userland IPsec implementation =
at 36.32 Gbps over 40 Gbps Ethernet with crypto offload via Intel=E2=80=99=
s QuickAssist, and yes, we use StrongSwan for IKEv2. The rest (40gbps - =
36.32) is framing overhead. See slide 11: =
https://wiki.fd.io/images/1/1d/40_Gbps_IPsec_on_commodity_hardware.pdf. =
On slide 10 you can see that we obtained 13.7Gbps single-stream =
throughput using AES-GCM-128 and AES-NI.
The next goal is to get to 100gbps using newer QAT cards and 100Gbps =
NICs.
OpenVPN will never get close to these results without a rewrite. Nor, =
to address the elephant in the room, can it obtain the same performance =
as IPsec on FreeBSD today.
>> It's a standard, too.=20
>=20
> IPsec in itself maybe a standard, but IKE does not seem to be much of =
a standard, I get the impression that there's much incompatibility =
between vendors (Cisco, racoon etc).=20
RFC 4301, RFC 4303, etc all define IPsec proper. See section 1.3 of RFC =
4301 for a more complete list. =
https://tools.ietf.org/html/rfc4301#section-1.3 RFC 7296 / STD 79 is the =
primary document for IKEv2. https://tools.ietf.org/html/rfc7296 Yes, =
there were implementation difficulties with ISAKMP/IKE (raccoon is IKE), =
but IKEv2 (Oct 2014) is considerably better when it comes to both =
security and interoperability of various implementations. Lessons were =
learned. OTOH, there is no RFC for OpenVPN, it=E2=80=99s a vendor =
implementation. Some documentation exists: =
https://openvpn.net/index.php/open-source/documentation/security-overview.=
html
The other =E2=80=9CVPN=E2=80=9D that is getting increasing mention is =
=E2=80=9CWireGuard=E2=80=9D https://www.wireguard.com/. WireGuard=E2=80=99=
s performance page has additional comparisons between OpenVPN, IPsec =
and, of course, WireGuard. https://www.wireguard.com/performance/. These =
tests are on linux, not FreeBSD, because no port of WireGuard to FreeBSD =
exists. This said, more than one individual has expressed interest in a =
FreeBSD port of WireGuard. The main issue here is that WireGuard (like =
OpenVPN and StrongSwan) is GPLed, but unlike these two, a performant =
WireGuard implementation for FreeBSD would need to be in-kernel, and =
that=E2=80=99s not going to occur while the code is still GPL. The =
primary author of WireGuard has indicated a willingness to dual-license =
WireGuard=E2=80=99s code, so the potential exists.
Jim
From owner-freebsd-net@freebsd.org Mon Nov 20 13:23:25 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 6EDA4DEB998
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 20 Nov 2017 13:23:25 +0000 (UTC)
(envelope-from agapon@gmail.com)
Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com
[209.85.215.53])
(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 EE6C37DDF4
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 13:23:24 +0000 (UTC)
(envelope-from agapon@gmail.com)
Received: by mail-lf0-f53.google.com with SMTP id g35so10028882lfi.13
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 05:23:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:cc:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=W5FnknpM2Kic2uU68MwAIgcxgQ7C2E+arjPeqJDvOBA=;
b=VQ0Ttsv9EGhFwYweH1aLlGNg+iw4iqnyPtuZYeRgu3K2pIqZm9GY3tFyUKlxL7+Wm+
/iqWdH536dK2SUomhKMBsV3sKLot2khjnQ8lmOF9U34BEa7t4R9rC7SB1/WMHt3O1lGX
by9o0eyfWXyeceYKux1Wf9woIaTJrMJLCOZw3GVFdEpZ8WRtfYClA58TYGZAJmbunK5r
0+9OuObqzq1lTEQPuY/0A+4aB4DRUJswRyIFX+bTF/zUXx+rL69lZ8KHLEb8TyuMHbWD
/0giKijbLwkJD9zJr7QmpGpihX3bJ+X/leeBX+MiZdfS6j6cE0h7+GmS6FTTe1Y8KNe6
1tKw==
X-Gm-Message-State: AJaThX5a2RDZJYoShjEx3iS7lPvft7M3YLsxjGra1ufjEHZQNNHEffRu
hvdPEXinMhjwUtN1P+Sxr0rMUEkK
X-Google-Smtp-Source: AGs4zMa4Pb1NkKgWJcsVUS9prAkM3KO5TtQ4QI7RUHfwi7mlN2ScTVZ92jEGq5ij9MQp5psw7Nv2FQ==
X-Received: by 10.46.27.24 with SMTP id b24mr4352629ljb.54.1511184196932;
Mon, 20 Nov 2017 05:23:16 -0800 (PST)
Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96])
by smtp.googlemail.com with ESMTPSA id 39sm2601021ljb.49.2017.11.20.05.23.15
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 20 Nov 2017 05:23:16 -0800 (PST)
Subject: Re: local_unbound, resolvconf, vpn
To: =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= <des@des.no>
Cc: freebsd-net@FreeBSD.org
References: <5689438f-6734-6b57-b700-d70ee2b7578a@FreeBSD.org>
<86a7zq8er7.fsf@desk.des.no>
From: Andriy Gapon <avg@FreeBSD.org>
Message-ID: <8a098542-9f04-3a41-76f1-e463e3e89c99@FreeBSD.org>
Date: Mon, 20 Nov 2017 15:23:14 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <86a7zq8er7.fsf@desk.des.no>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 13:23:25 -0000
On 13/11/2017 15:55, Dag-Erling Smørgrav wrote:
> Andriy Gapon <avg@FreeBSD.org> writes:
>> First, there is now an automatically generated /etc/resolvconf.conf.
>> It has the following comment:
>> # This file was generated by local-unbound-setup.
>> # Modifications will be overwritten.
>> Is that comment really true?
>> What and when is going to overwrite my modifications?
>
> service local_unbound setup
So, this is not going to happen automatically (after the initial setup) ?
I have to manually run that command?
If yes, then this is much less scary then the unconditional warning in the file.
>> Next. The auto-generated resolvconf.conf has this trick to prevent modifications
>> of resolv.conf: resolv_conf="/dev/null"
>> The trick works but it causes some small noise when resolvconf is run, like
>> cannot copy /dev/null to /dev/null.bak.
>> I think that a nicer solution is to just set name_servers=127.0.0.1:
>
> No, if we let resolvconf overwrite resolv.conf then we lose "options
> edns0".
There seems to be a small misunderstanding. The point I was trying to make is
that resolvconf would NOT overwrite resolv.conf if it's configured the way I
suggested. The details are in my original email. I never tried to suggest that
we should let resolvconf overwrite resolv.conf.
> What it boils down to is that resolvconf is a piece of shit and the only
> way to get it to do what we want would be to write a special backend for
> the local_unbound case (see /libexec/resolvconf).
Well, I do not see why...
We already configure resolvconf to not touch resolv.conf.
And resolvconf already has a backend for unbound, it is able to manage the
local_unbound configuration quite reasonably (from my experience).
>> unbound: [7457:0] error: cannot chdir to directory: (No such file or directory)
>
> This error is emitted by the configuration parser when it encounters the
> "directory" directive in the "server" section and fails to chdir to the
> specified directory, but there should be a name there. Can you do:
>
> # service local_unbound stop
> # mv /var/unbound /var/unbound.orig
> # mtree -deU -f /etc/mtree/BSD.var.dist
> # service local_unbound setup
> # diff -ru /var/unbound.orig /var/unbound
>
> and tell me if there are any differences?
Alexander Zagrebin already explained what's going on here.
local_unbound setup produces this configuration:
chroot: /var/unbound
directory: /var/unbound
And with it unbound apparently tries to chdir to "" after chrooting to
/var/unbound. That is, it removes $chroot from $directory and chdir-s to the
result. Changing directory to /var/unbound/ makes the complaint go away.
--
Andriy Gapon
From owner-freebsd-net@freebsd.org Mon Nov 20 13:25:13 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 67FC9DEBAA3
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 20 Nov 2017 13:25:13 +0000 (UTC)
(envelope-from agapon@gmail.com)
Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com
[209.85.215.47])
(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 ED7D17DF0E
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 13:25:12 +0000 (UTC)
(envelope-from agapon@gmail.com)
Received: by mail-lf0-f47.google.com with SMTP id m1so10059598lfj.9
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 05:25:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=MqksTrEXwzoAtV/qSewGwqOSkZLRD3yxWgC/qhH42o0=;
b=rjEFosLGAqGQdLwBwk5iw4fc0w1vy4YICkSvkS0l+IfUzvSsbIgzsnYKgHR1aFy1mp
WMgDchI26oa4CiKNGC0agjm3JM6UVJxEMkiWsv3Mat4bwvxTWhAUeXGQ5L56FWXMhAnV
xkHUFPThhRg/MTTIYdiT14a6QC9Aa997ZsI4bBuSta0Ryc0mAR+/Ud9grVQN1n6Zez73
4JAG4MudD3bml+fWDlKzhEI64E3Gui1aaNwhd3BqLgcoHDl7earoeICuTn/jJVaIMmn1
tZWAyr3wedhtjszDzrNrVcLLoip8/jVPDCWVk8YhqygxJMGwmye5XYQXI75CeGX0M5Cy
o4lg==
X-Gm-Message-State: AJaThX7XN67hn1b3Q9SO5UKxio30hsfoRbw8gjIKGnLZb4dcEUohaDfz
YCbwQukPpiBXlRjzK3ZNyjTy7y3p
X-Google-Smtp-Source: AGs4zMZ9Y6xeFd6mqAdeABRIWw8LJwcPDO7cC7BKa3jnmIOYOEa8hLCmPn69iRadXwa1e6iTCrEskA==
X-Received: by 10.46.71.133 with SMTP id u127mr2771022lja.52.1511184304402;
Mon, 20 Nov 2017 05:25:04 -0800 (PST)
Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96])
by smtp.googlemail.com with ESMTPSA id z6sm2301868ljc.8.2017.11.20.05.25.03
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 20 Nov 2017 05:25:03 -0800 (PST)
Subject: Re: local_unbound, resolvconf, vpn
To: Alexander Zagrebin <alex@zagrebin.ru>, freebsd-net@freebsd.org
References: <5689438f-6734-6b57-b700-d70ee2b7578a@FreeBSD.org>
<20171108151713.413d28c4@vm2.home.zagrebin.ru>
From: Andriy Gapon <avg@FreeBSD.org>
Message-ID: <7b016084-adf9-2d9e-bb04-c6a964cd6a0f@FreeBSD.org>
Date: Mon, 20 Nov 2017 15:25:02 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171108151713.413d28c4@vm2.home.zagrebin.ru>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 13:25:13 -0000
On 08/11/2017 14:17, Alexander Zagrebin wrote:
> This message appears because you are using chroot.
> You have to edit /var/unbound/unbound.conf and add a trailing slash to
> value of the 'directory' parameter:
That did it!
> server:
> ...
> chroot: /var/unbound
> directory: /var/unbound/
> ...
>
> When unbound uses chroot, it determines the directory name, that it will
> be use for chdir call, taking in account the value of 'chroot'
> parameter. If 'chroot' equals 'directory' the unbound will call
> chdir(''), which will cause an error.
Thank you very much for the advice and for the explanation behind it.
--
Andriy Gapon
From owner-freebsd-net@freebsd.org Mon Nov 20 14:37:04 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 C23BFDECFE4;
Mon, 20 Nov 2017 14:37:04 +0000 (UTC) (envelope-from lev@FreeBSD.org)
Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81])
by mx1.freebsd.org (Postfix) with ESMTP id 7AF748057E;
Mon, 20 Nov 2017 14:37:04 +0000 (UTC) (envelope-from lev@FreeBSD.org)
Received: from [192.168.19.110] (unknown [89.113.128.32])
(Authenticated sender: lev@serebryakov.spb.ru)
by onlyone.not-for.work (Postfix) with ESMTPSA id 8795C337;
Mon, 20 Nov 2017 17:36:56 +0300 (MSK)
Reply-To: lev@FreeBSD.org
Subject: =?UTF-8?Q?Re:_Intel_I210_=28igb=29_sometimes_consume_all_CPU_on_not?=
=?UTF-8?Q?-so-big_traffic_=e2=80=94_need_help!?=
From: Lev Serebryakov <lev@FreeBSD.org>
To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
freebsd-stable <freebsd-stable@freebsd.org>, Sean Bruno <sbruno@freebsd.org>
References: <8590fa5d-fd06-90c6-8d3e-34c155423720@FreeBSD.org>
Organization: FreeBSD
Message-ID: <8f7eb0e7-29fe-fcf5-7e8a-b509b9c6405b@FreeBSD.org>
Date: Mon, 20 Nov 2017 17:36:50 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <8590fa5d-fd06-90c6-8d3e-34c155423720@FreeBSD.org>
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature";
boundary="qM5H4Nr8lMIQGikPDmRt8BSgTD6pW4Htj"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 14:37:04 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--qM5H4Nr8lMIQGikPDmRt8BSgTD6pW4Htj
Content-Type: multipart/mixed; boundary="DEKsc0vcEjcH5Pvsmku8aEv4o0eX3N3LH";
protected-headers="v1"
From: Lev Serebryakov <lev@FreeBSD.org>
Reply-To: lev@FreeBSD.org
To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
freebsd-stable <freebsd-stable@freebsd.org>, Sean Bruno <sbruno@freebsd.org>
Message-ID: <8f7eb0e7-29fe-fcf5-7e8a-b509b9c6405b@FreeBSD.org>
Subject: =?UTF-8?Q?Re:_Intel_I210_=28igb=29_sometimes_consume_all_CPU_on_not?=
=?UTF-8?Q?-so-big_traffic_=e2=80=94_need_help!?=
References: <8590fa5d-fd06-90c6-8d3e-34c155423720@FreeBSD.org>
In-Reply-To: <8590fa5d-fd06-90c6-8d3e-34c155423720@FreeBSD.org>
--DEKsc0vcEjcH5Pvsmku8aEv4o0eX3N3LH
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 09.11.2017 23:17, Lev Serebryakov wrote:
Looks like I know where it spent all time. I've used 'pmcstat' and got
very suspicious flamegraph. Looks like problem is on codepath which lies
through
igb_refresh_mbufs
m_getjcl
uma_zalloc_arg
[zone_alloc_item]
zone_import
zone_fetch_slab
keg_fetch_slab
keg_alloc_slab
mbuf_jumbo_alloc
kmem_alloc_contig
vm_page_reclaim_contig
vm_phys_scan_contig
vm_page_scan_contig
zone_alloc_item is optional, it presents 50% of time, otherwise path is
one step shorter.
--=20
// Lev Serebryakov
--DEKsc0vcEjcH5Pvsmku8aEv4o0eX3N3LH--
--qM5H4Nr8lMIQGikPDmRt8BSgTD6pW4Htj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAloS6IJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5
NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c
R480QA/+Kh2iH3w1KVQRfIVUXpQEeMAOH+N5y8pVRCUeNLBubMmb9UcejZzdNmyY
tKT7wDwjDaF7VAq1cuKQD/wappWLx2uvrb2ZzUGvIqKHkDmGTlBDGL31jJso5hHV
oqGHoVU0Zt9OOKvYsQKVdoKJa79mKEKRADxtQrZbfEw4maVSIs3s6Xm+KIZFZHO+
dMbeSAoUdpC049T7NvAIYle+KZ2Qq1xnAXJWAb+MvuhQTOeAoc1tu2j4RZH+Euxz
KCN11xjAT/EOPySJC/IwG7W9uQDJcIelhf3A7eN4M6FQqxIK4MnKW61ekdCRsCwu
40X2+HO18OTeLBD3FO38n+uuwqHBU69Nvkozj/gzuIoh//1GQ+mraZuA2csWuHkx
iAs7JunuCjS0fMyCnk3pYM1ULqBvCr0BdQFBAX+lG2TXPxUnk/pxrGRjjPbZZG9Y
kVdsEgdtdW5BCDZvaBCP9RT/DNRpohjT+Z/rsb3B4aNfsqAj8yDUlODxi91dWlKU
jo3GKX0ulXfh83Tw0p/FXlbC1QFV+7TgdvDRMb4EbbMwer7HhxHHgNSIyt3QYOpu
fOe3etfyeTgdzShgU08HRU1SAy4JgEL6tAdZJSsi+tPunBDTKIfZDpHEh9yO95Rz
99CHjEuy6fKvP8lf+aL3ZmjYVhfV+1boO1jbzC8ZpyvtFYqLAmQ=
=REhC
-----END PGP SIGNATURE-----
--qM5H4Nr8lMIQGikPDmRt8BSgTD6pW4Htj--
From owner-freebsd-net@freebsd.org Mon Nov 20 14:43:19 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 F1DE4DED4F5
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 20 Nov 2017 14:43:19 +0000 (UTC) (envelope-from des@des.no)
Received: from smtp.des.no (smtp.des.no [194.63.250.102])
by mx1.freebsd.org (Postfix) with ESMTP id BB68D80C4D;
Mon, 20 Nov 2017 14:43:19 +0000 (UTC) (envelope-from des@des.no)
Received: from desk.des.no (smtp.des.no [194.63.250.102])
by smtp.des.no (Postfix) with ESMTP id 50F7410257;
Mon, 20 Nov 2017 14:43:12 +0000 (UTC)
Received: by desk.des.no (Postfix, from userid 1001)
id 64D629FFA; Mon, 20 Nov 2017 14:43:16 +0000 (UTC)
From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To: Andriy Gapon <avg@FreeBSD.org>
Cc: freebsd-net@FreeBSD.org
Subject: Re: local_unbound, resolvconf, vpn
References: <5689438f-6734-6b57-b700-d70ee2b7578a@FreeBSD.org>
<86a7zq8er7.fsf@desk.des.no>
<8a098542-9f04-3a41-76f1-e463e3e89c99@FreeBSD.org>
Date: Mon, 20 Nov 2017 15:43:16 +0100
In-Reply-To: <8a098542-9f04-3a41-76f1-e463e3e89c99@FreeBSD.org> (Andriy
Gapon's message of "Mon, 20 Nov 2017 15:23:14 +0200")
Message-ID: <86y3n16mez.fsf@desk.des.no>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 14:43:20 -0000
Andriy Gapon <avg@FreeBSD.org> writes:
> Dag-Erling Sm=C3=B8rgrav <des@des.no> writes:
> > Andriy Gapon <avg@FreeBSD.org> writes:
> > > What and when is going to overwrite my modifications?
> > service local_unbound setup
> So, this is not going to happen automatically (after the initial setup) ?
> I have to manually run that command?
Currently, yes, but we will sometimes recommend that users run it after
an upgrade or patch, and I may at some point change the rc script to run
setup every time you start or restart the service.
> > > I think that a nicer solution is to just set name_servers=3D127.0.0.1:
> > No, if we let resolvconf overwrite resolv.conf then we lose "options
> > edns0".
> There seems to be a small misunderstanding. The point I was trying to
> make is that resolvconf would NOT overwrite resolv.conf if it's
> configured the way I suggested.
It will.
> > What it boils down to is that resolvconf is a piece of shit and the
> > only way to get it to do what we want would be to write a special
> > backend for the local_unbound case (see /libexec/resolvconf).
> Well, I do not see why... We already configure resolvconf to not
> touch resolv.conf. And resolvconf already has a backend for unbound,
> it is able to manage the local_unbound configuration quite reasonably
> (from my experience).
Yes, we use that to maintain forward.conf.
But please believe me when I say that I have spent a *lot* of time with
resolvconf and its various backends and I am neither joking nor
exaggerating when I call it a piece of shit.
> Alexander Zagrebin already explained what's going on here.
> local_unbound setup produces this configuration:
> chroot: /var/unbound
> directory: /var/unbound
>
> And with it unbound apparently tries to chdir to "" after chrooting to
> /var/unbound. That is, it removes $chroot from $directory and chdir-s
> to the result. Changing directory to /var/unbound/ makes the
> complaint go away.
I understand, and it's been fixed upstream:
Index: util/configparser.y
=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
--- util/configparser.y (revision 3975)
+++ util/configparser.y (revision 3976)
@@ -585,9 +585,11 @@
strncmp(d, cfg_parser->chroot, strlen(
cfg_parser->chroot)) =3D=3D 0)
d +=3D strlen(cfg_parser->chroot);
- if(chdir(d))
+ if(d[0]) {
+ if(chdir(d))
log_err("cannot chdir to directory: %s (%s)",
d, strerror(errno));
+ }
}
}
;
but I am unable to reproduce the issue on 11.1.
DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no
From owner-freebsd-net@freebsd.org Mon Nov 20 15:14:51 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 90542DEE2CC
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 20 Nov 2017 15:14:51 +0000 (UTC)
(envelope-from agapon@gmail.com)
Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com
[209.85.215.44])
(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 204781DF3
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 15:14:50 +0000 (UTC)
(envelope-from agapon@gmail.com)
Received: by mail-lf0-f44.google.com with SMTP id f134so10475537lfg.8
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 07:14:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:cc:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=8Kd46Cj/7l8rq4j0UgVmz4cMkDkEua8RAu8COVVGpcs=;
b=cGucS0F9UO/f/LilYBGoh+MimKLX76WHF7wUZ1Q7llM1fRdKym5LYvaKz9iJx8CdfD
ii+f4lZPUQZD5BC6sxfZsqNnktUIr04OJl4dAqOermPaW9tK4vq8uMG6GJvpIoOc/K0J
RHqQh3M3R1LJp667agHhi9eqRel57V6MrFWxW1Ye3KjNfG4Naqo6lTuMML/e/2OmzgWM
oA+WqZTMa5TYM/5njxoZiX43DHg7/oUlFFH0rQfQs8XAvn5UJ1rN/ZzXdYx2gvbHASun
cQvC/20haFZT+dJakoyakFnQ7UeHQDpEESziy6BXeFZjBPzEerDDepd7UB0ZbFxP9TyT
gMlQ==
X-Gm-Message-State: AJaThX4qwEFth9dTvWRZ2XAVHwrt/4QfE5BYfqdYqrjfuuwfhxhnxMDf
/7iZw55gSrbxeozkzkRktYI9+Ygl
X-Google-Smtp-Source: AGs4zMbbHUlS6KDhZd4MflQSqaQ9wt+pghGeTVOtBGEi7rYv3YkpoGolvwruHeCFeKSHSNiVLkiAgQ==
X-Received: by 10.46.77.26 with SMTP id a26mr5219952ljb.155.1511190888295;
Mon, 20 Nov 2017 07:14:48 -0800 (PST)
Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96])
by smtp.googlemail.com with ESMTPSA id a69sm1450358ljf.54.2017.11.20.07.14.46
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 20 Nov 2017 07:14:47 -0800 (PST)
Subject: Re: local_unbound, resolvconf, vpn
To: =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= <des@des.no>
Cc: freebsd-net@FreeBSD.org
References: <5689438f-6734-6b57-b700-d70ee2b7578a@FreeBSD.org>
<86a7zq8er7.fsf@desk.des.no>
<8a098542-9f04-3a41-76f1-e463e3e89c99@FreeBSD.org>
<86y3n16mez.fsf@desk.des.no>
From: Andriy Gapon <avg@FreeBSD.org>
Message-ID: <37f97bc5-5187-2700-5811-a9cf173eeb10@FreeBSD.org>
Date: Mon, 20 Nov 2017 17:14:46 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <86y3n16mez.fsf@desk.des.no>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 15:14:51 -0000
On 20/11/2017 16:43, Dag-Erling Smørgrav wrote:
> Andriy Gapon <avg@FreeBSD.org> writes:
>> Dag-Erling Smørgrav <des@des.no> writes:
>>> Andriy Gapon <avg@FreeBSD.org> writes:
>>>> What and when is going to overwrite my modifications?
>>> service local_unbound setup
>> So, this is not going to happen automatically (after the initial setup) ?
>> I have to manually run that command?
>
> Currently, yes, but we will sometimes recommend that users run it after
> an upgrade or patch, and I may at some point change the rc script to run
> setup every time you start or restart the service.
Okay.
Maybe it would be possible to allow the auto-generated configuration and the
manual customizations to co-exists somehow. Like bracketing the auto-generated
lines with some delimiters. Or providing a base file that would get merged into
the generated file.
It would be inconvenient if I am unable to customize the file.
I think that I mentioned 'private_interfaces' already.
>>>> I think that a nicer solution is to just set name_servers=127.0.0.1:
>>> No, if we let resolvconf overwrite resolv.conf then we lose "options
>>> edns0".
>> There seems to be a small misunderstanding. The point I was trying to
>> make is that resolvconf would NOT overwrite resolv.conf if it's
>> configured the way I suggested.
>
> It will.
You are right. I see what happens here... resolvconf generates a new file that
looks very similar to the original file, but it's still a new file.
I have resolv_conf_options="edns0" in resolvconf.conf, so I don't lose the option.
So, I am not sure which way is better.
On the one hand, having unmodified resolv.conf is safer.
On the other hand, I get the search list updated when I connect to a vpn and
it's also nice.
>>> What it boils down to is that resolvconf is a piece of shit and the
>>> only way to get it to do what we want would be to write a special
>>> backend for the local_unbound case (see /libexec/resolvconf).
>> Well, I do not see why... We already configure resolvconf to not
>> touch resolv.conf. And resolvconf already has a backend for unbound,
>> it is able to manage the local_unbound configuration quite reasonably
>> (from my experience).
>
> Yes, we use that to maintain forward.conf.
>
> But please believe me when I say that I have spent a *lot* of time with
> resolvconf and its various backends and I am neither joking nor
> exaggerating when I call it a piece of shit.
I see.
And thank you for all the work that you have done on unbound and its integration.
>> Alexander Zagrebin already explained what's going on here.
>> local_unbound setup produces this configuration:
>> chroot: /var/unbound
>> directory: /var/unbound
>>
>> And with it unbound apparently tries to chdir to "" after chrooting to
>> /var/unbound. That is, it removes $chroot from $directory and chdir-s
>> to the result. Changing directory to /var/unbound/ makes the
>> complaint go away.
>
> I understand, and it's been fixed upstream:
That's cool!
> Index: util/configparser.y
> ===================================================================
> --- util/configparser.y (revision 3975)
> +++ util/configparser.y (revision 3976)
> @@ -585,9 +585,11 @@
> strncmp(d, cfg_parser->chroot, strlen(
> cfg_parser->chroot)) == 0)
> d += strlen(cfg_parser->chroot);
> - if(chdir(d))
> + if(d[0]) {
> + if(chdir(d))
> log_err("cannot chdir to directory: %s (%s)",
> d, strerror(errno));
> + }
> }
> }
> ;
>
> but I am unable to reproduce the issue on 11.1.
I am on head.
Did you do the import of unbound 1.5.10 before or after 11.1?
It seems that the chdir code was not present in the earlier version that we had.
--
Andriy Gapon
From owner-freebsd-net@freebsd.org Mon Nov 20 15:45:27 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 5F79CDEF554
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 20 Nov 2017 15:45:27 +0000 (UTC) (envelope-from des@des.no)
Received: from smtp.des.no (smtp.des.no [194.63.250.102])
by mx1.freebsd.org (Postfix) with ESMTP id 2826B3133;
Mon, 20 Nov 2017 15:45:26 +0000 (UTC) (envelope-from des@des.no)
Received: from desk.des.no (smtp.des.no [194.63.250.102])
by smtp.des.no (Postfix) with ESMTP id 5A62510378;
Mon, 20 Nov 2017 15:45:25 +0000 (UTC)
Received: by desk.des.no (Postfix, from userid 1001)
id 83C1348004; Mon, 20 Nov 2017 15:45:29 +0000 (UTC)
From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To: Andriy Gapon <avg@FreeBSD.org>
Cc: freebsd-net@FreeBSD.org
Subject: Re: local_unbound, resolvconf, vpn
References: <5689438f-6734-6b57-b700-d70ee2b7578a@FreeBSD.org>
<86a7zq8er7.fsf@desk.des.no>
<8a098542-9f04-3a41-76f1-e463e3e89c99@FreeBSD.org>
<86y3n16mez.fsf@desk.des.no>
<37f97bc5-5187-2700-5811-a9cf173eeb10@FreeBSD.org>
Date: Mon, 20 Nov 2017 16:45:29 +0100
In-Reply-To: <37f97bc5-5187-2700-5811-a9cf173eeb10@FreeBSD.org> (Andriy
Gapon's message of "Mon, 20 Nov 2017 17:14:46 +0200")
Message-ID: <86tvxp6jja.fsf@desk.des.no>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 15:45:27 -0000
Andriy Gapon <avg@FreeBSD.org> writes:
> Did you do the import of unbound 1.5.10 before or after 11.1?
FreeBSD 10 has 1.5.7. FreeBSD 11 and 12 both have 1.5.10.
> It seems that the chdir code was not present in the earlier version that =
we had.
It was added in 1.5.10, only a few hours after 1.5.9 was released.
DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no
From owner-freebsd-net@freebsd.org Mon Nov 20 16:27:50 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 7D079DF0404;
Mon, 20 Nov 2017 16:27:50 +0000 (UTC)
(envelope-from rysto32@gmail.com)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com
[IPv6:2607:f8b0:400d:c0d::22b])
(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 35ECD63B00;
Mon, 20 Nov 2017 16:27:50 +0000 (UTC)
(envelope-from rysto32@gmail.com)
Received: by mail-qt0-x22b.google.com with SMTP id a19so15446912qtb.3;
Mon, 20 Nov 2017 08:27:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=BdEPBVGsTAnt7HmmMMYJpoimUChSAmI/wfKBQMKur1s=;
b=ZJreQmLWx4Xz4TIkvvsbDfSok5e3QwGAtZ9ZXgrLoquL8jzz1eJ0YGrSL4xX1nRU6Q
3hcOFesRLj5Sbcox4tfWR3HNoAhDP53V5J3CtABZFwXAiekd1TX0R+3+TuLnKq2lcE1o
9g1jO7/iV0+ZsHRrhMQTSTbqtBdgxTnwsDQZrrC10niw/7yHCXf1VzIq7N/5lKztUU8e
QOdMH40P7r1I8gXFnwPcpLpXkjmDz/sHYHoINQtAjyLhNVM4O5J+JdwnncPT0MoP/MZr
29imVIGGVty4nasdJjH0BpgVoTGxmIaNRMc8wv5qHBvxhK5VLAB6L9Bs4RyN+vT/O2k0
IXrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=BdEPBVGsTAnt7HmmMMYJpoimUChSAmI/wfKBQMKur1s=;
b=MReeKdDjz4nlrC+4PhfXGVXpWJ6nqHM288IPZ2yE+IQ51XXeM2p7ey9OT8ewtROy7P
BkKjLWlueiUllX4VKwZ2ezwh57X1wEomqTNZxDgxuJ/SDX6gz626mePzTRejrkblGGWp
L5hGBwOiXAdL05/HHrSMjLWXeJJtxCJslsMEKOLJH3zc+PT/YNMpcudGebwy7R0RoqNV
ug9tFy1tEKTYqeEq48KSxMVKtJJBivy8U24rYY0SOhTp/GA8bnyz/zvdRglRIX9ZEfxo
acJREVkz/8ZfAnohl6zNFpGz1PK92Ig2EYbRiY95mBYJC5Vl9VvXycTSTvBiA3fW6RqO
SV4Q==
X-Gm-Message-State: AJaThX6SoVvcnmIyxp8UODJwq2cE7zic92oQPINZACYntHSX5ok4mjqj
KW6g45yMtBFy5ZSpXwMsGUEJ+xCrWlTmn1eW2t9krg==
X-Google-Smtp-Source: AGs4zMaaN0ArtVyQzldj/FVMf6OIxA0YjDvJlyaR/3oYyAGHmIcs/SgGt1/tn30vXhjWqp/h61vcEW60qmbgetcAK+o=
X-Received: by 10.200.45.215 with SMTP id q23mr11690057qta.134.1511195269005;
Mon, 20 Nov 2017 08:27:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.39.211 with HTTP; Mon, 20 Nov 2017 08:27:48 -0800 (PST)
In-Reply-To: <8f7eb0e7-29fe-fcf5-7e8a-b509b9c6405b@FreeBSD.org>
References: <8590fa5d-fd06-90c6-8d3e-34c155423720@FreeBSD.org>
<8f7eb0e7-29fe-fcf5-7e8a-b509b9c6405b@FreeBSD.org>
From: Ryan Stone <rysto32@gmail.com>
Date: Mon, 20 Nov 2017 11:27:48 -0500
Message-ID: <CAFMmRNy6VhsByNruN0Dp0CXUF-Lua18XV9x2AiCibNOL6oj2LA@mail.gmail.com>
Subject: =?UTF-8?Q?Re=3A_Intel_I210_=28igb=29_sometimes_consume_all_CPU_on_no?=
=?UTF-8?Q?t=2Dso=2Dbig_traffic_=E2=80=94_need_help=21?=
To: lev@freebsd.org
Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
freebsd-stable <freebsd-stable@freebsd.org>,
Sean Bruno <sbruno@freebsd.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 16:27:50 -0000
Please try the following patch. It should resolve your issue:
https://people.freebsd.org/~rstone/patches/e1000-9k.diff
From owner-freebsd-net@freebsd.org Mon Nov 20 17:30:22 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 49E86DF16F8;
Mon, 20 Nov 2017 17:30:22 +0000 (UTC) (envelope-from lev@FreeBSD.org)
Received: from onlyone.not-for.work (onlyone.not-for.work
[IPv6:2a01:4f8:201:6350::2])
by mx1.freebsd.org (Postfix) with ESMTP id 085F6659EE;
Mon, 20 Nov 2017 17:30:22 +0000 (UTC) (envelope-from lev@FreeBSD.org)
Received: from [192.168.19.110] (unknown [89.113.128.32])
(Authenticated sender: lev@serebryakov.spb.ru)
by onlyone.not-for.work (Postfix) with ESMTPSA id 683E8354;
Mon, 20 Nov 2017 20:30:20 +0300 (MSK)
Reply-To: lev@FreeBSD.org
Subject: =?UTF-8?Q?Re:_Intel_I210_=28igb=29_sometimes_consume_all_CPU_on_not?=
=?UTF-8?Q?-so-big_traffic_=e2=80=94_need_help!?=
To: Ryan Stone <rysto32@gmail.com>
Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
freebsd-stable <freebsd-stable@freebsd.org>
References: <8590fa5d-fd06-90c6-8d3e-34c155423720@FreeBSD.org>
<8f7eb0e7-29fe-fcf5-7e8a-b509b9c6405b@FreeBSD.org>
<CAFMmRNy6VhsByNruN0Dp0CXUF-Lua18XV9x2AiCibNOL6oj2LA@mail.gmail.com>
From: Lev Serebryakov <lev@FreeBSD.org>
Organization: FreeBSD
Message-ID: <f3cb4d54-6a3d-8a2e-ea3f-1680fdb2bfb2@FreeBSD.org>
Date: Mon, 20 Nov 2017 20:30:14 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAFMmRNy6VhsByNruN0Dp0CXUF-Lua18XV9x2AiCibNOL6oj2LA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature";
boundary="5LsCn8k4x5c0vqVlCIDwGuI7TFfA9hVWa"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 17:30:22 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5LsCn8k4x5c0vqVlCIDwGuI7TFfA9hVWa
Content-Type: multipart/mixed; boundary="cT4mjgaW9B95EWDHPp09FSV5WcboFQDve";
protected-headers="v1"
From: Lev Serebryakov <lev@FreeBSD.org>
Reply-To: lev@FreeBSD.org
To: Ryan Stone <rysto32@gmail.com>
Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
freebsd-stable <freebsd-stable@freebsd.org>
Message-ID: <f3cb4d54-6a3d-8a2e-ea3f-1680fdb2bfb2@FreeBSD.org>
Subject: =?UTF-8?Q?Re:_Intel_I210_=28igb=29_sometimes_consume_all_CPU_on_not?=
=?UTF-8?Q?-so-big_traffic_=e2=80=94_need_help!?=
References: <8590fa5d-fd06-90c6-8d3e-34c155423720@FreeBSD.org>
<8f7eb0e7-29fe-fcf5-7e8a-b509b9c6405b@FreeBSD.org>
<CAFMmRNy6VhsByNruN0Dp0CXUF-Lua18XV9x2AiCibNOL6oj2LA@mail.gmail.com>
In-Reply-To: <CAFMmRNy6VhsByNruN0Dp0CXUF-Lua18XV9x2AiCibNOL6oj2LA@mail.gmail.com>
--cT4mjgaW9B95EWDHPp09FSV5WcboFQDve
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 20.11.2017 19:27, Ryan Stone wrote:
> Please try the following patch. It should resolve your issue:
> https://people.freebsd.org/~rstone/patches/e1000-9k.diff
Thank you, I'll try! Really, typically I don't have this problem for
~week after reboot, so results will be later.
--=20
// Lev Serebryakov
--cT4mjgaW9B95EWDHPp09FSV5WcboFQDve--
--5LsCn8k4x5c0vqVlCIDwGuI7TFfA9hVWa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAloTESZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5
NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c
R49sYA/6AnqmaplRTHmGjWXBwY08T0Q0BgmvR7LC7ARBEDBDd0QpFfDMH08XyNWv
loF3eQjVKKdsmyCBFMc0IwdCmMtEseMgxVRBH+YwTSrgSbbBLdN+UYu3O2/gfQhc
XFvmxqEMo8JXFfPyJEDvJRSQs1BvH+5w5m4CWKMIGpvf6q4maCJ4fpbdD3bFA6Wd
GAsaHqNd1Tr64T//Qr9IAZiEQ1EGSdyoS2yWhqi1Wc7cXM8qJnYHMjndFMZkONEF
oX90f8cTq1Bv/9VqgAHXeru4mwpv/ESEjMsoaBzCup1537ipm9cQfGNQ27JmeCol
XWmywsuSW0wwJcIrN9TaxUrnfr0B+s0D6WNiRJ3K4aGPv9Io4TiqyJXyDF+0Dy9G
UEFNrQBzLETSYGcYHlpRdzHB/DnOT/Tq+Zn5IJWHjline2o1nN++DSLXFDY3uFoz
Bu+wBqggM1je6j3S9GM/LDYzUgrkCQsuuOAQEkwuPieyXjdNzKLZJ933c8BmdIBn
sD6bVmpBU2kpk3ie0tFbTqmAPkQZyUcVFw2LDqwDksJ70qivUWPPhnHmnu+GxKKb
Qi22+BBI2Kd1Ey4BM86BxswJXhgT3INHkoZ41EJJyBZmUq2Ls2eBxE6IbDNSNyk8
5CUr0eCvvtwL9HVF/C+ZNcgkRaYUyfzMMT5uKmlDfBFkETdmsEA=
=xo3M
-----END PGP SIGNATURE-----
--5LsCn8k4x5c0vqVlCIDwGuI7TFfA9hVWa--
From owner-freebsd-net@freebsd.org Mon Nov 20 21:26:19 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 24C48DF5EE1
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 20 Nov 2017 21:26:19 +0000 (UTC)
(envelope-from srs0=kikh=cs=sigsegv.be=kristof@codepro.be)
Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
bits))
(Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id B09CE6DE85
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 21:26:18 +0000 (UTC)
(envelope-from srs0=kikh=cs=sigsegv.be=kristof@codepro.be)
Received: from [192.168.228.1]
(ptr-8ripyyh5yvatgv0v6n7.18120a2.ip6.access.telenet.be
[IPv6:2a02:1811:2419:4e02:b5fe:9c82:3f34:4f63])
(Authenticated sender: kp)
by venus.codepro.be (Postfix) with ESMTPSA id EEF4DC621;
Mon, 20 Nov 2017 22:26:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail;
t=1511213176; bh=2pDL3hacsw/xwnITp0IsendOlrcFdBd6FjHKCEaMs+w=;
h=From:To:Cc:Subject:Date:In-Reply-To:References;
b=nsgrTAT3HS9TPp+hCcI79MFbHtvaLr3H2wv60OGzBgYaV7EudMOkbZvo+5p7OnUVy
LCv79NZwnEKT1qUXKnHSKkd8etytGmFj+RzVbqCRJYLhTEjMaOybL4fokOZG4mM8ON
9g995ADl6Iue/czEs1PqxaCVko43J3MGgBkORx2o=
From: "Kristof Provost" <kristof@sigsegv.be>
To: "Catalin Salgau" <csalgau@users.sourceforge.net>
Cc: freebsd-net@freebsd.org
Subject: Re: BPF packet pagesize limit
Date: Mon, 20 Nov 2017 22:26:13 +0100
Message-ID: <A2A39E3C-8A17-4C17-A52D-0EF72F809F99@sigsegv.be>
In-Reply-To: <966f384c-10b4-d018-efb1-68a7064c9521@users.sourceforge.net>
References: <966f384c-10b4-d018-efb1-68a7064c9521@users.sourceforge.net>
MIME-Version: 1.0
X-Mailer: MailMate (2.0BETAr6096)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 21:26:19 -0000
On 19 Nov 2017, at 19:49, Catalin Salgau wrote:
> I'm trying to address the limitation in (upstream) net/vblade that was
> brought up in
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205164
> This is related to writes larger than hw.pagesize but smaller than the
> configured MTU with BPF.
> I traced this to sys/net/bpf.c where calls to bpfwrite() will use
> bpf_movein() which in turn uses m_get2() to allocate a single mbuf.
> This
> will fail if the requested mbuf size is larger than MJUMPAGESIZE
> (defined as PAGE_SIZE on x86). I believe this should use m_getm2() and
> populate multiple mbufs.
> Code in NetBSD explicitly notes that they omit mbuf chaining, but this
> is not documentated behaviour in the man page.
>
Your analysis looks correct.
> Any chance of having this fixed in a supported release, or getting a
> usable/documented workaround?
Can you see if this works for you?
diff --git a/sys/net/bpf.c b/sys/net/bpf.c
index b176856cf35..b9ff40699bb 100644
--- a/sys/net/bpf.c
+++ b/sys/net/bpf.c
@@ -547,9 +547,11 @@ bpf_movein(struct uio *uio, int linktype, struct
ifnet *ifp, struct mbuf **mp,
if (len < hlen || len - hlen > ifp->if_mtu)
return (EMSGSIZE);
- m = m_get2(len, M_WAITOK, MT_DATA, M_PKTHDR);
+ m = m_getm2(NULL, len, M_WAITOK, MT_DATA, M_PKTHDR);
if (m == NULL)
return (EIO);
+ KASSERT(m->m_next == NULL, ("mbuf chains not supported here"));
+
m->m_pkthdr.len = m->m_len = len;
*mp = m;
It’s a little icky to trust that this will produce a single mbuf
rather than a chain, but it appears to be the case. Sadly the rest of
the bpf code (and especially bpf_filter()) really needs the mbuf to have
a single contiguous buffer.
Regards,
Kristof
From owner-freebsd-net@freebsd.org Mon Nov 20 23:35:54 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 92B9CD94373
for <freebsd-net@mailman.ysv.freebsd.org>;
Mon, 20 Nov 2017 23:35:54 +0000 (UTC)
(envelope-from sunxiaoye07@gmail.com)
Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com
[IPv6:2607:f8b0:4003:c0f::230])
(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 5327D72893
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 23:35:54 +0000 (UTC)
(envelope-from sunxiaoye07@gmail.com)
Received: by mail-ot0-x230.google.com with SMTP id s4so9066926ote.4
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 15:35:54 -0800 (PST)
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:cc;
bh=iNKW2W7RyghlNjRMNESJ3vjIK+4noElroYWolDSmNjM=;
b=CHbM2IGu6qSE6yG7BstmXyh5FFaHqPhlHqF0F9a+QHwbVlOeMRqYAM5QbBWebNIDFC
joCx1Z8z/Rg/SVhb5yBwnqkrVdYMSrkHnVl93qoboc/7V6Icjt/7jWOdCftdiBC1qwXT
lo1UsLUyeAhOhPGVhnH0AuEt1iVa/z62r6xJxja0j440P7wliOYonA3p1bCGhm4hR3Yw
CNgq7jmz0696W+6UZGBeeCEb7d40Ve72Z0x1TdBfX5lFKkhgLwsn0VTtIx8qelJ19NPG
d3CeBSvBPOUkoWj3CerDoa8tGS4GPhTrk2o5aFrjXFL4fVWrZrbclbFnkyeU2L/sCH+D
VI2w==
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:cc;
bh=iNKW2W7RyghlNjRMNESJ3vjIK+4noElroYWolDSmNjM=;
b=ZE872F044rMQ1krlUJNtaduCszoLUZjk/n/sx2fTdKsAwiYnzhc4jUL62Wdpd6n4KD
kX1PqDwjvSlXUIVOj1s79Yu26C7+1slUgfC+ndpZ6mp3JlfOybpjr0z/xe1Q7r2RSeWX
CUzqmAxSsvPl7vXuDWVxfcJrAxzbX2qni4L9xnvm2i6vaqo/R2O6lWnnrqwRyg8DN67z
znKSu38RBntlbj1u09U7+UXoQQLCGrGHBPxkEvJWr8bEOfLXeIsxgVtZQ2KAUc/VYl8E
FxdPVXjCtI7z6EcOQ8dMAaUChnXNrdm/kE9Q1Li3BRuq5FteHeF/YY2L7Cc8V7nGeoDv
d8QA==
X-Gm-Message-State: AJaThX5w/4tIGd4g/JY/InPXnkj9mjUMzfbM32wQ+4rxolDUAG6DURR5
mNI8NTkaYLWHxnUHIsrPneUm9SWIuuAA3udb1eo=
X-Google-Smtp-Source: AGs4zMbLoP5aU4CtV/8k89xycvbEQHVppEQjQZGxDbZwAScVUbi7LOFPcgYywsfnLMrVJlthAldsw803iphcq/yIKhI=
X-Received: by 10.157.89.173 with SMTP id u45mr9992245oth.341.1511220953509;
Mon, 20 Nov 2017 15:35:53 -0800 (PST)
MIME-Version: 1.0
Sender: sunxiaoye07@gmail.com
Received: by 10.157.14.167 with HTTP; Mon, 20 Nov 2017 15:35:53 -0800 (PST)
In-Reply-To: <CA+_eA9i5WOiA8j3y8fX65rzDLXEyt2B2wo8pK12jM2ZvEBURYg@mail.gmail.com>
References: <CAJnByzh4Kzp6-DXXcB06QHSBJpHBKhtDnKUn7R+K0A_5VUThyw@mail.gmail.com>
<CA+_eA9i5WOiA8j3y8fX65rzDLXEyt2B2wo8pK12jM2ZvEBURYg@mail.gmail.com>
From: Xiaoye Sun <Xiaoye.Sun@rice.edu>
Date: Mon, 20 Nov 2017 17:35:53 -0600
X-Google-Sender-Auth: T_iUv2h4LTCMwAbzMacQMp5N5Hw
Message-ID: <CAJnByzhv27D_V=kyJjzQPQ28GM8kACKsH87MB5uDKVkQ-aka0g@mail.gmail.com>
Subject: Re: [netmap] when does a packet in the netmap ring send out exactly
To: Vincenzo Maffione <v.maffione@gmail.com>
Cc: FreeBSD Net <freebsd-net@freebsd.org>
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 23:35:54 -0000
Hi,
I found that the tail pointer only moves when the ring has less than half
of the slots available. This prevents me from knowing the accurate time
when the packet in a slot is processed. Is there a way to move the tail
pointer as long as the packet in the slot is processed? Is this a
configurable feature?
Best,
Xiaoye
On Fri, Oct 27, 2017 at 11:52 AM, Vincenzo Maffione <v.maffione@gmail.com>
wrote:
> Hi,
> This is actually a limitation of the netmap API: ring->tail is exposed
> to the user so that it knows it can use the slots in the range
> "[ring->head..ring->tail[" for new transmissions (note that head is
> included, tail excluded, to prevent wraparound). However, there is no
> explicit indication of "up to what slots packets were transmitted".
> For hw NICs, however, ring->tail is an indication of where transmission
> was completed.
> Example:
> 1) at the beginning ring->tail = ring->head = ring->cur = 0
> 2) then your program moves head/cur forward: head = cur = 10
> 3) you call TXSYNC, to submit the packets to the NIC.
> 4) after the TXSYNC call, is very likely that tail is still 0, i.e.
> because no transmission has been completed by the NIC (and no interrupt
> generated).
> 5) say after 20 us you issue another TXSYNC, and in the meanwhile 6
> packets had completed. In this case after TXSYNC you will find tail==5,
> meaning that packets in the slots 0,1,2,3,4 and 5 have been completed. Note
> that also the slot pointed by tail has been completed.
>
> But you are right that there is no way to receive completion notification
> if the queue is not full. You must use TXSYNC to check (by sleeping or busy
> wait) when tail moves forward.
>
> Cheers,
> Vincenzo
>
>
> 2017-10-27 3:06 GMT+02:00 Xiaoye Sun <Xiaoye.Sun@rice.edu>:
>
>> Hi
>>
>> I write a netmap program that sends packets to the network. my program
>> uses one netmap ring and fills the ring slots with packets.
>> My program needs to do something (action A) after a particular packet
>> (packet P) in the ring slot is sent to the network. so the program tracks
>> the position of the tail point and checks if the tail point has moved
>> across the slot I used to put that packet P.
>> However, I found that the tail pointer may not move forward even seconds
>> after the receiver side got packet P.
>> Sometimes the tail pointer never moves forward until the TX ring is full.
>> I try ioctl(NIOCTXSYNC), however, it cannot 100% solve the problem.
>>
>> My question is that is there a way to make the TX ring empty as early as
>> possible so that I can know when my packet is sent out. or is there
>> another
>> way to know when the packet in the slot is sent to the network/NIC
>> physical
>> queue?
>>
>> I am using Linux 3.16.0-4-amd64.
>>
>> Thanks!
>>
>> Best,
>> Xiaoye
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>
>
>
>
> --
> Vincenzo Maffione
>
From owner-freebsd-net@freebsd.org Tue Nov 21 00:11:47 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 4FDEEDB83FE
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 00:11:47 +0000 (UTC)
(envelope-from rizzo.unipi@gmail.com)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com
[IPv6:2607:f8b0:4001:c06::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 159E173A81
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 00:11:47 +0000 (UTC)
(envelope-from rizzo.unipi@gmail.com)
Received: by mail-io0-x22f.google.com with SMTP id g73so17566979ioj.8
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 16:11:47 -0800 (PST)
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:cc;
bh=S8HAmXH9yuuFJK3rWcsNLF6IlkMnqYfJqKtb7gkzZ2w=;
b=JETbtoPJlJJEz9WUi1LohAX7HHf7D4Rx1tI3zCPihb4lM0829BOdPaauqv1D21475g
dzMHeuL4JsZaYGyWjUrUt8pFvtwVz99VtdC+zzdhqSVz7exrytfzvPOkc2ei8UFcwBDW
rlS2X9MkrA5nvGj63O753x1hwBpHf85vk+j6wb+dt4In07v42sVyszwdU1xul8DGMVIt
h0jI2hGD5gA5OiPLKEbcsEPx+DPb45OgJ8AD3MPy9YTVT311WrgeCn69QH8TyxFLY7jx
WTJ+NIezAc5hYPii3ae9Xo4XotAV0KDGeGbQhL2ZcR1T2wi0xLdZdVie3P8L80ECWK7Z
AeJA==
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:cc;
bh=S8HAmXH9yuuFJK3rWcsNLF6IlkMnqYfJqKtb7gkzZ2w=;
b=s4qgeV2le7sxwqLL8Ze7ee5yh2OJ+Q0UFXrt81TwgC2bAukwZjw9dpdAayEUz2xdkr
1FeG+yEGEyfynGqaPjh4SNIWz+IOYgNpmjwr+IcBwW8DiAAgJnFf6P/+xQLRYuopkXQ4
13SlgcDtp3W7l64HNvWpjGhDUTropmb0eOgT+WtRUInZ1wcPMO2xdRg2bkeyKkVLOhSH
IPm+v9O9ZrYIc9DvAtTIguW9K6Vab5jokR0htgrJe9V5G+h4hgegJNxwTidNUpkWgBja
tf7pHTYwZvHNTzwbDrjDC41kDo4qanTZwgdkSt6xv9ObIvFiew5+jzNcO8v28Pbio1kz
FBjw==
X-Gm-Message-State: AJaThX6rMtuVNCAAvFYNdqJxhR9eqvR7/7pFZDVXJhEskUmBtUAhnhCe
y+6mhT9llF6WdyBNmnfa6UqFKoZlho6YDKpekJU=
X-Google-Smtp-Source: AGs4zMZebZ4pG8gNb+ONGvqTk2OXor4MJ3ggtvJk7aEmgnQLwoDwoKLPKXW0KlWUstz9SQQB+Knp/ruFBOPEePtyZbA=
X-Received: by 10.107.182.7 with SMTP id g7mr15524664iof.39.1511223104798;
Mon, 20 Nov 2017 16:11:44 -0800 (PST)
MIME-Version: 1.0
Sender: rizzo.unipi@gmail.com
Received: by 10.107.141.201 with HTTP; Mon, 20 Nov 2017 16:11:44 -0800 (PST)
In-Reply-To: <CAJnByzhv27D_V=kyJjzQPQ28GM8kACKsH87MB5uDKVkQ-aka0g@mail.gmail.com>
References: <CAJnByzh4Kzp6-DXXcB06QHSBJpHBKhtDnKUn7R+K0A_5VUThyw@mail.gmail.com>
<CA+_eA9i5WOiA8j3y8fX65rzDLXEyt2B2wo8pK12jM2ZvEBURYg@mail.gmail.com>
<CAJnByzhv27D_V=kyJjzQPQ28GM8kACKsH87MB5uDKVkQ-aka0g@mail.gmail.com>
From: Luigi Rizzo <rizzo@iet.unipi.it>
Date: Mon, 20 Nov 2017 16:11:44 -0800
X-Google-Sender-Auth: gnqJjgtMrj_IoESYpCp6AJ-zMpM
Message-ID: <CA+hQ2+h0QEx3LPvFGNZv5ZvBJOJ-X0go-=c3V0gr6FRhe7icXA@mail.gmail.com>
Subject: Re: [netmap] when does a packet in the netmap ring send out exactly
To: Xiaoye Sun <Xiaoye.Sun@rice.edu>
Cc: Vincenzo Maffione <v.maffione@gmail.com>,
FreeBSD Net <freebsd-net@freebsd.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 00:11:47 -0000
Hi,
I think if you call the TXSYNC ioctl without advancing the head
pointer, then the tail is advanced
as much as possible.
Cheers
luigi
On Mon, Nov 20, 2017 at 3:35 PM, Xiaoye Sun <Xiaoye.Sun@rice.edu> wrote:
> Hi,
>
> I found that the tail pointer only moves when the ring has less than half
> of the slots available. This prevents me from knowing the accurate time
> when the packet in a slot is processed. Is there a way to move the tail
> pointer as long as the packet in the slot is processed? Is this a
> configurable feature?
>
> Best,
> Xiaoye
>
> On Fri, Oct 27, 2017 at 11:52 AM, Vincenzo Maffione <v.maffione@gmail.com>
> wrote:
>
>> Hi,
>> This is actually a limitation of the netmap API: ring->tail is exposed
>> to the user so that it knows it can use the slots in the range
>> "[ring->head..ring->tail[" for new transmissions (note that head is
>> included, tail excluded, to prevent wraparound). However, there is no
>> explicit indication of "up to what slots packets were transmitted".
>> For hw NICs, however, ring->tail is an indication of where transmission
>> was completed.
>> Example:
>> 1) at the beginning ring->tail = ring->head = ring->cur = 0
>> 2) then your program moves head/cur forward: head = cur = 10
>> 3) you call TXSYNC, to submit the packets to the NIC.
>> 4) after the TXSYNC call, is very likely that tail is still 0, i.e.
>> because no transmission has been completed by the NIC (and no interrupt
>> generated).
>> 5) say after 20 us you issue another TXSYNC, and in the meanwhile 6
>> packets had completed. In this case after TXSYNC you will find tail==5,
>> meaning that packets in the slots 0,1,2,3,4 and 5 have been completed. Note
>> that also the slot pointed by tail has been completed.
>>
>> But you are right that there is no way to receive completion notification
>> if the queue is not full. You must use TXSYNC to check (by sleeping or busy
>> wait) when tail moves forward.
>>
>> Cheers,
>> Vincenzo
>>
>>
>> 2017-10-27 3:06 GMT+02:00 Xiaoye Sun <Xiaoye.Sun@rice.edu>:
>>
>>> Hi
>>>
>>> I write a netmap program that sends packets to the network. my program
>>> uses one netmap ring and fills the ring slots with packets.
>>> My program needs to do something (action A) after a particular packet
>>> (packet P) in the ring slot is sent to the network. so the program tracks
>>> the position of the tail point and checks if the tail point has moved
>>> across the slot I used to put that packet P.
>>> However, I found that the tail pointer may not move forward even seconds
>>> after the receiver side got packet P.
>>> Sometimes the tail pointer never moves forward until the TX ring is full.
>>> I try ioctl(NIOCTXSYNC), however, it cannot 100% solve the problem.
>>>
>>> My question is that is there a way to make the TX ring empty as early as
>>> possible so that I can know when my packet is sent out. or is there
>>> another
>>> way to know when the packet in the slot is sent to the network/NIC
>>> physical
>>> queue?
>>>
>>> I am using Linux 3.16.0-4-amd64.
>>>
>>> Thanks!
>>>
>>> Best,
>>> Xiaoye
>>> _______________________________________________
>>> freebsd-net@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>>
>>
>>
>>
>> --
>> Vincenzo Maffione
>>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
--
-----------------------------------------+-------------------------------
Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL +39-050-2217533 . via Diotisalvi 2
Mobile +39-338-6809875 . 56122 PISA (Italy)
-----------------------------------------+-------------------------------
From owner-freebsd-net@freebsd.org Tue Nov 21 03:15:20 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 89E05DDBAEA
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 03:15:20 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 778FE7B459
for <freebsd-net@FreeBSD.org>; Tue, 21 Nov 2017 03:15:20 +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 vAL3FJi8035115
for <freebsd-net@FreeBSD.org>; Tue, 21 Nov 2017 03:15:20 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223767] tun device allows modification of if_type to any value
causing a page fault and panic
Date: Tue, 21 Nov 2017 03:15:20 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 10.4-STABLE
X-Bugzilla-Keywords: patch
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords assigned_to
Message-ID: <bug-223767-2472-ipTHqPlmN3@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223767-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223767-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 03:15:20 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223767
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-net@freebsd.org Tue Nov 21 03:43:08 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 3E250DDCBB3
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 03:43:08 +0000 (UTC)
(envelope-from sunxiaoye07@gmail.com)
Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com
[IPv6:2607:f8b0:4003:c0f::234])
(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 F13437C2B3
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 03:43:07 +0000 (UTC)
(envelope-from sunxiaoye07@gmail.com)
Received: by mail-ot0-x234.google.com with SMTP id j29so9416702oth.13
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 19:43:07 -0800 (PST)
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:cc;
bh=OYNUtopu+psxOIbWViqfrCHojFF+0VVW0I9KDOwlHSs=;
b=Lzx75WOXbRPJ/WcuIYXZ5JZ+1uECDpdtqXzRzEO1Y0DJchBjjsFGMut7nKOOTsu3dV
6Dh8ex8pVLXq4uDYljG1ZBqjDptixT7nL167kvuHDG6qg+KvHGs2l46A59S7EFQDHKBA
FQtXmGM/RzKKCOnAb+Ip3XkyikDKYu0KcSmrLXE1XUZ2xiYrvduS4StCH7sMpEmfQsRE
6Kc0Uo7jDuKyCaFvU8oDvTnLYHKvLyIaPeqdmccVaPFgDE7ZZmn+VN9cDa9ocvsQnAvL
pa48sfvQj9j+dyq729TIAOAx/qN2tzxxg1vFWhZC2uipC+qZB1g+ESLieBz4u1ZFNvHf
XG1A==
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:cc;
bh=OYNUtopu+psxOIbWViqfrCHojFF+0VVW0I9KDOwlHSs=;
b=dSb0AS0hqOptUuQ2J6Cv4JPS4C8wGql2lg8XzX8TM+Qmc02tQqpynUenG73dxKwm/u
Zym8cUKqDz/b/XjaixhnfbgV2HbUQOOxHySaUki0D8TK2ZGnve7tlH4KROLAvV1PausI
tddGlqqQ3uveo1L2hBGFhVFePV0TROEUgaxMhumxsV/VR38rp6uvdku7XgFkWsEV77Py
y2R8XhYmUaRgbyzfaVbLUy1VDY4/IjeSA3BIk5/KQ9W4RznCLsnAiDrXJfGTeODqI+YL
MOr1ZiLkpEzKGYC+wI3kibbcKnklLyD655G00urei/sF3MPa4IiIl4YaJvJXvsSDh6U4
6okw==
X-Gm-Message-State: AJaThX4RUZb0LFu/uarIK1E7Ilp8L4QsACNC82IWPTujcJ78uDNuvs6x
iB6BDqglRSjUumJtsOjEyCAeZ2MHDDXfiQj9ufw=
X-Google-Smtp-Source: AGs4zMZiCvauiwpik5UlzZmAd/iUqOKrqzcJ1y+k32UOgzD6+o+ZD6IjSN1uc5OgUHOJmPHhScyr34jrlECMiMqYrjI=
X-Received: by 10.157.27.101 with SMTP id l92mr9421679otl.315.1511235787161;
Mon, 20 Nov 2017 19:43:07 -0800 (PST)
MIME-Version: 1.0
Sender: sunxiaoye07@gmail.com
Received: by 10.157.14.167 with HTTP; Mon, 20 Nov 2017 19:43:06 -0800 (PST)
In-Reply-To: <CA+hQ2+h0QEx3LPvFGNZv5ZvBJOJ-X0go-=c3V0gr6FRhe7icXA@mail.gmail.com>
References: <CAJnByzh4Kzp6-DXXcB06QHSBJpHBKhtDnKUn7R+K0A_5VUThyw@mail.gmail.com>
<CA+_eA9i5WOiA8j3y8fX65rzDLXEyt2B2wo8pK12jM2ZvEBURYg@mail.gmail.com>
<CAJnByzhv27D_V=kyJjzQPQ28GM8kACKsH87MB5uDKVkQ-aka0g@mail.gmail.com>
<CA+hQ2+h0QEx3LPvFGNZv5ZvBJOJ-X0go-=c3V0gr6FRhe7icXA@mail.gmail.com>
From: Xiaoye Sun <Xiaoye.Sun@rice.edu>
Date: Mon, 20 Nov 2017 21:43:06 -0600
X-Google-Sender-Auth: q9QZ2dsPVPz9gfNTPs0Ctb6LHw4
Message-ID: <CAJnByzg-=9Aqy9S5ZuFFyLQgCJBtZ7MrDAuf5ccsVzj68=dSTw@mail.gmail.com>
Subject: Re: [netmap] when does a packet in the netmap ring send out exactly
To: Luigi Rizzo <rizzo@iet.unipi.it>
Cc: Vincenzo Maffione <v.maffione@gmail.com>,
FreeBSD Net <freebsd-net@freebsd.org>
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 03:43:08 -0000
Hi Luigi,
Thanks!
I was using the most recent netmap on Github and I believe the tail pointer
only moves forward when there are less than half of the total slots
available in the netmap ring.
Then I switch to the version of v11.3
<https://github.com/luigirizzo/netmap/tree/v11.3>, it behaves as what you
described.
Linux Kernel: 3.16.0-4-amd64
Best,
Xiaoye
On Mon, Nov 20, 2017 at 6:11 PM, Luigi Rizzo <rizzo@iet.unipi.it> wrote:
> Hi,
> I think if you call the TXSYNC ioctl without advancing the head
> pointer, then the tail is advanced
> as much as possible.
>
> Cheers
> luigi
>
> On Mon, Nov 20, 2017 at 3:35 PM, Xiaoye Sun <Xiaoye.Sun@rice.edu> wrote:
> > Hi,
> >
> > I found that the tail pointer only moves when the ring has less than half
> > of the slots available. This prevents me from knowing the accurate time
> > when the packet in a slot is processed. Is there a way to move the tail
> > pointer as long as the packet in the slot is processed? Is this a
> > configurable feature?
> >
> > Best,
> > Xiaoye
> >
> > On Fri, Oct 27, 2017 at 11:52 AM, Vincenzo Maffione <
> v.maffione@gmail.com>
> > wrote:
> >
> >> Hi,
> >> This is actually a limitation of the netmap API: ring->tail is exposed
> >> to the user so that it knows it can use the slots in the range
> >> "[ring->head..ring->tail[" for new transmissions (note that head is
> >> included, tail excluded, to prevent wraparound). However, there is no
> >> explicit indication of "up to what slots packets were transmitted".
> >> For hw NICs, however, ring->tail is an indication of where transmission
> >> was completed.
> >> Example:
> >> 1) at the beginning ring->tail = ring->head = ring->cur = 0
> >> 2) then your program moves head/cur forward: head = cur = 10
> >> 3) you call TXSYNC, to submit the packets to the NIC.
> >> 4) after the TXSYNC call, is very likely that tail is still 0, i.e.
> >> because no transmission has been completed by the NIC (and no interrupt
> >> generated).
> >> 5) say after 20 us you issue another TXSYNC, and in the meanwhile 6
> >> packets had completed. In this case after TXSYNC you will find tail==5,
> >> meaning that packets in the slots 0,1,2,3,4 and 5 have been completed.
> Note
> >> that also the slot pointed by tail has been completed.
> >>
> >> But you are right that there is no way to receive completion
> notification
> >> if the queue is not full. You must use TXSYNC to check (by sleeping or
> busy
> >> wait) when tail moves forward.
> >>
> >> Cheers,
> >> Vincenzo
> >>
> >>
> >> 2017-10-27 3:06 GMT+02:00 Xiaoye Sun <Xiaoye.Sun@rice.edu>:
> >>
> >>> Hi
> >>>
> >>> I write a netmap program that sends packets to the network. my program
> >>> uses one netmap ring and fills the ring slots with packets.
> >>> My program needs to do something (action A) after a particular packet
> >>> (packet P) in the ring slot is sent to the network. so the program
> tracks
> >>> the position of the tail point and checks if the tail point has moved
> >>> across the slot I used to put that packet P.
> >>> However, I found that the tail pointer may not move forward even
> seconds
> >>> after the receiver side got packet P.
> >>> Sometimes the tail pointer never moves forward until the TX ring is
> full.
> >>> I try ioctl(NIOCTXSYNC), however, it cannot 100% solve the problem.
> >>>
> >>> My question is that is there a way to make the TX ring empty as early
> as
> >>> possible so that I can know when my packet is sent out. or is there
> >>> another
> >>> way to know when the packet in the slot is sent to the network/NIC
> >>> physical
> >>> queue?
> >>>
> >>> I am using Linux 3.16.0-4-amd64.
> >>>
> >>> Thanks!
> >>>
> >>> Best,
> >>> Xiaoye
> >>> _______________________________________________
> >>> freebsd-net@freebsd.org mailing list
> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
> >>>
> >>
> >>
> >>
> >> --
> >> Vincenzo Maffione
> >>
> > _______________________________________________
> > freebsd-net@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
>
>
> --
> -----------------------------------------+-------------------------------
> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione
> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
> TEL +39-050-2217533 . via Diotisalvi 2
> Mobile +39-338-6809875 . 56122 PISA (Italy)
> -----------------------------------------+-------------------------------
>
From owner-freebsd-net@freebsd.org Tue Nov 21 06:45:32 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 347A2DE4E95
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 06:45:32 +0000 (UTC)
(envelope-from alex@zagrebin.ru)
Received: from mail.zagrebin.ru (srv0.zagrebin.ru [IPv6:2001:470:1f15:30e::1])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
bits)) (Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id DFF142A9A;
Tue, 21 Nov 2017 06:45:31 +0000 (UTC)
(envelope-from alex@zagrebin.ru)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru
; s=mail;
h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:
In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=EOmFyD/ACsjWHsgrhzaj0BjE6XCtBfeFUAuMQtezTfY=; b=fSgxyHcsqnS/BgMQSU8jK0r6ru
UYrAtS/se15tcpYPsA9/5eDLsliK+R5WEnOMJuKHQZdJPuGb5xqu8wrWIvZkSK359fGc9q0WE0yyh
5tUyD6cxR+nN49R0WuA/WnH4FuZ1R0Wskec+g0BGqzHsMtM6SsdrflEMWFI57Yt0WkfjqClFHinYe
ltOVJCr3Jwq9fNF3lgp9A41sEK4+afxK8eczzJ5tKaFT+5koJSsFCnXsW5bGW1sIwdKnfeW00vXUC
bVvaIT+QzGikFEJapuVp9Ae1rWZitIlVJOC+687Y/jVEon8q5urwRmExqaKvUyKUOhOwcKyQVn8dN
G+ZloAFw==;
Received: from [2001:470:1f15:30e::2] (helo=vm2.home.zagrebin.ru)
by mail.zagrebin.ru with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.89 (FreeBSD)) (envelope-from <alex@zagrebin.ru>)
id 1eH2JD-000LCg-Iw; Tue, 21 Nov 2017 09:45:27 +0300
Date: Tue, 21 Nov 2017 09:45:27 +0300
From: Alexander Zagrebin <alex@zagrebin.ru>
To: freebsd-net@freebsd.org
Cc: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= <des@des.no>, Andriy Gapon
<avg@FreeBSD.org>
Subject: Re: local_unbound, resolvconf, vpn
Message-ID: <20171121094527.0952f3b9@vm2.home.zagrebin.ru>
In-Reply-To: <86tvxp6jja.fsf@desk.des.no>
References: <5689438f-6734-6b57-b700-d70ee2b7578a@FreeBSD.org>
<86a7zq8er7.fsf@desk.des.no>
<8a098542-9f04-3a41-76f1-e463e3e89c99@FreeBSD.org>
<86y3n16mez.fsf@desk.des.no>
<37f97bc5-5187-2700-5811-a9cf173eeb10@FreeBSD.org>
<86tvxp6jja.fsf@desk.des.no>
X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.1)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 06:45:32 -0000
Hi!
Also I have to notice that there is another issue with the default
local_unbound setup:
by default unbound uses syslog for logging, but usually the
local_unbound service starts before syslogd and so logging doesn't work
until local_unbound will be reloaded.
So it's looks reasonable to use logging to file by default.
As unbound runs in chroot, the log file has to be inside of
the /var/unbound directory, but now this directory contains a config
files.
I suggest to change the /var/unbound structure to be more hier(7)
friendly.
For example,
/var
/unbound
/etc - unbound configuration files
/conf.d - additional configuration files
/var
/log - unbound log files
--
Alexander Zagrebin
From owner-freebsd-net@freebsd.org Tue Nov 21 06:51:04 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 426C4DE50B9
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 06:51:04 +0000 (UTC)
(envelope-from sunxiaoye07@gmail.com)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com
[IPv6:2607:f8b0:4003:c06::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 E521F2DB3
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 06:51:03 +0000 (UTC)
(envelope-from sunxiaoye07@gmail.com)
Received: by mail-oi0-x22c.google.com with SMTP id d93so142311oic.4
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 22:51:03 -0800 (PST)
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:cc;
bh=bid6bPhf4LH6PwF9oU5F0FyS2HqpAC+vOVVjFz5fw+k=;
b=U8Xdh7ZAGWSIQodQEs7+q9JFox3/0QCwAAjY1ts2wddSoDrm47qB6Em3IfPMWz6seM
fMA/BKGmhCsI0L0tYUj4XcUp9CvxgYGaPf+U57h+vLzyZw5NitadgHrMa8sHAz9AH4fl
HoNZw1O2sx7JM7kbcwuxGWabGvZ8AeIBxTAtic9MQXZP2jxZZuq9+OCrDy4dfRGD7ZSd
a7pyg7q/MokNj7ydldYEgEj6cY/yis/ZyfAemxH9kOavjmq+lvyZDIniAQzV5eJmiBwt
o7MiAeZOjB6SKHp34ytxrZC6uflOW0ZUsyAfxlzo8728Kkvv4F7XvL+WnhbOSGwvoymZ
hK4w==
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:cc;
bh=bid6bPhf4LH6PwF9oU5F0FyS2HqpAC+vOVVjFz5fw+k=;
b=dOXT5rIC/AIGeL7wK48euVpq+snBR1lHXv8Z8HGDbMB/ED3+MyYpXwsBM4R/eOZSdG
3qUmJTdkOLtLeKnek9mYza7HO/feRUTBFEGdcqOMvnmqMg6aRYDSG+ZpsQiRrFs0dE2X
usc99EwZxLIG14ocOiDf8iixMmh60MVZjVHqKsTjf3KVOZQ5gDBZFT44hTRFb6k/Xo9A
2Y8ElG5C8hq+HnW1xY3gt4sz+bGUCvnv/ullc+BPA7HgtSpeQoK/ooQVG+NP8VDQsveM
g1y4HW9wJbWcKX49KrVmqbPbV0TUDD+BvKO16HJ9Cg6zvWPB4+IynCbUO0HLEYrTkGvw
Oo+g==
X-Gm-Message-State: AJaThX7R45n6YgtEUXZ6cXGJBtZXWTvO2dVD4mZFZzrNEnzYab6Autsf
ylckJfLNaLyUNG99G20cu8pgeeC5ow5E7DdpRlYMbg==
X-Google-Smtp-Source: AGs4zMYoDFoOHPlPtSW+lugc2pBRs8FJLVuN2Qsa3DLFNERFmPyleT8UaFGuaIfnjshT1PPA+9H29TFlvwPez7uMMr0=
X-Received: by 10.202.173.207 with SMTP id w198mr640170oie.12.1511247062718;
Mon, 20 Nov 2017 22:51:02 -0800 (PST)
MIME-Version: 1.0
Sender: sunxiaoye07@gmail.com
Received: by 10.157.14.167 with HTTP; Mon, 20 Nov 2017 22:51:02 -0800 (PST)
In-Reply-To: <CAJnByzg0PCXCyjnypS_2+RhKB0mf_4s8X1niFiyfedaCLUku7Q@mail.gmail.com>
References: <CAJnByzj6Dj3vouZ2NbxqvCV-2-7TVtTR4FaWKuCFaaRN2X+yAA@mail.gmail.com>
<CALgsdbd3XuE3wMYp4ey+1aer+HSVNojLYoVqwqTBPAXXdf9i+Q@mail.gmail.com>
<CAJnByzirLXdCe-kwHV2s_E6ytGJG0Dth=0Ms12RrEk7FK_+8Og@mail.gmail.com>
<CA+hQ2+gMWY0eabjHGw0=PJCAkS-wO=RBrN5brSbaqWc3_AOYoQ@mail.gmail.com>
<CAJnByziBS8o6LtmpUrUu5xtRUd008Z2hnCsp=WVFv35r2J0rHw@mail.gmail.com>
<CA+hQ2+im9nFfYnqDS2HgRbAzdf5D0iaLCmCYhfXQVVRMouUFuw@mail.gmail.com>
<CAJnByzht-qfDcm8oEg1aSRyVBZ1ygPvc2eMuoyJcq4geueTZ0Q@mail.gmail.com>
<CA+hQ2+iERgWJ=cdFB-cByfT3r11T1kKr-5HiuCYZY-rxbjf=XA@mail.gmail.com>
<CAJnByziDzdR2C6DcSRNPtrWACLq0XFpe4X1Ek9yXtFP9ivqWQw@mail.gmail.com>
<CA+hQ2+hjnuGo1xKgc8CQ7gP35tiaZG7+roZBmX8aBgb8qWnLgg@mail.gmail.com>
<CAJnByzh-VrRZeYdpkRFtCUGEN_arFBkemcN7byb51XV6UPswyg@mail.gmail.com>
<CA+hQ2+iMw3kxjpcZy77vgOEsfk2UY0-farh9C8RKXZHMU7D8kw@mail.gmail.com>
<CAJnByzgsuNBhdfPJsGrrHcU79xjK+dq2RENgUkbZcehFm8MUxg@mail.gmail.com>
<CAJnByzgNZ9YsYd7tBgYxiQPvuS_VZbhZNGvsPS-0apCDga7XFA@mail.gmail.com>
<CANpwN=uHk-VwOoFz7NaPE9A-0B=MAapqxJ-uyCBtn=oMdacYnw@mail.gmail.com>
<CAJnByzgjEEAzmWZu7BsSWHXmpjUtZcqXFGN8umCqmvgME1Jv+A@mail.gmail.com>
<CANpwN=tfqitQW0BTXA7bU+TfmP8=wr7gE8wAP=hjAamjD7ny9Q@mail.gmail.com>
<CAJnByzi5WHHvwcrmEOkJOHf5SJekbTtQoUgLmPbMtwTotc8mzA@mail.gmail.com>
<CAJnByzhJnrmiwiLEEQV0meg7+DnLJ6Jq_J=6L=35Z9Lgw1GcyA@mail.gmail.com>
<CA+hQ2+jTXyYdN4N4aWOkDdkBr+D3quocHn+c8MA+xc9yLs9V4w@mail.gmail.com>
<CAJnByzg0PCXCyjnypS_2+RhKB0mf_4s8X1niFiyfedaCLUku7Q@mail.gmail.com>
From: Xiaoye Sun <Xiaoye.Sun@rice.edu>
Date: Tue, 21 Nov 2017 00:51:02 -0600
X-Google-Sender-Auth: wpRnucjkSHAA1jwatk8lmpQ9MaI
Message-ID: <CAJnByzipicNHhmw0kGq0cXnfgXqq1xP0aJ4dqr12SryBV1Ny3w@mail.gmail.com>
Subject: Re: swaping ring slots between NIC ring and Host ring does not always
success
To: Luigi Rizzo <rizzo@iet.unipi.it>
Cc: Victor Detoni <victordetoni@gmail.com>,
Pavel Odintsov <pavel.odintsov@gmail.com>,
"freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 06:51:04 -0000
Hi,
Recently I found another problem with netmap. I think this new problem
could be related to the problems in this threads so I just post the new
problem here.
In my setup, I have a sender program having a netmap ring (a pair of
RX/TX ring) for the NIC and a ring for the host stack. The sender program
puts customized packets (each packet has a unique sequence number and the
sender sends the packet in a sequence number increasing order) to the NIC
TX ring directly and also forwards the packets from the host RX ring to the
NIC TX ring using "zerocopy" by swapping the buffer indices.
However, the receiver sees duplicated customized packets. For example, in
the case where the ring size is 32 (32 slots in a ring) the order of the
sequence numbers the receiver see is 1,2,3,4,5,...,68,69,*70*
,71,72,73,...,99,100,*70*,101,102,103,... . An interesting thing I found is
that the "gaps" between these two duplicated packets (70 in the example)
are always a number very close to the ring size, 32 in this example. In my
experiment, I use a ring with 4096 slots and the gap is always more than
4090 and close to 4096. I verified that this duplication happens due to the
sender, not the receiver. Assuming my sender's implementation is correct,
then this duplication may happen in netmap and the NIC driver (ixgbe).
Thinking back to the original problem in this post, I think these problems
may be related. It seems to me that there could be multiple threads pulling
the packets from the NIC TX ring (or the thread moved to other CPUs when
the problem occurs) and these threads may run on different cores so that
the outdated content in the buffer may be sent out when new content is
written to the buffer.
I am wondering if there is a way to pin the NIC driver of the netmap module
to a specific core. or is there a way to know the root of such problem?
Best,
Xiaoye
On Wed, Feb 10, 2016 at 10:18 AM, Xiaoye Sun <Xiaoye.Sun@rice.edu> wrote:
> Hi Luigi,
>
> Thanks Luigi!
> Pinning the process to one CPU core solves the reorder problem!!!
> Let me check if the duplicated packet problem is solved also.
>
> Thanks!
>
> Best,
> Xiaoye
>
> On Wed, Feb 10, 2016 at 7:21 AM, Luigi Rizzo <rizzo@iet.unipi.it> wrote:
>
>> On Tue, Feb 9, 2016 at 1:12 PM, Xiaoye Sun <Xiaoye.Sun@rice.edu> wrote:
>> > Hi Luigi,
>> >
>> > Have you seen the previous email. any comments?
>>
>> Hi,
>> to summarize, you are seeing reordering when
>> reinjecting packets into the host stack from bridge.c
>>
>> On Linux, the NIOCTXSYNC towards the host stack calls netif_rx() one
>> packet at a time (on freebsd that would be ifp->if_input()), and
>> the calls are synchronous.
>>
>> In order to get reordering, you should have the following
>> sequence of events:
>>
>> 1. bridge.c calls ioctl(NIOCTXSYNC)
>> 2. netif_rx() queues packet instead of dispatching them to the socket
>> 3. bridge.c builds another batch and calls ioctl(NIOCTXSYNC)
>> 4. netif_rx() passes packets to the socket overtaking those in #2
>>
>> I don't know whether netif_rx() can defer
>> processing and how to prevent that.
>> If this is the problem,
>> one thing you could try is pin the bridge process
>> to a specific core and see if that makes the problem
>> disappear.
>>
>> cheers
>> luigi
>>
>> >
>> > On Fri, Feb 5, 2016 at 3:29 PM, Xiaoye Sun <Xiaoye.Sun@rice.edu> wrote:
>> >>
>> >> Hi Victor,
>> >> Thanks for the help. The command you provided worked perfectly for me.
>> >>
>> >> Hi Luigi,
>> >>
>> >> Thanks for your clarification.
>> >>
>> >> The experiment I did was NOT running on 3 nodes. They ran on two nodes.
>> >> node 1 ran [1. sender]; node 2 ran [2. bridge.c] and [3. receiver (not
>> using
>> >> netmap)]; [2. bridge.c ] saw packets inorder. [3. receiver] saw packets
>> >> out-of-order. I saw replication packets (even corrupted packets) in the
>> >> setup I mentioned in my first email in this threads. I did not see
>> >> replication packet in the sender-bridge-receiver setup. Let's solve the
>> >> reorder problem first and then solve the replication packet problem.
>> >>
>> >> I also tried the experiment setup having 3 nodes running sender,
>> bridge,
>> >> receiver( both non-netmap based and netmap based XYZ) respectively. In
>> the 3
>> >> nodes experiment, there is NO packet reorder no any node. The
>> difference
>> >> between the 2 nodes experiment and the 3 nodes experiment is that in
>> the
>> >> bridge of node 2 in the 2-nodes experiment the bridge interact with
>> the host
>> >> stack, while netmap does not interact with host stack in the 3-node
>> >> experiment.
>> >>
>> >> This makes me make the conclusion that there might be some problem with
>> >> the interaction between netmap and host stack. What is your opinion?
>> >>
>> >> Thanks!
>> >>
>> >> Xiaoye
>> >>
>> >> On Thu, Feb 4, 2016 at 6:26 PM, Victor Detoni <victordetoni@gmail.com>
>> >> wrote:
>> >>>
>> >>> I'm sorry, I made mistake. To workaround this try `ip link set $IFACE
>> >>> promisc on`
>> >>>
>> >>>
>> >>>
>> >>> On Thu, Feb 4, 2016 at 10:04 PM, Xiaoye Sun <Xiaoye.Sun@rice.edu>
>> wrote:
>> >>>>
>> >>>> Yes. all the interfaces are up. Are you able to get ARP request when
>> the
>> >>>> interfaces are down?
>> >>>>
>> >>>>
>> >>>> On Thursday, February 4, 2016, Victor Detoni <victordetoni@gmail.com
>> >
>> >>>> wrote:
>> >>>>>
>> >>>>> Both interfaces are up? Like ifconfig... up
>> >>>>>
>> >>>>> I had this the same problem and I solve with commands above
>> >>>>>
>> >>>>> Em quinta-feira, 4 de fevereiro de 2016, Xiaoye Sun
>> >>>>> <Xiaoye.Sun@rice.edu> escreveu:
>> >>>>>>
>> >>>>>> Hi Luigi,
>> >>>>>>
>> >>>>>> Thanks for your explanation.
>> >>>>>>
>> >>>>>> I used three machines to do this experiment. They are directly
>> >>>>>> connected.
>> >>>>>>
>> >>>>>> [(machine1) eth1]---[eth2 (machine2) eth3]---[eth4 (machine3)].
>> >>>>>>
>> >>>>>> First, I tried to run bridge.c on machine2 using the command
>> *bridge
>> >>>>>> -i
>> >>>>>> netmap:eth2 -i netmap:eth3*. (sender receiver or XYZ were not
>> running
>> >>>>>> on
>> >>>>>> machine 1or3)
>> >>>>>>
>> >>>>>> For my understanding, in this setup, machine2 will be transparent
>> to
>> >>>>>> machine1&3 since it forwards packet from its eth2 to eth3 and vice
>> >>>>>> versa
>> >>>>>> without any modification to the packets.
>> >>>>>>
>> >>>>>> I tried to ping machine 3 from machine 1 using the command like
>> *ping
>> >>>>>> 10.11.10.3*. However, it still does not success.
>> >>>>>> This is because that before machine1 sends ping message to
>> machine3,
>> >>>>>> it
>> >>>>>> will first send a ARP request message to get the mac address of
>> >>>>>> machine3.
>> >>>>>> machine3 gets that ARP request, and send the reply back (I use
>> tcpdump
>> >>>>>> to
>> >>>>>> verify that machine3 gets the ARP request and send out the ARP
>> reply).
>> >>>>>> However, machine1 does not get the ARP reply.
>> >>>>>>
>> >>>>>> I checked that the bridge can only forwarding packet in one
>> direction
>> >>>>>> at
>> >>>>>> the same time. it gets the ARP request but doesn't see the ARP
>> reply
>> >>>>>> (*pkt_queued* always returns 0 for one nic...).
>> >>>>>>
>> >>>>>> This behavior looks very weird to me. Do you think there is a
>> >>>>>> compatibility
>> >>>>>> issues between netmap and the os I am using? Is there a verified
>> linux
>> >>>>>> distribution (also the version) that perfectly works well with
>> netmap?
>> >>>>>>
>> >>>>>> The OS I use is 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1
>> >>>>>> (2015-05-24)
>> >>>>>> x86_64 GNU/Linux.
>> >>>>>> Linux kernel version is *3.16.0-4-amd64*
>> >>>>>>
>> >>>>>>
>> >>>>>> Thanks!
>> >>>>>> Xiaoye
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Wed, Feb 3, 2016 at 2:12 AM, Luigi Rizzo <rizzo@iet.unipi.it>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>> > On Tue, Feb 2, 2016 at 10:48 PM, Xiaoye Sun <Xiaoye.Sun@rice.edu
>> >
>> >>>>>> > wrote:
>> >>>>>> > >
>> >>>>>> > >
>> >>>>>> > > On Mon, Feb 1, 2016 at 11:34 PM, Luigi Rizzo <
>> rizzo@iet.unipi.it>
>> >>>>>> > > wrote:
>> >>>>>> > >>
>> >>>>>> > >> On Tue, Feb 2, 2016 at 6:23 AM, Xiaoye Sun <
>> Xiaoye.Sun@rice.edu>
>> >>>>>> > >> wrote:
>> >>>>>> > >> > Hi Luigi,
>> >>>>>> > >> >
>> >>>>>> > >> > I have to clarify about the *jumping issue* about the slot
>> >>>>>> > >> > indexes.
>> >>>>>> > >> > In the bridge.c program, the slot index never jumps and it
>> >>>>>> > >> > increases
>> >>>>>> > >> > sequentially.
>> >>>>>> > >> > In the receiver.c program, the udp packet seq jumps and I
>> >>>>>> > >> > showed the
>> >>>>>> > >> > slot
>> >>>>>> > >> > index that each udp packet uses. So the slot index jumps
>> >>>>>> > >> > together with
>> >>>>>> > >> > the
>> >>>>>> > >> > udp seq (at the receiver program only).
>> >>>>>> > >>
>> >>>>>> > >> So let me understand, is the "slot" some information written
>> >>>>>> > >> in the packet by bridge.c (referring to the rx or tx slot,
>> >>>>>> > >> I am not sure) and then read and printed by receiver.c
>> >>>>>> > >> (which gets the packet through recvfrom so there isn't
>> >>>>>> > >> really any slot index) ?
>> >>>>>> > >>
>> >>>>>> > > It works in the other way:
>> >>>>>> > > The bridge.c checks the seq numbers of the udp packets in
>> netmap
>> >>>>>> > > slots
>> >>>>>> > (in
>> >>>>>> > > nic rx ring) before the swap; then it records the seq number,
>> slot
>> >>>>>> > > number(both rx and tx (tx indexes were not shown in the
>> previous
>> >>>>>> > > email
>> >>>>>> > since
>> >>>>>> > > they all look correct)) and buf_idx (rx and tx). The bridge.c
>> does
>> >>>>>> > > not
>> >>>>>> > > change anything in the buffer and it knows the slot and buf_idx
>> >>>>>> > > that a
>> >>>>>> > > packet uses. Please refer to the added code in *process_rings*
>> >>>>>> > > function
>> >>>>>> > > http://www.owlnet.rice.edu/~xs6/bridge.c
>> >>>>>> > > The receiver.c checks the seq numbers only and print out the
>> seq
>> >>>>>> > > numbers
>> >>>>>> > it
>> >>>>>> > > receive sequentially.
>> >>>>>> > > With these information, I manually match the seq number I got
>> from
>> >>>>>> > > receiver.c and the seq number I got from bridge.c. So we know
>> what
>> >>>>>> > > is the
>> >>>>>> > > seq order the receiver sees and which slot a packet uses when
>> >>>>>> > > bridge.c
>> >>>>>> > swaps
>> >>>>>> > > the buf_idxs.
>> >>>>>> > >
>> >>>>>> > >> Do you see any ordering inversion when the receiver
>> >>>>>> > >> gets packets through the NETMAP API (e.g. using bridge.c
>> >>>>>> > >> instead of receiver.c) ?
>> >>>>>> > >>
>> >>>>>> > > There is no ordering inversion seen by bridge.c (As I said in
>> the
>> >>>>>> > previous
>> >>>>>> > > paragraph, the bridge.c checks the seq number and I did not see
>> >>>>>> > > any order
>> >>>>>> > > inversion in THIS simple experiment (In my multicast protocol
>> >>>>>> > > (mentioned
>> >>>>>> > in
>> >>>>>> > > the first email), there is ordering inversion. But let us solve
>> >>>>>> > > the
>> >>>>>> > simple
>> >>>>>> > > bridge.c's problem first. I think they are two relatively
>> >>>>>> > > independent
>> >>>>>> > > issues.)).
>> >>>>>> >
>> >>>>>> > Sorry there was a misunderstanding.
>> >>>>>> > I wanted you to check the following setup:
>> >>>>>> >
>> >>>>>> > [1: send.c] ->- [2: bridge.c] ->- [3: XYZ]
>> >>>>>> >
>> >>>>>> > where in XYZ you replace your receiver.c with some
>> >>>>>> > netmap-based receiver (it could be pkt-gen in rx mode,
>> >>>>>> > or possibly even another instance of bridge.c where
>> >>>>>> > you connect the output port to a vale switch so
>> >>>>>> > traffic is dropped), and then in XYZ print the content
>> >>>>>> > of the packets.
>> >>>>>> >
>> >>>>>> > From your previous report we know that node 2: sees packets
>> >>>>>> > in order, and node 3: sees packets out of order.
>> >>>>>> > However, if the problem were due to bridge.c sending
>> >>>>>> > the old buffer and not the new one, you'd see not only
>> >>>>>> > reordering but also replication of packets.
>> >>>>>> >
>> >>>>>> > The fact that you see only the reordering in 3: makes
>> >>>>>> > me think that the problem is in that node, and it could
>> >>>>>> > be the network stack in 3: that does something strange.
>> >>>>>> > So if you can run something netmap based in 3: and make
>> >>>>>> > sure there is only one queue to read from, we could
>> >>>>>> > at least figure out what is going on.
>> >>>>>> >
>> >>>>>> > cheers
>> >>>>>> > luigi
>> >>>>>> >
>> >>>>>> >
>> >>>>>> > is that
>> >>>>>> > >
>> >>>>>> > >>
>> >>>>>> > >> Are you using native netmap drivers or the emulated mode ?
>> >>>>>> > >> You can check that by playing with the "admode" sysctl entry
>> >>>>>> > >> (or sysfs on linux) - try setting to 1 and 2 and see if
>> >>>>>> > >> the behaviour changes.
>> >>>>>> > >>
>> >>>>>> > >> dev.netmap.admode: 0
>> >>>>>> > >> Controls the use of native or emulated adapter
>> mode.
>> >>>>>> > >> 0 uses the best available option,
>> >>>>>> > >> 1 forces native and fails if not available,
>> >>>>>> > >> 2 forces emulated hence never fails.
>> >>>>>> > >>
>> >>>>>> > > I was using admode 0. I changed the admode to 1 and 2 using the
>> >>>>>> > > command
>> >>>>>> > like
>> >>>>>> > > *echo 1 > /sys/module/netmap/parameters/admode* and restart
>> the
>> >>>>>> > > bridge
>> >>>>>> > > program. The behavior keeps the same.
>> >>>>>> > >
>> >>>>>> > >>
>> >>>>>> > >> cheers
>> >>>>>> > >> luigi
>> >>>>>> > >>
>> >>>>>> > >> >
>> >>>>>> > >> > There is really one ring (tx and rx) for NIC and one ring
>> (tx
>> >>>>>> > >> > and rx)
>> >>>>>> > >> > for
>> >>>>>> > >> > the host.
>> >>>>>> > >> > I also doubt that there might be multiple tx rings for the
>> >>>>>> > >> > host. It
>> >>>>>> > >> > seems
>> >>>>>> > >> > like that bridge program swap packet to multiple host rings
>> and
>> >>>>>> > >> > the
>> >>>>>> > udp
>> >>>>>> > >> > recv
>> >>>>>> > >> > program drains packets from these rings. But this is not the
>> >>>>>> > >> > case
>> >>>>>> > here.
>> >>>>>> > >> >
>> >>>>>> > >> > The bridge program prints a line like this
>> >>>>>> > >> > *515.277263 main [277] Ready to go, eth3 0x1/1 <-> eth3
>> 0x0/1.*
>> >>>>>> > >> > this is printed by the following line the original program
>> >>>>>> > >> > *D("Ready to go, %s 0x%x/%d <-> %s 0x%x/%d.",
>> pa->req.nr_name,
>> >>>>>> > >> > pa->first_rx_ring, pa->req.nr_rx_rings, pb->req.nr_name,
>> >>>>>> > >> > pb->first_rx_ring,
>> >>>>>> > >> > pb->req.nr_rx_rings);*
>> >>>>>> > >> >
>> >>>>>> > >> > I think this shows that there is really one NIC ring and one
>> >>>>>> > >> > HOST
>> >>>>>> > ring.
>> >>>>>> > >> >
>> >>>>>> > >> > Is there another way to verify the number of ring that
>> netmap
>> >>>>>> > >> > has?
>> >>>>>> > >> >
>> >>>>>> > >> > Thanks!
>> >>>>>> > >> > Xiaoye
>> >>>>>> > >> >
>> >>>>>> > >> > On Mon, Feb 1, 2016 at 10:48 PM, Luigi Rizzo
>> >>>>>> > >> > <rizzo@iet.unipi.it>
>> >>>>>> > wrote:
>> >>>>>> > >> >>
>> >>>>>> > >> >> Hi,
>> >>>>>> > >> >> there must be some wrong with your setting because
>> >>>>>> > >> >> slot indexes must be sequential and in your case they
>> >>>>>> > >> >> are not (see the jump from 295 to 474 and then
>> >>>>>> > >> >> back from 485 to 296, and the numerous interleavings
>> >>>>>> > >> >> that you are seeing later).
>> >>>>>> > >> >>
>> >>>>>> > >> >> I have no idea of the cause but typically this pattern
>> >>>>>> > >> >> is what you see when there are multiple input rings and
>> >>>>>> > >> >> not just one.
>> >>>>>> > >> >>
>> >>>>>> > >> >> Cheers
>> >>>>>> > >> >> Luigi
>> >>>>>> > >> >>
>> >>>>>> > >> >>
>> >>>>>> > >> >>
>> >>>>>> > >> >>
>> >>>>>> > >> >> On Tue, Feb 2, 2016 at 12:24 AM, Xiaoye Sun
>> >>>>>> > >> >> <Xiaoye.Sun@rice.edu>
>> >>>>>> > >> >> wrote:
>> >>>>>> > >> >> > Hi Luigi,
>> >>>>>> > >> >> >
>> >>>>>> > >> >> > Thanks for the detailed advice.
>> >>>>>> > >> >> >
>> >>>>>> > >> >> > With more detailed experiments, actually I found that the
>> >>>>>> > >> >> > udp
>> >>>>>> > >> >> > sender/receiver packet reorder issue *might* be
>> irrelevant
>> >>>>>> > >> >> > to the
>> >>>>>> > >> >> > original
>> >>>>>> > >> >> > issue I posted. However, I think we should solve the udp
>> >>>>>> > >> >> > sender/receiver
>> >>>>>> > >> >> > issue first.
>> >>>>>> > >> >> > I run the experiment with more detailed log. Here is my
>> >>>>>> > >> >> > findings.
>> >>>>>> > >> >> >
>> >>>>>> > >> >> > 1. I am running a netmap version available since about
>> Oct
>> >>>>>> > >> >> > 13rd
>> >>>>>> > from
>> >>>>>> > >> >> > github
>> >>>>>> > >> >> > (https://github.com/luigirizzo/netmap). So I think this
>> is
>> >>>>>> > >> >> > not the
>> >>>>>> > >> >> > one
>> >>>>>> > >> >> > related to the buffer allocation issue. I tried to
>> running
>> >>>>>> > >> >> > the
>> >>>>>> > newest
>> >>>>>> > >> >> > version, however, that version causes problem when I exit
>> >>>>>> > >> >> > the
>> >>>>>> > bridge
>> >>>>>> > >> >> > program
>> >>>>>> > >> >> > (something like kernel error which make the os crash).
>> >>>>>> > >> >> >
>> >>>>>> > >> >> > 2 & 3. I changed the receiver.c & bridge.c so that I can
>> get
>> >>>>>> > >> >> > more
>> >>>>>> > >> >> > information (more detailed log).
>> >>>>>> > >> >> > The reorder happens multiple times (about 10 times)
>> within a
>> >>>>>> > second.
>> >>>>>> > >> >> > Here is
>> >>>>>> > >> >> > one example trace collected from the above two programs.
>> >>>>>> > (remembering
>> >>>>>> > >> >> > that
>> >>>>>> > >> >> > we have udp sender running on one machine; netmap bridge
>> and
>> >>>>>> > >> >> > udp
>> >>>>>> > >> >> > receiver
>> >>>>>> > >> >> > are running on another machine).
>> >>>>>> > >> >> > There is only one pair of rings each with 512 slots (511
>> >>>>>> > >> >> > slot
>> >>>>>> > usable)
>> >>>>>> > >> >> > on
>> >>>>>> > >> >> > the
>> >>>>>> > >> >> > receiver machine.
>> >>>>>> > >> >> >
>> >>>>>> > >> >> > =================== packet trace collected from
>> receiver.c
>> >>>>>> > >> >> > ===================
>> >>>>>> > >> >> > ===== together with the slot and buf_idx of the
>> >>>>>> > >> >> > corresponding
>> >>>>>> > netmap
>> >>>>>> > >> >> > ring
>> >>>>>> > >> >> > slots ======
>> >>>>>> > >> >> > [seq] [slot] [buf_idx]
>> >>>>>> > >> >> > 8208 294 1833
>> >>>>>> > >> >> > 8209 295 1834
>> >>>>>> > >> >> > 8388 474 2013
>> >>>>>> > >> >> > ... (packet received in order)
>> >>>>>> > >> >> > 8398 484 2023
>> >>>>>> > >> >> > 8399 485 2024
>> >>>>>> > >> >> > 8210 296 1835
>> >>>>>> > >> >> > 8211 297 1836
>> >>>>>> > >> >> > ... (packet received in order)
>> >>>>>> > >> >> > ...
>> >>>>>> > >> >> > 8222 308 1847
>> >>>>>> > >> >> > 8400 486 2025
>> >>>>>> > >> >> > 8223 309 1848
>> >>>>>> > >> >> > 8401 487 2026
>> >>>>>> > >> >> > 8224 310 1849
>> >>>>>> > >> >> > 8402 488 2027
>> >>>>>> > >> >> > 8225 311 1850
>> >>>>>> > >> >> > 8403 489 2028
>> >>>>>> > >> >> > 8226 312 1851
>> >>>>>> > >> >> > 8404 450 2029
>> >>>>>> > >> >> > 8227 313 1852
>> >>>>>> > >> >> > 8228 314 1853
>> >>>>>> > >> >> >
>> >>>>>> > >> >> > ==============================
>> =====================================
>> >>>>>> > >> >> > As we can see that the udp receiver got packet 8210
>> after it
>> >>>>>> > >> >> > got
>> >>>>>> > >> >> > 8399,
>> >>>>>> > >> >> > which
>> >>>>>> > >> >> > is the first reorder. Then, the receiver got 8211 to 8222
>> >>>>>> > >> >> > sequentially.
>> >>>>>> > >> >> > Then
>> >>>>>> > >> >> > it got packet from 8223-8227 and 8400-8404 interleaved.
>> >>>>>> > >> >> >
>> >>>>>> > >> >> >
>> >>>>>> > >> >> > ==================== event order seen by netmap bridge
>> >>>>>> > >> >> > ==================
>> >>>>>> > >> >> > get 8209
>> >>>>>> > >> >> > poll called
>> >>>>>> > >> >> > get 8210
>> >>>>>> > >> >> > ...
>> >>>>>> > >> >> > ...
>> >>>>>> > >> >> > get 8228
>> >>>>>> > >> >> > poll called
>> >>>>>> > >> >> > get 8229
>> >>>>>> > >> >> > ...
>> >>>>>> > >> >> > ...
>> >>>>>> > >> >> > get 8383
>> >>>>>> > >> >> > poll called
>> >>>>>> > >> >> > get 8384
>> >>>>>> > >> >> > ...
>> >>>>>> > >> >> > get 8387
>> >>>>>> > >> >> > poll called
>> >>>>>> > >> >> > get 8388
>> >>>>>> > >> >> > ...
>> >>>>>> > >> >> > get 8393
>> >>>>>> > >> >> > poll called
>> >>>>>> > >> >> > get 8394
>> >>>>>> > >> >> > ...
>> >>>>>> > >> >> > get 8399
>> >>>>>> > >> >> > poll called
>> >>>>>> > >> >> > get 8400
>> >>>>>> > >> >> > ...
>> >>>>>> > >> >> > get 8404
>> >>>>>> > >> >> > poll called
>> >>>>>> > >> >> > get 8405
>> >>>>>> > >> >> >
>> >>>>>> > >> >> > ==============================
>> =====================================
>> >>>>>> > >> >> > As we can see, from the event ordering see by the
>> bridge.c,
>> >>>>>> > >> >> > all the
>> >>>>>> > >> >> > packets
>> >>>>>> > >> >> > are receiver in order, which means the the reorder
>> happens
>> >>>>>> > >> >> > when the
>> >>>>>> > >> >> > bridge
>> >>>>>> > >> >> > code swap the buf_idx between the nic ring(slot) and the
>> >>>>>> > >> >> > host
>> >>>>>> > >> >> > ring(slot).
>> >>>>>> > >> >> > The reordered seq usually right before or after the poll
>> >>>>>> > >> >> > function
>> >>>>>> > >> >> > call.
>> >>>>>> > >> >> >
>> >>>>>> > >> >> > Best,
>> >>>>>> > >> >> > Xiaoye
>> >>>>>> > >> >> >
>> >>>>>> > >> >> >
>> >>>>>> > >> >> >
>> >>>>>> > >> >> >
>> >>>>>> > >> >> >
>> >>>>>> > >> >> >
>> >>>>>> > >> >> >
>> >>>>>> > >> >> >
>> >>>>>> > >> >> > On Fri, Jan 29, 2016 at 4:27 PM, Luigi Rizzo
>> >>>>>> > >> >> > <rizzo@iet.unipi.it>
>> >>>>>> > >> >> > wrote:
>> >>>>>> > >> >> >>
>> >>>>>> > >> >> >> On Fri, Jan 29, 2016 at 2:12 PM, Xiaoye Sun
>> >>>>>> > >> >> >> <Xiaoye.Sun@rice.edu>
>> >>>>>> > >> >> >> wrote:
>> >>>>>> > >> >> >> > Hi Luigi,
>> >>>>>> > >> >> >> >
>> >>>>>> > >> >> >> > Thanks for your advice.
>> >>>>>> > >> >> >> > I forgot to mention that I use the command "ethtool -L
>> >>>>>> > >> >> >> > eth1
>> >>>>>> > >> >> >> > combined
>> >>>>>> > >> >> >> > 1"
>> >>>>>> > >> >> >> > to
>> >>>>>> > >> >> >> > set the number of rings of the nic to 1. The host
>> also
>> >>>>>> > >> >> >> > only has
>> >>>>>> > >> >> >> > one
>> >>>>>> > >> >> >> > ring.
>> >>>>>> > >> >> >> > I understand the situation where the first tx ring is
>> >>>>>> > >> >> >> > full so
>> >>>>>> > the
>> >>>>>> > >> >> >> > bridge
>> >>>>>> > >> >> >> > will swap the packets to the second tx ring and then
>> the
>> >>>>>> > host/nic
>> >>>>>> > >> >> >> > might
>> >>>>>> > >> >> >> > drain either rings. But this is not the case in the
>> >>>>>> > >> >> >> > experiment.
>> >>>>>> > >> >> >>
>> >>>>>> > >> >> >> ok good to know that.
>> >>>>>> > >> >> >>
>> >>>>>> > >> >> >> So if we have ruled out multiqueue and iommu, let's
>> look at
>> >>>>>> > >> >> >> the internal allocator and at bridge.c
>> >>>>>> > >> >> >>
>> >>>>>> > >> >> >> 1. are you running the most recent version of netmap ?
>> >>>>>> > >> >> >> Some older version (probably 1-2 years ago) had a bug
>> >>>>>> > >> >> >> in the buffer allocator and some buffers were
>> allocated
>> >>>>>> > >> >> >> twice.
>> >>>>>> > >> >> >>
>> >>>>>> > >> >> >> 2. can you tweak your receiver.c to report some more
>> info
>> >>>>>> > >> >> >> on how often you get out of sequence packets, how
>> much
>> >>>>>> > >> >> >> out of sequence they are ?
>> >>>>>> > >> >> >> Also it would be useful to report gaps on the
>> increasing
>> >>>>>> > >> >> >> side
>> >>>>>> > >> >> >> (i.e. new_seq != old_seq +1 )
>> >>>>>> > >> >> >>
>> >>>>>> > >> >> >> 3. can you tweak bridge.c so that it writes into the
>> packet
>> >>>>>> > >> >> >> the netmap buffer indexes and slots on the rx and tx
>> >>>>>> > >> >> >> side,
>> >>>>>> > >> >> >> so when you detect a sequence error we can figure out
>> >>>>>> > >> >> >> where it is happening.
>> >>>>>> > >> >> >> Ideally you could also add the sequence number
>> detection
>> >>>>>> > >> >> >> code in bridge.c so we can check whether the errors
>> >>>>>> > >> >> >> appear
>> >>>>>> > >> >> >> on the input or output sides.
>> >>>>>> > >> >> >>
>> >>>>>> > >> >> >> cheers
>> >>>>>> > >> >> >> luigi
>> >>>>>> > >> >> >>
>> >>>>>> > >> >> >
>> >>>>>> > >> >>
>> >>>>>> > >> >>
>> >>>>>> > >> >>
>> >>>>>> > >> >> --
>> >>>>>> > >> >>
>> >>>>>> > >> >>
>> >>>>>> >
>> >>>>>> > -----------------------------------------+------------------
>> -------------
>> >>>>>> > >> >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing.
>> >>>>>> > >> >> dell'Informazione
>> >>>>>> > >> >> http://www.iet.unipi.it/~luigi/ . Universita` di
>> Pisa
>> >>>>>> > >> >> TEL +39-050-2217533 . via Diotisalvi 2
>> >>>>>> > >> >> Mobile +39-338-6809875 . 56122 PISA
>> (Italy)
>> >>>>>> > >> >>
>> >>>>>> > >> >>
>> >>>>>> >
>> >>>>>> > -----------------------------------------+------------------
>> -------------
>> >>>>>> > >> >>
>> >>>>>> > >> >
>> >>>>>> > >>
>> >>>>>> > >>
>> >>>>>> > >>
>> >>>>>> > >> --
>> >>>>>> > >>
>> >>>>>> >
>> >>>>>> > -----------------------------------------+------------------
>> -------------
>> >>>>>> > >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing.
>> >>>>>> > dell'Informazione
>> >>>>>> > >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
>> >>>>>> > >> TEL +39-050-2217533 . via Diotisalvi 2
>> >>>>>> > >> Mobile +39-338-6809875 . 56122 PISA (Italy)
>> >>>>>> > >>
>> >>>>>> >
>> >>>>>> > -----------------------------------------+------------------
>> -------------
>> >>>>>> > >>
>> >>>>>> > >
>> >>>>>> >
>> >>>>>> >
>> >>>>>> >
>> >>>>>> > --
>> >>>>>> >
>> >>>>>> > -----------------------------------------+------------------
>> -------------
>> >>>>>> > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing.
>> >>>>>> > dell'Informazione
>> >>>>>> > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
>> >>>>>> > TEL +39-050-2217533 . via Diotisalvi 2
>> >>>>>> > Mobile +39-338-6809875 . 56122 PISA (Italy)
>> >>>>>> >
>> >>>>>> > -----------------------------------------+------------------
>> -------------
>> >>>>>> >
>> >>>>>> >
>> >>>>>> _______________________________________________
>> >>>>>> freebsd-net@freebsd.org mailing list
>> >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> >>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@
>> freebsd.org"
>> >>>
>> >>>
>> >>
>> >
>>
>>
>>
>> --
>> -----------------------------------------+-------------------------------
>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione
>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
>> TEL +39-050-2217533 . via Diotisalvi 2
>> Mobile +39-338-6809875 . 56122 PISA (Italy)
>> -----------------------------------------+-------------------------------
>>
>>
>
From owner-freebsd-net@freebsd.org Tue Nov 21 07:49:12 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 9E40ADE67D9
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 07:49:12 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com
[IPv6:2607:f8b0:400d:c0d::232])
(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 5371F638C1
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 07:49:12 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: by mail-qt0-x232.google.com with SMTP id r39so17942013qtr.13
for <freebsd-net@freebsd.org>; Mon, 20 Nov 2017 23:49:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=g+AolEVrcKe2QRifgRSpKfwxTsA/WghOm1PLe+YEMwU=;
b=QHduvJ9NO4ideTnsbUH0IL43sFKVz6PSyDVAADCWkrsbsUfffLYFKsSQJzXkGAAkWn
QuzL9Ruh7RyXV+/IcnjY3mFs221zn6KUB5d1YLBQqBeJUcHZKMfgJEIXuqplVuCrgW8o
cyXyBibb+zM4BMwLAo9QAc6cznth5bhSZaiB4iGDhGstt3nKqKIY1/iJemA2bCy8kEJG
Fwdgg2l7q0VqxoCxiRX3jy/uaNplODdEDvg3CxGbHpbwtVc6wKMx+dLVUTnSH63nlvFO
B00J2Uasnl3gJiKYzYp0Re65wwmx3q4PGKy9IGLf0AN5dZMi9oIk3/vL5CGmM7QytliM
CsGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=g+AolEVrcKe2QRifgRSpKfwxTsA/WghOm1PLe+YEMwU=;
b=gcNd+jpW9k2b9dWP0NWzkgfH/0XpOpRuZiAKdvkucG96b0LTK6SI3NxYrm2NaOrM17
q2JAUKEynYE5ieh4U1DMnNi21SnjDyuuCQkJ7VmBeNfFrZAbCBSBIFtWqT/BqmudUNav
FfC2YS/aB2stEdz9K+Fjc1HNjolzqFKCi799NhZtbtxnV8y1Nze8mrLtsJAsnY8f22wI
9zqv0Uzk/8nfl8KobTcKH2Cf3uw8A29LYf2PfcoDCQQ79ldVeqnRaAltG3MxkCqwzzS3
oOlNPbl8ZvDmF3Wf2CrRytG8mfWOwdGm04ip0FIcDyOatLUGj5T07JtpF2I+6eBa2Miy
/+vA==
X-Gm-Message-State: AJaThX6zaqISk9BQkkijhg0uJudCEEypBJhUCi8XuhVRHZl30ks62maq
dvJCLLo8XB00nk7fXT4HVbrwjnys+zAUYcZeBUo=
X-Google-Smtp-Source: AGs4zMaej/x59YehkZXLPIU17C2ffMh+fvbi2nCO6ykp2Ax60Ofklp3ktBoipEnV/umYRuVsbzROFevhTUOQnspLxaI=
X-Received: by 10.200.35.90 with SMTP id b26mr25319922qtb.324.1511250551177;
Mon, 20 Nov 2017 23:49:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.174.25 with HTTP; Mon, 20 Nov 2017 23:49:10 -0800 (PST)
In-Reply-To: <CAJnByzg-=9Aqy9S5ZuFFyLQgCJBtZ7MrDAuf5ccsVzj68=dSTw@mail.gmail.com>
References: <CAJnByzh4Kzp6-DXXcB06QHSBJpHBKhtDnKUn7R+K0A_5VUThyw@mail.gmail.com>
<CA+_eA9i5WOiA8j3y8fX65rzDLXEyt2B2wo8pK12jM2ZvEBURYg@mail.gmail.com>
<CAJnByzhv27D_V=kyJjzQPQ28GM8kACKsH87MB5uDKVkQ-aka0g@mail.gmail.com>
<CA+hQ2+h0QEx3LPvFGNZv5ZvBJOJ-X0go-=c3V0gr6FRhe7icXA@mail.gmail.com>
<CAJnByzg-=9Aqy9S5ZuFFyLQgCJBtZ7MrDAuf5ccsVzj68=dSTw@mail.gmail.com>
From: Vincenzo Maffione <v.maffione@gmail.com>
Date: Tue, 21 Nov 2017 08:49:10 +0100
Message-ID: <CA+_eA9i4DOWXP5np98+c8=JuMMg4w6zMpc7579xuNJoW9Z7qwA@mail.gmail.com>
Subject: Re: [netmap] when does a packet in the netmap ring send out exactly
To: Xiaoye Sun <Xiaoye.Sun@rice.edu>
Cc: Luigi Rizzo <rizzo@iet.unipi.it>, FreeBSD Net <freebsd-net@freebsd.org>,
Giuseppe Lettieri <g.lettieri@iet.unipi.it>
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 07:49:12 -0000
Hi,
Netmap version (tag v11.3 vs master) should be unrelated.
Are you using ixgbe? In this case it may depend on the ixgbe driver version
that netmap is using for patching.
On github master you can change the version by modifying the ixgbe line in
LINUX/default-config.mak.in_.
Valid versions are for instance 4.5.4 or 5.1.3.
Cheers,
Vincenzo
2017-11-21 4:43 GMT+01:00 Xiaoye Sun <Xiaoye.Sun@rice.edu>:
> Hi Luigi,
>
> Thanks!
> I was using the most recent netmap on Github and I believe the tail
> pointer only moves forward when there are less than half of the total slots
> available in the netmap ring.
> Then I switch to the version of v11.3
> <https://github.com/luigirizzo/netmap/tree/v11.3>, it behaves as what you
> described.
>
> Linux Kernel: 3.16.0-4-amd64
>
> Best,
> Xiaoye
>
>
> On Mon, Nov 20, 2017 at 6:11 PM, Luigi Rizzo <rizzo@iet.unipi.it> wrote:
>
>> Hi,
>> I think if you call the TXSYNC ioctl without advancing the head
>> pointer, then the tail is advanced
>> as much as possible.
>>
>> Cheers
>> luigi
>>
>> On Mon, Nov 20, 2017 at 3:35 PM, Xiaoye Sun <Xiaoye.Sun@rice.edu> wrote:
>> > Hi,
>> >
>> > I found that the tail pointer only moves when the ring has less than
>> half
>> > of the slots available. This prevents me from knowing the accurate time
>> > when the packet in a slot is processed. Is there a way to move the tail
>> > pointer as long as the packet in the slot is processed? Is this a
>> > configurable feature?
>> >
>> > Best,
>> > Xiaoye
>> >
>> > On Fri, Oct 27, 2017 at 11:52 AM, Vincenzo Maffione <
>> v.maffione@gmail.com>
>> > wrote:
>> >
>> >> Hi,
>> >> This is actually a limitation of the netmap API: ring->tail is
>> exposed
>> >> to the user so that it knows it can use the slots in the range
>> >> "[ring->head..ring->tail[" for new transmissions (note that head is
>> >> included, tail excluded, to prevent wraparound). However, there is no
>> >> explicit indication of "up to what slots packets were transmitted".
>> >> For hw NICs, however, ring->tail is an indication of where transmission
>> >> was completed.
>> >> Example:
>> >> 1) at the beginning ring->tail = ring->head = ring->cur = 0
>> >> 2) then your program moves head/cur forward: head = cur = 10
>> >> 3) you call TXSYNC, to submit the packets to the NIC.
>> >> 4) after the TXSYNC call, is very likely that tail is still 0, i.e.
>> >> because no transmission has been completed by the NIC (and no interrupt
>> >> generated).
>> >> 5) say after 20 us you issue another TXSYNC, and in the meanwhile 6
>> >> packets had completed. In this case after TXSYNC you will find tail==5,
>> >> meaning that packets in the slots 0,1,2,3,4 and 5 have been completed.
>> Note
>> >> that also the slot pointed by tail has been completed.
>> >>
>> >> But you are right that there is no way to receive completion
>> notification
>> >> if the queue is not full. You must use TXSYNC to check (by sleeping or
>> busy
>> >> wait) when tail moves forward.
>> >>
>> >> Cheers,
>> >> Vincenzo
>> >>
>> >>
>> >> 2017-10-27 3:06 GMT+02:00 Xiaoye Sun <Xiaoye.Sun@rice.edu>:
>> >>
>> >>> Hi
>> >>>
>> >>> I write a netmap program that sends packets to the network. my program
>> >>> uses one netmap ring and fills the ring slots with packets.
>> >>> My program needs to do something (action A) after a particular packet
>> >>> (packet P) in the ring slot is sent to the network. so the program
>> tracks
>> >>> the position of the tail point and checks if the tail point has moved
>> >>> across the slot I used to put that packet P.
>> >>> However, I found that the tail pointer may not move forward even
>> seconds
>> >>> after the receiver side got packet P.
>> >>> Sometimes the tail pointer never moves forward until the TX ring is
>> full.
>> >>> I try ioctl(NIOCTXSYNC), however, it cannot 100% solve the problem.
>> >>>
>> >>> My question is that is there a way to make the TX ring empty as early
>> as
>> >>> possible so that I can know when my packet is sent out. or is there
>> >>> another
>> >>> way to know when the packet in the slot is sent to the network/NIC
>> >>> physical
>> >>> queue?
>> >>>
>> >>> I am using Linux 3.16.0-4-amd64.
>> >>>
>> >>> Thanks!
>> >>>
>> >>> Best,
>> >>> Xiaoye
>> >>> _______________________________________________
>> >>> freebsd-net@freebsd.org mailing list
>> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org
>> "
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Vincenzo Maffione
>> >>
>> > _______________________________________________
>> > freebsd-net@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>
>>
>>
>> --
>> -----------------------------------------+-------------------------------
>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione
>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
>> TEL +39-050-2217533 . via Diotisalvi 2
>> <https://maps.google.com/?q=via+Diotisalvi+2&entry=gmail&source=g>
>> Mobile +39-338-6809875 . 56122 PISA (Italy)
>> -----------------------------------------+-------------------------------
>>
>
>
--
Vincenzo Maffione
From owner-freebsd-net@freebsd.org Tue Nov 21 08:34:16 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 B3286DE77D6
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 08:34:16 +0000 (UTC) (envelope-from des@des.no)
Received: from smtp.des.no (smtp.des.no [194.63.250.102])
by mx1.freebsd.org (Postfix) with ESMTP id 7A4BC64BFA;
Tue, 21 Nov 2017 08:34:15 +0000 (UTC) (envelope-from des@des.no)
Received: from desk.des.no (smtp.des.no [194.63.250.102])
by smtp.des.no (Postfix) with ESMTP id 98C5510841;
Tue, 21 Nov 2017 08:34:14 +0000 (UTC)
Received: by desk.des.no (Postfix, from userid 1001)
id 28E444811B; Tue, 21 Nov 2017 08:34:19 +0000 (UTC)
From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To: Alexander Zagrebin <alex@zagrebin.ru>
Cc: freebsd-net@freebsd.org, Andriy Gapon <avg@FreeBSD.org>
Subject: Re: local_unbound, resolvconf, vpn
References: <5689438f-6734-6b57-b700-d70ee2b7578a@FreeBSD.org>
<86a7zq8er7.fsf@desk.des.no>
<8a098542-9f04-3a41-76f1-e463e3e89c99@FreeBSD.org>
<86y3n16mez.fsf@desk.des.no>
<37f97bc5-5187-2700-5811-a9cf173eeb10@FreeBSD.org>
<86tvxp6jja.fsf@desk.des.no>
<20171121094527.0952f3b9@vm2.home.zagrebin.ru>
Date: Tue, 21 Nov 2017 09:34:19 +0100
In-Reply-To: <20171121094527.0952f3b9@vm2.home.zagrebin.ru> (Alexander
Zagrebin's message of "Tue, 21 Nov 2017 09:45:27 +0300")
Message-ID: <86po8c6nec.fsf@desk.des.no>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 08:34:16 -0000
Alexander Zagrebin <alex@zagrebin.ru> writes:
> Also I have to notice that there is another issue with the default
> local_unbound setup:
> by default unbound uses syslog for logging, but usually the
> local_unbound service starts before syslogd and so logging doesn't work
> until local_unbound will be reloaded.
That's a chicken-and-egg problem since syslogd may need DNS to log to an
external aggregator.
> So it's looks reasonable to use logging to file by default.
No, it's not reasonable. We have syslogd for a reason. What we need to
do is give unbound its own log socket inside the chroot, as we used to
do for named:
1) Have local-unbound-setup edit /var/run/syslogd.sockets if necessary.
2) Edit log_init() in contrib/unbound/util/log.c so it notices if the
log socket is inside the chroot and does the right thing (including
but not limited to rewriting the socket path and not using NDELAY).
This should be sufficient since syslog() will retry openlog() every time
you call it, so it doesn't matter if the log socket isn't present or
connected when Unbound starts, as long as it's reachable from within the
chroot when it does appear. Log messages emitted before syslogd starts
will go to the console, so they won't be lost.
For bonus points, modify syslogd so log sockets can be specified in
syslog.conf instead of (or in addition to) being passed on the command
line.
DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no
From owner-freebsd-net@freebsd.org Tue Nov 21 08:39:30 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 75E9CDE7ACA
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 08:39:30 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com
[IPv6:2607:f8b0:400d:c09::22d])
(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 2B32B64F06
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 08:39:30 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: by mail-qk0-x22d.google.com with SMTP id 136so10954628qkd.4
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 00:39:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=bCqbgXaXJ+K6xcKvmmb4ISiCT8Zwh6aZwWB5omO87rg=;
b=lJJ7Hd6GK609+wdswX3AoSvag8LvdiCR97np1/VuzGweikV6tUuGorj3Rf/+nsZ6mm
G2ENpnTzbv3sHjL/qcJYiSKzxujXQSyeZg+GgQ+Mv3GZxwxQxuQz1N5ztOiGtvweYm8X
StblgZUE4CZIa+G0IM+wyOZWjs0QdDfU+ZT2EpaKQ0oW0MlnOlcYJ/++0nkTS5xUii8r
eROaquPFnHKeRqYzM4PtYrxd0ii9/Vc2oKWOXsMskDCtzTMBjaMKVaod9NiAKRVU0kZt
y3CbWeK0Vl6oEhxoUw4DHlf4oit0dbZ3eUcJ/uDpuviW3yrzA726CItPwuFRkKe++wsZ
Jymg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=bCqbgXaXJ+K6xcKvmmb4ISiCT8Zwh6aZwWB5omO87rg=;
b=psqe89PEky4jgCl51rX0f2ZvOnAqDZBGTu7hpYX/ISWxcj0+GeITCxzxviRcTNhafG
jwf4w5qanI/oD8q5PfdAUe8hqdc6Fe26VeWBXmDQodMKh5d+Q+8AvXWoQKTAFZMq3rP/
SwKmoIc1OKHECVDfbtnZ+C/OvI7Loyjx6i3NX26Z56lb1HtM0+U2vVFYmwQUWX25olUY
7rzY8ady6pzenkPSwgCsjdX8T4PnD5DBBgvjBHkrK5scMTndsx593C/Y1X+iXCJ0OsPu
ACLvqeAxOwPBmFYXLriyCBUFnw7m9ldsYmo7Yjks26/9dorE85yoTCr3Vx6U7u1jGGoK
fxhQ==
X-Gm-Message-State: AJaThX4kYjB5M+h2h4ODyjyLQT/xGFtKeyuwEM/a411rkgqEKmhgGddL
5a0aNyeOtpuWSrnFsrbXrqqZOw89e714iC8Eu8rosA==
X-Google-Smtp-Source: AGs4zMayEVh9U9EK3Ciq8kgso6WrYxFrY3iQnoXKDwvwNjV3fCwcpHkVSgJ665GMWDAxVtrVSP7l4SXjU1q83VRVNlY=
X-Received: by 10.55.55.135 with SMTP id e129mr25932707qka.2.1511253568966;
Tue, 21 Nov 2017 00:39:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.174.25 with HTTP; Tue, 21 Nov 2017 00:39:28 -0800 (PST)
In-Reply-To: <5A0F14CD.3040407@omnilan.de>
References: <5A0F14CD.3040407@omnilan.de>
From: Vincenzo Maffione <v.maffione@gmail.com>
Date: Tue, 21 Nov 2017 09:39:28 +0100
Message-ID: <CA+_eA9giPsMJ2_O1CLvOro=rMm5TaJyQ-et_U01Re5J9+9VSqg@mail.gmail.com>
Subject: Re: netmap/vale periodic deadlock
To: Harry Schmalzbauer <freebsd@omnilan.de>
Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
Giuseppe Lettieri <g.lettieri@iet.unipi.it>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 08:39:30 -0000
Hi,
It's hard to say, specially because it happens after two days of normal
use.
Can't you enable deadlock debugging features in your kernel?
https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne=
ldebug-deadlocks.html
However, if I understand correctly you have created some VLAN interfaces
vlan0, vlan1, vlan2, ... on top of a NIC (say em0). And you have attached
each VLAN interface to a vale switch:
# vale-ctl -a vale0:vlan0
# vale-ctl -a vale1:vlan1
# vale-ctl -a vale2:vlan2
and each VALE switch is attached to a different set of bhyve guests.
If this is the case, although you are allowed to do that, I don't think
it's a convenient way to use netmap.
Since VLAN interfaces like vlan0 do not have (and cannot have) native
netmap support, you are falling back to emulated netmap adapters (which are
probably buggy on FreeBSD, specially when combined with VALE).
Apart from bugs I think that with this setup you can't get decent
performance that would justify using netmap rather than the standard kernel
bridge and TAP devices.
The right way to do it imho would be to write your own (userspace) netmap
application that forwards packets between your bhyve guests and the NIC,
prepending/stripping VLAN headers according to configuration (e.g. guest A
is configured to be on VLAN 100, guest B on VLAN 200), etc.
I think this would be a very interesting netmap application in general, and
more importantly you would get the performance that you can't get with your
setup.
Cheers,
Vincenzo
2017-11-17 17:56 GMT+01:00 Harry Schmalzbauer <freebsd@omnilan.de>:
> Hello,
>
> sorry for annoying with another question/problem.
>
> I'm using netmap's vale (on stable/11) for bhyve(8) virtio-net backed SDN=
.
>
> The guests =E2=80=93 unfortunately in production already =E2=80=93 quit n=
etwork services
> (resp. are not able to transceive any packets anymore) after about 2
> days; repeatedly and most likely not load related, since there is no
> significant load.
> Each guest is running fine, the host also runs without any other
> problem, no network problem elsewhere (different NICs; I use one
> dedicated NIC with vlan(4) children, each child connected to one vale
> switch).
>
> At some point, the complete netmap subsystem seems to deadlock:
> 'vale-ctl' hangs uninteruptable.
> Trying to attach a tcpdump to a vale switch also hands uninteruptable.
> Stoping (shuting down from inside) bhyve guests works up to the point
> where the vale port should be destroyed.
> I could continue the list of symptoms, but that doesn't help in any way
> I guess.
>
> My question is, where can I start finding out what happens with the
> netmap subsystem?
>
> There were no kernel messages right before or during the deadlock!
>
> The only userland tool I'm familar with (vale-ctl) isn't usable at all
> in that situation.
> Any hints what to try?
>
>
> Here's a excerpt of processes running when the netmap-lockuped host has
> all guests shut down, just before I rebooted.
> Snipped alot, the interesing ones are thos in state "netmap_g":
> =E2=80=A6
> 0 14213 1 0 20 0 5864 0 wait IW 3 0:00,00 (sh)
> 0 14214 14213 0 -92 0 5358120 3586232 nm_kn_lo TC 3 148:02,02 bhyve:
> kallisto (bhyve)
> 0 14976 2522 0 20 0 6976 0 wait IW 3 0:00,00 su
> 0 14981 14976 0 20 0 8256 0 pause IW 3 0:00,00 _su (csh)
> 0 61615 14981 0 20 0 5864 0 wait IW 3 0:00,00 (sh)
> 0 61616 61615 0 52 0 2180648 1973252 netmap_g DEC 3 286:11,91 bhyve:
> preed (bhyve)
> 0 62845 14981 0 20 0 11624 3328 bdg lock L+ 3 0:00,01 tcpdump -n -e -s
> 150 -i vale1:test
> =E2=80=A6
> 0 1390 1388 0 -92 0 2330024 767756 nm_kn_lo TC v0- 94:01,90 bhyve: styx0
> (bhyve)
> 0 1401 1 0 52 0 5784 0 wait IW v0- 0:00,00 (sh)
> 0 1403 1401 0 20 0 368328 43444 - TC v0- 3:35,66 bhyve: korso (bhyve)
> =E2=80=A6
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
--=20
Vincenzo Maffione
From owner-freebsd-net@freebsd.org Tue Nov 21 08:45:13 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 8ACEFDE7DEB
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 08:45:13 +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 78993653DB
for <freebsd-net@FreeBSD.org>; Tue, 21 Nov 2017 08:45:13 +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 vAL8jDtN088217
for <freebsd-net@FreeBSD.org>; Tue, 21 Nov 2017 08:45:13 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223767] tun device allows modification of if_type to any value
causing a page fault and panic
Date: Tue, 21 Nov 2017 08:45:13 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 10.4-STABLE
X-Bugzilla-Keywords: patch
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: hselasky@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-223767-2472-1c2yyQ0Pyx@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223767-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223767-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 08:45:13 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223767
Hans Petter Selasky <hselasky@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hselasky@FreeBSD.org
--- Comment #3 from Hans Petter Selasky <hselasky@FreeBSD.org> ---
Hi,
The committer can probably split the patch in two chunks.
Looks good to me.
--HPS
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-net@freebsd.org Tue Nov 21 09:58:04 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 D7593DE9552
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 09:58:04 +0000 (UTC)
(envelope-from freebsd@omnilan.de)
Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130])
(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 6940867577
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 09:58:04 +0000 (UTC)
(envelope-from freebsd@omnilan.de)
Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net
[IPv6:2a00:e10:2800::a135])
by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id vAL9w1VC069800;
Tue, 21 Nov 2017 10:58:01 +0100 (CET)
(envelope-from freebsd@omnilan.de)
Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mh0.gentlemail.de (Postfix) with ESMTPSA id B51CE908;
Tue, 21 Nov 2017 10:58:00 +0100 (CET)
Message-ID: <5A13F8A8.2020209@omnilan.de>
Date: Tue, 21 Nov 2017 10:58:00 +0100
From: Harry Schmalzbauer <freebsd@omnilan.de>
Organization: OmniLAN
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE;
rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: Vincenzo Maffione <v.maffione@gmail.com>
CC: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
Giuseppe Lettieri <g.lettieri@iet.unipi.it>
Subject: Re: netmap/vale periodic deadlock
References: <5A0F14CD.3040407@omnilan.de>
<CA+_eA9giPsMJ2_O1CLvOro=rMm5TaJyQ-et_U01Re5J9+9VSqg@mail.gmail.com>
In-Reply-To: <CA+_eA9giPsMJ2_O1CLvOro=rMm5TaJyQ-et_U01Re5J9+9VSqg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7
(mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]);
Tue, 21 Nov 2017 10:58:01 +0100 (CET)
X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ;
Sender-helo: mh0.gentlemail.de; )
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 09:58:04 -0000
Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39 (localtime):
> Hi,
> It's hard to say, specially because it happens after two days of
> normal use.
> Can't you enable deadlock debugging features in your kernel?
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
>
> However, if I understand correctly you have created some VLAN interfaces
> vlan0, vlan1, vlan2, ... on top of a NIC (say em0). And you have
> attached each VLAN interface to a vale switch:
>
> # vale-ctl -a vale0:vlan0
> # vale-ctl -a vale1:vlan1
> # vale-ctl -a vale2:vlan2
>
> and each VALE switch is attached to a different set of bhyve guests.
Hello Vincenzo,
thank you very much for your help again!
Your assumption is correct, here's my vale-ctl:
603.811416 bdg_ctl [148] bridge:0 port:0 vale1:nic1_dmz
603.811428 bdg_ctl [148] bridge:0 port:1 vale1:styx0
603.811430 bdg_ctl [148] bridge:0 port:2 vale1:korso
603.811432 bdg_ctl [148] bridge:0 port:3 vale1:kallisto
603.811434 bdg_ctl [148] bridge:1 port:0 vale2:nic1_inop
603.811435 bdg_ctl [148] bridge:1 port:1 vale2:styx0
603.811437 bdg_ctl [148] bridge:2 port:0 vale3:nic1_vnl
603.811439 bdg_ctl [148] bridge:2 port:1 vale3:styx0
603.811441 bdg_ctl [148] bridge:3 port:0 vale4:nic1_egn
603.811442 bdg_ctl [148] bridge:3 port:1 vale4:styx0
603.811444 bdg_ctl [148] bridge:3 port:2 vale4:preed
…
> If this is the case, although you are allowed to do that, I don't think
> it's a convenient way to use netmap.
> Since VLAN interfaces like vlan0 do not have (and cannot have) native
> netmap support, you are falling back to emulated netmap adapters (which
> are probably buggy on FreeBSD, specially when combined with VALE).
> Apart from bugs I think that with this setup you can't get decent
> performance that would justify using netmap rather than the standard
> kernel bridge and TAP devices.
I'm aware about the lost netmap-performace-benefit due to emulated
netmap fallback.
But there were some resonons why I chose vale(4) instead if_bridge(4):
1) Inter-Guest-traffic (virtio-net causes lot of LAPIC/IRQ overhead, but
still less overhead than tap(4)/if_bridge(4))
2) Future ptnetmap(4) upgrade path (which should save a lot of LAPIC/IRQ
CPU cycles and unleash huge performace benefits with inter-vm traffic)
3) Admin-mess and MTU limitation. Each if_bridge(4) causes a host-stack
interface, which I don't use and which spams ifconfig(8) output; which
if_vtnet(4) even doubles.
Most important disadvantage: if_bridge(4) needs all members to have
exactly the same MTU. This has been a problem for me many times over
the last years in various setups.
So with my current setup the overhead/efficiency of host-external packet
flow of
bhyve_virtio-net+dyn_vale_port+vale(4)
is equal to
bhyve_virtio-net+if_vtnet(4)+if_bridge(4)
But I have less disadvanteges with vale(4); as long as emulated netmap
mode doesn't destabilize my setup :-(
My second choice was ng_bridge(4). Which I made great experiences in my
router-vm, running on that host in question (and in turn uses virtio-net
interfaces attached to the individual vale(4) switches on the host).
[ Even more impressive: pf(4) runs in a VIMAGE jail in that guest,
utilizing those vale(4) interfaces. Reason for that complicated setup:
Closest hardware abstraction possible. The setup (guest) should be
easily migratable to real hardware ].
> The right way to do it imho would be to write your own (userspace)
> netmap application that forwards packets between your bhyve guests and
> the NIC, prepending/stripping VLAN headers according to configuration
> (e.g. guest A is configured to be on VLAN 100, guest B on VLAN 200), etc.
> I think this would be a very interesting netmap application in general,
> and more importantly you would get the performance that you can't get
> with your setup.
I agree that having a userland application which, like you described,
utilizes netmap to enable minimalistic SDN features, would be a great
solution. But I would need really a lot of time, since my C skills are
lousy, and I really don't have any time, not even one more day.
I'll see if I can get any useful information with the kernel deadlock
debuging feature you suggested
(https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html),
as soon as the problem shows up again.
Since I forgot to add all production-RAM, I had to shutdown yesterday,
so the lockup counter was reset ;-)
Another last-minute change was with netmap ring size: I changed the
vale-uplink interface. The one I used for passthrough had 2 queues
(with EM_MULTIQUEUE support) and the one for the vale uplink onyl one,
and during evaluation phase I reduced rx/tx descriptors to make netmap's
default ring size working.
Now I use the 2-queue NIC with vale uplink and increased ring size to
81920 while leaving the hardware default of 4096 rx/tx desriptors.
But my wording wasn't technically correct I think, because I guess what
I'm suffering isn't a real deadlock in terms of locking, but any
netmap-internal lockup/overflow/limit/whatever. Just guesing here! I
don't know netmap code! I only link symptoms, and since that setup is
working really nice for some limited time, I hoped you or any other
netmap expert could teach me how to find the root cause.
Your sentence about FreeBSD's netmap-interface-emulation leaves a bad
presentiment...
Thank you very much,
-harry
From owner-freebsd-net@freebsd.org Tue Nov 21 11:54:19 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 17384DEBFA4
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 11:54:19 +0000 (UTC) (envelope-from
s-2pptwqm0m71hfkvnuyao7l5j0pcdh7you9byn5lh603zvk4pecq4p8wy@bounce.linkedin.com)
Received: from maile-ce.linkedin.com (maile-ce.linkedin.com [108.174.6.197])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.linkedin.com",
Issuer "DigiCert SHA2 Secure Server CA" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id C8ED46AEFB
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 11:54:18 +0000 (UTC)
(envelope-from
s-2pptwqm0m71hfkvnuyao7l5j0pcdh7you9byn5lh603zvk4pecq4p8wy@bounce.linkedin.com)
From: =?UTF-8?B?546L6ZGr54Sx?= <messages-noreply@linkedin.com>
Message-ID: <257285933.713565.1511265256079.JavaMail.app@lsg1-app0216.prod.linkedin.com>
Subject: =?UTF-8?B?546L6ZGr54Sx6YKA6K+35oKo5Yqg5YWl6aKG6Iux?=
MIME-Version: 1.0
To: <freebsd-net@freebsd.org>
Date: Tue, 21 Nov 2017 11:54:16 +0000 (UTC)
X-LinkedIn-Class: INVITE-GUEST
X-LinkedIn-Template: invite_guest
X-LinkedIn-fbl: m2-aszv4g20i20htmn0e594n16r0ufztaw1tzzvogqv71532dus2pae958720bsb4vc4hxhke2pimd46jpxdmx1c8xd8qtes9fwmsf33p
X-LinkedIn-Id: xdi44-ja9kb81v-ew
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 11:54:19 -0000
=E7=8E=8B=E9=91=AB=E7=84=B1=E9=82=80=E8=AF=B7=E6=82=A8=E5=8A=A0=E5=85=A5=E5=
=85=A8=E7=90=83=E9=A2=86=E5=85=88=E7=9A=84=E8=81=8C=E4=B8=9A=E7=A4=BE=E4=BA=
=A4=E7=BD=91=E7=AB=99 LinkedIn (=E9=A2=86=E8=8B=B1)=E3=80=82=E9=A2=86=E8=8B=
=B1=E8=83=BD=E5=B8=AE=E5=8A=A9=E6=82=A8=E7=AE=A1=E7=90=86=E8=81=8C=E4=B8=9A=
=E7=94=9F=E6=B6=AF=EF=BC=8C=E8=AE=A9=E6=82=A8=E6=8E=A5=E8=A7=A6=E5=88=B0=E5=
=85=A8=E7=90=83=E5=90=84=E5=9C=B0=E7=9A=84=E5=B7=A5=E4=BD=9C=E6=9C=BA=E4=BC=
=9A=E3=80=82 =E5=BF=AB=E6=9D=A5=E5=8A=A0=E5=85=A5=E9=A2=86=E8=8B=B1=EF=BC=
=8C=E5=88=9B=E5=BB=BA=E6=82=A8=E7=9A=84=E8=81=8C=E4=B8=9A=E6=A1=A3=E6=A1=88=
=EF=BC=8C=E8=BD=BB=E6=9D=BE=E6=8B=93=E5=B1=95=E8=81=8C=E5=9C=BA=E4=BA=BA=E8=
=84=89=EF=BC=81
=E7=8E=8B=E9=91=AB=E7=84=B1
=E6=B7=B1=E5=9C=B3=E5=B8=82=E5=8D=8E=E8=9E=8D=E5=87=AF=E7=A7=91=E6=8A=80=E6=
=9C=89=E9=99=90=E5=85=AC=E5=8F=B8 - =E6=80=BB=E7=BB=8F=E7=90=86
=E4=B8=AD=E5=9B=BD =E5=B9=BF=E4=B8=9C =E6=B7=B1=E5=9C=B3
=E6=8E=A5=E5=8F=97=E9=82=80=E8=AF=B7: https://www.linkedin.com/comm/start/a=
ccept-invitation?sharedKey=3DkdBMJXHW&invitationId=3D6338700858955530248&tr=
k=3Deml-china-m2g-a-cta&trkEmail=3Deml-invite_guest-null-31-null-null-xdi44=
%7Eja9kb81v%7Eew-ssuw-start%7Esignup%7Ewarm&lipi=3Durn%3Ali%3Apage%3Aemail_=
invite_guest%3BcYV6WddyTleNt7TNpMv1Sg%3D%3D
=E6=9C=89=E4=BC=9A=E5=91=98=E9=82=80=E8=AF=B7=E6=82=A8=E5=BB=BA=E7=AB=8B=E8=
=81=94=E7=B3=BB=E3=80=82=E5=9C=A8=E2=80=9C=E7=8C=9C=E6=82=A8=E8=AE=A4=E8=AF=
=86=E2=80=9D=E7=AD=89=E5=8A=9F=E8=83=BD=E4=B8=AD=EF=BC=8C=E9=A2=86=E8=8B=B1=
=E5=B0=86=E4=BD=BF=E7=94=A8=E6=82=A8=E7=9A=84=E9=82=AE=E7=AE=B1=E5=9C=B0=E5=
=9D=80=E6=9D=A5=E5=90=91=E4=BC=9A=E5=91=98=E6=8E=A8=E8=8D=90=E4=BA=BA=E8=84=
=89=E3=80=82=E5=9C=A8=E6=AD=A4=E5=A4=84=E9=80=80=E8=AE=A2: https://www.link=
edin.com/e/v2?e=3Dxdi44-ja9kb81v-ew&t=3Dlun&midToken=3DAQFmrFVhGEd36Q&ek=3D=
invite_guest&loid=3DAQFG2Uc-l29EvwAAAV_ebcIvyqsvh1iov-6ykOCp9vSfTr4drnTZZ5V=
4CIEgx7qycDaCydxJdHGEDtv2dUzroBAXx0CaoUvpc5ZykOTt8A&eid=3Dxdi44-ja9kb81v-ew
=E6=AD=A4=E9=82=AE=E4=BB=B6=E7=9A=84=E6=94=B6=E4=BB=B6=E4=BA=BA=E6=98=AFfre=
ebsd-net@freebsd.org=E3=80=82
If you need assistance or have questions, please contact LinkedIn Customer =
Service: https://www.linkedin.com/e/v2?e=3Dxdi44-ja9kb81v-ew&lipi=3Durn%3Al=
i%3Apage%3Aemail_invite_guest%3BcYV6WddyTleNt7TNpMv1Sg%3D%3D&a=3DcustomerSe=
rviceUrl&ek=3Dinvite_guest
=C2=A9 2017 LinkedIn Corporation, 1000 West Maude Avenue, Sunnyvale, CA 940=
85.LinkedIn =E5=92=8C LinkedIn =E6=A0=87=E5=BF=97=E6=98=AF=E9=A2=86=E8=8B=
=B1=E7=9A=84=E6=B3=A8=E5=86=8C=E5=95=86=E6=A0=87=E3=80=82
From owner-freebsd-net@freebsd.org Tue Nov 21 13:26:29 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 BC41BDEED4E
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 13:26:29 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com
[IPv6:2607:f8b0:400d:c09::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 730486E95D
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 13:26:29 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: by mail-qk0-x22f.google.com with SMTP id w125so11971646qkb.6
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 05:26:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=GYoPBPInMrhqNzwh9LZBRHKk1ZONStGdcgPlkXuLhBI=;
b=hr8iwvOZswcAlrRJjEfguLAKQx2MDb7nXiLnl5zWoAJniakbT5RicSAubCKW9eLQ+f
m6kMV6q8H0k+sA5xI2mUffPRPOmQfAji3tHYqXQm18fMdXTLRXeOt0webhI3EtqjJaLK
BqFoEPyOhNgcyrfcFXITn/aD8qXpsmp7TyPGpo7uR/X2gdO4vVgPjgHXZmuifFaPZGdJ
y4YFeJLLr7bzJh8fPBC7gfwaUs/D2sopSubL3cCe0kCpLvgRZvJsQ4Mh1tRR8FDrSJkA
3Y8+FefBG/FvYt6riAuRVLeVxED8OyRNdfBlgpLP7sDwIw18WfaWAooaTfq71Fgkb+8g
6mKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=GYoPBPInMrhqNzwh9LZBRHKk1ZONStGdcgPlkXuLhBI=;
b=FvYj0lalrE0qKOyjNFIczaCn116CAte8ZBlmcEbsI6Lm7ibyNHcYgDi8ZD4zL6f0mX
BldUZTNteg0X2gIc3yzU79pOequHSSL/SiX6yGBNJDcNPXHDyO+h4AX6XLsO3s8aRj/I
TTIED1UFjzPSXCSyLvWbwqpwDcmywIC4EVxmxMz67pOV0ZfQhqgkkZNthpx6rAEgzpqO
n06byCF/CShsLwcpaLxYqpXCuzue7+Dbz5OqVf6IbgEoVmXmhMT7nEaVWFVqhT3CA0VG
m+oVO8KRUMHvh6pIsILAmsp8FmCH6nGtKYkFAkgYYjpA5FNcBGxMPZ6dRLCz47BAuzLT
/kWw==
X-Gm-Message-State: AJaThX47VO/YH02C2sG1+2dDtB57GLjr6QCiySlbhsSc2nic5Dlbxl55
s7T4VTURHrSWC8hr/yEyg0uY0HX+uwVK3KY43B4=
X-Google-Smtp-Source: AGs4zMb+xyCgZs3BeS/KUZPaPz8z/6bvlAvw9ZiFrYzjWp2AU7NtLxf8eOqObYdmhCbOTDE2eCCMXWPN4oFegVdcmbg=
X-Received: by 10.55.48.199 with SMTP id w190mr11247855qkw.87.1511270788358;
Tue, 21 Nov 2017 05:26:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.174.25 with HTTP; Tue, 21 Nov 2017 05:26:27 -0800 (PST)
In-Reply-To: <5A13F8A8.2020209@omnilan.de>
References: <5A0F14CD.3040407@omnilan.de>
<CA+_eA9giPsMJ2_O1CLvOro=rMm5TaJyQ-et_U01Re5J9+9VSqg@mail.gmail.com>
<5A13F8A8.2020209@omnilan.de>
From: Vincenzo Maffione <v.maffione@gmail.com>
Date: Tue, 21 Nov 2017 14:26:27 +0100
Message-ID: <CA+_eA9g85z0jkgR7of__x18K9muG4YouOgXKa5ySw16D=YE19g@mail.gmail.com>
Subject: Re: netmap/vale periodic deadlock
To: Harry Schmalzbauer <freebsd@omnilan.de>
Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
Giuseppe Lettieri <g.lettieri@iet.unipi.it>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 13:26:29 -0000
It may be that your is not a deadlock but some kind of crash. Enabling
debugging features would probably help (e.g. to get a stack trace).
Maybe your lockup/crash happened because you did some reconfiguration (ring
size, number of rings, etc.) while netmap was active and doing so you
triggered
some hidden bug.
You probably need to enable all these options
https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne=
ldebug-options.html
2017-11-21 10:58 GMT+01:00 Harry Schmalzbauer <freebsd@omnilan.de>:
> Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39 (localt=
ime):
> > Hi,
> > It's hard to say, specially because it happens after two days of
> > normal use.
> > Can't you enable deadlock debugging features in your kernel?
> > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/
> kerneldebug-deadlocks.html
> >
> > However, if I understand correctly you have created some VLAN interface=
s
> > vlan0, vlan1, vlan2, ... on top of a NIC (say em0). And you have
> > attached each VLAN interface to a vale switch:
> >
> > # vale-ctl -a vale0:vlan0
> > # vale-ctl -a vale1:vlan1
> > # vale-ctl -a vale2:vlan2
> >
> > and each VALE switch is attached to a different set of bhyve guests.
>
> Hello Vincenzo,
>
> thank you very much for your help again!
>
> Your assumption is correct, here's my vale-ctl:
> 603.811416 bdg_ctl [148] bridge:0 port:0 vale1:nic1_dmz
> 603.811428 bdg_ctl [148] bridge:0 port:1 vale1:styx0
> 603.811430 bdg_ctl [148] bridge:0 port:2 vale1:korso
> 603.811432 bdg_ctl [148] bridge:0 port:3 vale1:kallisto
>
> 603.811434 bdg_ctl [148] bridge:1 port:0 vale2:nic1_inop
> 603.811435 bdg_ctl [148] bridge:1 port:1 vale2:styx0
>
> 603.811437 bdg_ctl [148] bridge:2 port:0 vale3:nic1_vnl
> 603.811439 bdg_ctl [148] bridge:2 port:1 vale3:styx0
>
> 603.811441 bdg_ctl [148] bridge:3 port:0 vale4:nic1_egn
> 603.811442 bdg_ctl [148] bridge:3 port:1 vale4:styx0
> 603.811444 bdg_ctl [148] bridge:3 port:2 vale4:preed
> =E2=80=A6
>
>
> > If this is the case, although you are allowed to do that, I don't think
> > it's a convenient way to use netmap.
> > Since VLAN interfaces like vlan0 do not have (and cannot have) native
> > netmap support, you are falling back to emulated netmap adapters (which
> > are probably buggy on FreeBSD, specially when combined with VALE).
> > Apart from bugs I think that with this setup you can't get decent
> > performance that would justify using netmap rather than the standard
> > kernel bridge and TAP devices.
>
> I'm aware about the lost netmap-performace-benefit due to emulated
> netmap fallback.
> But there were some resonons why I chose vale(4) instead if_bridge(4):
>
> 1) Inter-Guest-traffic (virtio-net causes lot of LAPIC/IRQ overhead, but
> still less overhead than tap(4)/if_bridge(4))
>
> 2) Future ptnetmap(4) upgrade path (which should save a lot of LAPIC/IRQ
> CPU cycles and unleash huge performace benefits with inter-vm traffic)
>
> 3) Admin-mess and MTU limitation. Each if_bridge(4) causes a host-stack
> interface, which I don't use and which spams ifconfig(8) output; which
> if_vtnet(4) even doubles.
> Most important disadvantage: if_bridge(4) needs all members to have
> exactly the same MTU. This has been a problem for me many times over
> the last years in various setups.
>
> So with my current setup the overhead/efficiency of host-external packet
> flow of
> bhyve_virtio-net+dyn_vale_port+vale(4)
> is equal to
> bhyve_virtio-net+if_vtnet(4)+if_bridge(4)
>
> But I have less disadvanteges with vale(4); as long as emulated netmap
> mode doesn't destabilize my setup :-(
>
>
> My second choice was ng_bridge(4). Which I made great experiences in my
> router-vm, running on that host in question (and in turn uses virtio-net
> interfaces attached to the individual vale(4) switches on the host).
> [ Even more impressive: pf(4) runs in a VIMAGE jail in that guest,
> utilizing those vale(4) interfaces. Reason for that complicated setup:
> Closest hardware abstraction possible. The setup (guest) should be
> easily migratable to real hardware ].
>
>
> > The right way to do it imho would be to write your own (userspace)
> > netmap application that forwards packets between your bhyve guests and
> > the NIC, prepending/stripping VLAN headers according to configuration
> > (e.g. guest A is configured to be on VLAN 100, guest B on VLAN 200), et=
c.
> > I think this would be a very interesting netmap application in general,
> > and more importantly you would get the performance that you can't get
> > with your setup.
>
> I agree that having a userland application which, like you described,
> utilizes netmap to enable minimalistic SDN features, would be a great
> solution. But I would need really a lot of time, since my C skills are
> lousy, and I really don't have any time, not even one more day.
>
I see. But just FYI, there isn't that much to implement :)
Cheers,
Vincenzo
>
>
> I'll see if I can get any useful information with the kernel deadlock
> debuging feature you suggested
> (https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/
> kerneldebug-deadlocks.html),
> as soon as the problem shows up again.
> Since I forgot to add all production-RAM, I had to shutdown yesterday,
> so the lockup counter was reset ;-)
> Another last-minute change was with netmap ring size: I changed the
> vale-uplink interface. The one I used for passthrough had 2 queues
> (with EM_MULTIQUEUE support) and the one for the vale uplink onyl one,
> and during evaluation phase I reduced rx/tx descriptors to make netmap's
> default ring size working.
> Now I use the 2-queue NIC with vale uplink and increased ring size to
> 81920 while leaving the hardware default of 4096 rx/tx desriptors.
>
> But my wording wasn't technically correct I think, because I guess what
> I'm suffering isn't a real deadlock in terms of locking, but any
> netmap-internal lockup/overflow/limit/whatever. Just guesing here! I
> don't know netmap code! I only link symptoms, and since that setup is
> working really nice for some limited time, I hoped you or any other
> netmap expert could teach me how to find the root cause.
> Your sentence about FreeBSD's netmap-interface-emulation leaves a bad
> presentiment...
>
> Thank you very much,
>
> -harry
>
--=20
Vincenzo Maffione
From owner-freebsd-net@freebsd.org Tue Nov 21 13:46:41 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 A7E50DEF600
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 13:46:41 +0000 (UTC)
(envelope-from freebsd@omnilan.de)
Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130])
(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 2A1C06F346
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 13:46:41 +0000 (UTC)
(envelope-from freebsd@omnilan.de)
Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135])
by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id vALDkdvj072154;
Tue, 21 Nov 2017 14:46:39 +0100 (CET)
(envelope-from freebsd@omnilan.de)
Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mh0.gentlemail.de (Postfix) with ESMTPSA id E54CD94F;
Tue, 21 Nov 2017 14:46:38 +0100 (CET)
Message-ID: <5A142E3E.5010002@omnilan.de>
Date: Tue, 21 Nov 2017 14:46:38 +0100
From: Harry Schmalzbauer <freebsd@omnilan.de>
Organization: OmniLAN
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE;
rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: Vincenzo Maffione <v.maffione@gmail.com>
CC: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
Giuseppe Lettieri <g.lettieri@iet.unipi.it>
Subject: Re: netmap/vale periodic deadlock
References: <5A0F14CD.3040407@omnilan.de>
<CA+_eA9giPsMJ2_O1CLvOro=rMm5TaJyQ-et_U01Re5J9+9VSqg@mail.gmail.com>
<5A13F8A8.2020209@omnilan.de>
<CA+_eA9g85z0jkgR7of__x18K9muG4YouOgXKa5ySw16D=YE19g@mail.gmail.com>
In-Reply-To: <CA+_eA9g85z0jkgR7of__x18K9muG4YouOgXKa5ySw16D=YE19g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7
(mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]);
Tue, 21 Nov 2017 14:46:39 +0100 (CET)
X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ;
Sender-helo: mh0.gentlemail.de; )
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 13:46:41 -0000
Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 14:26 (localtime):
> It may be that your is not a deadlock but some kind of crash. Enabling
> debugging features would probably help (e.g. to get a stack trace).
> Maybe your lockup/crash happened because you did some reconfiguration
> (ring size, number of rings, etc.) while netmap was active and doing so
> you triggered
> some hidden bug.
The host was completely untouched when these lockups occured in late
test phase. Only guests were configured/utilized.
No previous (short term stress) test had caused any problem in that
path. It first showed up with real-world (unstressed) tests.
The last-minute change I described was with powered down guests and the
host was rebooted (ppt dev changed in loader.conf).
The host isn't going to be reconfigured in any way.
Let's wait and see if the lockup shows up again (after not limiting NICs
rx/tx descriptors and increasing netmap ring size).
Considering your suspect that emulated netmap code in FreeBSD might be
buggy, and the fact that I'm not able to debug it myself, I guess
switching from vale to netgraph is my best bet. It's not much effort
and causes almost no downtime. But it would disallow future ptnetmap
extension...
I'd prefere to stay with vale, although I'm using emulated mode only...
So at first occurance, I'll install the debug kernel and see if that
makes any difference.
Thanks,
-harry
From owner-freebsd-net@freebsd.org Tue Nov 21 16:14:23 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 5D8B9DF323A
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 16:14:23 +0000 (UTC)
(envelope-from csalgau@users.sourceforge.net)
Received: from mx02.buh.bitdefender.com (mx02.bbu.dsd.mx.bitdefender.com
[91.199.104.133])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "*.mx.bitdefender.com", Issuer "thawte SSL CA - G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id C69F374993
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 16:14:22 +0000 (UTC)
(envelope-from csalgau@users.sourceforge.net)
Received: (qmail 6302 invoked from network); 21 Nov 2017 18:14:14 +0200
Received: from mx01robo.bbu.dsd.mx.bitdefender.com (10.17.80.60)
by mx02.buh.bitdefender.com with AES128-GCM-SHA256 encrypted SMTP;
21 Nov 2017 18:14:14 +0200
Received: (qmail 15200 invoked from network); 21 Nov 2017 18:14:13 +0200
Received: from unknown (HELO ?10.210.20.54?) (10.210.20.54)
by mx01robo.bbu.dsd.mx.bitdefender.com with SMTP; 21 Nov 2017 18:14:13 +0200
Subject: Re: BPF packet pagesize limit
To: Kristof Provost <kristof@sigsegv.be>
Cc: freebsd-net@freebsd.org
References: <966f384c-10b4-d018-efb1-68a7064c9521@users.sourceforge.net>
<A2A39E3C-8A17-4C17-A52D-0EF72F809F99@sigsegv.be>
From: Catalin Salgau <csalgau@users.sourceforge.net>
Openpgp: preference=signencrypt
Message-ID: <e52b9a29-ccc3-af47-9fdb-4e856bda4e49@users.sourceforge.net>
Date: Tue, 21 Nov 2017 18:14:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101
Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <A2A39E3C-8A17-4C17-A52D-0EF72F809F99@sigsegv.be>
Content-Language: en-GB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 16:14:23 -0000
On 20/11/2017 11:26 pm, Kristof Provost wrote:
> On 19 Nov 2017, at 19:49, Catalin Salgau wrote:
>
> I'm trying to address the limitation in (upstream) net/vblade that was
> brought up in
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205164
> This is related to writes larger than hw.pagesize but smaller than the
> configured MTU with BPF.
> I traced this to sys/net/bpf.c where calls to bpfwrite() will use
> bpf_movein() which in turn uses m_get2() to allocate a single mbuf. This
> will fail if the requested mbuf size is larger than MJUMPAGESIZE
> (defined as PAGE_SIZE on x86). I believe this should use m_getm2() and
> populate multiple mbufs.
> Code in NetBSD explicitly notes that they omit mbuf chaining, but this
> is not documentated behaviour in the man page.
>
> Your analysis looks correct.
>
> Any chance of having this fixed in a supported release, or getting a
> usable/documented workaround?
>
> Can you see if this works for you?
>
> |diff --git a/sys/net/bpf.c b/sys/net/bpf.c index
> b176856cf35..b9ff40699bb 100644 --- a/sys/net/bpf.c +++ b/sys/net/bpf.c
> @@ -547,9 +547,11 @@ bpf_movein(struct uio *uio, int linktype, struct
> ifnet *ifp, struct mbuf **mp, if (len < hlen || len - hlen >
> ifp->if_mtu) return (EMSGSIZE); - m = m_get2(len, M_WAITOK, MT_DATA,
> M_PKTHDR); + m = m_getm2(NULL, len, M_WAITOK, MT_DATA, M_PKTHDR); if (m
> == NULL) return (EIO); + KASSERT(m->m_next == NULL, ("mbuf chains not
> supported here")); + m->m_pkthdr.len = m->m_len = len; *mp = m; |
>
> It’s a little icky to trust that this will produce a single mbuf rather
> than a chain, but it appears to be the case. Sadly the rest of the bpf
> code (and especially bpf_filter()) really needs the mbuf to have a
> single contiguous buffer.
Actually m_getm2() will always produce a chain for a size larger than
the page size, due to m_getjcl() being called with MJUMPAGESIZE every
time a large buffer is requested. The function could probably be called
with MJUM9BYTES in this case, but this should be dependant on backing
interface configuration(?).
On the other hand, as you pointed out, bpf_filter really needs a single
mbuf, and so does the call to uiomove(). The filter call, as it stands,
will overread due to being passed the larger len value, instead of the
mbuf's len.
As a note, to avoid the overruns and related panics, I'd suggest anyone
else trying this replace the assertion with an explicit
if (m->m_next != NULL) {
error = EIO;
goto bad;
}
It is quite clear to me that changing bpf_filter to handle a chain would
be very expensive for the BPF VM. One could probably have a caveat that
the filter will only run on the first mbuf(for reads and writes). I
don't think it would be legal to alter the uio in-place and run the
filter on that, if it's contiguous.
Any alternatives to this? I couldn't figure out if zero-copy mode chains
to bpf_write calls or not. Any insights?
Thanks
>
> Regards,
> Kristof
>
From owner-freebsd-net@freebsd.org Tue Nov 21 16:44:54 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 68D43DF3C54
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 16:44:54 +0000 (UTC)
(envelope-from srs0=1gm5=ct=sigsegv.be=kristof@codepro.be)
Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
bits))
(Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 26CFE758C2
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 16:44:53 +0000 (UTC)
(envelope-from srs0=1gm5=ct=sigsegv.be=kristof@codepro.be)
Received: from [172.16.5.2] (vega.codepro.be [IPv6:2a01:4f8:162:1127::3])
(Authenticated sender: kp)
by venus.codepro.be (Postfix) with ESMTPSA id 0CCC913D25;
Tue, 21 Nov 2017 17:44:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail;
t=1511282692; bh=Tp7BG8N2QKyNoVqiHqdsMgVdKiPtAJBgSXZOJ++T3So=;
h=From:To:Cc:Subject:Date:In-Reply-To:References;
b=RLlEOyEou2GaQzxaehPDGG3NGjDl4aCER5yNsiVnPbq/m5tdDmWbP1uvjBk6SVuRa
xM+ysUBeorvtfrAnRC9EJLhOx77XBfcq1+p4zQwomK7iK9pnuJlkILjsGB+b0Z7fli
PMSQ0CC/HTp7zpRXGyswRoAGNd8mH2PfSsOVWlSg=
From: "Kristof Provost" <kristof@sigsegv.be>
To: "Catalin Salgau" <csalgau@users.sourceforge.net>
Cc: freebsd-net@freebsd.org
Subject: Re: BPF packet pagesize limit
Date: Tue, 21 Nov 2017 17:44:59 +0100
Message-ID: <65E7BF88-EBEA-47DA-806B-5BFD6783F2B4@sigsegv.be>
In-Reply-To: <e52b9a29-ccc3-af47-9fdb-4e856bda4e49@users.sourceforge.net>
References: <966f384c-10b4-d018-efb1-68a7064c9521@users.sourceforge.net>
<A2A39E3C-8A17-4C17-A52D-0EF72F809F99@sigsegv.be>
<e52b9a29-ccc3-af47-9fdb-4e856bda4e49@users.sourceforge.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (2.0BETAr6096)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 16:44:54 -0000
On 21 Nov 2017, at 17:14, Catalin Salgau wrote:
> Actually m_getm2() will always produce a chain for a size larger than
> the page size, due to m_getjcl() being called with MJUMPAGESIZE every
> time a large buffer is requested. The function could probably be
> called
> with MJUM9BYTES in this case, but this should be dependant on backing
> interface configuration(?).
I’d be tempted to just always allocate MJUM9BYTES, but that’s
wasteful of memory.
I believe the most common use case for this code is the DHCP client,
where large packets are not a requirement.
There doesn’t seem to be an obvious way to allocate a contiguous mbuf,
other than allocating the memory yourself, and creating an M_EXT mbuf.
Some care must be taken to ensure the memory is correctly freed, but at
first glance that looks possible.
> On the other hand, as you pointed out, bpf_filter really needs a
> single
> mbuf, and so does the call to uiomove(). The filter call, as it
> stands,
> will overread due to being passed the larger len value, instead of the
> mbuf's len.
> As a note, to avoid the overruns and related panics, I'd suggest
> anyone
> else trying this replace the assertion with an explicit
> if (m->m_next != NULL) {
> error = EIO;
> goto bad;
> }
>
Yes, that would be better.
Regards,
Kristof
From owner-freebsd-net@freebsd.org Tue Nov 21 18:54:29 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 C5875DF6C33
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 18:54:29 +0000 (UTC)
(envelope-from rysto32@gmail.com)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com
[IPv6:2607:f8b0:400d:c09::230])
(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 7F1B37B9AE
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 18:54:29 +0000 (UTC)
(envelope-from rysto32@gmail.com)
Received: by mail-qk0-x230.google.com with SMTP id f63so13466179qke.8
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 10:54:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=LlBgSYXeORlbvuBy76yVyfrWWY52GH2SBBjYANIid78=;
b=q3wS7asksSybsY/t/Wr0RV5HoP2NwOfReWifTp1ZuNvtQTjmBfj/cQxucFWvMb53IE
Q6W40aSX3y5/8/LL7MbeDAGFXiVRlR71zOqy2KiTH3Ob/oRMlB+qjhWNhEgAnGum3KyZ
x2gzGbnsSR7L+GMBQHdrrMdVV7AeoMcM6tFOblF3/YzvB0o6oSm7cVhMidSYa3xd+jdy
hOtUnskkksO3F0VmhhNH9QcTrZHYWCrqLsu+nasPX0aLBoMrGye+Fz6McLYDMm9WZXax
p5+fL5hpObMcSyjxA+yn785vsp8NBR0Djc1LVVVV5jMK728Ygudgt9YUFPPS4bYSchpV
EFrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=LlBgSYXeORlbvuBy76yVyfrWWY52GH2SBBjYANIid78=;
b=Oo7ubPW0KkweKECKWdvRiOtbPQ9tnwffn4sttKTp+9lnodxuC3JfOGwofk89BNIyoA
bJK+GlPULU+YktdRwnlTy9KQM/7W6zuSkb/WaJTY9nt7pN87oToNBFeN0oQSBbhZirdn
Lb/im6y5Y1Nqly2diA+bYYNMVytD22MvTRJEThvanxdmIli2PpwjZo48Kxup+u4UhAB/
oQ3yf5DN/ZkYWcLUzb3+DW6Hie0Pd0qHnH5kgHJFBAvqmjy4lBzObsjCUgzBHtVUftw6
6bq9s2eLQ4qWgu/mhHwnCN+APqyWKOY1pdZZaupVWyc3xZQtkZt2WaC3i8COfNjc6xcg
rdgA==
X-Gm-Message-State: AJaThX6s/cKgMEuQnviWKgp+Spwlo6QJy02m7qkgpDIv0NNrhgQ96Foi
SGRKKMSMIrALwcT3ygJCK99Q4qE9O7gkLjMfbec=
X-Google-Smtp-Source: AGs4zMb3O145mDOZv5LXi5li2N6qqFcmcpXynPbNMwejmSpuwbov+5idAzqu1vHVLEbbC72a4jSvrzVZFDt0awjTzC8=
X-Received: by 10.55.221.212 with SMTP id u81mr28379124qku.174.1511290468623;
Tue, 21 Nov 2017 10:54:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.39.211 with HTTP; Tue, 21 Nov 2017 10:54:28 -0800 (PST)
In-Reply-To: <65E7BF88-EBEA-47DA-806B-5BFD6783F2B4@sigsegv.be>
References: <966f384c-10b4-d018-efb1-68a7064c9521@users.sourceforge.net>
<A2A39E3C-8A17-4C17-A52D-0EF72F809F99@sigsegv.be>
<e52b9a29-ccc3-af47-9fdb-4e856bda4e49@users.sourceforge.net>
<65E7BF88-EBEA-47DA-806B-5BFD6783F2B4@sigsegv.be>
From: Ryan Stone <rysto32@gmail.com>
Date: Tue, 21 Nov 2017 13:54:28 -0500
Message-ID: <CAFMmRNzw0SFBZKH5YNgnR2d7K0LyF=vD7dv9p5f_xquZ4BW69A@mail.gmail.com>
Subject: Re: BPF packet pagesize limit
To: Kristof Provost <kristof@sigsegv.be>
Cc: Catalin Salgau <csalgau@users.sourceforge.net>,
freebsd-net <freebsd-net@freebsd.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 18:54:29 -0000
Do not allocate MJUM9BYTES clusters under any circumstances. Trying
to allocate them when the system is under memory pressure is
enormously expensive and stands a good chance of livelocking the
system if you try to allocate too many too quickly, even when
allocating with M_NOWAIT.
Honestly, support for clusters > PAGE_SIZE should probably be retired
from the kernel given the significant havoc they cause.
From owner-freebsd-net@freebsd.org Tue Nov 21 20:48:15 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 5EFEFD94370
for <freebsd-net@mailman.ysv.freebsd.org>;
Tue, 21 Nov 2017 20:48:15 +0000 (UTC)
(envelope-from freebsd@omnilan.de)
Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130])
(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 D611C7F6CF
for <freebsd-net@freebsd.org>; Tue, 21 Nov 2017 20:48:14 +0000 (UTC)
(envelope-from freebsd@omnilan.de)
Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135])
by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id vALKmBqk076238;
Tue, 21 Nov 2017 21:48:11 +0100 (CET)
(envelope-from freebsd@omnilan.de)
Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mh0.gentlemail.de (Postfix) with ESMTPSA id 1114E9C2;
Tue, 21 Nov 2017 21:48:11 +0100 (CET)
Message-ID: <5A149107.9060507@omnilan.de>
Date: Tue, 21 Nov 2017 21:48:07 +0100
From: Harry Schmalzbauer <freebsd@omnilan.de>
Organization: OmniLAN
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE;
rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: Vincenzo Maffione <v.maffione@gmail.com>
CC: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
Giuseppe Lettieri <g.lettieri@iet.unipi.it>
Subject: Re: netmap/vale periodic deadlock
References: <5A0F14CD.3040407@omnilan.de>
<CA+_eA9giPsMJ2_O1CLvOro=rMm5TaJyQ-et_U01Re5J9+9VSqg@mail.gmail.com>
In-Reply-To: <CA+_eA9giPsMJ2_O1CLvOro=rMm5TaJyQ-et_U01Re5J9+9VSqg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7
(mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]);
Tue, 21 Nov 2017 21:48:11 +0100 (CET)
X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ;
Sender-helo: mh0.gentlemail.de; )
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 20:48:15 -0000
Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39 (localtime):
…
>
> If this is the case, although you are allowed to do that, I don't think
> it's a convenient way to use netmap.
> Since VLAN interfaces like vlan0 do not have (and cannot have) native
> netmap support, you are falling back to emulated netmap adapters (which
> are probably buggy on FreeBSD, specially when combined with VALE).
> Apart from bugs I think that with this setup you can't get decent
> performance that would justify using netmap rather than the standard
> kernel bridge and TAP devices.
Hello,
lockup happened earlier than expected.
This time 'vale-ctl' still reported (-l) the configuration.
One guest, using if_vtnet(4)-virtio-net#vale2:korso, showed:
dmz: watchdog timeout on queue 0
(dmz is the renamed if_vtnet(4))
I could attach tcpdump to the uplink interface and also to all vlan
children.
Complete silence everywhere. So it seems the nic stopped processing
anything.
Do you think that symptom could be caused by my special vale
integration, so that bugs in netmap emulation could crash the NIC?
Or is it unlikely that this is related.
I hadn't prepared a debug kernel for the host, so the machine rebooted
without again.
I think I'll have to start with replacing vale first, to narrow down
possible causes. Today I was lucky, the lockup happend after business
hours, but I won't rely on that.
At least I know if I really need to look for a debug netmap kernel, or
possibly there's something else...
Thanks,
-harry
From owner-freebsd-net@freebsd.org Wed Nov 22 08:04:55 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 3B411DE4137
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 22 Nov 2017 08:04:55 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com
[IPv6:2607:f8b0:400d:c09::231])
(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 E78C4715EE
for <freebsd-net@freebsd.org>; Wed, 22 Nov 2017 08:04:54 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: by mail-qk0-x231.google.com with SMTP id a142so15628098qkb.5
for <freebsd-net@freebsd.org>; Wed, 22 Nov 2017 00:04:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=56wjqg+iV9YX75E6CdeUPuEQ4hTgREksKE28bUdEh+M=;
b=lBbhcuOVHYUmXVXu3SDmQqiHnmAM88CB2d+n/qMFd4XMzOqFCvMMxR7PZ9zNxP4Czn
pUouPOSxFSrpm4Js9Qir+vvyk10bBrgEuri6Wlncke5v73E8azEyW/Uwh+yYrcNe9uUz
3IPAJUmSGXVwnUMwxmtHcA1faa76gYuxilq/xgIfPsuLqiaCJSl8GrDqvxHbrLP9diD4
tZ/F4agjdOMNKhKQ0qIkzn76CpCUJZdI2TitWrcArafMfgEbw0SpvYhQHipwZfaZmG6H
vOM8dDVt3qFEnzQAymNB5S12W4IlNBT2FhvlkgIwxYgWrYC2j4HChWw6oORSWCLl3F3l
0PeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=56wjqg+iV9YX75E6CdeUPuEQ4hTgREksKE28bUdEh+M=;
b=G03eDZWIQdBIlBN/LK6biHeBZZEwCTGDJt1yLtOk60OjxXCJGuYRgSRZx6zbnLwQxJ
cfL0o6znZp9je5lSj+G0tGhxcpWQvIn2QhqLV0TXqpvv143c8W26NwcudIledWPDfDrK
w9rB0EuimFWc+47geCK2K3D+nKKwhLWPeDD9QWmwPBs7NbJ+QY36phQdJEnlhmm3Vkew
Ixi5/dmRxIgU3zv1P6qh/q7DRwcbARWWyj/63jp8/5tGwu3LC6L381ffwSiGg5MwCcok
Zo9femIiGfso0f/gqcLK96aW8ToOBVNj9KJtbc831D5Y3gdmYMTiZXFV/YTLiyMWrBQd
qCZw==
X-Gm-Message-State: AJaThX5cFe6zv3BznOCIvRIkTkv5yiflxAf+g3hUxmrpWu23wLEyukUy
V3SIAjOdbiZRfrxohzFRCTOd2YmWw6FNPLHVeg8=
X-Google-Smtp-Source: AGs4zMbSsez/6XscPdZxInuybJM/vnPAJDnFvsvHWQF03pooKSZm9BT1G4ZokmPNczB9Gha6By6XW31Nl7OcSLFJ4r0=
X-Received: by 10.55.151.4 with SMTP id z4mr33117505qkd.173.1511337893846;
Wed, 22 Nov 2017 00:04:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.174.25 with HTTP; Wed, 22 Nov 2017 00:04:53 -0800 (PST)
In-Reply-To: <5A149107.9060507@omnilan.de>
References: <5A0F14CD.3040407@omnilan.de>
<CA+_eA9giPsMJ2_O1CLvOro=rMm5TaJyQ-et_U01Re5J9+9VSqg@mail.gmail.com>
<5A149107.9060507@omnilan.de>
From: Vincenzo Maffione <v.maffione@gmail.com>
Date: Wed, 22 Nov 2017 09:04:53 +0100
Message-ID: <CA+_eA9gW9mkCTr2JzMz4nqdhY+taGshStrVxLO3QOQ7MoUhWFg@mail.gmail.com>
Subject: Re: netmap/vale periodic deadlock
To: Harry Schmalzbauer <freebsd@omnilan.de>
Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
Giuseppe Lettieri <g.lettieri@iet.unipi.it>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Nov 2017 08:04:55 -0000
2017-11-21 21:48 GMT+01:00 Harry Schmalzbauer <freebsd@omnilan.de>:
> Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39 (localt=
ime):
> =E2=80=A6
> >
> > If this is the case, although you are allowed to do that, I don't think
> > it's a convenient way to use netmap.
> > Since VLAN interfaces like vlan0 do not have (and cannot have) native
> > netmap support, you are falling back to emulated netmap adapters (which
> > are probably buggy on FreeBSD, specially when combined with VALE).
> > Apart from bugs I think that with this setup you can't get decent
> > performance that would justify using netmap rather than the standard
> > kernel bridge and TAP devices.
>
> Hello,
>
> lockup happened earlier than expected.
> This time 'vale-ctl' still reported (-l) the configuration.
> One guest, using if_vtnet(4)-virtio-net#vale2:korso, showed:
> dmz: watchdog timeout on queue 0
> (dmz is the renamed if_vtnet(4))
>
> I could attach tcpdump to the uplink interface and also to all vlan
> children.
> Complete silence everywhere. So it seems the nic stopped processing
> anything.
>
> Do you think that symptom could be caused by my special vale
> integration, so that bugs in netmap emulation could crash the NIC?
> Or is it unlikely that this is related.
>
> I hadn't prepared a debug kernel for the host, so the machine rebooted
> without again.
> I think I'll have to start with replacing vale first, to narrow down
> possible causes. Today I was lucky, the lockup happend after business
> hours, but I won't rely on that.
> At least I know if I really need to look for a debug netmap kernel, or
> possibly there's something else...
>
> Thanks,
>
> -harry
>
I can't really say anything without a stack trace or meaningful logs.
There is a thing that you may do to see if the bug comes out of a bad
interaction between
emulated netmap and VALE.
Instead of attaching the vlan interfaces to VALE you can connect VALE to
the vlan interface
through the "bridge" program. In this way nothing changes from the
functional point of view,
but you are not attaching anymore the VLAN interface to VALE (and you are
using an additional process).
So instead of
# vale-ctl vale0:vlan0
you would have
# bridge netmap:vlan0 vale0:vv # "vv" can be anything
Cheers,
Vincenzo
--=20
Vincenzo Maffione
From owner-freebsd-net@freebsd.org Wed Nov 22 08:39:20 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 38521DE4F26
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 22 Nov 2017 08:39:20 +0000 (UTC)
(envelope-from freebsd@omnilan.de)
Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130])
(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 DC3697251F
for <freebsd-net@freebsd.org>; Wed, 22 Nov 2017 08:39:19 +0000 (UTC)
(envelope-from freebsd@omnilan.de)
Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135])
by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id vAM8dG2j084627;
Wed, 22 Nov 2017 09:39:16 +0100 (CET)
(envelope-from freebsd@omnilan.de)
Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mh0.gentlemail.de (Postfix) with ESMTPSA id 334C2AA0;
Wed, 22 Nov 2017 09:39:16 +0100 (CET)
Message-ID: <5A1537B3.9030603@omnilan.de>
Date: Wed, 22 Nov 2017 09:39:15 +0100
From: Harry Schmalzbauer <freebsd@omnilan.de>
Organization: OmniLAN
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE;
rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: Vincenzo Maffione <v.maffione@gmail.com>
CC: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
Giuseppe Lettieri <g.lettieri@iet.unipi.it>
Subject: Re: netmap/vale periodic deadlock
References: <5A0F14CD.3040407@omnilan.de>
<CA+_eA9giPsMJ2_O1CLvOro=rMm5TaJyQ-et_U01Re5J9+9VSqg@mail.gmail.com>
<5A149107.9060507@omnilan.de>
<CA+_eA9gW9mkCTr2JzMz4nqdhY+taGshStrVxLO3QOQ7MoUhWFg@mail.gmail.com>
In-Reply-To: <CA+_eA9gW9mkCTr2JzMz4nqdhY+taGshStrVxLO3QOQ7MoUhWFg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7
(mx0.gentlemail.de [78.138.80.130]); Wed, 22 Nov 2017 09:39:16 +0100 (CET)
X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135;
Sender-helo: mh0.gentlemail.de; )
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Nov 2017 08:39:20 -0000
Bezüglich Vincenzo Maffione's Nachricht vom 22.11.2017 09:04 (localtime):
>
>
> 2017-11-21 21:48 GMT+01:00 Harry Schmalzbauer <freebsd@omnilan.de
> <mailto:freebsd@omnilan.de>>:
>
> Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39
> (localtime):
> …
> >
> > If this is the case, although you are allowed to do that, I don't think
> > it's a convenient way to use netmap.
> > Since VLAN interfaces like vlan0 do not have (and cannot have) native
> > netmap support, you are falling back to emulated netmap adapters (which
> > are probably buggy on FreeBSD, specially when combined with VALE).
> > Apart from bugs I think that with this setup you can't get decent
> > performance that would justify using netmap rather than the standard
> > kernel bridge and TAP devices.
>
> Hello,
>
> lockup happened earlier than expected.
> This time 'vale-ctl' still reported (-l) the configuration.
> One guest, using if_vtnet(4)-virtio-net#vale2:korso, showed:
> dmz: watchdog timeout on queue 0
> (dmz is the renamed if_vtnet(4))
>
> I could attach tcpdump to the uplink interface and also to all vlan
> children.
> Complete silence everywhere. So it seems the nic stopped processing
> anything.
>
> Do you think that symptom could be caused by my special vale
> integration, so that bugs in netmap emulation could crash the NIC?
> Or is it unlikely that this is related.
>
> I hadn't prepared a debug kernel for the host, so the machine rebooted
> without again.
> I think I'll have to start with replacing vale first, to narrow down
> possible causes. Today I was lucky, the lockup happend after business
> hours, but I won't rely on that.
> At least I know if I really need to look for a debug netmap kernel, or
> possibly there's something else...
>
> Thanks,
>
> -harry
>
>
>
> I can't really say anything without a stack trace or meaningful logs.
> There is a thing that you may do to see if the bug comes out of a bad
> interaction between
> emulated netmap and VALE.
> Instead of attaching the vlan interfaces to VALE you can connect VALE to
> the vlan interface
> through the "bridge" program. In this way nothing changes from the
> functional point of view,
> but you are not attaching anymore the VLAN interface to VALE (and you
> are using an additional process).
>
> So instead of
>
> # vale-ctl vale0:vlan0
>
> you would have
>
> # bridge netmap:vlan0 vale0:vv # "vv" can be anything
Hello Vincenzo,
thank you very much for that interesting hint.
I prepared a netgraph setup yesterday evening, but I'll try your
suggestion first. Unfortunately I don't have time to prepare a debug
kernel until next reboot (today evening), but maybe the result of this
config is interesting/meaningful using the same kernel.
Will keep you informed, thanks,
-harry
From owner-freebsd-net@freebsd.org Wed Nov 22 09:19:02 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 28AA9DE5CDB
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 22 Nov 2017 09:19:02 +0000 (UTC)
(envelope-from freebsd@omnilan.de)
Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130])
(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 B854373618
for <freebsd-net@freebsd.org>; Wed, 22 Nov 2017 09:19:01 +0000 (UTC)
(envelope-from freebsd@omnilan.de)
Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135])
by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id vAM9Ix7n084990;
Wed, 22 Nov 2017 10:18:59 +0100 (CET)
(envelope-from freebsd@omnilan.de)
Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mh0.gentlemail.de (Postfix) with ESMTPSA id 077F9AA9;
Wed, 22 Nov 2017 10:18:58 +0100 (CET)
Message-ID: <5A154102.10007@omnilan.de>
Date: Wed, 22 Nov 2017 10:18:58 +0100
From: Harry Schmalzbauer <freebsd@omnilan.de>
Organization: OmniLAN
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE;
rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: Vincenzo Maffione <v.maffione@gmail.com>
CC: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
Giuseppe Lettieri <g.lettieri@iet.unipi.it>
Subject: Re: netmap/vale periodic deadlock
References: <5A0F14CD.3040407@omnilan.de>
<CA+_eA9giPsMJ2_O1CLvOro=rMm5TaJyQ-et_U01Re5J9+9VSqg@mail.gmail.com>
<5A149107.9060507@omnilan.de>
<CA+_eA9gW9mkCTr2JzMz4nqdhY+taGshStrVxLO3QOQ7MoUhWFg@mail.gmail.com>
<5A1537B3.9030603@omnilan.de>
In-Reply-To: <5A1537B3.9030603@omnilan.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7
(mx0.gentlemail.de [78.138.80.130]); Wed, 22 Nov 2017 10:18:59 +0100 (CET)
X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135;
Sender-helo: mh0.gentlemail.de; )
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Nov 2017 09:19:02 -0000
Bezüglich Harry Schmalzbauer's Nachricht vom 22.11.2017 09:39 (localtime):
> Bezüglich Vincenzo Maffione's Nachricht vom 22.11.2017 09:04 (localtime):
>>
>> 2017-11-21 21:48 GMT+01:00 Harry Schmalzbauer <freebsd@omnilan.de
>> <mailto:freebsd@omnilan.de>>:
>>
>> Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39
>> (localtime):
>> …
>> >
>> > If this is the case, although you are allowed to do that, I don't think
>> > it's a convenient way to use netmap.
>> > Since VLAN interfaces like vlan0 do not have (and cannot have) native
>> > netmap support, you are falling back to emulated netmap adapters (which
>> > are probably buggy on FreeBSD, specially when combined with VALE).
>> > Apart from bugs I think that with this setup you can't get decent
>> > performance that would justify using netmap rather than the standard
>> > kernel bridge and TAP devices.
>>
>> Hello,
>>
>> lockup happened earlier than expected.
>> This time 'vale-ctl' still reported (-l) the configuration.
>> One guest, using if_vtnet(4)-virtio-net#vale2:korso, showed:
>> dmz: watchdog timeout on queue 0
>> (dmz is the renamed if_vtnet(4))
>>
>> I could attach tcpdump to the uplink interface and also to all vlan
>> children.
>> Complete silence everywhere. So it seems the nic stopped processing
>> anything.
>>
>> Do you think that symptom could be caused by my special vale
>> integration, so that bugs in netmap emulation could crash the NIC?
>> Or is it unlikely that this is related.
>>
>> I hadn't prepared a debug kernel for the host, so the machine rebooted
>> without again.
>> I think I'll have to start with replacing vale first, to narrow down
>> possible causes. Today I was lucky, the lockup happend after business
>> hours, but I won't rely on that.
>> At least I know if I really need to look for a debug netmap kernel, or
>> possibly there's something else...
>>
>> Thanks,
>>
>> -harry
>>
>>
>>
>> I can't really say anything without a stack trace or meaningful logs.
>> There is a thing that you may do to see if the bug comes out of a bad
>> interaction between
>> emulated netmap and VALE.
>> Instead of attaching the vlan interfaces to VALE you can connect VALE to
>> the vlan interface
>> through the "bridge" program. In this way nothing changes from the
>> functional point of view,
>> but you are not attaching anymore the VLAN interface to VALE (and you
>> are using an additional process).
>>
>> So instead of
>>
>> # vale-ctl vale0:vlan0
>>
>> you would have
>>
>> # bridge netmap:vlan0 vale0:vv # "vv" can be anything
> Hello Vincenzo,
>
> thank you very much for that interesting hint.
> I prepared a netgraph setup yesterday evening, but I'll try your
> suggestion first. Unfortunately I don't have time to prepare a debug
Since this doesn't need a reboot and I'm in adventure mood, I just tried
it at runtime.
Unfortunately I can't find bridge documentation besides the source code.
It doesn't detach from terminal here:
bridge built Oct 8 2017
12:59:57
060.359974 main [244] ------- zerocopy NOT
supported
060.359987 main [251] Wait 4 secs for link to come up...
064.365872 main [255] Ready to go, nic1_egn 0x0/1 <-> vale4:nic1egn
0x0/1.
068.084364 main [306] poll timeout [0] ev 1 0 rx 0@33 tx 1022, [1] ev 1
0 rx 0@34 tx
1023
072.565559 main [306] poll timeout [0] ev 1 0 rx 0@34 tx 1022, [1] ev 1
0 rx 0@35 tx 1023
…
In general, things are working.
Is bridge staing in the foreground by design?
Thanks,
-harry
From owner-freebsd-net@freebsd.org Wed Nov 22 09:25:11 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 C2806DE5F6A
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 22 Nov 2017 09:25:11 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com
[IPv6:2607:f8b0:400d:c0d::22e])
(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 7973E739DA
for <freebsd-net@freebsd.org>; Wed, 22 Nov 2017 09:25:11 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: by mail-qt0-x22e.google.com with SMTP id h42so22843320qtk.11
for <freebsd-net@freebsd.org>; Wed, 22 Nov 2017 01:25:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=RPVmdcPWchSDMn4kbT77aYkhMyvTRobBSxI5//VQ+ic=;
b=sn2+bJNYP7vUAMIkHgdCKzqkpMyVmYBoQk2cKRUyq57XrhPD/rD8yUZRFycZsD3f6G
3Q3Lzrkfxhjhwl3hdaZ3cEqIisVOewImvLekc8kX+K/4pVCFSrAUlZwsimkcCv+kCrDp
EP6BkXfIFTwib38Eb8K72UFOTr6w+K2m2u+TGHKgaWb4ocOd2Tq7OzAMffRy5NTmk5Ic
YG79Ya+RcYfCTcHqKyes2EKqjHNv2oj81gNcdeKu2dQwKql3rCkWGfcgrFIUQF9r96so
6kYothAV3cvKiaNsIf/5QmQd5tqTl4ie9wF96N5BXEiAsFVYDztBXzgySqa1YnXyfIXE
jGSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=RPVmdcPWchSDMn4kbT77aYkhMyvTRobBSxI5//VQ+ic=;
b=CPUPwV9IxxUWePG7gmJveFSLQFEnMugYHsCIdOD/09Pb7G75lHf58RGGzkiLYD7AnM
ZS6t0dZhgFEjbL4vi03jZdYUVXo3AXmxhxudiyyvWiDfivNUMu7oq2/FAUYSNQuN3zvr
12lhPR75Ie+eJAxRTyajiP4xrWE8YzHNuztiTZ7xN/aKCzTyDEaV2+GqEkswkUt2eaDf
sXQu7LJmgmzGr+GgfRd+ntpC3Mk5RoKa0NZsZoj9BJ0I0zBNQ1EXR6cW6Ul052PvTNi9
UJ81YOh7by+2fDtZGH5E2wUioywhuTvGOsGJ/c1ONWpH3GXyQxdx4LMm55a6hygyVoS2
1SBA==
X-Gm-Message-State: AJaThX5m5tv7Tw5WqaFbbbPnqujK7UP9/6jSgb2l/4/MZBtxQ5C9a7Io
4hPC5u03ot7NQOAa3Vl+JWiBoLz+OZEjoB4wZ+4=
X-Google-Smtp-Source: AGs4zMaU2Lw5UOZNCLBcL584wdgS7+dy2huMVSFPqx6a+8hnplk4vIlUWEJXuF4A29/0aT8g5h2KL8z3Zyqqy4U97ao=
X-Received: by 10.200.35.90 with SMTP id b26mr31380184qtb.324.1511342710383;
Wed, 22 Nov 2017 01:25:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.174.25 with HTTP; Wed, 22 Nov 2017 01:25:09 -0800 (PST)
In-Reply-To: <5A154102.10007@omnilan.de>
References: <5A0F14CD.3040407@omnilan.de>
<CA+_eA9giPsMJ2_O1CLvOro=rMm5TaJyQ-et_U01Re5J9+9VSqg@mail.gmail.com>
<5A149107.9060507@omnilan.de>
<CA+_eA9gW9mkCTr2JzMz4nqdhY+taGshStrVxLO3QOQ7MoUhWFg@mail.gmail.com>
<5A1537B3.9030603@omnilan.de> <5A154102.10007@omnilan.de>
From: Vincenzo Maffione <v.maffione@gmail.com>
Date: Wed, 22 Nov 2017 10:25:09 +0100
Message-ID: <CA+_eA9hH+6yPO6q=kASQGSVRiK8tq6qV666c5yc1JZvi_BujWg@mail.gmail.com>
Subject: Re: netmap/vale periodic deadlock
To: Harry Schmalzbauer <freebsd@omnilan.de>
Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
Giuseppe Lettieri <g.lettieri@iet.unipi.it>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Nov 2017 09:25:11 -0000
Hi,
$ bridge -h
for usage.
Yes, bridge is just a simple example program, and stays in foreground.
Probably using daemon(8) you can turn it into a daemon.
Cheers,
Vincenzo
2017-11-22 10:18 GMT+01:00 Harry Schmalzbauer <freebsd@omnilan.de>:
> Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 22.11.2017 09:39 (loca=
ltime):
> > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 22.11.2017 09:04 (loca=
ltime):
> >>
> >> 2017-11-21 21:48 GMT+01:00 Harry Schmalzbauer <freebsd@omnilan.de
> >> <mailto:freebsd@omnilan.de>>:
> >>
> >> Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39
> >> (localtime):
> >> =E2=80=A6
> >> >
> >> > If this is the case, although you are allowed to do that, I don'=
t
> think
> >> > it's a convenient way to use netmap.
> >> > Since VLAN interfaces like vlan0 do not have (and cannot have)
> native
> >> > netmap support, you are falling back to emulated netmap adapters
> (which
> >> > are probably buggy on FreeBSD, specially when combined with VALE=
).
> >> > Apart from bugs I think that with this setup you can't get decen=
t
> >> > performance that would justify using netmap rather than the
> standard
> >> > kernel bridge and TAP devices.
> >>
> >> Hello,
> >>
> >> lockup happened earlier than expected.
> >> This time 'vale-ctl' still reported (-l) the configuration.
> >> One guest, using if_vtnet(4)-virtio-net#vale2:korso, showed:
> >> dmz: watchdog timeout on queue 0
> >> (dmz is the renamed if_vtnet(4))
> >>
> >> I could attach tcpdump to the uplink interface and also to all vla=
n
> >> children.
> >> Complete silence everywhere. So it seems the nic stopped processi=
ng
> >> anything.
> >>
> >> Do you think that symptom could be caused by my special vale
> >> integration, so that bugs in netmap emulation could crash the NIC?
> >> Or is it unlikely that this is related.
> >>
> >> I hadn't prepared a debug kernel for the host, so the machine
> rebooted
> >> without again.
> >> I think I'll have to start with replacing vale first, to narrow do=
wn
> >> possible causes. Today I was lucky, the lockup happend after
> business
> >> hours, but I won't rely on that.
> >> At least I know if I really need to look for a debug netmap kernel=
,
> or
> >> possibly there's something else...
> >>
> >> Thanks,
> >>
> >> -harry
> >>
> >>
> >>
> >> I can't really say anything without a stack trace or meaningful logs.
> >> There is a thing that you may do to see if the bug comes out of a bad
> >> interaction between
> >> emulated netmap and VALE.
> >> Instead of attaching the vlan interfaces to VALE you can connect VALE =
to
> >> the vlan interface
> >> through the "bridge" program. In this way nothing changes from the
> >> functional point of view,
> >> but you are not attaching anymore the VLAN interface to VALE (and you
> >> are using an additional process).
> >>
> >> So instead of
> >>
> >> # vale-ctl vale0:vlan0
> >>
> >> you would have
> >>
> >> # bridge netmap:vlan0 vale0:vv # "vv" can be anything
> > Hello Vincenzo,
> >
> > thank you very much for that interesting hint.
> > I prepared a netgraph setup yesterday evening, but I'll try your
> > suggestion first. Unfortunately I don't have time to prepare a debug
>
> Since this doesn't need a reboot and I'm in adventure mood, I just tried
> it at runtime.
> Unfortunately I can't find bridge documentation besides the source code.
> It doesn't detach from terminal here:
> bridge built Oct 8 2017
> 12:59:57
>
> 060.359974 main [244] ------- zerocopy NOT
> supported
>
> 060.359987 main [251] Wait 4 secs for link to come up...
> 064.365872 main [255] Ready to go, nic1_egn 0x0/1 <-> vale4:nic1egn
> 0x0/1.
>
> 068.084364 main [306] poll timeout [0] ev 1 0 rx 0@33 tx 1022, [1] ev 1
> 0 rx 0@34 tx
> 1023
> 072.565559 main [306] poll timeout [0] ev 1 0 rx 0@34 tx 1022, [1] ev 1
> 0 rx 0@35 tx 1023
> =E2=80=A6
>
> In general, things are working.
>
> Is bridge staing in the foreground by design?
>
> Thanks,
>
> -harry
>
--=20
Vincenzo Maffione
From owner-freebsd-net@freebsd.org Wed Nov 22 13:39:57 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 1E02EDEBF68
for <freebsd-net@mailman.ysv.freebsd.org>;
Wed, 22 Nov 2017 13:39:57 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com
[IPv6:2607:f8b0:400d:c09::231])
(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 BBF3F7AB18
for <freebsd-net@freebsd.org>; Wed, 22 Nov 2017 13:39:56 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: by mail-qk0-x231.google.com with SMTP id v137so16755086qkb.1
for <freebsd-net@freebsd.org>; Wed, 22 Nov 2017 05:39:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=U8RC0OErPfDWW3GK8am2ItmsELXnXS8CFfXAVwziKYA=;
b=TrUaEdyJBGqnNbp9wuuMkPqHsJBCO/ihb0CaqUun76PEuF0UcPnSBHIkchXsu0NJfQ
Erd/4MSLrZ+O1STad5npzckF31xaDNWT2Qwriil/3nP62kck18djdT7/h6lmCMRh+bVE
lRorqNmszZnN03h2KjTCZes4E/IpnwAeI19HDIqb4YnV99nmO6CYYHSuNwVa8R1ZsqUX
WlTmvJh5r1onJbmTiBv9RGyd+1H2T8sIrCWUeL75wOOS1ZExjQovsR3PeL8xHo0w6ptY
0yqOWWrWONBCGz3KP8/mKuql5SevBcQiQ2EV0ijQdC00qvgjXfXB9phwbGtU3rPbUwiB
LunQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=U8RC0OErPfDWW3GK8am2ItmsELXnXS8CFfXAVwziKYA=;
b=uZVwYBypbYg9bNkvK8iadpDEIs5gTQ7JMW6i5w0gWjSxH2jwtt/BNxLu/DahV07JK2
t+N+cfKWwj0OK0bpml7Txw24fbVecNZ8AkLV+jQkrPtEhk1jJHJXz1XtJ8q2iaVaqqgX
K6OYLq9EYp7hyt+1xGtvhJpwYzJwx6pYp1WdqNJKDK8qZ9KvxQ46ZJwKeB6VcdSrufKV
s0WRgWl7uqlbi7u1YKgkv5qHhLLHJiLdPTLeoMe3xibQvrYNqzEAVTRFgR/mdrUm/CPa
OjOCM5kIzc7qRUruDIS/MCVncfFxEsEAPSwn2mE5nDRTvQ4uBwmEPiF+cja5tsABnlXZ
w9Ig==
X-Gm-Message-State: AJaThX6ZvNa9VvoI4wU9LOMegpvMzf4lDDDq40cVUow9tgB5Vjme79fm
PQ34tGz3R/ZadbmEMx2uJvjg55aFQp+TWBfHwIw=
X-Google-Smtp-Source: AGs4zMbnB7GQoMpTze72LQ6MdE58ivLfEBRIPOLJYa6FE7iZ9j4XiQdd77a4pzE7nBQ2PLmi0JF5hm3MODlVf3QHRfA=
X-Received: by 10.55.120.199 with SMTP id t190mr15933519qkc.63.1511357995745;
Wed, 22 Nov 2017 05:39:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.174.25 with HTTP; Wed, 22 Nov 2017 05:39:55 -0800 (PST)
In-Reply-To: <CAJnByzipicNHhmw0kGq0cXnfgXqq1xP0aJ4dqr12SryBV1Ny3w@mail.gmail.com>
References: <CAJnByzj6Dj3vouZ2NbxqvCV-2-7TVtTR4FaWKuCFaaRN2X+yAA@mail.gmail.com>
<CALgsdbd3XuE3wMYp4ey+1aer+HSVNojLYoVqwqTBPAXXdf9i+Q@mail.gmail.com>
<CAJnByzirLXdCe-kwHV2s_E6ytGJG0Dth=0Ms12RrEk7FK_+8Og@mail.gmail.com>
<CA+hQ2+gMWY0eabjHGw0=PJCAkS-wO=RBrN5brSbaqWc3_AOYoQ@mail.gmail.com>
<CAJnByziBS8o6LtmpUrUu5xtRUd008Z2hnCsp=WVFv35r2J0rHw@mail.gmail.com>
<CA+hQ2+im9nFfYnqDS2HgRbAzdf5D0iaLCmCYhfXQVVRMouUFuw@mail.gmail.com>
<CAJnByzht-qfDcm8oEg1aSRyVBZ1ygPvc2eMuoyJcq4geueTZ0Q@mail.gmail.com>
<CA+hQ2+iERgWJ=cdFB-cByfT3r11T1kKr-5HiuCYZY-rxbjf=XA@mail.gmail.com>
<CAJnByziDzdR2C6DcSRNPtrWACLq0XFpe4X1Ek9yXtFP9ivqWQw@mail.gmail.com>
<CA+hQ2+hjnuGo1xKgc8CQ7gP35tiaZG7+roZBmX8aBgb8qWnLgg@mail.gmail.com>
<CAJnByzh-VrRZeYdpkRFtCUGEN_arFBkemcN7byb51XV6UPswyg@mail.gmail.com>
<CA+hQ2+iMw3kxjpcZy77vgOEsfk2UY0-farh9C8RKXZHMU7D8kw@mail.gmail.com>
<CAJnByzgsuNBhdfPJsGrrHcU79xjK+dq2RENgUkbZcehFm8MUxg@mail.gmail.com>
<CAJnByzgNZ9YsYd7tBgYxiQPvuS_VZbhZNGvsPS-0apCDga7XFA@mail.gmail.com>
<CANpwN=uHk-VwOoFz7NaPE9A-0B=MAapqxJ-uyCBtn=oMdacYnw@mail.gmail.com>
<CAJnByzgjEEAzmWZu7BsSWHXmpjUtZcqXFGN8umCqmvgME1Jv+A@mail.gmail.com>
<CANpwN=tfqitQW0BTXA7bU+TfmP8=wr7gE8wAP=hjAamjD7ny9Q@mail.gmail.com>
<CAJnByzi5WHHvwcrmEOkJOHf5SJekbTtQoUgLmPbMtwTotc8mzA@mail.gmail.com>
<CAJnByzhJnrmiwiLEEQV0meg7+DnLJ6Jq_J=6L=35Z9Lgw1GcyA@mail.gmail.com>
<CA+hQ2+jTXyYdN4N4aWOkDdkBr+D3quocHn+c8MA+xc9yLs9V4w@mail.gmail.com>
<CAJnByzg0PCXCyjnypS_2+RhKB0mf_4s8X1niFiyfedaCLUku7Q@mail.gmail.com>
<CAJnByzipicNHhmw0kGq0cXnfgXqq1xP0aJ4dqr12SryBV1Ny3w@mail.gmail.com>
From: Vincenzo Maffione <v.maffione@gmail.com>
Date: Wed, 22 Nov 2017 14:39:55 +0100
Message-ID: <CA+_eA9h3NL6Ga4=HRjEiDtNaANkR8m7oZ9+CCpoWVB+aYW3+tw@mail.gmail.com>
Subject: Re: swaping ring slots between NIC ring and Host ring does not always
success
To: Xiaoye Sun <Xiaoye.Sun@rice.edu>
Cc: Luigi Rizzo <rizzo@iet.unipi.it>,
"freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
Victor Detoni <victordetoni@gmail.com>,
Pavel Odintsov <pavel.odintsov@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Nov 2017 13:39:57 -0000
Hi,
2017-11-21 7:51 GMT+01:00 Xiaoye Sun <Xiaoye.Sun@rice.edu>:
> Hi,
>
> Recently I found another problem with netmap. I think this new problem
> could be related to the problems in this threads so I just post the new
> problem here.
>
> In my setup, I have a sender program having a netmap ring (a pair of
> RX/TX ring) for the NIC and a ring for the host stack. The sender program
> puts customized packets (each packet has a unique sequence number and the
> sender sends the packet in a sequence number increasing order) to the NIC
> TX ring directly and also forwards the packets from the host RX ring to the
> NIC TX ring using "zerocopy" by swapping the buffer indices.
> However, the receiver sees duplicated customized packets. For example, in
> the case where the ring size is 32 (32 slots in a ring) the order of the
> sequence numbers the receiver see is 1,2,3,4,5,...,68,69,*70*
> ,71,72,73,...,99,100,*70*,101,102,103,... . An interesting thing I found
> is
> that the "gaps" between these two duplicated packets (70 in the example)
> are always a number very close to the ring size, 32 in this example. In my
> experiment, I use a ring with 4096 slots and the gap is always more than
> 4090 and close to 4096. I verified that this duplication happens due to the
> sender, not the receiver. Assuming my sender's implementation is correct,
> then this duplication may happen in netmap and the NIC driver (ixgbe).
>
Netmap itself doesn't do any duplication nor takes a look at the packets.
It just passes
down ring->cur/ring->head to the ixgbe driver (after validation).
The ixgbe driver datapath is bypassed and replaced with a netmap-enabled
datapath (see
https://github.com/luigirizzo/netmap/blob/master/LINUX/ixgbe_netmap_linux.h#L294-L461
);
no duplication should happen there as each netmap slot (1 TX packet) is used
only once.
>
>
> Thinking back to the original problem in this post, I think these problems
> may be related. It seems to me that there could be multiple threads pulling
> the packets from the NIC TX ring (or the thread moved to other CPUs when
> the problem occurs) and these threads may run on different cores so that
> the outdated content in the buffer may be sent out when new content is
> written to the buffer.
>
>
There are no such threads pulling from the NIC TX ring. Your application
directly
puts new packets to be transmitted in the netmap buffers referenced in the
netmap TX
ring. When then you call NIOCTXSYNC or poll(), all the new TX buffers (e.g.
all
the ones from the previous value ring->head (included) to the new value of
ring->head (excluded))
are moved to the NIC TX ring. This happens in the context of your
application thread,
no worker threads are used. Then the NIC hardware starts the transmission.
> I am wondering if there is a way to pin the NIC driver of the netmap module
> to a specific core. or is there a way to know the root of such problem?
>
The only threads are the ones of your application.
Maybe your problem comes from concurrent accesses to the netmap TX ring
from different threads? Only one thread at a given time should update a
netmap
TX/RX ring. Otherwise the behaviour is unspecified.
Cheers,
Vincenzo
>
> Best,
> Xiaoye
>
>
--
Vincenzo Maffione
From owner-freebsd-net@freebsd.org Fri Nov 24 07:25:22 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 73667DBBA0E
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 07:25:22 +0000 (UTC) (envelope-from ml@netfence.it)
Received: from smtp208.alice.it (smtp208.alice.it [82.57.200.104])
by mx1.freebsd.org (Postfix) with ESMTP id 0E27868BEA
for <freebsd-net@freebsd.org>; Fri, 24 Nov 2017 07:25:21 +0000 (UTC)
(envelope-from ml@netfence.it)
Received: from soth.ventu (80.182.75.25) by smtp208.alice.it (8.6.060.28)
id 5A0BFDF101B0763C; Fri, 24 Nov 2017 08:24:39 +0100
Received: from alamar.ventu (alamar.local.netfence.it [10.1.2.18])
by soth.ventu (8.15.2/8.15.2) with ESMTP id vAO7OaNv052661;
Fri, 24 Nov 2017 08:24:37 +0100 (CET) (envelope-from ml@netfence.it)
X-Authentication-Warning: soth.ventu: Host alamar.local.netfence.it
[10.1.2.18] claimed to be alamar.ventu
Subject: [SOLVED] Re: bridge0 not working when cable disconnected
To: Eugene Grosbein <eugen@grosbein.net>, freebsd-net@freebsd.org
References: <59452bf1-25fb-970d-1d8d-5ca1463da4fd@netfence.it>
<5A0DD27A.3010304@grosbein.net>
From: Andrea Venturoli <ml@netfence.it>
Message-ID: <17132d5f-0708-04a4-9a82-3a1afb49d19b@netfence.it>
Date: Fri, 24 Nov 2017 08:24:31 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <5A0DD27A.3010304@grosbein.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 07:25:22 -0000
On 11/16/17 19:01, Eugene Grosbein wrote:
> If you add an interface to a bridge, you should remove all IP addresses from it
> and assign them to the bridge itself instead. And you will be fine.
Thanks.
In fact, assigning the base IP and all the jails to bridge0, instead of
re0 solved.
I still think bhyve assigns the VM's IP to tap0, but that doesn't seam
to be a problem.
bye
av.
From owner-freebsd-net@freebsd.org Fri Nov 24 09:52:08 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 F17DFDDE6CE
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 09:52:08 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com
[IPv6:2607:f8b0:400d:c0d::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 A91E76D36D
for <freebsd-net@freebsd.org>; Fri, 24 Nov 2017 09:52:08 +0000 (UTC)
(envelope-from v.maffione@gmail.com)
Received: by mail-qt0-x233.google.com with SMTP id i40so19502623qti.8
for <freebsd-net@freebsd.org>; Fri, 24 Nov 2017 01:52:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=5pESuRe9D5fcfq5eTUPcjS0z8ZRtzrHIhey92geYkpQ=;
b=YdNmERSHOxDS/V18Efv9Z9ateIZwoVubBSs83edGhsnf35jW/h1KVr0WjSjXR/ivIC
a7bIUdmD4NNuaPRKlh8lf3vbyfmt0GlDQPJ6+DQYS4k719L2qadFhLGoBefwBVXcYj3x
cERw5ls2eBncSUMYMWGtxeviWqa85Y/2M4lCO9duJEW+VS1toIF0DCyx69bSHKN8MCyE
5Y1ECbmVd0RoLyoN2mfJm6I9xdOPlWb7nh9jYtS7WqoiHeYO+Y5I4+ve0RaO/mutGpxj
VdSTVcfY+++3am5KjgefMXv9lwGylxrDm2A2mjNyyYbe3AjMVQUDIIIawF/vW4MZmvnR
8+Cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=5pESuRe9D5fcfq5eTUPcjS0z8ZRtzrHIhey92geYkpQ=;
b=ehLK70XwvGTLWuYTTjGlSyoPUUgIn50NQ2vMLbeZNaHGCle+oX3vahrMFwkwK9uUZ1
BKDY8cwYhUJjKPrPkkPTIcHDjWvJGS/N5tS7rHOxmhfs1pCRTgUtUCLKOVyNE15LFPgu
9K9PaYBQjw4B5RDGRFU8Buu5UzfmqPhzFc2Q1t80eXhAs+2yRb2Pnb3QGHgr4KAfzmg6
LoXsPPl1ZZk/aGK9UEHtlSrJ9kSEcsa23RQwBLQofojvWdj5ckvhuE+bSgzr6/nXbZXn
43hn7s2+aT/H3fnmOtFl2pvhJDAmXcsKA2plHBy43jv/vOziTYbtbH1AHZ/9JybCFYSF
D00g==
X-Gm-Message-State: AJaThX665J+SV3vVyjbUU2249QI9PpPBgtICKFcpndpsCB5V2RMQRLEx
+YX1IE/R7C/TALDDD7ifI6yq3dxyHuUF+dror/I=
X-Google-Smtp-Source: AGs4zMbLTiny70Biey0QpfPgUF1fVr0sch0nOgiZN/0wpEJEYaWDYVZj71jSxX2k8iPF2U7tG24SPcz7rvBcwFJgp5c=
X-Received: by 10.200.40.189 with SMTP id i58mr44030375qti.128.1511517127671;
Fri, 24 Nov 2017 01:52:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.174.5 with HTTP; Fri, 24 Nov 2017 01:52:07 -0800 (PST)
In-Reply-To: <17132d5f-0708-04a4-9a82-3a1afb49d19b@netfence.it>
References: <59452bf1-25fb-970d-1d8d-5ca1463da4fd@netfence.it>
<5A0DD27A.3010304@grosbein.net>
<17132d5f-0708-04a4-9a82-3a1afb49d19b@netfence.it>
From: Vincenzo Maffione <v.maffione@gmail.com>
Date: Fri, 24 Nov 2017 10:52:07 +0100
Message-ID: <CA+_eA9j_=OXm=fX7yEj-xfRfV=W24AJrLudSM2RBaBBQ8OXxZg@mail.gmail.com>
Subject: Re: [SOLVED] Re: bridge0 not working when cable disconnected
To: Andrea Venturoli <ml@netfence.it>
Cc: Eugene Grosbein <eugen@grosbein.net>,
"freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 09:52:09 -0000
Hi,
The VM IP is assigned to the emulated interface inside the guest OS (e.g.
vtnet0).
It would not make sense to assign an IP to tap0, and I'm quite sure bhyve
doesn't do that.
If tap0 is attached to bridge0 (which is normally the case, and I guess
it's your case), there is no reason for tap0 to have an IP (because it's a
data port of an L2 switch).
If you give an IP to tap0 it's not dangerous, but there is no need to do
that. (The only use-case for giving an IP to tap0 I can think of is when
you don't attach tap0 do any bridge, and you use tap0 as a peer-to-peer
link for applications on your host to communicate with applications in the
VM. But nobody does that since you can do the same with the bridge0
interface, which can be used to talk to multiple VMs, not just one).
Cheers,
Vincenzo
2017-11-24 8:24 GMT+01:00 Andrea Venturoli <ml@netfence.it>:
> On 11/16/17 19:01, Eugene Grosbein wrote:
>
> If you add an interface to a bridge, you should remove all IP addresses
>> from it
>> and assign them to the bridge itself instead. And you will be fine.
>>
>
> Thanks.
>
> In fact, assigning the base IP and all the jails to bridge0, instead of
> re0 solved.
> I still think bhyve assigns the VM's IP to tap0, but that doesn't seam to
> be a problem.
>
> bye
> av.
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
--
Vincenzo Maffione
From owner-freebsd-net@freebsd.org Fri Nov 24 11:51:28 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 E5405DE1F2F
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 11:51:28 +0000 (UTC) (envelope-from ml@netfence.it)
Received: from smtp206.alice.it (smtp206.alice.it [82.57.200.102])
by mx1.freebsd.org (Postfix) with ESMTP id 7C8AA7162E
for <freebsd-net@freebsd.org>; Fri, 24 Nov 2017 11:51:28 +0000 (UTC)
(envelope-from ml@netfence.it)
Received: from soth.ventu (80.182.75.25) by smtp206.alice.it (8.6.060.28)
id 5A0BFCB801BFB7EB; Fri, 24 Nov 2017 12:50:48 +0100
Received: from alamar.ventu (alamar.local.netfence.it [10.1.2.18])
by soth.ventu (8.15.2/8.15.2) with ESMTP id vAOBokwP072788;
Fri, 24 Nov 2017 12:50:46 +0100 (CET) (envelope-from ml@netfence.it)
X-Authentication-Warning: soth.ventu: Host alamar.local.netfence.it
[10.1.2.18] claimed to be alamar.ventu
Subject: Re: [SOLVED] Re: bridge0 not working when cable disconnected
To: Vincenzo Maffione <v.maffione@gmail.com>
Cc: Eugene Grosbein <eugen@grosbein.net>,
"freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
References: <59452bf1-25fb-970d-1d8d-5ca1463da4fd@netfence.it>
<5A0DD27A.3010304@grosbein.net>
<17132d5f-0708-04a4-9a82-3a1afb49d19b@netfence.it>
<CA+_eA9j_=OXm=fX7yEj-xfRfV=W24AJrLudSM2RBaBBQ8OXxZg@mail.gmail.com>
From: Andrea Venturoli <ml@netfence.it>
Message-ID: <533448c6-29b1-4767-11bd-4b7ee6e1859c@netfence.it>
Date: Fri, 24 Nov 2017 12:50:41 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <CA+_eA9j_=OXm=fX7yEj-xfRfV=W24AJrLudSM2RBaBBQ8OXxZg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 11:51:29 -0000
On 11/24/17 10:52, Vincenzo Maffione wrote:
> Hi,
> Â The VM IP is assigned to the emulated interface inside the guest OS
> (e.g. vtnet0).
> It would not make sense to assign an IP to tap0, and I'm quite sure
> bhyve doesn't do that.
Right.
Sorry for having expressed this with wrong wording.
bye & Thanks
av.
From owner-freebsd-net@freebsd.org Fri Nov 24 13:36:41 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 6D551DE5B2E
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 13:36:41 +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 5BB2174A28
for <freebsd-net@FreeBSD.org>; Fri, 24 Nov 2017 13:36:41 +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 vAODaff0059593
for <freebsd-net@FreeBSD.org>; Fri, 24 Nov 2017 13:36:41 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223835] BGP session not established with md5 password via
FRRouting
Date: Fri, 24 Nov 2017 13:36:41 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.1-STABLE
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-223835-2472-QuS3Sq3E75@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223835-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223835-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 13:36:41 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223835
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-net@freebsd.org Fri Nov 24 13:37:39 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 B44EFDE5C79
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 13:37:39 +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 A24E474BD1
for <freebsd-net@FreeBSD.org>; Fri, 24 Nov 2017 13:37:39 +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 vAODbdv7060770
for <freebsd-net@FreeBSD.org>; Fri, 24 Nov 2017 13:37:39 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223835] BGP session not established with md5 password via
FRRouting
Date: Fri, 24 Nov 2017 13:37:39 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.1-STABLE
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: pautina@kharkiv.net
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-223835-2472-HbhE0427mT@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223835-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223835-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 13:37:39 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223835
--- Comment #9 from Alexey <pautina@kharkiv.net> ---
Created attachment 188240
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D188240&action=
=3Dedit
TCPDUMP file for 185.1.62.69
I'm repeat command: 'tcpdump -M some_password -i vlan62 -XXX -vvv -n host
185.1.62.69' and save data to file for next analized.
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-net@freebsd.org Fri Nov 24 13:38:10 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 683ADDE5E39
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 13:38:10 +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 566F774D14
for <freebsd-net@FreeBSD.org>; Fri, 24 Nov 2017 13:38:10 +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 vAODc94f061468
for <freebsd-net@FreeBSD.org>; Fri, 24 Nov 2017 13:38:10 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223824] [arm64] Kernel panic in ng_base.c (netgraph)
Date: Fri, 24 Nov 2017 13:38:10 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc assigned_to
Message-ID: <bug-223824-2472-AzyzCYAMhm@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223824-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223824-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 13:38:10 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223824
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |freebsd-arm@FreeBSD.org
Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-net@freebsd.org Fri Nov 24 13:38:55 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 38669DE6079
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 13:38:55 +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 26BBD74F06
for <freebsd-net@FreeBSD.org>; Fri, 24 Nov 2017 13:38:55 +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 vAODcs6T062455
for <freebsd-net@FreeBSD.org>; Fri, 24 Nov 2017 13:38:55 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223817] mbuf leaking with tcpmd5
Date: Fri, 24 Nov 2017 13:38:55 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.1-RELEASE
X-Bugzilla-Keywords: regression
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-223817-2472-sHp8LKIjPJ@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223817-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223817-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 13:38:55 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223817
Mark Linimon <linimon@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-net@freebsd.org Fri Nov 24 13:58:59 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 E6CB6DE7074
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 13:58:59 +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 D4F5075E38
for <freebsd-net@FreeBSD.org>; Fri, 24 Nov 2017 13:58:59 +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 vAODwx06007015
for <freebsd-net@FreeBSD.org>; Fri, 24 Nov 2017 13:58:59 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223824] [arm64] Kernel panic in ng_base.c (netgraph)
Date: Fri, 24 Nov 2017 13:59:00 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: eugen@freebsd.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-223824-2472-eckXCFBt24@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223824-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223824-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 13:59:00 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223824
--- Comment #3 from Eugene Grosbein <eugen@freebsd.org> ---
You have to add NETGRAPH_DEBUG to your kernel configuration to obtain more
debug information. Please note that NETGRAPH_DEBUG changes netgraph ABI, so=
you
won't be able to use pre-built netgraph modules with such a kernel, so add =
all
needed options statically:
options NETGRAPH_DEBUG
options NETGRAPH
options NETGRAPH_SOCKET
options NETGRAPH_L2TP
options NETGRAPH_MPPC_COMPRESSION
options NETGRAPH_MPPC_ENCRYPTION
options NETGRAPH_IFACE
options NETGRAPH_PPP
options NETGRAPH_TEE
options NETGRAPH_VJC
options NETGRAPH_ETHER
options NETGRAPH_ASYNC
Then retry your test.
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-net@freebsd.org Fri Nov 24 16:23:52 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 2804FDEB32C
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 16:23:52 +0000 (UTC)
(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [89.188.221.64])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "plan-b.pwste.edu.pl", Issuer "plan-b.pwste.edu.pl" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 834D57AAA0
for <freebsd-net@freebsd.org>; Fri, 24 Nov 2017 16:23:50 +0000 (UTC)
(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1])
by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPS id vAOGAZQw092958
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Fri, 24 Nov 2017 17:10:35 +0100 (CET)
(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: (from zarychtam@localhost)
by plan-b.pwste.edu.pl (8.15.2/8.15.2/Submit) id vAOGAZ6t092955;
Fri, 24 Nov 2017 17:10:35 +0100 (CET) (envelope-from zarychtam)
Date: Fri, 24 Nov 2017 17:10:35 +0100
From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>
To: pautina@kharkiv.net
Cc: freebsd-net@freebsd.org
Subject: Re: [Bug 223835] BGP session not established with md5 password via
FRRouting
Message-ID: <20171124161035.GB82239@plan-b.pwste.edu.pl>
References: <bug-223835-2472@https.bugs.freebsd.org/bugzilla/>
<bug-223835-2472-QuS3Sq3E75@https.bugs.freebsd.org/bugzilla/>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="b5gNqxB1S1yM7hjW"
Content-Disposition: inline
In-Reply-To: <bug-223835-2472-QuS3Sq3E75@https.bugs.freebsd.org/bugzilla/>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 16:23:52 -0000
--b5gNqxB1S1yM7hjW
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Nov 24, 2017 at 01:36:41PM +0000, bugzilla-noreply@freebsd.org wrot=
e:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223835
>=20
> Mark Linimon <linimon@FreeBSD.org> changed:
>=20
> What |Removed |Added
> -------------------------------------------------------------------------=
---
> Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org
>=20
> --=20
> You are receiving this mail because:
> You are the assignee for the bug.
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Hi Alexey,
Some time ago I had the similar problem with TCP MD5 on LAGG interface.
It came out that the problem has nothing to do with LAGG.
If the interfaces do not support TX/RX checksums in hardware TCP MD5
signatures seem to be incorrect on 11.1-STABLE.
It is wasn't documented anywhere, I have changed NICs.
See the original thread:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219453
Best regards,
--=20
Marek Zarychta
--b5gNqxB1S1yM7hjW
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAloYRHUACgkQdZ/s//1S
jSzF4gf8CZYQwzDHYfM3J8fkuRdEAe0AqQC000d1cZWJNhdPl+8Z3PW5SJizABTu
CNomI4SMJDmA+YpIaJQ2ehXD58ePOb4uvR1tCzYkUFXMKVfSUZwbaZ0MIga3mj0K
lAAuliJ+j+wbdKYCdhL9dhRuF+cIurin5p1zR9Y5X2wjRCpF3s/p0yIllriZw9dJ
uiHHOQtPMSAC6e42dAIeGxJBmeg/rkYUoI6LqL/Bom7HStR5Z11ooQQfoDj/xRXy
Cu8lvQhpFHz1B3NeFfkvIysX9xsiSJlaTNEiubovc/0GOpRgJcgftx7Oq6o7KqV5
EzBgeO633D71RIesneFQ8V13mzPCjQ==
=fQ30
-----END PGP SIGNATURE-----
--b5gNqxB1S1yM7hjW--
From owner-freebsd-net@freebsd.org Fri Nov 24 19:55:37 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 6C8D0DF005F
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 19:55:37 +0000 (UTC)
(envelope-from freebsd@omnilan.de)
Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130])
(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 048FD3202
for <freebsd-net@freebsd.org>; Fri, 24 Nov 2017 19:55:36 +0000 (UTC)
(envelope-from freebsd@omnilan.de)
Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135])
by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id vAOJtWco024894
for <freebsd-net@freebsd.org>; Fri, 24 Nov 2017 20:55:32 +0100 (CET)
(envelope-from freebsd@omnilan.de)
Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mh0.gentlemail.de (Postfix) with ESMTPSA id 5F408F17;
Fri, 24 Nov 2017 20:55:32 +0100 (CET)
Message-ID: <5A187930.1070406@omnilan.de>
Date: Fri, 24 Nov 2017 20:55:28 +0100
From: Harry Schmalzbauer <freebsd@omnilan.de>
Organization: OmniLAN
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE;
rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: FreeBSD Net <freebsd-net@freebsd.org>
Subject: =?UTF-8?B?UTogW3J0YWR2ZF0gcHJlZml4IGluZm8gZmxhZyAnUicgLSBNb2JpbGU=?=
=?UTF-8?B?IElQdjYgZXh0ZW5zaW9uIOKAkyBvciBob3cgdG8gZGlzYWJsZSBsaW5rLWxvY2E=?=
=?UTF-8?B?bCBnYXRld2F5?=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7
(mx0.gentlemail.de [78.138.80.130]); Fri, 24 Nov 2017 20:55:32 +0100 (CET)
X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135;
Sender-helo: mh0.gentlemail.de; )
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 19:55:37 -0000
Hello,
it was unavoidable, so I took some time reading rtadvd.conf(5), rfc4861
(Neighbour Discovery for IP version 6, which also describes the Router
Advertisement Message Format with it's Prefix Information, flags L and
A) and rfc6275 (Mobility Support in IPv6, which extends the Prefix
Information Flags).
As far as I can tell, our rtadvd(8) doesn't support the extended 'R' flag.
My aim:
Stateful _only_ (dhcp6) configuration in the LAN for widest client
deversity possible, without the need to change anything on any client.
dhcp6 setup was no probelm with isc's dhcpd.
Finding the "managed adress" flag for RA messages, which tells most
popular clients to _also_ request DHCPv6 leases was also no big effort.
Finding the unwanted L flag for the prefix information in the RA message
was a bit trickier.
Finding out that rtadvd(8) seems to only respect the corresponding
"pinfoflags='l'" capability field if you explicitly set a addr for
prefix info (not leaving the auto-determination) was hard.
So for the records, if somebody else want's to restrict SLAAC in her
DHCPv6 environment, /etc/rtadvd.conf needs the following lines to
convince the most popular clients to use the stateful (dhcp6) address
for internet communication:
yourdefaults:\
:noifprefix:nolladdr:raflags='m':
yourif:\
:tc=yourdefaults:addr="2001:db8:abcd:1::":prefixlen#64:pinfoflags='l':
(If you only set the 'm' flag, most popular clients use the SLAAC
address, despite they got a dhcp lease.)
In any case, they use the link-local address of the gateway.
I'd prefer that clients use the global unicast address of the router,
instead of the link-local address.
What I found so far is the already mentioned "R" flag, but that's not
implemented so far (in rtadvd(8)).
What do your setups look like?
Do you use radvd(8) instead?
Any other trick?
Not caring about source addresses at all?
Thanks,
-harry
From owner-freebsd-net@freebsd.org Fri Nov 24 20:49:58 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 D004FDF110A
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 20:49:58 +0000 (UTC)
(envelope-from sunxiaoye07@gmail.com)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com
[IPv6:2607:f8b0:4003:c06::236])
(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 818A063F76
for <freebsd-net@freebsd.org>; Fri, 24 Nov 2017 20:49:58 +0000 (UTC)
(envelope-from sunxiaoye07@gmail.com)
Received: by mail-oi0-x236.google.com with SMTP id r190so15777670oie.6
for <freebsd-net@freebsd.org>; Fri, 24 Nov 2017 12:49:58 -0800 (PST)
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:cc;
bh=DDfG6IV7VjYkdScuU8YQsZUYPn+fVJNB3mC/zRi2+Po=;
b=AwBZEYWhtDQVP8sLBWfqFoZGECJkuHSSBTFaXLz6eyCM6qBOfQeFhO/IYuLeGN8ejp
4Z0zysw1/Rv0Bhi2GQzjsYMvbLHiOm/TlZ/2Jsw9ZTjPpbEWbCKYZyJ/rsp1OizfROaX
b1TJJWn6c1Yu7TY5EYrcURF5XImeWIKZvTp2GhysRaWo8Oaw8nGHkvy9zO14mMdhyVLp
ZoaUzyoHPenoKGp7ygdk4ngRI80yQn+lSA6Ak2LPP4jxtcAdBxU960Xzmjg9OTSjNS+1
mfe4JGdLJNeBMjD5PLze63SJYsNtgUdBxFW8urQdD/M+wcFC+iCw5kgXVN5OUUFuuXO7
+0UQ==
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:cc;
bh=DDfG6IV7VjYkdScuU8YQsZUYPn+fVJNB3mC/zRi2+Po=;
b=hqnakljJfeQ9lunnBwG5eXi4/oXmkKihjADEuZOQ+tRtMZ/7gAaXeT/fMUuV1VOsoN
j+hAwq5CcNQjceyKi3Rvj/2rWcg+2g82h0izmRr+G5g4fRMaf8CfCeBsH81FofUFx3/S
iaweuJstOrfMoS/utQNVT81x78ZAgLTFjbPgv/A+n4j6U9+Gmc12dmAEde982CFJQ2e/
U8pw9HPoVMlp4ejh/UiF7thCNAmOccWJLHJA65qbay7QmLjYe0FKX9JGgZGmfmrrzISR
Dch12hagOaNzK4BpHMKIiJiVDjFSHrCVfX834COndmUtMUSQyC1Pj+2HmwELMHSJiUYT
w0zQ==
X-Gm-Message-State: AJaThX7w8r6k2klP46dJ4Ogvl1VUI5oYX2U3trD9My+6SubPi+CFmkGy
0cz0qp2d4t/DjtOi/XTNTV3bdTfwmeQjZw07s1xVOQ==
X-Google-Smtp-Source: AGs4zMaaogoSakKXbdZZTXgP16b+4yPdZ59NZ9QcyDcnTqLY1Ebgq70FyqZwmfICV4rDpJyoNu08kDYQQUKgH+RCLzU=
X-Received: by 10.202.166.17 with SMTP id p17mr10492096oie.192.1511556597827;
Fri, 24 Nov 2017 12:49:57 -0800 (PST)
MIME-Version: 1.0
Sender: sunxiaoye07@gmail.com
Received: by 10.157.14.167 with HTTP; Fri, 24 Nov 2017 12:49:57 -0800 (PST)
In-Reply-To: <CA+_eA9h3NL6Ga4=HRjEiDtNaANkR8m7oZ9+CCpoWVB+aYW3+tw@mail.gmail.com>
References: <CAJnByzj6Dj3vouZ2NbxqvCV-2-7TVtTR4FaWKuCFaaRN2X+yAA@mail.gmail.com>
<CALgsdbd3XuE3wMYp4ey+1aer+HSVNojLYoVqwqTBPAXXdf9i+Q@mail.gmail.com>
<CAJnByzirLXdCe-kwHV2s_E6ytGJG0Dth=0Ms12RrEk7FK_+8Og@mail.gmail.com>
<CA+hQ2+gMWY0eabjHGw0=PJCAkS-wO=RBrN5brSbaqWc3_AOYoQ@mail.gmail.com>
<CAJnByziBS8o6LtmpUrUu5xtRUd008Z2hnCsp=WVFv35r2J0rHw@mail.gmail.com>
<CA+hQ2+im9nFfYnqDS2HgRbAzdf5D0iaLCmCYhfXQVVRMouUFuw@mail.gmail.com>
<CAJnByzht-qfDcm8oEg1aSRyVBZ1ygPvc2eMuoyJcq4geueTZ0Q@mail.gmail.com>
<CA+hQ2+iERgWJ=cdFB-cByfT3r11T1kKr-5HiuCYZY-rxbjf=XA@mail.gmail.com>
<CAJnByziDzdR2C6DcSRNPtrWACLq0XFpe4X1Ek9yXtFP9ivqWQw@mail.gmail.com>
<CA+hQ2+hjnuGo1xKgc8CQ7gP35tiaZG7+roZBmX8aBgb8qWnLgg@mail.gmail.com>
<CAJnByzh-VrRZeYdpkRFtCUGEN_arFBkemcN7byb51XV6UPswyg@mail.gmail.com>
<CA+hQ2+iMw3kxjpcZy77vgOEsfk2UY0-farh9C8RKXZHMU7D8kw@mail.gmail.com>
<CAJnByzgsuNBhdfPJsGrrHcU79xjK+dq2RENgUkbZcehFm8MUxg@mail.gmail.com>
<CAJnByzgNZ9YsYd7tBgYxiQPvuS_VZbhZNGvsPS-0apCDga7XFA@mail.gmail.com>
<CANpwN=uHk-VwOoFz7NaPE9A-0B=MAapqxJ-uyCBtn=oMdacYnw@mail.gmail.com>
<CAJnByzgjEEAzmWZu7BsSWHXmpjUtZcqXFGN8umCqmvgME1Jv+A@mail.gmail.com>
<CANpwN=tfqitQW0BTXA7bU+TfmP8=wr7gE8wAP=hjAamjD7ny9Q@mail.gmail.com>
<CAJnByzi5WHHvwcrmEOkJOHf5SJekbTtQoUgLmPbMtwTotc8mzA@mail.gmail.com>
<CAJnByzhJnrmiwiLEEQV0meg7+DnLJ6Jq_J=6L=35Z9Lgw1GcyA@mail.gmail.com>
<CA+hQ2+jTXyYdN4N4aWOkDdkBr+D3quocHn+c8MA+xc9yLs9V4w@mail.gmail.com>
<CAJnByzg0PCXCyjnypS_2+RhKB0mf_4s8X1niFiyfedaCLUku7Q@mail.gmail.com>
<CAJnByzipicNHhmw0kGq0cXnfgXqq1xP0aJ4dqr12SryBV1Ny3w@mail.gmail.com>
<CA+_eA9h3NL6Ga4=HRjEiDtNaANkR8m7oZ9+CCpoWVB+aYW3+tw@mail.gmail.com>
From: Xiaoye Sun <Xiaoye.Sun@rice.edu>
Date: Fri, 24 Nov 2017 14:49:57 -0600
X-Google-Sender-Auth: UufEaTQOT0KjRaYiw-AOlZbEhqc
Message-ID: <CAJnByzjozV4nKHN+Q=tgYXWwxg-5=inKNL_nWdtKvHXx5MTZpQ@mail.gmail.com>
Subject: Re: swaping ring slots between NIC ring and Host ring does not always
success
To: Vincenzo Maffione <v.maffione@gmail.com>
Cc: Luigi Rizzo <rizzo@iet.unipi.it>,
"freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
Victor Detoni <victordetoni@gmail.com>,
Pavel Odintsov <pavel.odintsov@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 20:49:58 -0000
Hi Vincenzo,
Thanks for your reply.
Let me clarify my problem.
I have a program, which is an extension of bridge.c
https://github.com/luigirizzo/netmap/blob/788f25dcc48dfec2e481573277b662968f690042/LINUX/ixgbe_netmap_linux.h#L377
On Wed, Nov 22, 2017 at 7:39 AM, Vincenzo Maffione <v.maffione@gmail.com>
wrote:
> Hi,
>
> 2017-11-21 7:51 GMT+01:00 Xiaoye Sun <Xiaoye.Sun@rice.edu>:
>
>> Hi,
>>
>> Recently I found another problem with netmap. I think this new problem
>> could be related to the problems in this threads so I just post the new
>> problem here.
>>
>> In my setup, I have a sender program having a netmap ring (a pair of
>> RX/TX ring) for the NIC and a ring for the host stack. The sender program
>> puts customized packets (each packet has a unique sequence number and the
>> sender sends the packet in a sequence number increasing order) to the NIC
>> TX ring directly and also forwards the packets from the host RX ring to
>> the
>> NIC TX ring using "zerocopy" by swapping the buffer indices.
>> However, the receiver sees duplicated customized packets. For example, in
>> the case where the ring size is 32 (32 slots in a ring) the order of the
>> sequence numbers the receiver see is 1,2,3,4,5,...,68,69,*70*
>> ,71,72,73,...,99,100,*70*,101,102,103,... . An interesting thing I found
>> is
>> that the "gaps" between these two duplicated packets (70 in the example)
>> are always a number very close to the ring size, 32 in this example. In my
>> experiment, I use a ring with 4096 slots and the gap is always more than
>> 4090 and close to 4096. I verified that this duplication happens due to
>> the
>> sender, not the receiver. Assuming my sender's implementation is correct,
>> then this duplication may happen in netmap and the NIC driver (ixgbe).
>>
>
> Netmap itself doesn't do any duplication nor takes a look at the packets.
> It just passes
> down ring->cur/ring->head to the ixgbe driver (after validation).
> The ixgbe driver datapath is bypassed and replaced with a netmap-enabled
> datapath (see https://github.com/luigirizzo/netmap/blob/master/LINUX/
> ixgbe_netmap_linux.h#L294-L461);
> no duplication should happen there as each netmap slot (1 TX packet) is
> used
> only once.
>
>>
>>
>> Thinking back to the original problem in this post, I think these problems
>> may be related. It seems to me that there could be multiple threads
>> pulling
>> the packets from the NIC TX ring (or the thread moved to other CPUs when
>> the problem occurs) and these threads may run on different cores so that
>> the outdated content in the buffer may be sent out when new content is
>> written to the buffer.
>>
>>
> There are no such threads pulling from the NIC TX ring. Your application
> directly
> puts new packets to be transmitted in the netmap buffers referenced in the
> netmap TX
> ring. When then you call NIOCTXSYNC or poll(), all the new TX buffers
> (e.g. all
> the ones from the previous value ring->head (included) to the new value of
> ring->head (excluded))
> are moved to the NIC TX ring. This happens in the context of your
> application thread,
> no worker threads are used. Then the NIC hardware starts the transmission.
>
>
>> I am wondering if there is a way to pin the NIC driver of the netmap
>> module
>> to a specific core. or is there a way to know the root of such problem?
>>
>
> The only threads are the ones of your application.
> Maybe your problem comes from concurrent accesses to the netmap TX ring
> from different threads? Only one thread at a given time should update a
> netmap
> TX/RX ring. Otherwise the behaviour is unspecified.
>
> Cheers,
> Vincenzo
>
>
>>
>> Best,
>> Xiaoye
>>
>>
> --
> Vincenzo Maffione
>
From owner-freebsd-net@freebsd.org Fri Nov 24 21:11:24 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 2E78EDF1981
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 21:11:24 +0000 (UTC)
(envelope-from sunxiaoye07@gmail.com)
Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com
[IPv6:2607:f8b0:4003:c0f::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 D38F664B53
for <freebsd-net@freebsd.org>; Fri, 24 Nov 2017 21:11:23 +0000 (UTC)
(envelope-from sunxiaoye07@gmail.com)
Received: by mail-ot0-x235.google.com with SMTP id d27so19678988ote.11
for <freebsd-net@freebsd.org>; Fri, 24 Nov 2017 13:11:23 -0800 (PST)
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:cc;
bh=NEVk7c/npE3sM+jaQgB5icOYJlf/8FXatI3rUO9BDcU=;
b=YwdfNklMO51XdFitph2+iTGo3tReimX5gOHIxgIhV3Wih5+8IyGl//8GJEWUC8iYgP
lVSilc7wQRVSAKrBr7sL/zTKYL36p4F5BFyJoILHeNVGBt4hn2v+LEEQnw/sTInWy/wE
CHbvKciauqHtuNKFomAcZQabG1auzg66vSCnDncTg0MjBgZkUYVPBSUJ50p5ucjxMZLf
u8uuIJL6I7quWPue128Uzo6uHEoj9HTIssNgB6QnJs431WkrXJRFTM5qbJooB0qapEvt
bIpWWW4CI9O5T2imep+9fks2xjmzBGHPQq9BEM1sS9sQye/yNqvswaVeWuUPYwjUXKaL
vpYA==
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:cc;
bh=NEVk7c/npE3sM+jaQgB5icOYJlf/8FXatI3rUO9BDcU=;
b=Oj3pcQxU56axuax8A4s6v8WEUWatqw08udby3OpyBrbyAEpPmBdYpNeT8m8961T+yN
sULgutFR1B4c5scyzJ8hQxFwRgaOAL8xOa2f5aUvxCRWmCbBDH0HfHxivM6kT7zEmp7t
U1tv8i8CLJJRR2wysGNLLey4YEamdtvq0EYkSctkthNIX3iwbqwZF4BNf/p7LEQLmrZe
pcNCLUspkB9ntoF3F/xJtxlQNa3HoB2eCfntBIOqywXS4aIglCmiWOBSzDzYSVqmBYmS
Pj2OLyL7tyUvzYDTUIQjgQxN+bS3JoMHVnNUglttD5JKhheFP6LaUsLJVHF/8sKjbgyd
/Mpw==
X-Gm-Message-State: AJaThX66TAtGOhjWvQoTL8QHPcbw+ZDRq6vqvjpnVnV9PStC1mtwAljL
lvNL33DU0yYWHfwNouroJjTCBJv0BkaHScv30kE=
X-Google-Smtp-Source: AGs4zMbeuC9OhI6YnqeDA6WnBp9qWqLwFQ581Lg4NrACMeZwyRIRjYm193pe2RUPPxBvsdiBglsLlUkhYNewYnPOJqk=
X-Received: by 10.157.65.213 with SMTP id v21mr21082707oti.392.1511557882985;
Fri, 24 Nov 2017 13:11:22 -0800 (PST)
MIME-Version: 1.0
Sender: sunxiaoye07@gmail.com
Received: by 10.157.14.167 with HTTP; Fri, 24 Nov 2017 13:11:22 -0800 (PST)
In-Reply-To: <CA+_eA9h3NL6Ga4=HRjEiDtNaANkR8m7oZ9+CCpoWVB+aYW3+tw@mail.gmail.com>
References: <CAJnByzj6Dj3vouZ2NbxqvCV-2-7TVtTR4FaWKuCFaaRN2X+yAA@mail.gmail.com>
<CALgsdbd3XuE3wMYp4ey+1aer+HSVNojLYoVqwqTBPAXXdf9i+Q@mail.gmail.com>
<CAJnByzirLXdCe-kwHV2s_E6ytGJG0Dth=0Ms12RrEk7FK_+8Og@mail.gmail.com>
<CA+hQ2+gMWY0eabjHGw0=PJCAkS-wO=RBrN5brSbaqWc3_AOYoQ@mail.gmail.com>
<CAJnByziBS8o6LtmpUrUu5xtRUd008Z2hnCsp=WVFv35r2J0rHw@mail.gmail.com>
<CA+hQ2+im9nFfYnqDS2HgRbAzdf5D0iaLCmCYhfXQVVRMouUFuw@mail.gmail.com>
<CAJnByzht-qfDcm8oEg1aSRyVBZ1ygPvc2eMuoyJcq4geueTZ0Q@mail.gmail.com>
<CA+hQ2+iERgWJ=cdFB-cByfT3r11T1kKr-5HiuCYZY-rxbjf=XA@mail.gmail.com>
<CAJnByziDzdR2C6DcSRNPtrWACLq0XFpe4X1Ek9yXtFP9ivqWQw@mail.gmail.com>
<CA+hQ2+hjnuGo1xKgc8CQ7gP35tiaZG7+roZBmX8aBgb8qWnLgg@mail.gmail.com>
<CAJnByzh-VrRZeYdpkRFtCUGEN_arFBkemcN7byb51XV6UPswyg@mail.gmail.com>
<CA+hQ2+iMw3kxjpcZy77vgOEsfk2UY0-farh9C8RKXZHMU7D8kw@mail.gmail.com>
<CAJnByzgsuNBhdfPJsGrrHcU79xjK+dq2RENgUkbZcehFm8MUxg@mail.gmail.com>
<CAJnByzgNZ9YsYd7tBgYxiQPvuS_VZbhZNGvsPS-0apCDga7XFA@mail.gmail.com>
<CANpwN=uHk-VwOoFz7NaPE9A-0B=MAapqxJ-uyCBtn=oMdacYnw@mail.gmail.com>
<CAJnByzgjEEAzmWZu7BsSWHXmpjUtZcqXFGN8umCqmvgME1Jv+A@mail.gmail.com>
<CANpwN=tfqitQW0BTXA7bU+TfmP8=wr7gE8wAP=hjAamjD7ny9Q@mail.gmail.com>
<CAJnByzi5WHHvwcrmEOkJOHf5SJekbTtQoUgLmPbMtwTotc8mzA@mail.gmail.com>
<CAJnByzhJnrmiwiLEEQV0meg7+DnLJ6Jq_J=6L=35Z9Lgw1GcyA@mail.gmail.com>
<CA+hQ2+jTXyYdN4N4aWOkDdkBr+D3quocHn+c8MA+xc9yLs9V4w@mail.gmail.com>
<CAJnByzg0PCXCyjnypS_2+RhKB0mf_4s8X1niFiyfedaCLUku7Q@mail.gmail.com>
<CAJnByzipicNHhmw0kGq0cXnfgXqq1xP0aJ4dqr12SryBV1Ny3w@mail.gmail.com>
<CA+_eA9h3NL6Ga4=HRjEiDtNaANkR8m7oZ9+CCpoWVB+aYW3+tw@mail.gmail.com>
From: Xiaoye Sun <Xiaoye.Sun@rice.edu>
Date: Fri, 24 Nov 2017 15:11:22 -0600
X-Google-Sender-Auth: yY_4K5yjfuJpVy0nDJfpH0Hqexs
Message-ID: <CAJnByziVfVJ6gX_aL+wFvmW9ZsfwPV1RRCkxgEbZMoe1kSo35A@mail.gmail.com>
Subject: Re: swaping ring slots between NIC ring and Host ring does not always
success
To: Vincenzo Maffione <v.maffione@gmail.com>
Cc: Luigi Rizzo <rizzo@iet.unipi.it>,
"freebsd-net@freebsd.org" <freebsd-net@freebsd.org>,
Victor Detoni <victordetoni@gmail.com>,
Pavel Odintsov <pavel.odintsov@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 21:11:24 -0000
Hi Vincenzo,
Let me clarify my problem. (please ignore the previous incompleted email)
I have a program, which is an extension of bridge.c
https://github.com/luigirizzo/netmap/blob/master/apps/bridge/bridge.c
The only difference is that my program also generates customized packets
sent to the NIC directly.
These customized packets have increasing sequence numbers.
So, this program not only sends these customized packets but also forwards
packets between NIC and host stack using zerocopy.
The program only takes one NIC queue and there is only one thread.
I think the problem is that there is a chance where netmap does not update
the pointer to the buffer even when NS_BUF_CHANGED is set (buf_idx is
changed).
Let's say the NIC tx ring has 4096 slots. The customized packet sequence 16
is filled in the buffer of slot 2057.
The customized packets keep filling the slots until the next available
slot is 2056.
Now the customised packet sequence 4111 is filled to 2056.
Then the netmap program is notified that there is a packet from the host
stack sent to the NIC.
The netmap program swaps the buf_idx between slot 2057 and the
corresponding slot in the host rx ring and set the NS_BUF_CHANGED flag of
both slots.
Then the netmap program fills sequence 4112 to slot 2058.
However, the buffer swap seems not succeed so that the original content of
slot 2057 (sequence 16) is sent out.
So that at the receiver side, the receiver sees two sequence
16s.(16,17...4110,4111,16,4112,4113).
So think the root of the problem is that the buffer pointer is not always
successfully/timely updated even after the NS_BUF_CHANGED flag is set and
the buf_idx is updated.
Best,
Xiaoye
On Wed, Nov 22, 2017 at 7:39 AM, Vincenzo Maffione <v.maffione@gmail.com>
wrote:
> Hi,
>
> 2017-11-21 7:51 GMT+01:00 Xiaoye Sun <Xiaoye.Sun@rice.edu>:
>
>> Hi,
>>
>> Recently I found another problem with netmap. I think this new problem
>> could be related to the problems in this threads so I just post the new
>> problem here.
>>
>> In my setup, I have a sender program having a netmap ring (a pair of
>> RX/TX ring) for the NIC and a ring for the host stack. The sender program
>> puts customized packets (each packet has a unique sequence number and the
>> sender sends the packet in a sequence number increasing order) to the NIC
>> TX ring directly and also forwards the packets from the host RX ring to
>> the
>> NIC TX ring using "zerocopy" by swapping the buffer indices.
>> However, the receiver sees duplicated customized packets. For example, in
>> the case where the ring size is 32 (32 slots in a ring) the order of the
>> sequence numbers the receiver see is 1,2,3,4,5,...,68,69,*70*
>> ,71,72,73,...,99,100,*70*,101,102,103,... . An interesting thing I found
>> is
>> that the "gaps" between these two duplicated packets (70 in the example)
>> are always a number very close to the ring size, 32 in this example. In my
>> experiment, I use a ring with 4096 slots and the gap is always more than
>> 4090 and close to 4096. I verified that this duplication happens due to
>> the
>> sender, not the receiver. Assuming my sender's implementation is correct,
>> then this duplication may happen in netmap and the NIC driver (ixgbe).
>>
>
> Netmap itself doesn't do any duplication nor takes a look at the packets.
> It just passes
> down ring->cur/ring->head to the ixgbe driver (after validation).
> The ixgbe driver datapath is bypassed and replaced with a netmap-enabled
> datapath (see https://github.com/luigirizzo/netmap/blob/master/LINUX/
> ixgbe_netmap_linux.h#L294-L461);
> no duplication should happen there as each netmap slot (1 TX packet) is
> used
> only once.
>
>>
>>
>> Thinking back to the original problem in this post, I think these problems
>> may be related. It seems to me that there could be multiple threads
>> pulling
>> the packets from the NIC TX ring (or the thread moved to other CPUs when
>> the problem occurs) and these threads may run on different cores so that
>> the outdated content in the buffer may be sent out when new content is
>> written to the buffer.
>>
>>
> There are no such threads pulling from the NIC TX ring. Your application
> directly
> puts new packets to be transmitted in the netmap buffers referenced in the
> netmap TX
> ring. When then you call NIOCTXSYNC or poll(), all the new TX buffers
> (e.g. all
> the ones from the previous value ring->head (included) to the new value of
> ring->head (excluded))
> are moved to the NIC TX ring. This happens in the context of your
> application thread,
> no worker threads are used. Then the NIC hardware starts the transmission.
>
>
>> I am wondering if there is a way to pin the NIC driver of the netmap
>> module
>> to a specific core. or is there a way to know the root of such problem?
>>
>
> The only threads are the ones of your application.
> Maybe your problem comes from concurrent accesses to the netmap TX ring
> from different threads? Only one thread at a given time should update a
> netmap
> TX/RX ring. Otherwise the behaviour is unspecified.
>
> Cheers,
> Vincenzo
>
>
>>
>> Best,
>> Xiaoye
>>
>>
> --
> Vincenzo Maffione
>
From owner-freebsd-net@freebsd.org Fri Nov 24 23:19:25 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 ABF6EDF3C6C
for <freebsd-net@mailman.ysv.freebsd.org>;
Fri, 24 Nov 2017 23:19:25 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 99E606868E
for <freebsd-net@FreeBSD.org>; Fri, 24 Nov 2017 23:19:25 +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 vAONJOiX035992
for <freebsd-net@FreeBSD.org>; Fri, 24 Nov 2017 23:19:25 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223835] BGP session not established with md5 password via
FRRouting
Date: Fri, 24 Nov 2017 23:19:24 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.1-STABLE
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: pautina@kharkiv.net
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: Not A Bug
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: resolution bug_status
Message-ID: <bug-223835-2472-tZ8IEZP972@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223835-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223835-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 23:19:25 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223835
Alexey <pautina@kharkiv.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |Not A Bug
Status|New |Closed
--- Comment #10 from Alexey <pautina@kharkiv.net> ---
Good night everybody.
The problem is solved.
Many thanks to Marek Zarychta mailto:zarychtam@plan-b.pwste.edu.pl for the
help.
He showed me a similar problem:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219453.
=D0=90nd indeed, the problem was that on the interface TX/RX checksums was =
disabled.
Now everything works with the following settings:
On interface ix0 or ixl0 or other must be turn ON: rxcsum txcsum; (ifconfig
ixl0 rxcsum txcsum)
At /etc/rc.conf:
ifconfig_ixl0=3D"up -tso -lro -vlanhwtso" (I disabled only tso and lro)
ipsec_enable=3D"YES"
ipsec_file=3D"/etc/ipsec.conf"
At /etc/ipsec.conf:
flush;
add 185.1.62.241 185.1.62.69 tcp 0x1000 -A tcp-md5 "some_password";
add 185.1.62.69 185.1.62.241 tcp 0x1001 -A tcp-md5 "some_password";
On kernel you must add next:
options IPSEC # IP (v4/v6) security
options IPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5
# The crypto framework is required by IPSEC
device crypto # Required by IPSEC
device cryptodev
options TCP_SIGNATURE
And need set password for neighbor on FRRouting, for example:
neighbor 185.1.62.69 password some_password
I think it's necessary to describe all this in documentation.=20
This would be good, as this problem arises for many. Or you can simply forg=
et
about it :)
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-net@freebsd.org Sat Nov 25 01:48:41 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 78A51DF75AF;
Sat, 25 Nov 2017 01:48:41 +0000 (UTC)
(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "gate2.funkthat.com",
Issuer "Let's Encrypt Authority X3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 5CD426C7C9;
Sat, 25 Nov 2017 01:48:40 +0000 (UTC)
(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (localhost [127.0.0.1])
by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id vAP1lt6L097598
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Fri, 24 Nov 2017 17:47:55 -0800 (PST)
(envelope-from jmg@gold.funkthat.com)
Received: (from jmg@localhost)
by gold.funkthat.com (8.15.2/8.15.2/Submit) id vAP1ltXD097597;
Fri, 24 Nov 2017 17:47:55 -0800 (PST) (envelope-from jmg)
Date: Fri, 24 Nov 2017 17:47:55 -0800
From: John-Mark Gurney <jmg@funkthat.com>
To: freebsd-net@FreeBSD.org
Cc: freebsd-current@FreeBSD.org
Subject: vlans + bridging is "interesting"
Message-ID: <20171125014755.GN42467@funkthat.com>
Mail-Followup-To: freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64
X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65
X-Files: The truth is out there
X-URL: https://www.funkthat.com/
X-Resume: https://www.funkthat.com/~jmg/resume.html
X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE
X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger?
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3
(gold.funkthat.com [127.0.0.1]); Fri, 24 Nov 2017 17:47:55 -0800 (PST)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Nov 2017 01:48:41 -0000
Hello,
I decided to try to run some bhyve VM's on my machine and bridge
them to a guest vlan on my main interface. I also want to support
running bhyve VM's on the untagged part of the interface as well
(this is the key problem as I'll describe later).
I configure it as you'd expect. Bridge the main interface em0, and
put the local IP's on the bridge0. Then I added an interface em0.14
that untags packets from em0, and added it to bridge1 along w/ a tap0
for the VM. This does not work. Packet goes out and comes back and
is observed on em0, but never appears on either em0.14 or bridge1.
After seeing: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139268
I decide to look on bridge0, and see the tagged vlan packet on that
interface. I attempted to add bridge0 as the vlandev for em0.14, but
that doesn't work:
#ifconfig em0.14 vlan 14 vlandev bridge0
ifconfig: SIOCSETVLAN: Protocol not supported
So, I did finally get things working by using epair. I added an epair
to the bridge, and that allows me to untag the packet, and pass on to
bridge1.
I have not attempted to use the patch in 139268, but if people think
it is an acceptable solution (with patch, if I set LINK0, it should work
w/ original configuration), I'll test and commit the patch.
Otherwise, please submit another fix.
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
From owner-freebsd-net@freebsd.org Sat Nov 25 02:26:07 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 80494DF993B;
Sat, 25 Nov 2017 02:26:07 +0000 (UTC)
(envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net)
Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 2D5ED6E34C;
Sat, 25 Nov 2017 02:26:06 +0000 (UTC)
(envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net)
Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1])
by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vAP2Q3Ji098083;
Fri, 24 Nov 2017 18:26:03 -0800 (PST)
(envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net)
Received: (from freebsd-rwg@localhost)
by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vAP2Q3jd098082;
Fri, 24 Nov 2017 18:26:03 -0800 (PST) (envelope-from freebsd-rwg)
From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>
Message-Id: <201711250226.vAP2Q3jd098082@pdx.rh.CN85.dnsmgr.net>
Subject: Re: vlans + bridging is "interesting"
In-Reply-To: <20171125014755.GN42467@funkthat.com>
To: John-Mark Gurney <jmg@funkthat.com>
Date: Fri, 24 Nov 2017 18:26:03 -0800 (PST)
CC: freebsd-net@freebsd.org, freebsd-current@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Nov 2017 02:26:07 -0000
> Hello,
>
> I decided to try to run some bhyve VM's on my machine and bridge
> them to a guest vlan on my main interface. I also want to support
> running bhyve VM's on the untagged part of the interface as well
> (this is the key problem as I'll describe later).
>
> I configure it as you'd expect. Bridge the main interface em0, and
> put the local IP's on the bridge0. Then I added an interface em0.14
> that untags packets from em0, and added it to bridge1 along w/ a tap0
> for the VM. This does not work. Packet goes out and comes back and
> is observed on em0, but never appears on either em0.14 or bridge1.
>
> After seeing: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139268
>
> I decide to look on bridge0, and see the tagged vlan packet on that
> interface. I attempted to add bridge0 as the vlandev for em0.14, but
> that doesn't work:
> #ifconfig em0.14 vlan 14 vlandev bridge0
> ifconfig: SIOCSETVLAN: Protocol not supported
>
> So, I did finally get things working by using epair. I added an epair
> to the bridge, and that allows me to untag the packet, and pass on to
> bridge1.
>
> I have not attempted to use the patch in 139268, but if people think
> it is an acceptable solution (with patch, if I set LINK0, it should work
> w/ original configuration), I'll test and commit the patch.
>
> Otherwise, please submit another fix.
>
> Thanks.
I am also experiencing difficulties with vlan +briding +bhyve. It
seems the host that can talk just fine out a trunked em0 interface
using vlan32 and vlan34 to all my other hardware can NOT talk to
my bhyve guests. Those bhyve guests can also talk out that
same interface to other hardware, but they are being passed in
the trunked interface, ie direct tap of bridge of em0 and the
vlan tagging/untagging is being done inside the guest.
All the guests can talk to each other and they can all talk
to real hardware that is via the em0 hardware, same for the
host, but the host can not talk to the guests nor the guests
to the host.
My guess is that the arp's are not being seen by the bridge
cause they are wrapping in vlan tags thus the bridge
never learns all the mac addresses, but this is just a
guess.
--
Rod Grimes rgrimes@freebsd.org
From owner-freebsd-net@freebsd.org Sat Nov 25 06:59:27 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 A7D09DBA3E4;
Sat, 25 Nov 2017 06:59:27 +0000 (UTC)
(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "gate2.funkthat.com",
Issuer "Let's Encrypt Authority X3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 8A679774A5;
Sat, 25 Nov 2017 06:59:26 +0000 (UTC)
(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (localhost [127.0.0.1])
by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id vAP6xP9p009484
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Fri, 24 Nov 2017 22:59:25 -0800 (PST)
(envelope-from jmg@gold.funkthat.com)
Received: (from jmg@localhost)
by gold.funkthat.com (8.15.2/8.15.2/Submit) id vAP6xPUN009481;
Fri, 24 Nov 2017 22:59:25 -0800 (PST) (envelope-from jmg)
Date: Fri, 24 Nov 2017 22:59:25 -0800
From: John-Mark Gurney <jmg@funkthat.com>
To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>
Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org
Subject: Re: vlans + bridging is "interesting"
Message-ID: <20171125065925.GO42467@funkthat.com>
Mail-Followup-To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>,
freebsd-net@freebsd.org, freebsd-current@freebsd.org
References: <20171125014755.GN42467@funkthat.com>
<201711250226.vAP2Q3jd098082@pdx.rh.CN85.dnsmgr.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201711250226.vAP2Q3jd098082@pdx.rh.CN85.dnsmgr.net>
X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64
X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65
X-Files: The truth is out there
X-URL: https://www.funkthat.com/
X-Resume: https://www.funkthat.com/~jmg/resume.html
X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE
X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger?
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3
(gold.funkthat.com [127.0.0.1]); Fri, 24 Nov 2017 22:59:25 -0800 (PST)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Nov 2017 06:59:27 -0000
Rodney W. Grimes wrote this message on Fri, Nov 24, 2017 at 18:26 -0800:
> > I decided to try to run some bhyve VM's on my machine and bridge
> > them to a guest vlan on my main interface. I also want to support
> > running bhyve VM's on the untagged part of the interface as well
> > (this is the key problem as I'll describe later).
> >
> > I configure it as you'd expect. Bridge the main interface em0, and
> > put the local IP's on the bridge0. Then I added an interface em0.14
> > that untags packets from em0, and added it to bridge1 along w/ a tap0
> > for the VM. This does not work. Packet goes out and comes back and
> > is observed on em0, but never appears on either em0.14 or bridge1.
> >
> > After seeing: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139268
> >
> > I decide to look on bridge0, and see the tagged vlan packet on that
> > interface. I attempted to add bridge0 as the vlandev for em0.14, but
> > that doesn't work:
> > #ifconfig em0.14 vlan 14 vlandev bridge0
> > ifconfig: SIOCSETVLAN: Protocol not supported
> >
> > So, I did finally get things working by using epair. I added an epair
> > to the bridge, and that allows me to untag the packet, and pass on to
> > bridge1.
> >
> > I have not attempted to use the patch in 139268, but if people think
> > it is an acceptable solution (with patch, if I set LINK0, it should work
> > w/ original configuration), I'll test and commit the patch.
> >
> > Otherwise, please submit another fix.
>
> I am also experiencing difficulties with vlan +briding +bhyve. It
> seems the host that can talk just fine out a trunked em0 interface
> using vlan32 and vlan34 to all my other hardware can NOT talk to
> my bhyve guests. Those bhyve guests can also talk out that
> same interface to other hardware, but they are being passed in
> the trunked interface, ie direct tap of bridge of em0 and the
> vlan tagging/untagging is being done inside the guest.
>
> All the guests can talk to each other and they can all talk
> to real hardware that is via the em0 hardware, same for the
> host, but the host can not talk to the guests nor the guests
> to the host.
This is probably related. I'm going to take a stab at your config,
so correct me if I'm wrong:
bridge0 w/ em0 & tapX
vlan32 on em0 vlan 32
vlan34 on em0 vlan 34
If this is the case, you're running into the same issue that I'm running
into... The issue is that when a packet comes in on em0, it is
forwarded directly to bridge0, bypassing the vlan interfaces...
If you do what I did above, which is add an epair interface to the
bridge, and then add the vlan's off the epair interface, it will work...
As w/ the epair you are effectively simulating what your VM does, and
doing the encap/decap as the "VM" in the host...
The issue is that packets make it out em0 properly wrapped, but they'll
never make it back to the vlan32 interface, em0 forwards it directly to
bridge0, bypassing the vlan32 interface, and the bridge0 has no where to
deliver the packet, and it gets dropped...
The reason the vms work is that as you're doing decap in the VM, the
encapsulated packets are making it successfully to them, and their
encapsulated replies are making it safely back to the switch...
> My guess is that the arp's are not being seen by the bridge
> cause they are wrapping in vlan tags thus the bridge
> never learns all the mac addresses, but this is just a
> guess.
I finally figured this out w/ tcpdump, as tcpdump was showing the
packets going out em0.14 (in my case), but the reply was never making
it back to em0.14. I was seeing it on em0 w/ "tcpdump -i em0 vlan 14",
and then, when I ran "tcpdump -i bridge0 vlan 14", I saw this missing
packet, which is how I decided to come up w/ the epair "solution"...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
From owner-freebsd-net@freebsd.org Sat Nov 25 07:23:24 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 CDEE7DBAA65
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 25 Nov 2017 07:23:24 +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 BC2FA7804F
for <freebsd-net@FreeBSD.org>; Sat, 25 Nov 2017 07:23:24 +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 vAP7NOQ3060458
for <freebsd-net@FreeBSD.org>; Sat, 25 Nov 2017 07:23:24 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223817] mbuf leaking with tcpmd5
Date: Sat, 25 Nov 2017 07:23:24 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.1-RELEASE
X-Bugzilla-Keywords: regression
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: dinoex@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-223817-2472-Z9LZlo0QJa@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223817-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223817-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Nov 2017 07:23:24 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223817
--- Comment #2 from Dirk Meyer <dinoex@FreeBSD.org> ---
uptime 3 min
tcp:
13140 packets sent
208 data packets (15004 bytes)
0 data packets (0 bytes) retransmitted
0 data packets unnecessarily retransmitted
0 resends initiated by MTU discovery
8423 ack-only packets (457 delayed)
0 URG only packets
0 window probe packets
4485 window update packets
24 control packets
18601 packets received
163 acks (for 15011 bytes)
35 duplicate acks
0 acks for unsent data
17810 packets (21631400 bytes) received in-sequence
35 completely duplicate packets (26221 bytes)
0 old duplicate packets
9 packets with some dup. data (11927 bytes duped)
464 out-of-order packets (625887 bytes)
0 packets (0 bytes) of data after window
0 window probes
0 window update packets
0 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 discarded due to memory problems
18 connection requests
1 connection accept
0 bad connection attempts
0 listen queue overflows
0 ignored RSTs in the windows
11 connections established (including accepts)
0 times used RTT from hostcache
0 times used RTT variance from hostcache
0 times used slow-start threshold from hostcache
17 connections closed (including 0 drops)
1 connection updated cached RTT on close
1 connection updated cached RTT variance on close
0 connections updated cached ssthresh on close
6 embryonic connections dropped
163 segments updated rtt (of 170 attempts)
62 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts
0 connections dropped by persist timeout
0 Connections (fin_wait_2) dropped because of timeout
6 keepalive timeouts
0 keepalive probes sent
6 connections dropped by keepalive
92 correct ACK header predictions
17774 correct data packet header predictions
1 syncache entry added
0 retransmitted
0 dupsyn
0 dropped
1 completed
0 bucket overflow
0 cache overflow
0 reset
0 stale
0 aborted
0 badack
0 unreach
0 zone failures
1 cookie sent
0 cookies received
1 hostcache entry added
0 bucket overflow
0 SACK recovery episodes
0 segment rexmits in SACK recovery episodes
0 byte rexmits in SACK recovery episodes
0 SACK options (SACK blocks) received
0 SACK options (SACK blocks) sent
0 SACK scoreboard overflow
0 packets with ECN CE bit set
0 packets with ECN ECT(0) bit set
0 packets with ECN ECT(1) bit set
0 successful ECN handshakes
0 times ECN reduced the congestion window
0 packets with matching signature received
0 packets with bad signature received
143 times failed to make signature due to no SA
0 times unexpected signature received
10 times no signature provided by segment
TCP connection count by state:
0 connections in CLOSED state
4 connections in LISTEN state
2 connections in SYN_SENT state
0 connections in SYN_RCVD state
5 connections in ESTABLISHED state
0 connections in CLOSE_WAIT state
0 connections in FIN_WAIT_1 state
0 connections in CLOSING state
0 connections in LAST_ACK state
0 connections in FIN_WAIT_2 state
0 connections in TIME_WAIT state
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-net@freebsd.org Sat Nov 25 07:24:18 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 BB782DBAAFB
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 25 Nov 2017 07:24:18 +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 AA6E07811C
for <freebsd-net@FreeBSD.org>; Sat, 25 Nov 2017 07:24:18 +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 vAP7OIBl061653
for <freebsd-net@FreeBSD.org>; Sat, 25 Nov 2017 07:24:18 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223817] mbuf leaking with tcpmd5
Date: Sat, 25 Nov 2017 07:24:18 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.1-RELEASE
X-Bugzilla-Keywords: regression
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: dinoex@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-223817-2472-xwRRZZMcLL@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223817-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223817-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Nov 2017 07:24:18 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223817
--- Comment #3 from Dirk Meyer <dinoex@FreeBSD.org> ---
uptime 30 min
tcp:
19129 packets sent
673 data packets (32758 bytes)
0 data packets (0 bytes) retransmitted
0 data packets unnecessarily retransmitted
0 resends initiated by MTU discovery
13871 ack-only packets (5040 delayed)
0 URG only packets
0 window probe packets
4485 window update packets
100 control packets
25085 packets received
572 acks (for 32765 bytes)
35 duplicate acks
0 acks for unsent data
23055 packets (22835499 bytes) received in-sequence
35 completely duplicate packets (26221 bytes)
0 old duplicate packets
9 packets with some dup. data (11927 bytes duped)
464 out-of-order packets (625887 bytes)
0 packets (0 bytes) of data after window
0 window probes
0 window update packets
0 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 discarded due to memory problems
94 connection requests
1 connection accept
0 bad connection attempts
0 listen queue overflows
1 ignored RSTs in the window
11 connections established (including accepts)
0 times used RTT from hostcache
0 times used RTT variance from hostcache
0 times used RTT from hostcache
0 times used RTT variance from hostcache
0 times used slow-start threshold from hostcache
93 connections closed (including 0 drops)
1 connection updated cached RTT on close
1 connection updated cached RTT variance on close
0 connections updated cached ssthresh on close
82 embryonic connections dropped
572 segments updated rtt (of 655 attempts)
669 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts
0 connections dropped by persist timeout
0 Connections (fin_wait_2) dropped because of timeout
82 keepalive timeouts
0 keepalive probes sent
82 connections dropped by keepalive
455 correct ACK header predictions
22992 correct data packet header predictions
1 syncache entry added
0 retransmitted
0 dupsyn
0 dropped
1 completed
0 bucket overflow
0 cache overflow
0 reset
0 stale
0 aborted
0 badack
0 unreach
0 zone failures
1 cookie sent
0 cookies received
1 hostcache entry added
0 bucket overflow
0 SACK recovery episodes
0 segment rexmits in SACK recovery episodes
0 byte rexmits in SACK recovery episodes
0 SACK options (SACK blocks) received
0 SACK options (SACK blocks) sent
0 SACK scoreboard overflow
0 packets with ECN CE bit set
0 packets with ECN ECT(0) bit set
0 packets with ECN ECT(1) bit set
0 successful ECN handshakes
0 times ECN reduced the congestion window
0 packets with matching signature received
0 packets with bad signature received
1209 times failed to make signature due to no SA
0 times unexpected signature received
10 times no signature provided by segment
TCP connection count by state:
0 connections in CLOSED state
4 connections in LISTEN state
2 connections in SYN_SENT state
0 connections in SYN_RCVD state
5 connections in ESTABLISHED state
0 connections in CLOSE_WAIT state
0 connections in FIN_WAIT_1 state
0 connections in CLOSING state
0 connections in LAST_ACK state
0 connections in FIN_WAIT_2 state
0 connections in TIME_WAIT state
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-net@freebsd.org Sat Nov 25 07:26:41 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 A7476DBAC1E
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 25 Nov 2017 07:26:41 +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 9562D781F0
for <freebsd-net@FreeBSD.org>; Sat, 25 Nov 2017 07:26:41 +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 vAP7Qf8I064791
for <freebsd-net@FreeBSD.org>; Sat, 25 Nov 2017 07:26:41 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223817] mbuf leaking with tcpmd5
Date: Sat, 25 Nov 2017 07:26:41 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.1-RELEASE
X-Bugzilla-Keywords: regression
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: dinoex@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-223817-2472-7XD40ZUxLp@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223817-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223817-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Nov 2017 07:26:41 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223817
--- Comment #4 from Dirk Meyer <dinoex@FreeBSD.org> ---
The same command on FreeeBSD 10.3
shows data for tcpmd5.
uptime 2 days:
root@hbw2:~# netstat -sp tcp
tcp:
404820 packets sent
16566 data packets (809618 bytes)
9 data packets (171 bytes) retransmitted
0 data packets unnecessarily retransmitted
0 resends initiated by MTU discovery
381530 ack-only packets (351256 delayed)
0 URG only packets
0 window probe packets
6703 window update packets
12 control packets
453693 packets received
15429 acks (for 809625 bytes)
6189 duplicate acks
0 acks for unsent data
420555 packets (130396892 bytes) received in-sequence
42 completely duplicate packets (32133 bytes)
0 old duplicate packets
9 packets with some dup. data (9812 bytes duped)
222 out-of-order packets (240797 bytes)
0 packets (0 bytes) of data after window
0 window probes
25 window update packets
0 packets received after close
3 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 discarded due to memory problems
8 connection requests
5 connection accepts
0 bad connection attempts
0 listen queue overflows
0 ignored RSTs in the windows
11 connections established (including accepts)
11 connections closed (including 0 drops)
4 connections updated cached RTT on close
4 connections updated cached RTT variance on close
0 connections updated cached ssthresh on close
0 embryonic connections dropped
15426 segments updated rtt (of 15426 attempts)
7 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts
0 connections dropped by persist timeout
0 Connections (fin_wait_2) dropped because of timeout
8 keepalive timeouts
8 keepalive probes sent
0 connections dropped by keepalive
13389 correct ACK header predictions
419108 correct data packet header predictions
10 syncache entries added
15 retransmitted
0 dupsyn
0 dropped
5 completed
0 bucket overflow
0 cache overflow
0 reset
5 stale
0 aborted
0 badack
0 unreach
0 zone failures
10 cookies sent
0 cookies received
3 hostcache entries added
0 bucket overflow
0 SACK recovery episodes
0 segment rexmits in SACK recovery episodes
0 byte rexmits in SACK recovery episodes
0 SACK options (SACK blocks) received
0 SACK options (SACK blocks) sent
0 SACK scoreboard overflow
0 packets with ECN CE bit set
0 packets with ECN ECT(0) bit set
0 packets with ECN ECT(1) bit set
0 successful ECN handshakes
0 times ECN reduced the congestion window
252573 packets with valid tcp-md5 signature received
2 packets with invalid tcp-md5 signature received
0 packets with tcp-md5 signature mismatch
0 packets with unexpected tcp-md5 signature received
2 packets without expected tcp-md5 signature received
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-net@freebsd.org Sat Nov 25 08:29:42 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 8E5B7DBBF04
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 25 Nov 2017 08:29:42 +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 7D22479AE1
for <freebsd-net@FreeBSD.org>; Sat, 25 Nov 2017 08:29:42 +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 vAP8TgYS009605
for <freebsd-net@FreeBSD.org>; Sat, 25 Nov 2017 08:29:42 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223817] mbuf leaking with tcpmd5
Date: Sat, 25 Nov 2017 08:29:42 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.1-RELEASE
X-Bugzilla-Keywords: regression
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: ae@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-223817-2472-gZqxVOCqn3@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223817-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223817-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Nov 2017 08:29:42 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223817
--- Comment #5 from Andrey V. Elsukov <ae@FreeBSD.org> ---
Can you try to see what will show the following dtrace script?
# kldload dtraceall
# dtrace -n 'fbt::tcp_ipsec_output:return {printf("%d", arg1);}'
Also, it seems your MD5-signed connections doesn't work. Probably you need =
to
check that SAs for both directions are created.
--=20
You are receiving this mail because:
You are the assignee for the bug.=
From owner-freebsd-net@freebsd.org Sat Nov 25 09:32:05 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 B20F5DC0EDF
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 25 Nov 2017 09:32:05 +0000 (UTC)
(envelope-from buchtajz@borsice.net)
Received: from smtpsec.sitkom.cz (smtpsec.sitkom.cz [IPv6:2a03:3a00:1:2::9:25])
by mx1.freebsd.org (Postfix) with ESMTP id 6FAB07B2B2
for <freebsd-net@freebsd.org>; Sat, 25 Nov 2017 09:32:05 +0000 (UTC)
(envelope-from buchtajz@borsice.net)
Received: from [IPv6:2a03:3a00:2:a00:458a:ef8b:9fd9:334b] (unknown
[IPv6:2a03:3a00:2:a00:458a:ef8b:9fd9:334b])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by smtpsec.sitkom.cz (Postfix) with ESMTPSA id BC0677BB8
for <freebsd-net@freebsd.org>; Sat, 25 Nov 2017 10:31:54 +0100 (CET)
Subject: Re: vlans + bridging is "interesting"
To: freebsd-net@freebsd.org
References: <20171125014755.GN42467@funkthat.com>
From: =?UTF-8?Q?Michal_Bucht=c3=adk?= <buchtajz@borsice.net>
Message-ID: <7b55197b-8f9d-6a54-3db4-70d4fc52abd0@borsice.net>
Date: Sat, 25 Nov 2017 10:32:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171125014755.GN42467@funkthat.com>
Content-Type: text/plain; charset=iso-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: cs
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Nov 2017 09:32:05 -0000
Hi,
maybe i don't understand you needs, but why do you create bridge0 and
add local ip's to it?.
When you would like to see untaged packets on VM, to this simple setup:
keep em0 as "trunk" interface
create interface em0.14
create bridge14 and add to it interfaces tap0 and em0.14
add local ip to bridge14
ifconfig em0.14 create
ifconfig em0.14 up
ifconfig bridge14 create
ifconfig bridge14 addm tap0 addm em0.14
ifconfig bridge14 up
ifconfig bridge14 <localip>
then your VM will can communicate (untagged) with your host system, and
you will see tagged packets on em0 (and untagged on em0.14 of course)
Michal
Dne 25.11.2017 v 2:47 John-Mark Gurney napsal(a):
> Hello,
>
> I decided to try to run some bhyve VM's on my machine and bridge
> them to a guest vlan on my main interface. I also want to support
> running bhyve VM's on the untagged part of the interface as well
> (this is the key problem as I'll describe later).
>
> I configure it as you'd expect. Bridge the main interface em0, and
> put the local IP's on the bridge0. Then I added an interface em0.14
> that untags packets from em0, and added it to bridge1 along w/ a tap0
> for the VM. This does not work. Packet goes out and comes back and
> is observed on em0, but never appears on either em0.14 or bridge1.
>
> After seeing: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139268
>
> I decide to look on bridge0, and see the tagged vlan packet on that
> interface. I attempted to add bridge0 as the vlandev for em0.14, but
> that doesn't work:
> #ifconfig em0.14 vlan 14 vlandev bridge0
> ifconfig: SIOCSETVLAN: Protocol not supported
>
> So, I did finally get things working by using epair. I added an epair
> to the bridge, and that allows me to untag the packet, and pass on to
> bridge1.
>
> I have not attempted to use the patch in 139268, but if people think
> it is an acceptable solution (with patch, if I set LINK0, it should work
> w/ original configuration), I'll test and commit the patch.
>
> Otherwise, please submit another fix.
>
> Thanks.
>
From owner-freebsd-net@freebsd.org Sat Nov 25 13:27:49 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@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 19C70DE39B6
for <freebsd-net@mailman.ysv.freebsd.org>;
Sat, 25 Nov 2017 13:27:49 +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 01F2980D35
for <freebsd-net@FreeBSD.org>; Sat, 25 Nov 2017 13:27:49 +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 vAPDRmG8008038
for <freebsd-net@FreeBSD.org>; Sat, 25 Nov 2017 13:27:48 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-net@FreeBSD.org
Subject: [Bug 223835] BGP session not established with md5 password via
FRRouting
Date: Sat, 25 Nov 2017 13:27:49 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.1-STABLE
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: pautina@kharkiv.net
X-Bugzilla-Status: Open
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: resolution bug_status
Message-ID: <bug-223835-2472-tadADYXzFP@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-223835-2472@https.bugs.freebsd.org/bugzilla/>
References: <bug-223835-2472@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-net@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Nov 2017 13:27:49 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223835
Alexey <pautina@kharkiv.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|Not A Bug |---
Status|Closed |Open
--- Comment #11 from Alexey <pautina@kharkiv.net> ---
Maybe it's still a bug.
--=20
You are receiving this mail because:
You are the assignee for the bug.=