From owner-freebsd-net@FreeBSD.ORG  Sun Jul 24 04:18:51 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 79EB9106566C;
	Sun, 24 Jul 2011 04:18:51 +0000 (UTC)
	(envelope-from rysto32@gmail.com)
Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com
	[209.85.215.54])
	by mx1.freebsd.org (Postfix) with ESMTP id 84F908FC0A;
	Sun, 24 Jul 2011 04:18:50 +0000 (UTC)
Received: by ewy1 with SMTP id 1so2947817ewy.13
	for <multiple recipients>; Sat, 23 Jul 2011 21:18:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=02rWBbcjVuzh6/AXPFasqTir3PFQjhEZ/HjA/SobU9k=;
	b=ovQeV4pmgNDj1KjsdQSdg1Oq4LjgdwURX1yTR61Rse6G+uQxMMwXrB+CI/+mW+iLmJ
	Ci7Rz2Dwh8OgBNFaHiz5Z+XmRSud71d8XVmvmy8zbAOH2fA8bsBz/V8C0/WWO8cgNG0b
	0T2/llrzKDcT93dYVBeQnMcNkqwOxyqBYJDuU=
MIME-Version: 1.0
Received: by 10.213.105.145 with SMTP id t17mr1282426ebo.31.1311479470609;
	Sat, 23 Jul 2011 20:51:10 -0700 (PDT)
Received: by 10.213.31.194 with HTTP; Sat, 23 Jul 2011 20:51:10 -0700 (PDT)
In-Reply-To: <20110714154457.GI70776@FreeBSD.org>
References: <20110714154457.GI70776@FreeBSD.org>
Date: Sat, 23 Jul 2011 23:51:10 -0400
Message-ID: <CAFMmRNwBbxR-F7PjkwF8E4GjwFQy_0USKW-3u-ZRNxPMJSOQcA@mail.gmail.com>
From: Ryan Stone <rysto32@gmail.com>
To: Gleb Smirnoff <glebius@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: gnn@freebsd.org, bz@freebsd.org, rwatson@freebsd.org, net@freebsd.org
Subject: Re: m_pkthdr.rcvif dangling pointer problem
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jul 2011 04:18:51 -0000

I ran headlong into this issue today when trying to test some network
stack changes.  It's depressingly easy to crash HEAD by periodically
destroying vlan interfaces while you are sending traffic over those
interfaces -- I get a panic within minutes.

> http://people.freebsd.org/~glebius/patches/ifnet.no_free

This patch makes my test system survive longer but does not resolve the issue.

From owner-freebsd-net@FreeBSD.ORG  Sun Jul 24 08:44:04 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 2945F106566C;
	Sun, 24 Jul 2011 08:44:04 +0000 (UTC)
	(envelope-from rwatson@freebsd.org)
Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42])
	by mx1.freebsd.org (Postfix) with ESMTP id 037FC8FC12;
	Sun, 24 Jul 2011 08:44:04 +0000 (UTC)
Received: from [192.168.2.112]
	(host86-148-225-194.range86-148.btcentralplus.com [86.148.225.194])
	by cyrus.watson.org (Postfix) with ESMTPSA id 62A5C46B03;
	Sun, 24 Jul 2011 04:44:02 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Robert N. M. Watson" <rwatson@freebsd.org>
In-Reply-To: <CAFMmRNwBbxR-F7PjkwF8E4GjwFQy_0USKW-3u-ZRNxPMJSOQcA@mail.gmail.com>
Date: Sun, 24 Jul 2011 09:43:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E05FE767-1923-4D47-9759-FA040E403618@freebsd.org>
References: <20110714154457.GI70776@FreeBSD.org>
	<CAFMmRNwBbxR-F7PjkwF8E4GjwFQy_0USKW-3u-ZRNxPMJSOQcA@mail.gmail.com>
To: Ryan Stone <rysto32@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: gnn@freebsd.org, bz@freebsd.org, net@freebsd.org
Subject: Re: m_pkthdr.rcvif dangling pointer problem
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jul 2011 08:44:04 -0000


On 24 Jul 2011, at 04:51, Ryan Stone wrote:

> I ran headlong into this issue today when trying to test some network
> stack changes.  It's depressingly easy to crash HEAD by periodically
> destroying vlan interfaces while you are sending traffic over those
> interfaces -- I get a panic within minutes.
>=20
>> http://people.freebsd.org/~glebius/patches/ifnet.no_free
>=20
> This patch makes my test system survive longer but does not resolve =
the issue.

Unfortunately, I'm a bit preoccupied currently, so haven't had a chance =
to follow up as yet, but just to follow up on the general issue here: =
this problem existed pre-SMP as well, and could be easily triggered by =
DUMMYNET and removable interfaces as well (as additional queuing delays =
just make the problem worse). In general: we need a solution that =
penalises interface removal, not common-case packet processing. As many =
packets have their source ifnet looked up in common-case processing =
(worth checking this assumption) because it's cheap, any solution that =
causes an interface lookup on every input packet (with synchronisation) =
is also an issue.

Instead, I think we should go for a more radical notion, which is a bit =
harder to implement in our stack: the network stack needs a race-free =
way to "drain" all mbufs referring to a particular ifnet, which does not =
cause existing processing to become more expensive. This is easy in some =
subsystems, but more complex in others -- and the composition of =
subsystems makes it all much harder since we need to know that (to be =
100% correct) packets aren't getting passed between subsystems (and =
hence belong to neither) in a way that races with a sweep through the =
subsystems. It may be possible to get this 99.9% right simply by =
providing a series of callbacks into subsystems that cause queues to be =
walked and drained of packets matching the doomed ifnet. It may also be =
quite cheap to have subsystems that "hold" packets outside of explicit =
queues for some period (i.e., in a thread-local pointer out of the =
stack) add explicit invalidation tests  (i.e., for IFF_DYING) before =
handing off to prevent those packets from traversing into other =
subsystems -- which can be done synchronisation-free, but still wouldn't =
100% prevent the race

Just to give an example: netisr should offer a method for =
netisr_drain_ifnet(struct ifnet *) that causes netisr to walk all of its =
queues to find matching packets and free them. Due to direct dispatch =
and thread-local queues during processing, netisr should also check =
IFF_DYING before handing off.

If we do that, I wonder how robust the system then becomes...? This may =
not be too hard to test. But I'd rather we penalise ifnet removal than, =
say, the IP input path when it needs to check a source interface =
property.

Robert=

From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 00:39:48 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 14146106564A;
	Mon, 25 Jul 2011 00:39:48 +0000 (UTC)
	(envelope-from adrian.chadd@gmail.com)
Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com
	[209.85.218.54])
	by mx1.freebsd.org (Postfix) with ESMTP id 9BCBA8FC08;
	Mon, 25 Jul 2011 00:39:47 +0000 (UTC)
Received: by yic13 with SMTP id 13so2370151yic.13
	for <multiple recipients>; Sun, 24 Jul 2011 17:39:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Tm+HXjw7fRemi6X4ThcVgONPNPKdJNzi0ncac8gkC5o=;
	b=UVRHaD20laeUefYYj422C13kAMDzs9Oacs2PzAxvVwd9AXfS+d7Vbc1Aim0x15J2lq
	G5I6UMsMZ6WDWJDjPOn/F17HRASlOdQdJERILk6zChhGt3vLjggrQz2TaTA6nBTmKKgb
	X9rVN+s7uz5TjSTrYeNA/PNIqoFlCG/4mOnWs=
MIME-Version: 1.0
Received: by 10.150.72.23 with SMTP id u23mr1017004yba.443.1311554386644; Sun,
	24 Jul 2011 17:39:46 -0700 (PDT)
Sender: adrian.chadd@gmail.com
Received: by 10.150.197.5 with HTTP; Sun, 24 Jul 2011 17:39:46 -0700 (PDT)
In-Reply-To: <4E2A5407.7080808@gmail.com>
References: <201107140702.p6E721Y4012318@freefall.freebsd.org>
	<4E246C95.40601@gmail.com>
	<CAJ-VmomL1d=0FxqkqyD6gp5NT-KoPC9qxA1Kb7L8WMkyj3fhkw@mail.gmail.com>
	<4E2A5407.7080808@gmail.com>
Date: Mon, 25 Jul 2011 08:39:46 +0800
X-Google-Sender-Auth: LZHzY0UeYRxWOntztUXjuugfHSQ
Message-ID: <CAJ-VmokrEN_vSRDx3BzmWu7C4KgSgfdBQqTaZkp_t2upHE+QbA@mail.gmail.com>
From: Adrian Chadd <adrian@freebsd.org>
To: Matt <sendtomatt@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ae@freebsd.org, freebsd-wireless@freebsd.org, freebsd-net@freebsd.org
Subject: Re: kern/155498: [ral] ral(4) needs to be resynced with OpenBSD's to
 gain RT2860/2870 support.
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 00:39:48 -0000

Keep up the great work :)


Adrian

On 23 July 2011 12:54, Matt <sendtomatt@gmail.com> wrote:
> On 07/22/11 18:42, Adrian Chadd wrote:
>>
>> When do we just give in and commit this merged code for now?
>>
>>
>> Adrian
>>
>> On 19 July 2011 01:25, Matt<sendtomatt@gmail.com> =A0wrote:
>>>
>>> On 07/14/11 00:02, ae@FreeBSD.org wrote:
>>>>
>>>> Synopsis: [ral] ral(4) needs to be resynced with OpenBSD's to gain
>>>> RT2860/2870 support.
>>>>
>>>> Responsible-Changed-From-To: freebsd-net->freebsd-wireless
>>>> Responsible-Changed-By: ae
>>>> Responsible-Changed-When: Thu Jul 14 07:00:44 UTC 2011
>>>> Responsible-Changed-Why:
>>>> Reassign to wireless team.
>>>>
>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D155498
>>>> _______________________________________________
>>>> freebsd-wireless@freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>>>> To unsubscribe, send any mail to
>>>> "freebsd-wireless-unsubscribe@freebsd.org"
>>>>
>>> This is in progress...either from OpenBSD or from Alexandr's rt2860 cod=
e.
>>> Or a merge of the two.
>>>
>>> In the mean time, anyone interested should please test.
>>> It seems like it may not work on anything but current, but I don't have
>>> enough information to be sure.
>>>
>>> Patches (rt2860 merged with ral):
>>>
>>> https://docs.google.com/leaf?id=3D0B6YlMzJxarGbMWFmZDUxMTgtOTU4ZC00MjRl=
LThhMTctZTE1MDcwNDJiZDIx&hl=3Den_US
>>>
>>> If you have build errors, please provide output of uname -a, and copyin=
g
>>> exact error messages if any.
>>>
>>> Thanks,
>>> Matt
>>> _______________________________________________
>>> freebsd-wireless@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>>> To unsubscribe, send any mail to
>>> "freebsd-wireless-unsubscribe@freebsd.org"
>>>
> That may be a good stopgap!
>
> My next step is to go line by line through OpenBSD ral & existing FreeBSD
> ral and try to find a way to either create an abstraction layer for easy
> porting or otherwise structure our driver to successfully "eat" OpenBSD
> changes in the future. This will take significant time on my part, as I a=
m a
> noobophyte :). If anyone knows of useful tools for organizing very large =
C
> sources by function please let me know, it would help!
>
> I will do some major hacking at it tonight I suppose...it's about time :)=
.
> I'll post updates sometime soon, but OpenBSD's 80211 stack seems quite
> different than ours...pci stuff is all different for sure.
>
> Matt
> _______________________________________________
> freebsd-wireless@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.or=
g"
>

From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 02:59:43 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id F3334106564A;
	Mon, 25 Jul 2011 02:59:42 +0000 (UTC)
	(envelope-from linimon@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id C94838FC0C;
	Mon, 25 Jul 2011 02:59:42 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6P2xgAx058697;
	Mon, 25 Jul 2011 02:59:42 GMT
	(envelope-from linimon@freefall.freebsd.org)
Received: (from linimon@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6P2xgsp058693;
	Mon, 25 Jul 2011 02:59:42 GMT (envelope-from linimon)
Date: Mon, 25 Jul 2011 02:59:42 GMT
Message-Id: <201107250259.p6P2xgsp058693@freefall.freebsd.org>
To: sreeramb@netapp.com, linimon@FreeBSD.org, freebsd-i386@FreeBSD.org,
	freebsd-net@FreeBSD.org
From: linimon@FreeBSD.org
Cc: 
Subject: Re: kern/159100: [ioctl] ioctl SIOCGIFCONF reports interface names
	which are blank
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 02:59:43 -0000

Old Synopsis: ioctl SIOCGIFCONF reports interface names which are blank
New Synopsis: [ioctl] ioctl SIOCGIFCONF reports interface names which are blank

State-Changed-From-To: open->closed
State-Changed-By: linimon
State-Changed-When: Mon Jul 25 02:58:18 UTC 2011
State-Changed-Why: 
Duplicate of kern/159099.


Responsible-Changed-From-To: freebsd-i386->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Jul 25 02:58:18 UTC 2011
Responsible-Changed-Why: 

http://www.freebsd.org/cgi/query-pr.cgi?pr=159100

From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 04:26:15 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 950C0106566C;
	Mon, 25 Jul 2011 04:26:15 +0000 (UTC) (envelope-from ae@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 6D4A48FC0C;
	Mon, 25 Jul 2011 04:26:15 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6P4QFQJ041323;
	Mon, 25 Jul 2011 04:26:15 GMT (envelope-from ae@freefall.freebsd.org)
Received: (from ae@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6P4QEjH041319;
	Mon, 25 Jul 2011 04:26:14 GMT (envelope-from ae)
Date: Mon, 25 Jul 2011 04:26:14 GMT
Message-Id: <201107250426.p6P4QEjH041319@freefall.freebsd.org>
To: dima_bsd@inbox.lv, ae@FreeBSD.org, freebsd-net@FreeBSD.org
From: ae@FreeBSD.org
Cc: 
Subject: Re: kern/143939: [ipfw] [em] ipfw nat and em interface rxcsum
	problem
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 04:26:15 -0000

Synopsis: [ipfw] [em] ipfw nat and em interface rxcsum problem

State-Changed-From-To: feedback->closed
State-Changed-By: ae
State-Changed-When: Mon Jul 25 04:25:21 UTC 2011
State-Changed-Why: 
The submitter has reported that the problem is already fixed. Thanks!

http://www.freebsd.org/cgi/query-pr.cgi?pr=143939

From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 07:50:11 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A05FA106566C
	for <freebsd-net@hub.freebsd.org>; Mon, 25 Jul 2011 07:50:11 +0000 (UTC)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 908878FC0C
	for <freebsd-net@hub.freebsd.org>; Mon, 25 Jul 2011 07:50:11 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6P7oBPH055739
	for <freebsd-net@freefall.freebsd.org>; Mon, 25 Jul 2011 07:50:11 GMT
	(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6P7oB34055738;
	Mon, 25 Jul 2011 07:50:11 GMT (envelope-from gnats)
Date: Mon, 25 Jul 2011 07:50:11 GMT
Message-Id: <201107250750.p6P7oB34055738@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: "lanxw" <lanxw@arraynetworks.com.cn>
Cc: 
Subject: Re: kern/158930: [bpf] BPF element leak in ifp-
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: lanxw <lanxw@arraynetworks.com.cn>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 07:50:11 -0000

The following reply was made to PR kern/158930; it has been noted by GNATS.

From: "lanxw" <lanxw@arraynetworks.com.cn>
To: "bug-followup" <bug-followup@FreeBSD.org>,
 "lanxw" <lanxw@arraynetworks.com.cn>
Cc:  
Subject: Re: kern/158930: [bpf] BPF element leak in ifp-
Date: Mon, 25 Jul 2011 15:27:51 +0800

 This is a multi-part message in MIME format.
 
 --=====003_Dragon261518268670_=====
 Content-Type: text/plain;
 	charset="us-ascii"
 Content-Transfer-Encoding: 7bit
 
 i think in sending packet case, the BFD device should not be inserted into ifp->bpf_if->bif_dlist list.
 anybody know this?
 thanks a lot!
 
 2011-07-25 
 
 
 
 lanxw 
 
 --=====003_Dragon261518268670_=====
 Content-Type: text/html;
 	charset="us-ascii"
 Content-Transfer-Encoding: 7bit
 
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <HTML><HEAD>
 <META content="text/html; charset=us-ascii" http-equiv=Content-Type>
 <META name=GENERATOR content="MSHTML 8.00.6001.19088"><LINK rel=stylesheet 
 href="BLOCKQUOTE{margin-Top: 0px; margin-Bottom: 0px; margin-Left: 2em}"></HEAD>
 <BODY style="MARGIN: 10px; FONT-FAMILY: verdana; FONT-SIZE: 10pt">
 <DIV><FONT size=2 face=Verdana>i think in sending packet case, the BFD device 
 should not be inserted into ifp-&gt;bpf_if-&gt;bif_dlist list.</FONT></DIV>
 <DIV>anybody know this?</DIV>
 <DIV>thanks a lot!</DIV>
 <DIV><FONT size=2 face=Verdana></FONT>&nbsp;</DIV>
 <DIV align=left><FONT color=#c0c0c0 size=2 face=Verdana>2011-07-25 
 </FONT></DIV><FONT size=2 face=Verdana>
 <HR style="WIDTH: 122px; HEIGHT: 2px" align=left SIZE=2>
 
 <DIV><FONT color=#c0c0c0 size=2 face=Verdana><SPAN>lanxw</SPAN> 
 </FONT></DIV></FONT></BODY></HTML>
 
 --=====003_Dragon261518268670_=====--
 

From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 08:59:56 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 949E4106564A;
	Mon, 25 Jul 2011 08:59:56 +0000 (UTC)
	(envelope-from glebius@FreeBSD.org)
Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117])
	by mx1.freebsd.org (Postfix) with ESMTP id 1A0E58FC0A;
	Mon, 25 Jul 2011 08:59:55 +0000 (UTC)
Received: from cell.glebius.int.ru (localhost [127.0.0.1])
	by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p6P8xsNJ002167;
	Mon, 25 Jul 2011 12:59:54 +0400 (MSD)
	(envelope-from glebius@FreeBSD.org)
Received: (from glebius@localhost)
	by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p6P8xsw3002166;
	Mon, 25 Jul 2011 12:59:54 +0400 (MSD)
	(envelope-from glebius@FreeBSD.org)
X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to
	glebius@FreeBSD.org using -f
Date: Mon, 25 Jul 2011 12:59:54 +0400
From: Gleb Smirnoff <glebius@FreeBSD.org>
To: "Robert N. M. Watson" <rwatson@FreeBSD.org>
Message-ID: <20110725085954.GR63969@glebius.int.ru>
References: <20110714154457.GI70776@FreeBSD.org>
	<CAFMmRNwBbxR-F7PjkwF8E4GjwFQy_0USKW-3u-ZRNxPMJSOQcA@mail.gmail.com>
	<E05FE767-1923-4D47-9759-FA040E403618@freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <E05FE767-1923-4D47-9759-FA040E403618@freebsd.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: gnn@FreeBSD.org, bz@FreeBSD.org, Ryan Stone <rysto32@gmail.com>,
	net@FreeBSD.org
Subject: Re: m_pkthdr.rcvif dangling pointer problem
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 08:59:56 -0000

On Sun, Jul 24, 2011 at 09:43:59AM +0100, Robert N. M. Watson wrote:
R> Instead, I think we should go for a more radical notion, which is a bit =
harder to implement in our stack: the network stack needs a race-free way t=
o "drain" all mbufs referring to a particular ifnet, which does not cause e=
xisting processing to become more expensive. This is easy in some subsystem=
s, but more complex in others -- and the composition of subsystems makes it=
 all much harder since we need to know that (to be 100% correct) packets ar=
en't getting passed between subsystems (and hence belong to neither) in a w=
ay that races with a sweep through the subsystems. It may be possible to ge=
t this 99.9% right simply by providing a series of callbacks into subsystem=
s that cause queues to be walked and drained of packets matching the doomed=
 ifnet. It may also be quite cheap to have subsystems that "hold" packets o=
utside of explicit queues for some period (i.e., in a thread-local pointer =
out of the stack) add explicit invalidation tests  (i.e., for IFF_DYING) be=
fore handing off to prevent those packets from traversing into other subsys=
tems -- which can be done synchronisation-free, but still wouldn't 100% pre=
vent the race
R>=20
R> Just to give an example: netisr should offer a method for netisr_drain_i=
fnet(struct ifnet *) that causes netisr to walk all of its queues to find m=
atching packets and free them. Due to direct dispatch and thread-local queu=
es during processing, netisr should also check IFF_DYING before handing off.
R>=20
R> If we do that, I wonder how robust the system then becomes...? This may =
not be too hard to test. But I'd rather we penalise ifnet removal than, say=
, the IP input path when it needs to check a source interface property.

What if some thread (e.g. netisr) have taken an mbuf off the queue, stored =
pointer
to it on stack, and got rescheduled. Then an ifnet has departured, all call=
backs
were called, all queues cleaned up from pointers. Then a thread with that m=
buf on=20
stack continues to process. ?

--=20
Totus tuus, Glebius.

From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 09:38:36 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 0A8F2106566C
	for <freebsd-net@freebsd.org>; Mon, 25 Jul 2011 09:38:36 +0000 (UTC)
	(envelope-from ivsan@ngs.ru)
Received: from smtpout.ngs.ru (smtpout3.ngs.ru [195.93.186.209])
	by mx1.freebsd.org (Postfix) with ESMTP id A40598FC12
	for <freebsd-net@freebsd.org>; Mon, 25 Jul 2011 09:38:35 +0000 (UTC)
Received: from mx14.intranet.ru (unknown [172.16.7.2])
	by mail.ngs.ru (smtp) with ESMTP id 9613B44631C57;
	Mon, 25 Jul 2011 16:38:32 +0700 (NOVST)
Received: from mx16.intranet.ru (unknown [172.16.7.4])
	by mx14.intranet.ru (mx14.intranet.ru) with ESMTP id 90C88FB56;
	Mon, 25 Jul 2011 16:38:32 +0700 (NOVST)
Received: from [80.242.66.33] (account ivsan@ngs.ru)
	by mx16.intranet.ru (CommuniGate Pro WebUser 4.3.11)
	with HTTP id 8364904; Mon, 25 Jul 2011 13:38:32 +0400
From: "Ivan Alexandrovich" <ivsan@ngs.ru>
To: Ryan Stone <rysto32@gmail.com>
Date: Mon, 25 Jul 2011 16:38:32 +0700
Message-ID: <web-8364904@mx16.intranet.ru>
In-Reply-To: <CAFMmRNxNYyWUYZ299GeK6oksay_5nL9XxVvM39LTQEakRPXE9g@mail.gmail.com>
References: <web-8285764@mx16.intranet.ru>
	<CAFMmRNxNYyWUYZ299GeK6oksay_5nL9XxVvM39LTQEakRPXE9g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: freebsd-net@freebsd.org
Subject: Re: Ethernet link status on i82576
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 09:38:36 -0000

On Fri, 22 Jul 2011 11:08:18 -0400 Ryan Stone <rysto32@gmail.com> wrote:
> I notice that the interface not up in your test.  If you ifconfig it
> up does it detect that it has lost link?  

Thank you. When the interface is "up" driver works as expected.

Thanks,
Ivan

From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 11:00:21 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id CCCE61065670;
	Mon, 25 Jul 2011 11:00:21 +0000 (UTC) (envelope-from Daan@vitsch.nl)
Received: from VM01.VEHosting.nl (VM016.VEHosting.nl
	[IPv6:2001:1af8:2100:b020::140])
	by mx1.freebsd.org (Postfix) with ESMTP id 691918FC08;
	Mon, 25 Jul 2011 11:00:21 +0000 (UTC)
Received: from [192.168.72.11] (124-54.bbned.dsl.internl.net [92.254.54.124])
	(authenticated bits=0)
	by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id p6PB0L7g051204;
	Mon, 25 Jul 2011 13:00:21 +0200 (CEST) (envelope-from Daan@vitsch.nl)
From: Daan Vreeken <Daan@vitsch.nl>
Organization: Vitsch Electronics
To: freebsd-net@freebsd.org
Date: Mon, 25 Jul 2011 13:00:20 +0200
User-Agent: KMail/1.9.10
References: <20110714154457.GI70776@FreeBSD.org>
	<CAFMmRNwBbxR-F7PjkwF8E4GjwFQy_0USKW-3u-ZRNxPMJSOQcA@mail.gmail.com>
	<E05FE767-1923-4D47-9759-FA040E403618@freebsd.org>
In-Reply-To: <E05FE767-1923-4D47-9759-FA040E403618@freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201107251300.20832.Daan@vitsch.nl>
x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008,
	2011 - Daan Vreeken - VEHosting
x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl
Cc: Ryan Stone <rysto32@gmail.com>, bz@freebsd.org,
	"Robert N. M. Watson" <rwatson@freebsd.org>, gnn@freebsd.org
Subject: Re: m_pkthdr.rcvif dangling pointer problem
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 11:00:22 -0000

Hi Robert,

On Sunday 24 July 2011 10:43:59 Robert N. M. Watson wrote:
> On 24 Jul 2011, at 04:51, Ryan Stone wrote:
> > I ran headlong into this issue today when trying to test some network
> > stack changes.  It's depressingly easy to crash HEAD by periodically
> > destroying vlan interfaces while you are sending traffic over those
> > interfaces -- I get a panic within minutes.
> >
> >> http://people.freebsd.org/~glebius/patches/ifnet.no_free
> >
> > This patch makes my test system survive longer but does not resolve the
> > issue.
>
> Unfortunately, I'm a bit preoccupied currently, so haven't had a chance to
> follow up as yet, but just to follow up on the general issue here: this
> problem existed pre-SMP as well, and could be easily triggered by DUMMYNET
> and removable interfaces as well (as additional queuing delays just make
> the problem worse). In general: we need a solution that penalises interface
> removal, not common-case packet processing. As many packets have their
> source ifnet looked up in common-case processing (worth checking this
> assumption) because it's cheap, any solution that causes an interface
> lookup on every input packet (with synchronisation) is also an issue.
>
> Instead, I think we should go for a more radical notion, which is a bit
> harder to implement in our stack: the network stack needs a race-free way
> to "drain" all mbufs referring to a particular ifnet, which does not cause
> existing processing to become more expensive. This is easy in some
> subsystems, but more complex in others -- and the composition of subsystems
> makes it all much harder since we need to know that (to be 100% correct)
> packets aren't getting passed between subsystems (and hence belong to
> neither) in a way that races with a sweep through the subsystems. It may be
> possible to get this 99.9% right simply by providing a series of callbacks
> into subsystems that cause queues to be walked and drained of packets
> matching the doomed ifnet. It may also be quite cheap to have subsystems
> that "hold" packets outside of explicit queues for some period (i.e., in a
> thread-local pointer out of the stack) add explicit invalidation tests 
> (i.e., for IFF_DYING) before handing off to prevent those packets from
> traversing into other subsystems -- which can be done synchronisation-free,
> but still wouldn't 100% prevent the race
>
> Just to give an example: netisr should offer a method for
> netisr_drain_ifnet(struct ifnet *) that causes netisr to walk all of its
> queues to find matching packets and free them. Due to direct dispatch and
> thread-local queues during processing, netisr should also check IFF_DYING
> before handing off.
>
> If we do that, I wonder how robust the system then becomes...? This may not
> be too hard to test. But I'd rather we penalise ifnet removal than, say,
> the IP input path when it needs to check a source interface property.

Couldn't the dangling pointer problem be solved by adding a 'generation' field 
to the mbuf structure?
The 'generation' could be a system-wide number that gets incremented whenever 
an interface is removed. The mbuf* functions could keep a (per CPU?) 
reference count on the number of mbufs allocated/freed during 
that 'generation'. After interface removal, the ifnet structure could be 
freed when all the reference counters of generations before the current 
generation reach zero (whenever that happens).


--
Daan Vreeken
Vitsch Electronics
http://Vitsch.nl
tel: +31-(0)40-7113051 / +31-(0)6-46210825
KvK nr: 17174380

From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 11:07:12 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 41F611065678
	for <freebsd-net@FreeBSD.org>; Mon, 25 Jul 2011 11:07:12 +0000 (UTC)
	(envelope-from owner-bugmaster@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 300048FC2B
	for <freebsd-net@FreeBSD.org>; Mon, 25 Jul 2011 11:07:12 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6PB7CbM046445
	for <freebsd-net@FreeBSD.org>; Mon, 25 Jul 2011 11:07:12 GMT
	(envelope-from owner-bugmaster@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6PB7BV0046443
	for freebsd-net@FreeBSD.org; Mon, 25 Jul 2011 11:07:11 GMT
	(envelope-from owner-bugmaster@FreeBSD.org)
Date: Mon, 25 Jul 2011 11:07:11 GMT
Message-Id: <201107251107.p6PB7BV0046443@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: gnats set sender to
	owner-bugmaster@FreeBSD.org using -f
From: FreeBSD bugmaster <bugmaster@FreeBSD.org>
To: freebsd-net@FreeBSD.org
Cc: 
Subject: Current problem reports assigned to freebsd-net@FreeBSD.org
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 11:07:12 -0000

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/158930  net        [bpf] BPF element leak in ifp->bpf_if->bif_dlist
o kern/158726  net        [ip6] [patch] ICMPv6 Router Announcement flooding limi
o kern/158694  net        [ix] [lagg] ix0 is not working within lagg(4)
o kern/158665  net        [ip6] [panic] kernel pagefault in in6_setscope()
o kern/158635  net        [em] TSO breaks BPF packet captures with em driver
f kern/158426  net        [e1000] [panic] _mtx_lock_sleep: recursed on non-recur
o kern/158156  net        [bce] bce driver shows "no carrier" on IBM blade (HS22
f kern/157802  net        [dummynet] [panic] kernel panic in dummynet
o kern/157785  net        amd64 + jail + ipfw + natd = very slow outbound traffi
o kern/157429  net        [re] Realtek RTL8169 doesn't work with re(4)
o kern/157418  net        [em] em driver lockup during boot on Supermicro X9SCM-
o kern/157410  net        [ip6] IPv6 Router Advertisements Cause Excessive CPU U
o kern/157287  net        [re] [panic] INVARIANTS panic (Memory modified after f
o kern/157209  net        [ip6] [patch] locking error in rip6_input() (sys/netin
o kern/157200  net        [network.subr] [patch] stf(4) can not communicate betw
o kern/157182  net        [lagg] lagg interface not working together with epair 
o kern/156978  net        [lagg][patch] Take lagg rlock before checking flags
o kern/156877  net        [dummynet] [panic] dummynet move_pkt() null ptr derefe
o kern/156667  net        [em] em0 fails to init on CURRENT after March 17
o kern/156408  net        [vlan] Routing failure when using VLANs vs. Physical e
o kern/156328  net        [icmp]: host can ping other subnet but no have IP from
o kern/156317  net        [ip6] Wrong order of IPv6 NS DAD/MLD Report
o kern/156283  net        [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re
o kern/156279  net        [if_bridge][divert][ipfw] unable to correctly re-injec
o kern/156226  net        [lagg]: failover does not announce the failover to swi
o kern/156030  net        [ip6] [panic] Crash in nd6_dad_start() due to null ptr
o kern/155772  net        ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc
o kern/155680  net        [multicast] problems with multicast
s kern/155642  net        [request] Add driver for Realtek RTL8191SE/RTL8192SE W
o kern/155604  net        [flowtable] Flowtable excessively caches dest MAC addr
o kern/155597  net        [panic] Kernel panics with "sbdrop" message
o kern/155585  net        [tcp] [panic] tcp_output tcp_mtudisc loop until kernel
o kern/155420  net        [vlan] adding vlan break existent vlan
o bin/155365   net        [patch] routed(8): if.c in routed fails to compile if 
o kern/155177  net        [route] [panic] Panic when inject routes in kernel
o kern/155030  net        [igb] igb(4) DEVICE_POLLING does not work with carp(4)
o kern/155010  net        [msk] ntfs-3g via iscsi using msk driver cause kernel 
o kern/155004  net        [bce] [panic] kernel panic in bce0 driver
o kern/154943  net        [gif] ifconfig gifX create on existing gifX clears IP
s kern/154851  net        [request]: Port brcm80211 driver from Linux to FreeBSD
o kern/154850  net        [netgraph] [patch] ng_ether fails to name nodes when t
o kern/154679  net        [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R
o kern/154600  net        [tcp] [panic] Random kernel panics on tcp_output
o kern/154557  net        [tcp] Freeze tcp-session of the clients, if in the gat
o kern/154443  net        [if_bridge] Kernel module bridgestp.ko missing after u
o kern/154286  net        [netgraph] [panic] 8.2-PRERELEASE panic in netgraph
o kern/154255  net        [nfs] NFS not responding
o kern/154214  net        [stf] [panic] Panic when creating stf interface
o kern/154185  net        race condition in mb_dupcl
o kern/154169  net        [multicast] [ip6] Node Information Query multicast add
o kern/154134  net        [ip6] stuck kernel state in LISTEN on ipv6 daemon whic
o kern/154091  net        [netgraph] [panic] netgraph, unaligned mbuf?
o conf/154062  net        [vlan] [patch] change to way of auto-generatation of v
o kern/153937  net        [ral] ralink panics the system (amd64 freeBSDD 8.X) wh
o kern/153936  net        [ixgbe] [patch] MPRC workaround incorrectly applied to
o kern/153816  net        [ixgbe] ixgbe doesn't work properly with the Intel 10g
o kern/153772  net        [ixgbe] [patch] sysctls reference wrong XON/XOFF varia
o kern/153497  net        [netgraph] netgraph panic due to race conditions
o kern/153454  net        [patch] [wlan] [urtw] Support ad-hoc and hostap modes 
o kern/153308  net        [em] em interface use 100% cpu
o kern/153244  net        [em] em(4) fails to send UDP to port 0xffff
o kern/152893  net        [netgraph] [panic] 8.2-PRERELEASE panic in netgraph
o kern/152853  net        [em] tftpd (and likely other udp traffic) fails over e
o kern/152828  net        [em] poor performance on 8.1, 8.2-PRE
o kern/152569  net        [net]: Multiple ppp connections and routing table prob
o kern/152235  net        [arp] Permanent local ARP entries are not properly upd
o kern/152141  net        [vlan] [patch] encapsulate vlan in ng_ether before out
o kern/152036  net        [libc] getifaddrs(3) returns truncated sockaddrs for n
o kern/151690  net        [ep] network connectivity won't work until dhclient is
o kern/151681  net        [nfs] NFS mount via IPv6 leads to hang on client with 
o kern/151593  net        [igb] [panic] Kernel panic when bringing up igb networ
o kern/150920  net        [ixgbe][igb] Panic when packets are dropped with heade
o bin/150642   net        netstat(1) doesn't print anything for SCTP sockets
o kern/150557  net        [igb] igb0: Watchdog timeout -- resetting
o kern/150251  net        [patch] [ixgbe] Late cable insertion broken
o kern/150249  net        [ixgbe] Media type detection broken
o bin/150224   net        ppp(8) does not reassign static IP after kill -KILL co
f kern/149969  net        [wlan] [ral] ralink rt2661 fails to maintain connectio
o kern/149937  net        [ipfilter] [patch] kernel panic in ipfilter IP fragmen
o kern/149643  net        [rum] device not sending proper beacon frames in ap mo
o kern/149609  net        [panic] reboot after adding second default route
o kern/149117  net        [inet] [patch] in_pcbbind: redundant test
o kern/149086  net        [multicast] Generic multicast join failure in 8.1
o kern/148018  net        [flowtable] flowtable crashes on ia64
o kern/147912  net        [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300  11
o kern/147894  net        [ipsec] IPv6-in-IPv4 does not work inside an ESP-only 
o kern/147155  net        [ip6] setfb not work with ipv6
o kern/146845  net        [libc] close(2) returns error 54 (connection reset by 
f kern/146792  net        [flowtable] flowcleaner 100% cpu's core load
o kern/146719  net        [pf] [panic] PF or dumynet kernel panic
o kern/146534  net        [icmp6] wrong source address in echo reply
o kern/146427  net        [mwl] Additional virtual access points don't work on m
o kern/146426  net        [mwl] 802.11n rates not possible on mwl
o kern/146425  net        [mwl] mwl dropping all packets during and after high u
f kern/146394  net        [vlan] IP source address for outgoing connections
o bin/146377   net        [ppp] [tun] Interface doesn't clear addresses when PPP
o kern/146358  net        [vlan] wrong destination MAC address
o kern/146165  net        [wlan] [panic] Setting bssid in adhoc mode causes pani
o kern/146082  net        [ng_l2tp] a false invaliant check was performed in ng_
o kern/146037  net        [panic] mpd + CoA = kernel panic
o bin/145934   net        [patch] add count option to netstat(1)
o kern/145825  net        [panic] panic: soabort: so_count
o kern/145728  net        [lagg] Stops working lagg between two servers.
f kern/144917  net        [flowtable] [panic] flowtable crashes system [regressi
o kern/144882  net        MacBookPro =>4.1 does not connect to BSD in hostap wit
o kern/144874  net        [if_bridge] [patch] if_bridge frees mbuf after pfil ho
o conf/144700  net        [rc.d] async dhclient breaks stuff for too many people
o kern/144616  net        [nat] [panic] ip_nat panic FreeBSD 7.2
o kern/144572  net        [carp] CARP preemption mode traffic partially goes to 
f kern/144315  net        [ipfw] [panic] freebsd 8-stable reboot after add ipfw 
o kern/144231  net        bind/connect/sendto too strict about sockaddr length
o kern/143846  net        [gif] bringing gif3 tunnel down causes gif0 tunnel to 
s kern/143673  net        [stf] [request] there should be a way to support multi
s kern/143666  net        [ip6] [request] PMTU black hole detection not implemen
o kern/143622  net        [pfil] [patch] unlock pfil lock while calling firewall
o kern/143593  net        [ipsec] When using IPSec, tcpdump doesn't show outgoin
o kern/143591  net        [ral] RT2561C-based DLink card (DWL-510) fails to work
o kern/143208  net        [ipsec] [gif] IPSec over gif interface not working
o kern/143034  net        [panic] system reboots itself in tcp code [regression]
o kern/142877  net        [hang] network-related repeatable 8.0-STABLE hard hang
o kern/142774  net        Problem with outgoing connections on interface with mu
o kern/142772  net        [libc] lla_lookup: new lle malloc failed
o kern/142018  net        [iwi] [patch] Possibly wrong interpretation of beacon-
o kern/141861  net        [wi] data garbled with WEP and wi(4) with Prism 2.5
f kern/141741  net        Etherlink III NIC won't work after upgrade to FBSD 8, 
o kern/141023  net        [carp] CARP arp replays with wrong src mac
o kern/140742  net        rum(4) Two asus-WL167G adapters cannot talk to each ot
o kern/140682  net        [netgraph] [panic] random panic in netgraph
o kern/140634  net        [vlan] destroying if_lagg interface with if_vlan membe
o kern/140619  net        [ifnet] [patch] refine obsolete if_var.h comments desc
o kern/140346  net        [wlan] High bandwidth use causes loss of wlan connecti
o kern/140142  net        [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6
o kern/140066  net        [bwi] install report for 8.0 RC 2 (multiple problems)
o kern/139565  net        [ipfilter] ipfilter ioctl SIOCDELST broken
o kern/139387  net        [ipsec] Wrong lenth of PF_KEY messages in promiscuous 
o bin/139346   net        [patch] arp(8) add option to remove static entries lis
o kern/139268  net        [if_bridge] [patch] allow if_bridge to forward just VL
p kern/139204  net        [arp] DHCP server replies rejected, ARP entry lost bef
o kern/139117  net        [lagg] + wlan boot timing (EBUSY)
o kern/139058  net        [ipfilter] mbuf cluster leak on FreeBSD 7.2
o kern/138850  net        [dummynet] dummynet doesn't work correctly on a bridge
o kern/138782  net        [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00
o kern/138688  net        [rum] possibly broken on 8 Beta 4 amd64: able to wpa a
o kern/138678  net        [lo] FreeBSD does not assign linklocal address to loop
o kern/138620  net        [lagg] [patch] lagg port bpf-writes blocked
o kern/138407  net        [gre] gre(4) interface does not come up after reboot
o kern/138332  net        [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/
o kern/138266  net        [panic] kernel panic when udp benchmark test used as r
o kern/138177  net        [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257
f kern/138029  net        [bpf] [panic] periodically kernel panic and reboot
o kern/137881  net        [netgraph] [panic] ng_pppoe fatal trap 12
p bin/137841   net        [patch] wpa_supplicant(8) cannot verify SHA256 signed 
p kern/137776  net        [rum] panic in rum(4) driver on 8.0-BETA2
o bin/137641   net        ifconfig(8): various problems with "vlan_device.vlan_i
o kern/137392  net        [ip] [panic] crash in ip_nat.c line 2577
o kern/137372  net        [ral] FreeBSD doesn't support wireless interface from 
o kern/137089  net        [lagg] lagg falsely triggers IPv6 duplicate address de
o bin/136994   net        [patch] ifconfig(8) print carp mac address
o kern/136911  net        [netgraph] [panic] system panic on kldload ng_bpf.ko t
o bin/136661   net        [patch] ndp(8) ignores -f option
o kern/136618  net        [pf][stf] panic on cloning interface without unit numb
o kern/136426  net        [panic] spawning several dhclients in parallel panics 
o kern/135502  net        [periodic] Warning message raised by rtfree function i
o kern/134583  net        [hang] Machine with jail freezes after random amount o
o kern/134531  net        [route] [panic] kernel crash related to routes/zebra
o kern/134157  net        [dummynet] dummynet loads cpu for 100% and make a syst
o kern/133969  net        [dummynet] [panic] Fatal trap 12: page fault while in 
o kern/133968  net        [dummynet] [panic] dummynet kernel panic
o kern/133736  net        [udp] ip_id not protected ...
o kern/133595  net        [panic] Kernel Panic at pcpu.h:195
o kern/133572  net        [ppp] [hang] incoming PPTP connection hangs the system
o kern/133490  net        [bpf] [panic] 'kmem_map too small' panic on Dell r900 
o kern/133235  net        [netinet] [patch] Process SIOCDLIFADDR command incorre
o kern/133218  net        [carp] [hang] use of carp(4) causes system to freeze
f kern/133213  net        arp and sshd errors on 7.1-PRERELEASE
o kern/133060  net        [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs
o kern/132889  net        [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d
o conf/132851  net        [patch] rc.conf(5): allow to setfib(1) for service run
o kern/132734  net        [ifmib] [panic] panic in net/if_mib.c
o kern/132705  net        [libwrap] [patch] libwrap - infinite loop if hosts.all
o kern/132672  net        [ndis] [panic] ndis with rt2860.sys causes kernel pani
o kern/132554  net        [ipl] There is no ippool start script/ipfilter magic t
o kern/132354  net        [nat] Getting some packages to ipnat(8) causes crash
o kern/132285  net        [carp] alias gives incorrect hash in dmesg
o kern/132277  net        [crypto] [ipsec] poor performance using cryptodevice f
o kern/132107  net        [carp] carp(4) advskew setting ignored when carp IP us
o kern/131781  net        [ndis] ndis keeps dropping the link
o kern/131776  net        [wi] driver fails to init
o kern/131753  net        [altq] [panic] kernel panic in hfsc_dequeue
o kern/131601  net        [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp
o bin/131567   net        [socket] [patch] Update for regression/sockets/unix_cm
o bin/131365   net        route(8): route add changes interpretation of network 
f kern/130820  net        [ndis] wpa_supplicant(8) returns 'no space on device'
o kern/130628  net        [nfs] NFS / rpc.lockd deadlock on 7.1-R
o conf/130555  net        [rc.d] [patch] No good way to set ipfilter variables a
o kern/130525  net        [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau
o kern/130311  net        [wlan_xauth] [panic] hostapd restart causing kernel pa
o kern/130109  net        [ipfw] Can not set fib for packets originated from loc
f kern/130059  net        [panic] Leaking 50k mbufs/hour
f kern/129719  net        [nfs] [panic] Panic during shutdown, tcp_ctloutput: in
o kern/129517  net        [ipsec] [panic] double fault / stack overflow
o kern/129508  net        [carp] [panic] Kernel panic with EtherIP (may be relat
o kern/129219  net        [ppp] Kernel panic when using kernel mode ppp
o kern/129197  net        [panic] 7.0 IP stack related panic
o bin/128954   net        ifconfig(8) deletes valid routes
o bin/128602   net        [an] wpa_supplicant(8) crashes with an(4)
o kern/128448  net        [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res
o bin/128295   net        [patch] ifconfig(8) does not print TOE4 or TOE6 capabi
o bin/128001   net        wpa_supplicant(8), wlan(4), and wi(4) issues
o kern/127826  net        [iwi] iwi0 driver has reduced performance and connecti
o kern/127815  net        [gif] [patch] if_gif does not set vlan attributes from
o kern/127724  net        [rtalloc] rtfree: 0xc5a8f870 has 1 refs
f bin/127719   net        [arp] arp: Segmentation fault (core dumped)
f kern/127528  net        [icmp]: icmp socket receives icmp replies not owned by
p kern/127360  net        [socket] TOE socket options missing from sosetopt()
o bin/127192   net        routed(8) removes the secondary alias IP of interface 
f kern/127145  net        [wi]: prism (wi) driver crash at bigger traffic
o kern/127050  net        [carp] ipv6 does not work on carp interfaces [regressi
o kern/126945  net        [carp] CARP interface destruction with ifconfig destro
o kern/126895  net        [patch] [ral] Add antenna selection (marked as TBD)
o kern/126874  net        [vlan]: Zebra problem if ifconfig vlanX destroy
o kern/126714  net        [carp] CARP interface renaming makes system no longer 
o kern/126695  net        rtfree messages and network disruption upon use of if_
o kern/126339  net        [ipw] ipw driver drops the connection
o kern/126075  net        [inet] [patch] internet control accesses beyond end of
o bin/125922   net        [patch] Deadlock in arp(8)
o kern/125920  net        [arp] Kernel Routing Table loses Ethernet Link status 
o kern/125845  net        [netinet] [patch] tcp_lro_rx() should make use of hard
o kern/125816  net        [carp] [if_bridge] carp stuck in init when using bridg
f kern/125442  net        [carp] [lagg] CARP combined with LAGG causes system pa
o kern/125258  net        [socket] socket's SO_REUSEADDR option does not work
o kern/125239  net        [gre] kernel crash when using gre
o kern/124341  net        [ral] promiscuous mode for wireless device ral0 looses
o kern/124225  net        [ndis] [patch] ndis network driver sometimes loses net
o kern/124160  net        [libc] connect(2) function loops indefinitely
o kern/124021  net        [ip6] [panic] page fault in nd6_output()
o kern/123968  net        [rum] [panic] rum driver causes kernel panic with WPA.
o kern/123892  net        [tap] [patch] No buffer space available
o kern/123890  net        [ppp] [panic] crash & reboot on work with PPP low-spee
o kern/123858  net        [stf] [patch] stf not usable behind a NAT
o kern/123796  net        [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not
o kern/123758  net        [panic] panic while restarting net/freenet6
o bin/123633   net        ifconfig(8) doesn't set inet and ether address in one 
o kern/123559  net        [iwi] iwi periodically disassociates/associates [regre
o bin/123465   net        [ip6] route(8): route add -inet6 <ipv6_addr> -interfac
o kern/123463  net        [ipsec] [panic] repeatable crash related to ipsec-tool
o conf/123330  net        [nsswitch.conf] Enabling samba wins in nsswitch.conf c
o kern/123160  net        [ip] Panic and reboot at sysctl kern.polling.enable=0
f kern/123045  net        [ng_mppc] ng_mppc_decompress - disabling node
o kern/122989  net        [swi] [panic] 6.3 kernel panic in swi1: net
o kern/122954  net        [lagg] IPv6 EUI64 incorrectly chosen for lagg devices
f kern/122780  net        [lagg] tcpdump on lagg interface during high pps wedge
o kern/122685  net        It is not visible passing packets in tcpdump(1)
o kern/122319  net        [wi] imposible to enable ad-hoc demo mode with Orinoco
o kern/122290  net        [netgraph] [panic] Netgraph related "kmem_map too smal
o kern/122033  net        [ral] [lor] Lock order reversal in ral0 at bootup ieee
o bin/121895   net        [patch] rtsol(8)/rtsold(8) doesn't handle managed netw
s kern/121774  net        [swi] [panic] 6.3 kernel panic in swi1: net
o kern/121555  net        [panic] Fatal trap 12: current process = 12 (swi1: net
o kern/121443  net        [gif] [lor] icmp6_input/nd6_lookup
o kern/121437  net        [vlan] Routing to layer-2 address does not work on VLA
o bin/121359   net        [patch] [security] ppp(8): fix local stack overflow in
o kern/121257  net        [tcp] TSO + natd  -> slow outgoing tcp traffic
o kern/121181  net        [panic] Fatal trap 3: breakpoint instruction fault whi
o kern/120966  net        [rum] kernel panic with if_rum and WPA encryption
o kern/120566  net        [request]: ifconfig(8) make order of arguments more fr
o kern/120304  net        [netgraph] [patch] netgraph source assumes 32-bit time
o kern/120266  net        [udp] [panic] gnugk causes kernel panic when closing U
o kern/120130  net        [carp] [panic] carp causes kernel panics in any conste
o bin/120060   net        routed(8) deletes link-level routes in the presence of
o kern/119945  net        [rum] [panic] rum device in hostap mode, cause kernel 
o kern/119791  net        [nfs] UDP NFS mount of aliased IP addresses from a Sol
o kern/119617  net        [nfs] nfs error on wpa network when reseting/shutdown
f kern/119516  net        [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi
o kern/119432  net        [arp] route add -host <host> -iface <nic> causes arp e
o kern/119225  net        [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr
o kern/118727  net        [netgraph] [patch] [request] add new ng_pf module
o kern/117448  net        [carp] 6.2 kernel crash [regression]
o kern/117423  net        [vlan] Duplicate IP on different interfaces
o bin/117339   net        [patch] route(8): loading routing management commands 
o kern/117271  net        [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap
o bin/116643   net        [patch] [request] fstat(1): add INET/INET6 socket deta
o kern/116185  net        [iwi] if_iwi driver leads system to reboot
o kern/115239  net        [ipnat] panic with 'kmem_map too small' using ipnat
o kern/115019  net        [netgraph] ng_ether upper hook packet flow stops on ad
o kern/115002  net        [wi] if_wi timeout. failed allocation (busy bit). ifco
o kern/114915  net        [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f
o kern/113432  net        [ucom] WARNING: attempt to net_add_domain(netgraph) af
o kern/112722  net        [ipsec] [udp] IP v4 udp fragmented packet reject
o kern/112686  net        [patm] patm driver freezes System (FreeBSD 6.2-p4) i38
o bin/112557   net        [patch] ppp(8) lock file should not use symlink name
o kern/112528  net        [nfs] NFS over TCP under load hangs with "impossible p
o kern/111537  net        [inet6] [patch] ip6_input() treats mbuf cluster wrong
o kern/111457  net        [ral] ral(4) freeze
o kern/110284  net        [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et
o kern/110249  net        [kernel] [regression] [patch] setsockopt() error regre
o kern/109470  net        [wi] Orinoco Classic Gold PC Card Can't Channel Hop
o kern/109308  net        [pppd] [panic] Multiple panics kernel ppp suspected [r
o bin/108895   net        pppd(8): PPPoE dead connections on 6.2 [regression]
o kern/107944  net        [wi] [patch] Forget to unlock mutex-locks
o conf/107035  net        [patch] bridge(8): bridge interface given in rc.conf n
o kern/106444  net        [netgraph] [panic] Kernel Panic on Binding to an ip to
o kern/106438  net        [ipf] ipfilter: keep state does not seem to allow repl
o kern/106316  net        [dummynet] dummynet with multipass ipfw drops packets 
o kern/105945  net        Address can disappear from network interface
s kern/105943  net        Network stack may modify read-only mbuf chain copies
o bin/105925   net        problems with ifconfig(8) and vlan(4) [regression]
o kern/104851  net        [inet6] [patch] On link routes not configured when usi
o kern/104751  net        [netgraph] kernel panic, when getting info about my tr
o kern/103191  net        Unpredictable reboot
o kern/103135  net        [ipsec] ipsec with ipfw divert (not NAT) encodes a pac
o kern/102540  net        [netgraph] [patch] supporting vlan(4) by ng_fec(4)
o conf/102502  net        [netgraph] [patch] ifconfig name does't rename netgrap
o kern/102035  net        [plip] plip networking disables parallel port printing
o kern/101948  net        [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau
o kern/100709  net        [libc] getaddrinfo(3) should return TTL info
o kern/100519  net        [netisr] suggestion to fix suboptimal network polling
o kern/98978   net        [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel
o kern/98597   net        [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu
o bin/98218    net        wpa_supplicant(8) blacklist not working
o kern/97306   net        [netgraph] NG_L2TP locks after connection with failed 
o conf/97014   net        [gif] gifconfig_gif? in rc.conf does not recognize IPv
f kern/96268   net        [socket] TCP socket performance drops by 3000% if pack
o kern/95519   net        [ral] ral0 could not map mbuf
o kern/95288   net        [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr
o kern/95277   net        [netinet] [patch] IP Encapsulation mask_match() return
o kern/95267   net        packet drops periodically appear
f kern/93378   net        [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo
o kern/93019   net        [ppp] ppp and tunX problems: no traffic after restarti
o kern/92880   net        [libc] [patch] almost rewritten inet_network(3) functi
s kern/92279   net        [dc] Core faults everytime I reboot, possible NIC issu
o kern/91859   net        [ndis] if_ndis does not work with Asus WL-138
s kern/91777   net        [ipf] [patch] wrong behaviour with skip rule inside an
o kern/91364   net        [ral] [wep] WF-511 RT2500 Card PCI and WEP
o kern/91311   net        [aue] aue interface hanging
s kern/90086   net        [hang] 5.4p8 on supermicro P8SCT hangs during boot if 
o kern/87521   net        [ipf] [panic] using ipfilter "auth" keyword leads to k
o kern/87421   net        [netgraph] [panic]: ng_ether + ng_eiface + if_bridge
s kern/86920   net        [ndis] ifconfig: SIOCS80211: Invalid argument [regress
o kern/86871   net        [tcp] [patch] allocation logic for PCBs in TIME_WAIT s
o kern/86427   net        [lor] Deadlock with FASTIPSEC and nat
o kern/86103   net        [ipf] Illegal NAT Traversal in IPFilter
o kern/85780   net        'panic: bogus refcnt 0' in routing/ipv6
o bin/85445    net        ifconfig(8): deprecated keyword to ifconfig inoperativ
p kern/85320   net        [gre] [patch] possible depletion of kernel stack in ip
o bin/82975    net        route change does not parse classfull network as given
o kern/82881   net        [netgraph] [panic] ng_fec(4) causes kernel panic after
o kern/82468   net        Using 64MB tcp send/recv buffers, trafficflow stops, i
o bin/82185    net        [patch] ndp(8) can delete the incorrect entry
o kern/81095   net        IPsec connection stops working if associated network i
o kern/79895   net        [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 
o kern/78968   net        FreeBSD freezes on mbufs exhaustion (network interface
o kern/78090   net        [ipf] ipf filtering on bridged packets doesn't work if
o kern/77341   net        [ip6] problems with IPV6 implementation
o kern/77273   net        [ipf] ipfilter breaks ipv6 statefull filtering on 5.3
s kern/77195   net        [ipf] [patch] ipfilter ioctl SIOCGNATL does not match 
o kern/75873   net        Usability problem with non-RFC-compliant IP spoof prot
s kern/75407   net        [an] an(4): no carrier after short time
a kern/71474   net        [route] route lookup does not skip interfaces marked d
o kern/71469   net        default route to internet magically disappears with mu
o kern/70904   net        [ipf] ipfilter ipnat problem with h323 proxy support
o kern/68889   net        [panic] m_copym, length > size of mbuf chain
o kern/66225   net        [netgraph] [patch] extend ng_eiface(4) control message
o kern/65616   net        IPSEC can't detunnel GRE packets after real ESP encryp
s kern/60293   net        [patch] FreeBSD arp poison patch
a kern/56233   net        IPsec tunnel (ESP) over IPv6: MTU computation is wrong
s bin/41647    net        ifconfig(8) doesn't accept lladdr along with inet addr
s kern/39937   net        ipstealth issue
a kern/38554   net        [patch] changing interface ipaddress doesn't seem to w
o kern/34665   net        [ipf] [hang] ipfilter rcmd proxy "hangs".
o kern/31940   net        ip queue length too short for >500kpps
o kern/31647   net        [libc] socket calls can return undocumented EINVAL
o kern/30186   net        [libc] getaddrinfo(3) does not handle incorrect servna
o kern/27474   net        [ipf] [ppp] Interactive use of user PPP and ipfilter c
f kern/24959   net        [patch] proper TCP_NOPUSH/TCP_CORK compatibility
o conf/23063   net        [arp] [patch] for static ARP tables in rc.network
o kern/21998   net        [socket] [patch] ident only for outgoing connections
o kern/5877    net        [socket] sb_cc counts control data as well as data dat

378 problems total.


From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 13:10:34 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 625871065673
	for <freebsd-net@freebsd.org>; Mon, 25 Jul 2011 13:10:34 +0000 (UTC)
	(envelope-from monthadar@gmail.com)
Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54])
	by mx1.freebsd.org (Postfix) with ESMTP id 294DE8FC14
	for <freebsd-net@freebsd.org>; Mon, 25 Jul 2011 13:10:33 +0000 (UTC)
Received: by gwb15 with SMTP id 15so3074969gwb.13
	for <freebsd-net@freebsd.org>; Mon, 25 Jul 2011 06:10:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=dqv18d5ZuBS5c30USzvRH/trLXLSfPeX1aO0w3THSYk=;
	b=rCTWhB77/VNdHCci2ah2ozp6OOTsX3nspMCjvLvjlZOE1HvQzNB6q8Y5u6gOaPGUdM
	1OMwFwGnZdGRqhN1gUQA31gACrBvv4/Rice1F1SH5Oudy3MegonL281bsSflInsjGY5U
	ddlkFCxHAG45tSguMvTa1zL8dWQ7FVZnbuB0I=
MIME-Version: 1.0
Received: by 10.150.40.15 with SMTP id n15mr4381406ybn.305.1311597577790; Mon,
	25 Jul 2011 05:39:37 -0700 (PDT)
Received: by 10.151.101.4 with HTTP; Mon, 25 Jul 2011 05:39:37 -0700 (PDT)
Date: Mon, 25 Jul 2011 14:39:37 +0200
Message-ID: <CA+sBSoLCwQz+3seb8m=Nd-6YNd5MTxCYpJGjLJuzGScPR2vscg@mail.gmail.com>
From: Monthadar Al Jaberi <monthadar@gmail.com>
To: freebsd-net@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Clarification request about mesh_parse_meshpeering_action()
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 13:10:34 -0000

Hi,

I hope someone can explain to me the following:

in ieee80211_mesh.c in function mesh_parse_meshpeering_action().
The last argument uint8_t subtype is supposed to tell the type of Mesh
Peer Managment Action frame.

The weird thing is that inside the function subtype is checked if it
is equal to IEEE80211_MESH_PEER_LINK_CLOSE and a bit lower in the code
it is checked if it is not equal to
IEEE80211_ACTION_MESHPEERING_CLOSE.

These two enums represent two different things. One is an
InformationElement while the other is an Action Frame that contains
Information elements.

How come?

br,
//Monthadar Al Jaberi

From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 14:24:47 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 6DECF106564A;
	Mon, 25 Jul 2011 14:24:47 +0000 (UTC)
	(envelope-from tuexen@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 458308FC12;
	Mon, 25 Jul 2011 14:24:47 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6PEOlS4038850;
	Mon, 25 Jul 2011 14:24:47 GMT
	(envelope-from tuexen@freefall.freebsd.org)
Received: (from tuexen@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6PEOlWL038846;
	Mon, 25 Jul 2011 14:24:47 GMT (envelope-from tuexen)
Date: Mon, 25 Jul 2011 14:24:47 GMT
Message-Id: <201107251424.p6PEOlWL038846@freefall.freebsd.org>
To: netch@netch.kiev.ua, tuexen@FreeBSD.org, freebsd-net@FreeBSD.org
From: tuexen@FreeBSD.org
Cc: 
Subject: Re: bin/150642: netstat(1) doesn't print anything for SCTP sockets
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 14:24:47 -0000

Synopsis: netstat(1) doesn't print anything for SCTP sockets

State-Changed-From-To: open->closed
State-Changed-By: tuexen
State-Changed-When: Mon Jul 25 14:23:48 UTC 2011
State-Changed-Why: 
Fixed in  http://svn.freebsd.org/changeset/base/224271

http://www.freebsd.org/cgi/query-pr.cgi?pr=150642

From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 15:32:33 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A65771065758
	for <freebsd-net@freebsd.org>; Mon, 25 Jul 2011 15:32:33 +0000 (UTC)
	(envelope-from bhutchings@solarflare.com)
Received: from exchange.solarflare.com (exchange.solarflare.com
	[216.237.3.220])
	by mx1.freebsd.org (Postfix) with ESMTP id 83A2F8FC15
	for <freebsd-net@freebsd.org>; Mon, 25 Jul 2011 15:32:33 +0000 (UTC)
Received: from [10.11.1.192] ([78.28.140.4]) by exchange.solarflare.com with
	Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 08:20:32 -0700
From: Ben Hutchings <bhutchings@solarflare.com>
To: Ivan Alexandrovich <ivsan@ngs.ru>
In-Reply-To: <web-8364904@mx16.intranet.ru>
References: <web-8285764@mx16.intranet.ru>
	<CAFMmRNxNYyWUYZ299GeK6oksay_5nL9XxVvM39LTQEakRPXE9g@mail.gmail.com>
	<web-8364904@mx16.intranet.ru>
Content-Type: text/plain; charset="UTF-8"
Organization: Solarflare Communications
Date: Mon, 25 Jul 2011 17:20:25 +0200
Message-ID: <1311607225.4301.69.camel@deadeye>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Jul 2011 15:20:33.0088 (UTC)
	FILETIME=[655FE400:01CC4ADE]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18282.005
X-TM-AS-Result: No--21.768000-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Cc: freebsd-net@freebsd.org, Ryan Stone <rysto32@gmail.com>
Subject: Re: Ethernet link status on i82576
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 15:32:33 -0000

On Mon, 2011-07-25 at 16:38 +0700, Ivan Alexandrovich wrote:
> On Fri, 22 Jul 2011 11:08:18 -0400 Ryan Stone <rysto32@gmail.com> wrote:
> > I notice that the interface not up in your test.  If you ifconfig it
> > up does it detect that it has lost link?  
> 
> Thank you. When the interface is "up" driver works as expected.

It's common behaviour that the physical link status is not (easily)
available while the interface is down.  In Linux we resolved that when
an interface is down its link state is always reported as down (where we
have to give a boolean answer).

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 17:05:15 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id DD426106566B
	for <freebsd-net@freebsd.org>; Mon, 25 Jul 2011 17:05:15 +0000 (UTC)
	(envelope-from jfvogel@gmail.com)
Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com
	[209.85.212.54])
	by mx1.freebsd.org (Postfix) with ESMTP id 964D98FC15
	for <freebsd-net@freebsd.org>; Mon, 25 Jul 2011 17:05:15 +0000 (UTC)
Received: by vws18 with SMTP id 18so4152498vws.13
	for <freebsd-net@freebsd.org>; Mon, 25 Jul 2011 10:05:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=JjKirhdiDFGjHwInm4xmfAFl6xjzju5zhCi7S3J4VfI=;
	b=nkQ+13RxEmjJknmwHNe+uAjkok/sIQKG6DWdQwJBjMaX4Mi2UoFHNxuMlrifAFJPyR
	WELf1zTHN67FgBQBnJT5YFyXtmUjijploP0ZRZfthJn2cThyxdhvee86LQkBoaU+Qa6k
	h25Rk7GN8WM5+GW9nQQbLjJnGJE9TS8LjGigk=
MIME-Version: 1.0
Received: by 10.52.22.201 with SMTP id g9mr4455488vdf.331.1311613514072; Mon,
	25 Jul 2011 10:05:14 -0700 (PDT)
Received: by 10.52.187.66 with HTTP; Mon, 25 Jul 2011 10:05:13 -0700 (PDT)
In-Reply-To: <1311607225.4301.69.camel@deadeye>
References: <web-8285764@mx16.intranet.ru>
	<CAFMmRNxNYyWUYZ299GeK6oksay_5nL9XxVvM39LTQEakRPXE9g@mail.gmail.com>
	<web-8364904@mx16.intranet.ru> <1311607225.4301.69.camel@deadeye>
Date: Mon, 25 Jul 2011 10:05:13 -0700
Message-ID: <CAFOYbcm73BeK8xgt9j1769ZUdM4cKJUSe9inBZHko7TXkYASSw@mail.gmail.com>
From: Jack Vogel <jfvogel@gmail.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: freebsd-net@freebsd.org, Ivan Alexandrovich <ivsan@ngs.ru>,
	Ryan Stone <rysto32@gmail.com>
Subject: Re: Ethernet link status on i82576
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 17:05:15 -0000

Ya, well that has some odd side effects also, for instance, the phy will in
fact
bring link up just via hardware initialization, so the link light will be on
if you
look at the port on the card, its this fact that is discovered when the
driver
attach routine is run, but as I said, no interrupts so no changes once that
first detection happens. If I were just to say its down until init happens
someone
would inevitably complain about the disagreement between those :)

On the 10G adapters the physical link also does not come up until init runs
so they are a bit more consistent.

Jack


On Mon, Jul 25, 2011 at 8:20 AM, Ben Hutchings <bhutchings@solarflare.com>wrote:

> On Mon, 2011-07-25 at 16:38 +0700, Ivan Alexandrovich wrote:
> > On Fri, 22 Jul 2011 11:08:18 -0400 Ryan Stone <rysto32@gmail.com> wrote:
> > > I notice that the interface not up in your test.  If you ifconfig it
> > > up does it detect that it has lost link?
> >
> > Thank you. When the interface is "up" driver works as expected.
>
> It's common behaviour that the physical link status is not (easily)
> available while the interface is down.  In Linux we resolved that when
> an interface is down its link state is always reported as down (where we
> have to give a boolean answer).
>
> Ben.
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>

From owner-freebsd-net@FreeBSD.ORG  Mon Jul 25 18:37:36 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 63251106564A
	for <net@freebsd.org>; Mon, 25 Jul 2011 18:37:36 +0000 (UTC)
	(envelope-from lists@jnielsen.net)
Received: from ns1temp.jnielsen.net (ns1temp.jnielsen.net [69.55.230.42])
	by mx1.freebsd.org (Postfix) with ESMTP id 4C3FD8FC12
	for <net@freebsd.org>; Mon, 25 Jul 2011 18:37:36 +0000 (UTC)
Received: from jnielsen.socialserve.com ([12.249.176.26])
	(authenticated bits=0)
	by ns1temp.jnielsen.net (8.14.3/8.14.3) with ESMTP id p6PI78Sx043569
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Mon, 25 Jul 2011 14:07:08 -0400 (EDT)
	(envelope-from lists@jnielsen.net)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: John Nielsen <lists@jnielsen.net>
In-Reply-To: <m2oc0kss6m.wl%randy@psg.com>
Date: Mon, 25 Jul 2011 14:07:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D1FE4BEB-7DE0-44B0-A2F0-B7AE7D40DB7E@jnielsen.net>
References: <m2oc0kss6m.wl%randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.1084)
X-DCC-sonic.net-Metrics: ns1temp.jnielsen.net; whitelist
X-Virus-Scanned: clamav-milter 0.97 at ns1temp.jnielsen.net
X-Virus-Status: Clean
Cc: FreeBSD Net <net@freebsd.org>
Subject: Re: netflix from japan
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 18:37:36 -0000

On Jul 23, 2011, at 3:38 PM, Randy Bush wrote:

> netflix streaming is not allowed to japan where we live.  i can tunnel
> to a server in one of my racks in the states.  the tokyo border is a
> soekris running FreeBSD 8.  it will kinda look like
>=20
>               .------------------------------.
>               |                              |
>               |                     b --wlan0| ......  Apple TV
>               |                     r        |
>    WAN IIJ    |                     i --- vr1|
>    PPP/NAT ---|vr0[PPPoE][ppp]tun0--d        | 192.168.0.0/24
> Public IP Addr |                     g --- vr2| LAN hosts,
>               |                     e        | DHCP Clients
>               |                     0 --- vr3| ...
>               |                              |
>               `------------------------------'
>=20
> ---
>=20
>    % cat /etc/ppp/ppp.conf
>    iij:
>     set device PPPoE:vr0
>     set MRU 1454
>     set MTU 1454
>     accept CHAP
>     enable lqr
>     add default HISADDR
>     nat enable yes
>     nat port tcp 192.168.0.33:51332 51332
>     nat port udp 192.168.0.33:51332 51332
>     nat port tcp 192.168.0.12:22 42022
>     set authname foo
>     set authkey bar
>=20
> ---
>=20
> there seem to be at least two sets of problems
>=20
>  o what are the ip addys and ports involved in netflix streaming =
set-up
>    and delivery?
>=20
>  o how to tunnel just those to/from a server in the states?
>=20
> anyone with suggestions?

I use my FreeBSD router at home for similar purposes from time to time =
(getting past draconian firewalls, working around various types of =
broken-ness in public WiFi networks, etc). I don't have many specific =
comments on your setup outlined above, but I hope that outlining my =
approach will give you some ideas.

On the side with "good" (unrestricted, etc) connectivity (home, in my =
case):
FreeBSD router w/ public IP.
NAT - I use IPFW but any solution should work
OpenVPN running as a TCP server on port 443 (for maximum chance of being =
reachable through draconian firewalls). Other VPN / tunneling solutions =
should work here. For some types of traffic (like streaming video) TCP =
is not ideal so if you don't have firewall issues use UDP and a more =
standard port.
NAT should be configured to work with VPN traffic.


On the restricted/broken side:
Any computer/OS that supports OpenVPN or whatever VPN/tunneling solution =
you use (FreeBSD, Linux, Mac, Windows, jailbroken iPhone...). This can =
be set up on a single device (laptop, etc) or on a router/gateway =
machine so the whole network benefits.
For somewhat restrictive but otherwise decent networks:
	Establish VPN connection
	Add static route(s) for restricted IP's using VPN server =
internal IP
For really broken networks, route ALL traffic through VPN:
	Use IP (not DNS name) for server in VPN config)
	Establish VPN connection
	Add static route using local gateway for VPN server external IP
	Delete existing (local) default gateway
	Add VPN server internal IP as default gateway
	Use VPN server or other known good server for DNS
There are some in-between combinations as well; just make sure to think =
about DNS and leave a working route for your VPN packets to follow.

Works like a charm, but keep in mind that the VPN download speed is the =
server side's upload speed. More of an issue for my home connection than =
for a datacenter link I imagine. To get your questions answered I would =
suggest setting up a general solution (get the VPN/tunnel and NAT =
working between your two gateways) and then do some experimenting. You =
could maybe start by forwarding all traffic from the LAN over the =
tunnel, start tcpdump on your local gateway, and fire up a show on the =
Apple TV. Then analyze the result--pay attention to the DNS requests as =
well as the actual data streams. Probably easiest just to identify the =
IP's being used then use whois to extrapolate them to IP blocks. Add =
static routes that use your tunnel for the IP ranges you identify. =
Repeat as needed.

If you want to be more specific than that (route based on LAN source IP =
or specific IP/port combinations) you should look in to using setfib and =
friends (possibly within your firewall ruleset).

HTH,

JN


From owner-freebsd-net@FreeBSD.ORG  Tue Jul 26 06:35:06 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id AD0E0106564A;
	Tue, 26 Jul 2011 06:35:06 +0000 (UTC)
	(envelope-from linimon@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 849228FC08;
	Tue, 26 Jul 2011 06:35:06 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6Q6Z69R034402;
	Tue, 26 Jul 2011 06:35:06 GMT
	(envelope-from linimon@freefall.freebsd.org)
Received: (from linimon@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6Q6Z6wQ034396;
	Tue, 26 Jul 2011 06:35:06 GMT (envelope-from linimon)
Date: Tue, 26 Jul 2011 06:35:06 GMT
Message-Id: <201107260635.p6Q6Z6wQ034396@freefall.freebsd.org>
To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org
From: linimon@FreeBSD.org
Cc: 
Subject: Re: kern/159203: [wpi] Intel 3945ABG Wireless LAN not support IBSS
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 06:35:06 -0000

Old Synopsis: Intel 3945ABG Wireless LAN not support IBSS
New Synopsis: [wpi] Intel 3945ABG Wireless LAN not support IBSS

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Jul 26 06:34:26 UTC 2011
Responsible-Changed-Why: 

Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=159203

From owner-freebsd-net@FreeBSD.ORG  Tue Jul 26 07:14:10 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 65B04106564A
	for <freebsd-net@freebsd.org>; Tue, 26 Jul 2011 07:14:10 +0000 (UTC)
	(envelope-from vladimir.budnev@gmail.com)
Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com
	[209.85.215.54])
	by mx1.freebsd.org (Postfix) with ESMTP id EE7208FC08
	for <freebsd-net@freebsd.org>; Tue, 26 Jul 2011 07:14:09 +0000 (UTC)
Received: by ewy1 with SMTP id 1so184835ewy.13
	for <freebsd-net@freebsd.org>; Tue, 26 Jul 2011 00:14:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=qW2XuDPy0c7JeiZRaATvk7V7MBwNDWZD03ZyI6ro6gE=;
	b=mtHdeAElg0Pw7/O65i8thbJjVJJtGEy9rgBxjtRCB3UholsCQSehXQLSDlhytkOogR
	zyzl0NldZgZUMOl5EpPM7RAG/KdOhaAwN/mHXTdWTJ10tqpT0Obrj9gLar8WBS5p5EMr
	t7D0Yt2YTK3KbVkOHrvMocvhM/HO+7sA7KZEg=
Received: by 10.204.13.202 with SMTP id d10mr557913bka.123.1311664448679;
	Tue, 26 Jul 2011 00:14:08 -0700 (PDT)
Received: from [192.168.66.106] ([80.253.27.98])
	by mx.google.com with ESMTPS id l21sm64424bkt.35.2011.07.26.00.14.07
	(version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 00:14:07 -0700 (PDT)
Message-ID: <4E2E692E.6050503@gmail.com>
Date: Tue, 26 Jul 2011 11:13:50 +0400
From: Vladimir Budnev <vladimir.budnev@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru_RU;
	rv:1.9.1.16) Gecko/20110303 Icedove/3.0.11
MIME-Version: 1.0
To: Bruce Evans <brde@optusnet.com.au>
References: <CAAvRK942U+AiokN0MWQVteeYS5tk+drCOQ_ybRcKZT0gN4Y8WA@mail.gmail.com>
	<20110723100828.S4156@besplex.bde.org>
In-Reply-To: <20110723100828.S4156@besplex.bde.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@FreeBSD.org
Subject: Re: What does define COMMENT_ONLY mean?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 07:14:10 -0000

On 07/23/11 04:21, Bruce Evans wrote:
>
> C didn't support support variable-sized structs before C99, and
> doesn't really support them now.  Various hacks are used to make
> pseudo-structs larger or smaller than ones that can actually be
> declared work.  The above is one.  The pseudo-struct is malloc()ed
> and has size larger than the declared one.  The above says what
> would be in it if it could be declared.
>
> If this were written in C99, it might declare u_char ar_foo[] in the
> the code instead of in a comment.  But C can't really support variable-
> sized structs.  It only allows one ar_foo[], which must be at the end
> of the struct.  ar_foo then has a known offset but an unknown size.
> The other ar_bar[]'s still can't be declared, since they want to be
> further beyond the end of the struct, which places them at an unknown
> offset.
>
> A probably-less-unportable way was to declare everything in the struct
> but malloc() less.  This only works if all the magic fields are at
> known offsets.  This doesn't work in the above, since the fields want
> to have variable lengths each and thus end up at variable offsets.
> Such fields can be allocated from a single larger field (usually an
> an array), but you lose the possibility of declaring them all.
>
> Bruce

I got the idea with "dynamic size", tnx:) But comment_only ...ah 
nevermined. Tnx for explanation, Bruce.

From owner-freebsd-net@FreeBSD.ORG  Tue Jul 26 09:09:12 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 770A6106566B;
	Tue, 26 Jul 2011 09:09:12 +0000 (UTC)
	(envelope-from rwatson@freebsd.org)
Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42])
	by mx1.freebsd.org (Postfix) with ESMTP id 513D58FC12;
	Tue, 26 Jul 2011 09:09:12 +0000 (UTC)
Received: from [192.168.2.112]
	(host86-148-225-194.range86-148.btcentralplus.com [86.148.225.194])
	by cyrus.watson.org (Postfix) with ESMTPSA id 2A90C46B23;
	Tue, 26 Jul 2011 05:09:11 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Robert N. M. Watson" <rwatson@freebsd.org>
In-Reply-To: <201107251300.20832.Daan@vitsch.nl>
Date: Tue, 26 Jul 2011 10:09:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1836450A-72C5-4796-811E-91C3974C1932@freebsd.org>
References: <20110714154457.GI70776@FreeBSD.org>
	<CAFMmRNwBbxR-F7PjkwF8E4GjwFQy_0USKW-3u-ZRNxPMJSOQcA@mail.gmail.com>
	<E05FE767-1923-4D47-9759-FA040E403618@freebsd.org>
	<201107251300.20832.Daan@vitsch.nl>
To: Daan Vreeken <Daan@vitsch.nl>
X-Mailer: Apple Mail (2.1084)
Cc: freebsd-net@freebsd.org, bz@freebsd.org, Ryan Stone <rysto32@gmail.com>,
	gnn@freebsd.org
Subject: Re: m_pkthdr.rcvif dangling pointer problem
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 09:09:12 -0000


On 25 Jul 2011, at 12:00, Daan Vreeken wrote:

> Couldn't the dangling pointer problem be solved by adding a =
'generation' field=20
> to the mbuf structure?
> The 'generation' could be a system-wide number that gets incremented =
whenever=20
> an interface is removed. The mbuf* functions could keep a (per CPU?)=20=

> reference count on the number of mbufs allocated/freed during=20
> that 'generation'. After interface removal, the ifnet structure could =
be=20
> freed when all the reference counters of generations before the =
current=20
> generation reach zero (whenever that happens).

I think a hybrid approach makes sense, combining a number of the ideas =
we've been kicking about:

(1) Add per-CPU ifnet refcounts that don't imply cache-line misses on =
each mbuf alloc/free
(2) Add optional subsystem drain functions so that subsystems that may =
have unbounded queueing times for mbufs deterministically ensure =
reference release, perhaps by substituting a common deadif for =
outstanding dying references.

The former gives us actual correctness in terms of avoiding races, the =
latter gives us deterministic freeing by subsystems that potentially =
queue mbufs forever (i.e., TCP) but no longer require the ifnet =
reference.

Robert=

From owner-freebsd-net@FreeBSD.ORG  Tue Jul 26 11:52:19 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id CD24D106564A
	for <freebsd-net@freebsd.org>; Tue, 26 Jul 2011 11:52:19 +0000 (UTC)
	(envelope-from pkeusem@visi.com)
Received: from g2host.com (mailfront3.g2host.com [208.42.184.241])
	by mx1.freebsd.org (Postfix) with ESMTP id 6D4F48FC1F
	for <freebsd-net@freebsd.org>; Tue, 26 Jul 2011 11:52:19 +0000 (UTC)
Received: from [173.30.51.17] (account pkeusem@visi.com HELO [172.16.175.217])
	by mailfront3.g2host.com (CommuniGate Pro SMTP 5.3.11)
	with ESMTPSA id 21892118; Tue, 26 Jul 2011 06:52:18 -0500
Message-ID: <4E2EAA70.2020708@visi.com>
Date: Tue, 26 Jul 2011 06:52:16 -0500
From: Paul Keusemann <pkeusem@visi.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US;
	rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Chuck Swiger <cswiger@mac.com>
References: <4E159C5A.5090702@visi.com>	<13D65A4C-F874-4970-A070-AA0392416680@mac.com>	<4E1C9FEA.2080608@visi.com>
	<5458975C-9FA3-4AB6-9535-3D7BD152378B@mac.com>
In-Reply-To: <5458975C-9FA3-4AB6-9535-3D7BD152378B@mac.com>
X-Is-From-Me: yes
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org
Subject: Re: Debugging dropped shell connections over a VPN
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 11:52:19 -0000

Once again, apologies for my sluggish response.  The VPN problem is a 
background job worked on when I can or when I'm too annoyed by it to do 
anything else.

On 07/12/11 17:42, Chuck Swiger wrote:
> On Jul 12, 2011, at 12:26 PM, Paul Keusemann wrote:
>> So, any other ideas on how to debug this?
> Gather data with tcpdump.  If you do it on one of the VPN endpoints, you ought to see the VPN contents rather than just packets going by in the encrypted tunnel.
>

I assume by endpoint, you are talking about the target of the remote 
shell.  Unfortunately, running tcpdump on the endpoint shows only the 
initial negotiation (and any interactive keyboard traffic) but nothing 
to indicate the connection has been dropped or timed out.

If I can get some time when I don't actually need to use the VPN for 
work, I'm going to try to run tcpdump on the tunnel to see if there's 
anything going across it that might shed some light on the cause of the 
dropped connections.

>> Anybody know how to get racoon to log everything to one file?  Right now, depending on the log level, I am getting messages in racoon.log (specified with -l at startup), messages and debug.log.  It would really be nice to have just one log to look at.
> This is likely governed by /etc/syslog.conf, but if you specify -l then racoon shouldn't use syslog logging.

My syslog.conf foo is not good but it seems that some stuff  from racoon 
always ends up in the messages file, even when the -l option to racoon 
is specified.

Thanks again for the tips.

-- 
Paul Keusemann			                      pkeusem@visi.com
4266 Joppa Court		                      (952) 894-7805
Savage, MN  55378


From owner-freebsd-net@FreeBSD.ORG  Tue Jul 26 11:54:01 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B1DEF1065670
	for <freebsd-net@freebsd.org>; Tue, 26 Jul 2011 11:54:01 +0000 (UTC)
	(envelope-from pkeusem@visi.com)
Received: from g2host.com (mailfront4.g2host.com [208.42.184.242])
	by mx1.freebsd.org (Postfix) with ESMTP id 695A28FC19
	for <freebsd-net@freebsd.org>; Tue, 26 Jul 2011 11:54:01 +0000 (UTC)
Received: from [173.30.51.17] (account pkeusem@visi.com HELO [172.16.175.217])
	by mailfront4.g2host.com (CommuniGate Pro SMTP 5.3.11)
	with ESMTPSA id 21150428; Tue, 26 Jul 2011 06:54:00 -0500
Message-ID: <4E2EAAD7.6040906@visi.com>
Date: Tue, 26 Jul 2011 06:53:59 -0500
From: Paul Keusemann <pkeusem@visi.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US;
	rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Gary Palmer <gpalmer@freebsd.org>
References: <4E159C5A.5090702@visi.com>	<13D65A4C-F874-4970-A070-AA0392416680@mac.com>	<4E1C9FEA.2080608@visi.com>
	<20110720201502.GA37199@in-addr.com>
In-Reply-To: <20110720201502.GA37199@in-addr.com>
X-Is-From-Me: yes
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org
Subject: Re: Debugging dropped shell connections over a VPN
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 11:54:01 -0000

Again, sorry for the sluggish response.

On 07/20/11 15:15, Gary Palmer wrote:
> On Tue, Jul 12, 2011 at 02:26:34PM -0500, Paul Keusemann wrote:
>> On 07/07/11 14:39, Chuck Swiger wrote:
>>> On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote:
>>>> My setup is something like this:
>>>> - My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris
>>>> machines running various OS versions.
>>>> - My gateway / firewall  machine is running FreeBSD-8.1-RELEASE-p1 with
>>>> ipfw, nat and racoon for the firewall and VPN.
>>>>
>>>> The problem is that rlogin, ssh and telnet connections over the VPN get
>>>> dropped after some period of inactivity.
>>> You're probably getting NAT timeouts against the VPN connection if it is
>>> left idle.  racoon ought to have a config setting called natt_keepalive
>>> which sends periodic keepalives-- see whether that's disabled.
>>>
>>> Regards,
>> Thanks for the suggestions Chuck, sorry it's taken so long to respond
>> but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in
>> order to try this out.
>>
>> One thing that I did not explicitly mention before is that I am routing
>> a network over the VPN.
> Hi Paul,
>
> Even if you are not being NAT'd on the VPN there may be a firewall (or
> other active network component like a load balancer) with an
> overflowing state table somewhere at the remote end.  We see this
> frequently where I work with customer networks and the firewall/VPN/network
> admin denies that its a time out issue so there is likely some device in
> the network that has a state table and if the connection is idle for a
> few minutes it gets dropped.

Hmmm,  this seems likely.  Have you had any luck in finding the culprit 
and resolving the problem?


> Regards,
>
> Gary
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>


-- 
Paul Keusemann			                      pkeusem@visi.com
4266 Joppa Court		                      (952) 894-7805
Savage, MN  55378


From owner-freebsd-net@FreeBSD.ORG  Tue Jul 26 13:05:51 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 085E71065672;
	Tue, 26 Jul 2011 13:05:51 +0000 (UTC)
	(envelope-from gpalmer@freebsd.org)
Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1])
	by mx1.freebsd.org (Postfix) with ESMTP id CEBDA8FC16;
	Tue, 26 Jul 2011 13:05:50 +0000 (UTC)
Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD))
	(envelope-from <gpalmer@freebsd.org>)
	id 1QlhKX-000DCI-7O; Tue, 26 Jul 2011 09:05:49 -0400
Date: Tue, 26 Jul 2011 09:05:49 -0400
From: Gary Palmer <gpalmer@freebsd.org>
To: Paul Keusemann <pkeusem@visi.com>
Message-ID: <20110726130549.GD1339@in-addr.com>
References: <4E159C5A.5090702@visi.com>
	<13D65A4C-F874-4970-A070-AA0392416680@mac.com>
	<4E1C9FEA.2080608@visi.com> <20110720201502.GA37199@in-addr.com>
	<4E2EAAD7.6040906@visi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4E2EAAD7.6040906@visi.com>
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: gpalmer@freebsd.org
X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false
Cc: freebsd-net@freebsd.org
Subject: Re: Debugging dropped shell connections over a VPN
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 13:05:51 -0000

On Tue, Jul 26, 2011 at 06:53:59AM -0500, Paul Keusemann wrote:
> Again, sorry for the sluggish response.
> 
> On 07/20/11 15:15, Gary Palmer wrote:
> >On Tue, Jul 12, 2011 at 02:26:34PM -0500, Paul Keusemann wrote:
> >>On 07/07/11 14:39, Chuck Swiger wrote:
> >>>On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote:
> >>>>My setup is something like this:
> >>>>- My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris
> >>>>machines running various OS versions.
> >>>>- My gateway / firewall  machine is running FreeBSD-8.1-RELEASE-p1 with
> >>>>ipfw, nat and racoon for the firewall and VPN.
> >>>>
> >>>>The problem is that rlogin, ssh and telnet connections over the VPN get
> >>>>dropped after some period of inactivity.
> >>>You're probably getting NAT timeouts against the VPN connection if it is
> >>>left idle.  racoon ought to have a config setting called natt_keepalive
> >>>which sends periodic keepalives-- see whether that's disabled.
> >>>
> >>>Regards,
> >>Thanks for the suggestions Chuck, sorry it's taken so long to respond
> >>but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in
> >>order to try this out.
> >>
> >>One thing that I did not explicitly mention before is that I am routing
> >>a network over the VPN.
> >Hi Paul,
> >
> >Even if you are not being NAT'd on the VPN there may be a firewall (or
> >other active network component like a load balancer) with an
> >overflowing state table somewhere at the remote end.  We see this
> >frequently where I work with customer networks and the firewall/VPN/network
> >admin denies that its a time out issue so there is likely some device in
> >the network that has a state table and if the connection is idle for a
> >few minutes it gets dropped.
> 
> Hmmm,  this seems likely.  Have you had any luck in finding the culprit 
> and resolving the problem?

Unfortunately no.  We know the problem exists but as a vendor we have
very little success in getting the customer to identify the problematic
device inside their network as it only seems to affect our connections
to them when we are helping them with problems, so there is almost
always something more important going on and the timeout issue gets put
on the back burner and forgotten.  We've worked around it in some
places by using the ssh 'ServerAliveInterval' directive to make ssh
send packets and keep the session open even if we're idle, but that
doesn't always work.

Gary

From owner-freebsd-net@FreeBSD.ORG  Tue Jul 26 13:13:39 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A943810657A6;
	Tue, 26 Jul 2011 13:13:39 +0000 (UTC)
	(envelope-from luigi@onelab2.iet.unipi.it)
Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238])
	by mx1.freebsd.org (Postfix) with ESMTP id 5577C8FC15;
	Tue, 26 Jul 2011 13:13:38 +0000 (UTC)
Received: by onelab2.iet.unipi.it (Postfix, from userid 275)
	id 4BDB47300A; Tue, 26 Jul 2011 15:12:15 +0200 (CEST)
Date: Tue, 26 Jul 2011 15:12:15 +0200
From: Luigi Rizzo <rizzo@iet.unipi.it>
To: "Robert N. M. Watson" <rwatson@freebsd.org>
Message-ID: <20110726131215.GC6415@onelab2.iet.unipi.it>
References: <20110714154457.GI70776@FreeBSD.org>
	<CAFMmRNwBbxR-F7PjkwF8E4GjwFQy_0USKW-3u-ZRNxPMJSOQcA@mail.gmail.com>
	<E05FE767-1923-4D47-9759-FA040E403618@freebsd.org>
	<201107251300.20832.Daan@vitsch.nl>
	<1836450A-72C5-4796-811E-91C3974C1932@freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1836450A-72C5-4796-811E-91C3974C1932@freebsd.org>
User-Agent: Mutt/1.4.2.3i
Cc: Daan Vreeken <Daan@vitsch.nl>, gnn@freebsd.org, bz@freebsd.org,
	Ryan Stone <rysto32@gmail.com>, freebsd-net@freebsd.org
Subject: Re: m_pkthdr.rcvif dangling pointer problem
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 13:13:39 -0000

On Tue, Jul 26, 2011 at 10:09:09AM +0100, Robert N. M. Watson wrote:
> 
> On 25 Jul 2011, at 12:00, Daan Vreeken wrote:
> 
> > Couldn't the dangling pointer problem be solved by adding a 'generation' field 
> > to the mbuf structure?
> > The 'generation' could be a system-wide number that gets incremented whenever 
> > an interface is removed. The mbuf* functions could keep a (per CPU?) 
> > reference count on the number of mbufs allocated/freed during 
> > that 'generation'. After interface removal, the ifnet structure could be 
> > freed when all the reference counters of generations before the current 
> > generation reach zero (whenever that happens).
> 
> I think a hybrid approach makes sense, combining a number of the ideas we've been kicking about:
> 
> (1) Add per-CPU ifnet refcounts that don't imply cache-line misses on each mbuf alloc/free
> (2) Add optional subsystem drain functions so that subsystems that may have unbounded queueing times for mbufs deterministically ensure reference release, perhaps by substituting a common deadif for outstanding dying references.
> 
> The former gives us actual correctness in terms of avoiding races, the latter gives us deterministic freeing by subsystems that potentially queue mbufs forever (i.e., TCP) but no longer require the ifnet reference.

I'd like to suggest that before doing all this work we could try
and see which subsystems have a real need to de-reference the
reference, which fields they use, and how often.

Because maybe just copying into the mbuf a blob of 8-16 bytes with
useful info (a cookie, fib index, some flags, etc) could perhaps cover the
majority of cases (in terms of usage frequency, not locations in the code)
and let us deal with other cases by looking up the cookie in some
data structure.

As an example:
- some functions just use rcvif to tell whether this is an incoming
  packet. No actual dereference;
- others might only care that rcvif equals some other (already refcounted)
  value, so we don't have a race there.

cheers
luigi

From owner-freebsd-net@FreeBSD.ORG  Tue Jul 26 14:53:18 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B3598106566C;
	Tue, 26 Jul 2011 14:53:18 +0000 (UTC)
	(envelope-from maxim@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 8BE938FC0C;
	Tue, 26 Jul 2011 14:53:18 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6QErIvr026128;
	Tue, 26 Jul 2011 14:53:18 GMT
	(envelope-from maxim@freefall.freebsd.org)
Received: (from maxim@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6QErItd026124;
	Tue, 26 Jul 2011 14:53:18 GMT (envelope-from maxim)
Date: Tue, 26 Jul 2011 14:53:18 GMT
Message-Id: <201107261453.p6QErItd026124@freefall.freebsd.org>
To: aboyer@averesystems.com, maxim@FreeBSD.org, freebsd-net@FreeBSD.org
From: maxim@FreeBSD.org
Cc: 
Subject: Re: kern/156978: [lagg][patch] Take lagg rlock before checking flags
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 14:53:18 -0000

Synopsis: [lagg][patch] Take lagg rlock before checking flags

State-Changed-From-To: open->patched
State-Changed-By: maxim
State-Changed-When: Tue Jul 26 14:52:18 UTC 2011
State-Changed-Why: 
thompsa@ has committed the patch to HEAD in r223846.

http://www.freebsd.org/cgi/query-pr.cgi?pr=156978

From owner-freebsd-net@FreeBSD.ORG  Tue Jul 26 18:35:20 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 11A05106564A;
	Tue, 26 Jul 2011 18:35:20 +0000 (UTC)
	(envelope-from pkeusem@visi.com)
Received: from g2host.com (mailfront4.g2host.com [208.42.184.242])
	by mx1.freebsd.org (Postfix) with ESMTP id A9FF38FC12;
	Tue, 26 Jul 2011 18:35:19 +0000 (UTC)
Received: from [173.30.51.17] (account pkeusem@visi.com HELO [172.16.175.217])
	by mailfront4.g2host.com (CommuniGate Pro SMTP 5.3.11)
	with ESMTPSA id 21228672; Tue, 26 Jul 2011 13:35:18 -0500
Message-ID: <4E2F08E4.2070100@visi.com>
Date: Tue, 26 Jul 2011 13:35:16 -0500
From: Paul Keusemann <pkeusem@visi.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US;
	rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Gary Palmer <gpalmer@freebsd.org>
References: <4E159C5A.5090702@visi.com>	<13D65A4C-F874-4970-A070-AA0392416680@mac.com>	<4E1C9FEA.2080608@visi.com>
	<20110720201502.GA37199@in-addr.com>	<4E2EAAD7.6040906@visi.com>
	<20110726130549.GD1339@in-addr.com>
In-Reply-To: <20110726130549.GD1339@in-addr.com>
X-Is-From-Me: yes
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org
Subject: Re: Debugging dropped shell connections over a VPN
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 18:35:20 -0000

On 07/26/11 08:05, Gary Palmer wrote:
> On Tue, Jul 26, 2011 at 06:53:59AM -0500, Paul Keusemann wrote:
>> Again, sorry for the sluggish response.
>>
>> On 07/20/11 15:15, Gary Palmer wrote:
>>> On Tue, Jul 12, 2011 at 02:26:34PM -0500, Paul Keusemann wrote:
>>>> On 07/07/11 14:39, Chuck Swiger wrote:
>>>>> On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote:
>>>>>> My setup is something like this:
>>>>>> - My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris
>>>>>> machines running various OS versions.
>>>>>> - My gateway / firewall  machine is running FreeBSD-8.1-RELEASE-p1 with
>>>>>> ipfw, nat and racoon for the firewall and VPN.
>>>>>>
>>>>>> The problem is that rlogin, ssh and telnet connections over the VPN get
>>>>>> dropped after some period of inactivity.
>>>>> You're probably getting NAT timeouts against the VPN connection if it is
>>>>> left idle.  racoon ought to have a config setting called natt_keepalive
>>>>> which sends periodic keepalives-- see whether that's disabled.
>>>>>
>>>>> Regards,
>>>> Thanks for the suggestions Chuck, sorry it's taken so long to respond
>>>> but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in
>>>> order to try this out.
>>>>
>>>> One thing that I did not explicitly mention before is that I am routing
>>>> a network over the VPN.
>>> Hi Paul,
>>>
>>> Even if you are not being NAT'd on the VPN there may be a firewall (or
>>> other active network component like a load balancer) with an
>>> overflowing state table somewhere at the remote end.  We see this
>>> frequently where I work with customer networks and the firewall/VPN/network
>>> admin denies that its a time out issue so there is likely some device in
>>> the network that has a state table and if the connection is idle for a
>>> few minutes it gets dropped.
>> Hmmm,  this seems likely.  Have you had any luck in finding the culprit
>> and resolving the problem?
> Unfortunately no.  We know the problem exists but as a vendor we have
> very little success in getting the customer to identify the problematic
> device inside their network as it only seems to affect our connections
> to them when we are helping them with problems, so there is almost
> always something more important going on and the timeout issue gets put
> on the back burner and forgotten.  We've worked around it in some
> places by using the ssh 'ServerAliveInterval' directive to make ssh
> send packets and keep the session open even if we're idle, but that
> doesn't always work.

OK, I found the ClientAliveInterval, and ClientAliveCountMax setting in 
the ssh_config man page.  I assume these are what you are referring to.  
I tried setting ClientAliveInterval to 15 seconds with 
ClientAliveCountMax set to 3 and this seems to help.  I've only tried 
this a couple of times but I have seen an ssh session stay alive for 
over an hour.  The bad news is that the sessions are still getting 
dropped, at least now I know when it happens.  Now I'm getting the 
following message:

     Received disconnect from 10.64.20.69: 2: Timeout, your session not 
responding.

 From a quick perusal of the openssh source, it is not obvious whether 
this message is coming from the client or the server side.   Initially, 
because the keep alive timer is a server side setting, I assumed the 
message was coming from the server side but if the session is not 
responding how is the message getting to the client?  If it is a client 
side problem, then I have much more flexibility to fix.  All I can do is 
whine about server side problems.

Paul


> Gary
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>


-- 
Paul Keusemann			                      pkeusem@visi.com
4266 Joppa Court		                      (952) 894-7805
Savage, MN  55378


From owner-freebsd-net@FreeBSD.ORG  Wed Jul 27 07:03:10 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id ADC121065675;
	Wed, 27 Jul 2011 07:03:10 +0000 (UTC)
	(envelope-from maxim@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 85B388FC22;
	Wed, 27 Jul 2011 07:03:10 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6R73AKH029954;
	Wed, 27 Jul 2011 07:03:10 GMT
	(envelope-from maxim@freefall.freebsd.org)
Received: (from maxim@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6R73ABe029950;
	Wed, 27 Jul 2011 07:03:10 GMT (envelope-from maxim)
Date: Wed, 27 Jul 2011 07:03:10 GMT
Message-Id: <201107270703.p6R73ABe029950@freefall.freebsd.org>
To: aboyer@averesystems.com, maxim@FreeBSD.org, freebsd-net@FreeBSD.org
From: maxim@FreeBSD.org
Cc: 
Subject: Re: kern/156978: [lagg][patch] Take lagg rlock before checking flags
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 07:03:10 -0000

Synopsis: [lagg][patch] Take lagg rlock before checking flags

State-Changed-From-To: patched->closed
State-Changed-By: maxim
State-Changed-When: Wed Jul 27 07:02:47 UTC 2011
State-Changed-Why: 
Merged to RELENG_8.

http://www.freebsd.org/cgi/query-pr.cgi?pr=156978

From owner-freebsd-net@FreeBSD.ORG  Wed Jul 27 11:50:44 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 69BD3106564A
	for <freebsd-net@freebsd.org>; Wed, 27 Jul 2011 11:50:44 +0000 (UTC)
	(envelope-from gpalmer@freebsd.org)
Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1])
	by mx1.freebsd.org (Postfix) with ESMTP id 2DBDF8FC08
	for <freebsd-net@freebsd.org>; Wed, 27 Jul 2011 11:50:44 +0000 (UTC)
Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD))
	(envelope-from <gpalmer@freebsd.org>)
	id 1Qm2dN-000Fd1-Ic; Wed, 27 Jul 2011 07:50:41 -0400
Date: Wed, 27 Jul 2011 07:50:41 -0400
From: Gary Palmer <gpalmer@freebsd.org>
To: Paul Keusemann <pkeusem@visi.com>
Message-ID: <20110727115041.GE1339@in-addr.com>
References: <4E159C5A.5090702@visi.com>
	<13D65A4C-F874-4970-A070-AA0392416680@mac.com>
	<4E1C9FEA.2080608@visi.com> <20110720201502.GA37199@in-addr.com>
	<4E2EAAD7.6040906@visi.com> <20110726130549.GD1339@in-addr.com>
	<4E2F08E4.2070100@visi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4E2F08E4.2070100@visi.com>
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: gpalmer@freebsd.org
X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false
Cc: freebsd-net@freebsd.org
Subject: Re: Debugging dropped shell connections over a VPN
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 11:50:44 -0000

On Tue, Jul 26, 2011 at 01:35:16PM -0500, Paul Keusemann wrote:
> On 07/26/11 08:05, Gary Palmer wrote:
> >On Tue, Jul 26, 2011 at 06:53:59AM -0500, Paul Keusemann wrote:
> >>Again, sorry for the sluggish response.
> >>
> >>On 07/20/11 15:15, Gary Palmer wrote:
> >>>On Tue, Jul 12, 2011 at 02:26:34PM -0500, Paul Keusemann wrote:
> >>>>On 07/07/11 14:39, Chuck Swiger wrote:
> >>>>>On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote:
> >>>>>>My setup is something like this:
> >>>>>>- My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris
> >>>>>>machines running various OS versions.
> >>>>>>- My gateway / firewall  machine is running FreeBSD-8.1-RELEASE-p1 
> >>>>>>with
> >>>>>>ipfw, nat and racoon for the firewall and VPN.
> >>>>>>
> >>>>>>The problem is that rlogin, ssh and telnet connections over the VPN 
> >>>>>>get
> >>>>>>dropped after some period of inactivity.
> >>>>>You're probably getting NAT timeouts against the VPN connection if it 
> >>>>>is
> >>>>>left idle.  racoon ought to have a config setting called natt_keepalive
> >>>>>which sends periodic keepalives-- see whether that's disabled.
> >>>>>
> >>>>>Regards,
> >>>>Thanks for the suggestions Chuck, sorry it's taken so long to respond
> >>>>but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in
> >>>>order to try this out.
> >>>>
> >>>>One thing that I did not explicitly mention before is that I am routing
> >>>>a network over the VPN.
> >>>Hi Paul,
> >>>
> >>>Even if you are not being NAT'd on the VPN there may be a firewall (or
> >>>other active network component like a load balancer) with an
> >>>overflowing state table somewhere at the remote end.  We see this
> >>>frequently where I work with customer networks and the 
> >>>firewall/VPN/network
> >>>admin denies that its a time out issue so there is likely some device in
> >>>the network that has a state table and if the connection is idle for a
> >>>few minutes it gets dropped.
> >>Hmmm,  this seems likely.  Have you had any luck in finding the culprit
> >>and resolving the problem?
> >Unfortunately no.  We know the problem exists but as a vendor we have
> >very little success in getting the customer to identify the problematic
> >device inside their network as it only seems to affect our connections
> >to them when we are helping them with problems, so there is almost
> >always something more important going on and the timeout issue gets put
> >on the back burner and forgotten.  We've worked around it in some
> >places by using the ssh 'ServerAliveInterval' directive to make ssh
> >send packets and keep the session open even if we're idle, but that
> >doesn't always work.
> 
> OK, I found the ClientAliveInterval, and ClientAliveCountMax setting in 
> the ssh_config man page.  I assume these are what you are referring to.  
> I tried setting ClientAliveInterval to 15 seconds with 
> ClientAliveCountMax set to 3 and this seems to help.  I've only tried 
> this a couple of times but I have seen an ssh session stay alive for 
> over an hour.  The bad news is that the sessions are still getting 
> dropped, at least now I know when it happens.  Now I'm getting the 
> following message:
> 
>     Received disconnect from 10.64.20.69: 2: Timeout, your session not 
> responding.
> 
> From a quick perusal of the openssh source, it is not obvious whether 
> this message is coming from the client or the server side.   Initially, 
> because the keep alive timer is a server side setting, I assumed the 
> message was coming from the server side but if the session is not 
> responding how is the message getting to the client?  If it is a client 
> side problem, then I have much more flexibility to fix.  All I can do is 
> whine about server side problems.


Hi Paul,

ServerAliveInterval is actually a client setting.  e.g.  put this in
your ~/.ssh/config file

host *
	ServerAliveInterval 15

will set the client to ping the server every 15 seconds and try to
keep the connection alive.  You can replace '*' you want to be more
targeted in your configuration.

I've never played with the server side settings for various reasons.

Regards,

Gary

From owner-freebsd-net@FreeBSD.ORG  Wed Jul 27 15:04:19 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 8BFCA106566B;
	Wed, 27 Jul 2011 15:04:19 +0000 (UTC)
	(envelope-from pkeusem@visi.com)
Received: from g2host.com (mailfront4.g2host.com [208.42.184.242])
	by mx1.freebsd.org (Postfix) with ESMTP id 30ABC8FC15;
	Wed, 27 Jul 2011 15:04:18 +0000 (UTC)
Received: from [173.30.51.17] (account pkeusem@visi.com HELO [172.16.175.217])
	by mailfront4.g2host.com (CommuniGate Pro SMTP 5.3.11)
	with ESMTPSA id 21345917; Wed, 27 Jul 2011 10:04:18 -0500
Message-ID: <4E3028F0.2010802@visi.com>
Date: Wed, 27 Jul 2011 10:04:16 -0500
From: Paul Keusemann <pkeusem@visi.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US;
	rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Gary Palmer <gpalmer@freebsd.org>
References: <4E159C5A.5090702@visi.com>	<13D65A4C-F874-4970-A070-AA0392416680@mac.com>	<4E1C9FEA.2080608@visi.com>
	<20110720201502.GA37199@in-addr.com>	<4E2EAAD7.6040906@visi.com>
	<20110726130549.GD1339@in-addr.com>	<4E2F08E4.2070100@visi.com>
	<20110727115041.GE1339@in-addr.com>
In-Reply-To: <20110727115041.GE1339@in-addr.com>
X-Is-From-Me: yes
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org
Subject: Re: Debugging dropped shell connections over a VPN
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 15:04:19 -0000

On 07/27/11 06:50, Gary Palmer wrote:
> On Tue, Jul 26, 2011 at 01:35:16PM -0500, Paul Keusemann wrote:
>> On 07/26/11 08:05, Gary Palmer wrote:
>>> On Tue, Jul 26, 2011 at 06:53:59AM -0500, Paul Keusemann wrote:
>>>> Again, sorry for the sluggish response.
>>>>
>>>> On 07/20/11 15:15, Gary Palmer wrote:
>>>>> On Tue, Jul 12, 2011 at 02:26:34PM -0500, Paul Keusemann wrote:
>>>>>> On 07/07/11 14:39, Chuck Swiger wrote:
>>>>>>> On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote:
>>>>>>>> My setup is something like this:
>>>>>>>> - My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris
>>>>>>>> machines running various OS versions.
>>>>>>>> - My gateway / firewall  machine is running FreeBSD-8.1-RELEASE-p1
>>>>>>>> with
>>>>>>>> ipfw, nat and racoon for the firewall and VPN.
>>>>>>>>
>>>>>>>> The problem is that rlogin, ssh and telnet connections over the VPN
>>>>>>>> get
>>>>>>>> dropped after some period of inactivity.
>>>>>>> You're probably getting NAT timeouts against the VPN connection if it
>>>>>>> is
>>>>>>> left idle.  racoon ought to have a config setting called natt_keepalive
>>>>>>> which sends periodic keepalives-- see whether that's disabled.
>>>>>>>
>>>>>>> Regards,
>>>>>> Thanks for the suggestions Chuck, sorry it's taken so long to respond
>>>>>> but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in
>>>>>> order to try this out.
>>>>>>
>>>>>> One thing that I did not explicitly mention before is that I am routing
>>>>>> a network over the VPN.
>>>>> Hi Paul,
>>>>>
>>>>> Even if you are not being NAT'd on the VPN there may be a firewall (or
>>>>> other active network component like a load balancer) with an
>>>>> overflowing state table somewhere at the remote end.  We see this
>>>>> frequently where I work with customer networks and the
>>>>> firewall/VPN/network
>>>>> admin denies that its a time out issue so there is likely some device in
>>>>> the network that has a state table and if the connection is idle for a
>>>>> few minutes it gets dropped.
>>>> Hmmm,  this seems likely.  Have you had any luck in finding the culprit
>>>> and resolving the problem?
>>> Unfortunately no.  We know the problem exists but as a vendor we have
>>> very little success in getting the customer to identify the problematic
>>> device inside their network as it only seems to affect our connections
>>> to them when we are helping them with problems, so there is almost
>>> always something more important going on and the timeout issue gets put
>>> on the back burner and forgotten.  We've worked around it in some
>>> places by using the ssh 'ServerAliveInterval' directive to make ssh
>>> send packets and keep the session open even if we're idle, but that
>>> doesn't always work.
>> OK, I found the ClientAliveInterval, and ClientAliveCountMax setting in
>> the ssh_config man page.  I assume these are what you are referring to.
>> I tried setting ClientAliveInterval to 15 seconds with
>> ClientAliveCountMax set to 3 and this seems to help.  I've only tried
>> this a couple of times but I have seen an ssh session stay alive for
>> over an hour.  The bad news is that the sessions are still getting
>> dropped, at least now I know when it happens.  Now I'm getting the
>> following message:
>>
>>      Received disconnect from 10.64.20.69: 2: Timeout, your session not
>> responding.
>>
>>  From a quick perusal of the openssh source, it is not obvious whether
>> this message is coming from the client or the server side.   Initially,
>> because the keep alive timer is a server side setting, I assumed the
>> message was coming from the server side but if the session is not
>> responding how is the message getting to the client?  If it is a client
>> side problem, then I have much more flexibility to fix.  All I can do is
>> whine about server side problems.
>
> Hi Paul,
>
> ServerAliveInterval is actually a client setting.  e.g.  put this in
> your ~/.ssh/config file
>
> host *
> 	ServerAliveInterval 15
>
> will set the client to ping the server every 15 seconds and try to
> keep the connection alive.  You can replace '*' you want to be more
> targeted in your configuration.

Ah, I see.  I was looking at the Solaris ssh_config man page.  The 
OpenSSH ssh_config man page is third in the sequence.  The ServerAlive* 
options are not documented in the Solaris ssh_config man page.  I'll try 
it out too.  Thanks.

> I've never played with the server side settings for various reasons.
>
> Regards,
>
> Gary
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>


-- 
Paul Keusemann			                      pkeusem@visi.com
4266 Joppa Court		                      (952) 894-7805
Savage, MN  55378


From owner-freebsd-net@FreeBSD.ORG  Wed Jul 27 16:45:44 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 456D6106566B
	for <freebsd-net@freebsd.org>; Wed, 27 Jul 2011 16:45:44 +0000 (UTC)
	(envelope-from rysto32@gmail.com)
Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com
	[209.85.215.54])
	by mx1.freebsd.org (Postfix) with ESMTP id D78C18FC12
	for <freebsd-net@freebsd.org>; Wed, 27 Jul 2011 16:45:43 +0000 (UTC)
Received: by ewy1 with SMTP id 1so1966657ewy.13
	for <freebsd-net@freebsd.org>; Wed, 27 Jul 2011 09:45:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=NOEs4lbqd+wGEd0eY4c0vJtDv5Jp0Smqltz/KJGoD4Q=;
	b=JjHlCoa224j30ojsydqwfkMC3Pi8JhZPdwCiFwfSci7pAlfZVOhDrjUL/U/xrTww2l
	2W+fJAIU+TwrNXtubbB+Dpoziy4N//6/OGyIejHlKxABQHmcKV+RX+y/Hh25JnLNuFoT
	4xpfWTu7WLKvuoY8APmn1iBx4spSVVWVnR4Ms=
MIME-Version: 1.0
Received: by 10.213.105.145 with SMTP id t17mr18892ebo.31.1311785142292; Wed,
	27 Jul 2011 09:45:42 -0700 (PDT)
Received: by 10.213.31.194 with HTTP; Wed, 27 Jul 2011 09:45:41 -0700 (PDT)
Date: Wed, 27 Jul 2011 12:45:41 -0400
Message-ID: <CAFMmRNzc717KaFk-r8+uBYYKq=+ifQ-1SC0TUjJHKKyiBE5_Pw@mail.gmail.com>
From: Ryan Stone <rysto32@gmail.com>
To: freebsd-net <freebsd-net@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: pxeboot hangs if link bounces
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 16:45:44 -0000

I'm trying to track down a very mysterious problem I've having with
pxebooting on 8.2-RELEASE and head (as of r224149).  I've found that
if I bring the link to a PXE client down and back up while it's in
pxeboot, pxeboot hangs and never recovers.  I've tried bouncing the
link to the NFS server and I see the same behaviour, so I believe that
the issue is really due to packet loss.  I added printfs to the loader
and I've found that the hang occurs when in vm86int() when it's called
from pxe_call, from readudp.  Once I bring down the link, vm86int()
never returns.  That's a BIOS bug -- PXENV_UDP_READ is defined to be
non-blocking by the spec -- but what utterly mystifies me is that a
6.1-RELEASE pxeldr does not get blocked in a PXENV_UDP_READ call.

I'm going to try a binary search to narrow down what set of changes
introduced the problem, but I'm hoping that somebody might have an
idea as to what could have changed that triggers this BIOS bug.  I've
tried building with -DOLD_NFSv2 but that didn't resolve the problem.

Ryan Stone

From owner-freebsd-net@FreeBSD.ORG  Wed Jul 27 18:53:06 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 581041065672
	for <freebsd-net@freebsd.org>; Wed, 27 Jul 2011 18:53:06 +0000 (UTC)
	(envelope-from rysto32@gmail.com)
Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com
	[209.85.215.54])
	by mx1.freebsd.org (Postfix) with ESMTP id DF3308FC0C
	for <freebsd-net@freebsd.org>; Wed, 27 Jul 2011 18:53:05 +0000 (UTC)
Received: by ewy1 with SMTP id 1so2114154ewy.13
	for <freebsd-net@freebsd.org>; Wed, 27 Jul 2011 11:53:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=qCr+6Q9Jgnoxe7kUy2Oj63qU1czDvS2LUyah+Rjzto0=;
	b=S+btZBq4CwG6SA4jbZ8qTfPRy6ApP/XZWmNu1rX4Q09XePcAqD1TsmnVfyUUcpHA4j
	NU5fFPMJDS6+NkRtbt3UH7d4mKFHhhh/2NKxEGuhXGxNAxr8vzlZjASpHRwqt1xB31fE
	RZIFzPoX+loAzXOJtlYWSkV34adPBeUeXbzEI=
MIME-Version: 1.0
Received: by 10.213.13.19 with SMTP id z19mr69739ebz.107.1311792784589; Wed,
	27 Jul 2011 11:53:04 -0700 (PDT)
Received: by 10.213.31.194 with HTTP; Wed, 27 Jul 2011 11:53:04 -0700 (PDT)
In-Reply-To: <CAFMmRNzc717KaFk-r8+uBYYKq=+ifQ-1SC0TUjJHKKyiBE5_Pw@mail.gmail.com>
References: <CAFMmRNzc717KaFk-r8+uBYYKq=+ifQ-1SC0TUjJHKKyiBE5_Pw@mail.gmail.com>
Date: Wed, 27 Jul 2011 14:53:04 -0400
Message-ID: <CAFMmRNxJ1OpqO6ZLiZUmxqHCN1cgO2p+yQFJ234XjZpFxpjhQw@mail.gmail.com>
From: Ryan Stone <rysto32@gmail.com>
To: freebsd-net <freebsd-net@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: pxeboot hangs if link bounces
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 18:53:06 -0000

On Wed, Jul 27, 2011 at 12:45 PM, Ryan Stone <rysto32@gmail.com> wrote:
> I'm going to try a binary search to narrow down what set of changes
> introduced the problem,

On that note, is there an faster way to cleanly build the boot code
than a full buildworld?  I can just make in sys/boot, but that picks
up the system's libstand and include files.

From owner-freebsd-net@FreeBSD.ORG  Thu Jul 28 14:53:36 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D63D6106566B
	for <freebsd-net@freebsd.org>; Thu, 28 Jul 2011 14:53:36 +0000 (UTC)
	(envelope-from adrian.chadd@gmail.com)
Received: from mail-gw0-f50.google.com (mail-gw0-f50.google.com [74.125.83.50])
	by mx1.freebsd.org (Postfix) with ESMTP id 978898FC15
	for <freebsd-net@freebsd.org>; Thu, 28 Jul 2011 14:53:36 +0000 (UTC)
Received: by gwj16 with SMTP id 16so2433247gwj.37
	for <freebsd-net@freebsd.org>; Thu, 28 Jul 2011 07:53:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=l99iBvsv+4ovo+IU/NTRcQiPCoxy2+Cc5YJcc64tFB8=;
	b=II7G5/vfOaNOLoEvUOPm1LButnY3eciBs4lOKYRVPZJuTLQQOilXZgS7WfAoedweEP
	hKW3sMOcnK5nXg/2nRTAsMhwr/dI8Iu176XPgnq28HB8ne/aaAE+FBADmgO3UMGpVG4V
	1hSphscDsM6cYXPRt+nDi7WMieIj2Wdn1vBgI=
MIME-Version: 1.0
Received: by 10.151.86.11 with SMTP id o11mr144000ybl.386.1311864814396; Thu,
	28 Jul 2011 07:53:34 -0700 (PDT)
Sender: adrian.chadd@gmail.com
Received: by 10.150.186.7 with HTTP; Thu, 28 Jul 2011 07:53:34 -0700 (PDT)
In-Reply-To: <CA+sBSoLCwQz+3seb8m=Nd-6YNd5MTxCYpJGjLJuzGScPR2vscg@mail.gmail.com>
References: <CA+sBSoLCwQz+3seb8m=Nd-6YNd5MTxCYpJGjLJuzGScPR2vscg@mail.gmail.com>
Date: Thu, 28 Jul 2011 22:53:34 +0800
X-Google-Sender-Auth: hsQL356vCCgOBaya6HZC4QkyEmk
Message-ID: <CAJ-VmokH3V7B6jUuroyNm4SxtOhEUMZLvy3_fVEm_xZPK+A08w@mail.gmail.com>
From: Adrian Chadd <adrian@freebsd.org>
To: Monthadar Al Jaberi <monthadar@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: freebsd-net@freebsd.org
Subject: Re: Clarification request about mesh_parse_meshpeering_action()
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2011 14:53:36 -0000

It's possible it's wrong?

Poke rpaulo@, see if he has some time to look at it?


Adrian

On 25 July 2011 20:39, Monthadar Al Jaberi <monthadar@gmail.com> wrote:
> Hi,
>
> I hope someone can explain to me the following:
>
> in ieee80211_mesh.c in function mesh_parse_meshpeering_action().
> The last argument uint8_t subtype is supposed to tell the type of Mesh
> Peer Managment Action frame.
>
> The weird thing is that inside the function subtype is checked if it
> is equal to IEEE80211_MESH_PEER_LINK_CLOSE and a bit lower in the code
> it is checked if it is not equal to
> IEEE80211_ACTION_MESHPEERING_CLOSE.
>
> These two enums represent two different things. One is an
> InformationElement while the other is an Action Frame that contains
> Information elements.
>
> How come?
>
> br,
> //Monthadar Al Jaberi
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>

From owner-freebsd-net@FreeBSD.ORG  Thu Jul 28 20:24:30 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 4A5C01065672
	for <freebsd-net@freebsd.org>; Thu, 28 Jul 2011 20:24:30 +0000 (UTC)
	(envelope-from jhb@freebsd.org)
Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42])
	by mx1.freebsd.org (Postfix) with ESMTP id 2160D8FC15
	for <freebsd-net@freebsd.org>; Thu, 28 Jul 2011 20:24:30 +0000 (UTC)
Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net
	[66.111.2.69])
	by cyrus.watson.org (Postfix) with ESMTPSA id 931CF46B2A;
	Thu, 28 Jul 2011 16:24:29 -0400 (EDT)
Received: from jhbbsd.localnet (unknown [209.249.190.124])
	by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3341E8A02C;
	Thu, 28 Jul 2011 16:24:29 -0400 (EDT)
From: John Baldwin <jhb@freebsd.org>
To: freebsd-net@freebsd.org
Date: Thu, 28 Jul 2011 16:24:28 -0400
User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; )
References: <CAFMmRNzc717KaFk-r8+uBYYKq=+ifQ-1SC0TUjJHKKyiBE5_Pw@mail.gmail.com>
	<CAFMmRNxJ1OpqO6ZLiZUmxqHCN1cgO2p+yQFJ234XjZpFxpjhQw@mail.gmail.com>
In-Reply-To: <CAFMmRNxJ1OpqO6ZLiZUmxqHCN1cgO2p+yQFJ234XjZpFxpjhQw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201107281624.28508.jhb@freebsd.org>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(bigwig.baldwin.cx); Thu, 28 Jul 2011 16:24:29 -0400 (EDT)
Cc: Ryan Stone <rysto32@gmail.com>
Subject: Re: pxeboot hangs if link bounces
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2011 20:24:30 -0000

On Wednesday, July 27, 2011 2:53:04 pm Ryan Stone wrote:
> On Wed, Jul 27, 2011 at 12:45 PM, Ryan Stone <rysto32@gmail.com> wrote:
> > I'm going to try a binary search to narrow down what set of changes
> > introduced the problem,
> 
> On that note, is there an faster way to cleanly build the boot code
> than a full buildworld?  I can just make in sys/boot, but that picks
> up the system's libstand and include files.

I think once you've done a make buildworld doing a make in sys/boot will 
prefer the libstand, etc. from the built world in /usr/obj rather than the 
ones on the currently running system.

-- 
John Baldwin

From owner-freebsd-net@FreeBSD.ORG  Fri Jul 29 08:07:58 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 7D7781065670;
	Fri, 29 Jul 2011 08:07:58 +0000 (UTC)
	(envelope-from maxim@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 564BB8FC08;
	Fri, 29 Jul 2011 08:07:58 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6T87wHF039974;
	Fri, 29 Jul 2011 08:07:58 GMT
	(envelope-from maxim@freefall.freebsd.org)
Received: (from maxim@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6T87vFp039970;
	Fri, 29 Jul 2011 08:07:57 GMT (envelope-from maxim)
Date: Fri, 29 Jul 2011 08:07:57 GMT
Message-Id: <201107290807.p6T87vFp039970@freefall.freebsd.org>
To: alex@infobit.ru, maxim@FreeBSD.org, freebsd-net@FreeBSD.org
From: maxim@FreeBSD.org
Cc: 
Subject: Re: kern/109308: [pppd] [panic] Multiple panics kernel ppp
	suspected [regression]
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2011 08:07:58 -0000

Synopsis: [pppd] [panic] Multiple panics kernel ppp suspected [regression]

State-Changed-From-To: open->closed
State-Changed-By: maxim
State-Changed-When: Fri Jul 29 08:07:19 UTC 2011
State-Changed-Why: 
pppd(8) and its kernel code was removed from the base
long time ago.

http://www.freebsd.org/cgi/query-pr.cgi?pr=109308

From owner-freebsd-net@FreeBSD.ORG  Fri Jul 29 09:00:27 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 378D8106564A
	for <freebsd-net@hub.freebsd.org>; Fri, 29 Jul 2011 09:00:27 +0000 (UTC)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 1E2978FC15
	for <freebsd-net@hub.freebsd.org>; Fri, 29 Jul 2011 09:00:27 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6T90QvK091149
	for <freebsd-net@freefall.freebsd.org>; Fri, 29 Jul 2011 09:00:26 GMT
	(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6T90QPo091148;
	Fri, 29 Jul 2011 09:00:26 GMT (envelope-from gnats)
Date: Fri, 29 Jul 2011 09:00:26 GMT
Message-Id: <201107290900.p6T90QPo091148@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: Maxim Konovalov <maxim.konovalov@gmail.com>
Cc: 
Subject: bin/121359
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Maxim Konovalov <maxim.konovalov@gmail.com>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2011 09:00:27 -0000

The following reply was made to PR bin/121359; it has been noted by GNATS.

From: Maxim Konovalov <maxim.konovalov@gmail.com>
To: bug-followup@freebsd.org
Cc:  
Subject: bin/121359
Date: Fri, 29 Jul 2011 12:53:19 +0400 (MSD)

 Try the following patch (ported from OpenBSD):
 
 Index: systems.c
 ===================================================================
 --- systems.c	(revision 224489)
 +++ systems.c	(working copy)
 @@ -64,9 +64,12 @@
    fclose(fp);
  }
 
 -/* Move string from ``from'' to ``to'', interpreting ``~'' and $.... */
 +/*
 + * Move string from ``from'' to ``to'', interpreting ``~'' and $....
 + * Returns NULL if string expansion failed due to lack of buffer space.
 + */
  const char *
 -InterpretArg(const char *from, char *to)
 +InterpretArg(const char *from, char *to, size_t tosiz)
  {
    char *ptr, *startto, *endto;
    struct passwd *pwd;
 @@ -76,12 +79,14 @@
 
    instring = 0;
    startto = to;
 -  endto = to + LINE_LEN - 1;
 +  endto = to + tosiz - 1;
 
    while(issep(*from))
      from++;
 
    while (*from != '\0') {
 +    if (to >= endto)
 +      return NULL;
      switch (*from) {
        case '"':
          instring = !instring;
 @@ -97,6 +102,8 @@
              *to++ = '\\';	/* Pass the escapes on, maybe skipping \# */
              break;
          }
 +        if (to >= endto)
 +          return NULL;
          *to++ = *from++;
          break;
        case '$':
 @@ -108,7 +115,7 @@
            if (ptr) {
              len = ptr - from - 2;
              if (endto - to < (int)len )
 -              len = endto - to;
 +              return NULL;
              if (len) {
                strncpy(to, from+2, len);
                to[len] = '\0';
 @@ -127,9 +134,13 @@
              *ptr++ = *from;
            *ptr = '\0';
          }
 +        if (to >= endto)
 +          return NULL;
          if (*to == '\0')
            *to++ = '$';
          else if ((env = getenv(to)) != NULL) {
 +          if (endto - to < (int)strlen(env))
 +            return NULL;
            strncpy(to, env, endto - to);
            *endto = '\0';
            to += strlen(to);
 @@ -142,19 +153,24 @@
          if (len == 0)
            pwd = getpwuid(ID0realuid());
          else {
 +          if (endto - to < (int)len)
 +            return NULL;
            strncpy(to, from, len);
            to[len] = '\0';
            pwd = getpwnam(to);
          }
 +        if (to >= endto)
 +          return NULL;
          if (pwd == NULL)
            *to++ = '~';
          else {
 +          if (endto - to < (int)strlen(pwd->pw_dir))
 +            return NULL;
            strncpy(to, pwd->pw_dir, endto - to);
            *endto = '\0';
            to += strlen(to);
            from += len;
          }
 -        endpwent();
          break;
 
        default:
 @@ -179,12 +195,16 @@
  #define CTRL_INCLUDE (1)
 
  static int
 -DecodeCtrlCommand(char *line, char *arg)
 +DecodeCtrlCommand(char *line, char *arg, size_t argsiz)
  {
    const char *end;
 
    if (!strncasecmp(line, "include", 7) && issep(line[7])) {
 -    end = InterpretArg(line+8, arg);
 +    end = InterpretArg(line+8, arg, argsiz);
 +    if (end == NULL) {
 +      log_Printf(LogWARN, "Failed to expand command '%s': too long for the destination buffer\n", line);
 +      return CTRL_UNKNOWN;
 +    }
      if (*end && *end != '#')
        log_Printf(LogWARN, "usage: !include filename\n");
      else
 @@ -218,7 +238,6 @@
          userok = 1;
          break;
        }
 -  endpwent();
 
    return 0;
  }
 @@ -353,7 +372,7 @@
        break;
 
      case '!':
 -      switch (DecodeCtrlCommand(cp+1, arg)) {
 +      switch (DecodeCtrlCommand(cp+1, arg, LINE_LEN)) {
        case CTRL_INCLUDE:
          log_Printf(LogCOMMAND, "%s: Including \"%s\"\n", filename, arg);
          n = ReadSystem(bundle, name, arg, prompt, cx, how);
 Index: systems.h
 ===================================================================
 --- systems.h	(revision 224489)
 +++ systems.h	(working copy)
 @@ -40,4 +40,4 @@
  extern void CloseSecret(FILE *);
  extern int AllowUsers(struct cmdargs const *);
  extern int AllowModes(struct cmdargs const *);
 -extern const char *InterpretArg(const char *, char *);
 +extern const char *InterpretArg(const char *, char *, size_t);
 Index: command.c
 ===================================================================
 --- command.c	(revision 224489)
 +++ command.c	(working copy)
 @@ -1139,7 +1134,11 @@
  {
    char buff2[LINE_LEN-offset];
 
 -  InterpretArg(buff, buff2);
 +  if (InterpretArg(buff, buff2, sizeof buff2) == NULL) {
 +    log_Printf(LogWARN, "Failed to expand command '%s': too long for the destination buffer\n", buff);
 +    return -1;
 +  }
 +
    strncpy(buff, buff2, LINE_LEN - offset - 1);
    buff[LINE_LEN - offset - 1] = '\0';
 
 %%%
 
 -- 
 Maxim Konovalov

From owner-freebsd-net@FreeBSD.ORG  Fri Jul 29 10:50:09 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 23FFB1065678
	for <freebsd-net@hub.freebsd.org>; Fri, 29 Jul 2011 10:50:09 +0000 (UTC)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id EFCF68FC12
	for <freebsd-net@hub.freebsd.org>; Fri, 29 Jul 2011 10:50:08 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6TAo8BE098627
	for <freebsd-net@freefall.freebsd.org>; Fri, 29 Jul 2011 10:50:08 GMT
	(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6TAo8dO098626;
	Fri, 29 Jul 2011 10:50:08 GMT (envelope-from gnats)
Date: Fri, 29 Jul 2011 10:50:08 GMT
Message-Id: <201107291050.p6TAo8dO098626@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: Sergey Kandaurov <pluknet@gmail.com>
Cc: 
Subject: Re: bin/136661: [patch] ndp(8) ignores -f option
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Sergey Kandaurov <pluknet@gmail.com>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2011 10:50:09 -0000

The following reply was made to PR bin/136661; it has been noted by GNATS.

From: Sergey Kandaurov <pluknet@gmail.com>
To: bug-followup@FreeBSD.org, melifaro@ipfw.ru
Cc:  
Subject: Re: bin/136661: [patch] ndp(8) ignores -f option
Date: Fri, 29 Jul 2011 14:47:28 +0400

 The '-f' argument parsing was (accidentally?) removed with KAME sync in 2003.
 
 "make command line argument parsing POSIX compliant."
 http://svn.freebsd.org/changeset/base/122615
 
 http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/ndp/ndp.c#rev1.92

From owner-freebsd-net@FreeBSD.ORG  Fri Jul 29 11:13:35 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 0E0731065670
	for <freebsd-net@freebsd.org>; Fri, 29 Jul 2011 11:13:35 +0000 (UTC)
	(envelope-from achilov-rn@askd.ru)
Received: from master.askd.ru (master.askd.ru [80.242.75.6])
	by mx1.freebsd.org (Postfix) with ESMTP id 6917F8FC0A
	for <freebsd-net@freebsd.org>; Fri, 29 Jul 2011 11:13:33 +0000 (UTC)
Received: from to-594.askd.gmbh (sentry [192.168.1.94])
	by master.askd.ru (8.14.5/8.14.5) with ESMTP id p6TBDUxc038152
	for <freebsd-net@freebsd.org>; Fri, 29 Jul 2011 18:13:32 +0700 (NOVT)
	(envelope-from achilov-rn@askd.ru)
From: "Rashid N. Achilov" <achilov-rn@askd.ru>
Organization: =?koi8-r?b?7+/v?= "=?koi8-r?b?4fMt88nT1MXNwQ==?=
	=?koi8-r?b?IOvPzdDMxcvT?="
To: freebsd-net@freebsd.org
Date: Fri, 29 Jul 2011 18:13:30 +0700
User-Agent: KMail/1.9.7
MIME-Version: 1.0
Content-Type: text/plain;
  charset="koi8-r"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201107291813.31024.achilov-rn@askd.ru>
Subject: kern/159103
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Achilov, Rashid" <achilov-rn@askd.ru>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2011 11:13:35 -0000

Additional data:

First. Tio obtain bug you should place "lo0" as latest member of network 
interfaces set, i.e:

network_interfaces="xl0 lo0" - bug will occured
network_interfaces="lo0 xl0" - bug will not occured
network_interfaces="xl0" - bug also will not occured

Second. To eliminate bug you must down interface and configure it manually 
again

What's a mess? I had have run with rc_debug=YES and the ONLY difference 
between "worked" and "non-worked" configuration is an order of network 
interfaces initialization! 
-- 
   With Best Regards.
   Rashid N. Achilov (RNA1-RIPE), JID: citycat4@jabber.infos.ru
   OOO "ACK" telecommunications administrator, e-mail: achilov-rn [at] askd.ru
   PGP: 83 CD E2 A7 37 4A D5 81 D6 D6 52 BF C9 2F 85 AF 97 BE CB 0A

From owner-freebsd-net@FreeBSD.ORG  Fri Jul 29 16:47:01 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B8FEC1065678
	for <freebsd-net@freebsd.org>; Fri, 29 Jul 2011 16:47:01 +0000 (UTC)
	(envelope-from jlott@averesystems.com)
Received: from zimbra.averesystems.com
	(75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245])
	by mx1.freebsd.org (Postfix) with ESMTP id 896708FC17
	for <freebsd-net@freebsd.org>; Fri, 29 Jul 2011 16:47:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
	by zimbra.averesystems.com (Postfix) with ESMTP id A1F3F8BC009;
	Fri, 29 Jul 2011 12:49:46 -0400 (EDT)
X-Virus-Scanned: amavisd-new at averesystems.com
Received: from zimbra.averesystems.com ([127.0.0.1])
	by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id TMZbZXTuov7s; Fri, 29 Jul 2011 12:49:45 -0400 (EDT)
Received: from jlott-mac.arriad.com (fw.arriad.com [10.0.0.16])
	by zimbra.averesystems.com (Postfix) with ESMTPSA id E0C508BC008;
	Fri, 29 Jul 2011 12:49:44 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jeremiah Lott <jlott@averesystems.com>
In-Reply-To: <1931983408.909766.1311369086133.JavaMail.root@erie.cs.uoguelph.ca>
Date: Fri, 29 Jul 2011 12:46:56 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE5AEDA6-052E-42BD-85D7-60AFF7EC1593@averesystems.com>
References: <1931983408.909766.1311369086133.JavaMail.root@erie.cs.uoguelph.ca>
To: Rick Macklem <rmacklem@uoguelph.ca>
X-Mailer: Apple Mail (2.1084)
Cc: freebsd-net@freebsd.org
Subject: Re: LOR with nfsclient "sillyrename"
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2011 16:47:01 -0000


On Jul 22, 2011, at 5:11 PM, Rick Macklem wrote:

> Please try the attached patch (which is also at):
>  http://people.freebsd.org/~rmacklem/oldsilly.patch
>  http://people.freebsd.org/~rmacklem/newsilly.patch
> (for the old and new clients in -current, respectively)
>=20
> - I think oldsilly.patch should apply to the 7.n kernel
>  sources, although you might have to do the edit by hand?

It applied with minimal futzing.

> Please let me know how testing goes with it, rick

Unfortunately we've never reproduced the original problem in the lab.  =
Only in the field under heavy stress.  I did build a kernel with the =
patch and run it under some of our tests, it seems to work correctly.  =
We'll continue to test it, but I wanted to give you an update.  Thanks a =
lot for your help.

  Jeremiah Lott
  Avere Systems


From owner-freebsd-net@FreeBSD.ORG  Fri Jul 29 19:14:47 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 6D0401065672;
	Fri, 29 Jul 2011 19:14:47 +0000 (UTC)
	(envelope-from julian@freebsd.org)
Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16])
	by mx1.freebsd.org (Postfix) with ESMTP id 3AFAE8FC12;
	Fri, 29 Jul 2011 19:14:46 +0000 (UTC)
Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137])
	(authenticated bits=0)
	by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p6TJEdKa048641
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 29 Jul 2011 12:14:43 -0700 (PDT)
	(envelope-from julian@freebsd.org)
Message-ID: <4E330699.9000002@freebsd.org>
Date: Fri, 29 Jul 2011 12:14:33 -0700
From: Julian Elischer <julian@freebsd.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US;
	rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: "Alexander V. Chernikov" <melifaro@ipfw.ru>
References: <A718ADB2-EC52-462C-A114-85053F1B2E55@dudu.ro>	<20110717.004248.48765964696292481.hrs@allbsd.org>
	<4E21BA0B.6080800@ipfw.ru>
In-Reply-To: <4E21BA0B.6080800@ipfw.ru>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-hackers@freebsd.org, "Bjoern A. Zeeb" <bz@freebsd.org>,
	Hiroki Sato <hrs@freebsd.org>, dudu@dudu.ro, freebsd-net@freebsd.org
Subject: Re: FIB separation
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2011 19:14:47 -0000

On 7/16/11 9:19 AM, Alexander V. Chernikov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hiroki Sato wrote:
>> Vlad Galu<dudu@dudu.ro>  wrote
>>    in<A718ADB2-EC52-462C-A114-85053F1B2E55@dudu.ro>:
>>
>> du>  Hello,
>> du>
>> du>  A couple of years ago, Stef Walter proposed a patch[1] that enforced
>> du>  the scope of routing messages. The general consesus was that the best
>> du>  approach would be the OpenBSD way - transporting the FIB number in the
>> du>  message and letting the user applications filter out unwanted
>> du>  messages.
>> du>
>> du>  Are there any plans to tackle this before 9.0?
>>
>>   I am looking into this and investigating other possible extensions in
>>   rtsock messages such as addition of a fib member to rt_msghdr.  I am
>>   not sure it can be done before 9.0, though...
> Actually there were an off-list discussion with bz@ and julian@ about
> interface fibs and rtsock changes several weeks ago.
>
> Initial messages:
> http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029040.html
>
> I've got 3 different patches:
> 1) straight forwarded kern/134931 fix (no fib in rtsock, no breaking
> ABI, send to bz@)
just got back from vacation in hungary so catching up...:

Didn't he commit it?   bz??

> 2) adding fib in rtsock with rtsock versioning and other ABI keeping tricks
> 3) adding special RTA which can contain TLV pairs, with single defined
> TLV with routing socket
>
> As a result of discussion, first patch was sent to bz@. Since patches
> from kern/134931 are outdated attaching it here.


From owner-freebsd-net@FreeBSD.ORG  Fri Jul 29 19:54:24 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 1E7D51065676;
	Fri, 29 Jul 2011 19:54:24 +0000 (UTC)
	(envelope-from julian@freebsd.org)
Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16])
	by mx1.freebsd.org (Postfix) with ESMTP id EFEC58FC1B;
	Fri, 29 Jul 2011 19:54:23 +0000 (UTC)
Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137])
	(authenticated bits=0)
	by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p6TJRA2t048676
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 29 Jul 2011 12:27:11 -0700 (PDT)
	(envelope-from julian@freebsd.org)
Message-ID: <4E330989.7030409@freebsd.org>
Date: Fri, 29 Jul 2011 12:27:05 -0700
From: Julian Elischer <julian@freebsd.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US;
	rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Gleb Smirnoff <glebius@freebsd.org>
References: <20110714154457.GI70776@FreeBSD.org>
In-Reply-To: <20110714154457.GI70776@FreeBSD.org>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Cc: gnn@freebsd.org, bz@freebsd.org, rwatson@freebsd.org, net@freebsd.org
Subject: Re: m_pkthdr.rcvif dangling pointer problem
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2011 19:54:24 -0000

On 7/14/11 8:44 AM, Gleb Smirnoff wrote:
>    Hi!
>
>    This problem is definitely known and is as old as network stack
> is parallel. Those, who know the problem may skip to next paragraph.
> Short description is the following: every mbuf that is allocated in
> an interface receive procedure has a field where a pointer to the
> corresponding struct ifnet is stored. Everything is okay, until you
> are running a box, where configuration of interfaces is changing
> rapidly, for example a PPP access concentrator. Utilizing any facility
> that can delay packet processing for example netgraph(4) or dummynet(4)
> would make probability of crash much bigger. Running INVARIANTS kernel
> would crash a box with dummynet and disappearing interfaces in a few
> minutes.
>
>    I see three approaches to this problem:
>
>    1) Every m_pkthdr.rcvif should if_ref() the interface. Releasing
> references can be done in the mbuf allocator: mb_dtor_mbuf(),
> mb_dtor_pack(). I'm afraid this approach would degrate performance,
> since adding at least a couple of atomic ops on every mbuf for its
> lifetime. That is +2 atomic ops per packet.

I did that in the 3.x timeframe in a branch.. it's probably in the cvs 
tree still but was expensive.

better idea would be to use ifnet number and a generation number...


>    2) kib@ suggested to allocate ifnets from a UMA_ZONE_NOFREE zone.
> I've made a compilable&  working patch:
>
> http://people.freebsd.org/~glebius/patches/ifnet.no_free
>
> But on second though I find this a bad idea, this is just fooling
> of INVARIANTS. Yes, we avoid thrashing of freed memory and rewriting
> it by some other kernel allocation. But still out pointer point to
> invalid ifnet. Even, if we make a check for IFF_DYING flag, we still
> can not guarantee that an interface had been re-allocated for a new
> instance. This would be not a panic condition, but subtle bugs in
> firewalls.
>
>    3) As we now have a straight if_index table that can grow, what about
> storing the if_index in the m_pkthdr? Lookup of interface by index
> is fast enough if done lockless. Doing it lockless isn't perfect, but
> better than current pointer dereferncing. Optionally it could be
> done with locking and with putting a reference. To avoid situation
> with with getting to a re-allocated interface with the same index,
> we can use a unique cookie, that is incremented in if_alloc().
> Smth like:
>
> struct ifnet *
> mbuf_rcvif(struct mbuf *m)
> {
>          struct ifnet *ifp;
>
>          M_ASSERTPKTHDR(m);
>
>          if (m->m_pkthdr.rcvif_idx == 0)
>                  return (NULL);
>
>          ifp = ifnet_byindex_locked(m->m_pkthdr.rcvif_idx);
>          if (ifp == NULL)
>                  return (NULL);
>          if (ifp->if_unique != m->m_pkthdr.rcvif_unique)
>                  return (NULL);
>
>          return (ifp);
> }
>
> struct ifnet *
> mbuf_rcvif_ref(struct mbuf *m)
> {
>          struct ifnet *ifp;
>
>          M_ASSERTPKTHDR(m);
>
>          if (m->m_pkthdr.rcvif_idx == 0)
>                  return (NULL);
>
>          ifp = ifnet_byindex_ref(m->m_pkthdr.rcvif_idx);
>          if (ifp == NULL)
>                  return (NULL);
>          if (ifp->if_unique != m->m_pkthdr.rcvif_unique) {
>                  if_rele(ifp);
>                  return (NULL);
>          }
>
>          return (ifp);
> }
>
> The size of struct mbuf isn't going to change on amd64:
>
> @@ -111,7 +111,8 @@
>    * Record/packet header in first mbuf of chain; valid only if M_PKTHDR is set.
>    */
>   struct pkthdr {
> -       struct ifnet    *rcvif;         /* rcv interface */
> +       uint32_t         rcvif_idx;     /* rcv interface index */
> +       uint32_t         rcvif_unique;  /* rcv interface unique id */
>
> A proof-of-concept patch is available here:
>
> http://people.freebsd.org/~glebius/patches/pkthdr.rcvif_idx
>
> It doesn't cover entire kernel, LINT won't compile. It covers kern, netinet,
> netinet6, several interface drivers and netgraph.
>
> One of the problems is ongoing namespace pollution: not all code that include
> mbuf.h includes if_var.h and vice versa. I've cut ifnet from m_devget(), but
> my new function do declare it in parameter list :(. To deal with that I had
> to declare functions in mbuf.h but implement them in if.c.
>
> Other problem is net80211 code that abuses the rcvif pointer in mbuf packet
> header for its own purposes casting it to private type. This can be fixed
> utilizing mbuf_tags(9), I think. I haven't made this yet, that's why LINT
> doesn't compile.
>
>    Comments are requested!
>
>    Any alternative ideas on solving the problem are welcome!
>


From owner-freebsd-net@FreeBSD.ORG  Fri Jul 29 20:42:36 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A3764106564A;
	Fri, 29 Jul 2011 20:42:36 +0000 (UTC)
	(envelope-from linimon@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 7B6708FC18;
	Fri, 29 Jul 2011 20:42:36 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6TKgaxq051305;
	Fri, 29 Jul 2011 20:42:36 GMT
	(envelope-from linimon@freefall.freebsd.org)
Received: (from linimon@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6TKgaTu051301;
	Fri, 29 Jul 2011 20:42:36 GMT (envelope-from linimon)
Date: Fri, 29 Jul 2011 20:42:36 GMT
Message-Id: <201107292042.p6TKgaTu051301@freefall.freebsd.org>
To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org
From: linimon@FreeBSD.org
Cc: 
Subject: Re: kern/159294: [em] em watchdog timeouts
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2011 20:42:36 -0000

Old Synopsis: em watchdog timeouts
New Synopsis: [em] em watchdog timeouts

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Jul 29 20:42:18 UTC 2011
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=159294

From owner-freebsd-net@FreeBSD.ORG  Sat Jul 30 19:58:40 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 84DB9106564A
	for <freebsd-net@freebsd.org>; Sat, 30 Jul 2011 19:58:40 +0000 (UTC)
	(envelope-from prvs=11856fad44=brian@Awfulhak.org)
Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9])
	by mx1.freebsd.org (Postfix) with ESMTP id 46B5C8FC0C
	for <freebsd-net@freebsd.org>; Sat, 30 Jul 2011 19:58:39 +0000 (UTC)
Received: from pd6ml1no-ssvc.prod.shaw.ca ([10.0.153.160])
	by pd7mo1no-svcs.prod.shaw.ca with ESMTP; 30 Jul 2011 13:43:37 -0600
X-Cloudmark-SP-Filtered: true
X-Cloudmark-SP-Result: v=1.1 cv=sma64emKALigICJU+V2L7RL3kPAolu7RCFSKDgo279k=
	c=1 sm=1
	a=wom5GMh1gUkA:10 a=lON2U-l0JHgA:10 a=dBRESv0yCI8A:10 a=BLceEmwcHowA:10
	a=kj9zAlcOel0A:10 a=cmB/9TsswV7PJ0tytqGp1Q==:17 a=MMwg4So0AAAA:8
	a=6I5d2MoRAAAA:8 a=GLdqeF5yD0_f_m2HdWsA:9 a=WfMR9K_jZqMEUEb2fJMA:7
	a=CjuIK1q_8ugA:10 a=WJ3hkfHDukgA:10 a=SV7veod9ZcQA:10
	a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Received: from unknown (HELO vstore.lan.Awfulhak.org) ([70.79.183.1])
	by pd6ml1no-dmz.prod.shaw.ca with ESMTP; 30 Jul 2011 13:43:37 -0600
Received: from vstore.lan.Awfulhak.org (localhost.localdomain [127.0.0.1])
	by localhost (Email Security Appliance) with SMTP id
	98BA315BEFD_E345EE7B; Sat, 30 Jul 2011 19:43:35 +0000 (GMT)
Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1])
	by vstore.lan.Awfulhak.org (Sophos Email Appliance) with ESMTP id
	3BDE815BE3C_E345EE5F; Sat, 30 Jul 2011 19:43:32 +0000 (GMT)
Received: from thong.lan.Awfulhak.org (thong.lan.Awfulhak.org [172.16.0.31])
	by gw.Awfulhak.org (8.14.5/8.14.5) with ESMTP id p6UJhXjp027133;
	Sat, 30 Jul 2011 12:43:33 -0700 (PDT)
	(envelope-from brian@lan.Awfulhak.org)
Received: from thong.lan.Awfulhak.org (localhost [127.0.0.1])
	by thong.lan.Awfulhak.org (8.14.5/8.14.5) with ESMTP id p6UJhXkM016372; 
	Sat, 30 Jul 2011 12:43:33 -0700 (PDT)
	(envelope-from brian@thong.lan.Awfulhak.org)
Received: (from brian@localhost)
	by thong.lan.Awfulhak.org (8.14.5/8.14.5/Submit) id p6UJhWOV016371;
	Sat, 30 Jul 2011 12:43:32 -0700 (PDT) (envelope-from brian)
Date: Sat, 30 Jul 2011 12:43:32 -0700
From: Brian Somers <brian@freebsd.org>
To: "Rashid N. Achilov" <achilov-rn@askd.ru>
Message-ID: <20110730194332.GI88174@thong.lan.Awfulhak.org>
References: <201107221454.11469.achilov-rn@askd.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201107221454.11469.achilov-rn@askd.ru>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: freebsd-net@freebsd.org
Subject: Re: strange ping on local address
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jul 2011 19:58:40 -0000

On Fri, Jul 22, 2011 at 02:54:11PM +0700, Rashid N. Achilov wrote:
> When I try to ping local interface - ping missed! When I try to ping this 
> interface with -S key (specified the same address) - working. What's a bug? 
> In RELENG_7 worked.
> 
> local interface on box:
> em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 
> 1500        
> options=219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC>
>         ether 00:xx:xx:xx:xx:xx
>         inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>         media: Ethernet autoselect (100baseTX <full-duplex>)
>         status: active
> 
> ping ordinary:
> master:[root] 105>ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
> ^C
> --- 192.168.1.1 ping statistics ---
> 2 packets transmitted, 0 packets received, 100.0% packet loss
> 
> ping with -S key:
> master:[root] 106>ping -S 192.168.1.1 192.168.1.1
> PING 192.168.1.1 (192.168.1.1) from 192.168.1.1: 56 data bytes
> 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.022 ms
> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.030 ms
> ^C
> --- 192.168.1.1 ping statistics ---
> 2 packets transmitted, 2 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 0.022/0.026/0.030/0.004 ms
> 
> master:[root] 103>uname -a
> FreeBSD master.askd.ru 8.2-STABLE FreeBSD 8.2-STABLE #1: Fri Jul 15 18:23:18
> NOVST 2011     root@master-new.askd.gmbh:/usr/obj/usr/src/sys/Master  i386
> 
> What's a terrible? I'm understand, that ping "itself" is rarely situation, but 
> it worked in 7.x! 

What happens if you "route delete 192.168.1.1" and then try the ping
without using -S?

-- 
Brian Somers                                          <brian@Awfulhak.org>
Don't _EVER_ lose your sense of humour !               <brian@FreeBSD.org>