From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 07:21:44 2008 Return-Path: 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 ; 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 ; 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 To: Brooks Davis 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, FreeBSD Net 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hans Petter Selasky 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: freebsd-hackers@freebsd.org, FreeBSD Net 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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" User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: Eugene Grosbein 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 , Brooks Davis , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: 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 X-X-Sender: robert@fledge.watson.org To: Alexander Motin 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 To: "Bruce M. Simpson" 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 , Brooks Davis , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ) id 1JfvVD-000FZu-Tg; Sun, 30 Mar 2008 11:15:07 +0000 Message-Id: <9C5282E0-B44F-4A07-A606-1783D7725B5A@elvandar.org> From: Remko Lodder To: Eugene Grosbein 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 , Brooks Davis , "Bruce M. Simpson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Robert Watson 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 To: Remko Lodder 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 , Brooks Davis , "Bruce M. Simpson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 To: Remko Lodder 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 , Brooks Davis , "Bruce M. Simpson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 To: Remko Lodder 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 , Brooks Davis , "Bruce M. Simpson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 X-X-Sender: robert@fledge.watson.org To: Alexander Motin 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 To: Remko Lodder 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 , Brooks Davis , "Bruce M. Simpson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Eugene Grosbein 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 , Remko Lodder , Brooks Davis , "Bruce M. Simpson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Eugene Grosbein 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 , Remko Lodder , Brooks Davis , "Bruce M. Simpson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Eugene Grosbein 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 , Remko Lodder , Brooks Davis , "Bruce M. Simpson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Eugene Grosbein 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 , Remko Lodder , Brooks Davis , "Bruce M. Simpson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Eugene Grosbein 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 , Remko Lodder , Brooks Davis , "Bruce M. Simpson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 -iface 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: 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 User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, dhartmei@FreeBSD.org, Max Laier Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pavlin Radoslavov 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 To: Sam Leffler 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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: Date: Tue, 1 Apr 2008 02:23:03 +0300 From: "Simas Kvilius" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hans Petter Selasky 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 Subject: Re: Multiple netgraph threads X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, FreeBSD 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: Subject: Multiple netgraph threads X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Robert Watson 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 Subject: Re: Multiple netgraph threads X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 X-X-Sender: robert@fledge.watson.org To: Alexander Motin 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 Subject: Re: Multiple netgraph threads X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 To: freebsd-hackers@freebsd.org, FreeBSD Net 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 Subject: Re: Multiple netgraph threads X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 X-X-Sender: robert@fledge.watson.org To: Alexander Motin 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 Subject: Re: Multiple netgraph threads X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 To: Anthony Pankov 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 - 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: 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 ; 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 ; 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 ; 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 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 To: jhb@freebsd.org Cc: =?ISO-8859-1?Q?Thomas_Nystr=F6m?= , 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: 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 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) Message-ID: <1493139437.20080401180529@mail.ru> To: Rui Paulo 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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: Date: Tue, 1 Apr 2008 18:27:46 +0300 From: "Simas Kvilius" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, 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: 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 ; 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 ; 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 ; 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 ; Tue, 01 Apr 2008 16:08:50 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Mark Atkinson Date: Tue, 01 Apr 2008 09:08:35 -0700 Lines: 47 Message-ID: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; Tue, 01 Apr 2008 17:57:54 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Mark Atkinson Date: Tue, 01 Apr 2008 10:57:46 -0700 Lines: 52 Message-ID: References: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 To: Mark Atkinson Message-ID: <20080401191246.GA1491@fnop.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: Rui Paulo 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; Tue, 01 Apr 2008 19:28:16 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Mark Atkinson Date: Tue, 01 Apr 2008 12:28:06 -0700 Lines: 108 Message-ID: References: <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 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 User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Mark Atkinson References: <20080401191246.GA1491@fnop.net> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 To: Andre Oppermann Message-ID: <20080401202005.GB1491@fnop.net> References: <20080401191246.GA1491@fnop.net> <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 Cc: freebsd-net@freebsd.org, rpaulo@freebsd.org, Mark Atkinson 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 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 User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Rui Paulo References: <20080401191246.GA1491@fnop.net> <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 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 User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Mark Atkinson References: <20080401191246.GA1491@fnop.net> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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" User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: Andre Oppermann References: <20080401191246.GA1491@fnop.net> <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 - 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: 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 User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Matthias Apitz 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: 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 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> <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 , Sam Leffler , Benjamin Close , Alphons Fonz van Werven , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: > > > > > > > >>>> 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 > > > > > > > >>> 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 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: 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 ; 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 ; 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 ; 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" 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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: 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 ; 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 ; 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 ; 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 ; Wed, 02 Apr 2008 15:08:28 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Mark Atkinson Date: Wed, 02 Apr 2008 08:08:18 -0700 Lines: 25 Message-ID: References: <20080401191246.GA1491@fnop.net> <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 15:33:20 2008 Return-Path: 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 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 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 - 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: 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 ; 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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: FreeBSD-Net mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 mtu 1500 driver flags look like this when injection is NOT OK: fxp0: flags=8843 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: 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 ; 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 ; 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 ; 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 To: Bruce M Simpson 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 mtu > 1500 > > driver flags look like this when injection is NOT OK: > fxp0: flags=8843 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: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; Thu, 03 Apr 2008 23:34:27 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 04 Apr 2008 01:34:07 +0200 Lines: 262 Message-ID: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 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 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 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 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; 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; 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; 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; 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; 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; 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; 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; 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; 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; syncache_expand: Segment=20 failed SYNCOOKIE authentication, segment rejected (probably spoofed) Mar 26 00:38:49 my.ip kernel: 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; 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; 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: 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 ; 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 ; 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 ) 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 To: Ivan Voras Message-ID: <20080403234059.GA53417@owl.midgard.homeip.net> Mail-Followup-To: Ivan Voras , freebsd-net@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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] -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 23:52:34 2008 Return-Path: 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 ; 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 ; 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 ; 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 ; Thu, 03 Apr 2008 23:52:28 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 04 Apr 2008 01:52:17 +0200 Lines: 73 Message-ID: References: <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 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 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 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 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; 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; 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; 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; 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; 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; 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; 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; 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; 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; syncache_expand: Segment > failed SYNCOOKIE authentication, segment rejected (probably spoofed) > Mar 26 00:38:49 my.ip kernel: 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; 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; 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: 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ivan Voras References: <20080403234059.GA53417@owl.midgard.homeip.net> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Julian Elischer In-Reply-To: <47F5748F.9050207@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Ivan Voras 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ian Smith References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ivan Voras 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; Fri, 04 Apr 2008 08:52:04 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 04 Apr 2008 10:51:47 +0200 Lines: 56 Message-ID: References: <20080403234059.GA53417@owl.midgard.homeip.net> <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; Fri, 04 Apr 2008 09:09:27 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 04 Apr 2008 11:09:19 +0200 Lines: 35 Message-ID: References: <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 To: Julian Elischer In-Reply-To: <47F5B17E.5000304@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Ivan Voras 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ian Smith References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ivan Voras 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: "Ronald F. Guilmette" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: "Ronald F. Guilmette" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; Fri, 04 Apr 2008 20:00:10 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 04 Apr 2008 21:59:56 +0200 Lines: 57 Message-ID: References: <47F5B17E.5000304@elischer.org> 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: X-Enigmail-Version: 0.95.6 Sender: news 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ) 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 To: freebsd-net@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: seraphi.lord@gmail.com References: <47D860AC.6030707@freebsd.org> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > wrote: >> On 3/12/08, Andre Oppermann 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: 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 ; 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 ; 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 ; Fri, 04 Apr 2008 21:22:46 +0100 Message-ID: <021701c89691$a3306020$3d010a0a@multiplay.co.uk> From: "Steven Hartland" To: "s3raphi" , References: <47D860AC.6030707@freebsd.org> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" > > 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: 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 ; 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 ; 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" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Steven Hartland In-Reply-To: <021701c89691$a3306020$3d010a0a@multiplay.co.uk> Message-ID: <20080404204927.Y66744@maildrop.int.zabbadoz.net> References: <47D860AC.6030707@freebsd.org> <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" >> >> 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: 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ivan Voras References: <47F5B17E.5000304@elischer.org> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 To: Julian Elischer In-Reply-To: <47F667FA.6020208@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Ivan Voras 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.12 (X11/20080405) MIME-Version: 1.0 To: FreeBSD-Net mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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: From: Jinmei_Tatuya@isc.org To: Max Laier 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2008 17:44:26 -0000 At Sat, 5 Apr 2008 18:50:34 +0200, Max Laier 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: 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ian Smith References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ivan Voras 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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".