From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 07:21:44 2008
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 E8A4A106564A
for <freebsd-net@freebsd.org>; Sun, 30 Mar 2008 07:21:44 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su
[213.184.65.80])
by mx1.freebsd.org (Postfix) with ESMTP id 53F6E8FC17
for <freebsd-net@freebsd.org>; Sun, 30 Mar 2008 07:21:44 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1])
by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m2U7Lfkc035844;
Sun, 30 Mar 2008 15:21:41 +0800 (KRAST)
(envelope-from eugen@www.svzserv.kemerovo.su)
Received: (from eugen@localhost)
by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m2U7LbqW035837;
Sun, 30 Mar 2008 15:21:37 +0800 (KRAST) (envelope-from eugen)
Date: Sun, 30 Mar 2008 15:21:37 +0800
From: Eugene Grosbein <eugen@kuzbass.ru>
To: Brooks Davis <brooks@freebsd.org>
Message-ID: <20080330072137.GA35435@svzserv.kemerovo.su>
References: <47EE42C8.3070100@quip.cz>
<20080329204344.GA66910@lor.one-eyed-alien.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080329204344.GA66910@lor.one-eyed-alien.net>
User-Agent: Mutt/1.4.2.3i
Cc: FreeBSD-Net mailing list <freebsd-net@freebsd.org>,
Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected?
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, 30 Mar 2008 07:21:45 -0000
On Sat, Mar 29, 2008 at 03:43:44PM -0500, Brooks Davis wrote:
> > I was using following command in FreeBSD 6.2:
> > # ifconfig lo1 create inet 172.16.16.2 netmask 255.255.255.0
> > In FreeBSD 7.0 I got an error:
> > # ifconfig lo1 create inet 172.16.16.2 netmask 255.255.255.0
> > ifconfig: inet: bad value
> > But it is working splitted in to two commands:
> > # ifconfig lo1 create
> > # ifconfig lo1 inet 172.16.16.2 netmask 255.255.255.0
> > Is this expected behavior or should I file a PR?
> This expected. There's some argument it's wrong, but filing a PR is
> unlikely to cause it to change any time soon.
Why? The same with creating gif-tunnel, now I need to invoke ifconfig
twice, once for 'create' and once for other tunnel parameters,
whereas for RELENG_6 this works: 'ifconfig gif0 create tunnel 1.1.1.1 2.2.2.2'
This breaks existing setups/scripts. This is POLA issue.
Why was it broken?
Eugene Grosbein
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 09:28:18 2008
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 8D0BE1065671
for <freebsd-net@freebsd.org>; Sun, 30 Mar 2008 09:28:18 +0000 (UTC)
(envelope-from mav@FreeBSD.org)
Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121])
by mx1.freebsd.org (Postfix) with ESMTP id 14CC38FC1C
for <freebsd-net@freebsd.org>; Sun, 30 Mar 2008 09:28:17 +0000 (UTC)
(envelope-from mav@FreeBSD.org)
X-Spam-Flag: SKIP
X-Spam-Yversion: Spamooborona-2.1.0
Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2])
by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14)
with ESMTPA id 99970234; Sun, 30 Mar 2008 11:28:15 +0300
Message-ID: <47EF4F18.502@FreeBSD.org>
Date: Sun, 30 Mar 2008 11:28:08 +0300
From: Alexander Motin <mav@FreeBSD.org>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc:
Subject: Multiple netgraph threads
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, 30 Mar 2008 09:28:18 -0000
Hi.
I have implemented a patch (for the HEAD) making netgraph to use several
own threads for event queues processing instead of using single swinet.
It should significantly improve netgraph SMP scalability on complicated
workloads that require queueing by implementation (PPTP/L2TP) or stack
size limitations. It works perfectly on my UP system, showing results
close to original or even a bit better. I have no real SMP test server
to measure real scalability, but test on HTT CPU works fine, utilizing
both virtual cores at the predictable level.
Reviews and feedbacks are welcome.
URL: http://people.freebsd.org/~mav/netgraph.threads.patch
--
Alexander Motin
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 09:46:47 2008
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 1E967106566B;
Sun, 30 Mar 2008 09:46:47 +0000 (UTC) (envelope-from bz@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
[IPv6:2001:4f8:fff6::28])
by mx1.freebsd.org (Postfix) with ESMTP id F2C6D8FC18;
Sun, 30 Mar 2008 09:46:46 +0000 (UTC) (envelope-from bz@FreeBSD.org)
Received: from freefall.freebsd.org (bz@localhost [127.0.0.1])
by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2U9kkQl015207;
Sun, 30 Mar 2008 09:46:46 GMT (envelope-from bz@freefall.freebsd.org)
Received: (from bz@localhost)
by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2U9kks0015203;
Sun, 30 Mar 2008 09:46:46 GMT (envelope-from bz)
Date: Sun, 30 Mar 2008 09:46:46 GMT
Message-Id: <200803300946.m2U9kks0015203@freefall.freebsd.org>
To: alephis@gmail.com, bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org
From: bz@FreeBSD.org
Cc:
Subject: Re: kern/122065: [gre] gre over ipsec not working
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, 30 Mar 2008 09:46:47 -0000
Synopsis: [gre] gre over ipsec not working
State-Changed-From-To: open->feedback
State-Changed-By: bz
State-Changed-When: Sun Mar 30 09:46:04 UTC 2008
State-Changed-Why:
I am exchanging mails with the submitter to narrow down the problem.
Responsible-Changed-From-To: freebsd-net->bz
Responsible-Changed-By: bz
Responsible-Changed-When: Sun Mar 30 09:46:04 UTC 2008
Responsible-Changed-Why:
I am exchanging mails with the submitter to narrow down the problem.
http://www.freebsd.org/cgi/query-pr.cgi?pr=122065
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 09:49:29 2008
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 2E117106566B;
Sun, 30 Mar 2008 09:49:29 +0000 (UTC) (envelope-from mav@FreeBSD.org)
Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121])
by mx1.freebsd.org (Postfix) with ESMTP id 73A788FC12;
Sun, 30 Mar 2008 09:49:28 +0000 (UTC) (envelope-from mav@FreeBSD.org)
X-Spam-Flag: SKIP
X-Spam-Yversion: Spamooborona-2.1.0
Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2])
by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14)
with ESMTPA id 99987913; Sun, 30 Mar 2008 12:49:27 +0300
Message-ID: <47EF6226.3090808@FreeBSD.org>
Date: Sun, 30 Mar 2008 12:49:26 +0300
From: Alexander Motin <mav@FreeBSD.org>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Hans Petter Selasky <hselasky@c2i.net>
References: <47EF4F18.502@FreeBSD.org> <200803301114.43336.hselasky@c2i.net>
In-Reply-To: <200803301114.43336.hselasky@c2i.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org>
Subject: Re: Multiple netgraph threads
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, 30 Mar 2008 09:49:29 -0000
Hans Petter Selasky wrote:
> Have you thought about nodes that lock the same mutex must be run on the same
> thread else for example one thread will run while another will just waits for
> a mutex ?
Usually different nodes does not share data, keeping them inside
node/hook private data, so I don't see problem here. It is possible that
two messages will be queued to the same node at same time, but to fulfil
serialization requirements each node queue processed only by one thread
at a time, so there is no place for congestion.
> You can achieve this by grouping nodes into a tree, and the node at the top of
> the tree decides on which thread the nodes in the tree should be run.
Netgraph graphs usually not linear and it is from hard to impossible to
predict the way execution will go and the locks that may be congested.
Including usually big number of nodes and usually small lock time,
congestion probability IMHO looks insignificant comparing to additional
logic overhead. If some node/hook needs big lock time it may be instead
declared as FORCE_WRITER to enqueue congested messages instead of
blocking them (such way now implemented all existing ppp
compression/encryption nodes).
--
Alexander Motin
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 10:13:45 2008
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 1F6BA106566B
for <freebsd-net@freebsd.org>; Sun, 30 Mar 2008 10:13:45 +0000 (UTC)
(envelope-from hselasky@c2i.net)
Received: from swip.net (mailfe05.swip.net [212.247.154.129])
by mx1.freebsd.org (Postfix) with ESMTP id B51648FC13
for <freebsd-net@freebsd.org>; Sun, 30 Mar 2008 10:13:44 +0000 (UTC)
(envelope-from hselasky@c2i.net)
X-Cloudmark-Score: 0.000000 []
Received: from [62.113.132.89] (account mc467741@c2i.net [62.113.132.89]
verified) by mailfe05.swip.net (CommuniGate Pro SMTP 5.1.13)
with ESMTPA id 773504940; Sun, 30 Mar 2008 11:13:33 +0200
From: Hans Petter Selasky <hselasky@c2i.net>
To: freebsd-hackers@freebsd.org,
FreeBSD Net <freebsd-net@freebsd.org>
Date: Sun, 30 Mar 2008 11:14:42 +0200
User-Agent: KMail/1.9.7
References: <47EF4F18.502@FreeBSD.org>
In-Reply-To: <47EF4F18.502@FreeBSD.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200803301114.43336.hselasky@c2i.net>
Cc: Alexander Motin <mav@freebsd.org>
Subject: Re: Multiple netgraph threads
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, 30 Mar 2008 10:13:45 -0000
Hi,
Have you thought about nodes that lock the same mutex must be run on the same
thread else for example one thread will run while another will just waits for
a mutex ?
You can achieve this by grouping nodes into a tree, and the node at the top of
the tree decides on which thread the nodes in the tree should be run.
How does your patch handle this ?
Also see recent discussion about multithreaded callouts
on "freebsd-arch@freebsd.org". Subject "timeout/callout small step forward".
--HPS
On Sunday 30 March 2008, Alexander Motin wrote:
> Hi.
>
> I have implemented a patch (for the HEAD) making netgraph to use several
> own threads for event queues processing instead of using single swinet.
> It should significantly improve netgraph SMP scalability on complicated
> workloads that require queueing by implementation (PPTP/L2TP) or stack
> size limitations. It works perfectly on my UP system, showing results
> close to original or even a bit better. I have no real SMP test server
> to measure real scalability, but test on HTT CPU works fine, utilizing
> both virtual cores at the predictable level.
>
> Reviews and feedbacks are welcome.
>
> URL: http://people.freebsd.org/~mav/netgraph.threads.patch
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 10:22:44 2008
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 0BB43106564A
for <freebsd-net@freebsd.org>; Sun, 30 Mar 2008 10:22:44 +0000 (UTC)
(envelope-from bms@FreeBSD.org)
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com
[66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id C6B7F8FC15
for <freebsd-net@freebsd.org>; Sun, 30 Mar 2008 10:22:43 +0000 (UTC)
(envelope-from bms@FreeBSD.org)
Received: from compute1.internal (compute1.internal [10.202.2.41])
by out1.messagingengine.com (Postfix) with ESMTP id 49582E3E2C;
Sun, 30 Mar 2008 06:22:43 -0400 (EDT)
Received: from heartbeat2.messagingengine.com ([10.202.2.161])
by compute1.internal (MEProxy); Sun, 30 Mar 2008 06:22:43 -0400
X-Sasl-enc: kd8Q+WAyl+CUPO5ysHWk+0QFFO08Si4G28ukJkQCq7gy 1206872562
Received: from empiric.lon.incunabulum.net
(82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254])
by mail.messagingengine.com (Postfix) with ESMTPSA id 8793024B51;
Sun, 30 Mar 2008 06:22:42 -0400 (EDT)
Message-ID: <47EF69F0.1050304@FreeBSD.org>
Date: Sun, 30 Mar 2008 11:22:40 +0100
From: "Bruce M. Simpson" <bms@FreeBSD.org>
User-Agent: Thunderbird 2.0.0.9 (X11/20080207)
MIME-Version: 1.0
To: Eugene Grosbein <eugen@kuzbass.ru>
References: <47EE42C8.3070100@quip.cz> <20080329204344.GA66910@lor.one-eyed-alien.net>
<20080330072137.GA35435@svzserv.kemerovo.su>
In-Reply-To: <20080330072137.GA35435@svzserv.kemerovo.su>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: FreeBSD-Net mailing list <freebsd-net@freebsd.org>,
Brooks Davis <brooks@freebsd.org>, Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected?
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, 30 Mar 2008 10:22:44 -0000
Eugene Grosbein wrote:
> On Sat, Mar 29, 2008 at 03:43:44PM -0500, Brooks Davis wrote:
>
>
>>> I was using following command in FreeBSD 6.2:
>>> # ifconfig lo1 create inet 172.16.16.2 netmask 255.255.255.0
>>> In FreeBSD 7.0 I got an error:
>>> # ifconfig lo1 create inet 172.16.16.2 netmask 255.255.255.0
>>> ifconfig: inet: bad value
>>> But it is working splitted in to two commands:
>>> # ifconfig lo1 create
>>> # ifconfig lo1 inet 172.16.16.2 netmask 255.255.255.0
>>> Is this expected behavior or should I file a PR?
>>>
>> This expected. There's some argument it's wrong, but filing a PR is
>> unlikely to cause it to change any time soon.
>>
>
> Why? The same with creating gif-tunnel, now I need to invoke ifconfig
> twice, once for 'create' and once for other tunnel parameters,
> whereas for RELENG_6 this works: 'ifconfig gif0 create tunnel 1.1.1.1 2.2.2.2'
>
> This breaks existing setups/scripts. This is POLA issue.
> Why was it broken?
>
I don't know why or how this has happened, however, given the complexity
of the command line grammar which ifconfig is expected to parse, our
choices are limited, unless someone(tm) is willing to come along and
implement a full parser in ifconfig.
I investigated this some years ago and frankly didn't get anywhere, one
of the constraints was that Sam wanted to modularize the ifconfig code,
with a view to future dynamic loading -- as such, this places
restrictions on the kind of parser which can be used.
There is valid argument that we should not do this, as ifconfig is a
tool which sits in the base system, and should be kept simple and
therefore small.
On the other hand, there's also the argument that as ifconfig's syntax
has grown considerably over the years, that we should go ahead and add a
parser anyway.
In the absence of a full-blown parser, I'm comfortable with "ifconfig
<cloner> create" being a separate operation, which preferably throws an
error if other commands are included with it, and understand why these
limitations apply.
cheers
BMS
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 10:34:21 2008
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 E77D3106566B;
Sun, 30 Mar 2008 10:34:21 +0000 (UTC)
(envelope-from rwatson@FreeBSD.org)
Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42])
by mx1.freebsd.org (Postfix) with ESMTP id C82AE8FC16;
Sun, 30 Mar 2008 10:34:21 +0000 (UTC)
(envelope-from rwatson@FreeBSD.org)
Received: from fledge.watson.org (fledge.watson.org [209.31.154.41])
by cyrus.watson.org (Postfix) with ESMTP id 59F6946B54;
Sun, 30 Mar 2008 06:34:21 -0400 (EDT)
Date: Sun, 30 Mar 2008 11:34:21 +0100 (BST)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: Alexander Motin <mav@FreeBSD.org>
In-Reply-To: <47EF4F18.502@FreeBSD.org>
Message-ID: <20080330112846.Y5921@fledge.watson.org>
References: <47EF4F18.502@FreeBSD.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org>
Subject: Re: Multiple netgraph threads
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, 30 Mar 2008 10:34:22 -0000
On Sun, 30 Mar 2008, Alexander Motin wrote:
> I have implemented a patch (for the HEAD) making netgraph to use several own
> threads for event queues processing instead of using single swinet. It
> should significantly improve netgraph SMP scalability on complicated
> workloads that require queueing by implementation (PPTP/L2TP) or stack size
> limitations. It works perfectly on my UP system, showing results close to
> original or even a bit better. I have no real SMP test server to measure
> real scalability, but test on HTT CPU works fine, utilizing both virtual
> cores at the predictable level. Reviews and feedbacks are welcome. URL:
> http://people.freebsd.org/~mav/netgraph.threads.patch
FYI, you might be interested in some similar work I've been doing in the
rwatson_netisr branch in Perforce, which:
(1) Adds per-CPU netisr threads
(2) Introduces inpcb affinity, assigned using a hash on the tuple (similar to
RSS) to load balance
(3) Moves to rwlock use on inpcb and pcbinfo, used extensively in UDP and
somewhat in TCP
My initial leaning would be that we would like to avoid adding too many more
threads that will do per-packet work, as that leads to excessive context
switching. I have similar worries regarding ithreads, and I suspect (hope?)
we will have an active discussion of this at the BSDCan developer summit.
BTW, I'd be careful with the term "should" and SMP -- often times scalability
to multiple cores involves not just introducing the opportunity for
parallelism, but also significantly refining or changing the data model to
allow that parallelism to be efficiently used. Right now, despite loopback
performance being a bottleneck with a single netisr thread, we're not seeing a
performance improvement for database workloads over loopback with multiple
netisr threads. We're diagnosing this still -- initially it appeared to be
tcbinfo lock contention (not surprising), but moving to read locking on
tcbinfo didn't appear to help (except in reducing contention leading to more
idle time rather than more progress). The current theory is that something
about the approach isn't working well with the scheduler but we need to
analyze the scheduler traces further. My recommendation would be that you do
a fairly thorough performance evaluation before committing.
Robert N M Watson
Computer Laboratory
University of Cambridge
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 10:45:29 2008
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 D962A1065674;
Sun, 30 Mar 2008 10:45:29 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su
[213.184.65.80])
by mx1.freebsd.org (Postfix) with ESMTP id 4566C8FC25;
Sun, 30 Mar 2008 10:45:28 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1])
by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m2UAjPC8057611;
Sun, 30 Mar 2008 18:45:26 +0800 (KRAST)
(envelope-from eugen@www.svzserv.kemerovo.su)
Received: (from eugen@localhost)
by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m2UAjPIk057610;
Sun, 30 Mar 2008 18:45:25 +0800 (KRAST) (envelope-from eugen)
Date: Sun, 30 Mar 2008 18:45:25 +0800
From: Eugene Grosbein <eugen@kuzbass.ru>
To: "Bruce M. Simpson" <bms@FreeBSD.org>
Message-ID: <20080330104525.GA57135@svzserv.kemerovo.su>
References: <47EE42C8.3070100@quip.cz>
<20080329204344.GA66910@lor.one-eyed-alien.net>
<20080330072137.GA35435@svzserv.kemerovo.su>
<47EF69F0.1050304@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <47EF69F0.1050304@FreeBSD.org>
User-Agent: Mutt/1.4.2.3i
Cc: FreeBSD-Net mailing list <freebsd-net@FreeBSD.org>,
Brooks Davis <brooks@FreeBSD.org>, Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected?
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, 30 Mar 2008 10:45:30 -0000
> >Why? The same with creating gif-tunnel, now I need to invoke ifconfig
> >twice, once for 'create' and once for other tunnel parameters,
> >whereas for RELENG_6 this works: 'ifconfig gif0 create tunnel 1.1.1.1
> >2.2.2.2'
> >This breaks existing setups/scripts. This is POLA issue.
> >Why was it broken?
>
> I don't know why or how this has happened, however, given the complexity
> of the command line grammar which ifconfig is expected to parse, our
> choices are limited, unless someone(tm) is willing to come along and
> implement a full parser in ifconfig.
It worked. Now it does not work. Someone(tm) made the change.
We have the CVS. Isn't there such thing as responsibility for changes?
A dichotomy will show us who did the change :-)
Eugene Grosbein
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 11:14:42 2008
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 166541065670
for <freebsd-net@FreeBSD.org>; Sun, 30 Mar 2008 11:14:42 +0000 (UTC)
(envelope-from remko@elvandar.org)
Received: from websrv01.jr-hosting.nl (websrv01.jr-hosting.nl [78.47.69.233])
by mx1.freebsd.org (Postfix) with ESMTP id D2B738FC44
for <freebsd-net@FreeBSD.org>; Sun, 30 Mar 2008 11:14:41 +0000 (UTC)
(envelope-from remko@elvandar.org)
Received: from [195.64.94.120] (helo=[10.0.2.152])
by websrv01.jr-hosting.nl with esmtpsa (TLSv1:AES128-SHA:128)
(Exim 4.69 (FreeBSD)) (envelope-from <remko@elvandar.org>)
id 1JfvVD-000FZu-Tg; Sun, 30 Mar 2008 11:15:07 +0000
Message-Id: <9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org>
From: Remko Lodder <remko@elvandar.org>
To: Eugene Grosbein <eugen@kuzbass.ru>
In-Reply-To: <20080330104525.GA57135@svzserv.kemerovo.su>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Sun, 30 Mar 2008 13:14:36 +0200
References: <47EE42C8.3070100@quip.cz>
<20080329204344.GA66910@lor.one-eyed-alien.net>
<20080330072137.GA35435@svzserv.kemerovo.su>
<47EF69F0.1050304@FreeBSD.org>
<20080330104525.GA57135@svzserv.kemerovo.su>
X-Mailer: Apple Mail (2.919.2)
Cc: FreeBSD-Net mailing list <freebsd-net@FreeBSD.org>,
Brooks Davis <brooks@FreeBSD.org>, "Bruce M. Simpson" <bms@FreeBSD.org>,
Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected?
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, 30 Mar 2008 11:14:42 -0000
On Mar 30, 2008, at 12:45 PM, Eugene Grosbein wrote:
>>> Why? The same with creating gif-tunnel, now I need to invoke
>>> ifconfig
>>> twice, once for 'create' and once for other tunnel parameters,
>>> whereas for RELENG_6 this works: 'ifconfig gif0 create tunnel
>>> 1.1.1.1
>>> 2.2.2.2'
>>> This breaks existing setups/scripts. This is POLA issue.
>>> Why was it broken?
>>
>> I don't know why or how this has happened, however, given the
>> complexity
>> of the command line grammar which ifconfig is expected to parse, our
>> choices are limited, unless someone(tm) is willing to come along and
>> implement a full parser in ifconfig.
>
> It worked. Now it does not work. Someone(tm) made the change.
> We have the CVS. Isn't there such thing as responsibility for changes?
> A dichotomy will show us who did the change :-)
>
> Eugene Grosbein
Given that the idea is that we dont expect to get to this anytime
soon, we welcome the person who does the analysis for us so that we
might be able to fix this quicker (if possible with all the changes
involved).
Thanks,
remko
--
/"\ Best regards, | remko@FreeBSD.org
\ / Remko Lodder | remko@EFnet
X http://www.evilcoder.org/ |
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 11:22:09 2008
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 AACBE106566B;
Sun, 30 Mar 2008 11:22:09 +0000 (UTC) (envelope-from mav@FreeBSD.org)
Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121])
by mx1.freebsd.org (Postfix) with ESMTP id F10388FC1C;
Sun, 30 Mar 2008 11:22:08 +0000 (UTC) (envelope-from mav@FreeBSD.org)
X-Spam-Flag: SKIP
X-Spam-Yversion: Spamooborona-2.1.0
Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2])
by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14)
with ESMTPA id 100031004; Sun, 30 Mar 2008 14:22:07 +0300
Message-ID: <47EF77DE.6040200@FreeBSD.org>
Date: Sun, 30 Mar 2008 14:22:06 +0300
From: Alexander Motin <mav@FreeBSD.org>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Robert Watson <rwatson@FreeBSD.org>
References: <47EF4F18.502@FreeBSD.org> <20080330112846.Y5921@fledge.watson.org>
In-Reply-To: <20080330112846.Y5921@fledge.watson.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org>
Subject: Re: Multiple netgraph threads
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, 30 Mar 2008 11:22:09 -0000
Robert Watson wrote:
> FYI, you might be interested in some similar work I've been doing
> in the rwatson_netisr branch in Perforce, which:
> Adds per-CPU netisr threads
Thanks. Netgraph from the beginning uses concept of direct function
calls, when level of parallelism limited by data source. In that point
multiple netisr threads will give benefits.
> My initial leaning would be that we would like to avoid adding too many
> more threads that will do per-packet work, as that leads to excessive
> context switching.
Netgraph uses queueing only as last resort, when direct call is not
possible due to locking or stack limitations. For example, while working
with kernel sockets (*upcall)() I have got many issues which make
impossible to freely use received data without queueing as upcall()
caller holds some locks leading to unpredicted LORs in socket/TCP/UDP code.
In case of such forced queueing, node becomes an independent data source
which can be pinned to and processed by whatever specialized thread or
netisr, when it will be able to do it more effectively.
--
Alexander Motin
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 11:39:32 2008
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 80562106566B;
Sun, 30 Mar 2008 11:39:32 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su
[213.184.65.80])
by mx1.freebsd.org (Postfix) with ESMTP id DFFE88FC20;
Sun, 30 Mar 2008 11:39:31 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1])
by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m2UBdOmB063604;
Sun, 30 Mar 2008 19:39:24 +0800 (KRAST)
(envelope-from eugen@www.svzserv.kemerovo.su)
Received: (from eugen@localhost)
by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m2UBdNLt063603;
Sun, 30 Mar 2008 19:39:23 +0800 (KRAST) (envelope-from eugen)
Date: Sun, 30 Mar 2008 19:39:23 +0800
From: Eugene Grosbein <eugen@kuzbass.ru>
To: Remko Lodder <remko@elvandar.org>
Message-ID: <20080330113923.GB57135@svzserv.kemerovo.su>
References: <47EE42C8.3070100@quip.cz>
<20080329204344.GA66910@lor.one-eyed-alien.net>
<20080330072137.GA35435@svzserv.kemerovo.su>
<47EF69F0.1050304@FreeBSD.org>
<20080330104525.GA57135@svzserv.kemerovo.su>
<9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org>
User-Agent: Mutt/1.4.2.3i
Cc: FreeBSD-Net mailing list <freebsd-net@freebsd.org>,
Brooks Davis <brooks@freebsd.org>, "Bruce M. Simpson" <bms@freebsd.org>,
Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected?
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, 30 Mar 2008 11:39:32 -0000
On Sun, Mar 30, 2008 at 01:14:36PM +0200, Remko Lodder wrote:
> >It worked. Now it does not work. Someone(tm) made the change.
> >We have the CVS. Isn't there such thing as responsibility for changes?
> >A dichotomy will show us who did the change :-)
>
> Given that the idea is that we dont expect to get to this anytime
> soon, we welcome the person who does the analysis for us so that we
> might be able to fix this quicker (if possible with all the changes
> involved).
The revision 1.120 of src/sbin/ifconfig broke this:
"cvs update -D '2006/07/09 06:00:00'" gives us ifconfig binary
what works and "cvs update -D '2006/07/10 00:00:00'" gives one
that fails. The commit deals with interface cloning.
Now I'm looking for the fix. This is POLA issue and such regressions
should not be tolerated, there are already too many of them.
Eugene Grosbein
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 11:41:17 2008
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 E6FD1106566B;
Sun, 30 Mar 2008 11:41:17 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su
[213.184.65.80])
by mx1.freebsd.org (Postfix) with ESMTP id 51DA78FC14;
Sun, 30 Mar 2008 11:41:17 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1])
by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m2UBfAgY063970;
Sun, 30 Mar 2008 19:41:10 +0800 (KRAST)
(envelope-from eugen@www.svzserv.kemerovo.su)
Received: (from eugen@localhost)
by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m2UBfARi063969;
Sun, 30 Mar 2008 19:41:10 +0800 (KRAST) (envelope-from eugen)
Date: Sun, 30 Mar 2008 19:41:10 +0800
From: Eugene Grosbein <eugen@kuzbass.ru>
To: Remko Lodder <remko@elvandar.org>
Message-ID: <20080330114110.GC57135@svzserv.kemerovo.su>
References: <47EE42C8.3070100@quip.cz>
<20080329204344.GA66910@lor.one-eyed-alien.net>
<20080330072137.GA35435@svzserv.kemerovo.su>
<47EF69F0.1050304@FreeBSD.org>
<20080330104525.GA57135@svzserv.kemerovo.su>
<9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org>
<20080330113923.GB57135@svzserv.kemerovo.su>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080330113923.GB57135@svzserv.kemerovo.su>
User-Agent: Mutt/1.4.2.3i
Cc: FreeBSD-Net mailing list <freebsd-net@freebsd.org>,
Brooks Davis <brooks@freebsd.org>, "Bruce M. Simpson" <bms@freebsd.org>,
Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected?
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, 30 Mar 2008 11:41:18 -0000
On Sun, Mar 30, 2008 at 07:39:23PM +0800, Eugene Grosbein wrote:
> The revision 1.120 of src/sbin/ifconfig broke this:
> "cvs update -D '2006/07/09 06:00:00'" gives us ifconfig binary
> what works and "cvs update -D '2006/07/10 00:00:00'" gives one
> that fails. The commit deals with interface cloning.
Read: "... of src/sbin/ifconfig.c"
Eugene Grosbein
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 12:59:11 2008
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 597C3106566C;
Sun, 30 Mar 2008 12:59:11 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su
[213.184.65.80])
by mx1.freebsd.org (Postfix) with ESMTP id B8EB18FC16;
Sun, 30 Mar 2008 12:59:10 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1])
by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m2UCx1pj073899;
Sun, 30 Mar 2008 20:59:01 +0800 (KRAST)
(envelope-from eugen@www.svzserv.kemerovo.su)
Received: (from eugen@localhost)
by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m2UCx1VX073896;
Sun, 30 Mar 2008 20:59:01 +0800 (KRAST) (envelope-from eugen)
Date: Sun, 30 Mar 2008 20:59:01 +0800
From: Eugene Grosbein <eugen@kuzbass.ru>
To: Remko Lodder <remko@elvandar.org>
Message-ID: <20080330125901.GD57135@svzserv.kemerovo.su>
References: <47EE42C8.3070100@quip.cz>
<20080329204344.GA66910@lor.one-eyed-alien.net>
<20080330072137.GA35435@svzserv.kemerovo.su>
<47EF69F0.1050304@FreeBSD.org>
<20080330104525.GA57135@svzserv.kemerovo.su>
<9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org>
User-Agent: Mutt/1.4.2.3i
Cc: FreeBSD-Net mailing list <freebsd-net@FreeBSD.org>,
Brooks Davis <brooks@FreeBSD.org>, "Bruce M. Simpson" <bms@FreeBSD.org>,
Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected?
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, 30 Mar 2008 12:59:11 -0000
On Sun, Mar 30, 2008 at 01:14:36PM +0200, Remko Lodder wrote:
> >It worked. Now it does not work. Someone(tm) made the change.
> >We have the CVS. Isn't there such thing as responsibility for changes?
> >A dichotomy will show us who did the change :-)
>
> Given that the idea is that we dont expect to get to this anytime
> soon, we welcome the person who does the analysis for us so that we
> might be able to fix this quicker (if possible with all the changes
> involved).
Let's take a look to ifconfig(8) manual page:
SYNOPSIS
ifconfig [-L] [-k] [-m] [-n] interface [create] [address_family] [address
[dest_address]] [parameters]
It states that "create" word may be used with address family,
adresses and other paramerets in line. Now there is design problem brought
into ifconfig code with sam's commit 2006/07/09. Current code
defers device cloning using callback facility because vlan creation
procedure needs to gather vlan tag and parent device parameners before.
However, it means that "create inet" or "create tunnel" clauses
now became incorrect. So this change broke things and should be corrected.
Basically, it broke all setups for sake of vlan processing.
It seems that vlans should be processed as special case leaving
all other cases in peace.
Eugene Grosbein
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 13:27:23 2008
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 5CFBA106564A;
Sun, 30 Mar 2008 13:27:23 +0000 (UTC)
(envelope-from rwatson@FreeBSD.org)
Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42])
by mx1.freebsd.org (Postfix) with ESMTP id 3D59F8FC14;
Sun, 30 Mar 2008 13:27:23 +0000 (UTC)
(envelope-from rwatson@FreeBSD.org)
Received: from fledge.watson.org (fledge.watson.org [209.31.154.41])
by cyrus.watson.org (Postfix) with ESMTP id D68CE46B3B;
Sun, 30 Mar 2008 09:27:22 -0400 (EDT)
Date: Sun, 30 Mar 2008 14:27:22 +0100 (BST)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: Alexander Motin <mav@FreeBSD.org>
In-Reply-To: <47EF77DE.6040200@FreeBSD.org>
Message-ID: <20080330142332.Y5921@fledge.watson.org>
References: <47EF4F18.502@FreeBSD.org> <20080330112846.Y5921@fledge.watson.org>
<47EF77DE.6040200@FreeBSD.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org>
Subject: Re: Multiple netgraph threads
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, 30 Mar 2008 13:27:23 -0000
On Sun, 30 Mar 2008, Alexander Motin wrote:
>> My initial leaning would be that we would like to avoid adding too many
>> more threads that will do per-packet work, as that leads to excessive
>> context switching.
>
> Netgraph uses queueing only as last resort, when direct call is not possible
> due to locking or stack limitations. For example, while working with kernel
> sockets (*upcall)() I have got many issues which make impossible to freely
> use received data without queueing as upcall() caller holds some locks
> leading to unpredicted LORs in socket/TCP/UDP code. In case of such forced
> queueing, node becomes an independent data source which can be pinned to and
> processed by whatever specialized thread or netisr, when it will be able to
> do it more effectively.
I guess my caution is that it does not necessarily follow from a design that
allows for explicit parallelism that the implementation will use it well, and
that any time context switchs are necessarily introduced, cost goes up. The
move to direct dispatch from the ithread, despite reducing opportunities for
parallelism, significantly increased performance for many local workloads.
If we have a netisr thread, an ithread, and a netgraph thread, the potential
context switch overhead is significant, even if we are doing a good job at
batching work transfer between them. Often times, the way this behaves in
practice is quite dependent on scheduling, and right now we have known
defficiencies in this area, so give it a try on an SMP box and see what
happens. Since you're a FreeBSD committer, you can sign up to use the netperf
cluster, which might not be a bad idea if you don't have local access to a
good SMP test setup.
Robert N M Watson
Computer Laboratory
University of Cambridge
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 14:30:01 2008
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 7D80C106564A;
Sun, 30 Mar 2008 14:30:01 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su
[213.184.65.80])
by mx1.freebsd.org (Postfix) with ESMTP id D4BA38FC20;
Sun, 30 Mar 2008 14:30:00 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1])
by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m2UETpPP084789;
Sun, 30 Mar 2008 22:29:51 +0800 (KRAST)
(envelope-from eugen@www.svzserv.kemerovo.su)
Received: (from eugen@localhost)
by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m2UETpmP084786;
Sun, 30 Mar 2008 22:29:51 +0800 (KRAST) (envelope-from eugen)
Date: Sun, 30 Mar 2008 22:29:51 +0800
From: Eugene Grosbein <eugen@kuzbass.ru>
To: Remko Lodder <remko@elvandar.org>
Message-ID: <20080330142951.GA80768@svzserv.kemerovo.su>
References: <47EE42C8.3070100@quip.cz>
<20080329204344.GA66910@lor.one-eyed-alien.net>
<20080330072137.GA35435@svzserv.kemerovo.su>
<47EF69F0.1050304@FreeBSD.org>
<20080330104525.GA57135@svzserv.kemerovo.su>
<9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org>
User-Agent: Mutt/1.4.2.3i
Cc: FreeBSD-Net mailing list <freebsd-net@freebsd.org>,
Brooks Davis <brooks@freebsd.org>, "Bruce M. Simpson" <bms@freebsd.org>,
Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected?
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, 30 Mar 2008 14:30:01 -0000
On Sun, Mar 30, 2008 at 01:14:36PM +0200, Remko Lodder wrote:
> Given that the idea is that we dont expect to get to this anytime
> soon, we welcome the person who does the analysis for us so that we
> might be able to fix this quicker (if possible with all the changes
> involved).
Here is a patch for RELENG_7. I ask Miroslav Lachman to test it.
Apply:
cd /usr/src/sbin/ifconfig
patch < /path/to/patchfile
make
Test:
./ifconfig lo1 create inet 5.5.5.5 netmask 255.255.255.0
Or full-blown syntax:
./ifconfig gif0 create inet 6.6.6.6 7.7.7.7 tunnel 1.1.1.1 2.2.2.2 \
netmask 255.255.255.255 mtu 1500 link2
Index: ifclone.c
===================================================================
RCS file: /home/ncvs/src/sbin/ifconfig/ifclone.c,v
retrieving revision 1.3
diff -u -r1.3 ifclone.c
--- ifclone.c 12 Aug 2006 18:07:17 -0000 1.3
+++ ifclone.c 30 Mar 2008 14:19:08 -0000
@@ -131,7 +131,9 @@
static
DECL_CMD_FUNC(clone_create, arg, d)
{
- callback_register(ifclonecreate, NULL);
+ if (strstr(name, "vlan") == name)
+ callback_register(ifclonecreate, NULL);
+ else ifclonecreate(s, NULL);
}
static
Index: ifconfig.c
===================================================================
RCS file: /home/ncvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.134
diff -u -r1.134 ifconfig.c
--- ifconfig.c 4 Oct 2007 09:45:41 -0000 1.134
+++ ifconfig.c 30 Mar 2008 14:22:00 -0000
@@ -247,7 +247,12 @@
if (iflen >= sizeof(name))
errx(1, "%s: cloning name too long",
ifname);
- ifconfig(argc, argv, NULL);
+ if (argc > 1) {
+ afp = af_getbyname(argv[1]);
+ if (afp != NULL)
+ argv[1] = NULL;
+ }
+ ifconfig(argc, argv, afp);
exit(0);
}
errx(1, "interface %s does not exist", ifname);
@@ -451,6 +456,9 @@
while (argc > 0) {
const struct cmd *p;
+ if(*argv == NULL)
+ goto next;
+
p = cmd_lookup(*argv);
if (p == NULL) {
/*
@@ -479,6 +487,7 @@
} else
p->c_u.c_func(*argv, p->c_parameter, s, afp);
}
+ next:
argc--, argv++;
}
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 17:47:26 2008
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 26AE41065672;
Sun, 30 Mar 2008 17:47:26 +0000 (UTC) (envelope-from sam@freebsd.org)
Received: from ebb.errno.com (ebb.errno.com [69.12.149.25])
by mx1.freebsd.org (Postfix) with ESMTP id D2D448FC1F;
Sun, 30 Mar 2008 17:47:25 +0000 (UTC) (envelope-from sam@freebsd.org)
Received: from trouble.errno.com (trouble.errno.com [10.0.0.248])
(authenticated bits=0)
by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2UHlEPn093563
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sun, 30 Mar 2008 10:47:15 -0700 (PDT) (envelope-from sam@freebsd.org)
Message-ID: <47EFD222.2050008@freebsd.org>
Date: Sun, 30 Mar 2008 10:47:14 -0700
From: Sam Leffler <sam@freebsd.org>
Organization: FreeBSD Project
User-Agent: Thunderbird 2.0.0.9 (X11/20071125)
MIME-Version: 1.0
To: Eugene Grosbein <eugen@kuzbass.ru>
References: <47EE42C8.3070100@quip.cz> <20080329204344.GA66910@lor.one-eyed-alien.net> <20080330072137.GA35435@svzserv.kemerovo.su> <47EF69F0.1050304@FreeBSD.org> <20080330104525.GA57135@svzserv.kemerovo.su> <9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org>
<20080330142951.GA80768@svzserv.kemerovo.su>
In-Reply-To: <20080330142951.GA80768@svzserv.kemerovo.su>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-DCC-Misty-Metrics: ebb.errno.com; whitelist
Cc: FreeBSD-Net mailing list <freebsd-net@freebsd.org>,
Remko Lodder <remko@elvandar.org>, Brooks Davis <brooks@freebsd.org>,
"Bruce M. Simpson" <bms@freebsd.org>, Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected?
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, 30 Mar 2008 17:47:26 -0000
Eugene Grosbein wrote:
> On Sun, Mar 30, 2008 at 01:14:36PM +0200, Remko Lodder wrote:
>
>
>> Given that the idea is that we dont expect to get to this anytime
>> soon, we welcome the person who does the analysis for us so that we
>> might be able to fix this quicker (if possible with all the changes
>> involved).
>>
>
> Here is a patch for RELENG_7. I ask Miroslav Lachman to test it.
> Apply:
>
> cd /usr/src/sbin/ifconfig
> patch < /path/to/patchfile
> make
>
> Test:
>
> ./ifconfig lo1 create inet 5.5.5.5 netmask 255.255.255.0
>
> Or full-blown syntax:
>
> ./ifconfig gif0 create inet 6.6.6.6 7.7.7.7 tunnel 1.1.1.1 2.2.2.2 \
> netmask 255.255.255.255 mtu 1500 link2
>
> Index: ifclone.c
> ===================================================================
> RCS file: /home/ncvs/src/sbin/ifconfig/ifclone.c,v
> retrieving revision 1.3
> diff -u -r1.3 ifclone.c
> --- ifclone.c 12 Aug 2006 18:07:17 -0000 1.3
> +++ ifclone.c 30 Mar 2008 14:19:08 -0000
> @@ -131,7 +131,9 @@
> static
> DECL_CMD_FUNC(clone_create, arg, d)
> {
> - callback_register(ifclonecreate, NULL);
> + if (strstr(name, "vlan") == name)
> + callback_register(ifclonecreate, NULL);
> + else ifclonecreate(s, NULL);
>
This breaks other cloning operations (e.g. wlan vaps that are about to
show up in HEAD). In general it is wrong to embed knowledge about one
type of cloning op in the common clone code. If you want to add the
notion of cloning operations that should be done immediately vs. ones
that should be deferred then do it generically; not by hacks like this.
Understand however that now !vlan clone operations behave differently
than vlans and many people will be utterly confused by the inconsistency.
> }
>
> static
> Index: ifconfig.c
> ===================================================================
> RCS file: /home/ncvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving revision 1.134
> diff -u -r1.134 ifconfig.c
> --- ifconfig.c 4 Oct 2007 09:45:41 -0000 1.134
> +++ ifconfig.c 30 Mar 2008 14:22:00 -0000
> @@ -247,7 +247,12 @@
> if (iflen >= sizeof(name))
> errx(1, "%s: cloning name too long",
> ifname);
> - ifconfig(argc, argv, NULL);
> + if (argc > 1) {
> + afp = af_getbyname(argv[1]);
> + if (afp != NULL)
> + argv[1] = NULL;
> + }
> + ifconfig(argc, argv, afp);
> exit(0);
> }
> errx(1, "interface %s does not exist", ifname);
> @@ -451,6 +456,9 @@
> while (argc > 0) {
> const struct cmd *p;
>
> + if(*argv == NULL)
> + goto next;
> +
> p = cmd_lookup(*argv);
> if (p == NULL) {
> /*
> @@ -479,6 +487,7 @@
> } else
> p->c_u.c_func(*argv, p->c_parameter, s, afp);
> }
> + next:
> argc--, argv++;
> }
>
Aside from not maintaining prevailing style and breaking cloning of
other devices you seem to understand the issue. How to handle it is
however unclear. I considered making 2 passes over the arguments to
collect those required for a clone operation but never got to it. That
still seems like the correct approach.
Sam
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 17:53:40 2008
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 4F3DB106566C;
Sun, 30 Mar 2008 17:53:40 +0000 (UTC) (envelope-from sam@freebsd.org)
Received: from ebb.errno.com (ebb.errno.com [69.12.149.25])
by mx1.freebsd.org (Postfix) with ESMTP id 0405A8FC17;
Sun, 30 Mar 2008 17:53:39 +0000 (UTC) (envelope-from sam@freebsd.org)
Received: from trouble.errno.com (trouble.errno.com [10.0.0.248])
(authenticated bits=0)
by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2UHrXHu093599
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sun, 30 Mar 2008 10:53:33 -0700 (PDT) (envelope-from sam@freebsd.org)
Message-ID: <47EFD39D.8030107@freebsd.org>
Date: Sun, 30 Mar 2008 10:53:33 -0700
From: Sam Leffler <sam@freebsd.org>
Organization: FreeBSD Project
User-Agent: Thunderbird 2.0.0.9 (X11/20071125)
MIME-Version: 1.0
To: Eugene Grosbein <eugen@kuzbass.ru>
References: <47EE42C8.3070100@quip.cz> <20080329204344.GA66910@lor.one-eyed-alien.net> <20080330072137.GA35435@svzserv.kemerovo.su> <47EF69F0.1050304@FreeBSD.org> <20080330104525.GA57135@svzserv.kemerovo.su> <9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org> <20080330142951.GA80768@svzserv.kemerovo.su>
<47EFD222.2050008@freebsd.org>
In-Reply-To: <47EFD222.2050008@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-DCC-Misty-Metrics: ebb.errno.com; whitelist
Cc: FreeBSD-Net mailing list <freebsd-net@freebsd.org>,
Remko Lodder <remko@elvandar.org>, Brooks Davis <brooks@freebsd.org>,
"Bruce M. Simpson" <bms@freebsd.org>, Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected?
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, 30 Mar 2008 17:53:40 -0000
Sam Leffler wrote:
> Eugene Grosbein wrote:
>> On Sun, Mar 30, 2008 at 01:14:36PM +0200, Remko Lodder wrote:
>>
>>
>>> Given that the idea is that we dont expect to get to this anytime
>>> soon, we welcome the person who does the analysis for us so that we
>>> might be able to fix this quicker (if possible with all the changes
>>> involved).
>>>
>>
>> Here is a patch for RELENG_7. I ask Miroslav Lachman to test it.
>> Apply:
>>
>> cd /usr/src/sbin/ifconfig
>> patch < /path/to/patchfile
>> make
>>
>> Test:
>>
>> ./ifconfig lo1 create inet 5.5.5.5 netmask 255.255.255.0
>>
>> Or full-blown syntax:
>>
>> ./ifconfig gif0 create inet 6.6.6.6 7.7.7.7 tunnel 1.1.1.1 2.2.2.2 \
>> netmask 255.255.255.255 mtu 1500 link2
>>
>> Index: ifclone.c
>> ===================================================================
>> RCS file: /home/ncvs/src/sbin/ifconfig/ifclone.c,v
>> retrieving revision 1.3
>> diff -u -r1.3 ifclone.c
>> --- ifclone.c 12 Aug 2006 18:07:17 -0000 1.3
>> +++ ifclone.c 30 Mar 2008 14:19:08 -0000
>> @@ -131,7 +131,9 @@
>> static
>> DECL_CMD_FUNC(clone_create, arg, d)
>> {
>> - callback_register(ifclonecreate, NULL);
>> + if (strstr(name, "vlan") == name)
>> + callback_register(ifclonecreate, NULL);
>> + else ifclonecreate(s, NULL);
>>
>
> This breaks other cloning operations (e.g. wlan vaps that are about to
> show up in HEAD). In general it is wrong to embed knowledge about one
> type of cloning op in the common clone code. If you want to add the
> notion of cloning operations that should be done immediately vs. ones
> that should be deferred then do it generically; not by hacks like
> this. Understand however that now !vlan clone operations behave
> differently than vlans and many people will be utterly confused by the
> inconsistency.
>
>> }
>>
>> static
>> Index: ifconfig.c
>> ===================================================================
>> RCS file: /home/ncvs/src/sbin/ifconfig/ifconfig.c,v
>> retrieving revision 1.134
>> diff -u -r1.134 ifconfig.c
>> --- ifconfig.c 4 Oct 2007 09:45:41 -0000 1.134
>> +++ ifconfig.c 30 Mar 2008 14:22:00 -0000
>> @@ -247,7 +247,12 @@
>> if (iflen >= sizeof(name))
>> errx(1, "%s: cloning name too long",
>> ifname);
>> - ifconfig(argc, argv, NULL);
>> + if (argc > 1) {
>> + afp = af_getbyname(argv[1]);
>> + if (afp != NULL)
>> + argv[1] = NULL;
>> + }
>> + ifconfig(argc, argv, afp);
>> exit(0);
>> }
>> errx(1, "interface %s does not exist", ifname);
>> @@ -451,6 +456,9 @@
>> while (argc > 0) {
>> const struct cmd *p;
>>
>> + if(*argv == NULL)
>> + goto next;
>> + p = cmd_lookup(*argv);
>> if (p == NULL) {
>> /*
>> @@ -479,6 +487,7 @@
>> } else
>> p->c_u.c_func(*argv, p->c_parameter, s, afp);
>> }
>> + next:
>> argc--, argv++;
>> }
>>
>
> Aside from not maintaining prevailing style and breaking cloning of
> other devices you seem to understand the issue. How to handle it is
> however unclear. I considered making 2 passes over the arguments to
> collect those required for a clone operation but never got to it.
> That still seems like the correct approach.
It might be simpler to just do 1 pass over the args and push the clone
callback on the first non-clone parameter. Right now however there's no
way to tell what is clone-related and what is not.
Sam
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 19:40:24 2008
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 258AD1065677;
Sun, 30 Mar 2008 19:40:24 +0000 (UTC) (envelope-from sam@freebsd.org)
Received: from ebb.errno.com (ebb.errno.com [69.12.149.25])
by mx1.freebsd.org (Postfix) with ESMTP id C3CD68FC28;
Sun, 30 Mar 2008 19:40:23 +0000 (UTC) (envelope-from sam@freebsd.org)
Received: from trouble.errno.com (trouble.errno.com [10.0.0.248])
(authenticated bits=0)
by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2UJeBls094160
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sun, 30 Mar 2008 12:40:12 -0700 (PDT) (envelope-from sam@freebsd.org)
Message-ID: <47EFEC9B.8040205@freebsd.org>
Date: Sun, 30 Mar 2008 12:40:11 -0700
From: Sam Leffler <sam@freebsd.org>
Organization: FreeBSD Project
User-Agent: Thunderbird 2.0.0.9 (X11/20071125)
MIME-Version: 1.0
To: Eugene Grosbein <eugen@kuzbass.ru>
References: <47EE42C8.3070100@quip.cz> <20080329204344.GA66910@lor.one-eyed-alien.net> <20080330072137.GA35435@svzserv.kemerovo.su> <47EF69F0.1050304@FreeBSD.org> <20080330104525.GA57135@svzserv.kemerovo.su> <9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org> <20080330142951.GA80768@svzserv.kemerovo.su> <47EFD222.2050008@freebsd.org>
<47EFD39D.8030107@freebsd.org>
In-Reply-To: <47EFD39D.8030107@freebsd.org>
Content-Type: multipart/mixed; boundary="------------090706030204090709050703"
X-DCC-Misty-Metrics: ebb.errno.com; whitelist
Cc: FreeBSD-Net mailing list <freebsd-net@freebsd.org>,
Remko Lodder <remko@elvandar.org>, Brooks Davis <brooks@freebsd.org>,
"Bruce M. Simpson" <bms@freebsd.org>, Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected?
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, 30 Mar 2008 19:40:24 -0000
This is a multi-part message in MIME format.
--------------090706030204090709050703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sam Leffler wrote:
> Sam Leffler wrote:
>> Eugene Grosbein wrote:
>>> On Sun, Mar 30, 2008 at 01:14:36PM +0200, Remko Lodder wrote:
>>>
>>>
>>>> Given that the idea is that we dont expect to get to this anytime
>>>> soon, we welcome the person who does the analysis for us so that
>>>> we might be able to fix this quicker (if possible with all the
>>>> changes involved).
>>>>
>>>
>>> Here is a patch for RELENG_7. I ask Miroslav Lachman to test it.
>>> Apply:
>>>
>>> cd /usr/src/sbin/ifconfig
>>> patch < /path/to/patchfile
>>> make
>>>
>>> Test:
>>>
>>> ./ifconfig lo1 create inet 5.5.5.5 netmask 255.255.255.0
>>>
>>> Or full-blown syntax:
>>>
>>> ./ifconfig gif0 create inet 6.6.6.6 7.7.7.7 tunnel 1.1.1.1 2.2.2.2 \
>>> netmask 255.255.255.255 mtu 1500 link2
>>>
>>> Index: ifclone.c
>>> ===================================================================
>>> RCS file: /home/ncvs/src/sbin/ifconfig/ifclone.c,v
>>> retrieving revision 1.3
>>> diff -u -r1.3 ifclone.c
>>> --- ifclone.c 12 Aug 2006 18:07:17 -0000 1.3
>>> +++ ifclone.c 30 Mar 2008 14:19:08 -0000
>>> @@ -131,7 +131,9 @@
>>> static
>>> DECL_CMD_FUNC(clone_create, arg, d)
>>> {
>>> - callback_register(ifclonecreate, NULL);
>>> + if (strstr(name, "vlan") == name)
>>> + callback_register(ifclonecreate, NULL);
>>> + else ifclonecreate(s, NULL);
>>>
>>
>> This breaks other cloning operations (e.g. wlan vaps that are about
>> to show up in HEAD). In general it is wrong to embed knowledge about
>> one type of cloning op in the common clone code. If you want to add
>> the notion of cloning operations that should be done immediately vs.
>> ones that should be deferred then do it generically; not by hacks
>> like this. Understand however that now !vlan clone operations behave
>> differently than vlans and many people will be utterly confused by
>> the inconsistency.
>>
>>> }
>>>
>>> static
>>> Index: ifconfig.c
>>> ===================================================================
>>> RCS file: /home/ncvs/src/sbin/ifconfig/ifconfig.c,v
>>> retrieving revision 1.134
>>> diff -u -r1.134 ifconfig.c
>>> --- ifconfig.c 4 Oct 2007 09:45:41 -0000 1.134
>>> +++ ifconfig.c 30 Mar 2008 14:22:00 -0000
>>> @@ -247,7 +247,12 @@
>>> if (iflen >= sizeof(name))
>>> errx(1, "%s: cloning name too long",
>>> ifname);
>>> - ifconfig(argc, argv, NULL);
>>> + if (argc > 1) {
>>> + afp = af_getbyname(argv[1]);
>>> + if (afp != NULL)
>>> + argv[1] = NULL;
>>> + }
>>> + ifconfig(argc, argv, afp);
>>> exit(0);
>>> }
>>> errx(1, "interface %s does not exist", ifname);
>>> @@ -451,6 +456,9 @@
>>> while (argc > 0) {
>>> const struct cmd *p;
>>>
>>> + if(*argv == NULL)
>>> + goto next;
>>> + p = cmd_lookup(*argv);
>>> if (p == NULL) {
>>> /*
>>> @@ -479,6 +487,7 @@
>>> } else
>>> p->c_u.c_func(*argv, p->c_parameter, s, afp);
>>> }
>>> + next:
>>> argc--, argv++;
>>> }
>>>
>>
>> Aside from not maintaining prevailing style and breaking cloning of
>> other devices you seem to understand the issue. How to handle it is
>> however unclear. I considered making 2 passes over the arguments to
>> collect those required for a clone operation but never got to it.
>> That still seems like the correct approach.
>
> It might be simpler to just do 1 pass over the args and push the clone
> callback on the first non-clone parameter. Right now however there's
> no way to tell what is clone-related and what is not.
I think the attached patch against HEAD DTRT. Should work on RELENG_7 too.
Sam
--------------090706030204090709050703
Content-Type: text/plain;
name="ifconfig.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ifconfig.patch"
Index: ifconfig.c
===================================================================
RCS file: /usr/ncvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.135
diff -u -r1.135 ifconfig.c
--- ifconfig.c 10 Dec 2007 02:31:00 -0000 1.135
+++ ifconfig.c 30 Mar 2008 19:29:39 -0000
@@ -93,7 +93,8 @@
int supmedia = 0;
int printkeys = 0; /* Print keying material for interfaces. */
-static int ifconfig(int argc, char *const *argv, const struct afswtch *afp);
+static int ifconfig(int argc, char *const *argv, int iscreate,
+ const struct afswtch *afp);
static void status(const struct afswtch *afp, const struct sockaddr_dl *sdl,
struct ifaddrs *ifa);
static void tunnel_status(int s);
@@ -247,7 +248,7 @@
if (iflen >= sizeof(name))
errx(1, "%s: cloning name too long",
ifname);
- ifconfig(argc, argv, NULL);
+ ifconfig(argc, argv, 1, NULL);
exit(0);
}
errx(1, "interface %s does not exist", ifname);
@@ -305,7 +306,7 @@
}
if (argc > 0)
- ifconfig(argc, argv, afp);
+ ifconfig(argc, argv, 0, afp);
else
status(afp, sdl, ifa);
}
@@ -433,17 +434,19 @@
DEF_CMD("ifdstaddr", 0, setifdstaddr);
static int
-ifconfig(int argc, char *const *argv, const struct afswtch *afp)
+ifconfig(int argc, char *const *argv, int iscreate, const struct afswtch *afp)
{
+ const struct afswtch *nafp;
struct callback *cb;
int s;
+ strncpy(ifr.ifr_name, name, sizeof ifr.ifr_name);
+top:
if (afp == NULL)
afp = af_getbyname("inet");
ifr.ifr_addr.sa_family =
afp->af_af == AF_LINK || afp->af_af == AF_UNSPEC ?
AF_INET : afp->af_af;
- strncpy(ifr.ifr_name, name, sizeof ifr.ifr_name);
if ((s = socket(ifr.ifr_addr.sa_family, SOCK_DGRAM, 0)) < 0)
err(1, "socket(family %u,SOCK_DGRAM", ifr.ifr_addr.sa_family);
@@ -460,6 +463,32 @@
p = (setaddr ? &setifdstaddr_cmd : &setifaddr_cmd);
}
if (p->c_u.c_func || p->c_u.c_func2) {
+ if (iscreate && !p->c_iscloneop) {
+ /*
+ * Push the clone create callback so the new
+ * device is created and can be used for any
+ * remaining arguments.
+ */
+ cb = callbacks;
+ if (cb == NULL)
+ errx(1, "internal error, no callback");
+ callbacks = cb->cb_next;
+ cb->cb_func(s, cb->cb_arg);
+ /*
+ * Handle any address family spec that
+ * immediately follows and potentially
+ * recreate the socket.
+ */
+ nafp = af_getbyname(*argv);
+ if (nafp != NULL) {
+ argc--, argv++;
+ if (nafp != afp) {
+ close(s);
+ afp = nafp;
+ goto top;
+ }
+ }
+ }
if (p->c_parameter == NEXTARG) {
if (argv[1] == NULL)
errx(1, "'%s' requires argument",
Index: ifconfig.h
===================================================================
RCS file: /usr/ncvs/src/sbin/ifconfig/ifconfig.h,v
retrieving revision 1.21
diff -u -r1.21 ifconfig.h
--- ifconfig.h 13 Jun 2007 18:07:59 -0000 1.21
+++ ifconfig.h 30 Mar 2008 19:38:31 -0000
@@ -52,6 +52,7 @@
c_func *c_func;
c_func2 *c_func2;
} c_u;
+ int c_iscloneop;
struct cmd *c_next;
};
void cmd_register(struct cmd *);
@@ -71,6 +72,8 @@
#define DEF_CMD_ARG(name, func) { name, NEXTARG, { .c_func = func } }
#define DEF_CMD_OPTARG(name, func) { name, OPTARG, { .c_func = func } }
#define DEF_CMD_ARG2(name, func) { name, NEXTARG2, { .c_func2 = func } }
+#define DEF_CLONE_CMD(name, param, func) { name, param, { .c_func = func }, 1 }
+#define DEF_CLONE_CMD_ARG(name, func) { name, NEXTARG, { .c_func = func }, 1 }
struct ifaddrs;
struct addrinfo;
Index: ifvlan.c
===================================================================
RCS file: /usr/ncvs/src/sbin/ifconfig/ifvlan.c,v
retrieving revision 1.12
diff -u -r1.12 ifvlan.c
--- ifvlan.c 9 Jul 2006 06:10:23 -0000 1.12
+++ ifvlan.c 30 Mar 2008 19:25:26 -0000
@@ -172,8 +172,8 @@
}
static struct cmd vlan_cmds[] = {
- DEF_CMD_ARG("vlan", setvlantag),
- DEF_CMD_ARG("vlandev", setvlandev),
+ DEF_CLONE_CMD_ARG("vlan", setvlantag),
+ DEF_CLONE_CMD_ARG("vlandev", setvlandev),
/* XXX For compatibility. Should become DEF_CMD() some day. */
DEF_CMD_OPTARG("-vlandev", unsetvlandev),
DEF_CMD("vlanmtu", IFCAP_VLAN_MTU, setifcap),
--------------090706030204090709050703--
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 19:55:35 2008
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 0984A106564A;
Sun, 30 Mar 2008 19:55:35 +0000 (UTC) (envelope-from sam@freebsd.org)
Received: from ebb.errno.com (ebb.errno.com [69.12.149.25])
by mx1.freebsd.org (Postfix) with ESMTP id C23208FC26;
Sun, 30 Mar 2008 19:55:34 +0000 (UTC) (envelope-from sam@freebsd.org)
Received: from trouble.errno.com (trouble.errno.com [10.0.0.248])
(authenticated bits=0)
by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2UJtS0s094239
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sun, 30 Mar 2008 12:55:28 -0700 (PDT) (envelope-from sam@freebsd.org)
Message-ID: <47EFF030.6010108@freebsd.org>
Date: Sun, 30 Mar 2008 12:55:28 -0700
From: Sam Leffler <sam@freebsd.org>
Organization: FreeBSD Project
User-Agent: Thunderbird 2.0.0.9 (X11/20071125)
MIME-Version: 1.0
To: Eugene Grosbein <eugen@kuzbass.ru>
References: <47EE42C8.3070100@quip.cz> <20080329204344.GA66910@lor.one-eyed-alien.net> <20080330072137.GA35435@svzserv.kemerovo.su> <47EF69F0.1050304@FreeBSD.org> <20080330104525.GA57135@svzserv.kemerovo.su> <9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org> <20080330142951.GA80768@svzserv.kemerovo.su> <47EFD222.2050008@freebsd.org> <47EFD39D.8030107@freebsd.org>
<47EFEC9B.8040205@freebsd.org>
In-Reply-To: <47EFEC9B.8040205@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-DCC-Misty-Metrics: ebb.errno.com; whitelist
Cc: FreeBSD-Net mailing list <freebsd-net@freebsd.org>,
Remko Lodder <remko@elvandar.org>, Brooks Davis <brooks@freebsd.org>,
"Bruce M. Simpson" <bms@freebsd.org>, Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected?
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, 30 Mar 2008 19:55:35 -0000
Sam Leffler wrote:
> I think the attached patch against HEAD DTRT. Should work on RELENG_7
> too.
Never mind; this has some issues. I'll post another patch after I do
some real testing.
Sam
From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 21:19:13 2008
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 04C0C106564A;
Sun, 30 Mar 2008 21:19:13 +0000 (UTC) (envelope-from sam@freebsd.org)
Received: from ebb.errno.com (ebb.errno.com [69.12.149.25])
by mx1.freebsd.org (Postfix) with ESMTP id A9EB98FC17;
Sun, 30 Mar 2008 21:19:12 +0000 (UTC) (envelope-from sam@freebsd.org)
Received: from trouble.errno.com (trouble.errno.com [10.0.0.248])
(authenticated bits=0)
by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2ULJ4Y8094803
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sun, 30 Mar 2008 14:19:05 -0700 (PDT) (envelope-from sam@freebsd.org)
Message-ID: <47F003C8.6080605@freebsd.org>
Date: Sun, 30 Mar 2008 14:19:04 -0700
From: Sam Leffler <sam@freebsd.org>
Organization: FreeBSD Project
User-Agent: Thunderbird 2.0.0.9 (X11/20071125)
MIME-Version: 1.0
To: Eugene Grosbein <eugen@kuzbass.ru>
References: <47EE42C8.3070100@quip.cz> <20080329204344.GA66910@lor.one-eyed-alien.net> <20080330072137.GA35435@svzserv.kemerovo.su> <47EF69F0.1050304@FreeBSD.org> <20080330104525.GA57135@svzserv.kemerovo.su> <9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org> <20080330142951.GA80768@svzserv.kemerovo.su> <47EFD222.2050008@freebsd.org> <47EFD39D.8030107@freebsd.org> <47EFEC9B.8040205@freebsd.org>
<47EFF030.6010108@freebsd.org>
In-Reply-To: <47EFF030.6010108@freebsd.org>
Content-Type: multipart/mixed; boundary="------------030506010604030001050708"
X-DCC-Misty-Metrics: ebb.errno.com; whitelist
Cc: FreeBSD-Net mailing list <freebsd-net@freebsd.org>,
Remko Lodder <remko@elvandar.org>, Brooks Davis <brooks@freebsd.org>,
"Bruce M. Simpson" <bms@freebsd.org>, Miroslav Lachman <000.fbsd@quip.cz>
Subject: Re: 7.0 - ifconfig create is not working as expected? [patch 2]
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, 30 Mar 2008 21:19:13 -0000
This is a multi-part message in MIME format.
--------------030506010604030001050708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sam Leffler wrote:
> Sam Leffler wrote:
>> I think the attached patch against HEAD DTRT. Should work on
>> RELENG_7 too.
>
> Never mind; this has some issues. I'll post another patch after I do
> some real testing.
>
Try this. It does as a I suggested--on seeing the first cmd line arg
that is not marked as a cloning parameter the callback is done and state
is updated. Still too hackish for my taste but to handle this and other
similar stuff "properly" requires a significant overhaul (there have
been too many hands in the code doing just enough to get their feature
working).
Sam
--------------030506010604030001050708
Content-Type: text/plain;
name="ifconfig.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ifconfig.patch"
Index: ifclone.c
===================================================================
RCS file: /usr/ncvs/src/sbin/ifconfig/ifclone.c,v
retrieving revision 1.3
diff -u -r1.3 ifclone.c
--- ifclone.c 12 Aug 2006 18:07:17 -0000 1.3
+++ ifclone.c 30 Mar 2008 19:58:35 -0000
@@ -143,9 +143,9 @@
}
static struct cmd clone_cmds[] = {
- DEF_CMD("create", 0, clone_create),
+ DEF_CLONE_CMD("create", 0, clone_create),
DEF_CMD("destroy", 0, clone_destroy),
- DEF_CMD("plumb", 0, clone_create),
+ DEF_CLONE_CMD("plumb", 0, clone_create),
DEF_CMD("unplumb", 0, clone_destroy),
};
Index: ifconfig.c
===================================================================
RCS file: /usr/ncvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.135
diff -u -r1.135 ifconfig.c
--- ifconfig.c 10 Dec 2007 02:31:00 -0000 1.135
+++ ifconfig.c 30 Mar 2008 19:43:34 -0000
@@ -93,7 +93,8 @@
int supmedia = 0;
int printkeys = 0; /* Print keying material for interfaces. */
-static int ifconfig(int argc, char *const *argv, const struct afswtch *afp);
+static int ifconfig(int argc, char *const *argv, int iscreate,
+ const struct afswtch *afp);
static void status(const struct afswtch *afp, const struct sockaddr_dl *sdl,
struct ifaddrs *ifa);
static void tunnel_status(int s);
@@ -247,7 +248,7 @@
if (iflen >= sizeof(name))
errx(1, "%s: cloning name too long",
ifname);
- ifconfig(argc, argv, NULL);
+ ifconfig(argc, argv, 1, NULL);
exit(0);
}
errx(1, "interface %s does not exist", ifname);
@@ -305,7 +306,7 @@
}
if (argc > 0)
- ifconfig(argc, argv, afp);
+ ifconfig(argc, argv, 0, afp);
else
status(afp, sdl, ifa);
}
@@ -433,17 +434,19 @@
DEF_CMD("ifdstaddr", 0, setifdstaddr);
static int
-ifconfig(int argc, char *const *argv, const struct afswtch *afp)
+ifconfig(int argc, char *const *argv, int iscreate, const struct afswtch *afp)
{
+ const struct afswtch *nafp;
struct callback *cb;
int s;
+ strncpy(ifr.ifr_name, name, sizeof ifr.ifr_name);
+top:
if (afp == NULL)
afp = af_getbyname("inet");
ifr.ifr_addr.sa_family =
afp->af_af == AF_LINK || afp->af_af == AF_UNSPEC ?
AF_INET : afp->af_af;
- strncpy(ifr.ifr_name, name, sizeof ifr.ifr_name);
if ((s = socket(ifr.ifr_addr.sa_family, SOCK_DGRAM, 0)) < 0)
err(1, "socket(family %u,SOCK_DGRAM", ifr.ifr_addr.sa_family);
@@ -460,6 +463,33 @@
p = (setaddr ? &setifdstaddr_cmd : &setifaddr_cmd);
}
if (p->c_u.c_func || p->c_u.c_func2) {
+ if (iscreate && !p->c_iscloneop) {
+ /*
+ * Push the clone create callback so the new
+ * device is created and can be used for any
+ * remaining arguments.
+ */
+ cb = callbacks;
+ if (cb == NULL)
+ errx(1, "internal error, no callback");
+ callbacks = cb->cb_next;
+ cb->cb_func(s, cb->cb_arg);
+ iscreate = 0;
+ /*
+ * Handle any address family spec that
+ * immediately follows and potentially
+ * recreate the socket.
+ */
+ nafp = af_getbyname(*argv);
+ if (nafp != NULL) {
+ argc--, argv++;
+ if (nafp != afp) {
+ close(s);
+ afp = nafp;
+ goto top;
+ }
+ }
+ }
if (p->c_parameter == NEXTARG) {
if (argv[1] == NULL)
errx(1, "'%s' requires argument",
Index: ifconfig.h
===================================================================
RCS file: /usr/ncvs/src/sbin/ifconfig/ifconfig.h,v
retrieving revision 1.21
diff -u -r1.21 ifconfig.h
--- ifconfig.h 13 Jun 2007 18:07:59 -0000 1.21
+++ ifconfig.h 30 Mar 2008 19:38:31 -0000
@@ -52,6 +52,7 @@
c_func *c_func;
c_func2 *c_func2;
} c_u;
+ int c_iscloneop;
struct cmd *c_next;
};
void cmd_register(struct cmd *);
@@ -71,6 +72,8 @@
#define DEF_CMD_ARG(name, func) { name, NEXTARG, { .c_func = func } }
#define DEF_CMD_OPTARG(name, func) { name, OPTARG, { .c_func = func } }
#define DEF_CMD_ARG2(name, func) { name, NEXTARG2, { .c_func2 = func } }
+#define DEF_CLONE_CMD(name, param, func) { name, param, { .c_func = func }, 1 }
+#define DEF_CLONE_CMD_ARG(name, func) { name, NEXTARG, { .c_func = func }, 1 }
struct ifaddrs;
struct addrinfo;
Index: ifvlan.c
===================================================================
RCS file: /usr/ncvs/src/sbin/ifconfig/ifvlan.c,v
retrieving revision 1.12
diff -u -r1.12 ifvlan.c
--- ifvlan.c 9 Jul 2006 06:10:23 -0000 1.12
+++ ifvlan.c 30 Mar 2008 19:25:26 -0000
@@ -172,8 +172,8 @@
}
static struct cmd vlan_cmds[] = {
- DEF_CMD_ARG("vlan", setvlantag),
- DEF_CMD_ARG("vlandev", setvlandev),
+ DEF_CLONE_CMD_ARG("vlan", setvlantag),
+ DEF_CLONE_CMD_ARG("vlandev", setvlandev),
/* XXX For compatibility. Should become DEF_CMD() some day. */
DEF_CMD_OPTARG("-vlandev", unsetvlandev),
DEF_CMD("vlanmtu", IFCAP_VLAN_MTU, setifcap),
--------------030506010604030001050708--
From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 11:07:06 2008
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 28A01106581A
for <freebsd-net@hub.freebsd.org>; Mon, 31 Mar 2008 11:07:06 +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 195878FC12
for <freebsd-net@hub.freebsd.org>; Mon, 31 Mar 2008 11:07:06 +0000 (UTC)
(envelope-from owner-bugmaster@FreeBSD.org)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2VB7560038991
for <freebsd-net@FreeBSD.org>; Mon, 31 Mar 2008 11:07:05 GMT
(envelope-from owner-bugmaster@FreeBSD.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2VB75OC038987
for freebsd-net@FreeBSD.org; Mon, 31 Mar 2008 11:07:05 GMT
(envelope-from owner-bugmaster@FreeBSD.org)
Date: Mon, 31 Mar 2008 11:07:05 GMT
Message-Id: <200803311107.m2VB75OC038987@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, 31 Mar 2008 11:07:06 -0000
Current FreeBSD problem reports
Critical problems
Serious problems
S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri
a kern/38554 net changing interface ipaddress doesn't seem to work
s kern/39937 net ipstealth issue
s kern/81147 net [net] [patch] em0 reinitialization while adding aliase
s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument (regress
o kern/92090 net [bge] bge0: watchdog timeout -- resetting
f kern/92552 net A serious bug in most network drivers from 5.X to 6.X
o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr
s kern/105943 net Network stack may modify read-only mbuf chain copies
o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets
o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL
o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p
o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38
o kern/112722 net [udp] IP v4 udp fragmented packet reject
o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi
o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support
o kern/114839 net [fxp] fxp looses ability to speak with traffic
o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat
o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast
f kern/116172 net [tun] [panic] Network / ipv6 recursive mutex panic
o kern/116185 net [iwi] if_iwi driver leads system to reboot
o kern/116328 net [bge]: Solid hang with bge interface
o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile
o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic
o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM
o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap
o kern/117423 net [vlan] Duplicate IP on different interfaces
o kern/117448 net [carp] 6.2 kernel crash (regression)
o kern/118880 net [ipv6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented
o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card (regr
o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n
o kern/119361 net [bge] bge(4) transmit performance problem
o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel
o kern/120130 net [carp] [panic] carp causes kernel panics in any conste
o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc
o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time
f kern/120725 net [bce] On board second lan port 'bce1' with Broadcom Ne
f kern/120966 net [rum]: kernel panic with if_rum and WPA encryption
o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi
o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA
o kern/121555 net Fatal trap 12: current process = 12 (swi1: net)
o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to
o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711
o kern/121983 net [fxp] fxp0 MBUF and PAE
o kern/122033 net [ral] Lock order reversal in ral0 at bootup (regressio
o kern/122058 net [em] [panic] Panic on em1: taskq
o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop
47 problems total.
Non-critical problems
S Tracker Resp. Description
--------------------------------------------------------------------------------
o conf/23063 net [PATCH] for static ARP tables in rc.network
s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr
o kern/54383 net [nfs] [patch] NFS root configurations without dynamic
s kern/60293 net FreeBSD arp poison patch
o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3
o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4)
o bin/79228 net [patch] extend /sbin/arp to be able to create blackhol
o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo
o kern/95267 net packet drops periodically appear
o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return
o kern/100519 net [netisr] suggestion to fix suboptimal network polling
o kern/102035 net [plip] plip networking disables parallel port printing
o conf/102502 net [patch] ifconfig name does't rename netgraph node in n
o conf/107035 net [patch] bridge interface given in rc.conf not taking a
o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop
o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego
o bin/112557 net [patch] ppp(8) lock file should not use symlink name
o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f
o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta
o bin/117339 net [patch] route(8): loading routing management commands
o kern/118727 net [ng] [patch] [request] add new ng_pf module
a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch
o kern/118975 net [bge] [patch] Broadcom 5906 not handled by FreeBSD
o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor
o kern/119432 net [arp] route add -host <host> -iface <nic> causes arp e
o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown
o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol
o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6
o kern/120566 net [request]: ifconfig(8) make order of arguments more fr
o kern/120958 net no response to ICMP traffic on interface configured wi
o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't
o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic
o kern/121443 net [gif] LOR icmp6_input/nd6_lookup
o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit
s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net
o kern/122068 net [ppp] ppp can not set the correct interface with pptpd
36 problems total.
From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 12:25:33 2008
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 870FE106564A;
Mon, 31 Mar 2008 12:25:33 +0000 (UTC)
(envelope-from bms@incunabulum.net)
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com
[66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 49B198FC24;
Mon, 31 Mar 2008 12:25:33 +0000 (UTC)
(envelope-from bms@incunabulum.net)
Received: from compute2.internal (compute2.internal [10.202.2.42])
by out1.messagingengine.com (Postfix) with ESMTP id B94F4E46CF;
Mon, 31 Mar 2008 08:25:32 -0400 (EDT)
Received: from heartbeat2.messagingengine.com ([10.202.2.161])
by compute2.internal (MEProxy); Mon, 31 Mar 2008 08:25:32 -0400
X-Sasl-enc: fsSfxK1KalipsDCaTWI4pzoag1sd1K1K6SspjfBe2Baf 1206966332
Received: from empiric.lon.incunabulum.net
(82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254])
by mail.messagingengine.com (Postfix) with ESMTPSA id 026CF2B42C;
Mon, 31 Mar 2008 08:25:31 -0400 (EDT)
Message-ID: <47F0D83B.7070506@incunabulum.net>
Date: Mon, 31 Mar 2008 13:25:31 +0100
From: Bruce M Simpson <bms@incunabulum.net>
User-Agent: Thunderbird 2.0.0.9 (X11/20080207)
MIME-Version: 1.0
To: freebsd-net@FreeBSD.org, dhartmei@FreeBSD.org,
Max Laier <max@love2party.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Pavlin Radoslavov <pavlin@icir.org>
Subject: Unbreaking igmp with pf.
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, 31 Mar 2008 12:25:33 -0000
Hi all,
Just to follow up on my message last week.
If I don't hear further feedback, I am likely to commit code which
allows IP Router Alert options through the pf firewall by default.
For further background read on.
cheers
BMS
----------------
The lack of support for allowing the IP Router Alert option
(henceforth: RA)
by default in pf is problematic for the widespread deployment of IGMPv3.
It's also bit some people who have been trying to set up multicast capable
routers, even without IGMPv3, as FreeBSD sends RA by default in IGMP and has
done since the 3.x era.
Currently, PF has no capability to parse IP options, and defaults to
dropping
traffic which contains them. In day to day deployment, the most used option
is in fact RA.
The meaning of RA is quite simple: all routers on the path must examine the
datagram. It is described in RFC 2113. Currently FreeBSD's forwarding plane
performs no special processing of RA.
Whilst RA came into existence well into after, RFC 3376 extends the
notion of
IGMP to make the use of RA mandatory. It's reasonable to do this, given that
vendor kit is intended to do it. It also helps IGMP snooping switches spot
the group joins. It is also used with MPLS and RSVP.
"So what?", I hear you cry. Yes, but if outgoing IGMP is being squelched
at the host, it breaks IP multicasting for everything but the most
trivial cases (i.e. service discovery at 1 hop, pfsync, etc).
Furthermore... if you don't send IGMP for link-scope groups (224.0.0.0/24),
it will break them anyway if the switch is configured to prune link-layer
multicast traffic.
Options:
1. Change default in FreeBSD pf import to ip options enabled.
2. Add code to pf to simply allow the RA option by default.
[I'm happiest with this one.]
3. Add code to the options path in pf to decode options, if and only if
options are allowed, and add a mask specifying the allowed values.
For reference, the IANA list of IP option numbers is here:
http://www.iana.org/assignments/ip-parameters
...most of those are never used in practice. RA is. There are 30
possibilities specified for an 8-bit-wide space; the minimal mask fits
in 32 bits; the maximal mask is therefore 256 bits.
There is some overlap between 2 and 3; FreeBSD's kernel only tacks on 4
bytes
to the IP header in outgoing router alert traffic, userland apps may do
different things.
So, if I don't hear more feedback from folk, I am likely to commit code
which
implements option 2.
From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 13:27:02 2008
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 ECE4D106564A;
Mon, 31 Mar 2008 13:27:02 +0000 (UTC)
(envelope-from eugen@grosbein.pp.ru)
Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.166])
by mx1.freebsd.org (Postfix) with ESMTP id 252C88FC1D;
Mon, 31 Mar 2008 13:27:01 +0000 (UTC)
(envelope-from eugen@grosbein.pp.ru)
Received: from grosbein.pp.ru (localhost [127.0.0.1])
by grosbein.pp.ru (8.14.2/8.14.2) with ESMTP id m2VCpvlm001556;
Mon, 31 Mar 2008 20:51:57 +0800 (KRAST)
(envelope-from eugen@grosbein.pp.ru)
Received: (from eugen@localhost)
by grosbein.pp.ru (8.14.2/8.14.2/Submit) id m2VCpvF1001555;
Mon, 31 Mar 2008 20:51:57 +0800 (KRAST) (envelope-from eugen)
Date: Mon, 31 Mar 2008 20:51:57 +0800
From: Eugene Grosbein <eugen@grosbein.pp.ru>
To: Sam Leffler <sam@freebsd.org>
Message-ID: <20080331125157.GA1542@grosbein.pp.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <47F003C8.6080605@freebsd.org>
User-Agent: Mutt/1.4.2.2i
Cc: net@freebsd.org
Subject: Re: 7.0 - ifconfig create is not working as expected? [patch 2]
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, 31 Mar 2008 13:27:03 -0000
> Try this.
I've tried your second patch for RELENG_7 and it works, thank you!
Please commit.
Eugene Grosbein
From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 16:01:07 2008
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 C21641065671;
Mon, 31 Mar 2008 16:01:07 +0000 (UTC)
(envelope-from gavin@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
[IPv6:2001:4f8:fff6::28])
by mx1.freebsd.org (Postfix) with ESMTP id A38748FC1D;
Mon, 31 Mar 2008 16:01:07 +0000 (UTC)
(envelope-from gavin@FreeBSD.org)
Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1])
by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2VG175f082337;
Mon, 31 Mar 2008 16:01:07 GMT
(envelope-from gavin@freefall.freebsd.org)
Received: (from gavin@localhost)
by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2VG17mT082333;
Mon, 31 Mar 2008 16:01:07 GMT (envelope-from gavin)
Date: Mon, 31 Mar 2008 16:01:07 GMT
Message-Id: <200803311601.m2VG17mT082333@freefall.freebsd.org>
To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org
From: gavin@FreeBSD.org
Cc:
Subject: Re: kern/122145: error while compiling with device ath_rate_amrr
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, 31 Mar 2008 16:01:07 -0000
Synopsis: error while compiling with device ath_rate_amrr
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Mon Mar 31 15:57:16 UTC 2008
Responsible-Changed-Why:
Over to -net mailing list. Is compiling ath_rate_amrr into the kernel
supported at all? There's no mention of it in the ath_rate man page
http://www.freebsd.org/cgi/query-pr.cgi?pr=122145
From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 17:47:40 2008
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 B050C1065674;
Mon, 31 Mar 2008 17:47:40 +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 779AB8FC45;
Mon, 31 Mar 2008 17:47:40 +0000 (UTC)
(envelope-from linimon@FreeBSD.org)
Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1])
by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2VHleNA094760;
Mon, 31 Mar 2008 17:47:40 GMT
(envelope-from linimon@freefall.freebsd.org)
Received: (from linimon@localhost)
by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2VHledb094756;
Mon, 31 Mar 2008 17:47:40 GMT (envelope-from linimon)
Date: Mon, 31 Mar 2008 17:47:40 GMT
Message-Id: <200803311747.m2VHledb094756@freefall.freebsd.org>
To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org
From: linimon@FreeBSD.org
Cc:
Subject: Re: kern/122295: [bge] bge Ierr rate increase (since 6.0R)
(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: Mon, 31 Mar 2008 17:47:40 -0000
Synopsis: [bge] bge Ierr rate increase (since 6.0R) (regression)
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Mar 31 17:47:28 UTC 2008
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=122295
From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 18:04:21 2008
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 59BB4106564A;
Mon, 31 Mar 2008 18:04:21 +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 30F7A8FC24;
Mon, 31 Mar 2008 18:04:21 +0000 (UTC)
(envelope-from linimon@FreeBSD.org)
Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1])
by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2VI4K13096226;
Mon, 31 Mar 2008 18:04:20 GMT
(envelope-from linimon@freefall.freebsd.org)
Received: (from linimon@localhost)
by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2VI4KNp096222;
Mon, 31 Mar 2008 18:04:20 GMT (envelope-from linimon)
Date: Mon, 31 Mar 2008 18:04:20 GMT
Message-Id: <200803311804.m2VI4KNp096222@freefall.freebsd.org>
To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org
From: linimon@FreeBSD.org
Cc:
Subject: Re: kern/122290: [netgraph] [panic] Netgraph related "kmem_map too
small" panics
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, 31 Mar 2008 18:04:21 -0000
Old Synopsis: Netgraph related "kmem_map too small" panics
New Synopsis: [netgraph] [panic] Netgraph related "kmem_map too small" panics
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Mar 31 18:04:02 UTC 2008
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=122290
From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 18:50:03 2008
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 8EF4E1065674
for <freebsd-net@hub.freebsd.org>; Mon, 31 Mar 2008 18:50:03 +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 7F1FC8FC20
for <freebsd-net@hub.freebsd.org>; Mon, 31 Mar 2008 18:50:03 +0000 (UTC)
(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1])
by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2VIo3bm002362
for <freebsd-net@freefall.freebsd.org>; Mon, 31 Mar 2008 18:50:03 GMT
(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2VIo3aw002361;
Mon, 31 Mar 2008 18:50:03 GMT (envelope-from gnats)
Date: Mon, 31 Mar 2008 18:50:03 GMT
Message-Id: <200803311850.m2VIo3aw002361@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: dfilter@FreeBSD.org (dfilter service)
Cc:
Subject: Re: kern/122145: commit references a PR
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dfilter service <dfilter@FreeBSD.org>
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, 31 Mar 2008 18:50:03 -0000
The following reply was made to PR kern/122145; it has been noted by GNATS.
From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:
Subject: Re: kern/122145: commit references a PR
Date: Mon, 31 Mar 2008 18:49:16 +0000 (UTC)
sam 2008-03-31 18:49:09 UTC
FreeBSD src repository
Modified files:
sys/conf files
Log:
add include path required to find ah_osdep.h
PR: kern/122145
MFC after: 3 days
Revision Changes Path
1.1286 +2 -1 src/sys/conf/files
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 23:50:41 2008
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 ACD3C106564A
for <freebsd-net@freebsd.org>; Mon, 31 Mar 2008 23:50:41 +0000 (UTC)
(envelope-from kvilius.simas@gmail.com)
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182])
by mx1.freebsd.org (Postfix) with ESMTP id 6FF0A8FC2B
for <freebsd-net@freebsd.org>; Mon, 31 Mar 2008 23:50:41 +0000 (UTC)
(envelope-from kvilius.simas@gmail.com)
Received: by py-out-1112.google.com with SMTP id u52so2669988pyb.10
for <freebsd-net@freebsd.org>; Mon, 31 Mar 2008 16:50:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
bh=ltoxmwqFd5ZOWDo4pXTtKCGcNuQB6IqDdJ/Gmha3QPg=;
b=t4RSzE3RDetnYhW/Zicd1QAdBwirU+VDxRUW0Ck7I84G116IbZXgIxGBzTeyJN10GsH7lhChyKDRpMvOJsLiJ7iaWvvcuwXMqsLA8oBuGZ91faDlOjQYAnkXh2Ffx1rXVE4Yudu/xKMcUeiLwwGjoDb8RDmxtH6+cEfiW+k3r3U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
b=mvOlqIF+4tPyonkRZ5At0BZJM1Dk6DRyBGLRA76trqhB8aW8e4aAJ6ZrlA/qLvk0sf/GxoeQhPr5HVoTavmu42gI6+89UKrJrXlFclizFW6xk7vXYtnxdxAqpg6Wu1ZdaQyJ7ZR39AyddaT+U1gnFutqPbTYAfese2CL5gC5W54=
Received: by 10.140.165.21 with SMTP id n21mr2720926rve.289.1207005789309;
Mon, 31 Mar 2008 16:23:09 -0700 (PDT)
Received: by 10.141.49.9 with HTTP; Mon, 31 Mar 2008 16:23:03 -0700 (PDT)
Message-ID: <f30a14450803311623r7e5979cel71e8764eff7e03d@mail.gmail.com>
Date: Tue, 1 Apr 2008 02:23:03 +0300
From: "Simas Kvilius" <kvilius.simas@gmail.com>
To: freebsd-bugbusters@freebsd.org, freebsd-net@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc:
Subject: wi driver ad-hoc demo mode
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, 31 Mar 2008 23:50:41 -0000
I'm using old Lucent orinoco wireless card in ad-hoc demo mode.
It seems someone forgot to implement ad-hoc demo mode in the newest wi
driver (driver which comes with RELENG7). I added following statement
to if_wi.c line 407 to indicate, that my card supports ad-hoc demo
mode (someone definitely forgot to include this):
ic->ic_caps |= IEEE80211_C_AHDEMO;
Now I can enable ad-hoc demo mode using ifconfig utility (with command
ifconfig wi0 mode 11b media DS/11Mbps mediaopt adhoc mediaopt flag0),
but it seems there is another bug. Now I cannot change radio channel
(nic is always stuck in channel 3, i think this channel is hardcoded
as default ibss channel inside my nic).
Could anyone fix this bug with channels (I tried to figure out where
problem is, but it seems I'm to lame to do kernel hacking of this
level by myself). My card was working fine with FreeBSD 5.1 (both with
ifconfig and wicontrol tools) and Linux.
Regards,
Simas
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 05:58:49 2008
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 7E97B1065670
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 05:58:49 +0000 (UTC)
(envelope-from zlat_student@mail.ru)
Received: from wombat.diezmil.com (wombat.diezmil.com [209.190.27.106])
by mx1.freebsd.org (Postfix) with ESMTP id 475408FC27
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 05:58:49 +0000 (UTC)
(envelope-from zlat_student@mail.ru)
Received: from wombat.diezmil.com (wombat.diezmil.com [127.0.0.1])
by wombat.diezmil.com (8.13.8/8.13.8) with ESMTP id m315RgQ5011739
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 01:27:42 -0400
Date: Tue, 1 Apr 2008 01:27:42 -0400
Message-ID: <8041484.1207027662134.JavaMail.root@wombat.diezmil.com>
From: zlat_student@mail.ru
To: freebsd-net@freebsd.org
In-Reply-To: <200803011950.m21Jo3gU003891@freefall.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: Re: kern/118975: [bge] [patch] Broadcom 5906 not handled by
FreeBSD
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: zlat_student@mail.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: Tue, 01 Apr 2008 05:58:49 -0000
After patching kernel by this, http://groups.google.com/group/mailing.freebsd.net/browse_thread/thread/1ca4073751b54f38/2f98a9b681580c09?fwc=1, compiler return next messages:
[code]
/usr/src/sys/dev/bge/if_bge.c:326: warning: 'struct bge_softic' declared inside parameter list
/usr/src/sys/dev/bge/if_bge.c:326: warning: its scope is only this definition or declaration, which is probably not what you want
/usr/src/sys/dev/bge/if_bge.c:327: warning: 'struct bge_softic' declared inside parameter list
/usr/src/sys/dev/bge/if_bge.c:328: warning: 'struct bge_softic' declared inside parameter list
/usr/src/sys/dev/bge/if_bge.c:329: warning: 'struct bge_softic' declared inside parameter list
/usr/src/sys/dev/bge/if_bge.c: In function 'bge_attach':
/usr/src/sys/dev/bge/if_bge.c:2554: warning: passing argument 1 of 'bge_get_eaddr' from incompatible pointer type
/usr/src/sys/dev/bge/if_bge.c: At top level:
/usr/src/sys/dev/bge/if_bge.c:4690: error: conflicting types for 'bge_get_eaddr_mem'
/usr/src/sys/dev/bge/if_bge.c:326: error: previous declaration of 'bge_get_eaddr_mem' was here
/usr/src/sys/dev/bge/if_bge.c:4710: error: conflicting types for 'bge_get_eaddr_nvram'
/usr/src/sys/dev/bge/if_bge.c:327: error: previous declaration of 'bge_get_eaddr_nvram' was here
/usr/src/sys/dev/bge/if_bge.c:4721: error: conflicting types for 'bge_get_eaddr_eeprom'
/usr/src/sys/dev/bge/if_bge.c:328: error: previous declaration of 'bge_get_eaddr_eeprom' was here
/usr/src/sys/dev/bge/if_bge.c:4731: error: conflicting types for 'bge_get_eaddr'
/usr/src/sys/dev/bge/if_bge.c:329: error: previous declaration of 'bge_get_eaddr' was here
[/code]
What can I do for resolve this problem?
--
This message was sent on behalf of zlat_student@mail.ru at openSubscriber.com
http://www.opensubscriber.com/message/freebsd-net@freebsd.org/8716454.html
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 06:00:20 2008
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 0597C1065675
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 06:00:20 +0000 (UTC)
(envelope-from root@mmu.edu.my)
Received: from staff.cyber.mmu.edu.my (staff.cyber.mmu.edu.my [203.106.62.12])
by mx1.freebsd.org (Postfix) with ESMTP id 815048FC19
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 06:00:19 +0000 (UTC)
(envelope-from root@mmu.edu.my)
Received: by staff.cyber.mmu.edu.my (Postfix, from userid 0)
id 27CAB4D4718; Tue, 1 Apr 2008 13:35:44 +0800 (MYT)
Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53])
by mmu.edu.my (Postfix) with ESMTP id 9952E55E4B0
for <opal@mmu.edu.my>; Sat, 29 Mar 2008 06:54:56 +0800 (MYT)
Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36])
by mx2.freebsd.org (Postfix) with ESMTP id 6CA08153A9D;
Fri, 28 Mar 2008 17:32:04 +0000 (UTC)
(envelope-from owner-freebsd-performance@freebsd.org)
Received: from hub.freebsd.org (localhost [127.0.0.1])
by hub.freebsd.org (Postfix) with ESMTP id 60CB01065678;
Fri, 28 Mar 2008 17:32:03 +0000 (UTC)
(envelope-from owner-freebsd-performance@freebsd.org)
Delivered-To: performance@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id E8800106564A;
Fri, 28 Mar 2008 17:31:55 +0000 (UTC) (envelope-from ap00@mail.ru)
Received: from mx0.awanti.com (mx0.awanti.com [91.190.112.18])
by mx1.freebsd.org (Postfix) with ESMTP id A2DE38FC15;
Fri, 28 Mar 2008 17:31:55 +0000 (UTC) (envelope-from ap00@mail.ru)
Received: by mx0.awanti.com (Postfix, from userid 100)
id F1AF74C022; Fri, 28 Mar 2008 20:13:18 +0300 (MSK)
X-Spam-Flag: NO
X-Spam-Checker-Version: SpamAssassin 3.1.9 on mx0.awanti.com
X-Spam-Status: No, score=-2.3 required=6.5 tests=AWL,BAYES_00 autolearn=ham
version=3.1.9
Received: from pstation (unknown [10.28.4.14])
by mx0.awanti.com (Postfix) with ESMTP id 467204C019;
Fri, 28 Mar 2008 20:13:17 +0300 (MSK)
Date: Fri, 28 Mar 2008 20:14:58 +0300
From: Anthony Pankov <ap00@mail.ru>
X-Mailer: The Bat! (v1.51) Personal
X-Priority: 3 (Normal)
Message-ID: <1333421734.20080328201458@mail.ru>
To: freebsd-net@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-performance@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Sender: owner-freebsd-performance@freebsd.org
Errors-To: owner-freebsd-performance@freebsd.org
Cc: performance@freebsd.org
Subject: packet delay because of blackhole
X-BeenThere: freebsd-net@freebsd.org
Reply-To: Anthony Pankov <ap00@mail.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: Tue, 01 Apr 2008 06:00:20 -0000
Just for somebody convince.
While analyzing client<->server HTTPS conversation one second delay in
packet exchange was discovered (strongly reproducible):
Sample:
N time
6 0.002303 10.28.4.14 10.28.4.50 SSL Client Hello
7 0.106710 10.28.4.50 10.28.4.14 TCP 443 > 1447 [ACK] Seq=1 Ack=103 Win=65535 Len=0
8 1.045712 10.28.4.50 10.28.4.14 TLSv1 Server Hello, Certificate, Server Hello Done
Another sample:
10 0.011722 10.28.4.14 10.28.4.50 TLSv1 Application Data
11 0.115933 10.28.4.50 10.28.4.14 TCP 443 > 1442 [ACK] Seq=839 Ack=519 Win=65466 Len=0
12 1.054037 10.28.4.50 10.28.4.14 TLSv1 Application Data
The reason for delay is sysctl tcp.blackhole value grater than 0, much to surprise.
So, turning tcp.blackhole to 0 eliminate any delay (strongly reproducible).
System: FreeBSD 6_2_stable
--
Best regards,
Anthony mailto:ap00@mail.ru
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 06:10:42 2008
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 6CF5B106564A;
Tue, 1 Apr 2008 06:10:42 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: from staff.cyber.mmu.edu.my (staff.cyber.mmu.edu.my [203.106.62.12])
by mx1.freebsd.org (Postfix) with ESMTP id B1C938FC2A;
Tue, 1 Apr 2008 06:10:41 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: by staff.cyber.mmu.edu.my (Postfix, from userid 0)
id 6DE744D49C3; Tue, 1 Apr 2008 14:10:10 +0800 (MYT)
Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53])
by mmu.edu.my (Postfix) with ESMTP id 02FCC55E491
for <opal@mmu.edu.my>; Sun, 30 Mar 2008 17:50:19 +0800 (MYT)
Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36])
by mx2.freebsd.org (Postfix) with ESMTP id 383861608B7;
Sun, 30 Mar 2008 09:49:37 +0000 (UTC)
(envelope-from owner-freebsd-hackers@freebsd.org)
Received: from hub.freebsd.org (localhost [127.0.0.1])
by hub.freebsd.org (Postfix) with ESMTP id B79711065705;
Sun, 30 Mar 2008 09:49:36 +0000 (UTC)
(envelope-from owner-freebsd-hackers@freebsd.org)
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id 2E117106566B;
Sun, 30 Mar 2008 09:49:29 +0000 (UTC) (envelope-from mav@FreeBSD.org)
Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121])
by mx1.freebsd.org (Postfix) with ESMTP id 73A788FC12;
Sun, 30 Mar 2008 09:49:28 +0000 (UTC) (envelope-from mav@FreeBSD.org)
X-Spam-Flag: SKIP
X-Spam-Yversion: Spamooborona-2.1.0
Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2])
by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14)
with ESMTPA id 99987913; Sun, 30 Mar 2008 12:49:27 +0300
Message-ID: <47EF6226.3090808@FreeBSD.org>
Date: Sun, 30 Mar 2008 12:49:26 +0300
From: Alexander Motin <mav@FreeBSD.org>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Hans Petter Selasky <hselasky@c2i.net>
References: <47EF4F18.502@FreeBSD.org> <200803301114.43336.hselasky@c2i.net>
In-Reply-To: <200803301114.43336.hselasky@c2i.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Sender: owner-freebsd-hackers@freebsd.org
Errors-To: owner-freebsd-hackers@freebsd.org
Cc: freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org>
Subject: Re: Multiple netgraph threads
X-BeenThere: freebsd-net@freebsd.org
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, 01 Apr 2008 06:10:42 -0000
Hans Petter Selasky wrote:
> Have you thought about nodes that lock the same mutex must be run on the same
> thread else for example one thread will run while another will just waits for
> a mutex ?
Usually different nodes does not share data, keeping them inside
node/hook private data, so I don't see problem here. It is possible that
two messages will be queued to the same node at same time, but to fulfil
serialization requirements each node queue processed only by one thread
at a time, so there is no place for congestion.
> You can achieve this by grouping nodes into a tree, and the node at the top of
> the tree decides on which thread the nodes in the tree should be run.
Netgraph graphs usually not linear and it is from hard to impossible to
predict the way execution will go and the locks that may be congested.
Including usually big number of nodes and usually small lock time,
congestion probability IMHO looks insignificant comparing to additional
logic overhead. If some node/hook needs big lock time it may be instead
declared as FORCE_WRITER to enqueue congested messages instead of
blocking them (such way now implemented all existing ppp
compression/encryption nodes).
--
Alexander Motin
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 06:13:23 2008
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 690AF1065672;
Tue, 1 Apr 2008 06:13:23 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: from staff.cyber.mmu.edu.my (staff.cyber.mmu.edu.my [203.106.62.12])
by mx1.freebsd.org (Postfix) with ESMTP id A027F8FC2B;
Tue, 1 Apr 2008 06:13:13 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: by staff.cyber.mmu.edu.my (Postfix, from userid 0)
id C92934D4979; Tue, 1 Apr 2008 14:12:13 +0800 (MYT)
Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53])
by mmu.edu.my (Postfix) with ESMTP id 3258E55E4B2
for <opal@mmu.edu.my>; Sun, 30 Mar 2008 16:29:50 +0800 (MYT)
Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36])
by mx2.freebsd.org (Postfix) with ESMTP id 3BC921601A8;
Sun, 30 Mar 2008 08:28:27 +0000 (UTC)
(envelope-from owner-freebsd-hackers@freebsd.org)
Received: from hub.freebsd.org (localhost [127.0.0.1])
by hub.freebsd.org (Postfix) with ESMTP id B617010656A7;
Sun, 30 Mar 2008 08:28:25 +0000 (UTC)
(envelope-from owner-freebsd-hackers@freebsd.org)
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id 68C77106566C
for <freebsd-hackers@freebsd.org>; Sun, 30 Mar 2008 08:28:17 +0000 (UTC)
(envelope-from mav@FreeBSD.org)
Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121])
by mx1.freebsd.org (Postfix) with ESMTP id AFADC8FC14
for <freebsd-hackers@freebsd.org>; Sun, 30 Mar 2008 08:28:16 +0000 (UTC)
(envelope-from mav@FreeBSD.org)
X-Spam-Flag: SKIP
X-Spam-Yversion: Spamooborona-2.1.0
Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2])
by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14)
with ESMTPA id 99970234; Sun, 30 Mar 2008 11:28:15 +0300
Message-ID: <47EF4F18.502@FreeBSD.org>
Date: Sun, 30 Mar 2008 11:28:08 +0300
From: Alexander Motin <mav@FreeBSD.org>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Sender: owner-freebsd-hackers@freebsd.org
Errors-To: owner-freebsd-hackers@freebsd.org
Cc:
Subject: Multiple netgraph threads
X-BeenThere: freebsd-net@freebsd.org
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, 01 Apr 2008 06:13:23 -0000
Hi.
I have implemented a patch (for the HEAD) making netgraph to use several
own threads for event queues processing instead of using single swinet.
It should significantly improve netgraph SMP scalability on complicated
workloads that require queueing by implementation (PPTP/L2TP) or stack
size limitations. It works perfectly on my UP system, showing results
close to original or even a bit better. I have no real SMP test server
to measure real scalability, but test on HTT CPU works fine, utilizing
both virtual cores at the predictable level.
Reviews and feedbacks are welcome.
URL: http://people.freebsd.org/~mav/netgraph.threads.patch
--
Alexander Motin
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 06:16:14 2008
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 DC100106566C;
Tue, 1 Apr 2008 06:16:13 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: from staff.cyber.mmu.edu.my (staff.cyber.mmu.edu.my [203.106.62.12])
by mx1.freebsd.org (Postfix) with ESMTP id 225E08FC25;
Tue, 1 Apr 2008 06:16:13 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: by staff.cyber.mmu.edu.my (Postfix, from userid 0)
id 46F404D4C61; Tue, 1 Apr 2008 14:15:21 +0800 (MYT)
Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53])
by mmu.edu.my (Postfix) with ESMTP id 5BA1355E4AF
for <opal@mmu.edu.my>; Sun, 30 Mar 2008 19:23:08 +0800 (MYT)
Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36])
by mx2.freebsd.org (Postfix) with ESMTP id 01426163DE5;
Sun, 30 Mar 2008 11:22:27 +0000 (UTC)
(envelope-from owner-freebsd-hackers@freebsd.org)
Received: from hub.freebsd.org (localhost [127.0.0.1])
by hub.freebsd.org (Postfix) with ESMTP id 14B7210657CE;
Sun, 30 Mar 2008 11:22:21 +0000 (UTC)
(envelope-from owner-freebsd-hackers@freebsd.org)
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id AACBE106566B;
Sun, 30 Mar 2008 11:22:09 +0000 (UTC) (envelope-from mav@FreeBSD.org)
Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121])
by mx1.freebsd.org (Postfix) with ESMTP id F10388FC1C;
Sun, 30 Mar 2008 11:22:08 +0000 (UTC) (envelope-from mav@FreeBSD.org)
X-Spam-Flag: SKIP
X-Spam-Yversion: Spamooborona-2.1.0
Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2])
by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14)
with ESMTPA id 100031004; Sun, 30 Mar 2008 14:22:07 +0300
Message-ID: <47EF77DE.6040200@FreeBSD.org>
Date: Sun, 30 Mar 2008 14:22:06 +0300
From: Alexander Motin <mav@FreeBSD.org>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Robert Watson <rwatson@FreeBSD.org>
References: <47EF4F18.502@FreeBSD.org> <20080330112846.Y5921@fledge.watson.org>
In-Reply-To: <20080330112846.Y5921@fledge.watson.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Sender: owner-freebsd-hackers@freebsd.org
Errors-To: owner-freebsd-hackers@freebsd.org
Cc: freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org>
Subject: Re: Multiple netgraph threads
X-BeenThere: freebsd-net@freebsd.org
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, 01 Apr 2008 06:16:14 -0000
Robert Watson wrote:
> FYI, you might be interested in some similar work I've been doing
> in the rwatson_netisr branch in Perforce, which:
> Adds per-CPU netisr threads
Thanks. Netgraph from the beginning uses concept of direct function
calls, when level of parallelism limited by data source. In that point
multiple netisr threads will give benefits.
> My initial leaning would be that we would like to avoid adding too many
> more threads that will do per-packet work, as that leads to excessive
> context switching.
Netgraph uses queueing only as last resort, when direct call is not
possible due to locking or stack limitations. For example, while working
with kernel sockets (*upcall)() I have got many issues which make
impossible to freely use received data without queueing as upcall()
caller holds some locks leading to unpredicted LORs in socket/TCP/UDP code.
In case of such forced queueing, node becomes an independent data source
which can be pinned to and processed by whatever specialized thread or
netisr, when it will be able to do it more effectively.
--
Alexander Motin
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 06:20:41 2008
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 3AB391065673;
Tue, 1 Apr 2008 06:20:41 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: from staff.cyber.mmu.edu.my (staff.cyber.mmu.edu.my [203.106.62.12])
by mx1.freebsd.org (Postfix) with ESMTP id 7A7D98FC13;
Tue, 1 Apr 2008 06:20:40 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: by staff.cyber.mmu.edu.my (Postfix, from userid 0)
id 672074D5177; Tue, 1 Apr 2008 14:19:22 +0800 (MYT)
Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53])
by mmu.edu.my (Postfix) with ESMTP id CC7DD55E4A3
for <opal@mmu.edu.my>; Sun, 30 Mar 2008 21:44:10 +0800 (MYT)
Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36])
by mx2.freebsd.org (Postfix) with ESMTP id 4CF2F161893;
Sun, 30 Mar 2008 13:27:36 +0000 (UTC)
(envelope-from owner-freebsd-hackers@freebsd.org)
Received: from hub.freebsd.org (localhost [127.0.0.1])
by hub.freebsd.org (Postfix) with ESMTP id 8B33010656D8;
Sun, 30 Mar 2008 13:27:34 +0000 (UTC)
(envelope-from owner-freebsd-hackers@freebsd.org)
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id 5CFBA106564A;
Sun, 30 Mar 2008 13:27:23 +0000 (UTC)
(envelope-from rwatson@FreeBSD.org)
Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42])
by mx1.freebsd.org (Postfix) with ESMTP id 3D59F8FC14;
Sun, 30 Mar 2008 13:27:23 +0000 (UTC)
(envelope-from rwatson@FreeBSD.org)
Received: from fledge.watson.org (fledge.watson.org [209.31.154.41])
by cyrus.watson.org (Postfix) with ESMTP id D68CE46B3B;
Sun, 30 Mar 2008 09:27:22 -0400 (EDT)
Date: Sun, 30 Mar 2008 14:27:22 +0100 (BST)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: Alexander Motin <mav@FreeBSD.org>
In-Reply-To: <47EF77DE.6040200@FreeBSD.org>
Message-ID: <20080330142332.Y5921@fledge.watson.org>
References: <47EF4F18.502@FreeBSD.org> <20080330112846.Y5921@fledge.watson.org>
<47EF77DE.6040200@FreeBSD.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Sender: owner-freebsd-hackers@freebsd.org
Errors-To: owner-freebsd-hackers@freebsd.org
Cc: freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org>
Subject: Re: Multiple netgraph threads
X-BeenThere: freebsd-net@freebsd.org
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, 01 Apr 2008 06:20:41 -0000
On Sun, 30 Mar 2008, Alexander Motin wrote:
>> My initial leaning would be that we would like to avoid adding too many
>> more threads that will do per-packet work, as that leads to excessive
>> context switching.
>
> Netgraph uses queueing only as last resort, when direct call is not possible
> due to locking or stack limitations. For example, while working with kernel
> sockets (*upcall)() I have got many issues which make impossible to freely
> use received data without queueing as upcall() caller holds some locks
> leading to unpredicted LORs in socket/TCP/UDP code. In case of such forced
> queueing, node becomes an independent data source which can be pinned to and
> processed by whatever specialized thread or netisr, when it will be able to
> do it more effectively.
I guess my caution is that it does not necessarily follow from a design that
allows for explicit parallelism that the implementation will use it well, and
that any time context switchs are necessarily introduced, cost goes up. The
move to direct dispatch from the ithread, despite reducing opportunities for
parallelism, significantly increased performance for many local workloads.
If we have a netisr thread, an ithread, and a netgraph thread, the potential
context switch overhead is significant, even if we are doing a good job at
batching work transfer between them. Often times, the way this behaves in
practice is quite dependent on scheduling, and right now we have known
defficiencies in this area, so give it a try on an SMP box and see what
happens. Since you're a FreeBSD committer, you can sign up to use the netperf
cluster, which might not be a bad idea if you don't have local access to a
good SMP test setup.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 06:21:01 2008
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 780541065689;
Tue, 1 Apr 2008 06:21:01 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: from staff.cyber.mmu.edu.my (staff.cyber.mmu.edu.my [203.106.62.12])
by mx1.freebsd.org (Postfix) with ESMTP id BDD338FC23;
Tue, 1 Apr 2008 06:21:00 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: by staff.cyber.mmu.edu.my (Postfix, from userid 0)
id B84B94D4DD4; Tue, 1 Apr 2008 14:19:49 +0800 (MYT)
Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53])
by mmu.edu.my (Postfix) with ESMTP id D78AA55E4AF
for <opal@mmu.edu.my>; Sun, 30 Mar 2008 17:14:22 +0800 (MYT)
Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36])
by mx2.freebsd.org (Postfix) with ESMTP id 055581529E7;
Sun, 30 Mar 2008 09:13:48 +0000 (UTC)
(envelope-from owner-freebsd-hackers@freebsd.org)
Received: from hub.freebsd.org (localhost [127.0.0.1])
by hub.freebsd.org (Postfix) with ESMTP id 1B0B210656A6;
Sun, 30 Mar 2008 09:13:44 +0000 (UTC)
(envelope-from owner-freebsd-hackers@freebsd.org)
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id 319041065670;
Sun, 30 Mar 2008 09:13:36 +0000 (UTC)
(envelope-from hselasky@c2i.net)
Received: from swip.net (mailfe05.swip.net [212.247.154.129])
by mx1.freebsd.org (Postfix) with ESMTP id 6DE0A8FC21;
Sun, 30 Mar 2008 09:13:35 +0000 (UTC)
(envelope-from hselasky@c2i.net)
X-Cloudmark-Score: 0.000000 []
Received: from [62.113.132.89] (account mc467741@c2i.net [62.113.132.89]
verified) by mailfe05.swip.net (CommuniGate Pro SMTP 5.1.13)
with ESMTPA id 773504940; Sun, 30 Mar 2008 11:13:33 +0200
From: Hans Petter Selasky <hselasky@c2i.net>
To: freebsd-hackers@freebsd.org,
FreeBSD Net <freebsd-net@freebsd.org>
Date: Sun, 30 Mar 2008 11:14:42 +0200
User-Agent: KMail/1.9.7
References: <47EF4F18.502@FreeBSD.org>
In-Reply-To: <47EF4F18.502@FreeBSD.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200803301114.43336.hselasky@c2i.net>
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Sender: owner-freebsd-hackers@freebsd.org
Errors-To: owner-freebsd-hackers@freebsd.org
Cc: Alexander Motin <mav@freebsd.org>
Subject: Re: Multiple netgraph threads
X-BeenThere: freebsd-net@freebsd.org
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, 01 Apr 2008 06:21:01 -0000
Hi,
Have you thought about nodes that lock the same mutex must be run on the same
thread else for example one thread will run while another will just waits for
a mutex ?
You can achieve this by grouping nodes into a tree, and the node at the top of
the tree decides on which thread the nodes in the tree should be run.
How does your patch handle this ?
Also see recent discussion about multithreaded callouts
on "freebsd-arch@freebsd.org". Subject "timeout/callout small step forward".
--HPS
On Sunday 30 March 2008, Alexander Motin wrote:
> Hi.
>
> I have implemented a patch (for the HEAD) making netgraph to use several
> own threads for event queues processing instead of using single swinet.
> It should significantly improve netgraph SMP scalability on complicated
> workloads that require queueing by implementation (PPTP/L2TP) or stack
> size limitations. It works perfectly on my UP system, showing results
> close to original or even a bit better. I have no real SMP test server
> to measure real scalability, but test on HTT CPU works fine, utilizing
> both virtual cores at the predictable level.
>
> Reviews and feedbacks are welcome.
>
> URL: http://people.freebsd.org/~mav/netgraph.threads.patch
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 06:22:02 2008
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 173DE1065672;
Tue, 1 Apr 2008 06:22:02 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: from staff.cyber.mmu.edu.my (staff.cyber.mmu.edu.my [203.106.62.12])
by mx1.freebsd.org (Postfix) with ESMTP id 615688FC13;
Tue, 1 Apr 2008 06:22:01 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: by staff.cyber.mmu.edu.my (Postfix, from userid 0)
id 6780C4D4FFB; Tue, 1 Apr 2008 14:20:29 +0800 (MYT)
Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53])
by mmu.edu.my (Postfix) with ESMTP id EBD8855E4AF
for <opal@mmu.edu.my>; Sun, 30 Mar 2008 18:35:28 +0800 (MYT)
Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36])
by mx2.freebsd.org (Postfix) with ESMTP id 2E431152F9C;
Sun, 30 Mar 2008 10:34:32 +0000 (UTC)
(envelope-from owner-freebsd-hackers@freebsd.org)
Received: from hub.freebsd.org (localhost [127.0.0.1])
by hub.freebsd.org (Postfix) with ESMTP id E377F10656BF;
Sun, 30 Mar 2008 10:34:30 +0000 (UTC)
(envelope-from owner-freebsd-hackers@freebsd.org)
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id E77D3106566B;
Sun, 30 Mar 2008 10:34:21 +0000 (UTC)
(envelope-from rwatson@FreeBSD.org)
Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42])
by mx1.freebsd.org (Postfix) with ESMTP id C82AE8FC16;
Sun, 30 Mar 2008 10:34:21 +0000 (UTC)
(envelope-from rwatson@FreeBSD.org)
Received: from fledge.watson.org (fledge.watson.org [209.31.154.41])
by cyrus.watson.org (Postfix) with ESMTP id 59F6946B54;
Sun, 30 Mar 2008 06:34:21 -0400 (EDT)
Date: Sun, 30 Mar 2008 11:34:21 +0100 (BST)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: Alexander Motin <mav@FreeBSD.org>
In-Reply-To: <47EF4F18.502@FreeBSD.org>
Message-ID: <20080330112846.Y5921@fledge.watson.org>
References: <47EF4F18.502@FreeBSD.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Sender: owner-freebsd-hackers@freebsd.org
Errors-To: owner-freebsd-hackers@freebsd.org
Cc: freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org>
Subject: Re: Multiple netgraph threads
X-BeenThere: freebsd-net@freebsd.org
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, 01 Apr 2008 06:22:02 -0000
On Sun, 30 Mar 2008, Alexander Motin wrote:
> I have implemented a patch (for the HEAD) making netgraph to use several own
> threads for event queues processing instead of using single swinet. It
> should significantly improve netgraph SMP scalability on complicated
> workloads that require queueing by implementation (PPTP/L2TP) or stack size
> limitations. It works perfectly on my UP system, showing results close to
> original or even a bit better. I have no real SMP test server to measure
> real scalability, but test on HTT CPU works fine, utilizing both virtual
> cores at the predictable level. Reviews and feedbacks are welcome. URL:
> http://people.freebsd.org/~mav/netgraph.threads.patch
FYI, you might be interested in some similar work I've been doing in the
rwatson_netisr branch in Perforce, which:
(1) Adds per-CPU netisr threads
(2) Introduces inpcb affinity, assigned using a hash on the tuple (similar to
RSS) to load balance
(3) Moves to rwlock use on inpcb and pcbinfo, used extensively in UDP and
somewhat in TCP
My initial leaning would be that we would like to avoid adding too many more
threads that will do per-packet work, as that leads to excessive context
switching. I have similar worries regarding ithreads, and I suspect (hope?)
we will have an active discussion of this at the BSDCan developer summit.
BTW, I'd be careful with the term "should" and SMP -- often times scalability
to multiple cores involves not just introducing the opportunity for
parallelism, but also significantly refining or changing the data model to
allow that parallelism to be efficiently used. Right now, despite loopback
performance being a bottleneck with a single netisr thread, we're not seeing a
performance improvement for database workloads over loopback with multiple
netisr threads. We're diagnosing this still -- initially it appeared to be
tcbinfo lock contention (not surprising), but moving to read locking on
tcbinfo didn't appear to help (except in reducing contention leading to more
idle time rather than more progress). The current theory is that something
about the approach isn't working well with the scheduler but we need to
analyze the scheduler traces further. My recommendation would be that you do
a fairly thorough performance evaluation before committing.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 06:40:04 2008
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 BC94E1065678;
Tue, 1 Apr 2008 06:40:04 +0000 (UTC)
(envelope-from remko@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
[IPv6:2001:4f8:fff6::28])
by mx1.freebsd.org (Postfix) with ESMTP id 949538FC27;
Tue, 1 Apr 2008 06:40:04 +0000 (UTC)
(envelope-from remko@FreeBSD.org)
Received: from freefall.freebsd.org (remko@localhost [127.0.0.1])
by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m316e4Ed099107;
Tue, 1 Apr 2008 06:40:04 GMT
(envelope-from remko@freefall.freebsd.org)
Received: (from remko@localhost)
by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m316e4Fr099103;
Tue, 1 Apr 2008 06:40:04 GMT (envelope-from remko)
Date: Tue, 1 Apr 2008 06:40:04 GMT
Message-Id: <200804010640.m316e4Fr099103@freefall.freebsd.org>
To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org
From: remko@FreeBSD.org
Cc:
Subject: Re: kern/122319: [wi] imposible to enable ad-hoc demo mode with
Orinoco Gold PC card
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, 01 Apr 2008 06:40:04 -0000
Synopsis: [wi] imposible to enable ad-hoc demo mode with Orinoco Gold PC card
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: remko
Responsible-Changed-When: Tue Apr 1 06:39:55 UTC 2008
Responsible-Changed-Why:
reassign to networking team
http://www.freebsd.org/cgi/query-pr.cgi?pr=122319
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 10:42:47 2008
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 78582106566B
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 10:42:47 +0000 (UTC)
(envelope-from rpaulo@gmail.com)
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173])
by mx1.freebsd.org (Postfix) with ESMTP id F02048FC13
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 10:42:46 +0000 (UTC)
(envelope-from rpaulo@gmail.com)
Received: by ug-out-1314.google.com with SMTP id y2so75330uge.37
for <freebsd-net@freebsd.org>; Tue, 01 Apr 2008 03:42:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender;
bh=Mg2EoIw3Bn9zqeuLrD/DOi5Q9WiJADfVrdvtzLegDLU=;
b=XXKpajZ6JbRpjUdrjIgxX5rkhkkbsL2vkjAi/LC8/PbkgrWdT27KxA8tc2i0kuoQK/4aQHDdiWTpxtqO5K/AkI3J5CaPox/pAEtYaav5VonEzwjBTXlzrm9PAu4OyqRRMlteGrbawBluDiIrNC1xvAyMRi2B/dMC+nZbF2+7oNg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender;
b=PCn82L/isERc2o5gMbYCVW3G4q8iF0iVhJpRqX/WzEx8OEohX4Qt0JFpOpN7NvE8loh2vmBqHaitRwV1XQUAnKIDrisjTa4rKfZNqHskVpYzagWJdfr1ur6QdNYE/aGoT17j8b6nD069GddmV2LXpyiWUT+l4yb43xg5q8XUOg0=
Received: by 10.67.30.3 with SMTP id h3mr284034ugj.35.1207046565656;
Tue, 01 Apr 2008 03:42:45 -0700 (PDT)
Received: from fnop.net ( [89.214.129.156])
by mx.google.com with ESMTPS id j4sm245284ugf.49.2008.04.01.03.42.42
(version=SSLv3 cipher=OTHER); Tue, 01 Apr 2008 03:42:44 -0700 (PDT)
Date: Tue, 1 Apr 2008 11:41:29 +0100
From: Rui Paulo <rpaulo@FreeBSD.org>
To: Anthony Pankov <ap00@mail.ru>
Message-ID: <20080401104128.GA1194@fnop.net>
References: <1333421734.20080328201458@mail.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1333421734.20080328201458@mail.ru>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: Rui Paulo <rpaulo@gmail.com>
Cc: freebsd-net@freebsd.org, performance@freebsd.org
Subject: Re: packet delay because of blackhole
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, 01 Apr 2008 10:42:47 -0000
On Fri, Mar 28, 2008 at 08:14:58PM +0300, Anthony Pankov wrote:
> Just for somebody convince.
>
> While analyzing client<->server HTTPS conversation one second delay in
> packet exchange was discovered (strongly reproducible):
>
> Sample:
> N time
> 6 0.002303 10.28.4.14 10.28.4.50 SSL Client Hello
> 7 0.106710 10.28.4.50 10.28.4.14 TCP 443 > 1447 [ACK] Seq=1 Ack=103 Win=65535 Len=0
> 8 1.045712 10.28.4.50 10.28.4.14 TLSv1 Server Hello, Certificate, Server Hello Done
>
> Another sample:
> 10 0.011722 10.28.4.14 10.28.4.50 TLSv1 Application Data
> 11 0.115933 10.28.4.50 10.28.4.14 TCP 443 > 1442 [ACK] Seq=839 Ack=519 Win=65466 Len=0
> 12 1.054037 10.28.4.50 10.28.4.14 TLSv1 Application Data
>
> The reason for delay is sysctl tcp.blackhole value grater than 0, much to surprise.
>
> So, turning tcp.blackhole to 0 eliminate any delay (strongly reproducible).
>
> System: FreeBSD 6_2_stable
I'm not sure how performance penalty can induce a cache miss and I
it's very processor specific. So, you're best guess is to profile the
kernel.
Regards,
--
Rui Paulo
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 12:15:32 2008
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 0BD32106566B
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 12:15:32 +0000 (UTC)
(envelope-from Matthias.Apitz@oclc.org)
Received: from mail.pica.nl (mail.pica.nl [192.87.44.30])
by mx1.freebsd.org (Postfix) with ESMTP id 976018FC13
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 12:15:31 +0000 (UTC)
(envelope-from Matthias.Apitz@oclc.org)
Received: from rebelion.Sisis.de ([193.31.10.34]) by mail.pica.nl with
Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Apr 2008 14:06:09 +0200
Received: (from guru@localhost)
by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id m31C3QHb005910
for freebsd-net@freebsd.org; Tue, 1 Apr 2008 14:03:26 +0200 (CEST)
(envelope-from matthias.apitz@oclc.org)
X-Authentication-Warning: rebelion.Sisis.de: guru set sender to
matthias.apitz@oclc.org using -f
Date: Tue, 1 Apr 2008 14:03:26 +0200
From: Matthias Apitz <guru@Sisis.de>
To: freebsd-net@freebsd.org
Message-ID: <20080401120326.GA5887@rebelion.Sisis.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
X-Operating-System: FreeBSD 7.0-RELEASE (i386)
X-OriginalArrivalTime: 01 Apr 2008 12:06:09.0337 (UTC)
FILETIME=[C5673A90:01C893F0]
Subject: kern/122331: 7.0-RELEASE && panic in Wifi area with WPA mode (not
in WEP mode)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Matthias Apitz <matthias.apitz@oclc.org>
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, 01 Apr 2008 12:15:32 -0000
Hello,
I've just filed the following bug report:
http://www.freebsd.org/cgi/query-pr.cgi?pr=122331
Synopsis: 7.0-RELEASE && panic in Wifi area with WPA mode (not in WEP mode)
when wpa_supplicant with WPA is used (i.e. the problem does not occure
with WEP. even not in days of uptime) the kernel crashes from time to
time, after hours or even after a some minutes;
last kgdb bt shows:...
matthias
--
Matthias Apitz
Manager Technical Support - OCLC GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <matthias.apitz@oclc.org> - w http://www.oclc.org/ http://www.UnixArea.de/
b http://gurucubano.blogspot.com/
Don't top-post, read RFC1855 http://www.faqs.org/rfcs/rfc1855.html
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on Usenet and in e-mail?
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 13:10:02 2008
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 B80FC106564A
for <freebsd-net@hub.freebsd.org>; Tue, 1 Apr 2008 13:10:02 +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 A68A98FC1A
for <freebsd-net@hub.freebsd.org>; Tue, 1 Apr 2008 13:10:02 +0000 (UTC)
(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1])
by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m31DA2rO031988
for <freebsd-net@freefall.freebsd.org>; Tue, 1 Apr 2008 13:10:02 GMT
(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m31DA2Dq031987;
Tue, 1 Apr 2008 13:10:02 GMT (envelope-from gnats)
Date: Tue, 1 Apr 2008 13:10:02 GMT
Message-Id: <200804011310.m31DA2Dq031987@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: Benjamin Close <Benjamin.Close@clearchain.com>
Cc:
Subject: Re: kern/118975: [bge] [patch] Broadcom 5906 not handled by FreeBSD
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Benjamin Close <Benjamin.Close@clearchain.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: Tue, 01 Apr 2008 13:10:02 -0000
The following reply was made to PR kern/118975; it has been noted by GNATS.
From: Benjamin Close <Benjamin.Close@clearchain.com>
To: jhb@freebsd.org
Cc: =?ISO-8859-1?Q?Thomas_Nystr=F6m?= <thn@saeab.se>, bug-followup@freebsd.org
Subject: Re: kern/118975: [bge] [patch] Broadcom 5906 not handled by FreeBSD
Date: Tue, 01 Apr 2008 23:29:49 +1030
This is a multi-part message in MIME format.
--------------030107050408040208070301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Thomas Nyström wrote:
> Benjamin Close skrev:
>> Hi Thomas,
>> Are you able to attach a recent patch rather than inling it - I'll
>> see what I can do to test/get it merged.
>
> Hi Benjamin!
>
> I tried to attach the updated patch the last time but it seems that
> something got wrong...
>
> I have now put both patches here: http://ture.saeab.se/bcm5906/
> One for 6.3R and one for 7.0R. Last time I checked the 7.0R also
> applied to -CURRENT without problem.
>
> Currently my machine with 5906 is running 6.3R but I will arrange so
> it also could run -CURRENT.
>
> /Thomas
>
Hi John,
Are you the current maintainer of bge(4)?
The patch put together by Thomas (cc'd) adds 5906 chipset support for
the driver and works very well (sending this email via the patched
driver). Any chance of committing - or happy for me to commit? (Patch
against -current attached)
Cheers,
Benjamin
--------------030107050408040208070301
Content-Type: text/plain;
name="20080325-5906.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="20080325-5906.diff"
Index: dev/bge/if_bge.c
===================================================================
RCS file: /devel/FreeBSD/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.204
diff -u -r1.204 if_bge.c
--- dev/bge/if_bge.c 11 Mar 2008 15:05:54 -0000 1.204
+++ dev/bge/if_bge.c 25 Mar 2008 02:44:25 -0000
@@ -196,6 +196,8 @@
{ BCOM_VENDORID, BCOM_DEVICEID_BCM5901 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM5901A2 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM5903M },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM5906 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM5906M },
{ SK_VENDORID, SK_DEVICEID_ALTIMA },
@@ -273,6 +275,8 @@
{ BGE_CHIPID_BCM5787_A0, "BCM5754/5787 A0" },
{ BGE_CHIPID_BCM5787_A1, "BCM5754/5787 A1" },
{ BGE_CHIPID_BCM5787_A2, "BCM5754/5787 A2" },
+ { BGE_CHIPID_BCM5906_A1, "BCM5906 A1" },
+ { BGE_CHIPID_BCM5906_A2, "BCM5906 A2" },
{ 0, NULL }
};
@@ -295,6 +299,7 @@
{ BGE_ASICREV_BCM5755, "unknown BCM5755" },
/* 5754 and 5787 share the same ASIC ID */
{ BGE_ASICREV_BCM5787, "unknown BCM5754/5787" },
+ { BGE_ASICREV_BCM5906, "unknown BCM5906" },
{ 0, NULL }
};
@@ -307,6 +312,9 @@
const struct bge_revision * bge_lookup_rev(uint32_t);
const struct bge_vendor * bge_lookup_vendor(uint16_t);
+
+typedef int (*bge_eaddr_fcn_t)(struct bge_softc *, uint8_t[]);
+
static int bge_probe(device_t);
static int bge_attach(device_t);
static int bge_detach(device_t);
@@ -317,6 +325,11 @@
static int bge_dma_alloc(device_t);
static void bge_dma_free(struct bge_softc *);
+static int bge_get_eaddr_mem(struct bge_softc *, uint8_t[]);
+static int bge_get_eaddr_nvram(struct bge_softc *, uint8_t[]);
+static int bge_get_eaddr_eeprom(struct bge_softc *, uint8_t[]);
+static int bge_get_eaddr(struct bge_softc *, uint8_t[]);
+
static void bge_txeof(struct bge_softc *);
static void bge_rxeof(struct bge_softc *);
@@ -339,6 +352,9 @@
static int bge_ifmedia_upd(struct ifnet *);
static void bge_ifmedia_sts(struct ifnet *, struct ifmediareq *);
+static uint8_t bge_nvram_getbyte(struct bge_softc *, int, uint8_t *);
+static int bge_read_nvram(struct bge_softc *, caddr_t, int, int);
+
static uint8_t bge_eeprom_getbyte(struct bge_softc *, int, uint8_t *);
static int bge_read_eeprom(struct bge_softc *, caddr_t, int, int);
@@ -361,6 +377,7 @@
static int bge_has_eeprom(struct bge_softc *);
static uint32_t bge_readmem_ind(struct bge_softc *, int);
static void bge_writemem_ind(struct bge_softc *, int, int);
+static void bge_writembx(struct bge_softc *, int, int);
#ifdef notdef
static uint32_t bge_readreg_ind(struct bge_softc *, int);
#endif
@@ -476,6 +493,10 @@
return (0);
}
#endif
+
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5906)
+ return (0);
+
return (1);
}
@@ -535,6 +556,15 @@
CSR_WRITE_4(sc, off, val);
}
+static void
+bge_writembx(struct bge_softc *sc, int off, int val)
+{
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5906)
+ off += BGE_LPMBX_IRQ0_HI - BGE_MBX_IRQ0_HI;
+
+ CSR_WRITE_4(sc, off, val);
+}
+
/*
* Map a single buffer address.
*/
@@ -557,6 +587,78 @@
ctx->bge_busaddr = segs->ds_addr;
}
+static uint8_t
+bge_nvram_getbyte(struct bge_softc *sc, int addr, uint8_t *dest)
+{
+ uint32_t access, byte = 0;
+ int i;
+
+ /* Lock. */
+ CSR_WRITE_4(sc, BGE_NVRAM_SWARB, BGE_NVRAMSWARB_SET1);
+ for (i = 0; i < 8000; i++) {
+ if (CSR_READ_4(sc, BGE_NVRAM_SWARB) & BGE_NVRAMSWARB_GNT1)
+ break;
+ DELAY(20);
+ }
+ if (i == 8000)
+ return (1);
+
+ /* Enable access. */
+ access = CSR_READ_4(sc, BGE_NVRAM_ACCESS);
+ CSR_WRITE_4(sc, BGE_NVRAM_ACCESS, access | BGE_NVRAMACC_ENABLE);
+
+ CSR_WRITE_4(sc, BGE_NVRAM_ADDR, addr & 0xfffffffc);
+ CSR_WRITE_4(sc, BGE_NVRAM_CMD, BGE_NVRAM_READCMD);
+ for (i = 0; i < BGE_TIMEOUT * 10; i++) {
+ DELAY(10);
+ if (CSR_READ_4(sc, BGE_NVRAM_CMD) & BGE_NVRAMCMD_DONE) {
+ DELAY(10);
+ break;
+ }
+ }
+
+ if (i == BGE_TIMEOUT * 10) {
+ if_printf(sc->bge_ifp, "nvram read timed out\n");
+ return (1);
+ }
+
+ /* Get result. */
+ byte = CSR_READ_4(sc, BGE_NVRAM_RDDATA);
+
+ *dest = (bswap32(byte) >> ((addr % 4) * 8)) & 0xFF;
+
+ /* Disable access. */
+ CSR_WRITE_4(sc, BGE_NVRAM_ACCESS, access);
+
+ /* Unlock. */
+ CSR_WRITE_4(sc, BGE_NVRAM_SWARB, BGE_NVRAMSWARB_CLR1);
+ CSR_READ_4(sc, BGE_NVRAM_SWARB);
+
+ return (0);
+}
+
+/*
+ * Read a sequence of bytes from NVRAM.
+ */
+static int
+bge_read_nvram(struct bge_softc *sc, caddr_t dest, int off, int cnt)
+{
+ int err = 0, i;
+ uint8_t byte = 0;
+
+ if (sc->bge_asicrev != BGE_ASICREV_BCM5906)
+ return (1);
+
+ for (i = 0; i < cnt; i++) {
+ err = bge_nvram_getbyte(sc, off + i, &byte);
+ if (err)
+ break;
+ *(dest + i) = byte;
+ }
+
+ return (err ? 1 : 0);
+}
+
/*
* Read a byte of data stored in the EEPROM at address 'addr.' The
* BCM570x supports both the traditional bitbang interface and an
@@ -661,11 +763,13 @@
}
if (i == BGE_TIMEOUT) {
- device_printf(sc->bge_dev, "PHY read timed out\n");
+ device_printf(sc->bge_dev, "PHY read timed out "
+ "(phy %d, reg %d, val 0x%08x)\n", phy, reg, val);
val = 0;
goto done;
}
+ DELAY(5);
val = CSR_READ_4(sc, BGE_MI_COMM);
done:
@@ -689,6 +793,10 @@
sc = device_get_softc(dev);
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5906 &&
+ (reg == BRGPHY_MII_1000CTL || reg == BRGPHY_MII_AUXCTL))
+ return(0);
+
/* Reading with autopolling on may trigger PCI errors */
autopoll = CSR_READ_4(sc, BGE_MI_MODE);
if (autopoll & BGE_MIMODE_AUTOPOLL) {
@@ -701,12 +809,17 @@
for (i = 0; i < BGE_TIMEOUT; i++) {
DELAY(10);
- if (!(CSR_READ_4(sc, BGE_MI_COMM) & BGE_MICOMM_BUSY))
+ if (!(CSR_READ_4(sc, BGE_MI_COMM) & BGE_MICOMM_BUSY)) {
+ DELAY(5);
+ CSR_READ_4(sc, BGE_MI_COMM); /* dummy read */
break;
+ }
}
if (i == BGE_TIMEOUT) {
- device_printf(sc->bge_dev, "PHY write timed out\n");
+ device_printf(sc->bge_dev,
+ "PHY write timed out (phy %d, reg %d, val %d)\n",
+ phy, reg, val);
return (0);
}
@@ -889,7 +1002,7 @@
BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE);
sc->bge_std = i - 1;
- CSR_WRITE_4(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std);
+ bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std);
return (0);
}
@@ -936,7 +1049,7 @@
BGE_RCB_FLAG_USE_EXT_RX_BD);
CSR_WRITE_4(sc, BGE_RX_JUMBO_RCB_MAXLEN_FLAGS, rcb->bge_maxlen_flags);
- CSR_WRITE_4(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo);
+ bge_writembx(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo);
return (0);
}
@@ -992,17 +1105,17 @@
/* Initialize transmit producer index for host-memory send ring. */
sc->bge_tx_prodidx = 0;
- CSR_WRITE_4(sc, BGE_MBX_TX_HOST_PROD0_LO, sc->bge_tx_prodidx);
+ bge_writembx(sc, BGE_MBX_TX_HOST_PROD0_LO, sc->bge_tx_prodidx);
/* 5700 b2 errata */
if (sc->bge_chiprev == BGE_CHIPREV_5700_BX)
- CSR_WRITE_4(sc, BGE_MBX_TX_HOST_PROD0_LO, sc->bge_tx_prodidx);
+ bge_writembx(sc, BGE_MBX_TX_HOST_PROD0_LO, sc->bge_tx_prodidx);
/* NIC-memory send ring not used; initialize to zero. */
- CSR_WRITE_4(sc, BGE_MBX_TX_NIC_PROD0_LO, 0);
+ bge_writembx(sc, BGE_MBX_TX_NIC_PROD0_LO, 0);
/* 5700 b2 errata */
if (sc->bge_chiprev == BGE_CHIPREV_5700_BX)
- CSR_WRITE_4(sc, BGE_MBX_TX_NIC_PROD0_LO, 0);
+ bge_writembx(sc, BGE_MBX_TX_NIC_PROD0_LO, 0);
return (0);
}
@@ -1273,6 +1386,15 @@
/* Set the timer prescaler (always 66Mhz) */
CSR_WRITE_4(sc, BGE_MISC_CFG, BGE_32BITTIME_66MHZ);
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5906) {
+ DELAY(40); /* XXX */
+
+ /* Put PHY into ready state */
+ BGE_CLRBIT(sc, BGE_MISC_CFG, BGE_MISCCFG_EPHY_IDDQ);
+ CSR_READ_4(sc, BGE_MISC_CFG); /* Flush */
+ DELAY(40);
+ }
+
return (0);
}
@@ -1309,15 +1431,21 @@
CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_LEN, 0x2000);
}
+
/* Configure mbuf pool watermarks */
- if (BGE_IS_5705_PLUS(sc)) {
- CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
- CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10);
- } else {
+ if (!BGE_IS_5705_PLUS(sc)) {
CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x50);
CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x20);
+ CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60);
+ } else if (sc->bge_asicrev == BGE_ASICREV_BCM5906) {
+ CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
+ CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x04);
+ CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x10);
+ } else {
+ CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
+ CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10);
+ CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60);
}
- CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60);
/* Configure DMA resource watermarks */
CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_LOWAT, 5);
@@ -1464,15 +1592,15 @@
BGE_RCB_MAXLEN_FLAGS(sc->bge_return_ring_cnt,
BGE_RCB_FLAG_RING_DISABLED));
RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0);
- CSR_WRITE_4(sc, BGE_MBX_RX_CONS0_LO +
+ bge_writembx(sc, BGE_MBX_RX_CONS0_LO +
(i * (sizeof(uint64_t))), 0);
vrcb += sizeof(struct bge_rcb);
}
/* Initialize RX ring indexes */
- CSR_WRITE_4(sc, BGE_MBX_RX_STD_PROD_LO, 0);
- CSR_WRITE_4(sc, BGE_MBX_RX_JUMBO_PROD_LO, 0);
- CSR_WRITE_4(sc, BGE_MBX_RX_MINI_PROD_LO, 0);
+ bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, 0);
+ bge_writembx(sc, BGE_MBX_RX_JUMBO_PROD_LO, 0);
+ bge_writembx(sc, BGE_MBX_RX_MINI_PROD_LO, 0);
/*
* Set up RX return ring 0
@@ -2232,7 +2360,6 @@
struct ifnet *ifp;
struct bge_softc *sc;
uint32_t hwcfg = 0;
- uint32_t mac_tmp = 0;
u_char eaddr[ETHER_ADDR_LEN];
int error, reg, rid, trys;
@@ -2294,6 +2421,7 @@
case BGE_ASICREV_BCM5752:
case BGE_ASICREV_BCM5755:
case BGE_ASICREV_BCM5787:
+ case BGE_ASICREV_BCM5906:
sc->bge_flags |= BGE_FLAG_575X_PLUS;
/* FALLTHRU */
case BGE_ASICREV_BCM5705:
@@ -2316,7 +2444,7 @@
sc->bge_asicrev == BGE_ASICREV_BCM5787) {
if (sc->bge_chipid != BGE_CHIPID_BCM5722_A0)
sc->bge_flags |= BGE_FLAG_JITTER_BUG;
- } else
+ } else if (sc->bge_asicrev != BGE_ASICREV_BCM5906)
sc->bge_flags |= BGE_FLAG_BER_BUG;
}
@@ -2427,22 +2555,14 @@
}
#ifdef __sparc64__
- if ((sc->bge_flags & BGE_FLAG_EEPROM) == 0)
+ if (((sc->bge_flags & BGE_FLAG_EEPROM) == 0) &&
+ (sc->bge_asicrev != BGE_ASICREV_BCM5906))
OF_getetheraddr(dev, eaddr);
else
#endif
{
- mac_tmp = bge_readmem_ind(sc, 0x0C14);
- if ((mac_tmp >> 16) == 0x484B) {
- eaddr[0] = (u_char)(mac_tmp >> 8);
- eaddr[1] = (u_char)mac_tmp;
- mac_tmp = bge_readmem_ind(sc, 0x0C18);
- eaddr[2] = (u_char)(mac_tmp >> 24);
- eaddr[3] = (u_char)(mac_tmp >> 16);
- eaddr[4] = (u_char)(mac_tmp >> 8);
- eaddr[5] = (u_char)mac_tmp;
- } else if (bge_read_eeprom(sc, eaddr,
- BGE_EE_MAC_OFFSET + 2, ETHER_ADDR_LEN)) {
+ error = bge_get_eaddr(sc, eaddr);
+ if (error) {
device_printf(sc->bge_dev,
"failed to read station address\n");
error = ENXIO;
@@ -2700,7 +2820,8 @@
dev = sc->bge_dev;
- if (BGE_IS_575X_PLUS(sc) && !BGE_IS_5714_FAMILY(sc)) {
+ if (BGE_IS_575X_PLUS(sc) && !BGE_IS_5714_FAMILY(sc) &&
+ (sc->bge_asicrev != BGE_ASICREV_BCM5906)) {
if (sc->bge_flags & BGE_FLAG_PCIE)
write_op = bge_writemem_direct;
else
@@ -2756,6 +2877,17 @@
/* Issue global reset */
write_op(sc, BGE_MISC_CFG, reset);
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5906) {
+ uint32_t status, ctrl;
+
+ status = CSR_READ_4(sc, BGE_VCPU_STATUS);
+ CSR_WRITE_4(sc, BGE_VCPU_STATUS,
+ status | BGE_VCPU_STATUS_DRV_RESET);
+ ctrl = CSR_READ_4(sc, BGE_VCPU_EXT_CTRL);
+ CSR_WRITE_4(sc, BGE_VCPU_EXT_CTRL,
+ ctrl & ~BGE_VCPU_EXT_CTRL_HALT_CPU);
+ }
+
DELAY(1000);
/* XXX: Broadcom Linux driver. */
@@ -2800,21 +2932,34 @@
} else
CSR_WRITE_4(sc, BGE_MARB_MODE, BGE_MARBMODE_ENABLE);
- /*
- * Poll until we see the 1's complement of the magic number.
- * This indicates that the firmware initialization is complete.
- * We expect this to fail if no EEPROM is fitted though.
- */
- for (i = 0; i < BGE_TIMEOUT; i++) {
- DELAY(10);
- val = bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM);
- if (val == ~BGE_MAGIC_NUMBER)
- break;
- }
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5906) {
+ for (i = 0; i < BGE_TIMEOUT; i++) {
+ val = CSR_READ_4(sc, BGE_VCPU_STATUS);
+ if (val & BGE_VCPU_STATUS_INIT_DONE)
+ break;
+ DELAY(100);
+ }
+ if (i == BGE_TIMEOUT) {
+ device_printf(sc->bge_dev, "reset timed out\n");
+ return (1);
+ }
+ } else {
+ /*
+ * Poll until we see the 1's complement of the magic number.
+ * This indicates that the firmware initialization is complete.
+ * We expect this to fail if no EEPROM is fitted though.
+ */
+ for (i = 0; i < BGE_TIMEOUT; i++) {
+ DELAY(10);
+ val = bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM);
+ if (val == ~BGE_MAGIC_NUMBER)
+ break;
+ }
- if ((sc->bge_flags & BGE_FLAG_EEPROM) && i == BGE_TIMEOUT)
- device_printf(sc->bge_dev, "firmware handshake timed out, "
- "found 0x%08x\n", val);
+ if ((sc->bge_flags & BGE_FLAG_EEPROM) && i == BGE_TIMEOUT)
+ device_printf(sc->bge_dev, "firmware handshake timed out, "
+ "found 0x%08x\n", val);
+ }
/*
* XXX Wait for the value of the PCISTATE register to
@@ -3034,11 +3179,11 @@
bus_dmamap_sync(sc->bge_cdata.bge_rx_jumbo_ring_tag,
sc->bge_cdata.bge_rx_jumbo_ring_map, BUS_DMASYNC_PREWRITE);
- CSR_WRITE_4(sc, BGE_MBX_RX_CONS0_LO, sc->bge_rx_saved_considx);
+ bge_writembx(sc, BGE_MBX_RX_CONS0_LO, sc->bge_rx_saved_considx);
if (stdcnt)
- CSR_WRITE_4(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std);
+ bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std);
if (jumbocnt)
- CSR_WRITE_4(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo);
+ bge_writembx(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo);
#ifdef notyet
/*
* This register wraps very quickly under heavy packet drops.
@@ -3180,7 +3325,7 @@
* the status check). So toggling would probably be a pessimization
* even with MSI. It would only be needed for using a task queue.
*/
- CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0);
+ bge_writembx(sc, BGE_MBX_IRQ0_LO, 0);
/*
* Do the mandatory PCI flush as well as get the link status.
@@ -3557,10 +3702,10 @@
return;
/* Transmit. */
- CSR_WRITE_4(sc, BGE_MBX_TX_HOST_PROD0_LO, prodidx);
+ bge_writembx(sc, BGE_MBX_TX_HOST_PROD0_LO, prodidx);
/* 5700 b2 errata */
if (sc->bge_chiprev == BGE_CHIPREV_5700_BX)
- CSR_WRITE_4(sc, BGE_MBX_TX_HOST_PROD0_LO, prodidx);
+ bge_writembx(sc, BGE_MBX_TX_HOST_PROD0_LO, prodidx);
sc->bge_tx_prodidx = prodidx;
@@ -3687,7 +3832,7 @@
if (ifp->if_capenable & IFCAP_POLLING) {
BGE_SETBIT(sc, BGE_PCI_MISC_CTL,
BGE_PCIMISCCTL_MASK_PCI_INTR);
- CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1);
+ bge_writembx(sc, BGE_MBX_IRQ0_LO, 1);
} else
#endif
@@ -3695,7 +3840,7 @@
{
BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_CLEAR_INTA);
BGE_CLRBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR);
- CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0);
+ bge_writembx(sc, BGE_MBX_IRQ0_LO, 0);
}
bge_ifmedia_upd_locked(ifp);
@@ -3918,7 +4063,7 @@
BGE_LOCK(sc);
BGE_SETBIT(sc, BGE_PCI_MISC_CTL,
BGE_PCIMISCCTL_MASK_PCI_INTR);
- CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1);
+ bge_writembx(sc, BGE_MBX_IRQ0_LO, 1);
ifp->if_capenable |= IFCAP_POLLING;
BGE_UNLOCK(sc);
} else {
@@ -3927,7 +4072,7 @@
BGE_LOCK(sc);
BGE_CLRBIT(sc, BGE_PCI_MISC_CTL,
BGE_PCIMISCCTL_MASK_PCI_INTR);
- CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0);
+ bge_writembx(sc, BGE_MBX_IRQ0_LO, 0);
ifp->if_capenable &= ~IFCAP_POLLING;
BGE_UNLOCK(sc);
}
@@ -4052,7 +4197,7 @@
/* Disable host interrupts. */
BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR);
- CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1);
+ bge_writembx(sc, BGE_MBX_IRQ0_LO, 1);
/*
* Tell firmware we're shutting down.
@@ -4548,3 +4693,64 @@
return (error);
}
#endif
+
+static int
+bge_get_eaddr_mem(struct bge_softc *sc, uint8_t ether_addr[])
+{
+ uint32_t mac_addr;
+ int ret = 1;
+
+ mac_addr = bge_readmem_ind(sc, 0x0c14);
+ if ((mac_addr >> 16) == 0x484b) {
+ ether_addr[0] = (uint8_t)(mac_addr >> 8);
+ ether_addr[1] = (uint8_t)mac_addr;
+ mac_addr = bge_readmem_ind(sc, 0x0c18);
+ ether_addr[2] = (uint8_t)(mac_addr >> 24);
+ ether_addr[3] = (uint8_t)(mac_addr >> 16);
+ ether_addr[4] = (uint8_t)(mac_addr >> 8);
+ ether_addr[5] = (uint8_t)mac_addr;
+ ret = 0;
+ }
+ return ret;
+}
+
+static int
+bge_get_eaddr_nvram(struct bge_softc *sc, uint8_t ether_addr[])
+{
+ int mac_offset = BGE_EE_MAC_OFFSET;
+
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5906)
+ mac_offset = BGE_EE_MAC_OFFSET_5906;
+
+ return bge_read_nvram(sc, ether_addr, mac_offset + 2, ETHER_ADDR_LEN);
+}
+
+static int
+bge_get_eaddr_eeprom(struct bge_softc *sc, uint8_t ether_addr[])
+{
+ if (!(sc->bge_flags & BGE_FLAG_EEPROM))
+ return 1;
+
+ return bge_read_eeprom(sc, ether_addr, BGE_EE_MAC_OFFSET + 2,
+ ETHER_ADDR_LEN);
+}
+
+static int
+bge_get_eaddr(struct bge_softc *sc, uint8_t eaddr[])
+{
+ static const bge_eaddr_fcn_t bge_eaddr_funcs[] = {
+ /* NOTE: Order is critical */
+ bge_get_eaddr_mem,
+ bge_get_eaddr_nvram,
+ bge_get_eaddr_eeprom,
+ NULL
+ };
+ const bge_eaddr_fcn_t *func;
+
+ for (func = bge_eaddr_funcs; *func != NULL; ++func) {
+ if ((*func)(sc, eaddr) == 0)
+ break;
+ }
+ return (*func == NULL ? ENXIO : 0);
+}
+
Index: dev/bge/if_bgereg.h
===================================================================
RCS file: /devel/FreeBSD/ncvs/src/sys/dev/bge/if_bgereg.h,v
retrieving revision 1.77
diff -u -r1.77 if_bgereg.h
--- dev/bge/if_bgereg.h 6 Mar 2008 21:48:34 -0000 1.77
+++ dev/bge/if_bgereg.h 25 Mar 2008 02:41:09 -0000
@@ -284,6 +284,8 @@
#define BGE_CHIPID_BCM5787_A0 0xb0000000
#define BGE_CHIPID_BCM5787_A1 0xb0010000
#define BGE_CHIPID_BCM5787_A2 0xb0020000
+#define BGE_CHIPID_BCM5906_A1 0xc0010000
+#define BGE_CHIPID_BCM5906_A2 0xc0020000
/* shorthand one */
#define BGE_ASICREV(x) ((x) >> 28)
@@ -300,6 +302,7 @@
#define BGE_ASICREV_BCM5755 0x0a
#define BGE_ASICREV_BCM5754 0x0b
#define BGE_ASICREV_BCM5787 0x0b
+#define BGE_ASICREV_BCM5906 0x0c
/* chip revisions */
#define BGE_CHIPREV(x) ((x) >> 24)
@@ -1439,6 +1442,17 @@
#define BGE_RXCPUSTAT_MA_REQ_FIFOOFLOW 0x40000000
#define BGE_RXCPUSTAT_BLOCKING_READ 0x80000000
+/*
+ * V? CPU registers
+ */
+#define BGE_VCPU_STATUS 0x5100
+#define BGE_VCPU_EXT_CTRL 0x6890
+
+#define BGE_VCPU_STATUS_INIT_DONE 0x04000000
+#define BGE_VCPU_STATUS_DRV_RESET 0x08000000
+
+#define BGE_VCPU_EXT_CTRL_HALT_CPU 0x00400000
+#define BGE_VCPU_EXT_CTRL_DISABLE_WOL 0x20000000
/*
* TX CPU registers
@@ -1684,6 +1698,55 @@
#define BGE_MDI_CTL 0x6844
#define BGE_EE_DELAY 0x6848
#define BGE_FASTBOOT_PC 0x6894
+/*
+ * NVRAM Control registers
+ */
+#define BGE_NVRAM_CMD 0x7000
+#define BGE_NVRAM_STAT 0x7004
+#define BGE_NVRAM_WRDATA 0x7008
+#define BGE_NVRAM_ADDR 0x700c
+#define BGE_NVRAM_RDDATA 0x7010
+#define BGE_NVRAM_CFG1 0x7014
+#define BGE_NVRAM_CFG2 0x7018
+#define BGE_NVRAM_CFG3 0x701c
+#define BGE_NVRAM_SWARB 0x7020
+#define BGE_NVRAM_ACCESS 0x7024
+#define BGE_NVRAM_WRITE1 0x7028
+
+#define BGE_NVRAMCMD_RESET 0x00000001
+#define BGE_NVRAMCMD_DONE 0x00000008
+#define BGE_NVRAMCMD_START 0x00000010
+#define BGE_NVRAMCMD_WR 0x00000020 /* 1 = wr, 0 = rd */
+#define BGE_NVRAMCMD_ERASE 0x00000040
+#define BGE_NVRAMCMD_FIRST 0x00000080
+#define BGE_NVRAMCMD_LAST 0x00000100
+
+#define BGE_NVRAM_READCMD \
+ (BGE_NVRAMCMD_FIRST|BGE_NVRAMCMD_LAST| \
+ BGE_NVRAMCMD_START|BGE_NVRAMCMD_DONE)
+#define BGE_NVRAM_WRITECMD \
+ (BGE_NVRAMCMD_FIRST|BGE_NVRAMCMD_LAST| \
+ BGE_NVRAMCMD_START|BGE_NVRAMCMD_DONE|BGE_NVRAMCMD_WR)
+
+#define BGE_NVRAMSWARB_SET0 0x00000001
+#define BGE_NVRAMSWARB_SET1 0x00000002
+#define BGE_NVRAMSWARB_SET2 0x00000003
+#define BGE_NVRAMSWARB_SET3 0x00000004
+#define BGE_NVRAMSWARB_CLR0 0x00000010
+#define BGE_NVRAMSWARB_CLR1 0x00000020
+#define BGE_NVRAMSWARB_CLR2 0x00000040
+#define BGE_NVRAMSWARB_CLR3 0x00000080
+#define BGE_NVRAMSWARB_GNT0 0x00000100
+#define BGE_NVRAMSWARB_GNT1 0x00000200
+#define BGE_NVRAMSWARB_GNT2 0x00000400
+#define BGE_NVRAMSWARB_GNT3 0x00000800
+#define BGE_NVRAMSWARB_REQ0 0x00001000
+#define BGE_NVRAMSWARB_REQ1 0x00002000
+#define BGE_NVRAMSWARB_REQ2 0x00004000
+#define BGE_NVRAMSWARB_REQ3 0x00008000
+
+#define BGE_NVRAMACC_ENABLE 0x00000001
+#define BGE_NVRAMACC_WRENABLE 0x00000002
/* Mode control register */
#define BGE_MODECTL_INT_SNDCOAL_ONLY 0x00000001
@@ -1712,6 +1775,7 @@
/* Misc. config register */
#define BGE_MISCCFG_RESET_CORE_CLOCKS 0x00000001
#define BGE_MISCCFG_TIMER_PRESCALER 0x000000FE
+#define BGE_MISCCFG_EPHY_IDDQ 0x00200000
#define BGE_32BITTIME_66MHZ (0x41 << 1)
@@ -2039,6 +2103,8 @@
#define BCOM_DEVICEID_BCM5901 0x170D
#define BCOM_DEVICEID_BCM5901A2 0x170E
#define BCOM_DEVICEID_BCM5903M 0x16FF
+#define BCOM_DEVICEID_BCM5906 0x1712
+#define BCOM_DEVICEID_BCM5906M 0x1713
/*
* Alteon AceNIC PCI vendor/device ID.
@@ -2092,6 +2158,7 @@
* Offset of MAC address inside EEPROM.
*/
#define BGE_EE_MAC_OFFSET 0x7C
+#define BGE_EE_MAC_OFFSET_5906 0x10
#define BGE_EE_HWCFG_OFFSET 0xC8
#define BGE_HWCFG_VOLTAGE 0x00000003
@@ -2477,6 +2544,7 @@
#define BGE_FLAG_BER_BUG 0x02000000
#define BGE_FLAG_ADJUST_TRIM 0x04000000
#define BGE_FLAG_CRC_BUG 0x08000000
+#define BGE_FLAG_NO_EEPROM 0x10000000
uint32_t bge_chipid;
uint8_t bge_asicrev;
uint8_t bge_chiprev;
Index: dev/mii/brgphy.c
===================================================================
RCS file: /devel/FreeBSD/ncvs/src/sys/dev/mii/brgphy.c,v
retrieving revision 1.73
diff -u -r1.73 brgphy.c
--- dev/mii/brgphy.c 6 Mar 2008 21:42:48 -0000 1.73
+++ dev/mii/brgphy.c 25 Mar 2008 02:47:22 -0000
@@ -134,6 +134,7 @@
MII_PHY_DESC(xxBROADCOM_ALT1, BCM5709CAX),
MII_PHY_DESC(xxBROADCOM_ALT1, BCM5722),
MII_PHY_DESC(xxBROADCOM_ALT1, BCM5709C),
+ MII_PHY_DESC(BROADCOM2, BCM5906),
MII_PHY_END
};
@@ -189,6 +190,7 @@
/* Handle any special cases based on the PHY ID */
switch (bsc->mii_oui) {
case MII_OUI_BROADCOM:
+ case MII_OUI_BROADCOM2:
break;
case MII_OUI_xxBROADCOM:
switch (bsc->mii_model) {
@@ -229,12 +231,14 @@
bce_sc = ifp->if_softc;
}
- /* Todo: Need to add additional controllers such as 5906 & 5787F */
+ /* Todo: Need to add additional controllers such as 5787F */
/* The 590x chips are 10/100 only. */
if (bge_sc &&
pci_get_vendor(bge_sc->bge_dev) == BCOM_VENDORID &&
(pci_get_device(bge_sc->bge_dev) == BCOM_DEVICEID_BCM5901 ||
- pci_get_device(bge_sc->bge_dev) == BCOM_DEVICEID_BCM5901A2)) {
+ pci_get_device(bge_sc->bge_dev) == BCOM_DEVICEID_BCM5901A2 ||
+ pci_get_device(bge_sc->bge_dev) == BCOM_DEVICEID_BCM5906 ||
+ pci_get_device(bge_sc->bge_dev) == BCOM_DEVICEID_BCM5906M)) {
fast_ether = 1;
sc->mii_anegticks = MII_ANEGTICKS;
}
@@ -927,6 +931,11 @@
PHY_READ(sc, BRGPHY_MII_PHY_EXTCTL) &
~BRGPHY_PHY_EXTCTL_3_LED);
}
+
+ /* Adjust output voltage (From Linux driver) */
+ if (bge_sc->bge_asicrev == BGE_ASICREV_BCM5906)
+ PHY_WRITE(sc, BRGPHY_MII_EPHY_PTEST, 0x12);
+
/* Handle any bce (NetXtreme II) workarounds. */
} else if (bce_sc) {
Index: dev/mii/brgphyreg.h
===================================================================
RCS file: /devel/FreeBSD/ncvs/src/sys/dev/mii/brgphyreg.h,v
retrieving revision 1.10
diff -u -r1.10 brgphyreg.h
--- dev/mii/brgphyreg.h 7 Jun 2007 02:21:38 -0000 1.10
+++ dev/mii/brgphyreg.h 25 Mar 2008 02:41:09 -0000
@@ -161,6 +161,7 @@
#define BRGPHY_MII_DSP_RW_PORT 0x15 /* DSP coefficient r/w port */
#define BRGPHY_MII_DSP_ADDR_REG 0x17 /* DSP coefficient addr register */
+#define BRGPHY_MII_EPHY_PTEST 0x17 /* 5906 PHY register */
#define BRGPHY_DSP_TAP_NUMBER_MASK 0x00
#define BRGPHY_DSP_AGC_A 0x00
Index: dev/mii/miidevs
===================================================================
RCS file: /devel/FreeBSD/ncvs/src/sys/dev/mii/miidevs,v
retrieving revision 1.51
diff -u -r1.51 miidevs
--- dev/mii/miidevs 6 Mar 2008 21:42:48 -0000 1.51
+++ dev/mii/miidevs 25 Mar 2008 02:43:03 -0000
@@ -52,6 +52,7 @@
oui ALTIMA 0x0010a9 Altima Communications
oui AMD 0x00001a Advanced Micro Devices
oui BROADCOM 0x001018 Broadcom Corporation
+oui BROADCOM2 0x000af7 Broadcom Corporation
oui CICADA 0x0003F1 Cicada Semiconductor
oui DAVICOM 0x00606e Davicom Semiconductor
oui ICPLUS 0x0090c3 IC Plus Corp.
@@ -138,6 +139,7 @@
model xxBROADCOM_ALT1 BCM5709CAX 0x002c BCM5709C(AX) 10/100/1000baseTX PHY
model xxBROADCOM_ALT1 BCM5722 0x002d BCM5722 10/100/1000baseTX PHY
model xxBROADCOM_ALT1 BCM5709C 0x003c BCM5709C 10/100/1000baseTX PHY
+model BROADCOM2 BCM5906 0x0004 BCM5906 10/100baseTX PHY
/* Cicada Semiconductor PHYs (now owned by Vitesse?) */
model CICADA CS8201 0x0001 Cicada CS8201 10/100/1000TX PHY
--------------030107050408040208070301--
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 14:03:49 2008
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 11239106566B;
Tue, 1 Apr 2008 14:03:49 +0000 (UTC) (envelope-from ap00@mail.ru)
Received: from mx0.awanti.com (mx0.awanti.com [91.190.112.18])
by mx1.freebsd.org (Postfix) with ESMTP id 8EABE8FC16;
Tue, 1 Apr 2008 14:03:48 +0000 (UTC) (envelope-from ap00@mail.ru)
Received: by mx0.awanti.com (Postfix, from userid 100)
id D55244C3F1; Tue, 1 Apr 2008 18:03:46 +0400 (MSD)
X-Spam-Flag: NO
X-Spam-Checker-Version: SpamAssassin 3.1.9 on mx0.awanti.com
X-Spam-Status: No, score=-2.3 required=6.5 tests=AWL,BAYES_00 autolearn=ham
version=3.1.9
Received: from pstation (unknown [10.28.4.14])
by mx0.awanti.com (Postfix) with ESMTP id A5F364C3DD;
Tue, 1 Apr 2008 18:03:45 +0400 (MSD)
Date: Tue, 1 Apr 2008 18:05:29 +0400
From: Anthony Pankov <ap00@mail.ru>
X-Mailer: The Bat! (v1.51) Personal
X-Priority: 3 (Normal)
Message-ID: <1493139437.20080401180529@mail.ru>
To: Rui Paulo <rpaulo@FreeBSD.org>
In-Reply-To: <20080401104128.GA1194@fnop.net>
References: <1333421734.20080328201458@mail.ru>
<20080401104128.GA1194@fnop.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org, performance@freebsd.org
Subject: Re[2]: packet delay because of blackhole
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Anthony Pankov <ap00@mail.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: Tue, 01 Apr 2008 14:03:49 -0000
Hello Rui,
Tuesday, April 01, 2008, 2:41:29 PM, you wrote:
RP> On Fri, Mar 28, 2008 at 08:14:58PM +0300, Anthony Pankov wrote:
>> Just for somebody convince.
>>
>> While analyzing client<->server HTTPS conversation one second delay in
>> packet exchange was discovered (strongly reproducible):
>>
>> Sample:
>> N time
>> 6 0.002303 10.28.4.14 10.28.4.50 SSL Client Hello
>> 7 0.106710 10.28.4.50 10.28.4.14 TCP 443 > 1447 [ACK] Seq=1 Ack=103 Win=65535 Len=0
>> 8 1.045712 10.28.4.50 10.28.4.14 TLSv1 Server Hello, Certificate, Server Hello Done
>>
>> Another sample:
>> 10 0.011722 10.28.4.14 10.28.4.50 TLSv1 Application Data
>> 11 0.115933 10.28.4.50 10.28.4.14 TCP 443 > 1442 [ACK] Seq=839 Ack=519 Win=65466 Len=0
>> 12 1.054037 10.28.4.50 10.28.4.14 TLSv1 Application Data
>>
>> The reason for delay is sysctl tcp.blackhole value grater than 0, much to surprise.
>>
>> So, turning tcp.blackhole to 0 eliminate any delay (strongly reproducible).
>>
>> System: FreeBSD 6_2_stable
RP> I'm not sure how performance penalty can induce a cache miss and I
RP> it's very processor specific. So, you're best guess is to profile the
RP> kernel.
RP> Regards,
I'm not fully understand what cache miss do you mean.
I'll try to be more clear.
During client<->server HTTPS conversation there is a packet delay (see "sample" and
"Another sample") about 900 ms. Delay appear one per conversation in
random place (between 7-8 packet in "sample", 11-12 in "another
sample"). Of course, it's not depending from SSL session cache, SSL
negotiation or any other apache/mod_ssl/OpenSSL setting/performance,
otherwise i should write to another maillist.
I have disabled all my sysctl tuning, one by one. No effect has
achieved.
But when i turn tcp.blackhole to zero, all things became fine. Maximum
delay between packet is 6 ms.
It is strange, so i've reported to all.
I suggest to keep tcp.blackhole=0 and use firewall for protection. If
one would raise tcp.blackhole value, than he should dump packets and
make sure that there is no strange delay between packets.
It most likely FreeBSD net issue.
P.S. "Another sample" is not a sequel of "Sample", it is a dump of
different transaction.
--
Best regards,
Anthony mailto:ap00@mail.ru
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 15:27:47 2008
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 9F0B41065671
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 15:27:47 +0000 (UTC)
(envelope-from kvilius.simas@gmail.com)
Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189])
by mx1.freebsd.org (Postfix) with ESMTP id 72CA88FC2D
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 15:27:47 +0000 (UTC)
(envelope-from kvilius.simas@gmail.com)
Received: by rv-out-0910.google.com with SMTP id g13so1416969rvb.43
for <freebsd-net@freebsd.org>; Tue, 01 Apr 2008 08:27:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
bh=nPnkjIXnz5b948Ouakb/lNoaBeOXiGP0qDpy/pWdM/Q=;
b=P8ESM42gl6oPiV1VJRXaTsaC2BLmYVJyswbFGSz1sR+CyzT0P769VwRfudCozdyVYgj4xLX2x0iFRqWy80x0S4l2nRzguwYN95J4gVlSwhHI4EhX37bS9wMnCASKvo0dsjL356Lxxg5frSuQ+LxMiv5rfQLSCm5nQ0navabDxvA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
b=LD/LWZi/K+O18vLc6gMXmeze6hryxn+fRhN1RgVnrKWTgqYjQAzj4qsZNkyAJ6o2Bf4dx75xuPpn3oEYybXF7ZKVDW9iJSwiTLoxtX4fsbGzMehxYM7eEjCramRSN3py5SnilVdojk4EUFwSGLJ39TPAa1VtC3D572twLkoWt6g=
Received: by 10.141.129.14 with SMTP id g14mr4370205rvn.274.1207063666997;
Tue, 01 Apr 2008 08:27:46 -0700 (PDT)
Received: by 10.141.49.9 with HTTP; Tue, 1 Apr 2008 08:27:46 -0700 (PDT)
Message-ID: <f30a14450804010827h6718f992jeaf42310db541055@mail.gmail.com>
Date: Tue, 1 Apr 2008 18:27:46 +0300
From: "Simas Kvilius" <kvilius.simas@gmail.com>
To: remko@freebsd.org
In-Reply-To: <200804010640.m316e4Fr099103@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200804010640.m316e4Fr099103@freefall.freebsd.org>
Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: kern/122319: [wi] imposible to enable ad-hoc demo mode with
Orinoco Gold PC card
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, 01 Apr 2008 15:27:47 -0000
Addition info:
Today I tested FreeBSD6.3 wi driver and inspected underlying wi code.
I found out that FreeBSD6.3 has the same adhoc demo bug as 7.0
(inability to turn on ad-hoc demo mode), I added following code to
/dev/wi/if_wi.c line 385:
ic->ic_caps |= IEEE80211_C_AHDEMO;
This code line completely fixed issues with my Lucent Orinoco wireless
card in FreeBSD6.3, now I'm able to do both tasks: enable ad-hoc mode
and change radio channels.
ifconfig wi0 media DS/11Mbps mode 11b mediaopt adhoc,flag0 <-- this
command enables ad-hoc demo mode as it should
ifconfig wi0 channel 13 <-- this command changes radio channel as it should
This discovery implies two things:
1. Inability to enable ad-hoc demo mode in FreeBSD6.3 and FreeBSD7.0
and inability to change channels if FreeBSD are two separate (and
probably unrelated) bugs.
2. Because in FreeBSD6.3 I can change channels, but in FreeBSD I can
not, the bug lies somewhere in code, which was updated between
FreeBSD6.3 and 7.0, moreover I discovered that I cannot change channel
in standard adhoc mode as well as in adhoc demo mode, so this bug is
general to adhoc mode.
On Tue, Apr 1, 2008 at 9:40 AM, <remko@freebsd.org> wrote:
> Synopsis: [wi] imposible to enable ad-hoc demo mode with Orinoco Gold PC card
>
> Responsible-Changed-From-To: freebsd-bugs->freebsd-net
> Responsible-Changed-By: remko
> Responsible-Changed-When: Tue Apr 1 06:39:55 UTC 2008
> Responsible-Changed-Why:
> reassign to networking team
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=122319
> _______________________________________________
> 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 Tue Apr 1 16:08:55 2008
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 6E7D2106567D
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 16:08:55 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
by mx1.freebsd.org (Postfix) with ESMTP id 2AE508FC1B
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 16:08:54 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1Jgj2Y-0002fp-Qv
for freebsd-net@freebsd.org; Tue, 01 Apr 2008 16:08:51 +0000
Received: from mulderlab.f5.com ([205.229.151.151])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Tue, 01 Apr 2008 16:08:50 +0000
Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Tue, 01 Apr 2008 16:08:50 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-net@freebsd.org
From: Mark Atkinson <atkin901@yahoo.com>
Date: Tue, 01 Apr 2008 09:08:35 -0700
Lines: 47
Message-ID: <fstmm9$oci$1@ger.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: mulderlab.f5.com
User-Agent: KNode/0.10.5
Sender: news <news@ger.gmane.org>
Subject: panic: tcp_addoptions: TCP options too long w/ with TCP_SIGNATURE
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: Tue, 01 Apr 2008 16:08:55 -0000
I have a 8-CURRENT kernel compiled with the following options, from about
march 5th.
options IPSEC
options TCP_SIGNATURE #include support for RFC 2385
device crypto
device cryptodev
device pf
device pflog
device vlan
I also have a external server supporting MD5 tcp signatures. If I give the
following command:
/usr/src/tools/regression/netinet/tcpconnect/tcpconnect client 172.16.1.145
7 1 tcpmd5
panic: tcp_addoptions: TCP options too long
cpuid = 0
KDB: enter: panic
[thread pid 63738 tid 100052 ]
Stopped at kdb_enter+0x3a: movl $0,kdb_why
db>
db> bt
Tracing pid 63738 tid 100052 td 0xc5065690
kdb_enter(c0b5e1c7,c0b5e1c7,c0b739e8,e8114ad4,0,...) at kdb_enter+0x3a
panic(c0b739e8,c0af8d24,4,e8114ba8,e8114ba4,...) at panic+0x12c
tcp_addoptions(e8114ba0,e8114bbc,c0b73a24,26f,c5065690,...) at
tcp_addoptions+0x367
tcp_output(c5711910,c50d7720,c0b75546,1d8,c570f2b8,...) at tcp_output+0x9a9
tcp_usr_connect(c577f308,c50d7720,c5065690,25,e8114c60,...) at
tcp_usr_connect+0x125
soconnect(c577f308,c50d7720,c5065690,c0800646,bfbfebf0,...) atsoconnect+0x52
kern_connect(c5065690,3,c50d7720,c50d7720,3,...) at kern_connect+0x96
connect(c5065690,e8114cfc,c,c0b63e42,c0c19b70,...) at connect+0x46
syscall(e8114d38) at syscall+0x2b3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (98, FreeBSD ELF32, connect), eip = 0x2813b1bb, esp =
0xbfbfebac, ebp = 0xbfbfec18 ---
db>
--
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 17:58:01 2008
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 D84BA106566B
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 17:58:01 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
by mx1.freebsd.org (Postfix) with ESMTP id 93A748FC15
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 17:58:01 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1Jgkk6-00009D-Qh
for freebsd-net@freebsd.org; Tue, 01 Apr 2008 17:57:55 +0000
Received: from mulderlab.f5.com ([205.229.151.151])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Tue, 01 Apr 2008 17:57:54 +0000
Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Tue, 01 Apr 2008 17:57:54 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-net@freebsd.org
From: Mark Atkinson <atkin901@yahoo.com>
Date: Tue, 01 Apr 2008 10:57:46 -0700
Lines: 52
Message-ID: <fstt2r$ifm$1@ger.gmane.org>
References: <fstmm9$oci$1@ger.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: mulderlab.f5.com
User-Agent: KNode/0.10.5
Sender: news <news@ger.gmane.org>
Subject: Re: panic: tcp_addoptions: TCP options too long w/ with
TCP_SIGNATURE 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: Tue, 01 Apr 2008 17:58:01 -0000
Mark Atkinson wrote:
> I have a 8-CURRENT kernel compiled with the following options, from about
> march 5th.
>
> options IPSEC
> options TCP_SIGNATURE #include support for RFC 2385
> device crypto
> device cryptodev
>
> device pf
> device pflog
>
> device vlan
>
> I also have a external server supporting MD5 tcp signatures. If I give
> the following command:
>
> /usr/src/tools/regression/netinet/tcpconnect/tcpconnect client
> 172.16.1.145 7 1 tcpmd5
>
> panic: tcp_addoptions: TCP options too long
> cpuid = 0
> KDB: enter: panic
> [thread pid 63738 tid 100052 ]
> Stopped at kdb_enter+0x3a: movl $0,kdb_why
> db>
> db> bt
> Tracing pid 63738 tid 100052 td 0xc5065690
> kdb_enter(c0b5e1c7,c0b5e1c7,c0b739e8,e8114ad4,0,...) at kdb_enter+0x3a
> panic(c0b739e8,c0af8d24,4,e8114ba8,e8114ba4,...) at panic+0x12c
> tcp_addoptions(e8114ba0,e8114bbc,c0b73a24,26f,c5065690,...) at
> tcp_addoptions+0x367
> tcp_output(c5711910,c50d7720,c0b75546,1d8,c570f2b8,...) at
> tcp_output+0x9a9
> tcp_usr_connect(c577f308,c50d7720,c5065690,25,e8114c60,...) at
> tcp_usr_connect+0x125
> soconnect(c577f308,c50d7720,c5065690,c0800646,bfbfebf0,...)
> atsoconnect+0x52 kern_connect(c5065690,3,c50d7720,c50d7720,3,...) at
> kern_connect+0x96 connect(c5065690,e8114cfc,c,c0b63e42,c0c19b70,...) at
> connect+0x46 syscall(e8114d38) at syscall+0x2b3 Xint0x80_syscall() at
> Xint0x80_syscall+0x20 --- syscall (98, FreeBSD ELF32, connect), eip =
> 0x2813b1bb, esp = 0xbfbfebac, ebp = 0xbfbfec18 ---
> db>
>
Confirmed to still be in a kernel built from todays sources.
--
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 19:12:56 2008
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 66D61106567F
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 19:12:56 +0000 (UTC)
(envelope-from rpaulo@gmail.com)
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188])
by mx1.freebsd.org (Postfix) with ESMTP id D08E98FC27
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 19:12:55 +0000 (UTC)
(envelope-from rpaulo@gmail.com)
Received: by fk-out-0910.google.com with SMTP id b27so3483197fka.11
for <freebsd-net@freebsd.org>; Tue, 01 Apr 2008 12:12:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender;
bh=1dkZ0O+/jPK5FqlySC6LlIA8EJEUan5L3wMf7pGUBu0=;
b=ITQ2xmumSv9JkWLhN21nXcQuzcZo09IOBFcuAg15LUz150U6qNzLdnev5BcqA0m60B7cux3XfJNVoCT1odEGQGQM/BhC+5ZWAVxOdNbQ8/8pw0GeK5k7eoPahUXZCMC9Hlj00J09Tnqt7lRuZHLBNlAVhzMXYZ4o6P/5xgRrF8U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
h=date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender;
b=Odj7220diT+R92g9H6aUYOpnSC0Q2QxPcpysQotLCW9mU/K8S4ydaX35Ex3iCQCxcjlCwpwuhLIHIV7jJq6mMQvdiY09LkgbO/JemkH0zxaYVkdMV1zK5WUg18OQHa+jkdtFgDW+ce0C0ONjY8DM3vOEhh5sKqryyIlHVSKmNLU=
Received: by 10.82.171.16 with SMTP id t16mr21188269bue.25.1207077173079;
Tue, 01 Apr 2008 12:12:53 -0700 (PDT)
Received: from fnop.net ( [89.214.179.125])
by mx.google.com with ESMTPS id e32sm512502fke.10.2008.04.01.12.12.50
(version=SSLv3 cipher=OTHER); Tue, 01 Apr 2008 12:12:52 -0700 (PDT)
Date: Tue, 1 Apr 2008 20:12:46 +0100
From: Rui Paulo <rpaulo@FreeBSD.org>
To: Mark Atkinson <atkin901@yahoo.com>
Message-ID: <20080401191246.GA1491@fnop.net>
References: <fstmm9$oci$1@ger.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <fstmm9$oci$1@ger.gmane.org>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: Rui Paulo <rpaulo@gmail.com>
Cc: freebsd-net@freebsd.org
Subject: Re: panic: tcp_addoptions: TCP options too long w/ with
TCP_SIGNATURE 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: Tue, 01 Apr 2008 19:12:56 -0000
Hi,
On Tue, Apr 01, 2008 at 09:08:35AM -0700, Mark Atkinson wrote:
> I have a 8-CURRENT kernel compiled with the following options, from about
> march 5th.
>
> options IPSEC
> options TCP_SIGNATURE #include support for RFC 2385
> device crypto
> device cryptodev
>
> device pf
> device pflog
>
> device vlan
>
> I also have a external server supporting MD5 tcp signatures. If I give the
> following command:
>
> /usr/src/tools/regression/netinet/tcpconnect/tcpconnect client 172.16.1.145
> 7 1 tcpmd5
>
> panic: tcp_addoptions: TCP options too long
Could you please use gdb or add a printf to find the value of optlen ?
--
Rui Paulo
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 19:28:19 2008
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 E061A106564A
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 19:28:18 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
by mx1.freebsd.org (Postfix) with ESMTP id 6E7C18FC39
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 19:28:18 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1Jgm9Y-0005gD-2g
for freebsd-net@freebsd.org; Tue, 01 Apr 2008 19:28:16 +0000
Received: from mulderlab.f5.com ([205.229.151.151])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Tue, 01 Apr 2008 19:28:16 +0000
Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Tue, 01 Apr 2008 19:28:16 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-net@freebsd.org
From: Mark Atkinson <atkin901@yahoo.com>
Date: Tue, 01 Apr 2008 12:28:06 -0700
Lines: 108
Message-ID: <fsu2c6$6iv$1@ger.gmane.org>
References: <fstmm9$oci$1@ger.gmane.org> <20080401191246.GA1491@fnop.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: mulderlab.f5.com
User-Agent: KNode/0.10.5
Sender: news <news@ger.gmane.org>
Subject: Re: panic: tcp_addoptions: TCP options too long w/ with
TCP_SIGNATURE 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: Tue, 01 Apr 2008 19:28:19 -0000
Rui Paulo wrote:
> Hi,
>
> On Tue, Apr 01, 2008 at 09:08:35AM -0700, Mark Atkinson wrote:
>> I have a 8-CURRENT kernel compiled with the following options, from about
>> march 5th.
>>
>> options IPSEC
>> options TCP_SIGNATURE #include support for RFC 2385
>> device crypto
>> device cryptodev
>>
>> device pf
>> device pflog
>>
>> device vlan
>>
>> I also have a external server supporting MD5 tcp signatures. If I give
>> the following command:
>>
>> /usr/src/tools/regression/netinet/tcpconnect/tcpconnect client
>> 172.16.1.145 7 1 tcpmd5
>>
>> panic: tcp_addoptions: TCP options too long
>
> Could you please use gdb or add a printf to find the value of optlen ?
>
$ kgdb kernel.debug /var/crash/vmcore.2
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Reading symbols from /boot/kernel/acpi.ko...Reading symbols
from /boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/ipfw.ko...Reading symbols
from /boot/kernel/ipfw.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ipfw.ko
Unread portion of the kernel message buffer:
panic: tcp_addoptions: TCP options too long
cpuid = 1
KDB: enter: panic
Physical memory: 2034 MB
Dumping 79 MB: 64 48 32 16
#0 doadump () at pcpu.h:195
195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0xc04c7159 in db_fncall (dummy1=1017, dummy2=0, dummy3=1019,
dummy4=0xe7b808b0 "ø\003") at /usr/src/sys/ddb/db_command.c:516
#2 0xc04c76dc in db_command (last_cmdp=0xc0c5c7b4, cmd_table=0x0,
dopager=1) at /usr/src/sys/ddb/db_command.c:413
#3 0xc04c77ea in db_command_loop () at /usr/src/sys/ddb/db_command.c:466
#4 0xc04c8fec in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228
#5 0xc07cf325 in kdb_trap (type=3, code=0, tf=0xe7b80a58)
at /usr/src/sys/kern/subr_kdb.c:510
#6 0xc0ac8d5f in trap (frame=0xe7b80a58)
at /usr/src/sys/i386/i386/trap.c:643
#7 0xc0aad7cb in calltrap () at /usr/src/sys/i386/i386/exception.s:146
#8 0xc07cf4aa in kdb_enter (why=0xc0b62ce8 "panic", msg=0xc0b62ce8 "panic")
at cpufunc.h:60
#9 0xc07a67cc in panic (fmt=0xc0b78840 "%s: TCP options too long")
at /usr/src/sys/kern/kern_shutdown.c:556
#10 0xc08e8207 in tcp_addoptions (to=0xe7b80ba4,
optp=0xe7b80bc0 "\002\004\005´\001\003\003\003\001\001\b\n")
at /usr/src/sys/netinet/tcp_output.c:1402
#11 0xc08e8c79 in tcp_output (tp=0xc576d570)
at /usr/src/sys/netinet/tcp_output.c:693
#12 0xc08f4f35 in tcp_usr_connect (so=0xc5709794, nam=0xc5260280,
td=0xc5729210) at tcp_offload.h:251
#13 0xc07ff092 in soconnect (so=0xc5709794, nam=0xc5260280, td=0xc5729210)
at /usr/src/sys/kern/uipc_socket.c:765
#14 0xc0805436 in kern_connect (td=0xc5729210, fd=3, sa=0xc5260280)
at /usr/src/sys/kern/uipc_syscalls.c:560
#15 0xc08055a6 in connect (td=0xc5729210, uap=0xe7b80cfc)
at /usr/src/sys/kern/uipc_syscalls.c:524
#16 0xc0ac8513 in syscall (frame=0xe7b80d38)
at /usr/src/sys/i386/i386/trap.c:1026
#17 0xc0aad830 in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:203
#18 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 10
#10 0xc08e8207 in tcp_addoptions (to=0xe7b80ba4,
optp=0xe7b80bc0 "\002\004\005´\001\003\003\003\001\001\b\n")
at /usr/src/sys/netinet/tcp_output.c:1402
1402 KASSERT(optlen <= TCP_MAXOLEN, ("%s: TCP options too long",
__func__));
(kgdb) p optlen
$1 = 44
(kgdb)
---
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 20:00:39 2008
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 9D55D106566C
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 20:00:39 +0000 (UTC)
(envelope-from andre@freebsd.org)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2])
by mx1.freebsd.org (Postfix) with ESMTP id 074518FC16
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 20:00:38 +0000 (UTC)
(envelope-from andre@freebsd.org)
Received: (qmail 44300 invoked from network); 1 Apr 2008 19:09:08 -0000
Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1])
(envelope-sender <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <atkin901@yahoo.com>; 1 Apr 2008 19:09:08 -0000
Message-ID: <47F29471.10901@freebsd.org>
Date: Tue, 01 Apr 2008 22:00:49 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Thunderbird 1.5.0.14 (Windows/20071210)
MIME-Version: 1.0
To: Mark Atkinson <atkin901@yahoo.com>
References: <fstmm9$oci$1@ger.gmane.org> <20080401191246.GA1491@fnop.net>
<fsu2c6$6iv$1@ger.gmane.org>
In-Reply-To: <fsu2c6$6iv$1@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: freebsd-net@freebsd.org, rpaulo@freebsd.org
Subject: Re: panic: tcp_addoptions: TCP options too long w/
with TCP_SIGNATURE 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: Tue, 01 Apr 2008 20:00:39 -0000
Mark Atkinson wrote:
> Rui Paulo wrote:
>
>> Hi,
>>
>> On Tue, Apr 01, 2008 at 09:08:35AM -0700, Mark Atkinson wrote:
>>> I have a 8-CURRENT kernel compiled with the following options, from about
>>> march 5th.
>>>
>>> options IPSEC
>>> options TCP_SIGNATURE #include support for RFC 2385
>>> device crypto
>>> device cryptodev
>>>
>>> device pf
>>> device pflog
>>>
>>> device vlan
>>>
>>> I also have a external server supporting MD5 tcp signatures. If I give
>>> the following command:
>>>
>>> /usr/src/tools/regression/netinet/tcpconnect/tcpconnect client
>>> 172.16.1.145 7 1 tcpmd5
>>>
>>> panic: tcp_addoptions: TCP options too long
>> Could you please use gdb or add a printf to find the value of optlen ?
>>
>
> $ kgdb kernel.debug /var/crash/vmcore.2
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
> Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd".
> Reading symbols from /boot/kernel/acpi.ko...Reading symbols
> from /boot/kernel/acpi.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/acpi.ko
> Reading symbols from /boot/kernel/ipfw.ko...Reading symbols
> from /boot/kernel/ipfw.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/ipfw.ko
>
> Unread portion of the kernel message buffer:
> panic: tcp_addoptions: TCP options too long
> cpuid = 1
> KDB: enter: panic
> Physical memory: 2034 MB
> Dumping 79 MB: 64 48 32 16
>
> #0 doadump () at pcpu.h:195
> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) bt
> #0 doadump () at pcpu.h:195
> #1 0xc04c7159 in db_fncall (dummy1=1017, dummy2=0, dummy3=1019,
> dummy4=0xe7b808b0 "ø\003") at /usr/src/sys/ddb/db_command.c:516
> #2 0xc04c76dc in db_command (last_cmdp=0xc0c5c7b4, cmd_table=0x0,
> dopager=1) at /usr/src/sys/ddb/db_command.c:413
> #3 0xc04c77ea in db_command_loop () at /usr/src/sys/ddb/db_command.c:466
> #4 0xc04c8fec in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228
> #5 0xc07cf325 in kdb_trap (type=3, code=0, tf=0xe7b80a58)
> at /usr/src/sys/kern/subr_kdb.c:510
> #6 0xc0ac8d5f in trap (frame=0xe7b80a58)
> at /usr/src/sys/i386/i386/trap.c:643
> #7 0xc0aad7cb in calltrap () at /usr/src/sys/i386/i386/exception.s:146
> #8 0xc07cf4aa in kdb_enter (why=0xc0b62ce8 "panic", msg=0xc0b62ce8 "panic")
> at cpufunc.h:60
> #9 0xc07a67cc in panic (fmt=0xc0b78840 "%s: TCP options too long")
> at /usr/src/sys/kern/kern_shutdown.c:556
> #10 0xc08e8207 in tcp_addoptions (to=0xe7b80ba4,
> optp=0xe7b80bc0 "\002\004\005´\001\003\003\003\001\001\b\n")
> at /usr/src/sys/netinet/tcp_output.c:1402
> #11 0xc08e8c79 in tcp_output (tp=0xc576d570)
> at /usr/src/sys/netinet/tcp_output.c:693
> #12 0xc08f4f35 in tcp_usr_connect (so=0xc5709794, nam=0xc5260280,
> td=0xc5729210) at tcp_offload.h:251
> #13 0xc07ff092 in soconnect (so=0xc5709794, nam=0xc5260280, td=0xc5729210)
> at /usr/src/sys/kern/uipc_socket.c:765
> #14 0xc0805436 in kern_connect (td=0xc5729210, fd=3, sa=0xc5260280)
> at /usr/src/sys/kern/uipc_syscalls.c:560
> #15 0xc08055a6 in connect (td=0xc5729210, uap=0xe7b80cfc)
> at /usr/src/sys/kern/uipc_syscalls.c:524
> #16 0xc0ac8513 in syscall (frame=0xe7b80d38)
> at /usr/src/sys/i386/i386/trap.c:1026
> #17 0xc0aad830 in Xint0x80_syscall ()
> at /usr/src/sys/i386/i386/exception.s:203
> #18 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb) frame 10
> #10 0xc08e8207 in tcp_addoptions (to=0xe7b80ba4,
> optp=0xe7b80bc0 "\002\004\005´\001\003\003\003\001\001\b\n")
> at /usr/src/sys/netinet/tcp_output.c:1402
> 1402 KASSERT(optlen <= TCP_MAXOLEN, ("%s: TCP options too long",
> __func__));
> (kgdb) p optlen
> $1 = 44
> (kgdb)
The order of the TCP options was changed recently to fix another problem.
This has caused sub-optimal padding and this overflow as not all options
fit. The tcp_addoptions() loop is not bound internally.
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c?rev=1.146
--
Andre
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 20:20:17 2008
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 53505106564A
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 20:20:17 +0000 (UTC)
(envelope-from rpaulo@gmail.com)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156])
by mx1.freebsd.org (Postfix) with ESMTP id CFB068FC15
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 20:20:16 +0000 (UTC)
(envelope-from rpaulo@gmail.com)
Received: by fg-out-1718.google.com with SMTP id 16so2342356fgg.35
for <freebsd-net@freebsd.org>; Tue, 01 Apr 2008 13:20:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender;
bh=fQ0gaspDDR6SOmA0HIaOI6GEVQUCmPw5lQK4b00rjkk=;
b=NSSkWdHxUHlpxHiW5Q3rs0XFkw/pUttFILANdmu5kJWtOfNf7qKfgWdisdA19RoXB2fA5Ltmjr062VvYMtQZ5O2VfvVR3dtwKNkyIeec04BAryZS+DiFxz3kFV58ZCoV0qllEzuNcUlsNWekALpDjjcAO7PW6KAcNlGgpp8eAvY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
h=date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender;
b=iBRqxqTqMsgcXf3iR6kQdUGZoTpVmSiWccqkidtZDEYfTmnLEOEzVV+4X7V0xR58ZiZhxQRLw6lE2LQNT/ujfKht97lBdneBmP/UZscleqzJGQQ4z/7FGVHYL9ehjLsumCy+jsh9u+PrckPkhofb45dHCYnBDDKbxRpKg5GsR54=
Received: by 10.86.82.16 with SMTP id f16mr5665088fgb.60.1207081213942;
Tue, 01 Apr 2008 13:20:13 -0700 (PDT)
Received: from fnop.net ( [89.214.179.125])
by mx.google.com with ESMTPS id 4sm383961fge.3.2008.04.01.13.20.11
(version=SSLv3 cipher=OTHER); Tue, 01 Apr 2008 13:20:13 -0700 (PDT)
Date: Tue, 1 Apr 2008 21:20:05 +0100
From: Rui Paulo <rpaulo@fnop.net>
To: Andre Oppermann <andre@freebsd.org>
Message-ID: <20080401202005.GB1491@fnop.net>
References: <fstmm9$oci$1@ger.gmane.org> <20080401191246.GA1491@fnop.net>
<fsu2c6$6iv$1@ger.gmane.org> <47F29471.10901@freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <47F29471.10901@freebsd.org>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: Rui Paulo <rpaulo@gmail.com>
Cc: freebsd-net@freebsd.org, rpaulo@freebsd.org,
Mark Atkinson <atkin901@yahoo.com>
Subject: Re: panic: tcp_addoptions: TCP options too long w/ with
TCP_SIGNATURE 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: Tue, 01 Apr 2008 20:20:17 -0000
On Tue, Apr 01, 2008 at 10:00:49PM +0200, Andre Oppermann wrote:
>
> The order of the TCP options was changed recently to fix another problem.
> This has caused sub-optimal padding and this overflow as not all options
> fit. The tcp_addoptions() loop is not bound internally.
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c?rev=1.146
Hmm. Are you sure you wanted to show this revision ?
There's not change for optlen because TCPOLEN_NOP == 1, I think.
--
Rui Paulo
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 20:39:35 2008
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 A74E5106564A
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 20:39:35 +0000 (UTC)
(envelope-from andre@freebsd.org)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2])
by mx1.freebsd.org (Postfix) with ESMTP id D26348FC1B
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 20:39:34 +0000 (UTC)
(envelope-from andre@freebsd.org)
Received: (qmail 44871 invoked from network); 1 Apr 2008 19:48:04 -0000
Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1])
(envelope-sender <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <rpaulo@fnop.net>; 1 Apr 2008 19:48:04 -0000
Message-ID: <47F29D91.6060408@freebsd.org>
Date: Tue, 01 Apr 2008 22:39:45 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Thunderbird 1.5.0.14 (Windows/20071210)
MIME-Version: 1.0
To: Rui Paulo <rpaulo@fnop.net>
References: <fstmm9$oci$1@ger.gmane.org> <20080401191246.GA1491@fnop.net>
<fsu2c6$6iv$1@ger.gmane.org> <47F29471.10901@freebsd.org>
<20080401202005.GB1491@fnop.net>
In-Reply-To: <20080401202005.GB1491@fnop.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org, rpaulo@freebsd.org,
Mark Atkinson <atkin901@yahoo.com>
Subject: Re: panic: tcp_addoptions: TCP options too long w/
with TCP_SIGNATURE 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: Tue, 01 Apr 2008 20:39:35 -0000
Rui Paulo wrote:
> On Tue, Apr 01, 2008 at 10:00:49PM +0200, Andre Oppermann wrote:
>> The order of the TCP options was changed recently to fix another problem.
>> This has caused sub-optimal padding and this overflow as not all options
>> fit. The tcp_addoptions() loop is not bound internally.
>>
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c?rev=1.146
>
> Hmm. Are you sure you wanted to show this revision ?
> There's not change for optlen because TCPOLEN_NOP == 1, I think.
Oops, wrong URL in paste buffer. Try this:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.160;r2=1.161
--
Andre
From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 20:40:54 2008
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 211851065670
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 20:40:54 +0000 (UTC)
(envelope-from andre@freebsd.org)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2])
by mx1.freebsd.org (Postfix) with ESMTP id 6E5F08FC2D
for <freebsd-net@freebsd.org>; Tue, 1 Apr 2008 20:40:53 +0000 (UTC)
(envelope-from andre@freebsd.org)
Received: (qmail 44895 invoked from network); 1 Apr 2008 19:49:22 -0000
Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1])
(envelope-sender <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <atkin901@yahoo.com>; 1 Apr 2008 19:49:22 -0000
Message-ID: <47F29DE0.6080500@freebsd.org>
Date: Tue, 01 Apr 2008 22:41:04 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Thunderbird 1.5.0.14 (Windows/20071210)
MIME-Version: 1.0
To: Mark Atkinson <atkin901@yahoo.com>
References: <fstmm9$oci$1@ger.gmane.org>
<20080401191246.GA1491@fnop.net> <fsu2c6$6iv$1@ger.gmane.org>
<47F29471.10901@freebsd.org>
In-Reply-To: <47F29471.10901@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: freebsd-net@freebsd.org, rpaulo@freebsd.org
Subject: Re: panic: tcp_addoptions: TCP options too long w/
with TCP_SIGNATURE 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: Tue, 01 Apr 2008 20:40:54 -0000
Andre Oppermann wrote:
> Mark Atkinson wrote:
>> Rui Paulo wrote:
>>
>>> Hi,
>>>
>>> On Tue, Apr 01, 2008 at 09:08:35AM -0700, Mark Atkinson wrote:
>>>> I have a 8-CURRENT kernel compiled with the following options, from
>>>> about
>>>> march 5th.
>>>>
>>>> options IPSEC
>>>> options TCP_SIGNATURE #include support for RFC 2385
>>>> device crypto
>>>> device cryptodev
>>>>
>>>> device pf
>>>> device pflog
>>>>
>>>> device vlan
>>>>
>>>> I also have a external server supporting MD5 tcp signatures. If I give
>>>> the following command:
>>>>
>>>> /usr/src/tools/regression/netinet/tcpconnect/tcpconnect client
>>>> 172.16.1.145 7 1 tcpmd5
>>>>
>>>> panic: tcp_addoptions: TCP options too long
>>> Could you please use gdb or add a printf to find the value of optlen ?
>>>
>>
>> $ kgdb kernel.debug /var/crash/vmcore.2
>> [GDB will not be able to debug user-mode threads:
>> /usr/lib/libthread_db.so:
>> Undefined symbol "ps_pglobal_lookup"]
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and
>> you are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for
>> details.
>> This GDB was configured as "i386-marcel-freebsd".
>> Reading symbols from /boot/kernel/acpi.ko...Reading symbols
>> from /boot/kernel/acpi.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/acpi.ko
>> Reading symbols from /boot/kernel/ipfw.ko...Reading symbols
>> from /boot/kernel/ipfw.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/ipfw.ko
>>
>> Unread portion of the kernel message buffer:
>> panic: tcp_addoptions: TCP options too long
>> cpuid = 1
>> KDB: enter: panic
>> Physical memory: 2034 MB
>> Dumping 79 MB: 64 48 32 16
>>
>> #0 doadump () at pcpu.h:195
>> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
>> (kgdb) bt
>> #0 doadump () at pcpu.h:195
>> #1 0xc04c7159 in db_fncall (dummy1=1017, dummy2=0, dummy3=1019,
>> dummy4=0xe7b808b0 "ø\003") at /usr/src/sys/ddb/db_command.c:516
>> #2 0xc04c76dc in db_command (last_cmdp=0xc0c5c7b4, cmd_table=0x0,
>> dopager=1) at /usr/src/sys/ddb/db_command.c:413
>> #3 0xc04c77ea in db_command_loop () at /usr/src/sys/ddb/db_command.c:466
>> #4 0xc04c8fec in db_trap (type=3, code=0) at
>> /usr/src/sys/ddb/db_main.c:228
>> #5 0xc07cf325 in kdb_trap (type=3, code=0, tf=0xe7b80a58)
>> at /usr/src/sys/kern/subr_kdb.c:510
>> #6 0xc0ac8d5f in trap (frame=0xe7b80a58)
>> at /usr/src/sys/i386/i386/trap.c:643
>> #7 0xc0aad7cb in calltrap () at /usr/src/sys/i386/i386/exception.s:146
>> #8 0xc07cf4aa in kdb_enter (why=0xc0b62ce8 "panic", msg=0xc0b62ce8
>> "panic")
>> at cpufunc.h:60
>> #9 0xc07a67cc in panic (fmt=0xc0b78840 "%s: TCP options too long")
>> at /usr/src/sys/kern/kern_shutdown.c:556
>> #10 0xc08e8207 in tcp_addoptions (to=0xe7b80ba4,
>> optp=0xe7b80bc0 "\002\004\005´\001\003\003\003\001\001\b\n")
>> at /usr/src/sys/netinet/tcp_output.c:1402
>> #11 0xc08e8c79 in tcp_output (tp=0xc576d570)
>> at /usr/src/sys/netinet/tcp_output.c:693
>> #12 0xc08f4f35 in tcp_usr_connect (so=0xc5709794, nam=0xc5260280,
>> td=0xc5729210) at tcp_offload.h:251
>> #13 0xc07ff092 in soconnect (so=0xc5709794, nam=0xc5260280,
>> td=0xc5729210)
>> at /usr/src/sys/kern/uipc_socket.c:765
>> #14 0xc0805436 in kern_connect (td=0xc5729210, fd=3, sa=0xc5260280)
>> at /usr/src/sys/kern/uipc_syscalls.c:560
>> #15 0xc08055a6 in connect (td=0xc5729210, uap=0xe7b80cfc)
>> at /usr/src/sys/kern/uipc_syscalls.c:524
>> #16 0xc0ac8513 in syscall (frame=0xe7b80d38)
>> at /usr/src/sys/i386/i386/trap.c:1026
>> #17 0xc0aad830 in Xint0x80_syscall ()
>> at /usr/src/sys/i386/i386/exception.s:203
>> #18 0x00000033 in ?? ()
>> Previous frame inner to this frame (corrupt stack?)
>> (kgdb) frame 10
>> #10 0xc08e8207 in tcp_addoptions (to=0xe7b80ba4,
>> optp=0xe7b80bc0 "\002\004\005´\001\003\003\003\001\001\b\n")
>> at /usr/src/sys/netinet/tcp_output.c:1402
>> 1402 KASSERT(optlen <= TCP_MAXOLEN, ("%s: TCP options too
>> long",
>> __func__));
>> (kgdb) p optlen
>> $1 = 44
>> (kgdb)
>
> The order of the TCP options was changed recently to fix another problem.
> This has caused sub-optimal padding and this overflow as not all options
> fit. The tcp_addoptions() loop is not bound internally.
Correction: It is bound but not for all options (only SACK and Signature).
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c?rev=1.146
Before:
MSS (4) + NOP (1) + Window scale (3) + SACK permitted (2) +
Timestamp (10) + Signature (18) = 38 bytes out of a maximum of 40.
After:
MSS (4) + NOP (1) + Window scale (3) + NOP (2) + Timestamp (10) +
NOP (2) + Signature (18) + SACK permitted (2) + EOL (1) + PAD (1) =
44 bytes out of a maximum of 40.
With the attached patch it will omit the SACK permitted option (disabling
SACK) and limiting it to 40 bytes.
--
Andre
==== //depot/projects/tcp_reass/netinet/tcp_output.c#5 (text+ko) ====
@@ -1279,12 +1279,16 @@
for (mask = 1; mask < TOF_MAXOPT; mask <<= 1) {
if ((to->to_flags & mask) != mask)
continue;
+ if (optlen == TCP_MAXOLEN)
+ break;
switch (to->to_flags & mask) {
case TOF_MSS:
while (optlen % 4) {
optlen += TCPOLEN_NOP;
*optp++ = TCPOPT_NOP;
}
+ if (TCP_MAXOLEN - optlen < TCPOLEN_MAXSEG)
+ continue;
optlen += TCPOLEN_MAXSEG;
*optp++ = TCPOPT_MAXSEG;
*optp++ = TCPOLEN_MAXSEG;
@@ -1297,6 +1301,8 @@
optlen += TCPOLEN_NOP;
*optp++ = TCPOPT_NOP;
}
+ if (TCP_MAXOLEN - optlen < TCPOLEN_WINDOW)
+ continue;
optlen += TCPOLEN_WINDOW;
*optp++ = TCPOPT_WINDOW;
*optp++ = TCPOLEN_WINDOW;
@@ -1307,6 +1313,8 @@
optlen += TCPOLEN_NOP;
*optp++ = TCPOPT_NOP;
}
+ if (TCP_MAXOLEN - optlen < TCPOLEN_SACK_PERMITTED)
+ continue;
optlen += TCPOLEN_SACK_PERMITTED;
*optp++ = TCPOPT_SACK_PERMITTED;
*optp++ = TCPOLEN_SACK_PERMITTED;
@@ -1316,6 +1324,8 @@
optlen += TCPOLEN_NOP;
*optp++ = TCPOPT_NOP;
}
+ if (TCP_MAXOLEN - optlen < TCPOLEN_TIMESTAMP)
+ continue;
optlen += TCPOLEN_TIMESTAMP;
*optp++ = TCPOPT_TIMESTAMP;
*optp++ = TCPOLEN_TIMESTAMP;
@@ -1352,7 +1362,7 @@
optlen += TCPOLEN_NOP;
*optp++ = TCPOPT_NOP;
}
- if (TCP_MAXOLEN - optlen < 2 + TCPOLEN_SACK)
+ if (TCP_MAXOLEN - optlen < TCPOLEN_SACKHDR + TCPOLEN_SACK)
continue;
optlen += TCPOLEN_SACKHDR;
*optp++ = TCPOPT_SACK;
From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 00:16:58 2008
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 199251065676;
Wed, 2 Apr 2008 00:16:58 +0000 (UTC) (envelope-from bms@FreeBSD.org)
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com
[66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id E03A68FC1A;
Wed, 2 Apr 2008 00:16:57 +0000 (UTC) (envelope-from bms@FreeBSD.org)
Received: from compute2.internal (compute2.internal [10.202.2.42])
by out1.messagingengine.com (Postfix) with ESMTP id 47989E4A01;
Tue, 1 Apr 2008 20:16:57 -0400 (EDT)
Received: from heartbeat1.messagingengine.com ([10.202.2.160])
by compute2.internal (MEProxy); Tue, 01 Apr 2008 20:16:57 -0400
X-Sasl-enc: qJb6xZkjb0xttlvEF81q7u8BG4mCX9y1R6Nj0uihOd4h 1207095416
Received: from empiric.lon.incunabulum.net
(82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254])
by mail.messagingengine.com (Postfix) with ESMTPSA id 5576A104D2;
Tue, 1 Apr 2008 20:16:56 -0400 (EDT)
Message-ID: <47F2D077.3000503@FreeBSD.org>
Date: Wed, 02 Apr 2008 01:16:55 +0100
From: "Bruce M. Simpson" <bms@FreeBSD.org>
User-Agent: Thunderbird 2.0.0.9 (X11/20080207)
MIME-Version: 1.0
To: Andre Oppermann <andre@freebsd.org>
References: <fstmm9$oci$1@ger.gmane.org> <20080401191246.GA1491@fnop.net> <fsu2c6$6iv$1@ger.gmane.org> <47F29471.10901@freebsd.org>
<47F29DE0.6080500@freebsd.org>
In-Reply-To: <47F29DE0.6080500@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org, rpaulo@freebsd.org,
Mark Atkinson <atkin901@yahoo.com>
Subject: Re: panic: tcp_addoptions: TCP options too long w/
with TCP_SIGNATURE 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: Wed, 02 Apr 2008 00:16:58 -0000
Dontcha just hate broken vendor NAT?
Yes, it seems reasonable that SACK is the sacrificial victim.
Considering folk normally configure TCP-MD5 between routers which are
usually directly connected on the same switch, doing away with SACK
should be fine.
Funny, I was staring at that define moments ago whilst debugging a
totally unrelated piece of code in a different language.
Good stuff.
From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 05:28:01 2008
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 3EC20106566B;
Wed, 2 Apr 2008 05:28:01 +0000 (UTC)
(envelope-from matthias.apitz@oclc.org)
Received: from hunter.Sisis.de (hunter.sisis.de [193.31.11.194])
by mx1.freebsd.org (Postfix) with ESMTP id 1236C8FC14;
Wed, 2 Apr 2008 05:27:59 +0000 (UTC)
(envelope-from matthias.apitz@oclc.org)
Received: (from mail@localhost) by hunter.Sisis.de (8.8.8/8.8.8) id HAA16025;
Wed, 2 Apr 2008 07:02:58 +0200 (CEST)
(envelope-from matthias.apitz@oclc.org)
Received: from ppp-82-135-9-69.dynamic.mnet-online.de(82.135.9.69) by
hunter.Sisis.de via smap (V2.1)
id xma015991; Wed, 2 Apr 08 07:02:50 +0200
Received: (from guru@localhost)
by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id m325A50a002667;
Wed, 2 Apr 2008 07:10:05 +0200 (CEST)
(envelope-from matthias.apitz@oclc.org)
X-Authentication-Warning: rebelion.Sisis.de: guru set sender to
matthias.apitz@oclc.org using -f
Date: Wed, 2 Apr 2008 07:10:05 +0200
From: Matthias Apitz <guru@Sisis.de>
To: linimon@freebsd.org
Message-ID: <20080402051005.GA2200@rebelion.Sisis.de>
References: <200804020024.m320OQE6071682@freefall.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200804020024.m320OQE6071682@freefall.freebsd.org>
User-Agent: Mutt/1.4.2.3i
X-Operating-System: FreeBSD 7.0-RELEASE (i386)
Cc: freebsd-net@freebsd.org, guru@Sisis.de, freebsd-bugs@freebsd.org
Subject: Re: kern/122331: [panic] 7.0-RELEASE && panic in Wifi area with WPA
mode (not in WEP mode)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Matthias Apitz <matthias.apitz@oclc.org>
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, 02 Apr 2008 05:28:01 -0000
El dÃa Wednesday, April 02, 2008 a las 12:24:26AM +0000, linimon@freebsd.org escribió:
> Synopsis: [panic] 7.0-RELEASE && panic in Wifi area with WPA mode (not in WEP mode)
>
> State-Changed-From-To: open->closed
> State-Changed-By: linimon
> State-Changed-When: Wed Apr 2 00:24:15 UTC 2008
> State-Changed-Why:
> See kern/122286 from same submitter.
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=122331
hmmm :-)
Kris Kennaway <kris@FreeBSD.org> asked me to file this new bug report
kern/122331 because the kgdb backtrace in kern/122286 looks for him more
like a panic caused by an unclean file system (which was indeed unclean
in that moment as a 'fsck -fy' in single user mode proofed);
maybe I should attach the kgdb backtrace from kern/122331 to
kern/122286?
thanks in advance for closing kern/122286 as well with a
solution, I hope :-)
if you need further information, just let me know; it's really boring to
stay in my office with Ethernet cable, while the Windows guys walk freely
around :-(
matthias
--
Matthias Apitz
Manager Technical Support - OCLC GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <matthias.apitz@oclc.org> - w http://www.oclc.org/ http://www.UnixArea.de/
b http://gurucubano.blogspot.com/
Don't top-post, read RFC1855 http://www.faqs.org/rfcs/rfc1855.html
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on Usenet and in e-mail?
From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 09:49:03 2008
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 E44081065672;
Wed, 2 Apr 2008 09:49:03 +0000 (UTC)
(envelope-from kris@FreeBSD.org)
Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28])
by mx1.freebsd.org (Postfix) with ESMTP id 34A408FC1C;
Wed, 2 Apr 2008 09:49:02 +0000 (UTC)
(envelope-from kris@FreeBSD.org)
Message-ID: <47F35693.4050700@FreeBSD.org>
Date: Wed, 02 Apr 2008 11:49:07 +0200
From: Kris Kennaway <kris@FreeBSD.org>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Matthias Apitz <matthias.apitz@oclc.org>
References: <200804020024.m320OQE6071682@freefall.freebsd.org>
<20080402051005.GA2200@rebelion.Sisis.de>
In-Reply-To: <20080402051005.GA2200@rebelion.Sisis.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: freebsd-net@freebsd.org, guru@Sisis.de, freebsd-bugs@freebsd.org,
linimon@freebsd.org
Subject: Re: kern/122331: [panic] 7.0-RELEASE && panic in Wifi area with WPA
mode (not in WEP mode)
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, 02 Apr 2008 09:49:04 -0000
Matthias Apitz wrote:
> El dÃa Wednesday, April 02, 2008 a las 12:24:26AM +0000, linimon@freebsd.org escribió:
>
>> Synopsis: [panic] 7.0-RELEASE && panic in Wifi area with WPA mode (not in WEP mode)
>>
>> State-Changed-From-To: open->closed
>> State-Changed-By: linimon
>> State-Changed-When: Wed Apr 2 00:24:15 UTC 2008
>> State-Changed-Why:
>> See kern/122286 from same submitter.
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=122331
>
> hmmm :-)
>
> Kris Kennaway <kris@FreeBSD.org> asked me to file this new bug report
> kern/122331 because the kgdb backtrace in kern/122286 looks for him more
> like a panic caused by an unclean file system (which was indeed unclean
> in that moment as a 'fsck -fy' in single user mode proofed);
>
> maybe I should attach the kgdb backtrace from kern/122331 to
> kern/122286?
>
> thanks in advance for closing kern/122286 as well with a
> solution, I hope :-)
>
> if you need further information, just let me know; it's really boring to
> stay in my office with Ethernet cable, while the Windows guys walk freely
> around :-(
>
> matthias
Yes, this new one is unrelated to the old one (also not related to wifi
though) and should stay open. The panic in the old PR is also not
wifi-related, but there are apparently non-panic wifi issues that he
still needs to resolve.
Kris
From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 12:16:13 2008
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 174A11065675;
Wed, 2 Apr 2008 12:16:13 +0000 (UTC)
(envelope-from fbsd.questions@rachie.is-a-geek.net)
Received: from snoogles.rachie.is-a-geek.net (rachie.is-a-geek.net
[66.230.99.27])
by mx1.freebsd.org (Postfix) with ESMTP id 94A048FC13;
Wed, 2 Apr 2008 12:16:12 +0000 (UTC)
(envelope-from fbsd.questions@rachie.is-a-geek.net)
Received: from localhost (localhost [127.0.0.1])
by snoogles.rachie.is-a-geek.net (Postfix) with ESMTP id 215CD1CD60;
Wed, 2 Apr 2008 04:00:06 -0800 (AKDT)
From: Mel <fbsd.questions@rachie.is-a-geek.net>
To: freebsd-mobile@freebsd.org
Date: Wed, 2 Apr 2008 14:00:02 +0200
User-Agent: KMail/1.9.7
References: <47C078EC.4020907@student.utwente.nl>
<D148E5EB841844D393DBB58285CEA4BF@alderaan>
<47E1088A.8090203@clearchain.com>
In-Reply-To: <47E1088A.8090203@clearchain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200804021400.04442.fbsd.questions@rachie.is-a-geek.net>
Cc: Yousif Hassan <yousif@alumni.jmu.edu>, Sam Leffler <sam@freebsd.org>,
Benjamin Close <Benjamin.Close@clearchain.com>,
Alphons Fonz van Werven <a.j.werven@student.utwente.nl>,
freebsd-net@freebsd.org
Subject: Re: [Wireless] Can't connect to wlan
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, 02 Apr 2008 12:16:13 -0000
On Wednesday 19 March 2008 13:35:22 Benjamin Close wrote:
> Yousif Hassan wrote:
> > Benjamin Close wrote:
> >> Sam Leffler wrote:
> >>> Yousif Hassan wrote:
> >>>> On Wed, 2008-03-12 at 08:06 +1030, Benjamin Close wrote:
> >
> > <snip>
> >
> >>>> The slightly wonky:
> >>>> - As reported by someone else:
> >>>> wpi0: timeout resetting Tx ring 1
> >>>> wpi0: timeout resetting Tx ring 3
> >>>> wpi0: timeout resetting Tx ring 4
> >>>> appear on startup and occasionally on kldload - however they don't
> >>>> appear to adversely affect too much
> >
> > <snip>
> >
> >>> wpi doesn't yet support background scan so doing an explicit scan
> >>> from the command line will disconnect you from any ap you care
> >>> connected to. It shouldn't be hard to add bgscan--but that's easy
> >>> for me to say :)
> >>
> >> It's certainly on my todo list!
> >
> > Thanks for reminding me about the bgscan thing. I had read that
> > somewhere before and completely forgotten!
> >
> > Ben, are the
> > wpi0: timeout resetting Tx ring 1
> > wpi0: timeout resetting Tx ring 3
> > wpi0: timeout resetting Tx ring 4
> > (and other variants thereof)
> > messages anything to be concerned about? It doesn't seem to affect
> > stuff but it does show up on initial startup and every other scan I do.
> >
> > Thanks to everyone who worked on wpi for a most excellent driver.
>
> The timeouts are related to the firmware not being able to reset the tx
> ring. Normally this isn't too bad as the first thing after resetting the
> tx rings is to stop the firmware and reinit it. Whilst it won't cause a
> crash, it still a bug that needs fixing.
I think I finally found the issue with the connection dropping. It is related
to a beacon miss and the driver not getting back to authenticated state.
The /root/bin/testwpi.sh script mentioned below pings the AP 50 times sends it
to syslog and does it again.
Apr 1 09:20:30 laptop kernel: Beacon miss: 20 >= 7
Apr 1 09:20:30 laptop kernel: Beacon miss: 21 >= 7
Apr 1 09:20:30 laptop kernel: wpi_newstate: RUN -> ASSOC
Apr 1 09:20:30 laptop kernel: wpi0: link state changed to DOWN
Then this Beacon miss continues incrementing until:
Apr 1 09:20:56 laptop kernel: Beacon miss: 274 >= 7
At this point the packet loss is still 100%:
Apr 1 09:21:04 laptop /root/bin/testwpi.sh: 50 packets transmitted, 14
packets received, 72.0%
packet loss round-trip min/avg/max/stddev = 0.513/0.599/1.046/0.131 ms
Apr 1 09:22:05 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0%
packet loss
Apr 1 09:23:06 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0%
packet loss
Then for no apparent reason, it tries again:
Apr 1 10:49:41 laptop kernel: Beacon miss: 20 >= 7
Apr 1 10:49:41 laptop kernel: Beacon miss: 21 >= 7
Apr 1 10:49:41 laptop kernel: Beacon miss: 22 >= 7
...
Apr 1 10:50:07 laptop kernel: Beacon miss: 273 >= 7
Apr 1 10:50:37 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0% packet loss
Apr 1 10:51:38 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0% packet loss
Apr 1 10:53:40 laptop last message repeated 2 times
Apr 1 11:03:51 laptop last message repeated 10 times
...
Then for no apparent reason (as far as I know, no one was near the machine at
the time):
Apr 1 16:34:00 laptop kernel: wpi_newstate: ASSOC -> AUTH
Apr 1 16:34:00 laptop kernel: wpi_ops: command: 16
Apr 1 16:34:00 laptop kernel: config chan 1 flags 8035 cck f ofdm 15
Apr 1 16:34:00 laptop kernel: wpi_ops: command: 1
Apr 1 16:34:00 laptop kernel: wpi_ops: command: 8
Apr 1 16:34:00 laptop kernel: Ignoring WPI_SET_CHAN
Apr 1 16:34:00 laptop kernel: wpi_ops: command: 2
Apr 1 16:34:00 laptop kernel: Scanning Essid: "MYSSID"
Apr 1 16:34:00 laptop kernel: Scanning 1 Passive: 0
Apr 1 16:34:00 laptop kernel: wpi_newstate: AUTH -> AUTH
Apr 1 16:34:00 laptop kernel: wpi_ops: command: 16
Apr 1 16:34:00 laptop kernel: config chan 1 flags 8035 cck f ofdm 15
Apr 1 16:34:00 laptop kernel: scanning channel 1 status 1
Apr 1 16:34:00 laptop kernel: scan finished nchan=0 status=2 chan=0
Apr 1 16:34:00 laptop kernel: wpi_ops: command: 4
Apr 1 16:34:36 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0% packet loss
Apr 1 16:35:37 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0% packet loss
Apr 1 16:36:38 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets
received, 100.0% packet loss
Apr 1 16:46:49 laptop last message repeated 10 times
And then my girl came home from work and did the "down and list scan trick":
Apr 1 17:53:06 laptop sudo: rachie : TTY=ttyp1 ; PWD=/home/rachie ;
USER=root ; COMMAND=/sbi
n/ifconfig wpi0 down
Apr 1 17:53:06 laptop kernel: Disabling Firmware execution
Apr 1 17:53:06 laptop kernel: wpi_newstate: AUTH -> INIT
Apr 1 17:53:10 laptop sudo: rachie : TTY=ttyp1 ; PWD=/home/rachie ;
USER=root ; COMMAND=/sbi
n/ifconfig wpi0 up list scan
Apr 1 17:53:11 laptop kernel: wpi0: timeout resetting Tx ring 1
Apr 1 17:53:11 laptop kernel: wpi0: timeout resetting Tx ring 3
Apr 1 17:53:11 laptop kernel: wpi0: timeout resetting Tx ring 4
Apr 1 17:53:11 laptop kernel: Disabling Firmware execution
Apr 1 17:53:11 laptop kernel: wpi_newstate: INIT -> INIT
Apr 1 17:53:11 laptop kernel: Resetting the card - clearing any uploaded
firmware
Apr 1 17:53:11 laptop kernel: Attempting Loading Firmware from wpi_fw module
Apr 1 17:53:11 laptop kernel: Firmware Version: Major 2, Minor 14, Driver 4,
Apr 1 17:53:11 laptop kernel: runtime (text: 80524, data: 32768) init (text:
2668, data 32768)
boot (text 900)
Apr 1 17:53:11 laptop kernel: rtext 0xf802020
Apr 1 17:53:11 laptop kernel: rdata 0x0
Apr 1 17:53:11 laptop kernel: itext 0xf802020
Apr 1 17:53:11 laptop kernel: idata 0x0
Apr 1 17:53:11 laptop kernel: btext 0xf802020
Apr 1 17:53:11 laptop kernel: Loading microcode size 0x384
Apr 1 17:53:11 laptop kernel: firmware status=0xffff0000, val=0x40400000,
result=0x40400000
Apr 1 17:53:11 laptop kernel: Status Match! - ntries = 0
Apr 1 17:53:11 laptop kernel: microcode alive notification version 10e02
alive 1
Apr 1 17:53:11 laptop kernel: microcode alive notification version 10e02
alive 1
Apr 1 17:53:11 laptop kernel: Firmware loaded to driver successfully
Apr 1 17:53:11 laptop kernel: wpi_newstate: INIT -> SCAN
Apr 1 17:53:11 laptop kernel: wpi_ops: command: 1
Apr 1 17:53:11 laptop kernel: wpi_ops: command: 8
<snipped lots of scanning>
Apr 1 17:53:13 laptop kernel: scan finished nchan=1 status=1 chan=165
Apr 1 17:53:13 laptop kernel: wpi_newstate: SCAN -> AUTH
Apr 1 17:53:13 laptop kernel: wpi_ops: command: 4
Apr 1 17:53:13 laptop kernel: wpi_ops: command: 8
Apr 1 17:53:13 laptop kernel: Ignoring WPI_SET_CHAN
Apr 1 17:53:13 laptop kernel: wpi_ops: command: 8
Apr 1 17:53:13 laptop kernel: Ignoring WPI_SET_CHAN
Apr 1 17:53:13 laptop kernel: wpi_ops: command: 16
Apr 1 17:53:13 laptop kernel: config chan 1 flags 8005 cck f ofdm 15
Apr 1 17:53:13 laptop kernel: wpi_newstate: AUTH -> ASSOC
Apr 1 17:53:13 laptop kernel: wpi_newstate: ASSOC -> RUN
Apr 1 17:53:13 laptop kernel: wpi_ops: command: 32
Apr 1 17:53:13 laptop kernel: config chan 1 flags 8035
Apr 1 17:53:13 laptop kernel: wpi0: link state changed to UP
At this point it's working again, connection is flakey with packet loss
ranging from 0 to 50% but it's working.
This is wpi from 7-RELEASE with patch mentioned in this thread.
--
Mel
Problem with today's modular software: they start with the modules
and never get to the software part.
From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 14:50:02 2008
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 A50201065672
for <freebsd-net@hub.freebsd.org>; Wed, 2 Apr 2008 14:50:02 +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 9135B8FC13
for <freebsd-net@hub.freebsd.org>; Wed, 2 Apr 2008 14:50:02 +0000 (UTC)
(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1])
by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m32Eo2WJ059790
for <freebsd-net@freefall.freebsd.org>; Wed, 2 Apr 2008 14:50:02 GMT
(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m32Eo20O059789;
Wed, 2 Apr 2008 14:50:02 GMT (envelope-from gnats)
Date: Wed, 2 Apr 2008 14:50:02 GMT
Message-Id: <200804021450.m32Eo20O059789@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: "Simas Kvilius" <kvilius.simas@gmail.com>
Cc:
Subject: Re: kern/122319: [wi] imposible to enable ad-hoc demo mode with
Orinoco Gold PC card
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Simas Kvilius <kvilius.simas@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: Wed, 02 Apr 2008 14:50:02 -0000
The following reply was made to PR kern/122319; it has been noted by GNATS.
From: "Simas Kvilius" <kvilius.simas@gmail.com>
To: bug-followup@FreeBSD.org, kvilius.simas@gmail.com
Cc:
Subject: Re: kern/122319: [wi] imposible to enable ad-hoc demo mode with Orinoco Gold PC card
Date: Wed, 2 Apr 2008 17:16:32 +0300
Addition info:
Today I tested FreeBSD6.3 wi driver and inspected underlying wi code.
I found out that FreeBSD6.3 has the same adhoc demo bug as 7.0
(inability to turn on ad-hoc demo mode), I added following code to
/dev/wi/if_wi.c line 385:
ic->ic_caps |= IEEE80211_C_AHDEMO;
This code line completely fixed issues with my Lucent Orinoco wireless
card in FreeBSD6.3, now I'm able to do both tasks: enable ad-hoc mode
and change radio channels.
ifconfig wi0 media DS/11Mbps mode 11b mediaopt adhoc,flag0 <-- this
command enables ad-hoc demo mode as it should
ifconfig wi0 channel 13 <-- this command changes radio channel as it should
This discovery implies two things:
1. Inability to enable ad-hoc demo mode in FreeBSD6.3 and FreeBSD7.0
and inability to change channels if FreeBSD are two separate (and
probably unrelated) bugs.
2. Because in FreeBSD6.3 I can change channels, but in FreeBSD I can
not, the bug lies somewhere in code, which was updated between
FreeBSD6.3 and 7.0, moreover I discovered that I cannot change channel
in standard adhoc mode as well as in adhoc demo mode, so this bug is
general to adhoc mode.
From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 15:08:31 2008
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 C94FA1065741
for <freebsd-net@freebsd.org>; Wed, 2 Apr 2008 15:08:31 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
by mx1.freebsd.org (Postfix) with ESMTP id 81E1E8FC1A
for <freebsd-net@freebsd.org>; Wed, 2 Apr 2008 15:08:31 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1Jh4Zg-0000cQ-C5
for freebsd-net@freebsd.org; Wed, 02 Apr 2008 15:08:28 +0000
Received: from mulderlab.f5.com ([205.229.151.151])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Wed, 02 Apr 2008 15:08:28 +0000
Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Wed, 02 Apr 2008 15:08:28 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-net@freebsd.org
From: Mark Atkinson <atkin901@yahoo.com>
Date: Wed, 02 Apr 2008 08:08:18 -0700
Lines: 25
Message-ID: <ft07h2$ukj$1@ger.gmane.org>
References: <fstmm9$oci$1@ger.gmane.org>
<20080401191246.GA1491@fnop.net> <fsu2c6$6iv$1@ger.gmane.org>
<47F29471.10901@freebsd.org> <47F29DE0.6080500@freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: mulderlab.f5.com
User-Agent: KNode/0.10.5
Sender: news <news@ger.gmane.org>
Subject: Re: panic: tcp_addoptions: TCP options too long w/
with TCP_SIGNATURE 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: Wed, 02 Apr 2008 15:08:31 -0000
Andre Oppermann wrote:
> Before:
>
> MSS (4) + NOP (1) + Window scale (3) + SACK permitted (2) +
> Timestamp (10) + Signature (18) = 38 bytes out of a maximum of 40.
>
> After:
>
> MSS (4) + NOP (1) + Window scale (3) + NOP (2) + Timestamp (10) +
> NOP (2) + Signature (18) + SACK permitted (2) + EOL (1) + PAD (1) =
> 44 bytes out of a maximum of 40.
>
> With the attached patch it will omit the SACK permitted option (disabling
> SACK) and limiting it to 40 bytes.
Appears to work with patch.
08:06:38.324770 IP 172.16.15.254.41869 > 172.16.1.145.7: S
1106204761:1106204761(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp
684040 0,nop,nop,md5:valid>
--
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);
From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 15:33:20 2008
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 12DF1106564A;
Wed, 2 Apr 2008 15:33:20 +0000 (UTC)
(envelope-from Matthias.Apitz@oclc.org)
Received: from mail.pica.nl (mail.pica.nl [192.87.44.30])
by mx1.freebsd.org (Postfix) with ESMTP id 930DF8FC23;
Wed, 2 Apr 2008 15:33:19 +0000 (UTC)
(envelope-from Matthias.Apitz@oclc.org)
Received: from rebelion.Sisis.de ([193.31.10.34]) by mail.pica.nl with
Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 17:36:00 +0200
Received: (from guru@localhost)
by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id m32FX8Gg066848;
Wed, 2 Apr 2008 17:33:08 +0200 (CEST)
(envelope-from matthias.apitz@oclc.org)
X-Authentication-Warning: rebelion.Sisis.de: guru set sender to
matthias.apitz@oclc.org using -f
Date: Wed, 2 Apr 2008 17:33:08 +0200
From: Matthias Apitz <guru@Sisis.de>
To: freebsd-net@freebsd.org
Message-ID: <20080402153308.GA66807@rebelion.Sisis.de>
References: <20080326124324.GA1756@rebelion.Sisis.de>
<47EAB19E.8010804@FreeBSD.org>
<20080331101250.GA3094@rebelion.Sisis.de>
<47F0BF52.1010109@FreeBSD.org>
<20080331130404.GB1615@rebelion.Sisis.de>
<20080401075221.GA2138@rebelion.Sisis.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20080401075221.GA2138@rebelion.Sisis.de>
User-Agent: Mutt/1.4.2.3i
X-Operating-System: FreeBSD 7.0-RELEASE (i386)
X-OriginalArrivalTime: 02 Apr 2008 15:36:00.0315 (UTC)
FILETIME=[409FC0B0:01C894D7]
Cc: Sam Leffler <sam@freebsd.org>
Subject: Re: 7.0-RELEASE && panic after ~4 hours
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Matthias Apitz <matthias.apitz@oclc.org>
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, 02 Apr 2008 15:33:20 -0000
El dÃa Tuesday, April 01, 2008 a las 09:52:21AM +0200, Matthias Apitz escribió:
> El dÃa Monday, March 31, 2008 a las 03:04:04PM +0200, Matthias Apitz escribió:
>
> > > You should unmount (or boot to single-user mode) and run a full fsck
> > > (fsck -fy).
> >
> > Thanks for your hint and I've done what you have advised and I'm
> > connected through Wifi again now (until next panic :-))
> > The fsck has indeed correct something where the block count should have
> > been zero but was some decimal number of 20 digits, I think (don't
> > remember that large number);
> >
> > I'll copy this e-mail into the TT;
>
> While the laptop worked all night at home (and only with clean shutdows
> since the last 'fsck -fy' yesterday afternoon), it crashed after around
> 20 minutes in my office this morning; the kgdb says:
...
just a short note: this morning I have switched off 'bgscan' with
# ifconfig iwi0 -bgscan
and the uptime here in my office's Wifi with WPA is already
$ uptime
5:32PM up 8:35, 11 users, load averages: 0,00 0,02 0,01
matthias
--
Matthias Apitz
Manager Technical Support - OCLC GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <matthias.apitz@oclc.org> - w http://www.oclc.org/ http://www.UnixArea.de/
b http://gurucubano.blogspot.com/
Don't top-post, read RFC1855 http://www.faqs.org/rfcs/rfc1855.html
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on Usenet and in e-mail?
From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 16:11:18 2008
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 80CAD1065676
for <freebsd-net@freebsd.org>; Wed, 2 Apr 2008 16:11:18 +0000 (UTC)
(envelope-from bms@incunabulum.net)
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com
[66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 54EA08FC29
for <freebsd-net@freebsd.org>; Wed, 2 Apr 2008 16:11:18 +0000 (UTC)
(envelope-from bms@incunabulum.net)
Received: from compute1.internal (compute1.internal [10.202.2.41])
by out1.messagingengine.com (Postfix) with ESMTP id 9BF51E47D7
for <freebsd-net@freebsd.org>; Wed, 2 Apr 2008 12:11:17 -0400 (EDT)
Received: from heartbeat1.messagingengine.com ([10.202.2.160])
by compute1.internal (MEProxy); Wed, 02 Apr 2008 12:11:17 -0400
X-Sasl-enc: UAJuE1+nbC+LknF3FAiuYekzOjK9nG60bg4uX5i2k8DC 1207152676
Received: from empiric.lon.incunabulum.net
(82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254])
by mail.messagingengine.com (Postfix) with ESMTPSA id C47C214121
for <freebsd-net@freebsd.org>; Wed, 2 Apr 2008 12:11:16 -0400 (EDT)
Message-ID: <47F3B023.60108@incunabulum.net>
Date: Wed, 02 Apr 2008 17:11:15 +0100
From: Bruce M Simpson <bms@incunabulum.net>
User-Agent: Thunderbird 2.0.0.9 (X11/20080207)
MIME-Version: 1.0
To: FreeBSD-Net mailing list <freebsd-net@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: fxp(4) multicast transmission bug.
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, 02 Apr 2008 16:11:18 -0000
Hi,
I am doing some protocol testing, and I just saw something very odd on
6.3-RELEASE.
If I try to inject multicast traffic via bpf with fxp, bpf will report
that it went out OK, however it never makes it out onto the wire. I have
ruled out firewalls, switches and other layer 2 behaviour.
sysctls look like this:
dev.fxp.0.int_delay: 1000
dev.fxp.0.bundle_max: 6
dev.fxp.0.rnr: 0
dev.fxp.0.noflow: 1
driver flags look like this when injection is OK:
fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu
1500
driver flags look like this when injection is NOT OK:
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
... however, if for any reason the group I'm sending to has been joined
by another process or kernel entity, sending is OK.
My understanding of multicast hash filters was that they worked in only
one direction -- receive, not send.
However, I see from reading the driver that the fxp chip has certain
restrictions on how the hash filter is programmed -- the command to do
so must come before any other descriptors are queued.
That's all well and good, but sending should "just work". Further
reading of the driver suggests that it does nothing special about
multicast transmission, so that would seem to point the finger at the
driver firmware or the ASIC itself.
If fxp is behaving differently to 99% of hardware out there, surely this
needs to be marked in capabilities -- I shouldn't strictly need to
program the hash filter to send the traffic, only receive. Whilst it's
something an application is *likely* to do, it doesn't have to do so by
spec, therefore this behaviour is a bug.
Or is there something I'm missing completely here?
Comments? feedback? suggestions?
cheers
BMS
From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 01:11:28 2008
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 0FFA11065670
for <freebsd-net@freebsd.org>; Thu, 3 Apr 2008 01:11:28 +0000 (UTC)
(envelope-from pyunyh@gmail.com)
Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.244])
by mx1.freebsd.org (Postfix) with ESMTP id AFE738FC18
for <freebsd-net@freebsd.org>; Thu, 3 Apr 2008 01:11:27 +0000 (UTC)
(envelope-from pyunyh@gmail.com)
Received: by hs-out-0708.google.com with SMTP id m63so2472151hsc.11
for <freebsd-net@freebsd.org>; Wed, 02 Apr 2008 18:11:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent;
bh=dMhGxRn+0smTf0/s+0UUaS6wNSZkr8TjHTZQd9E4KsI=;
b=kDofoyEQwHKZ6GwBVQrwSqFrKLZEDqiyGqri/MCbWpnDyblkmVB7HMMLh4j0JlBgRBau/k5A+Aw6ZBkSR1DTPU5iioIaw6hvg9p4UQ+AgU2GPzJkiNoNtAda0Y0IhjST712w66vOLMF98AsSF+Cth9SgVCXyIYTgpo+oM6xk5Y0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent;
b=F8J3tvdDgLM50kngsKYrjk37RpfkLC3Yve8dqAtM+lWQF04nfJaMvELdiGBSWFflXkIG/pD9/B8bv99K4jUs02pSx6kwFt6DfLc2iCXtUo4UmdY2gYatPPuJyzx0Q0tqqO2U09l02sZqYYSOdSy91Rh9NK+caVQSLMI8xM7nmHQ=
Received: by 10.100.241.17 with SMTP id o17mr24273787anh.30.1207185086554;
Wed, 02 Apr 2008 18:11:26 -0700 (PDT)
Received: from michelle.cdnetworks.co.kr ( [211.53.35.84])
by mx.google.com with ESMTPS id a42sm4604324rne.15.2008.04.02.18.11.24
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 02 Apr 2008 18:11:25 -0700 (PDT)
Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr
[127.0.0.1])
by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id
m331BKj6023077
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Thu, 3 Apr 2008 10:11:20 +0900 (KST) (envelope-from pyunyh@gmail.com)
Received: (from yongari@localhost)
by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m331BIXN023076;
Thu, 3 Apr 2008 10:11:18 +0900 (KST) (envelope-from pyunyh@gmail.com)
Date: Thu, 3 Apr 2008 10:11:18 +0900
From: Pyun YongHyeon <pyunyh@gmail.com>
To: Bruce M Simpson <bms@incunabulum.net>
Message-ID: <20080403011118.GC22730@cdnetworks.co.kr>
References: <47F3B023.60108@incunabulum.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <47F3B023.60108@incunabulum.net>
User-Agent: Mutt/1.4.2.1i
Cc: FreeBSD-Net mailing list <freebsd-net@freebsd.org>
Subject: Re: fxp(4) multicast transmission bug.
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: pyunyh@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: Thu, 03 Apr 2008 01:11:28 -0000
On Wed, Apr 02, 2008 at 05:11:15PM +0100, Bruce M Simpson wrote:
> Hi,
>
> I am doing some protocol testing, and I just saw something very odd on
> 6.3-RELEASE.
>
> If I try to inject multicast traffic via bpf with fxp, bpf will report
> that it went out OK, however it never makes it out onto the wire. I have
> ruled out firewalls, switches and other layer 2 behaviour.
>
> sysctls look like this:
> dev.fxp.0.int_delay: 1000
> dev.fxp.0.bundle_max: 6
> dev.fxp.0.rnr: 0
> dev.fxp.0.noflow: 1
>
> driver flags look like this when injection is OK:
> fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu
> 1500
>
> driver flags look like this when injection is NOT OK:
> fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>
> ... however, if for any reason the group I'm sending to has been joined
> by another process or kernel entity, sending is OK.
>
> My understanding of multicast hash filters was that they worked in only
> one direction -- receive, not send.
>
> However, I see from reading the driver that the fxp chip has certain
> restrictions on how the hash filter is programmed -- the command to do
> so must come before any other descriptors are queued.
>
> That's all well and good, but sending should "just work". Further
> reading of the driver suggests that it does nothing special about
> multicast transmission, so that would seem to point the finger at the
> driver firmware or the ASIC itself.
>
> If fxp is behaving differently to 99% of hardware out there, surely this
> needs to be marked in capabilities -- I shouldn't strictly need to
> program the hash filter to send the traffic, only receive. Whilst it's
> something an application is *likely* to do, it doesn't have to do so by
> spec, therefore this behaviour is a bug.
>
> Or is there something I'm missing completely here?
>
> Comments? feedback? suggestions?
>
Because I'm not familiar with fxp(4) so I'm not sure but I guess
this is a bug in fxp(4). I think fxp(4) should also reprogram
multicast filtering in its fxp_init() as well as ioctl handler.
Otherwise you may have to join process in a group in order to send
multicast packets.
How about adding fxp_mc_setup() in fxp_init? I guess you may also
have to modify fxp_mc_setup() to set a flag that indicates "waiting
for a completion of multicast setup command". Or you may be able to
remove fxp_mc_setup() out of interrupt handler of fxp(4) and make
fxp_mc_setup() as a full-featured multicast filtering function, e.g.
not relying on an interrupt to catch the completion of multicast
setup command.
> cheers
> BMS
--
Regards,
Pyun YongHyeon
From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 10:04:24 2008
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 E0BD5106564A
for <net@freebsd.org>; Thu, 3 Apr 2008 10:04:24 +0000 (UTC)
(envelope-from gnn@neville-neil.com)
Received: from proxy.meer.net (proxy.meer.net [64.13.141.13])
by mx1.freebsd.org (Postfix) with ESMTP id CD37B8FC22
for <net@freebsd.org>; Thu, 3 Apr 2008 10:04:24 +0000 (UTC)
(envelope-from gnn@neville-neil.com)
Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23])
by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m336F48x021146
for <net@freebsd.org>; Wed, 2 Apr 2008 23:15:04 -0700 (PDT)
(envelope-from gnn@neville-neil.com)
Received: from mail.meer.net (mail.meer.net [209.157.152.14])
by outbound0.mx.meer.net (8.12.10/8.12.6) with ESMTP id m3361Qi1037589
for <net@freebsd.org>; Wed, 2 Apr 2008 22:01:58 -0800 (PST)
(envelope-from gnn@neville-neil.com)
Received: from mail2.meer.net (mail2.meer.net [64.13.141.16])
by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m3361Ifu038014
for <net@freebsd.org>; Wed, 2 Apr 2008 23:01:18 -0700 (PDT)
(envelope-from gnn@neville-neil.com)
Received: from minion.local.neville-neil.com
(61.204.211.246.customerlink.pwd.ne.jp [61.204.211.246])
(authenticated bits=0)
by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m3361HCL004997
for <net@freebsd.org>; Wed, 2 Apr 2008 23:01:17 -0700 (PDT)
(envelope-from gnn@neville-neil.com)
Date: Thu, 03 Apr 2008 15:01:15 +0900
Message-ID: <m2abkb8ok4.wl%gnn@neville-neil.com>
From: gnn@freebsd.org
To: net@freebsd.org
User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka)
FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1.50
(i386-apple-darwin8.11.1) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-Bayes-Prob: 0.5 (Score 0)
X-Spam-Score: 0.70 () [Tag at 5.00] COMBINED_FROM,NO_REAL_NAME
X-CanItPRO-Stream: default
X-Canit-Stats-ID: 88952 - 4a0053035148
X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13
Cc:
Subject: A new tool to measure multicast performance...
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, 03 Apr 2008 10:04:25 -0000
Howdy,
I have just finished updating a new tool in src/tools/tools/mctest
which is a multicast test program. The mctest program works by
sending packets from a source to a sink over using a multicast address
and then the sink reflects the packets it receives back to the
source. The source records the transmission and reception time of
each packet and reports the round trip time, which the sink prints out
the time between packets, in microseconds. The program is best used
to debug ethernet drivers as well as our multicast and UDP code.
For more information please read the manual page.
Sorry, IPv6 is not supported as yet, only IPv4.
Best,
George
From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 22:37:10 2008
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 7F3D61065670;
Thu, 3 Apr 2008 22:37:10 +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 4D5B78FC14;
Thu, 3 Apr 2008 22:37:10 +0000 (UTC)
(envelope-from linimon@FreeBSD.org)
Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1])
by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m33MbAKA045291;
Thu, 3 Apr 2008 22:37:10 GMT
(envelope-from linimon@freefall.freebsd.org)
Received: (from linimon@localhost)
by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m33MbADA045287;
Thu, 3 Apr 2008 22:37:10 GMT (envelope-from linimon)
Date: Thu, 3 Apr 2008 22:37:10 GMT
Message-Id: <200804032237.m33MbADA045287@freefall.freebsd.org>
To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org
From: linimon@FreeBSD.org
Cc:
Subject: Re: kern/122427: [apm] [panic] apm and mDNSResponder cause panic
during shutdown (multicast)
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, 03 Apr 2008 22:37:10 -0000
Old Synopsis: apm and mDNSResponder cause panic during shutdown (multicast)
New Synopsis: [apm] [panic] apm and mDNSResponder cause panic during shutdown (multicast)
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Apr 3 22:36:48 UTC 2008
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=122427
From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 23:34:36 2008
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 94A56106566C
for <freebsd-net@freebsd.org>; Thu, 3 Apr 2008 23:34:36 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
by mx1.freebsd.org (Postfix) with ESMTP id ECDB18FC13
for <freebsd-net@freebsd.org>; Thu, 3 Apr 2008 23:34:35 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1JhYwt-0001AG-17
for freebsd-net@freebsd.org; Thu, 03 Apr 2008 23:34:27 +0000
Received: from 78-0-69-170.adsl.net.t-com.hr ([78.0.69.170])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Thu, 03 Apr 2008 23:34:27 +0000
Received: from ivoras by 78-0-69-170.adsl.net.t-com.hr with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Thu, 03 Apr 2008 23:34:27 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-net@freebsd.org
From: Ivan Voras <ivoras@freebsd.org>
Date: Fri, 04 Apr 2008 01:34:07 +0200
Lines: 262
Message-ID: <ft3phn$ai3$1@ger.gmane.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig1FB290221A96A9CD76AF169F"
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 78-0-69-170.adsl.net.t-com.hr
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
X-Enigmail-Version: 0.95.6
Sender: news <news@ger.gmane.org>
Subject: Trouble with IPFW or TCP?
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, 03 Apr 2008 23:34:36 -0000
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1FB290221A96A9CD76AF169F
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
In which case would an ipfw ruleset like this:
00100 114872026 40487887607 allow ip from any to any via lo0
00200 0 0 deny ip from any to 127.0.0.0/8
00300 0 0 deny ip from 127.0.0.0/8 to any
00600 1585 112576 deny ip from table(0) to me
01000 90279 7325972 allow icmp from any to any
05000 475961039 334422494257 allow tcp from me to any setup keep-state
05100 634155 65779377 allow udp from me to any keep-state
06022 409604 69177326 allow tcp from any to me dst-port 22 setup=20
keep-state
06080 52159025 43182548092 allow tcp from any to me dst-port 80 setup=20
keep-state
06443 6392366 2043532158 allow tcp from any to me dst-port 443 setup =
keep-state
07020 517065 292377553 allow tcp from any to me dst-port 8080=20
setup keep-state
65400 12273387 629703212 deny log ip from any to any
65535 0 0 deny ip from any to any
Generate syslog messages like these:
Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:60725=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:57387=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:57387=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:61998=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:61998=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:64288=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:64288=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:50212=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:50212=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:58149=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:58149=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:13 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:61919=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:13 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:61919=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:13 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:56792=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:13 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:56792=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:14 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:53795=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58314=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:63204=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58314=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:52125=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:53386=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:63626=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:63204=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:51376=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:61880=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:49319=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:52125=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:62381=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:53386=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:63626=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:51376=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:54109=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:56945=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:61880=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:50800=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:49319=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:53347=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58735=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58732=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:62381=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:56837=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:54109=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:65318=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:56945=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:50800=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:53347=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58735=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58732=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:56837=20
my.ip.my.ip:443 in via em0
Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:65318=20
my.ip.my.ip:443 in via em0
?
I can connect with plain telnet from the reported addresses without=20
problems. One thing that is suspicious is that the messages come in=20
these bursts (which I can't explain) but the Apache's listen backlog=20
should handle those. In any case, I don't think they are connection=20
requests:
Here's output of "tcpdump -v host xx.xx.xx.xx and port 443":
01:13:07.654677 IP (tos 0x0, ttl 58, id 54089, offset 0, flags [none],=20
proto TCP (6), length 40) xx.xx.xx.xx.58789 > my.ip.my.ip.https: .,=20
cksum 0x54ca (correct), ack 3708282724 win 0
01:13:07.654764 IP (tos 0x0, ttl 58, id 54095, offset 0, flags [none],=20
proto TCP (6), length 40) xx.xx.xx.xx.61579 > my.ip.my.ip.https: .,=20
cksum 0xf60d (correct), ack 610863831 win 0
01:13:07.654810 IP (tos 0x0, ttl 58, id 54099, offset 0, flags [none],=20
proto TCP (6), length 40) xx.xx.xx.xx.61852 > my.ip.my.ip.https: .,=20
cksum 0xab18 (correct), ack 1491048554 win 0
01:13:07.654854 IP (tos 0x0, ttl 58, id 54103, offset 0, flags [none],=20
proto TCP (6), length 40) xx.xx.xx.xx.63950 > my.ip.my.ip.https: .,=20
cksum 0x1e51 (correct), ack 2955921131 win 0
01:13:07.654897 IP (tos 0x0, ttl 58, id 54107, offset 0, flags [none],=20
proto TCP (6), length 40) xx.xx.xx.xx.53299 > my.ip.my.ip.https: .,=20
cksum 0xa141 (correct), ack 2339864417 win 0
01:13:07.654940 IP (tos 0x0, ttl 58, id 54121, offset 0, flags [none],=20
proto TCP (6), length 40) xx.xx.xx.xx.50521 > my.ip.my.ip.https: .,=20
cksum 0x2c55 (correct), ack 216576745 win 0
01:13:07.654984 IP (tos 0x0, ttl 58, id 54123, offset 0, flags [DF],=20
proto TCP (6), length 52) xx.xx.xx.xx.58789 > my.ip.my.ip.https: .,=20
cksum 0x882d (correct), ack 1 win 33304 <nop,nop,timestamp 140692997=20
4077078528>
01:13:07.655026 IP (tos 0x0, ttl 58, id 54126, offset 0, flags [DF],=20
proto TCP (6), length 52) xx.xx.xx.xx.61579 > my.ip.my.ip.https: .,=20
cksum 0x0617 (correct), ack 1 win 33304 <nop,nop,timestamp 140692997=20
3172245833>
01:13:07.655069 IP (tos 0x0, ttl 58, id 54128, offset 0, flags [DF],=20
proto TCP (6), length 52) xx.xx.xx.xx.61852 > my.ip.my.ip.https: .,=20
cksum 0x7006 (correct), ack 1 win 33304 <nop,nop,timestamp 140692997=20
3472415360>
01:13:07.655112 IP (tos 0x0, ttl 58, id 54130, offset 0, flags [DF],=20
proto TCP (6), length 52) xx.xx.xx.xx.63950 > my.ip.my.ip.https: .,=20
cksum 0x7ade (correct), ack 1 win 33304 <nop,nop,timestamp 140692997=20
415365400>
01:13:07.655155 IP (tos 0x0, ttl 58, id 54132, offset 0, flags [DF],=20
proto TCP (6), length 52) xx.xx.xx.xx.53299 > my.ip.my.ip.https: .,=20
cksum 0x4087 (correct), ack 1 win 33304 <nop,nop,timestamp 140692997=20
2999393370>
01:13:07.655197 IP (tos 0x0, ttl 58, id 54139, offset 0, flags [DF],=20
proto TCP (6), length 52) xx.xx.xx.xx.50521 > my.ip.my.ip.https: .,=20
cksum 0x13e0 (correct), ack 1 win 33304 <nop,nop,timestamp 140692997=20
3427580559>
There are no SYNs here, so it looks to me like something mid-traffic.
For addresses such as those in the ipfw log, I see several messages like:=
Mar 24 17:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:64714 to=20
[my.ip.my.ip]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2:=20
Received 198 bytes of data after socket was closed, sending RST and=20
removing tcpcb
Mar 24 17:10:57 my.ip kernel: 6110>ipfw: 65400 Deny TCP=20
xx.xx.xx.xx:58213 my.ip.my.ip:443 in via em0
Mar 25 00:00:05 my.ip kernel: TCP: [xx.xx.xx.xx]:52233 to=20
[my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed=20
SYNCOOKIE authentication, segment rejected (probably spoofed)
Mar 25 01:45:05 my.ip kernel: TCP: [xx.xx.xx.xx]:51120 to=20
[my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed=20
SYNCOOKIE authentication, segment rejected (probably spoofed)
Mar 25 01:45:05 my.ip kernel: TCP: [xx.xx.xx.xx]:51120 to=20
[my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed=20
SYNCOOKIE authentication, segment rejected (probably spoofed)
Mar 25 14:00:09 my.ip kernel: TCP: [xx.xx.xx.xx]:55665 to=20
[my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed=20
SYNCOOKIE authentication, segment rejected (probably spoofed)
Mar 25 14:00:09 my.ip kernel: TCP: [xx.xx.xx.xx]:55665 to=20
[my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed=20
SYNCOOKIE authentication, segment rejected (probably spoofed)
Mar 25 17:00:00 my.ip kernel: TCP: [xx.xx.xx.xx]:60048 to=20
[my.ip.my.ip]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1:=20
Received 346 bytes of data after socket was closed, sending RST and=20
removing tcpcb
Mar 25 17:00:00 my.ip kernel: TCP: [xx.xx.xx.xx]:60048 to=20
[my.ip.my.ip]:443 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment=20
failed SYNCOOKIE authentication, segment rejected (probably spoofed)
Mar 25 23:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:50205 to=20
[my.ip.my.ip]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1:=20
Received 346 bytes of data after socket was closed, sending RST and=20
removing tcpcb
Mar 25 23:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:50205 to=20
[my.ip.my.ip]:443 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment=20
failed SYNCOOKIE authentication, segment rejected (probably spoofed)
Mar 26 00:38:49 my.ip kernel: <a10>ipfw: 65400 Deny TCP=20
xx.xx.xx.xx:61129 my.ip.my.ip:443 in via em0
Apr 2 09:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:57248 to=20
[my.ip.my.ip]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1:=20
Received 330 bytes of data after socket was closed, sending RST and=20
removing tcpcb
Apr 2 09:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:57248 to=20
[my.ip.my.ip]:443 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment=20
failed SYNCOOKIE authentication, segment rejected (probably spoofed)
But these messages do *not* occur when the ipfw log and tcpdump record=20
the above described behaviour so it might not be connected.
The machine at my.ip is running 7.0-RELEASE i386, the rest are a set of=20
machines that send trivial periodic (every 15 minutes) HTTPS messages to =
this machine.
In this set most are 6.2 or 6.3, mixed i386 and amd64. The one 7-STABLE=20
machine that does the same thing doesn't generate the behaviour=20
described above so it might be something specific to when 6.x machines=20
talk to 7.x. Was there a bug like that in 6.x?
--------------enig1FB290221A96A9CD76AF169F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH9Wl1ldnAQVacBcgRAnwfAJ9jkCiQbHFCari7u2iR/FseGAlbeQCfSF7y
RpnNQrpzFeYeXTGhcg6UBGg=
=WLHk
-----END PGP SIGNATURE-----
--------------enig1FB290221A96A9CD76AF169F--
From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 23:41:04 2008
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 92075106566C
for <freebsd-net@freebsd.org>; Thu, 3 Apr 2008 23:41:04 +0000 (UTC)
(envelope-from erikt@midgard.homeip.net)
Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net
[80.76.149.213])
by mx1.freebsd.org (Postfix) with ESMTP id 38DF08FC1A
for <freebsd-net@freebsd.org>; Thu, 3 Apr 2008 23:41:04 +0000 (UTC)
(envelope-from erikt@midgard.homeip.net)
Received: from c83-253-25-183.bredband.comhem.se ([83.253.25.183]:62423
helo=falcon.midgard.homeip.net)
by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68)
(envelope-from <erikt@midgard.homeip.net>) id 1JhZ3H-0003FT-7A
for freebsd-net@freebsd.org; Fri, 04 Apr 2008 01:41:03 +0200
Received: (qmail 87566 invoked from network); 4 Apr 2008 01:40:59 +0200
Received: from owl.midgard.homeip.net (10.1.5.7)
by falcon.midgard.homeip.net with ESMTP; 4 Apr 2008 01:40:59 +0200
Received: (qmail 53449 invoked by uid 1001); 4 Apr 2008 01:40:59 +0200
Date: Fri, 4 Apr 2008 01:40:59 +0200
From: Erik Trulsson <ertr1013@student.uu.se>
To: Ivan Voras <ivoras@freebsd.org>
Message-ID: <20080403234059.GA53417@owl.midgard.homeip.net>
Mail-Followup-To: Ivan Voras <ivoras@freebsd.org>, freebsd-net@freebsd.org
References: <ft3phn$ai3$1@ger.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ft3phn$ai3$1@ger.gmane.org>
User-Agent: Mutt/1.5.17 (2007-11-01)
X-Originating-IP: 83.253.25.183
X-Scan-Result: No virus found in message 1JhZ3H-0003FT-7A.
X-Scan-Signature: ch-smtp02.sth.basefarm.net 1JhZ3H-0003FT-7A
8b7a739b805a5ab5cf0a9c13a259232e
Cc: freebsd-net@freebsd.org
Subject: Re: Trouble with IPFW or TCP?
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, 03 Apr 2008 23:41:04 -0000
On Fri, Apr 04, 2008 at 01:34:07AM +0200, Ivan Voras wrote:
> In which case would an ipfw ruleset like this:
>
> 00100 114872026 40487887607 allow ip from any to any via lo0
> 00200 0 0 deny ip from any to 127.0.0.0/8
> 00300 0 0 deny ip from 127.0.0.0/8 to any
> 00600 1585 112576 deny ip from table(0) to me
> 01000 90279 7325972 allow icmp from any to any
> 05000 475961039 334422494257 allow tcp from me to any setup keep-state
> 05100 634155 65779377 allow udp from me to any keep-state
> 06022 409604 69177326 allow tcp from any to me dst-port 22 setup
> keep-state
> 06080 52159025 43182548092 allow tcp from any to me dst-port 80 setup
> keep-state
> 06443 6392366 2043532158 allow tcp from any to me dst-port 443 setup
> keep-state
> 07020 517065 292377553 allow tcp from any to me dst-port 8080 setup
> keep-state
> 65400 12273387 629703212 deny log ip from any to any
> 65535 0 0 deny ip from any to any
If you are using 'keep-state' should there not also be some rule containing
'check-state' ?
>
> Generate syslog messages like these:
>
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:60725
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:57387
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:57387
[snip]
--
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 23:52:34 2008
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 1C66E1065671
for <freebsd-net@freebsd.org>; Thu, 3 Apr 2008 23:52:34 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
by mx1.freebsd.org (Postfix) with ESMTP id 892CF8FC1C
for <freebsd-net@freebsd.org>; Thu, 3 Apr 2008 23:52:33 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1JhZEK-0001rc-G3
for freebsd-net@freebsd.org; Thu, 03 Apr 2008 23:52:28 +0000
Received: from 78-0-69-170.adsl.net.t-com.hr ([78.0.69.170])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Thu, 03 Apr 2008 23:52:28 +0000
Received: from ivoras by 78-0-69-170.adsl.net.t-com.hr with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Thu, 03 Apr 2008 23:52:28 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-net@freebsd.org
From: Ivan Voras <ivoras@freebsd.org>
Date: Fri, 04 Apr 2008 01:52:17 +0200
Lines: 73
Message-ID: <ft3qji$cr9$1@ger.gmane.org>
References: <ft3phn$ai3$1@ger.gmane.org>
<20080403234059.GA53417@owl.midgard.homeip.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigF880E0CA1C628C10ADC94C29"
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 78-0-69-170.adsl.net.t-com.hr
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
In-Reply-To: <20080403234059.GA53417@owl.midgard.homeip.net>
X-Enigmail-Version: 0.95.6
Sender: news <news@ger.gmane.org>
Subject: Re: Trouble with IPFW or TCP?
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, 03 Apr 2008 23:52:34 -0000
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF880E0CA1C628C10ADC94C29
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Erik Trulsson wrote:
> On Fri, Apr 04, 2008 at 01:34:07AM +0200, Ivan Voras wrote:
>> In which case would an ipfw ruleset like this:
>>
>> 00100 114872026 40487887607 allow ip from any to any via lo0
>> 00200 0 0 deny ip from any to 127.0.0.0/8
>> 00300 0 0 deny ip from 127.0.0.0/8 to any
>> 00600 1585 112576 deny ip from table(0) to me
>> 01000 90279 7325972 allow icmp from any to any
>> 05000 475961039 334422494257 allow tcp from me to any setup keep-state=
>> 05100 634155 65779377 allow udp from me to any keep-state
>> 06022 409604 69177326 allow tcp from any to me dst-port 22 setu=
p=20
>> keep-state
>> 06080 52159025 43182548092 allow tcp from any to me dst-port 80 setu=
p=20
>> keep-state
>> 06443 6392366 2043532158 allow tcp from any to me dst-port 443 set=
up=20
>> keep-state
>> 07020 517065 292377553 allow tcp from any to me dst-port 8080 se=
tup=20
>> keep-state
>> 65400 12273387 629703212 deny log ip from any to any
>> 65535 0 0 deny ip from any to any
>=20
> If you are using 'keep-state' should there not also be some rule contai=
ning
> 'check-state' ?
Not according to the ipfw(8) manual:
"""
These dynamic rules, which have a limited lifetime, are checked at =
the
first occurrence of a check-state, keep-state or limit rule, and=20
are typ-
ically used to open the firewall on-demand to legitimate traffic on=
ly.
See the STATEFUL FIREWALL and EXAMPLES Sections below for more=20
informa-
tion on the stateful behaviour of ipfw.
"""
I read this to mean the dynamic rules are checked at rule #5000 from the =
above list. Is there an advantage to having an explicit check-state rule =
in simple rulesets like this one?
--------------enigF880E0CA1C628C10ADC94C29
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH9W2xldnAQVacBcgRAjBJAKDabcurfBDVJOTfpscs4EDJ81r5VgCfc8LD
jC+ufoPOHjpxuExmy7syXjE=
=X4TR
-----END PGP SIGNATURE-----
--------------enigF880E0CA1C628C10ADC94C29--
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 00:20:09 2008
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 7431F1065673
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 00:20:09 +0000 (UTC)
(envelope-from julian@elischer.org)
Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net
[216.240.47.249])
by mx1.freebsd.org (Postfix) with ESMTP id 492F58FC26
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 00:20:09 +0000 (UTC)
(envelope-from julian@elischer.org)
Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160)
by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP;
Thu, 03 Apr 2008 17:28:41 -0700
Received: from julian-mac.elischer.org (localhost [127.0.0.1])
by idiom.com (Postfix) with ESMTP id 515472D6B3B;
Thu, 3 Apr 2008 17:20:06 -0700 (PDT)
Message-ID: <47F57437.6040400@elischer.org>
Date: Thu, 03 Apr 2008 17:20:07 -0700
From: Julian Elischer <julian@elischer.org>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Ivan Voras <ivoras@freebsd.org>
References: <ft3phn$ai3$1@ger.gmane.org>
In-Reply-To: <ft3phn$ai3$1@ger.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org
Subject: Re: Trouble with IPFW or TCP?
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, 04 Apr 2008 00:20:09 -0000
Ivan Voras wrote:
> In which case would an ipfw ruleset like this:
>
> 00100 114872026 40487887607 allow ip from any to any via lo0
> 00200 0 0 deny ip from any to 127.0.0.0/8
> 00300 0 0 deny ip from 127.0.0.0/8 to any
> 00600 1585 112576 deny ip from table(0) to me
ipfw add 700 check-state
> 01000 90279 7325972 allow icmp from any to any
> 05000 475961039 334422494257 allow tcp from me to any setup keep-state
> 05100 634155 65779377 allow udp from me to any keep-state
> 06022 409604 69177326 allow tcp from any to me dst-port 22 setup
> keep-state
> 06080 52159025 43182548092 allow tcp from any to me dst-port 80 setup
> keep-state
> 06443 6392366 2043532158 allow tcp from any to me dst-port 443 setup
> keep-state
> 07020 517065 292377553 allow tcp from any to me dst-port 8080
> setup keep-state
> 65400 12273387 629703212 deny log ip from any to any
> 65535 0 0 deny ip from any to any
lots of keep-state rules but nothing to check the state
>
> Generate syslog messages like these:
>
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:60725
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:57387
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:57387
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:61998
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:61998
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:64288
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:64288
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:50212
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:50212
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:58149
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:58149
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:13 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:61919
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:13 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:61919
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:13 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:56792
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:13 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:56792
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:14 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:53795
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58314
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:63204
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58314
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:52125
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:53386
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:63626
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:63204
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:51376
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:61880
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:49319
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:52125
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:62381
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:53386
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:63626
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:51376
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:54109
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:56945
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:61880
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:50800
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:49319
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:53347
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58735
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58732
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:62381
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:56837
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:54109
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:65318
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:56945
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:50800
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:53347
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58735
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58732
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:56837
> my.ip.my.ip:443 in via em0
> Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:65318
> my.ip.my.ip:443 in via em0
>
> ?
>
> I can connect with plain telnet from the reported addresses without
> problems. One thing that is suspicious is that the messages come in
> these bursts (which I can't explain) but the Apache's listen backlog
> should handle those. In any case, I don't think they are connection
> requests:
>
> Here's output of "tcpdump -v host xx.xx.xx.xx and port 443":
>
> 01:13:07.654677 IP (tos 0x0, ttl 58, id 54089, offset 0, flags [none],
> proto TCP (6), length 40) xx.xx.xx.xx.58789 > my.ip.my.ip.https: .,
> cksum 0x54ca (correct), ack 3708282724 win 0
> 01:13:07.654764 IP (tos 0x0, ttl 58, id 54095, offset 0, flags [none],
> proto TCP (6), length 40) xx.xx.xx.xx.61579 > my.ip.my.ip.https: .,
> cksum 0xf60d (correct), ack 610863831 win 0
> 01:13:07.654810 IP (tos 0x0, ttl 58, id 54099, offset 0, flags [none],
> proto TCP (6), length 40) xx.xx.xx.xx.61852 > my.ip.my.ip.https: .,
> cksum 0xab18 (correct), ack 1491048554 win 0
> 01:13:07.654854 IP (tos 0x0, ttl 58, id 54103, offset 0, flags [none],
> proto TCP (6), length 40) xx.xx.xx.xx.63950 > my.ip.my.ip.https: .,
> cksum 0x1e51 (correct), ack 2955921131 win 0
> 01:13:07.654897 IP (tos 0x0, ttl 58, id 54107, offset 0, flags [none],
> proto TCP (6), length 40) xx.xx.xx.xx.53299 > my.ip.my.ip.https: .,
> cksum 0xa141 (correct), ack 2339864417 win 0
> 01:13:07.654940 IP (tos 0x0, ttl 58, id 54121, offset 0, flags [none],
> proto TCP (6), length 40) xx.xx.xx.xx.50521 > my.ip.my.ip.https: .,
> cksum 0x2c55 (correct), ack 216576745 win 0
> 01:13:07.654984 IP (tos 0x0, ttl 58, id 54123, offset 0, flags [DF],
> proto TCP (6), length 52) xx.xx.xx.xx.58789 > my.ip.my.ip.https: .,
> cksum 0x882d (correct), ack 1 win 33304 <nop,nop,timestamp 140692997
> 4077078528>
> 01:13:07.655026 IP (tos 0x0, ttl 58, id 54126, offset 0, flags [DF],
> proto TCP (6), length 52) xx.xx.xx.xx.61579 > my.ip.my.ip.https: .,
> cksum 0x0617 (correct), ack 1 win 33304 <nop,nop,timestamp 140692997
> 3172245833>
> 01:13:07.655069 IP (tos 0x0, ttl 58, id 54128, offset 0, flags [DF],
> proto TCP (6), length 52) xx.xx.xx.xx.61852 > my.ip.my.ip.https: .,
> cksum 0x7006 (correct), ack 1 win 33304 <nop,nop,timestamp 140692997
> 3472415360>
> 01:13:07.655112 IP (tos 0x0, ttl 58, id 54130, offset 0, flags [DF],
> proto TCP (6), length 52) xx.xx.xx.xx.63950 > my.ip.my.ip.https: .,
> cksum 0x7ade (correct), ack 1 win 33304 <nop,nop,timestamp 140692997
> 415365400>
> 01:13:07.655155 IP (tos 0x0, ttl 58, id 54132, offset 0, flags [DF],
> proto TCP (6), length 52) xx.xx.xx.xx.53299 > my.ip.my.ip.https: .,
> cksum 0x4087 (correct), ack 1 win 33304 <nop,nop,timestamp 140692997
> 2999393370>
> 01:13:07.655197 IP (tos 0x0, ttl 58, id 54139, offset 0, flags [DF],
> proto TCP (6), length 52) xx.xx.xx.xx.50521 > my.ip.my.ip.https: .,
> cksum 0x13e0 (correct), ack 1 win 33304 <nop,nop,timestamp 140692997
> 3427580559>
>
> There are no SYNs here, so it looks to me like something mid-traffic.
>
> For addresses such as those in the ipfw log, I see several messages like:
>
> Mar 24 17:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:64714 to
> [my.ip.my.ip]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2:
> Received 198 bytes of data after socket was closed, sending RST and
> removing tcpcb
> Mar 24 17:10:57 my.ip kernel: 6110>ipfw: 65400 Deny TCP
> xx.xx.xx.xx:58213 my.ip.my.ip:443 in via em0
> Mar 25 00:00:05 my.ip kernel: TCP: [xx.xx.xx.xx]:52233 to
> [my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed
> SYNCOOKIE authentication, segment rejected (probably spoofed)
> Mar 25 01:45:05 my.ip kernel: TCP: [xx.xx.xx.xx]:51120 to
> [my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed
> SYNCOOKIE authentication, segment rejected (probably spoofed)
> Mar 25 01:45:05 my.ip kernel: TCP: [xx.xx.xx.xx]:51120 to
> [my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed
> SYNCOOKIE authentication, segment rejected (probably spoofed)
> Mar 25 14:00:09 my.ip kernel: TCP: [xx.xx.xx.xx]:55665 to
> [my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed
> SYNCOOKIE authentication, segment rejected (probably spoofed)
> Mar 25 14:00:09 my.ip kernel: TCP: [xx.xx.xx.xx]:55665 to
> [my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed
> SYNCOOKIE authentication, segment rejected (probably spoofed)
> Mar 25 17:00:00 my.ip kernel: TCP: [xx.xx.xx.xx]:60048 to
> [my.ip.my.ip]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1:
> Received 346 bytes of data after socket was closed, sending RST and
> removing tcpcb
> Mar 25 17:00:00 my.ip kernel: TCP: [xx.xx.xx.xx]:60048 to
> [my.ip.my.ip]:443 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment
> failed SYNCOOKIE authentication, segment rejected (probably spoofed)
> Mar 25 23:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:50205 to
> [my.ip.my.ip]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1:
> Received 346 bytes of data after socket was closed, sending RST and
> removing tcpcb
> Mar 25 23:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:50205 to
> [my.ip.my.ip]:443 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment
> failed SYNCOOKIE authentication, segment rejected (probably spoofed)
> Mar 26 00:38:49 my.ip kernel: <a10>ipfw: 65400 Deny TCP
> xx.xx.xx.xx:61129 my.ip.my.ip:443 in via em0
> Apr 2 09:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:57248 to
> [my.ip.my.ip]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1:
> Received 330 bytes of data after socket was closed, sending RST and
> removing tcpcb
> Apr 2 09:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:57248 to
> [my.ip.my.ip]:443 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment
> failed SYNCOOKIE authentication, segment rejected (probably spoofed)
>
> But these messages do *not* occur when the ipfw log and tcpdump record
> the above described behaviour so it might not be connected.
>
> The machine at my.ip is running 7.0-RELEASE i386, the rest are a set of
> machines that send trivial periodic (every 15 minutes) HTTPS messages to
> this machine.
>
> In this set most are 6.2 or 6.3, mixed i386 and amd64. The one 7-STABLE
> machine that does the same thing doesn't generate the behaviour
> described above so it might be something specific to when 6.x machines
> talk to 7.x. Was there a bug like that in 6.x?
>
>
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 00:21:36 2008
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 71FED1065673
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 00:21:36 +0000 (UTC)
(envelope-from julian@elischer.org)
Received: from outO.internet-mail-service.net (outo.internet-mail-service.net
[216.240.47.238])
by mx1.freebsd.org (Postfix) with ESMTP id 4A8528FC20
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 00:21:36 +0000 (UTC)
(envelope-from julian@elischer.org)
Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160)
by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP;
Thu, 03 Apr 2008 17:30:09 -0700
Received: from julian-mac.elischer.org (localhost [127.0.0.1])
by idiom.com (Postfix) with ESMTP id 9D80D2D6088;
Thu, 3 Apr 2008 17:21:33 -0700 (PDT)
Message-ID: <47F5748F.9050207@elischer.org>
Date: Thu, 03 Apr 2008 17:21:35 -0700
From: Julian Elischer <julian@elischer.org>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Ivan Voras <ivoras@freebsd.org>
References: <ft3phn$ai3$1@ger.gmane.org> <20080403234059.GA53417@owl.midgard.homeip.net>
<ft3qji$cr9$1@ger.gmane.org>
In-Reply-To: <ft3qji$cr9$1@ger.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org
Subject: Re: Trouble with IPFW or TCP?
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, 04 Apr 2008 00:21:36 -0000
Ivan Voras wrote:
> Erik Trulsson wrote:
>> On Fri, Apr 04, 2008 at 01:34:07AM +0200, Ivan Voras wrote:
>>> In which case would an ipfw ruleset like this:
>>>
>>> 00100 114872026 40487887607 allow ip from any to any via lo0
>>> 00200 0 0 deny ip from any to 127.0.0.0/8
>>> 00300 0 0 deny ip from 127.0.0.0/8 to any
>>> 00600 1585 112576 deny ip from table(0) to me
>>> 01000 90279 7325972 allow icmp from any to any
>>> 05000 475961039 334422494257 allow tcp from me to any setup keep-state
>>> 05100 634155 65779377 allow udp from me to any keep-state
>>> 06022 409604 69177326 allow tcp from any to me dst-port 22
>>> setup keep-state
>>> 06080 52159025 43182548092 allow tcp from any to me dst-port 80
>>> setup keep-state
>>> 06443 6392366 2043532158 allow tcp from any to me dst-port 443
>>> setup keep-state
>>> 07020 517065 292377553 allow tcp from any to me dst-port 8080
>>> setup keep-state
>>> 65400 12273387 629703212 deny log ip from any to any
>>> 65535 0 0 deny ip from any to any
>>
>> If you are using 'keep-state' should there not also be some rule
>> containing
>> 'check-state' ?
>
> Not according to the ipfw(8) manual:
>
> """
> These dynamic rules, which have a limited lifetime, are checked at the
> first occurrence of a check-state, keep-state or limit rule, and
> are typ-
> ically used to open the firewall on-demand to legitimate traffic only.
> See the STATEFUL FIREWALL and EXAMPLES Sections below for more
> informa-
> tion on the stateful behaviour of ipfw.
> """
>
> I read this to mean the dynamic rules are checked at rule #5000 from the
> above list. Is there an advantage to having an explicit check-state rule
> in simple rulesets like this one?
the docs are wrong then I think.
>
>
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 03:12:08 2008
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 3D45E1065670
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 03:12:08 +0000 (UTC)
(envelope-from smithi@nimnet.asn.au)
Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143])
by mx1.freebsd.org (Postfix) with ESMTP id 515908FC16
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 03:12:05 +0000 (UTC)
(envelope-from smithi@nimnet.asn.au)
Received: from localhost (smithi@localhost)
by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id NAA22083;
Fri, 4 Apr 2008 13:11:59 +1000 (EST)
(envelope-from smithi@nimnet.asn.au)
Date: Fri, 4 Apr 2008 13:11:58 +1000 (EST)
From: Ian Smith <smithi@nimnet.asn.au>
To: Julian Elischer <julian@elischer.org>
In-Reply-To: <47F5748F.9050207@elischer.org>
Message-ID: <Pine.BSF.3.96.1080404123439.19138A-100000@gaia.nimnet.asn.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: freebsd-net@freebsd.org, Ivan Voras <ivoras@freebsd.org>
Subject: Re: Trouble with IPFW or TCP?
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, 04 Apr 2008 03:12:08 -0000
On Thu, 3 Apr 2008, Julian Elischer wrote:
> Ivan Voras wrote:
> > Erik Trulsson wrote:
> >> On Fri, Apr 04, 2008 at 01:34:07AM +0200, Ivan Voras wrote:
> >>> In which case would an ipfw ruleset like this:
> >>>
> >>> 00100 114872026 40487887607 allow ip from any to any via lo0
> >>> 00200 0 0 deny ip from any to 127.0.0.0/8
> >>> 00300 0 0 deny ip from 127.0.0.0/8 to any
> >>> 00600 1585 112576 deny ip from table(0) to me
> >>> 01000 90279 7325972 allow icmp from any to any
> >>> 05000 475961039 334422494257 allow tcp from me to any setup keep-state
> >>> 05100 634155 65779377 allow udp from me to any keep-state
> >>> 06022 409604 69177326 allow tcp from any to me dst-port 22
> >>> setup keep-state
> >>> 06080 52159025 43182548092 allow tcp from any to me dst-port 80
> >>> setup keep-state
> >>> 06443 6392366 2043532158 allow tcp from any to me dst-port 443
> >>> setup keep-state
> >>> 07020 517065 292377553 allow tcp from any to me dst-port 8080
> >>> setup keep-state
> >>> 65400 12273387 629703212 deny log ip from any to any
> >>> 65535 0 0 deny ip from any to any
> >>
> >> If you are using 'keep-state' should there not also be some rule
> >> containing
> >> 'check-state' ?
> >
> > Not according to the ipfw(8) manual:
> >
> > """
> > These dynamic rules, which have a limited lifetime, are checked at the
> > first occurrence of a check-state, keep-state or limit rule, and
> > are typ-
> > ically used to open the firewall on-demand to legitimate traffic only.
> > See the STATEFUL FIREWALL and EXAMPLES Sections below for more
> > informa-
> > tion on the stateful behaviour of ipfw.
> > """
> >
> > I read this to mean the dynamic rules are checked at rule #5000 from the
> > above list. Is there an advantage to having an explicit check-state rule
> > in simple rulesets like this one?
>
> the docs are wrong then I think.
If so, they've been wrong since 4.something .. certainly before 4.8.
It's hard to imagine nobody else has ever relied on that doc behaviour,
so perhaps the docs, if wrong, have become so at some more recent time?
I guess the simple way to find out is for Ivan to add a check-state
somewhere before the first keep-state, affecting all new connections.
If that doesn't fix the problem, then it looks like the denied packets
really are coming in from non-established sessions, as they would appear
on the surface - if it wasn't known that the sources should be good!
No chance net.inet.ip.fw.dyn_count is hitting net.inet.ip.fw.dyn_max ?
cheers, Ian
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 04:41:35 2008
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 81B4F106566C
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 04:41:35 +0000 (UTC)
(envelope-from julian@elischer.org)
Received: from outX.internet-mail-service.net (outx.internet-mail-service.net
[216.240.47.247])
by mx1.freebsd.org (Postfix) with ESMTP id 625AA8FC1F
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 04:41:35 +0000 (UTC)
(envelope-from julian@elischer.org)
Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160)
by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP;
Thu, 03 Apr 2008 22:05:55 -0700
Received: from julian-mac.elischer.org (localhost [127.0.0.1])
by idiom.com (Postfix) with ESMTP id 302272D6006;
Thu, 3 Apr 2008 21:41:32 -0700 (PDT)
Message-ID: <47F5B17E.5000304@elischer.org>
Date: Thu, 03 Apr 2008 21:41:34 -0700
From: Julian Elischer <julian@elischer.org>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Ian Smith <smithi@nimnet.asn.au>
References: <Pine.BSF.3.96.1080404123439.19138A-100000@gaia.nimnet.asn.au>
In-Reply-To: <Pine.BSF.3.96.1080404123439.19138A-100000@gaia.nimnet.asn.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org, Ivan Voras <ivoras@freebsd.org>
Subject: Re: Trouble with IPFW or TCP?
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, 04 Apr 2008 04:41:35 -0000
Ian Smith wrote:
> On Thu, 3 Apr 2008, Julian Elischer wrote:
> > Ivan Voras wrote:
> > > Erik Trulsson wrote:
> > >> On Fri, Apr 04, 2008 at 01:34:07AM +0200, Ivan Voras wrote:
> > >>> In which case would an ipfw ruleset like this:
> > >>>
> > >>> 00100 114872026 40487887607 allow ip from any to any via lo0
> > >>> 00200 0 0 deny ip from any to 127.0.0.0/8
> > >>> 00300 0 0 deny ip from 127.0.0.0/8 to any
> > >>> 00600 1585 112576 deny ip from table(0) to me
> > >>> 01000 90279 7325972 allow icmp from any to any
> > >>> 05000 475961039 334422494257 allow tcp from me to any setup keep-state
> > >>> 05100 634155 65779377 allow udp from me to any keep-state
> > >>> 06022 409604 69177326 allow tcp from any to me dst-port 22
> > >>> setup keep-state
> > >>> 06080 52159025 43182548092 allow tcp from any to me dst-port 80
> > >>> setup keep-state
> > >>> 06443 6392366 2043532158 allow tcp from any to me dst-port 443
> > >>> setup keep-state
> > >>> 07020 517065 292377553 allow tcp from any to me dst-port 8080
> > >>> setup keep-state
> > >>> 65400 12273387 629703212 deny log ip from any to any
> > >>> 65535 0 0 deny ip from any to any
> > >>
> > >> If you are using 'keep-state' should there not also be some rule
> > >> containing
> > >> 'check-state' ?
> > >
> > > Not according to the ipfw(8) manual:
> > >
> > > """
> > > These dynamic rules, which have a limited lifetime, are checked at the
> > > first occurrence of a check-state, keep-state or limit rule, and
> > > are typ-
> > > ically used to open the firewall on-demand to legitimate traffic only.
> > > See the STATEFUL FIREWALL and EXAMPLES Sections below for more
> > > informa-
> > > tion on the stateful behaviour of ipfw.
> > > """
> > >
> > > I read this to mean the dynamic rules are checked at rule #5000 from the
> > > above list. Is there an advantage to having an explicit check-state rule
> > > in simple rulesets like this one?
> >
> > the docs are wrong then I think.
>
> If so, they've been wrong since 4.something .. certainly before 4.8.
> It's hard to imagine nobody else has ever relied on that doc behaviour,
> so perhaps the docs, if wrong, have become so at some more recent time?
Not that I have known... keep-state does not (and never has) include
an implicit check-state.
I think the document is talking about the lifetime.
Each time a keep-state or check-state or limit is hit,
the TTL is kicked.
>
> I guess the simple way to find out is for Ivan to add a check-state
> somewhere before the first keep-state, affecting all new connections.
>
> If that doesn't fix the problem, then it looks like the denied packets
> really are coming in from non-established sessions, as they would appear
> on the surface - if it wasn't known that the sources should be good!
>
> No chance net.inet.ip.fw.dyn_count is hitting net.inet.ip.fw.dyn_max ?
>
> cheers, Ian
>
> _______________________________________________
> 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 Fri Apr 4 05:05:37 2008
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 165BB1065671
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 05:05:36 +0000 (UTC)
(envelope-from rfg@tristatelogic.com)
Received: from segfault-outgoing-helo.tristatelogic.com
(112.171-60-66-fuji-dsl.static.surewest.net [66.60.171.112])
by mx1.freebsd.org (Postfix) with ESMTP id 7F2188FC13
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 05:05:36 +0000 (UTC)
(envelope-from rfg@tristatelogic.com)
Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1])
by segfault.tristatelogic.com (Postfix) with ESMTP id 5598F1142D
for <freebsd-net@freebsd.org>; Thu, 3 Apr 2008 22:05:36 -0700 (PDT)
To: freebsd-net@freebsd.org
Date: Thu, 03 Apr 2008 22:05:36 -0700
Message-ID: <74665.1207285536@tristatelogic.com>
From: "Ronald F. Guilmette" <rfg@tristatelogic.com>
Subject: Measuring Wireless Performance (?)
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, 04 Apr 2008 05:05:37 -0000
As I just mentioned in my immediately preceeding post, I'm a total
neophite when it come to wirless networking, so I need to ask a
rather basic question.
In preparation for installing my first ever wireless network, I read
up on the subject awhile first, and I found several people who had
commented (in various places) that they had bought "upgrade" antennas
for their wirless cards, and that this helped them, either to make
connections where they otherwise couldn't, or else with throughput/
performance of their wireless link.
Being totally new to this stuff, I have no idea if I would benefit
from a better antenna for my wireless card or not, so I gotta ask:
How can I tell?
Are there some tools available for FreeBSD that would tell me about
stuff like:
Received Signal Strength Indicator (RSSI)
Failed Frame Transmission Count, etc.
and/or performance of the wirless link generally?
Humm... OK. I just found this, but it seems to be a Windoze-only thing:
http://sysnet.ucsd.edu/pawn/wrapi/
:-)
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 05:09:17 2008
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 9702D1065670
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 05:09:17 +0000 (UTC)
(envelope-from rfg@tristatelogic.com)
Received: from segfault-outgoing-helo.tristatelogic.com
(112.171-60-66-fuji-dsl.static.surewest.net [66.60.171.112])
by mx1.freebsd.org (Postfix) with ESMTP id 6D5668FC17
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 05:09:17 +0000 (UTC)
(envelope-from rfg@tristatelogic.com)
Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1])
by segfault.tristatelogic.com (Postfix) with ESMTP id 84EBB11423
for <freebsd-net@freebsd.org>; Thu, 3 Apr 2008 21:51:30 -0700 (PDT)
To: freebsd-net@freebsd.org
Date: Thu, 03 Apr 2008 21:51:30 -0700
Message-ID: <74565.1207284690@tristatelogic.com>
From: "Ronald F. Guilmette" <rfg@tristatelogic.com>
Subject: WMP54g, ral(4) driver, & 7.0-RELEASE -- Thanks, question, & comments
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, 04 Apr 2008 05:09:17 -0000
I just wanted to drop a line and say "Thanks!" to everybody who worked on
getting support for the Linksys WMP54g v4/v4.1 (and the RT2561C chipset -
now supported by the ral(4) driver) into 7.0-RELEASE.
I'm a total wireless neophite, but after a modest amount of fiddling and
Reading of the Fine Manual, this card... I have the v4.1 version... seems
to be working great for me. So thanks to all who had a hand in that.
I do have one (or maybe two) small questions however. It appears that
if one has this card and one does an "ifconfig ral0 scan", that this scan
will hang forever _unless_ there is something out there for the card to
find, i.e. something it can talk to. Is that by design, or did somebody
just forget to slip in a timeout someplace?
Also, I've seen this exact same "hang forever during a scan" behavior now
in another context too, and it seems really weird... I can't explain it,
and I hope that somebody else will take a stab at explaining it to me. I have
purchased a shiny new Linksys WRT54G router to keep my shiny new Linksys
WMP54g wireless PCI card company, and strangly/inexplicably, it seems that
if I configure the router for either "WPA Personal" or "WPA2 Personal"
security _and_ then also select just "AES" rather than the other choice,
which is "TKIP+AES", then in this case also, doing an "ifconfig ral0 scan"
back on the machine with the WMP54g card in it seems to hang forever. Does
anybody have any idea why that might happen?
It's no big deal. The obvious workaround is just to leave "TKIP+AES" set
on the WRT54G all of the time, and that seems to work fine.
Now that I've gotten my question out of the way, a few comments. I'm
providing these in the hope sthat they may perhaps help some other
wireless neophites who, like me, are just getting started with wireless
stuff.
Firstly, to any of you other folks out there who are just getting ready to
buy components, and who want to do some wirless networking with FreeBSD,
allow me to suggest that you _not_ buy an ASUS WL-138G. These are currently
available from Newegg, and are pretty inexpensive (about $19 bucks) but
(as I learned _after_ I bought one) the chipset of those is a Marvell
chipset, and thus, the thing ain't directly supported by BSD. You gotta
use a clever kludge... it's very clever, but its still a kludge... called
"ndiswrapper" to get BSD to talk to the Marvell chipset. And under that
approach, you're basically using a (non-open) Windoze driver for the chipset
which gets magically wedged into BSD (or Linux) via the magic of ndiswrapper.
All things considered, its better to get a card that has a chipset that's
natively supported by your own kernel. I'm sure that the ASUS WL-138G,
like all ASUS products, is a fine product and a find card, but if anybody
wants one, I happen to be selling one, cheap.
As regards to the Linksys WMP54g (v4/v4.1) PCI wireless card... well... the
kernel didn't even see it as being present under FreeBSD 6.2-RELEASE, but
thankfully, that has now been corrected, and under FreeBSD 7.0-RELEASE the
card seems to work just peachy. Looking at all of the wireless-G PCI cards
available at Newegg right now, this is certainly one of the less expensive
ones (around $39 bucks as of this writing) so that fact that FreeBSD now
supports it is really helpful. (And, as you might expect, it seems to play
well with the Linksys WRT54G router, which is also really inexpensive at
Newegg right now... around $43 bucks.)
That's all. I hope thatthis infor will be helpful to others.
Regards,
rfg
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 08:52:13 2008
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 A22DE1065674
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 08:52:13 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
by mx1.freebsd.org (Postfix) with ESMTP id 2BA3F8FC28
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 08:52:12 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1JhheW-0006bn-64
for freebsd-net@freebsd.org; Fri, 04 Apr 2008 08:52:04 +0000
Received: from lara.cc.fer.hr ([161.53.72.113])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Fri, 04 Apr 2008 08:52:04 +0000
Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Fri, 04 Apr 2008 08:52:04 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-net@freebsd.org
From: Ivan Voras <ivoras@freebsd.org>
Date: Fri, 04 Apr 2008 10:51:47 +0200
Lines: 56
Message-ID: <ft4q79$ub9$1@ger.gmane.org>
References: <ft3phn$ai3$1@ger.gmane.org> <20080403234059.GA53417@owl.midgard.homeip.net> <ft3qji$cr9$1@ger.gmane.org>
<47F5748F.9050207@elischer.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig856CFB6FE3BCEC37C20C2631"
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
In-Reply-To: <47F5748F.9050207@elischer.org>
X-Enigmail-Version: 0.95.0
Sender: news <news@ger.gmane.org>
Subject: Re: Trouble with IPFW or TCP?
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, 04 Apr 2008 08:52:13 -0000
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig856CFB6FE3BCEC37C20C2631
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Julian Elischer wrote:
> Ivan Voras wrote:
>> Not according to the ipfw(8) manual:
>>
>> """
>> These dynamic rules, which have a limited lifetime, are checked
>> at the
>> first occurrence of a check-state, keep-state or limit rule, and
>> are typ-
>> ically used to open the firewall on-demand to legitimate traffic
>> only.
>> See the STATEFUL FIREWALL and EXAMPLES Sections below for more
>> informa-
>> tion on the stateful behaviour of ipfw.
>> """
>>
>> I read this to mean the dynamic rules are checked at rule #5000 from
>> the above list. Is there an advantage to having an explicit
>> check-state rule in simple rulesets like this one?
>=20
> the docs are wrong then I think.
Ok, but:
- The connections work. If keep-states don't include implicit
check-state somewhere, the behaviour should be as if there's no
"keep-state" option to the rules, i.e. only the "setup" (syn,!ack)
packet would pass, which would prevent TCP connections to happen (from
experience I know that omitting keep-state works just like that).
- The same behaviour works on other machines (no explicit check-state)
ranging from 5.x to 7-STABLE.
- I've been using ipfw this way since FreeBSD 4.4 or something like
that, without described problems. The other machine with 7.x also
doesn't have check-state and works.
--------------enig856CFB6FE3BCEC37C20C2631
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH9ewpldnAQVacBcgRAiJfAKCZu43WCHtWPJavBNz/rD8ay+BFQgCglJSw
63DXqyAP9Cph4ZfYHbr0Pso=
=DHsL
-----END PGP SIGNATURE-----
--------------enig856CFB6FE3BCEC37C20C2631--
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 09:09:29 2008
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 008361065672
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 09:09:29 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
by mx1.freebsd.org (Postfix) with ESMTP id AD7CB8FC22
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 09:09:28 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1JhhvL-0007KH-2O
for freebsd-net@freebsd.org; Fri, 04 Apr 2008 09:09:27 +0000
Received: from lara.cc.fer.hr ([161.53.72.113])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Fri, 04 Apr 2008 09:09:27 +0000
Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Fri, 04 Apr 2008 09:09:27 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-net@freebsd.org
From: Ivan Voras <ivoras@freebsd.org>
Date: Fri, 04 Apr 2008 11:09:19 +0200
Lines: 35
Message-ID: <ft4r7v$ub9$3@ger.gmane.org>
References: <ft3phn$ai3$1@ger.gmane.org> <47F57437.6040400@elischer.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig5E3D2D59E7F4BE98E6F221EF"
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
In-Reply-To: <47F57437.6040400@elischer.org>
X-Enigmail-Version: 0.95.0
Sender: news <news@ger.gmane.org>
Subject: Re: Trouble with IPFW or TCP?
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, 04 Apr 2008 09:09:29 -0000
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5E3D2D59E7F4BE98E6F221EF
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Julian Elischer wrote:
> Ivan Voras wrote:
>> In which case would an ipfw ruleset like this:
>>
>> 00100 114872026 40487887607 allow ip from any to any via lo0
>> 00200 0 0 deny ip from any to 127.0.0.0/8
>> 00300 0 0 deny ip from 127.0.0.0/8 to any
>> 00600 1585 112576 deny ip from table(0) to me
> ipfw add 700 check-state
Predictably, adding check-state doesn't do anything new. Additionally,
the counters of check-state are always 0 (I don't know if this is good
or not).
--------------enig5E3D2D59E7F4BE98E6F221EF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH9fA/ldnAQVacBcgRAvoDAJ94W3FvLXT0m5UUy5O7+zfY5arE1gCffhXa
8TGZKzSarV3FSkpNFjS6QGk=
=faaQ
-----END PGP SIGNATURE-----
--------------enig5E3D2D59E7F4BE98E6F221EF--
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 14:38:30 2008
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 CB3F2106567C;
Fri, 4 Apr 2008 14:38:30 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su
[213.184.65.80])
by mx1.freebsd.org (Postfix) with ESMTP id 242C38FC12;
Fri, 4 Apr 2008 14:38:29 +0000 (UTC)
(envelope-from eugen@kuzbass.ru)
Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1])
by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m34EC8Sv056263;
Fri, 4 Apr 2008 22:12:08 +0800 (KRAST)
(envelope-from eugen@www.svzserv.kemerovo.su)
Received: (from eugen@localhost)
by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m34EC8ir056262;
Fri, 4 Apr 2008 22:12:08 +0800 (KRAST) (envelope-from eugen)
Date: Fri, 4 Apr 2008 22:12:08 +0800
From: Eugene Grosbein <eugen@kuzbass.ru>
To: bug-followup@freebsd.org
Message-ID: <20080404141208.GA55848@svzserv.kemerovo.su>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Cc: net@freebsd.org
Subject: Re: bin/120720: [patch] [ipfw] unbreak POLA for ipfw table list
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, 04 Apr 2008 14:38:30 -0000
Hi!
This PR was closed 6 weeks ago and had a record "MFC After: 3 days".
http://www.freebsd.org/cgi/query-pr.cgi?pr=120720
There is still no MFC to RELENG_7 nor to RELENG_6 where POLA was broken.
Please do it.
Eugene Grosbein
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 16:03:32 2008
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 C01A6106564A;
Fri, 4 Apr 2008 16:03:32 +0000 (UTC)
(envelope-from smithi@nimnet.asn.au)
Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143])
by mx1.freebsd.org (Postfix) with ESMTP id 663138FC1F;
Fri, 4 Apr 2008 16:03:30 +0000 (UTC)
(envelope-from smithi@nimnet.asn.au)
Received: from localhost (smithi@localhost)
by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id CAA12901;
Sat, 5 Apr 2008 02:03:21 +1000 (EST)
(envelope-from smithi@nimnet.asn.au)
Date: Sat, 5 Apr 2008 02:03:17 +1000 (EST)
From: Ian Smith <smithi@nimnet.asn.au>
To: Julian Elischer <julian@elischer.org>
In-Reply-To: <47F5B17E.5000304@elischer.org>
Message-ID: <Pine.BSF.3.96.1080405010904.6611B-100000@gaia.nimnet.asn.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: freebsd-net@freebsd.org, Ivan Voras <ivoras@freebsd.org>
Subject: Re: Trouble with IPFW or TCP?
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, 04 Apr 2008 16:03:32 -0000
On Thu, 3 Apr 2008, Julian Elischer wrote:
> Ian Smith wrote:
> > On Thu, 3 Apr 2008, Julian Elischer wrote:
> > > Ivan Voras wrote:
> > > > Erik Trulsson wrote:
> > > >> On Fri, Apr 04, 2008 at 01:34:07AM +0200, Ivan Voras wrote:
> > > >>> In which case would an ipfw ruleset like this:
> > > >>>
> > > >>> 00100 114872026 40487887607 allow ip from any to any via lo0
> > > >>> 00200 0 0 deny ip from any to 127.0.0.0/8
> > > >>> 00300 0 0 deny ip from 127.0.0.0/8 to any
> > > >>> 00600 1585 112576 deny ip from table(0) to me
> > > >>> 01000 90279 7325972 allow icmp from any to any
> > > >>> 05000 475961039 334422494257 allow tcp from me to any setup keep-state
> > > >>> 05100 634155 65779377 allow udp from me to any keep-state
> > > >>> 06022 409604 69177326 allow tcp from any to me dst-port 22
> > > >>> setup keep-state
> > > >>> 06080 52159025 43182548092 allow tcp from any to me dst-port 80
> > > >>> setup keep-state
> > > >>> 06443 6392366 2043532158 allow tcp from any to me dst-port 443
> > > >>> setup keep-state
> > > >>> 07020 517065 292377553 allow tcp from any to me dst-port 8080
> > > >>> setup keep-state
> > > >>> 65400 12273387 629703212 deny log ip from any to any
> > > >>> 65535 0 0 deny ip from any to any
> > > >>
> > > >> If you are using 'keep-state' should there not also be some rule
> > > >> containing
> > > >> 'check-state' ?
> > > >
> > > > Not according to the ipfw(8) manual:
> > > >
> > > > """
> > > > These dynamic rules, which have a limited lifetime, are checked at the
> > > > first occurrence of a check-state, keep-state or limit rule, and
> > > > are typ-
> > > > ically used to open the firewall on-demand to legitimate traffic only.
> > > > See the STATEFUL FIREWALL and EXAMPLES Sections below for more
> > > > informa-
> > > > tion on the stateful behaviour of ipfw.
> > > > """
> > > >
> > > > I read this to mean the dynamic rules are checked at rule #5000 from the
> > > > above list. Is there an advantage to having an explicit check-state rule
> > > > in simple rulesets like this one?
> > >
> > > the docs are wrong then I think.
> >
> > If so, they've been wrong since 4.something .. certainly before 4.8.
> > It's hard to imagine nobody else has ever relied on that doc behaviour,
> > so perhaps the docs, if wrong, have become so at some more recent time?
>
> Not that I have known... keep-state does not (and never has) include
> an implicit check-state.
Sorry (and surprised!) to have to differ, but you MADE me read the code!
Bearing in mind I'm reading 5.5 sources - stop me if it's changed - but
starting with /usr/sbin/ipfw/ipfw2.c we see that adding check-state just
generates an O_CHECK_STATE, while adding keep-state or limit rules first
generate an initial O_PROBE_STATE opcode (ignored when listing rules):
/*
* Now copy stuff into the rule.
* If we have a keep-state option, the first instruction
* must be a PROBE_STATE (which is generated here).
* If we have a LOG option, it was stored as the first command,
* and now must be moved to the top of the action part.
*/
dst = (ipfw_insn *)rule->cmd;
[..]
/*
* generate O_PROBE_STATE if necessary
*/
if (have_state && have_state->opcode != O_CHECK_STATE) {
fill_cmd(dst, O_PROBE_STATE, 0, 0);
dst = next_cmd(dst);
then go on to generate the O_KEEP_STATE or O_LIMIT rule as appropriate.
Now in /sys/netinet/ip_fw2.c in ipfw_chk circa line 2400 (@5.5) we have:
* O_LIMIT and O_KEEP_STATE: these opcodes are
* not real 'actions', and are stored right
* before the 'action' part of the rule.
* These opcodes try to install an entry in the
* state tables; if successful, we continue with
* the next opcode (match=1; break;), otherwise
* the packet * must be dropped
* ('goto done' after setting retval);
*
* O_PROBE_STATE and O_CHECK_STATE: these opcodes
* cause a lookup of the state table, and a jump
* to the 'action' part of the parent rule
* ('goto check_body') if an entry is found, or
* (CHECK_STATE only) a jump to the next rule if
* the entry is not found ('goto next_rule').
* The result of the lookup is cached to make
* further instances of these opcodes are
* effectively NOPs.
*/
case O_LIMIT:
case O_KEEP_STATE:
if (install_state(f,
(ipfw_insn_limit *)cmd, args)) {
retval = IP_FW_PORT_DENY_FLAG;
goto done; /* error/limit violation */
}
match = 1;
break;
case O_PROBE_STATE:
case O_CHECK_STATE:
/*
* dynamic rules are checked at the first
* keep-state or check-state occurrence,
* with the result being stored in dyn_dir.
* The compiler introduces a PROBE_STATE
* instruction for us when we have a
* KEEP_STATE (because PROBE_STATE needs
* to be run first).
*/
if (dyn_dir == MATCH_UNKNOWN &&
(q = lookup_dyn_rule(&args->f_id,
&dyn_dir, proto == IPPROTO_TCP ?
L3HDR(struct tcphdr, ip) : NULL))
!= NULL) {
/*
* Found dynamic entry, update stats
* and jump to the 'action' part of
* the parent rule.
*/
q->pcnt++;
q->bcnt += pktlen;
f = q->rule;
cmd = ACTION_PTR(f);
l = f->cmd_len - f->act_ofs;
IPFW_DYN_UNLOCK();
goto check_body;
}
/*
* Dynamic entry not found. If CHECK_STATE,
* skip to next rule, if PROBE_STATE just
* ignore and continue with next opcode.
*/
if (cmd->opcode == O_CHECK_STATE)
goto next_rule;
match = 1;
break;
So indeed each rule with keep-state or limit options does the same probe
as a check-state in the first opcode, before then installing or checking
state in the subsequent opcode. Or so it reads to an ancient neophyte ..
> I think the document is talking about the lifetime.
> Each time a keep-state or check-state or limit is hit,
> the TTL is kicked.
That's pretty well described under keep-state and elsewhere. Good ol'
ipfw(8) has yet to let me down, and like Ivan I recall keep-state rules
(albeit only for UDP) without any check-state working just fine.
Not that any of that helps solve Ivan's problem ..
cheers, Ian
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 17:40:12 2008
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 13EC1106564A
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 17:40:12 +0000 (UTC)
(envelope-from julian@elischer.org)
Received: from outD.internet-mail-service.net (outd.internet-mail-service.net
[216.240.47.227])
by mx1.freebsd.org (Postfix) with ESMTP id EAC788FC19
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 17:40:11 +0000 (UTC)
(envelope-from julian@elischer.org)
Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160)
by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP;
Fri, 04 Apr 2008 13:18:38 -0700
Received: from julian-mac.elischer.org (localhost [127.0.0.1])
by idiom.com (Postfix) with ESMTP id 7FD702D6010;
Fri, 4 Apr 2008 10:40:08 -0700 (PDT)
Message-ID: <47F667FA.6020208@elischer.org>
Date: Fri, 04 Apr 2008 10:40:10 -0700
From: Julian Elischer <julian@elischer.org>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Ian Smith <smithi@nimnet.asn.au>
References: <Pine.BSF.3.96.1080405010904.6611B-100000@gaia.nimnet.asn.au>
In-Reply-To: <Pine.BSF.3.96.1080405010904.6611B-100000@gaia.nimnet.asn.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org, Ivan Voras <ivoras@freebsd.org>
Subject: Re: Trouble with IPFW or TCP?
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, 04 Apr 2008 17:40:12 -0000
Ian Smith wrote:
> On Thu, 3 Apr 2008, Julian Elischer wrote:
>
> > Not that I have known... keep-state does not (and never has) include
> > an implicit check-state.
>
> Sorry (and surprised!) to have to differ, but you MADE me read the code!
yep you are right..
boy is that ever a broken feature..
there is no way to set a new session without leaping off into the
previously declared sessions.
I just tested it and it does as you say...
00001 166 17438 skipto 1000 tcp from any to 10.2.2.2 keep-state
00002 9 886 allow ip from any to any
01000 166 17438 count log ip from any to any
01001 93 7727 count log tcp from any to 10.2.2.2
01002 73 9711 count log tcp from 10.2.2.2 to any
65535 166 17438 allow ip from any to any
I'm stunned..
boy is that ever a broken feature..
There is no way to set a new session without leaping off into the
previously declared sessions.
I also have to check my firewalls to see if I'm hitting unexpeced
behaviour.
>
> Bearing in mind I'm reading 5.5 sources - stop me if it's changed - but
> starting with /usr/sbin/ipfw/ipfw2.c we see that adding check-state just
> generates an O_CHECK_STATE, while adding keep-state or limit rules first
> generate an initial O_PROBE_STATE opcode (ignored when listing rules):
>
> /*
> * Now copy stuff into the rule.
> * If we have a keep-state option, the first instruction
> * must be a PROBE_STATE (which is generated here).
> * If we have a LOG option, it was stored as the first command,
> * and now must be moved to the top of the action part.
> */
> dst = (ipfw_insn *)rule->cmd;
> [..]
> /*
> * generate O_PROBE_STATE if necessary
> */
> if (have_state && have_state->opcode != O_CHECK_STATE) {
> fill_cmd(dst, O_PROBE_STATE, 0, 0);
> dst = next_cmd(dst);
>
> then go on to generate the O_KEEP_STATE or O_LIMIT rule as appropriate.
>
> Now in /sys/netinet/ip_fw2.c in ipfw_chk circa line 2400 (@5.5) we have:
>
> * O_LIMIT and O_KEEP_STATE: these opcodes are
> * not real 'actions', and are stored right
> * before the 'action' part of the rule.
> * These opcodes try to install an entry in the
> * state tables; if successful, we continue with
> * the next opcode (match=1; break;), otherwise
> * the packet * must be dropped
> * ('goto done' after setting retval);
> *
> * O_PROBE_STATE and O_CHECK_STATE: these opcodes
> * cause a lookup of the state table, and a jump
> * to the 'action' part of the parent rule
> * ('goto check_body') if an entry is found, or
> * (CHECK_STATE only) a jump to the next rule if
> * the entry is not found ('goto next_rule').
> * The result of the lookup is cached to make
> * further instances of these opcodes are
> * effectively NOPs.
> */
> case O_LIMIT:
> case O_KEEP_STATE:
> if (install_state(f,
> (ipfw_insn_limit *)cmd, args)) {
> retval = IP_FW_PORT_DENY_FLAG;
> goto done; /* error/limit violation */
> }
> match = 1;
> break;
>
> case O_PROBE_STATE:
> case O_CHECK_STATE:
> /*
> * dynamic rules are checked at the first
> * keep-state or check-state occurrence,
> * with the result being stored in dyn_dir.
> * The compiler introduces a PROBE_STATE
> * instruction for us when we have a
> * KEEP_STATE (because PROBE_STATE needs
> * to be run first).
> */
> if (dyn_dir == MATCH_UNKNOWN &&
> (q = lookup_dyn_rule(&args->f_id,
> &dyn_dir, proto == IPPROTO_TCP ?
> L3HDR(struct tcphdr, ip) : NULL))
> != NULL) {
> /*
> * Found dynamic entry, update stats
> * and jump to the 'action' part of
> * the parent rule.
> */
> q->pcnt++;
> q->bcnt += pktlen;
> f = q->rule;
> cmd = ACTION_PTR(f);
> l = f->cmd_len - f->act_ofs;
> IPFW_DYN_UNLOCK();
> goto check_body;
> }
> /*
> * Dynamic entry not found. If CHECK_STATE,
> * skip to next rule, if PROBE_STATE just
> * ignore and continue with next opcode.
> */
> if (cmd->opcode == O_CHECK_STATE)
> goto next_rule;
> match = 1;
> break;
>
> So indeed each rule with keep-state or limit options does the same probe
> as a check-state in the first opcode, before then installing or checking
> state in the subsequent opcode. Or so it reads to an ancient neophyte ..
>
> > I think the document is talking about the lifetime.
> > Each time a keep-state or check-state or limit is hit,
> > the TTL is kicked.
>
> That's pretty well described under keep-state and elsewhere. Good ol'
> ipfw(8) has yet to let me down, and like Ivan I recall keep-state rules
> (albeit only for UDP) without any check-state working just fine.
>
> Not that any of that helps solve Ivan's problem ..
>
> cheers, Ian
>
> _______________________________________________
> 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 Fri Apr 4 17:49:16 2008
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 D3A731065672
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 17:49:16 +0000 (UTC)
(envelope-from sam@freebsd.org)
Received: from ebb.errno.com (ebb.errno.com [69.12.149.25])
by mx1.freebsd.org (Postfix) with ESMTP id 8ACE78FC31
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 17:49:16 +0000 (UTC)
(envelope-from sam@freebsd.org)
Received: from trouble.errno.com (trouble.errno.com [10.0.0.248])
(authenticated bits=0)
by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m34HnFWX037991
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Fri, 4 Apr 2008 10:49:15 -0700 (PDT) (envelope-from sam@freebsd.org)
Message-ID: <47F66A1B.50603@freebsd.org>
Date: Fri, 04 Apr 2008 10:49:15 -0700
From: Sam Leffler <sam@freebsd.org>
Organization: FreeBSD Project
User-Agent: Thunderbird 2.0.0.9 (X11/20071125)
MIME-Version: 1.0
To: "Ronald F. Guilmette" <rfg@tristatelogic.com>
References: <74565.1207284690@tristatelogic.com>
In-Reply-To: <74565.1207284690@tristatelogic.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist
Cc: freebsd-net@freebsd.org
Subject: Re: WMP54g, ral(4) driver, & 7.0-RELEASE -- Thanks, question,
& comments
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, 04 Apr 2008 17:49:16 -0000
Ronald F. Guilmette wrote:
> I just wanted to drop a line and say "Thanks!" to everybody who worked on
> getting support for the Linksys WMP54g v4/v4.1 (and the RT2561C chipset -
> now supported by the ral(4) driver) into 7.0-RELEASE.
>
> I'm a total wireless neophite, but after a modest amount of fiddling and
> Reading of the Fine Manual, this card... I have the v4.1 version... seems
> to be working great for me. So thanks to all who had a hand in that.
>
> I do have one (or maybe two) small questions however. It appears that
> if one has this card and one does an "ifconfig ral0 scan", that this scan
> will hang forever _unless_ there is something out there for the card to
> find, i.e. something it can talk to. Is that by design, or did somebody
> just forget to slip in a timeout someplace?
>
ifconfig issues a scan request and waits for an event indicating the
scan has completed. If it hangs then it didn't receive the event for
some reason. You haven't said how your card was setup or what state it
was in so there's no way to guess what's going on. wlandebug(8) can be
used to see what's happening; e.g.
wlandebug -i ral0 scan
will send debug msgs to the console for scan operations.
> Also, I've seen this exact same "hang forever during a scan" behavior now
> in another context too, and it seems really weird... I can't explain it,
> and I hope that somebody else will take a stab at explaining it to me. I have
> purchased a shiny new Linksys WRT54G router to keep my shiny new Linksys
> WMP54g wireless PCI card company, and strangly/inexplicably, it seems that
> if I configure the router for either "WPA Personal" or "WPA2 Personal"
> security _and_ then also select just "AES" rather than the other choice,
> which is "TKIP+AES", then in this case also, doing an "ifconfig ral0 scan"
> back on the machine with the WMP54g card in it seems to hang forever. Does
> anybody have any idea why that might happen?
>
> It's no big deal. The obvious workaround is just to leave "TKIP+AES" set
> on the WRT54G all of the time, and that seems to work fine.
>
Again, no logs, no way of answering. It's possible your AP doesn't
offer AES only TKIP so the scan continued looking for an AP that matches
the requirements you set out. A log from wpa_supplicant would likely
tell you what's happening.
>
> Now that I've gotten my question out of the way, a few comments. I'm
> providing these in the hope sthat they may perhaps help some other
> wireless neophites who, like me, are just getting started with wireless
> stuff.
>
> Firstly, to any of you other folks out there who are just getting ready to
> buy components, and who want to do some wirless networking with FreeBSD,
> allow me to suggest that you _not_ buy an ASUS WL-138G. These are currently
> available from Newegg, and are pretty inexpensive (about $19 bucks) but
> (as I learned _after_ I bought one) the chipset of those is a Marvell
> chipset, and thus, the thing ain't directly supported by BSD. You gotta
> use a clever kludge... it's very clever, but its still a kludge... called
> "ndiswrapper" to get BSD to talk to the Marvell chipset. And under that
> approach, you're basically using a (non-open) Windoze driver for the chipset
> which gets magically wedged into BSD (or Linux) via the magic of ndiswrapper.
>
Depends which Marvell part. There's a driver in HEAD that will get
MFC'd not to long from now to support the 8335 part. If this card uses
the "Libertas" chipset then there's no driver right now but we could do
one as Marvell has publicized how to program these parts and we have a
good relationship with them.
> All things considered, its better to get a card that has a chipset that's
> natively supported by your own kernel. I'm sure that the ASUS WL-138G,
> like all ASUS products, is a fine product and a find card, but if anybody
> wants one, I happen to be selling one, cheap.
>
> As regards to the Linksys WMP54g (v4/v4.1) PCI wireless card... well... the
> kernel didn't even see it as being present under FreeBSD 6.2-RELEASE, but
> thankfully, that has now been corrected, and under FreeBSD 7.0-RELEASE the
> card seems to work just peachy. Looking at all of the wireless-G PCI cards
> available at Newegg right now, this is certainly one of the less expensive
> ones (around $39 bucks as of this writing) so that fact that FreeBSD now
> supports it is really helpful. (And, as you might expect, it seems to play
> well with the Linksys WRT54G router, which is also really inexpensive at
> Newegg right now... around $43 bucks.)
>
> That's all. I hope thatthis infor will be helpful to others.
>
>
> Regards,
> rfg
>
> _______________________________________________
> 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 Fri Apr 4 17:52:52 2008
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 9A799106566B
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 17:52:52 +0000 (UTC)
(envelope-from sam@freebsd.org)
Received: from ebb.errno.com (ebb.errno.com [69.12.149.25])
by mx1.freebsd.org (Postfix) with ESMTP id 6C8458FC13
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 17:52:52 +0000 (UTC)
(envelope-from sam@freebsd.org)
Received: from trouble.errno.com (trouble.errno.com [10.0.0.248])
(authenticated bits=0)
by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m34HqpuR038024
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Fri, 4 Apr 2008 10:52:52 -0700 (PDT) (envelope-from sam@freebsd.org)
Message-ID: <47F66AF3.9020004@freebsd.org>
Date: Fri, 04 Apr 2008 10:52:51 -0700
From: Sam Leffler <sam@freebsd.org>
Organization: FreeBSD Project
User-Agent: Thunderbird 2.0.0.9 (X11/20071125)
MIME-Version: 1.0
To: "Ronald F. Guilmette" <rfg@tristatelogic.com>
References: <74665.1207285536@tristatelogic.com>
In-Reply-To: <74665.1207285536@tristatelogic.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-DCC--Metrics: ebb.errno.com; whitelist
Cc: freebsd-net@freebsd.org
Subject: Re: Measuring Wireless Performance (?)
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, 04 Apr 2008 17:52:52 -0000
Ronald F. Guilmette wrote:
> As I just mentioned in my immediately preceeding post, I'm a total
> neophite when it come to wirless networking, so I need to ask a
> rather basic question.
>
> In preparation for installing my first ever wireless network, I read
> up on the subject awhile first, and I found several people who had
> commented (in various places) that they had bought "upgrade" antennas
> for their wirless cards, and that this helped them, either to make
> connections where they otherwise couldn't, or else with throughput/
> performance of their wireless link.
>
> Being totally new to this stuff, I have no idea if I would benefit
> from a better antenna for my wireless card or not, so I gotta ask:
> How can I tell?
>
> Are there some tools available for FreeBSD that would tell me about
> stuff like:
>
> Received Signal Strength Indicator (RSSI)
> Failed Frame Transmission Count, etc.
>
> and/or performance of the wirless link generally?
>
> Humm... OK. I just found this, but it seems to be a Windoze-only thing:
>
> http://sysnet.ucsd.edu/pawn/wrapi/
>
> :-)
> _______________________________________________
>
ifconfig ral0 list sta shows rssi + noise floor if the driver provides
it. As to performance you need to distinguish between tx+rx operation.
The ral driver in REELNG_7 uses a tx rate control algorithm that is
mismatched for the device capabilities. As a result tx performance is
suboptimal. Using unidirectional UDP tests like netperf -t UDP_STREAM
in each direction is useful to characterize operation + performance.
If your problem is you are simply too far from your ap then boosting
gain with an outboard antenna can help but rx sensitivity is just as
important (in many cases more important) than tx power so whatever you
do must consider this.
In the end you're likely better off just springing for a better wireless
card.
Sam
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 20:00:14 2008
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 E408B106566B
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 20:00:14 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
by mx1.freebsd.org (Postfix) with ESMTP id 5F4098FC21
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 20:00:14 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1Jhs54-0007O3-Fe
for freebsd-net@freebsd.org; Fri, 04 Apr 2008 20:00:10 +0000
Received: from 89-172-58-186.adsl.net.t-com.hr ([89.172.58.186])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Fri, 04 Apr 2008 20:00:10 +0000
Received: from ivoras by 89-172-58-186.adsl.net.t-com.hr with local (Gmexim
0.1 (Debian)) id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Fri, 04 Apr 2008 20:00:10 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-net@freebsd.org
From: Ivan Voras <ivoras@freebsd.org>
Date: Fri, 04 Apr 2008 21:59:56 +0200
Lines: 57
Message-ID: <ft61c4$ea6$1@ger.gmane.org>
References: <47F5B17E.5000304@elischer.org>
<Pine.BSF.3.96.1080405010904.6611B-100000@gaia.nimnet.asn.au>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig99AEA128A080BA6C64C18C77"
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 89-172-58-186.adsl.net.t-com.hr
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
In-Reply-To: <Pine.BSF.3.96.1080405010904.6611B-100000@gaia.nimnet.asn.au>
X-Enigmail-Version: 0.95.6
Sender: news <news@ger.gmane.org>
Subject: Re: Trouble with IPFW or TCP?
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, 04 Apr 2008 20:00:15 -0000
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig99AEA128A080BA6C64C18C77
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Ian Smith wrote:
> That's pretty well described under keep-state and elsewhere. Good ol'
> ipfw(8) has yet to let me down, and like Ivan I recall keep-state rules=
> (albeit only for UDP) without any check-state working just fine.
>=20
> Not that any of that helps solve Ivan's problem ..
Thanks for verifying this. I've reread what I posted and I think I=20
wasn't clear about one thing: it's not exactly a "hard" problem - as I=20
said, connections do get established and apparently they get processed=20
(the effects of those HTTPS messages are present). What troubles me is=20
that I wouldn't expect that to happen, considering the ipfw log messages =
I've posted. In short, either:
a) The senders (or something in between like a broken router; but note=20
that the 7.x machine behind the same infrastructure isn't generating the =
symptomatic log records) keeps sending spurious packets long after the=20
TCP session (communication) is actually completed. Someone with better=20
knowledge of TCP flows could maybe verify that. HTTPS messages are sent=20
every 15 minutes and I'd expect various timers to timeout the connection =
if the ACKs aren't processed.
b) The receiving side somehow bounces the packets around, reinserting=20
them after the TCP session is done. This would be weird. The server from =
which the posted logs and traces come from isn't running anything=20
special like netgraph, bpf applications, routed. It's basically a web=20
server.
--------------enig99AEA128A080BA6C64C18C77
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH9ojCldnAQVacBcgRAlQCAJ0V86n0rpMZv4jVLrQYLDNOHwZMhwCfTlro
FaOKsMd148RLICQ+r/pmQ1I=
=VGS4
-----END PGP SIGNATURE-----
--------------enig99AEA128A080BA6C64C18C77--
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 20:14:21 2008
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 E0A511065684
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 20:14:20 +0000 (UTC)
(envelope-from bounces@nabble.com)
Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158])
by mx1.freebsd.org (Postfix) with ESMTP id 834AC8FC32
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 20:14:20 +0000 (UTC)
(envelope-from bounces@nabble.com)
Received: from isper.nabble.com ([192.168.236.156])
by kuber.nabble.com with esmtp (Exim 4.63)
(envelope-from <bounces@nabble.com>) id 1JhsIl-0007MH-HE
for freebsd-net@freebsd.org; Fri, 04 Apr 2008 13:14:19 -0700
Message-ID: <16497816.post@talk.nabble.com>
Date: Fri, 4 Apr 2008 13:14:19 -0700 (PDT)
From: s3raphi <seraphi.lord@gmail.com>
To: freebsd-net@freebsd.org
In-Reply-To: <f383264b0803211553s6651fec4lb4b6f2a2f2e4af4a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Nabble-From: seraphi.lord@gmail.com
References: <f90b44e40803111756h517b373ala8afdff9395b7fac@mail.gmail.com>
<47D860AC.6030707@freebsd.org>
<f90b44e40803201909i2aab437bp58bc06755f60500f@mail.gmail.com>
<f383264b0803211553s6651fec4lb4b6f2a2f2e4af4a@mail.gmail.com>
Subject: Re: TCP options order changed in FreeBSD 7, incompatible with some
routers
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, 04 Apr 2008 20:14:21 -0000
I upgraded many web servers to FreeBSD 7.0-Release several weeks ago. These
servers serve hundreds of thousands of users. Since then, we have had many
users complain that they cannot connect to these servers any more. This was
a very tricky problem to diagnose, but using packet captures on both the
servers and the clients who have the problem I ended up with the same
results as the original poster. The user can ping the server with ICMP. The
user cannot complete a TCP connection.
Client sends SYN to server
Server responds SYN/ACK
Client packet capture does not show the SYN/ACK arrive.
Connection fails.
The windows client was running wireshark.
This problem is specific to windows, but also the network it is on or
devices it goes through. The same user experiencing the problem tried to
connect using a mac, and the problem does not manifest itself. Both the mac
and the windows pc were on the same network, behind the same SOHO router,
same ISP, and talking to the same FreeBSD7.0-RELEASE server.
Baffled by what the problem could have been, I stood up one of the old
FreeBSD 6.1 servers which had not yet been replaced with FreeBSD7. The user
has no trouble at all accessing the FreeBSD 6.1 server.
More interesting info:
-This makes it look like windows:
Fails: WindowsXPpro PC -> SOHO -> ISP -> Internet -> MyDataCenter ->
FreeBSD7
Works: MacBook -> SOHO -> ISP -> Internet -> MyDataCenter -> FreeBSD7
-This makes it look like the network(router/firewall/etc..):
If the WindowsPC connects to our office VPN, the connection to the FreeBSD7
server will work without issue.
The problem is specific to some combination of Windows and networks or
network devices. I have seen users on many different ISPs, and with many
different flavors of routers/firewalls.
-The problem only effects a small percentage of our users. Most of our
Windows users have no issue.
This is a very serious problem for anyone using FreeBSD7 in production as an
internet facing server as a huge percentage of clients will be windows, and
a percentage of those users will no longer be able to use your web services.
Can the patch be made available to freebsd-update?
-Seraphi
Matt Reimer wrote:
>
> On Thu, Mar 20, 2008 at 7:09 PM, d.s. al coda <coda.trigger@gmail.com>
> wrote:
>> On 3/12/08, Andre Oppermann <andre@freebsd.org> wrote:
>>
>> >
>>
>> > I'd be very interesting to know the exactly models and their firmware
>> > version
>> > of the affected routers. If available locally I'd like to obtain a
>> > similar
>> > model myself for future regression tests.
>>
>>
>> Here are the models we managed to hear about via email:
>> D-Link WBR-1310
>> Linksys WCG200 (with firewall enabled)
>> Encore Broadband Router
>> Linksys WAG354G
>> Ambit U10C019
>> Netgear CG814GCMR
>
> I've seen this on a Netgear CG814WG.
>
> Matt
> _______________________________________________
> 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"
>
>
--
View this message in context: http://www.nabble.com/TCP-options-order-changed-in-FreeBSD-7%2C-incompatible-with-some-routers-tp15996110p16497816.html
Sent from the freebsd-net mailing list archive at Nabble.com.
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 20:35:19 2008
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 0539F106566C
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 20:35:19 +0000 (UTC)
(envelope-from prvs=1980632278=killing@multiplay.co.uk)
Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23])
by mx1.freebsd.org (Postfix) with ESMTP id 6658D8FC23
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 20:35:18 +0000 (UTC)
(envelope-from prvs=1980632278=killing@multiplay.co.uk)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk;
s=Multiplay; t=1207340568; x=1207945368; q=dns/txt; h=Received:
Message-ID:From:To:References:Subject:Date:MIME-Version:
Content-Type:Content-Transfer-Encoding; bh=UlwVX3KY6i5xelXrU7E5J
P8w5c6u5MSvyyHV/ySybxU=; b=heM3UbkIpx+CEPsyPviWP2QNkG7671HUrR5zA
WAcW2/8GEH84Iq5djCZ7QJ76H2yjIk94SrNpMuWC70Xy2x+7uzCL8IMFlntbPqRw
JG/Ivh5pVb6jPqPm5h5xpBaSiD5IHIgkYGnYY1qCqexNBTLsXBvW6ds9H4y0v+de
RNukkg=
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on
mail1.multiplay.co.uk
X-Spam-Level:
X-Spam-Status: No, score=-14.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST,
USER_IN_WHITELIST_TO autolearn=ham version=3.1.8
Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v9.6.3)
with ESMTP id md50005435917.msg
for <freebsd-net@freebsd.org>; Fri, 04 Apr 2008 21:22:46 +0100
Message-ID: <021701c89691$a3306020$3d010a0a@multiplay.co.uk>
From: "Steven Hartland" <killing@multiplay.co.uk>
To: "s3raphi" <seraphi.lord@gmail.com>,
<freebsd-net@freebsd.org>
References: <f90b44e40803111756h517b373ala8afdff9395b7fac@mail.gmail.com><47D860AC.6030707@freebsd.org><f90b44e40803201909i2aab437bp58bc06755f60500f@mail.gmail.com><f383264b0803211553s6651fec4lb4b6f2a2f2e4af4a@mail.gmail.com>
<16497816.post@talk.nabble.com>
Date: Fri, 4 Apr 2008 21:22:42 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Authenticated-Sender: Killing@multiplay.co.uk
X-MDRemoteIP: 85.236.96.60
X-Return-Path: prvs=1980632278=killing@multiplay.co.uk
X-Envelope-From: killing@multiplay.co.uk
X-MDaemon-Deliver-To: freebsd-net@freebsd.org
X-Spam-Processed: mail1.multiplay.co.uk, Fri, 04 Apr 2008 21:22:47 +0100
X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 04 Apr 2008 21:22:48 +0100
Cc:
Subject: Re: TCP options order changed in FreeBSD 7,
incompatible with some routers
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, 04 Apr 2008 20:35:19 -0000
I believe this has already been covered in quite some depth
and iirc its regards the ordering of the new tcp flags
introduced in 7. Best to have a look in the list archives for
the specifics.
Regards
Steve
----- Original Message -----
From: "s3raphi" <seraphi.lord@gmail.com>
>
> I upgraded many web servers to FreeBSD 7.0-Release several weeks ago. These
> servers serve hundreds of thousands of users. Since then, we have had many
> users complain that they cannot connect to these servers any more. This was
> a very tricky problem to diagnose, but using packet captures on both the
> servers and the clients who have the problem I ended up with the same
> results as the original poster. The user can ping the server with ICMP. The
> user cannot complete a TCP connection.
> Client sends SYN to server
> Server responds SYN/ACK
> Client packet capture does not show the SYN/ACK arrive.
> Connection fails.
....
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 21:10:08 2008
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 411141065672
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 21:10:08 +0000 (UTC)
(envelope-from bzeeb-lists@lists.zabbadoz.net)
Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27])
by mx1.freebsd.org (Postfix) with ESMTP id CE9018FC26
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 21:10:07 +0000 (UTC)
(envelope-from bzeeb-lists@lists.zabbadoz.net)
Received: from localhost (amavis.str.cksoft.de [192.168.74.71])
by mail.cksoft.de (Postfix) with ESMTP id D45D441C752;
Fri, 4 Apr 2008 23:10:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at cksoft.de
Received: from mail.cksoft.de ([62.111.66.27])
by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new,
port 10024)
with ESMTP id KWeVjTvsCLY7; Fri, 4 Apr 2008 23:10:05 +0200 (CEST)
Received: by mail.cksoft.de (Postfix, from userid 66)
id 56FA041C75C; Fri, 4 Apr 2008 23:10:05 +0200 (CEST)
Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net
[10.111.66.10])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mail.int.zabbadoz.net (Postfix) with ESMTP id ACDF344487F;
Fri, 4 Apr 2008 21:07:00 +0000 (UTC)
Date: Fri, 4 Apr 2008 21:07:00 +0000 (UTC)
From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
X-X-Sender: bz@maildrop.int.zabbadoz.net
To: Steven Hartland <killing@multiplay.co.uk>
In-Reply-To: <021701c89691$a3306020$3d010a0a@multiplay.co.uk>
Message-ID: <20080404204927.Y66744@maildrop.int.zabbadoz.net>
References: <f90b44e40803111756h517b373ala8afdff9395b7fac@mail.gmail.com><47D860AC.6030707@freebsd.org><f90b44e40803201909i2aab437bp58bc06755f60500f@mail.gmail.com><f383264b0803211553s6651fec4lb4b6f2a2f2e4af4a@mail.gmail.com>
<16497816.post@talk.nabble.com>
<021701c89691$a3306020$3d010a0a@multiplay.co.uk>
X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-net@freebsd.org, s3raphi <seraphi.lord@gmail.com>
Subject: Re: TCP options order changed in FreeBSD 7, incompatible with some
routers
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, 04 Apr 2008 21:10:08 -0000
On Fri, 4 Apr 2008, Steven Hartland wrote:
Hi,
> I believe this has already been covered in quite some depth
> and iirc its regards the ordering of the new tcp flags
> introduced in 7. Best to have a look in the list archives for
> the specifics.
so as more users come and see this I am still trying to identify that
it's really the ordering of tcp options and not the bad padding.
History:
* the original problem showed up the first time
* people thought it was different option ordering
* tcp option ordering was changed back
* it was disocvered that there was bad padding after the options
* unfortunately changing back tcp options ordering hides the padding
problem as the bad padding does not occur
* padding fix was comitted
* both changes have been MFCed to 7-STABLE.
What you can do:
I am talking to someone else but the more people with resources could
verify this the next days/weeks the more confident we can be.
If you are running 7.0-RELEASE please apply this patch:
1.141.2.4 +10 -2 src/sys/netinet/tcp_output.c << that's the padding fix
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c.diff?r1=1.141.2.3;r2=1.141.2.4
rebuild your kernel, test with your users if things work ok now. If
they do (for all of them but the usual noise;) let us know.
If it does not help, apply the following patch as well and everything should be
fine (do not use TCP-MD5 as changing the order introduced another bug).
1.157.2.2 +5 -2 src/sys/netinet/tcp_var.h << that's the ordering fix
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.157.2.1;r2=1.157.2.2
In case you do not have the resources either directly apply both
patches or go to 7-STABLE (and do not use TCP-MD5 either).
There are no binary updates for this yet.
> ----- Original Message ----- From: "s3raphi" <seraphi.lord@gmail.com>
>>
>> I upgraded many web servers to FreeBSD 7.0-Release several weeks ago. These
>> servers serve hundreds of thousands of users. Since then, we have had many
>> users complain that they cannot connect to these servers any more. This was
>> a very tricky problem to diagnose, but using packet captures on both the
>> servers and the clients who have the problem I ended up with the same
>> results as the original poster. The user can ping the server with ICMP. The
>> user cannot complete a TCP connection.
>> Client sends SYN to server
>> Server responds SYN/ACK
>> Client packet capture does not show the SYN/ACK arrive.
>> Connection fails.
> ....
what would also be interesting to know is:
- Did the (SOHO) router drop it or the windows (XP) or another OS
like MAC OSX, linux, or ...
- Which (SOHO) router - if you think this is the culprit - vendor/model
- If it was the windows, and it was XP, was the XP firewall on?
- If it was the windows, are there any other 3rd party firewalls
running on it.
Someone may not understand why all these questions are important if
there is a patch available already:
a) finding out which change broke things is good for documentation
purposes. Especially if it would be the tcp options ordering
b) if it wasn't options ordering we might want to go back to the
more effective version
Bjoern
PS: you will also find tcpdump patches to show the tcp options and the
bad padding in this thread:
http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017267.html
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
Software is harder than hardware so better get it right the first time.
From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 22:23:41 2008
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 3CD661065671
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 22:23:41 +0000 (UTC)
(envelope-from julian@elischer.org)
Received: from outM.internet-mail-service.net (outm.internet-mail-service.net
[216.240.47.236])
by mx1.freebsd.org (Postfix) with ESMTP id 1445E8FC21
for <freebsd-net@freebsd.org>; Fri, 4 Apr 2008 22:23:41 +0000 (UTC)
(envelope-from julian@elischer.org)
Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160)
by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP;
Fri, 04 Apr 2008 18:10:48 -0700
Received: from julian-mac.elischer.org (localhost [127.0.0.1])
by idiom.com (Postfix) with ESMTP id 3D60E2D600F;
Fri, 4 Apr 2008 15:23:38 -0700 (PDT)
Message-ID: <47F6AA6B.30601@elischer.org>
Date: Fri, 04 Apr 2008 15:23:39 -0700
From: Julian Elischer <julian@elischer.org>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Ivan Voras <ivoras@freebsd.org>
References: <47F5B17E.5000304@elischer.org> <Pine.BSF.3.96.1080405010904.6611B-100000@gaia.nimnet.asn.au>
<ft61c4$ea6$1@ger.gmane.org>
In-Reply-To: <ft61c4$ea6$1@ger.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org
Subject: Re: Trouble with IPFW or TCP?
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, 04 Apr 2008 22:23:41 -0000
Ivan Voras wrote:
> Ian Smith wrote:
>
>> That's pretty well described under keep-state and elsewhere. Good ol'
>> ipfw(8) has yet to let me down, and like Ivan I recall keep-state rules
>> (albeit only for UDP) without any check-state working just fine.
>>
>> Not that any of that helps solve Ivan's problem ..
>
> Thanks for verifying this. I've reread what I posted and I think I
> wasn't clear about one thing: it's not exactly a "hard" problem - as I
> said, connections do get established and apparently they get processed
> (the effects of those HTTPS messages are present). What troubles me is
> that I wouldn't expect that to happen, considering the ipfw log messages
> I've posted. In short, either:
>
> a) The senders (or something in between like a broken router; but note
> that the 7.x machine behind the same infrastructure isn't generating the
> symptomatic log records) keeps sending spurious packets long after the
> TCP session (communication) is actually completed. Someone with better
> knowledge of TCP flows could maybe verify that. HTTPS messages are sent
> every 15 minutes and I'd expect various timers to timeout the connection
> if the ACKs aren't processed.
>
> b) The receiving side somehow bounces the packets around, reinserting
> them after the TCP session is done. This would be weird. The server from
> which the posted logs and traces come from isn't running anything
> special like netgraph, bpf applications, routed. It's basically a web
> server.
>
>
>
check that the ipfw dynamic sessions are not generating keepalives..
they should stop doing so when they see the FIN, but if they don't
see it, they could generate keepalives forever.
(there is an option to disable this)
From owner-freebsd-net@FreeBSD.ORG Sat Apr 5 08:12:58 2008
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 784ED1065674
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 08:12:58 +0000 (UTC)
(envelope-from frenchy@driven-monkey.com)
Received: from titania.wxnz.net (titania.wxnz.net [58.28.4.13])
by mx1.freebsd.org (Postfix) with ESMTP id 3BEF28FC1C
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 08:12:57 +0000 (UTC)
(envelope-from frenchy@driven-monkey.com)
Received: from mini-tank.local (ip-118-90-33-186.xdsl.xnet.co.nz
[118.90.33.186])
by titania.wxnz.net (Postfix) with ESMTP id 4AF305E859A
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 20:50:08 +1300 (NZDT)
From: frenchy@driven-monkey.com
To: freebsd-net@freebsd.org
Date: Sat, 5 Apr 2008 20:50:09 +1300
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200804052050.09531.frenchy@driven-monkey.com>
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Initialising networking protocol
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, 05 Apr 2008 08:12:58 -0000
Hi All,
I am working on implementing MPLS in FreeBSD at the moment. I was wondering if
anyone had some links to any references I could use, or recommend any books I
can use to help me in that. Failing that, I am struggling with trying to work
out how to initialise my MPLS protocol in the netisr stack, so the mpls_input
function I am writing is called when an MPLS packet is received.
Thanks for any help,
Ryan French.
From owner-freebsd-net@FreeBSD.ORG Sat Apr 5 09:20:03 2008
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 9BD36106566C;
Sat, 5 Apr 2008 09:20:03 +0000 (UTC)
(envelope-from smithi@nimnet.asn.au)
Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143])
by mx1.freebsd.org (Postfix) with ESMTP id 407B08FC17;
Sat, 5 Apr 2008 09:20:00 +0000 (UTC)
(envelope-from smithi@nimnet.asn.au)
Received: from localhost (smithi@localhost)
by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id TAA12951;
Sat, 5 Apr 2008 19:19:52 +1000 (EST)
(envelope-from smithi@nimnet.asn.au)
Date: Sat, 5 Apr 2008 19:19:51 +1000 (EST)
From: Ian Smith <smithi@nimnet.asn.au>
To: Julian Elischer <julian@elischer.org>
In-Reply-To: <47F667FA.6020208@elischer.org>
Message-ID: <Pine.BSF.3.96.1080405180234.6389B-100000@gaia.nimnet.asn.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: freebsd-net@freebsd.org, Ivan Voras <ivoras@freebsd.org>
Subject: Re: Trouble with IPFW or TCP?
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, 05 Apr 2008 09:20:03 -0000
On Fri, 4 Apr 2008, Julian Elischer wrote:
> Ian Smith wrote:
> > On Thu, 3 Apr 2008, Julian Elischer wrote:
> >
> > > Not that I have known... keep-state does not (and never has) include
> > > an implicit check-state.
> >
> > Sorry (and surprised!) to have to differ, but you MADE me read the code!
>
> yep you are right..
> boy is that ever a broken feature..
> there is no way to set a new session without leaping off into the
> previously declared sessions.
>
> I just tested it and it does as you say...
>
> 00001 166 17438 skipto 1000 tcp from any to 10.2.2.2 keep-state
> 00002 9 886 allow ip from any to any
> 01000 166 17438 count log ip from any to any
> 01001 93 7727 count log tcp from any to 10.2.2.2
> 01002 73 9711 count log tcp from 10.2.2.2 to any
> 65535 166 17438 allow ip from any to any
>
> I'm stunned..
> boy is that ever a broken feature..
> There is no way to set a new session without leaping off into the
> previously declared sessions.
>
> I also have to check my firewalls to see if I'm hitting unexpeced
> behaviour.
I don't see why you think it's broken? Apart from obvious efficiency of
having a check-state rule earlier, to get on with matching this packet
against existing dynamic rules without wading through intervening rules,
state is still only checked once; like it says, the O_PROBE_STATE opcode
only causes a state check at the first check-state, keep-state or limit
rule (encountered); any others found then become a short-path NOP.
Personally I like to do traffic accounting before any packet is whisked
off to be dealt with (and accounted by) any keep-state rules, though as
your example shows that can be done afterwards, if not piped or such.
But I can't see why you ever wouldn't want to check the existing state
of any src-addr/src-port <-> dst-addr/dst-port packet before attempting
to add a new dynamic rule for that same session?
cheers, Ian
> >
> > Bearing in mind I'm reading 5.5 sources - stop me if it's changed - but
> > starting with /usr/sbin/ipfw/ipfw2.c we see that adding check-state just
> > generates an O_CHECK_STATE, while adding keep-state or limit rules first
> > generate an initial O_PROBE_STATE opcode (ignored when listing rules):
> >
> > /*
> > * Now copy stuff into the rule.
> > * If we have a keep-state option, the first instruction
> > * must be a PROBE_STATE (which is generated here).
> > * If we have a LOG option, it was stored as the first command,
> > * and now must be moved to the top of the action part.
> > */
> > dst = (ipfw_insn *)rule->cmd;
> > [..]
> > /*
> > * generate O_PROBE_STATE if necessary
> > */
> > if (have_state && have_state->opcode != O_CHECK_STATE) {
> > fill_cmd(dst, O_PROBE_STATE, 0, 0);
> > dst = next_cmd(dst);
> >
> > then go on to generate the O_KEEP_STATE or O_LIMIT rule as appropriate.
> >
> > Now in /sys/netinet/ip_fw2.c in ipfw_chk circa line 2400 (@5.5) we have:
> >
> > * O_LIMIT and O_KEEP_STATE: these opcodes are
> > * not real 'actions', and are stored right
> > * before the 'action' part of the rule.
> > * These opcodes try to install an entry in the
> > * state tables; if successful, we continue with
> > * the next opcode (match=1; break;), otherwise
> > * the packet * must be dropped
> > * ('goto done' after setting retval);
> > *
> > * O_PROBE_STATE and O_CHECK_STATE: these opcodes
> > * cause a lookup of the state table, and a jump
> > * to the 'action' part of the parent rule
> > * ('goto check_body') if an entry is found, or
> > * (CHECK_STATE only) a jump to the next rule if
> > * the entry is not found ('goto next_rule').
> > * The result of the lookup is cached to make
> > * further instances of these opcodes are
> > * effectively NOPs.
> > */
> > case O_LIMIT:
> > case O_KEEP_STATE:
> > if (install_state(f,
> > (ipfw_insn_limit *)cmd, args)) {
> > retval = IP_FW_PORT_DENY_FLAG;
> > goto done; /* error/limit violation */
> > }
> > match = 1;
> > break;
> >
> > case O_PROBE_STATE:
> > case O_CHECK_STATE:
> > /*
> > * dynamic rules are checked at the first
> > * keep-state or check-state occurrence,
> > * with the result being stored in dyn_dir.
> > * The compiler introduces a PROBE_STATE
> > * instruction for us when we have a
> > * KEEP_STATE (because PROBE_STATE needs
> > * to be run first).
> > */
> > if (dyn_dir == MATCH_UNKNOWN &&
> > (q = lookup_dyn_rule(&args->f_id,
> > &dyn_dir, proto == IPPROTO_TCP ?
> > L3HDR(struct tcphdr, ip) : NULL))
> > != NULL) {
> > /*
> > * Found dynamic entry, update stats
> > * and jump to the 'action' part of
> > * the parent rule.
> > */
> > q->pcnt++;
> > q->bcnt += pktlen;
> > f = q->rule;
> > cmd = ACTION_PTR(f);
> > l = f->cmd_len - f->act_ofs;
> > IPFW_DYN_UNLOCK();
> > goto check_body;
> > }
> > /*
> > * Dynamic entry not found. If CHECK_STATE,
> > * skip to next rule, if PROBE_STATE just
> > * ignore and continue with next opcode.
> > */
> > if (cmd->opcode == O_CHECK_STATE)
> > goto next_rule;
> > match = 1;
> > break;
> >
> > So indeed each rule with keep-state or limit options does the same probe
> > as a check-state in the first opcode, before then installing or checking
> > state in the subsequent opcode. Or so it reads to an ancient neophyte ..
> >
> > > I think the document is talking about the lifetime.
> > > Each time a keep-state or check-state or limit is hit,
> > > the TTL is kicked.
> >
> > That's pretty well described under keep-state and elsewhere. Good ol'
> > ipfw(8) has yet to let me down, and like Ivan I recall keep-state rules
> > (albeit only for UDP) without any check-state working just fine.
> >
> > Not that any of that helps solve Ivan's problem ..
> >
> > cheers, Ian
> >
> > _______________________________________________
> > 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 Sat Apr 5 14:37:07 2008
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 376F91065670
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 14:37:07 +0000 (UTC)
(envelope-from bms@incunabulum.net)
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com
[66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 773808FC12
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 14:37:06 +0000 (UTC)
(envelope-from bms@incunabulum.net)
Received: from compute1.internal (compute1.internal [10.202.2.41])
by out1.messagingengine.com (Postfix) with ESMTP id 2C9FCE7F22
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 10:37:06 -0400 (EDT)
Received: from heartbeat1.messagingengine.com ([10.202.2.160])
by compute1.internal (MEProxy); Sat, 05 Apr 2008 10:37:06 -0400
X-Sasl-enc: ll3Suby99k+E7zbMw0dx3nJV5yTTzzeyybAQjpyKxvuN 1207406225
Received: from empiric.lon.incunabulum.net
(82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254])
by mail.messagingengine.com (Postfix) with ESMTPSA id C1B4D11110
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 10:37:05 -0400 (EDT)
Message-ID: <47F78E90.1000706@incunabulum.net>
Date: Sat, 05 Apr 2008 15:37:04 +0100
From: Bruce M Simpson <bms@incunabulum.net>
User-Agent: Thunderbird 2.0.0.12 (X11/20080405)
MIME-Version: 1.0
To: FreeBSD-Net mailing list <freebsd-net@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: getifaddrs() scalability
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, 05 Apr 2008 14:37:07 -0000
Just off the top of my head...
=2E..has anyone run into problems with the scalability of this call?
One of the XORP users needs to create =BB1000 interfaces in Linux, and I'=
m=20
wondering if any FreeBSD users need to create that amount of network=20
interfaces.
As such the getifaddrs() call is likely to get slow in that scenario, as =
it uses a linked list.
cheers
BMS
From owner-freebsd-net@FreeBSD.ORG Sat Apr 5 16:52:59 2008
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 5D946106566C
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 16:52:59 +0000 (UTC)
(envelope-from max@love2party.net)
Received: from moutng.kundenserver.de (moutng.kundenserver.de
[212.227.126.171])
by mx1.freebsd.org (Postfix) with ESMTP id C96598FC15
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 16:52:58 +0000 (UTC)
(envelope-from max@love2party.net)
Received: from vampire.homelinux.org (dslb-088-064-181-110.pools.arcor-ip.net
[88.64.181.110])
by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis)
id 0ML31I-1JiBdR3txn-0003py; Sat, 05 Apr 2008 18:52:58 +0200
Received: (qmail 6594 invoked from network); 5 Apr 2008 16:51:58 -0000
Received: from myhost.laiers.local (192.168.4.151)
by mx.laiers.local with SMTP; 5 Apr 2008 16:51:58 -0000
From: Max Laier <max@love2party.net>
Organization: FreeBSD
To: freebsd-net@freebsd.org
Date: Sat, 5 Apr 2008 18:50:34 +0200
User-Agent: KMail/1.9.9
References: <47F78E90.1000706@incunabulum.net>
In-Reply-To: <47F78E90.1000706@incunabulum.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200804051850.34371.max@love2party.net>
X-Provags-ID: V01U2FsdGVkX1+ehwkze/ApFOw4xyfb8hRJmr7EXTHGFGUDUBo
Q9Qbj8DCmxvOS7lqpfUJfaq1pVZO8bX8ryoyhT6eBUWVM7Rc/X
FYEUX8H0tjtN8gSNQvHNg==
Cc: Bruce M Simpson <bms@incunabulum.net>
Subject: Re: getifaddrs() scalability
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, 05 Apr 2008 16:52:59 -0000
On Saturday 05 April 2008 16:37:04 Bruce M Simpson wrote:
> Just off the top of my head...
> ...has anyone run into problems with the scalability of this call?
>
> One of the XORP users needs to create =BB1000 interfaces in Linux, and
> I'm wondering if any FreeBSD users need to create that amount of
> network interfaces.
>
> As such the getifaddrs() call is likely to get slow in that scenario,
> as it uses a linked list.
I'm not sure what you are trying to achieve. getifaddrs is the API to get=
=20
a complete and consistent snapshot of all currently configured addresses=20
and I don't think there is a better way to represent that then a linked=20
list. If you need to do lookups in userland you should build your own=20
data structure off of that list. You can use a PF_ROUTE socket to watch=20
for changes and modify your view accordingly.
=2D-=20
/"\ Best regards, | mlaier@freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
From owner-freebsd-net@FreeBSD.ORG Sat Apr 5 17:44:26 2008
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 B43981065670
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 17:44:26 +0000 (UTC)
(envelope-from Jinmei_Tatuya@isc.org)
Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162])
by mx1.freebsd.org (Postfix) with ESMTP id 873BF8FC0C
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 17:44:26 +0000 (UTC)
(envelope-from Jinmei_Tatuya@isc.org)
Received: from dhcp-191.sql1.isc.org (unknown
[IPv6:2001:4f8:3:bb:5177:2da0:2a07:637])
by mon.jinmei.org (Postfix) with ESMTP id 39F9133C2E;
Sat, 5 Apr 2008 10:44:26 -0700 (PDT)
Date: Sat, 05 Apr 2008 10:44:24 -0700
Message-ID: <m2lk3si4cn.wl%Jinmei_Tatuya@isc.org>
From: Jinmei_Tatuya@isc.org
To: Max Laier <max@love2party.net>
In-Reply-To: <200804051850.34371.max@love2party.net>
References: <47F78E90.1000706@incunabulum.net>
<200804051850.34371.max@love2party.net>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Cc: freebsd-net@freebsd.org, Bruce M Simpson <bms@incunabulum.net>
Subject: Re: getifaddrs() scalability
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, 05 Apr 2008 17:44:26 -0000
At Sat, 5 Apr 2008 18:50:34 +0200,
Max Laier <max@love2party.net> wrote:
> > As such the getifaddrs() call is likely to get slow in that scenario,
> > as it uses a linked list.
>
> I'm not sure what you are trying to achieve. getifaddrs is the API to get
> a complete and consistent snapshot of all currently configured addresses
> and I don't think there is a better way to represent that then a linked
> list. If you need to do lookups in userland you should build your own
> data structure off of that list. You can use a PF_ROUTE socket to watch
> for changes and modify your view accordingly.
If getifaddrs() is used to search for something, the linear aspect
can be a serious overhead that could be actually avoided. For
example, the current implementation of if_indextoname() calls
getaddrinfo() and search the returned list of ifaddrs for the
interface name that matches the given index. It requires a linear
order regarding the number of interfaces (and addresses), but it could
in theory be done in O(1).
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
From owner-freebsd-net@FreeBSD.ORG Sat Apr 5 17:53:25 2008
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 7A988106564A
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 17:53:25 +0000 (UTC)
(envelope-from julian@elischer.org)
Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net
[216.240.47.249])
by mx1.freebsd.org (Postfix) with ESMTP id 493828FC17
for <freebsd-net@freebsd.org>; Sat, 5 Apr 2008 17:53:25 +0000 (UTC)
(envelope-from julian@elischer.org)
Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160)
by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP;
Sat, 05 Apr 2008 13:41:01 -0700
Received: from julian-mac.elischer.org (localhost [127.0.0.1])
by idiom.com (Postfix) with ESMTP id 181CE2D6011;
Sat, 5 Apr 2008 10:53:22 -0700 (PDT)
Message-ID: <47F7BC95.7090907@elischer.org>
Date: Sat, 05 Apr 2008 10:53:25 -0700
From: Julian Elischer <julian@elischer.org>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Ian Smith <smithi@nimnet.asn.au>
References: <Pine.BSF.3.96.1080405180234.6389B-100000@gaia.nimnet.asn.au>
In-Reply-To: <Pine.BSF.3.96.1080405180234.6389B-100000@gaia.nimnet.asn.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org, Ivan Voras <ivoras@freebsd.org>
Subject: Re: Trouble with IPFW or TCP?
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, 05 Apr 2008 17:53:25 -0000
Ian Smith wrote:
>
> I don't see why you think it's broken? Apart from obvious efficiency of
> having a check-state rule earlier, to get on with matching this packet
> against existing dynamic rules without wading through intervening rules,
> state is still only checked once; like it says, the O_PROBE_STATE opcode
> only causes a state check at the first check-state, keep-state or limit
> rule (encountered); any others found then become a short-path NOP.
>
> Personally I like to do traffic accounting before any packet is whisked
> off to be dealt with (and accounted by) any keep-state rules, though as
> your example shows that can be done afterwards, if not piped or such.
>
> But I can't see why you ever wouldn't want to check the existing state
> of any src-addr/src-port <-> dst-addr/dst-port packet before attempting
> to add a new dynamic rule for that same session?
My firewall rules a re very complex and I could want to change the
action stored with a particular session..
trivial example:
Assuming that keep-state did NOT do a check state:
10 check-state
100 skipto 1000 tcp from any to any in $inside keep-state
[...]
1000 skipto 2000 tcp from any to any iplen 1480-9200 keep-state
[...]
2000 count log ip from any to any
[....]
now I change the action for jumbo packets for accounting purposes to
go straight to 2000
with implicit check state..
1/ I have no way of changing what to do as the keep-state on 100 will
never bee done
2/ I have no idea what happens when you effectlvely do a
"1000 skipto 1000".