From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 01:18:13 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 EB5F3106566C; Sun, 20 Apr 2008 01:18:13 +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 C51488FC16; Sun, 20 Apr 2008 01:18:13 +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 m3K1IDZ0047897; Sun, 20 Apr 2008 01:18:13 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3K1IDVk047893; Sun, 20 Apr 2008 01:18:13 GMT (envelope-from linimon) Date: Sun, 20 Apr 2008 01:18:13 GMT Message-Id: <200804200118.m3K1IDVk047893@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/122875: [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) (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: Sun, 20 Apr 2008 01:18:14 -0000 Old Synopsis: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) New Synopsis: [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) (regression) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Apr 20 01:17:35 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122875 From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 02:45: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 5EE2B106566B for ; Sun, 20 Apr 2008 02:45:30 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from gtcomm.net (web.gtcomm.net [72.10.164.67]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0BB8FC1B for ; Sun, 20 Apr 2008 02:45:29 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from [192.168.1.3] (c-76-108-179-28.hsd1.fl.comcast.net [76.108.179.28]) by gtcomm.net (8.12.20/8.12.10) with ESMTP id m3K1leBM017996; Sat, 19 Apr 2008 22:47:41 -0300 Message-ID: <480AA135.6070406@gtcomm.net> Date: Sat, 19 Apr 2008 21:49:41 -0400 From: Paul User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Haddad References: <944074f30804191423v93d1acet9246269e4072d46a@mail.gmail.com> In-Reply-To: <944074f30804191423v93d1acet9246269e4072d46a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Network Instability when upgrading to 4GB of RAM 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, 20 Apr 2008 02:45:30 -0000 I had some similar issues for some reason.. Check the output of netstat -m and see if the mbuf clusters in use line if the total is anywhere near the max. Mine was maxing out and causing some very weird problems with no errors in any log anywhere. Paul Haddad wrote: > Hi All, > I've got the below system setup that has so far been very stable when > running with 2GB of RAM. I've recently been attempting to upgrade it to 4GB > of ram (using 4 DIMMs vs the current 2). The problem is that within a few > hours of running with the 4GB config I start getting odd network errors. > There's nothing in the logs, but incoming ssh connections start failing > with errors like (Bad Packet Length) and things like ftp and nfs all fail in > odd ways. > > As far as I can tell the RAM is fine, I've ran it through a few diff RAM > testing utilities and it all comes out fine. I've also successfully run > both sets of DIMMs by themselves, so at least it seems that this isn't a > hardware problem. > > I'd appreciate any suggestions on tracking down the problem, again the logs > don't seem to have any useful info on it. > From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 02:50:15 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 E6EC51065670 for ; Sun, 20 Apr 2008 02:50:15 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 7CBFE8FC1B for ; Sun, 20 Apr 2008 02:50:15 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m3K2oCpw014619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Apr 2008 12:50:13 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m3K2oB8G013679; Sun, 20 Apr 2008 12:50:11 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m3K2oBNT013678; Sun, 20 Apr 2008 12:50:11 +1000 (EST) (envelope-from peter) Date: Sun, 20 Apr 2008 12:50:11 +1000 From: Peter Jeremy To: Mark Hills Message-ID: <20080420025010.GJ73016@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KM+e2hnYAO+MCJ5e" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 20 Apr 2008 02:50:16 -0000 --KM+e2hnYAO+MCJ5e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 19, 2008 at 03:27:28PM +0100, Mark Hills wrote: >I'm are having a trouble with TCP connections being dropped with "read:=20 >Operation timed out". What is unusual is that this is happening right in= =20 >the middle of sending a steady stream of data with no network congestion. Can you give some more detail about your hardware (speed, CPU, available RAM, UP or SMP) and the application (roughly what does the core of the code look like and is it single-threaded/multi-threaded and/or multi-process). >systat doesn't show problems inbound; all packets received are delivered t= o=20 >the upper layer. But on outbound, there is consistent 'output drops': > > IP Output >7028 total packets sent >7028 - generated locally > 314 - output drops > >As the number of outbound connections increases, the 'output drops'=20 >increases to around 10% of the total packets sent and maintains that ratio= =2E=20 >There's no problems with network capacity. 'output drops' (ips_odropped) means that the kernel is unable to buffer the write (no mbufs or send queue full). Userland should see ENOBUFS unless the error was triggered by a fragmentation request. I can't explain the problem but it definitely looks like a resource starvation issue within the kernel. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --KM+e2hnYAO+MCJ5e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkgKr2IACgkQ/opHv/APuIdX3QCfZSeBTQCmnIgxUFN/tKD+7foS 2cMAoIb02k7r5FD4J6ELBWg7gnURQma3 =jQEl -----END PGP SIGNATURE----- --KM+e2hnYAO+MCJ5e-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 03:15:50 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 412121065671 for ; Sun, 20 Apr 2008 03:15:50 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate2.pacific.net.sg (smtpgate2.pacific.net.sg [203.120.90.32]) by mx1.freebsd.org (Postfix) with SMTP id 6FDEE8FC16 for ; Sun, 20 Apr 2008 03:15:49 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: (qmail 31791 invoked from network); 20 Apr 2008 02:49:06 -0000 Received: from bb116-14-167-83.singnet.com.sg (HELO P2120.somewherefaraway.com) (oceanare@116.14.167.83) by smtpgate2.pacific.net.sg with ESMTPA; 20 Apr 2008 02:49:06 -0000 Message-ID: <480A867D.5070901@pacific.net.sg> Date: Sun, 20 Apr 2008 07:55:41 +0800 From: Erich Dollansky User-Agent: Thunderbird 2.0.0.6 (X11/20070826) MIME-Version: 1.0 To: Paul Haddad References: <944074f30804191423v93d1acet9246269e4072d46a@mail.gmail.com> In-Reply-To: <944074f30804191423v93d1acet9246269e4072d46a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Network Instability when upgrading to 4GB of RAM 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, 20 Apr 2008 03:15:50 -0000 Hi, Paul Haddad wrote: > I've got the below system setup that has so far been very stable when > running with 2GB of RAM. I've recently been attempting to upgrade it to 4GB > of ram (using 4 DIMMs vs the current 2). The problem is that within a few > hours of running with the 4GB config I start getting odd network errors. > There's nothing in the logs, but incoming ssh connections start failing > with errors like (Bad Packet Length) and things like ftp and nfs all fail in > odd ways. > > As far as I can tell the RAM is fine, I've ran it through a few diff RAM > testing utilities and it all comes out fine. I've also successfully run > both sets of DIMMs by themselves, so at least it seems that this isn't a > hardware problem. > it still could be a contact problem with the RAM. Can you create some kind of load to force all 4GB of being actually used without any network activity. Maybe even with the network 'unplugged'? Do you have ECC RAM? Erich From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 04:22:09 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 9FD8E1065673; Sun, 20 Apr 2008 04:22:09 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by mx1.freebsd.org (Postfix) with ESMTP id 7FEEC8FC22; Sun, 20 Apr 2008 04:22:09 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 1JnQIt-0006Az-CE; Sun, 20 Apr 2008 03:33:23 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp3.email.verio.net with esmtp id 1JnQIt-00065f-2T; Sun, 20 Apr 2008 03:33:23 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id CFAE58E298; Sat, 19 Apr 2008 22:33:22 -0500 (CDT) Date: Sat, 19 Apr 2008 22:33:22 -0500 From: David DeSimone To: Oliver Lehmann Message-ID: <20080420033322.GA16657@verio.net> References: <20080419195643.a5187267.oliver@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20080419195643.a5187267.oliver@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: net@freebsd.org Subject: Re: problems interacting on TCP level with K5JB 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, 20 Apr 2008 04:22:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oliver Lehmann wrote: > > 19:22:31.003359 IP (tos 0x10, ttl 64, id 730, offset 0, flags [DF], proto TCP (6), length 60) 10.1.1.1.54398 > 10.1.1.2.telnet: S, cksum 0xceef (correct), 1217851052:1217851052(0) win 65535 > > 19:22:31.301210 IP (tos 0x0, ttl 254, id 25, offset 0, flags [none], proto TCP (6), length 44) 10.1.1.2.telnet > 10.1.1.1.54398: S, cksum 0xe752 (correct), 2405380816:2405380816(0) ack 4294967213 win 2048 > > 19:22:31.301234 IP (tos 0x0, ttl 64, id 747, offset 0, flags [DF], proto TCP (6), length 40) 10.1.1.1.54398 > 10.1.1.2.telnet: R, cksum 0xc598 (correct), 4294967213:4294967213(0) win 0 The SYN-ACK packet in response contains an ACK for sequence 4294967213, but that was not the sequence sent by the initial SYN (it was 1217851052). The RST shows that FreeBSD doesn't know what your system is talking about. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFICrmCFSrKRjX5eCoRAl+lAJ97gDxSyCopVusgVLN6K9Vm2rtA1QCgoGUJ F8HufJzE3Ur+EOOAnL0U+10= =cDMN -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 09:20:22 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 58A1C106564A for ; Sun, 20 Apr 2008 09:20:22 +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 F3B138FC17 for ; Sun, 20 Apr 2008 09:20: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 614BB46B7B; Sun, 20 Apr 2008 05:20:21 -0400 (EDT) Date: Sun, 20 Apr 2008 10:20:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kip Macy In-Reply-To: Message-ID: <20080420101315.G67663@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-net@freebsd.org" Subject: Re: MFC of TOE support to RELENG_7 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, 20 Apr 2008 09:20:22 -0000 On Thu, 17 Apr 2008, Kip Macy wrote: > I would like to MFC TOE and RDMA support in the last week of May / first > week of June. My primary objective is that it be present in 7.1. The re team > has not yet decided when the freeze date for 7.1 will be, so I may end up > asking to do it earlier. I'm not entirely opposed to MFC'ing TOE this summer, but I notice that several parts of what is intended to be a new public device driver interface remain entirely undocumented. A necessary step before this work can be properly reviewed is for it to be properly documented. A such, while not in principle unreasonable, I think you should consider the proposed MFC schedule somewhat hypothetical until that issue is resolved, allowing a more critical (and hence substantive) review of the interface. I greatly appreciate, BTW, the time you've put into working to resolve the ABI issues raised on arch@, etc. I hope to have a chance to look at them in more detail in the next couple of weeks and provide feedback. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 09:27: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 79BC2106564A; Sun, 20 Apr 2008 09:27:16 +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 4D3FB8FC12; Sun, 20 Apr 2008 09:27:16 +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 ED43A46B03; Sun, 20 Apr 2008 05:27:15 -0400 (EDT) Date: Sun, 20 Apr 2008 10:27:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Brooks Davis In-Reply-To: <20080418152827.GA20382@lor.one-eyed-alien.net> Message-ID: <20080420102047.R67663@fledge.watson.org> References: <490341.95478.qm@web33501.mail.mud.yahoo.com> <20080418152827.GA20382@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, vijay singh Subject: Re: Regarding if_alloc() 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, 20 Apr 2008 09:27:16 -0000 On Fri, 18 Apr 2008, Brooks Davis wrote: > On Thu, Apr 17, 2008 at 06:35:23PM -0700, vijay singh wrote: >> Hi all. How do we avoid a race in populating the ifindex_table? Id this is >> a TODO, as it seems from the code below, would it be acceptable if I wrote >> a patch and reused the ifnet_lock [IFNET_WLOCK, IFNET_WUNLOCK]? > > Locking if_index management with ifnet_lock should be ok. Ideally we should > probably be using ALLOC_UNR(9) to manage if_indexes instead of this rather > expensive loop. > > Be aware, that if_index generation is least of the issues in this area. The > if_grow() call is much riskier since it changes the value of the global > ifnet pointer which I'm not sure we can afford to lock. It would be worth > experimenting with rmlocks to see what the impact if of locking would be. > > I'm serious tempted to kill if_grow in favor of some sort of if_index_max > tunable. I've seen a number of reports of panics that may well be traceable to races in if_index handling, and have looked a bit at possible fixes. Quite a few uses of if_index are inherently racy, as they rely on stability of the index value, which of course can't be guaranteed with removable interfaces. I think a reasonable interim fix would be to protect all use of the byindex arrays using the ifnet lock, but remember that the read methods, not just the write methods, need protection, and as such should move from being macros in if_var.h to functions in if.c. if_grow is probably OK if this is done right, but it will need to be set up to drop the lock, grow, re-aquire, and re-validate assumptions (i.e., repeat the search for a free index and loop if it fails to find one). Once the read methods are using the lock also, we should seriously consider converting it to an rwlock. We can probably also un-publicize at least one of the byindex lookup routines (the dev lookup, which is needed only in if.c). This would prevent races on modifying and evaluating the index array, but not on disappearing cdevs and ifnets, which are a separate problem, and one that probably is exercised significanty less. The reports I've seen appear to have only to do with pulling the array out from other consumers while in use. Robert N M Watson Computer Laboratory University of Cambridge > > -- Brooks > >> if_alloc(u_char type) >> { >> struct ifnet *ifp; >> >> ifp = malloc(sizeof(struct ifnet), M_IFNET, M_WAITOK|M_ZERO); >> >> /* >> * Try to find an empty slot below if_index. If we fail, take >> * the next slot. >> * >> * XXX: should be locked! >> */ >> for (ifp->if_index = 1; ifp->if_index <= if_index; ifp->if_index++) { >> if (ifnet_byindex(ifp->if_index) == NULL) >> break; >> } >> >> >> >> >> >> ____________________________________________________________________________________ >> Be a better friend, newshound, and >> know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ >> _______________________________________________ >> 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 Sun Apr 20 09:32:26 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 79451106564A; Sun, 20 Apr 2008 09:32:26 +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 52FAC8FC0A; Sun, 20 Apr 2008 09:32:26 +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 0745A46B03; Sun, 20 Apr 2008 05:32:26 -0400 (EDT) Date: Sun, 20 Apr 2008 10:32:25 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: gnn@freebsd.org In-Reply-To: Message-ID: <20080420102827.U67663@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: zonelimit issues... 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, 20 Apr 2008 09:32:26 -0000 On Fri, 18 Apr 2008, gnn@freebsd.org wrote: > I am wondering why this patch was never committed? > > http://people.freebsd.org/~delphij/misc/patch-zonelimit-workaround > > It does seem to address an issue I'm seeing where processes get into the > zonelimit state through the use of mbufs (a high speed UDP packet receiver) > but even after network pressure is reduced/removed the process never gets > out of that state again. Applying the patch fixed the issue, but I'd like > to have some discussion as to the general merits of the approach. > > Unfortunately the test that currently causes this is tied very tightly to > code at work that I can't share, but I will hopefully be improving mctest to > try to exhibit this behavior. When you take all load off the system, do mbufs and clusters get properly freed back to UMA (as visible in netstat -m)? If not, continuing to bump up against the zonelimit would suggest an mbuf/cluster leak, in which case we need to track that bug. You might consider adding a debugging-only zonelimit waiter count to the UMA zone, and checks/assertions that a wakeup is being generated properly. That is, to confirm that the wakeup is generated when memory is freed up if there are threads waiting. There is at least one as-yet MFC'd fix to the sleep/wakeup code, I believe, that might be relevant here. Is the problem you're reporting on 7.x, or on 8.x? If 8.x, that's probably not it, but if 7.x, it could be. (This same sleep/wakeup bug occasionally leads to wedging of dump(8), I believe). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 09:43:20 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 D6E02106566B; Sun, 20 Apr 2008 09:43:20 +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 ABE778FC1A; Sun, 20 Apr 2008 09:43:20 +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 4293246B7B; Sun, 20 Apr 2008 05:43:20 -0400 (EDT) Date: Sun, 20 Apr 2008 10:43:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Chris Pratt In-Reply-To: <382258DB-13B8-4108-B8F4-157F247A7E4B@hughes.net> Message-ID: <20080420103258.D67663@fledge.watson.org> References: <48087C98.8060600@delphij.net> <382258DB-13B8-4108-B8F4-157F247A7E4B@hughes.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: gnn@freebsd.org, d@delphij.net, net@freebsd.org Subject: Re: zonelimit issues... 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, 20 Apr 2008 09:43:20 -0000 On Fri, 18 Apr 2008, Chris Pratt wrote: > Doesn't 7.0 fix this? I'd like to see an official definitive answer and all > I've been going on is that the problem description is no longer in the > errata. Unfortunately, bugs of this sort don't really "work" that way -- specific bugs are a property of a problem in code (or a problem in design), but what we have right now is a report of a symptom that might reflect zero or more specific bugs. It's unclear that the problem described in errata is the problem you've been experiencing, or that the (at least one) fixed bug with the same symptoms is that one you've been experiencing. For better or worse, the only way to really tell of a generic class of hang or wedging is fixed is to try out the new version and see. In most cases, "zonelimit" wedging reflects one of two things: (1) Inadequate resource allocation to the network stack or some other component, try tuning up the memory tunable for clusters (for example). (2) A memory leak in a network device driver or other network part, which needs to be debugged and fixed. On at least one prior occasion, there has been a bug in UMA itself that lead to getting stuck in zonelimit, and it's not impossible there's a scheduler sleep/wakeup bug that would lead to a similar symptom but for a different reason. In FreeBSD 7-STABLE, you can now use procstat -k to print kernel stack traces of user threads blocked in kernel, which may make diagnosing the general class of problem a bit easier without using a kernel debugger. "zonelimit" is the generic wait channel across all memory type and allocation paths, so doesn't reveal a lot about *which* limit is being hit. Using a kernel stack trace, we can see which specific memory type and allocation context is involved. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 14:23:46 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 844631065673; Sun, 20 Apr 2008 14:23:46 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5A67B8FC25; Sun, 20 Apr 2008 14:23:46 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3KENkKe082929; Sun, 20 Apr 2008 14:23:46 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3KENjUY082925; Sun, 20 Apr 2008 14:23:45 GMT (envelope-from vwe) Date: Sun, 20 Apr 2008 14:23:45 GMT Message-Id: <200804201423.m3KENjUY082925@freefall.freebsd.org> To: neil@hoggarth.me.uk, vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/122928: [em] interface watchdog timeouts and stops receiving packets 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, 20 Apr 2008 14:23:46 -0000 Old Synopsis: em net interface watchdog timeouts and stops receiving packets New Synopsis: [em] interface watchdog timeouts and stops receiving packets State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Sun Apr 20 14:22:02 UTC 2008 State-Changed-Why: Neil: Please additionally provide output of `ifconfig em0' and `sysctl hw.em' Over to maintainer(s). Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sun Apr 20 14:22:02 UTC 2008 Responsible-Changed-Why: Neil: Please additionally provide output of `ifconfig em0' and `sysctl hw.em' Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122928 From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 14:43: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 F2462106566C for ; Sun, 20 Apr 2008 14:43:09 +0000 (UTC) (envelope-from mark@pogo.org.uk) Received: from metheny.ijneb.com (unknown [IPv6:2001:ba8:0:1ba:214:22ff:feb1:2693]) by mx1.freebsd.org (Postfix) with ESMTP id 93A0E8FC17 for ; Sun, 20 Apr 2008 14:43:09 +0000 (UTC) (envelope-from mark@pogo.org.uk) Received: from localhost ([127.0.0.1] ident=mark) by metheny.ijneb.com with esmtp (Exim 4.69) (envelope-from ) id 1Jnal1-0003km-2L; Sun, 20 Apr 2008 15:43:07 +0100 Date: Sun, 20 Apr 2008 15:43:07 +0100 (BST) From: Mark Hills To: Peter Jeremy In-Reply-To: <20080420025010.GJ73016@server.vk2pj.dyndns.org> Message-ID: References: <20080420025010.GJ73016@server.vk2pj.dyndns.org> User-Agent: Alpine 1.10 (BSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: mark@pogo.org.uk Cc: freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 20 Apr 2008 14:43:10 -0000 On Sun, 20 Apr 2008, Peter Jeremy wrote: > Can you give some more detail about your hardware (speed, CPU, > available RAM, UP or SMP) and the application (roughly what does the > core of the code look like and is it single-threaded/multi-threaded > and/or multi-process). The current test is a Dell 2650, 2Gb, Quad Xeon with onboard bge. The application is single threaded, non-blocking multiplexed I/O based on poll(). It's relatively simple at its core -- read() from an inbound connection and write() to outbound sockets. >> As the number of outbound connections increases, the 'output drops' >> increases to around 10% of the total packets sent and maintains that ratio. >> There's no problems with network capacity. > > 'output drops' (ips_odropped) means that the kernel is unable to > buffer the write (no mbufs or send queue full). Userland should see > ENOBUFS unless the error was triggered by a fragmentation request. The app definitely isn't seeing ENOBUFS; this would be treated as a fatal condition and reported. > I can't explain the problem but it definitely looks like a resource > starvation issue within the kernel. I've traced the source of the ETIMEDOUT within the kernel to tcp_timer_rexmt() in tcp_timer.c: if (++tp->t_rxtshift > TCP_MAXRXTSHIFT) { tp->t_rxtshift = TCP_MAXRXTSHIFT; tcpstat.tcps_timeoutdrop++; tp = tcp_drop(tp, tp->t_softerror ? tp->t_softerror : ETIMEDOUT); goto out; } I'm new to FreeBSD, but it seems to implies that it's reaching a limit of a number of retransmits of sending ACKs on the TCP connection receiving the inbound data? But I checked this using tcpdump on the server and could see no retransmissions. As a test, I ran a simulation with the necessary changes to increase TCP_MAXRXTSHIFT (including adding appropriate entries to tcp_sync_backoff[] and tcp_backoff[]) and it appeared I was able to reduce the frequency of the problem occurring, but not to a usable level. With ACKs in mind, I took the test back to stock kernel and configuration, and went ahead with disabling sack on the server and the client which supplies the data (FreeBSD 6.1, not 7). This greatly reduced the 'duplicate acks' metric, but didn't fix the problem. The next step was to switch off delayed_ack as well, and I didn't see the problem for some hours on the test system at 850mbit output. But hasn't eliminated it, as it happened again. Perhaps someone with a greater knowledge can help to join the dots of all these symptoms? Mark From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 17:04:39 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 2C2B61065672 for ; Sun, 20 Apr 2008 17:04:39 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from n016.sc0.he.tucows.com (smtpout1120.sc0.he.tucows.com [64.97.144.120]) by mx1.freebsd.org (Postfix) with ESMTP id 00D6F8FC19 for ; Sun, 20 Apr 2008 17:04:38 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from sc0-out06.emaildefenseservice.com (64.97.131.2) by n016.sc0.he.tucows.com (7.2.078) id 4794C3EA014D2C98; Sun, 20 Apr 2008 17:04:38 +0000 X-SpamScore: 2 X-Spamcatcher-Summary: 2, 0, 0, ff8509a8af3eee98, fe71ce1fe1bfd227, eagletree@hughes.net, -, RULES_HIT:355:379:541:564:599:601:945:966:967:973:980:982:988:989:1260:1261:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1535:1544:1593:1594:1605:1711:1730:1747:1766:1792:1981:2194:2196:2198:2199:2200:2201:2378:2379:2393:2525:2553:2559:2563:2682:2685:2693:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3636:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941: 3944:3947:4117:4250:4385:4860:5007:6119:7652:7679:7904, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none, TSO:0 X-Spamcatcher-Explanation: Received: from [192.168.0.3] (dpc6744118153.direcpc.com [67.44.118.153]) (Authenticated sender: eagletree@hughes.net) by sc0-out06.emaildefenseservice.com (Postfix) with ESMTP; Sun, 20 Apr 2008 17:04:30 +0000 (UTC) In-Reply-To: <20080420103258.D67663@fledge.watson.org> References: <48087C98.8060600@delphij.net> <382258DB-13B8-4108-B8F4-157F247A7E4B@hughes.net> <20080420103258.D67663@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33AC96BF-B9AC-4303-9597-80BC341B7309@hughes.net> Content-Transfer-Encoding: 7bit From: Chris Pratt Date: Sun, 20 Apr 2008 09:53:49 -0700 To: Robert Watson X-Mailer: Apple Mail (2.753) Cc: net@freebsd.org Subject: Re: zonelimit issues... 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, 20 Apr 2008 17:04:39 -0000 On Apr 20, 2008, at 2:43 AM, Robert Watson wrote: > > On Fri, 18 Apr 2008, Chris Pratt wrote: > >> Doesn't 7.0 fix this? I'd like to see an official definitive >> answer and all I've been going on is that the problem description >> is no longer in the errata. > > Unfortunately, bugs of this sort don't really "work" that way -- > specific bugs are a property of a problem in code (or a problem in > design), but what we have right now is a report of a symptom that > might reflect zero or more specific bugs. It's unclear that the > problem described in errata is the problem you've been > experiencing, or that the (at least one) fixed bug with the same > symptoms is that one you've been experiencing. For better or > worse, the only way to really tell of a generic class of hang or > wedging is fixed is to try out the new version and see. In most > cases, "zonelimit" wedging reflects one of two things: > > (1) Inadequate resource allocation to the network stack or some other > component, try tuning up the memory tunable for clusters (for > example). > For several months I did quite a bit of tuning. I never increased nmbclusters beyond the 32768 shown in the docs because man tuning doesn't define it's use of "arbitrarily high". Inability to boot could mean travel. Kris Kenneway had provided instructions to get a dump. I set up for that but have never had a dump. The only respite came from adding another circuit, another NIC and spreading traffic. We increased our lock time from every couple of days during the heavy bot period of late 2006 to now every month or during traditionally slow months, even two months. For example, we ran a record 72 days last summer. It was a very dead summer traffic wise. I will try to increase the nmbclusters dramatically if I can figure out what a safe top limit is but it sounds like the jump to 7.0 RELEASE may be worth the effort. I would want to wait until this issue with TCP, Windows and certain routers is well past. I had not seen that applied to 7_0_0 yet and that would be a show stopper. Is there a way to know what is safe for nmbclusters given an 8GB ram system? I did vmstats data collection for a couple of months when things were at their worst. The results were nebulous to me based on lack of code knowledge. All I actually found was that a certain counter would drop to 0 and never recover. I didn't know if it was meaningful and received no replies when I asked FreeBSD-Questions. It was 128-Bucket or something like that. > (2) A memory leak in a network device driver or other network part, > which > needs to be debugged and fixed. > Initially I thought there may be something related to the bge driver and moved the high traffic apps on an em. This didn't seem to help much, nor did polling. I am most willing to collect data if I could figure out how to collect something meaningful. I gather from what you say, that 7.0 would provide this. I really appreciate both of your responses. Just based on this one problem, 6.x has been a bad experience after years of seemingly impossible uptime on 4 and 5.x FreeBSD. > On at least one prior occasion, there has been a bug in UMA itself > that lead to getting stuck in zonelimit, and it's not impossible > there's a scheduler sleep/wakeup bug that would lead to a similar > symptom but for a different reason. > > In FreeBSD 7-STABLE, you can now use procstat -k to print kernel > stack traces of user threads blocked in kernel, which may make > diagnosing the general class of problem a bit easier without using > a kernel debugger. "zonelimit" is the generic wait channel across > all memory type and allocation paths, so doesn't reveal a lot about > *which* limit is being hit. Using a kernel stack trace, we can see > which specific memory type and allocation context is involved. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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 Sun Apr 20 18:06:06 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 A7FFD106566C for ; Sun, 20 Apr 2008 18:06:06 +0000 (UTC) (envelope-from oliver@FreeBSD.org) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.freebsd.org (Postfix) with SMTP id 1BC1E8FC16 for ; Sun, 20 Apr 2008 18:06:05 +0000 (UTC) (envelope-from oliver@FreeBSD.org) Received: (qmail 21487 invoked by uid 89); 20 Apr 2008 18:06:03 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 20 Apr 2008 18:06:03 -0000 Date: Sun, 20 Apr 2008 20:06:12 +0200 From: Oliver Lehmann To: David DeSimone Message-Id: <20080420200612.d8315aea.oliver@FreeBSD.org> In-Reply-To: <20080420033322.GA16657@verio.net> References: <20080419195643.a5187267.oliver@FreeBSD.org> <20080420033322.GA16657@verio.net> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: problems interacting on TCP level with K5JB 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, 20 Apr 2008 18:06:06 -0000 Hi David, David DeSimone wrote: > The SYN-ACK packet in response contains an ACK for sequence 4294967213, > but that was not the sequence sent by the initial SYN (it was 1217851052). Yeah, this was the error - fixed the 32bit-pulling function in K5JB which pulls out the sequence of the TCP header to work correctly on my ZEUS-clone UNIX and here we go... attention - some leet spamming below: olivleh1@kartoffel olivleh1> ftp 10.1.1.2 Connected to 10.1.1.2. 220 FTP version K5JB.k31 ready at Fri Apr 19 10:08:17 1991 Name (10.1.1.2:root): test 331 Enter PASS command Password: 230 Logged in ftp> ls 500 Unknown command "epsv" 500 Unknown command "pasv" 200 Port command okay 150 Opening data connection for LIST / total 362 -rw-r----- 1 wega system 745 Apr 21 1990 .cshrc drwxrwxr-x 2 bin system 1824 Apr 29 1990 bin -r--r--r-- 1 wega system 6798 Jan 1 1990 boot drwxrwxr-x 2 bin system 1184 Apr 22 1990 dev drwxr-xr-x 3 bin system 1136 Apr 4 22:16 etc drwxr-xr-x 2 wega system 32 Jan 1 1990 fd0 drwxr-xr-x 2 wega system 32 Jan 1 1990 fd1 -rw-rw-rw- 1 wega system 14 Apr 19 00:35 ftpusers -rw-rw-rw- 1 wega system 34 Apr 19 00:42 hosts.net drwxrwxr-x 2 bin system 528 Apr 13 16:17 lib drwxr-x--- 2 wega system 2560 Jan 1 1990 lost+found -rwx------ 1 wega system 172 Apr 16 00:03 mount_fs -r-------- 1 wega system 464 Jan 1 1990 pb.image -r--r--r-- 1 wega system 1036 Jan 1 1990 sa.cat -r--r--r-- 1 wega system 28962 Jan 1 1990 sa.diags -r--r--r-- 1 wega system 10204 Jan 1 1990 sa.format -r--r--r-- 1 wega system 7122 Jan 1 1990 sa.install -r--r--r-- 1 wega system 4260 Jan 1 1990 sa.mkfs -r--r--r-- 1 wega system 2464 Jan 1 1990 sa.shipdisk -r--r--r-- 1 wega system 2568 Jan 1 1990 sa.timer -r--r--r-- 1 wega system 5162 Jan 1 1990 sa.verify -rw-rw-rw- 1 wega system 107 Apr 19 08:26 startup.net drwxrwxrwx 4 wega system 576 Apr 19 10:06 tmp drwxrwxrwx16 wega system 288 Apr 3 21:06 usr -r-------- 1 wega system 98548 May 1 1990 wega drwxrwxrwx13 wega system 224 Apr 19 03:06 z 226 File sent OK ftp> cd /z/src/k5jb.k31 257 "/z/src/k5jb.k31" is current directory ftp> get tcpin.c local: tcpin.c remote: tcpin.c 200 Port command okay 150 Opening data connection for RETR tcpin.c 23096 0.23 KB/s 226 File sent OK 23096 bytes received in 01:36 (0.23 KB/s) ftp> exit 221 Goodbye! olivleh1@kartoffel olivleh1> -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 18:10:05 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 5B3201065675 for ; Sun, 20 Apr 2008 18:10:05 +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 32CEC8FC2B for ; Sun, 20 Apr 2008 18:10:05 +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 m3KIA4PL001756 for ; Sun, 20 Apr 2008 18:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3KIA484001755; Sun, 20 Apr 2008 18:10:04 GMT (envelope-from gnats) Date: Sun, 20 Apr 2008 18:10:04 GMT Message-Id: <200804201810.m3KIA484001755@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: =?ISO-8859-15?Q?Lars_K=F6ller?= 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 Reply-To: =?ISO-8859-15?Q?Lars_K=F6ller?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2008 18:10:05 -0000 The following reply was made to PR kern/122427; it has been noted by GNATS. From: =?ISO-8859-15?Q?Lars_K=F6ller?= To: bug-followup@FreeBSD.org, root@koellers.net Cc: Subject: Re: kern/122427: [apm] [panic] apm and mDNSResponder cause panic during shutdown (multicast) Date: Sun, 20 Apr 2008 19:51:17 +0200 Same crash occurs on a ACPI Machine. I install mDNSresponder for testing the slimserver port. When I stop mdnsresponder per rc-script, the machin panics. From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 18:47: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 0AFB6106566C; Sun, 20 Apr 2008 18:47:44 +0000 (UTC) (envelope-from neil@hoggarth.me.uk) Received: from neilhoggarth-2.dsl.easynet.co.uk (neilhoggarth-2.dsl.easynet.co.uk [217.206.124.94]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4EA8FC18; Sun, 20 Apr 2008 18:47:43 +0000 (UTC) (envelope-from neil@hoggarth.me.uk) Received: from neilhoggarth-2.dsl.easynet.co.uk (localhost [127.0.0.1]) by neilhoggarth-2.dsl.easynet.co.uk (8.14.2/8.14.2) with ESMTP id m3KIFMhF010206; Sun, 20 Apr 2008 19:15:22 +0100 (BST) (envelope-from neil@hoggarth.me.uk) Received: from localhost (njh@localhost) by neilhoggarth-2.dsl.easynet.co.uk (8.14.2/8.14.2/Submit) with ESMTP id m3KIFL7i010203; Sun, 20 Apr 2008 19:15:22 +0100 (BST) (envelope-from neil@hoggarth.me.uk) X-Authentication-Warning: neilhoggarth-2.dsl.easynet.co.uk: njh owned process doing -bs Date: Sun, 20 Apr 2008 19:15:21 +0100 (BST) From: Neil Hoggarth X-X-Sender: njh@neilhoggarth-2.dsl.easynet.co.uk To: vwe@FreeBSD.org In-Reply-To: <200804201423.m3KENjUY082925@freefall.freebsd.org> Message-ID: References: <200804201423.m3KENjUY082925@freefall.freebsd.org> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org, neil@hoggarth.me.uk Subject: Re: kern/122928: [em] interface watchdog timeouts and stops receiving packets 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, 20 Apr 2008 18:47:44 -0000 On Sun, 20 Apr 2008, vwe@FreeBSD.org wrote: > Neil: Please additionally provide output of `ifconfig em0' and `sysctl hw.em' The output of "ifconfig em0" looks like this: em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:0e:0c:06:c2:3a inet 10.0.0.7 netmask 0xff000000 broadcast 10.255.255.255 media: Ethernet autoselect (1000baseTX ) status: active "sysctl hw.em" gives an "unknown oid" error. "sysctl dev.em" gives: dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 dev.em.0.%driver: em dev.em.0.%location: slot=9 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x100e subvendor=0x8086 subdevice=0x002e class=0x020000 dev.em.0.%parent: pci2 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 22:02: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 8BCEE1065672 for ; Sun, 20 Apr 2008 22:02: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 E6FB18FC20 for ; Sun, 20 Apr 2008 22:02:38 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 83686 invoked from network); 20 Apr 2008 21:07:34 -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 ; 20 Apr 2008 21:07:34 -0000 Message-ID: <480BBD7E.8010700@freebsd.org> Date: Mon, 21 Apr 2008 00:02:38 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Mark Hills References: <20080420025010.GJ73016@server.vk2pj.dyndns.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 20 Apr 2008 22:02:39 -0000 Mark Hills wrote: > On Sun, 20 Apr 2008, Peter Jeremy wrote: > >> Can you give some more detail about your hardware (speed, CPU, >> available RAM, UP or SMP) and the application (roughly what does the >> core of the code look like and is it single-threaded/multi-threaded >> and/or multi-process). > > The current test is a Dell 2650, 2Gb, Quad Xeon with onboard bge. > > The application is single threaded, non-blocking multiplexed I/O based > on poll(). It's relatively simple at its core -- read() from an inbound > connection and write() to outbound sockets. > >>> As the number of outbound connections increases, the 'output drops' >>> increases to around 10% of the total packets sent and maintains that >>> ratio. >>> There's no problems with network capacity. >> >> 'output drops' (ips_odropped) means that the kernel is unable to >> buffer the write (no mbufs or send queue full). Userland should see >> ENOBUFS unless the error was triggered by a fragmentation request. > > The app definitely isn't seeing ENOBUFS; this would be treated as a > fatal condition and reported. TCP application will never see ENOBUFS. TCP tries to reliably deliver all data even on temporary memory shortages that prevent it from sending a segment right now. Only after all those retries failed it will report ETIMEDOUT and abort the connection. >> I can't explain the problem but it definitely looks like a resource >> starvation issue within the kernel. > > I've traced the source of the ETIMEDOUT within the kernel to > tcp_timer_rexmt() in tcp_timer.c: > > if (++tp->t_rxtshift > TCP_MAXRXTSHIFT) { > tp->t_rxtshift = TCP_MAXRXTSHIFT; > tcpstat.tcps_timeoutdrop++; > tp = tcp_drop(tp, tp->t_softerror ? > tp->t_softerror : ETIMEDOUT); > goto out; > } Yes, this is related to either lack of mbufs to create a segment or a problem in sending it. That may be full interface queue, a bandwidth manager (dummynet) or some firewall internally rejecting the segment (ipfw, pf). Do you run any firewall in stateful mode? > I'm new to FreeBSD, but it seems to implies that it's reaching a limit > of a number of retransmits of sending ACKs on the TCP connection > receiving the inbound data? But I checked this using tcpdump on the > server and could see no retransmissions. When you have internal problems the segment never makes it to the wire and thus you wont see it in tcpdump. Please report the output of 'netstat -s -p tcp' and 'netstat -m'. > As a test, I ran a simulation with the necessary changes to increase > TCP_MAXRXTSHIFT (including adding appropriate entries to > tcp_sync_backoff[] and tcp_backoff[]) and it appeared I was able to > reduce the frequency of the problem occurring, but not to a usable level. Possible causes are timers that fire too early. Resource starvation (you are doing a lot of traffic). Or of course some bug in the code. > With ACKs in mind, I took the test back to stock kernel and > configuration, and went ahead with disabling sack on the server and the > client which supplies the data (FreeBSD 6.1, not 7). This greatly > reduced the 'duplicate acks' metric, but didn't fix the problem. The > next step was to switch off delayed_ack as well, and I didn't see the > problem for some hours on the test system at 850mbit output. But hasn't > eliminated it, as it happened again. > > Perhaps someone with a greater knowledge can help to join the dots of > all these symptoms? -- Andre From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 23:34:48 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 D628B106564A; Sun, 20 Apr 2008 23:34:48 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 612838FC20; Sun, 20 Apr 2008 23:34:48 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.2/jtpda-5.4) with ESMTP id m3KN2Zox002315 ; Mon, 21 Apr 2008 01:02:36 +0200 (CEST) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id m3KN2Yrb016566 ; Mon, 21 Apr 2008 01:02:34 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id m3KN2YLE016563; Mon, 21 Apr 2008 01:02:34 +0200 (MEST) (envelope-from arno) To: stable@freebsd.org From: "Arno J. Klaassen" Date: 21 Apr 2008 01:02:33 +0200 Message-ID: Lines: 66 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.164]); Mon, 21 Apr 2008 01:02:36 +0200 (CEST) X-Virus-Scanned: ClamAV 0.92/6851/Sun Apr 20 23:25:02 2008 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 480BCB8C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 480BCB8C.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ X-j-chkmail-Score: MSGID : 480BCB8C.000 on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.016 -> S=0.016 X-j-chkmail-Status: Ham Cc: net@freebsd.org Subject: nfs-server silent data corruption 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, 20 Apr 2008 23:34:48 -0000 Hello, I've a strange problem with a box I'm setting up as nfs-server under 7-stable : - tyan S2895 MB, 2*285Dualcore Opteron, 4G-ECC, ahd-scsi, nfe-network - stripped GENERIC as kernel - sources as of last saturday afternoon (European time) I removed everything from /boot/loader.conf and /etc/sysctl.conf, still I get "easily" data corruption when exporting ahd-scsi over nfs (NB exporting geom_raid5 gives same data corruption) Testing with the following pseudo code : while checksum1 == checksum2 do create random file of $1 MBytes calculate md5 checksum1 copy calculate md5 checksum2 on copy Tested on both (as nfs-client) a 6-stable-i386 from a couple of weeks ago as well as a linux 2.6.15-gentoo-r1 of about two years ago : within half an hour the copy will be different .... ;( I played with nfs-options on client side (nfs[23], conn, intr, [udp|tcp], -r=, -w= ) but none seem to matter. Start/Stop rpc.lock/sttatd on server/client just provoked some : cp: utimes: BIG2: No such file or directory cp: chown: BIG2: Stale NFS file handle cp: chmod: BIG2: Stale NFS file handle cp: chflags: BIG2: Operation not supported cp: BIG2: Stale NFS file handle cp: setting permissions for `BIG2': Stale NFS file handle cp: closing `BIG2': Stale NFS file handle [and then the while loop continued ... as if the NFS handle where not that stale ..] Anyway, I'll try to nail this down more (e.g. nfs-write performance is horrible ... (nfsd falling down to 0% cpu and then after while 'wake up' and be at around 3-6% again)) I didn't stress-test this MB for a while, but last time I did was with 7-PRELEASE/RC?/CANTremember-exactly-but-close-to-release and all worked great I did add 2G ECC to the 2nd CPU since, though I doubt that interferes with NFS. Bref, if anyone has a suggestion ???? (I will try downgrade to RELENG_7_0 iff noone has a new suggestion for RELENG_7, but I'd like to go forward and test some maybe suspect recent MFC or other suggestion) Thanx in advance, best, Arno From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 06: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 B7D70106564A for ; Mon, 21 Apr 2008 06:41:17 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 65BCA8FC1E for ; Mon, 21 Apr 2008 06:41:17 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so842412ywt.13 for ; Sun, 20 Apr 2008 23:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=XgGvSEQ+YlBoXbjK1ejJ4QW5qC3GMD60QlLSSDGEls4=; b=p4k1hMsPj8rAmrn4KRzMYSsgOnlTPP8k6WMq74Ip6mFL/y+TamQWt3p2oxXAuzpElhbgLUuqEOCBOTlS7FikoDfEJWQs5ntyA0jzV8mOAXyqKsgTnI5bz+Hl+EKwDPb+zgWwu/E2NtdfGtJNrmHfzaWO2yaAvZ0wQs93DkNjWo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=xQsYr/CjGwmzmN0EO+BLo/4rQQb6xUa3ulU9tvwgk06TBq8ftmoKk2PwelgBepisv1yn1IC2DjBD6+hvh4pPsebHlZ0bNhmpUbQeL9nBkwYHY93ZCLL4OhaHJ2CUz52oYECqx/nQlifj7Psh4IHFpvjPi8IUzhlM/h3gb3w476A= Received: by 10.150.58.17 with SMTP id g17mr6452856yba.235.1208758391080; Sun, 20 Apr 2008 23:13:11 -0700 (PDT) Received: from ?192.168.12.8? ( [97.101.40.241]) by mx.google.com with ESMTPS id 9sm6991837yws.6.2008.04.20.23.13.09 (version=SSLv3 cipher=RC4-MD5); Sun, 20 Apr 2008 23:13:10 -0700 (PDT) Message-ID: <480C306F.5000006@gmail.com> Date: Mon, 21 Apr 2008 02:13:03 -0400 From: Sten Daniel Soersdal User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Mark Hills References: <20080420025010.GJ73016@server.vk2pj.dyndns.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 21 Apr 2008 06:41:17 -0000 Mark Hills wrote: > On Sun, 20 Apr 2008, Peter Jeremy wrote: > >> Can you give some more detail about your hardware (speed, CPU, >> available RAM, UP or SMP) and the application (roughly what does the >> core of the code look like and is it single-threaded/multi-threaded >> and/or multi-process). > > The current test is a Dell 2650, 2Gb, Quad Xeon with onboard bge. > > The application is single threaded, non-blocking multiplexed I/O based > on poll(). It's relatively simple at its core -- read() from an inbound > connection and write() to outbound sockets. > >>> As the number of outbound connections increases, the 'output drops' >>> increases to around 10% of the total packets sent and maintains that >>> ratio. >>> There's no problems with network capacity. >> >> 'output drops' (ips_odropped) means that the kernel is unable to >> buffer the write (no mbufs or send queue full). Userland should see >> ENOBUFS unless the error was triggered by a fragmentation request. > > The app definitely isn't seeing ENOBUFS; this would be treated as a > fatal condition and reported. > >> I can't explain the problem but it definitely looks like a resource >> starvation issue within the kernel. > > I've traced the source of the ETIMEDOUT within the kernel to > tcp_timer_rexmt() in tcp_timer.c: > > if (++tp->t_rxtshift > TCP_MAXRXTSHIFT) { > tp->t_rxtshift = TCP_MAXRXTSHIFT; > tcpstat.tcps_timeoutdrop++; > tp = tcp_drop(tp, tp->t_softerror ? > tp->t_softerror : ETIMEDOUT); > goto out; > } > > I'm new to FreeBSD, but it seems to implies that it's reaching a limit > of a number of retransmits of sending ACKs on the TCP connection > receiving the inbound data? But I checked this using tcpdump on the > server and could see no retransmissions. > > As a test, I ran a simulation with the necessary changes to increase > TCP_MAXRXTSHIFT (including adding appropriate entries to > tcp_sync_backoff[] and tcp_backoff[]) and it appeared I was able to > reduce the frequency of the problem occurring, but not to a usable level. > > With ACKs in mind, I took the test back to stock kernel and > configuration, and went ahead with disabling sack on the server and the > client which supplies the data (FreeBSD 6.1, not 7). This greatly > reduced the 'duplicate acks' metric, but didn't fix the problem. The > next step was to switch off delayed_ack as well, and I didn't see the > problem for some hours on the test system at 850mbit output. But hasn't > eliminated it, as it happened again. > > Perhaps someone with a greater knowledge can help to join the dots of > all these symptoms? Verify that you are not experiencing connection loss due to mtu related issues. What is path mtu? is mss adjusted along the way? Try turning off txcsum and rxcsum using ifconfig. Just my $0.02 -- Sten Daniel Soersdal From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 06:51: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 A99CC106564A; Mon, 21 Apr 2008 06:51:19 +0000 (UTC) (envelope-from mark@pogo.org.uk) Received: from metheny.ijneb.com (unknown [IPv6:2001:ba8:0:1ba:214:22ff:feb1:2693]) by mx1.freebsd.org (Postfix) with ESMTP id 27D728FC12; Mon, 21 Apr 2008 06:51:19 +0000 (UTC) (envelope-from mark@pogo.org.uk) Received: from localhost ([127.0.0.1] ident=mark) by metheny.ijneb.com with esmtp (Exim 4.69) (envelope-from ) id 1Jnprw-0004YH-7C; Mon, 21 Apr 2008 07:51:16 +0100 Date: Mon, 21 Apr 2008 07:51:16 +0100 (BST) From: Mark Hills To: Andre Oppermann In-Reply-To: <480BBD7E.8010700@freebsd.org> Message-ID: References: <20080420025010.GJ73016@server.vk2pj.dyndns.org> <480BBD7E.8010700@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: mark@pogo.org.uk Cc: Peter Jeremy , freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 21 Apr 2008 06:51:19 -0000 On Mon, 21 Apr 2008, Andre Oppermann wrote: > Mark Hills wrote: >> On Sun, 20 Apr 2008, Peter Jeremy wrote: >>> I can't explain the problem but it definitely looks like a resource >>> starvation issue within the kernel. >> >> I've traced the source of the ETIMEDOUT within the kernel to >> tcp_timer_rexmt() in tcp_timer.c: >> >> if (++tp->t_rxtshift > TCP_MAXRXTSHIFT) { >> tp->t_rxtshift = TCP_MAXRXTSHIFT; >> tcpstat.tcps_timeoutdrop++; >> tp = tcp_drop(tp, tp->t_softerror ? >> tp->t_softerror : ETIMEDOUT); >> goto out; >> } > > Yes, this is related to either lack of mbufs to create a segment > or a problem in sending it. That may be full interface queue, a > bandwidth manager (dummynet) or some firewall internally rejecting > the segment (ipfw, pf). Do you run any firewall in stateful mode? There's no firewall running. >> I'm new to FreeBSD, but it seems to implies that it's reaching a limit >> of a number of retransmits of sending ACKs on the TCP connection >> receiving the inbound data? But I checked this using tcpdump on the >> server and could see no retransmissions. > > When you have internal problems the segment never makes it to the > wire and thus you wont see it in tcpdump. > > Please report the output of 'netstat -s -p tcp' and 'netstat -m'. Posted below. You can see it it in there: "131 connections dropped by rexmit timeout" >> As a test, I ran a simulation with the necessary changes to increase >> TCP_MAXRXTSHIFT (including adding appropriate entries to tcp_sync_backoff[] >> and tcp_backoff[]) and it appeared I was able to reduce the frequency of >> the problem occurring, but not to a usable level. > > Possible causes are timers that fire too early. Resource starvation > (you are doing a lot of traffic). Or of course some bug in the code. As I said in my original email, the data transfer doesn't stop or splutter, it's simply cut mid-flow. Sounds like something happening prematurely. Thanks for the help, Mark $ netstat -m 14632/8543/23175 mbufs in use (current/cache/total) 504/4036/4540/25600 mbuf clusters in use (current/cache/total/max) 504/3976 mbuf+clusters out of packet secondary zone in use (current/cache) 12550/250/12800/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 54866K/11207K/66073K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/6/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines $ netstat -s -p tcp tcp: 3408601864 packets sent 3382078274 data packets (1431587515 bytes) 454189057 data packets (1209708476 bytes) retransmitted 14969051 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 2216740 ack-only packets (9863 delayed) 0 URG only packets 0 window probe packets 273815 window update packets 35946 control packets 2372591976 packets received 1991632669 acks (for 2122913190 bytes) 16032443 duplicate acks 0 acks for unsent data 1719033 packets (1781984933 bytes) received in-sequence 1404 completely duplicate packets (197042 bytes) 1 old duplicate packet 54 packets with some dup. data (6403 bytes duped) 9858 out-of-order packets (9314285 bytes) 0 packets (0 bytes) of data after window 0 window probes 363132176 window update packets 3 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 635 discarded due to memory problems 39 connection requests 86333 connection accepts 0 bad connection attempts 2256 listen queue overflows 8557 ignored RSTs in the windows 86369 connections established (including accepts) 83380 connections closed (including 31174 drops) 74004 connections updated cached RTT on close 74612 connections updated cached RTT variance on close 74591 connections updated cached ssthresh on close 3 embryonic connections dropped 1979184038 segments updated rtt (of 1729113221 attempts) 110108313 retransmit timeouts 131 connections dropped by rexmit timeout 1 persist timeout 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 23 keepalive timeouts 22 keepalive probes sent 1 connection dropped by keepalive 320 correct ACK header predictions 1638923 correct data packet header predictions 87976 syncache entries added 182 retransmitted 111 dupsyn 13061 dropped 86333 completed 8907 bucket overflow 0 cache overflow 1 reset 0 stale 2256 aborted 0 badack 0 unreach 0 zone failures 101037 cookies sent 9521 cookies received 36888 SACK recovery episodes 68139 segment rexmits in SACK recovery episodes 98390670 byte rexmits in SACK recovery episodes 243196 SACK options (SACK blocks) received 2853 SACK options (SACK blocks) sent 0 SACK scoreboard overflow From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 07:44: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 1336E106566C; Mon, 21 Apr 2008 07:44:24 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id E0F3F8FC2F; Mon, 21 Apr 2008 07:44:23 +0000 (UTC) (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 m3L7iIhs095533; Mon, 21 Apr 2008 00:44:23 -0700 (PDT) (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 m3L7hawk025348; Mon, 21 Apr 2008 00:43:36 -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 m3L7hZhK013416; Mon, 21 Apr 2008 00:43:36 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Mon, 21 Apr 2008 16:43:34 +0900 Message-ID: From: gnn@freebsd.org To: Chris Pratt In-Reply-To: <33AC96BF-B9AC-4303-9597-80BC341B7309@hughes.net> References: <48087C98.8060600@delphij.net> <382258DB-13B8-4108-B8F4-157F247A7E4B@hughes.net> <20080420103258.D67663@fledge.watson.org> <33AC96BF-B9AC-4303-9597-80BC341B7309@hughes.net> 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 Cc: Robert Watson , net@freebsd.org Subject: Re: zonelimit issues... 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, 21 Apr 2008 07:44:24 -0000 At Sun, 20 Apr 2008 09:53:49 -0700, Chris Pratt wrote: > > > On Apr 20, 2008, at 2:43 AM, Robert Watson wrote: > > > > > On Fri, 18 Apr 2008, Chris Pratt wrote: > > > >> Doesn't 7.0 fix this? I'd like to see an official definitive > >> answer and all I've been going on is that the problem description > >> is no longer in the errata. > > > > Unfortunately, bugs of this sort don't really "work" that way -- > > specific bugs are a property of a problem in code (or a problem in > > design), but what we have right now is a report of a symptom that > > might reflect zero or more specific bugs. It's unclear that the > > problem described in errata is the problem you've been > > experiencing, or that the (at least one) fixed bug with the same > > symptoms is that one you've been experiencing. For better or > > worse, the only way to really tell of a generic class of hang or > > wedging is fixed is to try out the new version and see. In most > > cases, "zonelimit" wedging reflects one of two things: > > > > (1) Inadequate resource allocation to the network stack or some other > > component, try tuning up the memory tunable for clusters (for > > example). > > > For several months I did quite a bit of tuning. I never increased > nmbclusters beyond the 32768 shown in the docs because man > tuning doesn't define it's use of "arbitrarily high". Inability to boot > could mean travel. Kris Kenneway had provided instructions to > get a dump. I set up for that but have never had a dump. The > only respite came from adding another circuit, another NIC and > spreading traffic. We increased our lock time from every couple > of days during the heavy bot period of late 2006 to now every > month or during traditionally slow months, even two months. > For example, we ran a record 72 days last summer. It was a > very dead summer traffic wise. > > I will try to increase the nmbclusters dramatically if I can figure > out what a safe top limit is but it sounds like the jump to > 7.0 RELEASE may be worth the effort. I would want to wait > until this issue with TCP, Windows and certain routers is well > past. I had not seen that applied to 7_0_0 yet and that would be > a show stopper. Is there a way to know what is safe for > nmbclusters given an 8GB ram system? On "big" systems I am currently using 65000, and that seems safe so far. This is on an 8 core (2P) Xeon box with 8G of RAM. > I did vmstats data collection for a couple of months when things > were at their worst. The results were nebulous to me based > on lack of code knowledge. All I actually found was that a > certain counter would drop to 0 and never recover. I didn't > know if it was meaningful and received no replies when I > asked FreeBSD-Questions. It was 128-Bucket or something > like that. > > > (2) A memory leak in a network device driver or other network part, > > which > > needs to be debugged and fixed. > > > > Initially I thought there may be something related to the bge > driver and moved the high traffic apps on an em. This didn't > seem to help much, nor did polling. > > I am most willing to collect data if I could figure out how to > collect something meaningful. I gather from what you say, > that 7.0 would provide this. > > I really appreciate both of your responses. Just based on > this one problem, 6.x has been a bad experience after > years of seemingly impossible uptime on 4 and 5.x > FreeBSD. Well there are plenty of us motivated to get at these issues. Can you do me a favor and characterize your traffic a bit? Is it mostly TCP, or heavily UDP or some sort of mix? The issues I see are UDP based, which is less surprising as UDP has no backpressure and it is easy to over commit the system by upping the socket buffer space allocated without upping the number of clusters to compensate. Best, George From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 07:46:19 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 8749C106564A; Mon, 21 Apr 2008 07:46:19 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id 637BB8FC1C; Mon, 21 Apr 2008 07:46:19 +0000 (UTC) (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 m3L7kIhs095581; Mon, 21 Apr 2008 00:46:19 -0700 (PDT) (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 m3L7k1tM026124; Mon, 21 Apr 2008 00:46:01 -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 m3L7k1Su014039; Mon, 21 Apr 2008 00:46:01 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Mon, 21 Apr 2008 16:46:00 +0900 Message-ID: From: gnn@FreeBSD.org To: Robert Watson In-Reply-To: <20080420102827.U67663@fledge.watson.org> References: <20080420102827.U67663@fledge.watson.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 Cc: net@FreeBSD.org Subject: Re: zonelimit issues... 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, 21 Apr 2008 07:46:19 -0000 At Sun, 20 Apr 2008 10:32:25 +0100 (BST), rwatson wrote: > > > On Fri, 18 Apr 2008, gnn@freebsd.org wrote: > > > I am wondering why this patch was never committed? > > > > http://people.freebsd.org/~delphij/misc/patch-zonelimit-workaround > > > > It does seem to address an issue I'm seeing where processes get into the > > zonelimit state through the use of mbufs (a high speed UDP packet receiver) > > but even after network pressure is reduced/removed the process never gets > > out of that state again. Applying the patch fixed the issue, but I'd like > > to have some discussion as to the general merits of the approach. > > > > Unfortunately the test that currently causes this is tied very tightly to > > code at work that I can't share, but I will hopefully be improving mctest to > > try to exhibit this behavior. > > When you take all load off the system, do mbufs and clusters get properly > freed back to UMA (as visible in netstat -m)? If not, continuing to bump up > against the zonelimit would suggest an mbuf/cluster leak, in which case we > need to track that bug. > This is unclear as the process that creates the issue opens 50 UDP multicast sockets with very large socket buffers. I am investigating this aspect some more. > You might consider adding a debugging-only zonelimit waiter count to > the UMA zone, and checks/assertions that a wakeup is being generated > properly. Yes. Do you have an example I can easily steal? > That is, to confirm that the wakeup is generated when memory is > freed up if there are threads waiting. There is at least one as-yet > MFC'd fix to the sleep/wakeup code, I believe, that might be > relevant here. Is the problem you're reporting on 7.x, or on 8.x? > If 8.x, that's probably not it, but if 7.x, it could be. (This same > sleep/wakeup bug occasionally leads to wedging of dump(8), I > believe). I have seen this on 7.0 RELEASE, and STABLE and on CURRENT (8). I am currently working on it on CURRENT because if I have a fix it's going to have to go there first. Best, George From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 08:17:01 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 E05871065672; Mon, 21 Apr 2008 08:17:01 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id BC48C8FC25; Mon, 21 Apr 2008 08:17:01 +0000 (UTC) (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 m3L8H0hs096252; Mon, 21 Apr 2008 01:17:01 -0700 (PDT) (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 m3L8GUcV033985; Mon, 21 Apr 2008 01:16:30 -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 m3L8GTuR020588; Mon, 21 Apr 2008 01:16:30 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Mon, 21 Apr 2008 17:16:28 +0900 Message-ID: From: gnn@freebsd.org To: gnn@freebsd.org In-Reply-To: References: <20080420102827.U67663@fledge.watson.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 Cc: Robert Watson , net@freebsd.org Subject: Re: zonelimit issues... 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, 21 Apr 2008 08:17:02 -0000 At Mon, 21 Apr 2008 16:46:00 +0900, gnn@freebsd.org wrote: > > At Sun, 20 Apr 2008 10:32:25 +0100 (BST), > rwatson wrote: > > > > > > On Fri, 18 Apr 2008, gnn@freebsd.org wrote: > > > > > I am wondering why this patch was never committed? > > > > > > http://people.freebsd.org/~delphij/misc/patch-zonelimit-workaround > > > > > > It does seem to address an issue I'm seeing where processes get into the > > > zonelimit state through the use of mbufs (a high speed UDP packet receiver) > > > but even after network pressure is reduced/removed the process never gets > > > out of that state again. Applying the patch fixed the issue, but I'd like > > > to have some discussion as to the general merits of the approach. > > > > > > Unfortunately the test that currently causes this is tied very tightly to > > > code at work that I can't share, but I will hopefully be improving mctest to > > > try to exhibit this behavior. > > > > When you take all load off the system, do mbufs and clusters get properly > > freed back to UMA (as visible in netstat -m)? If not, continuing to bump up > > against the zonelimit would suggest an mbuf/cluster leak, in which case we > > need to track that bug. > > > > This is unclear as the process that creates the issue opens 50 UDP > multicast sockets with very large socket buffers. I am investigating > this aspect some more. > OK, yes, the clusters etc. go back to normal when the incoming pressure is released. I do not believe we have a cluster/mbuf leak. Best, George From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 08:41:37 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 BC4031065675; Mon, 21 Apr 2008 08:41:37 +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 8E9CA8FC16; Mon, 21 Apr 2008 08:41:37 +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 m3L8fbq3085135; Mon, 21 Apr 2008 08:41:37 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3L8fb1i085131; Mon, 21 Apr 2008 08:41:37 GMT (envelope-from linimon) Date: Mon, 21 Apr 2008 08:41:37 GMT Message-Id: <200804210841.m3L8fb1i085131@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/122954: [lagg] IPv6 EUI64 incorrectly chosen for lagg devices 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, 21 Apr 2008 08:41:37 -0000 Synopsis: [lagg] IPv6 EUI64 incorrectly chosen for lagg devices Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 21 08:41:27 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122954 From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 09:27:06 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 B2762106564A for ; Mon, 21 Apr 2008 09:27:06 +0000 (UTC) (envelope-from fam@solacetel.com) Received: from ns1.sky.net.pk (mx1.sky.net.pk [203.175.64.8]) by mx1.freebsd.org (Postfix) with ESMTP id BD4B88FC20 for ; Mon, 21 Apr 2008 09:27:05 +0000 (UTC) (envelope-from fam@solacetel.com) Received: from solace638d593b (fam.sky.net.pk [203.175.64.65]) by ns1.sky.net.pk (8.13.5/8.13.5) with ESMTP id m3L7qdLG028833 for ; Mon, 21 Apr 2008 13:52:47 +0600 Message-Id: <200804210752.m3L7qdLG028833@ns1.sky.net.pk> From: "Fazal Ahmed Malik" To: Date: Mon, 21 Apr 2008 13:48:50 +0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcijjIUQg1WPl7loSjOUXkvKm11Q9w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Web server behind ipfw firewall 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, 21 Apr 2008 09:27:06 -0000 Hi, I need help for setting up web server behind IPFW firewall. I have Freebsd 6.0 working as router on LAN with transparent squid. Now I want to setup web server to be running on private IP please help me in writing IPFW rules to serve the purpose. Current IPFW rules are as under, $fwcmd add divert natd all from any to any via vr0 $fwcmd add fwd $external_ip,8080 tcp from not me to any 80 #$fwcmd add fwd $internal_ip log tcp from any to me dst-port 80 in via vr0 #$fwcmd add fwd $internal_ip tcp from any to me dst-port 80 out via re0 $fwcmd add allow log tcp from any to any in tcpflags syn,fin $fwcmd add check-state $fwcmd add allow tcp from any to any out keep-state $fwcmd add allow tcp from any to any via vr0 established $fwcmd add allow tcp from any to any 21 setup $fwcmd add allow tcp from any to any 22 setup $fwcmd add allow tcp from any to any 23 setup $fwcmd add allow tcp from any to any 43 setup $fwcmd add allow tcp from any to me 80 setup $fwcmd add allow tcp from any to any 110 setup $fwcmd add allow tcp from any to any 143 setup $fwcmd add allow tcp from any to any 443 setup $fwcmd add allow tcp from any to any 789 setup $fwcmd add reset log tcp from any to any 113 in recv vr0 $fwcmd add allow udp from any to any 53 out xmit vr0 $fwcmd add allow udp from any 53 to any in recv vr0 $fwcmd add 03000 allow icmp from me to any $fwcmd add 04000 allow icmp from any to any Thanks, Fazal No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.2/1388 - Release Date: 4/20/2008 3:01 PM From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 09:47:18 2008 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 04594106566C; Mon, 21 Apr 2008 09:47:18 +0000 (UTC) Date: Mon, 21 Apr 2008 09:47:18 +0000 From: Kris Kennaway To: "Arno J. Klaassen" Message-ID: <20080421094718.GY25623@hub.freebsd.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org, net@freebsd.org Subject: Re: nfs-server silent data corruption 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, 21 Apr 2008 09:47:18 -0000 On Mon, Apr 21, 2008 at 01:02:33AM +0200, Arno J. Klaassen wrote: > I didn't stress-test this MB for a while, but last time I did was > with 7-PRELEASE/RC?/CANTremember-exactly-but-close-to-release > and all worked great > > I did add 2G ECC to the 2nd CPU since, though I doubt that interferes > with NFS. Uh, you're getting server-side data corruption, it could definitely be because of the memory you added. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 10:42: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 45153106567D; Mon, 21 Apr 2008 10:42:42 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by mx1.freebsd.org (Postfix) with ESMTP id 01B1C8FC3C; Mon, 21 Apr 2008 10:42:41 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx27.mail.ru (mx27.mail.ru [194.67.23.23]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id C3CD8126083; Mon, 21 Apr 2008 12:55:23 +0400 (MSD) Received: from [217.25.27.27] (port=41343 helo=[217.25.27.27]) by mx27.mail.ru with asmtp id 1Jnro2-000BMK-00; Mon, 21 Apr 2008 12:55:22 +0400 Message-ID: <480C5679.8060904@mail.ru> Date: Mon, 21 Apr 2008 13:55:21 +0500 From: rihad User-Agent: Icedove 1.5.0.14pre (X11/20080305) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected Cc: freebsd-drivers@freebsd.org, freebsd-hardware@freebsd.org Subject: bce(4) polling support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rihad@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2008 10:42:42 -0000 Hi all, Just wondering if someone's been working on POLLING support for bce(4) Broadcom NetXtreme II (BCM5706/BCM5708) PCI/PCIe Gigabit Ethernet adapter driver? AFAIK late in 2006 brueffer@ decided[*] to remove the erroneous polling(4) man entry claiming bce support... and that's it. Any advancements since then? [*] http://monkey.org/freebsd/archive/freebsd-net/200612/msg00004.html TIA From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 11:06: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 DE11A1065684 for ; Mon, 21 Apr 2008 11:06:52 +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 C37528FC2F for ; Mon, 21 Apr 2008 11:06:52 +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 m3LB6q1e095244 for ; Mon, 21 Apr 2008 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3LB6qGV095240 for freebsd-net@FreeBSD.org; Mon, 21 Apr 2008 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Apr 2008 11:06:52 GMT Message-Id: <200804211106.m3LB6qGV095240@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, 21 Apr 2008 11:06:52 -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/121298 net [em] [panic] Fatal trap 12: page fault while in kernel 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 o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122875 net [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stabl o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices 58 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/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 o kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) (regression) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o amd64/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem f kern/122928 net [em] interface watchdog timeouts and stops receiving p 42 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 11:43:51 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 8139510656C2; Mon, 21 Apr 2008 11:43:51 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 3C7C28FC1F; Mon, 21 Apr 2008 11:43:51 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id 0825F5C23; Mon, 21 Apr 2008 15:28:32 +0400 (MSD) Date: Mon, 21 Apr 2008 15:27:53 +0400 From: Igor Sysoev To: gnn@freebsd.org Message-ID: <20080421112753.GD44915@rambler-co.ru> References: <20080420102827.U67663@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Robert Watson , net@freebsd.org Subject: Re: zonelimit issues... 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, 21 Apr 2008 11:43:51 -0000 On Mon, Apr 21, 2008 at 05:16:28PM +0900, gnn@freebsd.org wrote: > At Mon, 21 Apr 2008 16:46:00 +0900, > gnn@freebsd.org wrote: > > > > At Sun, 20 Apr 2008 10:32:25 +0100 (BST), > > rwatson wrote: > > > > > > > > > On Fri, 18 Apr 2008, gnn@freebsd.org wrote: > > > > > > > I am wondering why this patch was never committed? > > > > > > > > http://people.freebsd.org/~delphij/misc/patch-zonelimit-workaround > > > > > > > > It does seem to address an issue I'm seeing where processes get into the > > > > zonelimit state through the use of mbufs (a high speed UDP packet receiver) > > > > but even after network pressure is reduced/removed the process never gets > > > > out of that state again. Applying the patch fixed the issue, but I'd like > > > > to have some discussion as to the general merits of the approach. > > > > > > > > Unfortunately the test that currently causes this is tied very tightly to > > > > code at work that I can't share, but I will hopefully be improving mctest to > > > > try to exhibit this behavior. > > > > > > When you take all load off the system, do mbufs and clusters get properly > > > freed back to UMA (as visible in netstat -m)? If not, continuing to bump up > > > against the zonelimit would suggest an mbuf/cluster leak, in which case we > > > need to track that bug. > > > > > > > This is unclear as the process that creates the issue opens 50 UDP > > multicast sockets with very large socket buffers. I am investigating > > this aspect some more. > > > > OK, yes, the clusters etc. go back to normal when the incoming > pressure is released. I do not believe we have a cluster/mbuf leak. There is no cluster/mbuf leak. The problem that FreeBSD has small KVA space: only 2G even on amd64 32G machines. So with vm.kmem_size=1G # 64M KVA kern.maxbcache=64M # 4M KVA kern.ipc.maxpipekva=4M I can use something like this: # 256M KVA/KVM kern.ipc.nmbjumbop=64000 # 216M KVA/KVM kern.ipc.nmbclusters=98304 # 162M KVA/KVM kern.ipc.maxsockets=163840 # 8M KVA/KVM net.inet.tcp.maxtcptw=163840 # 24M KVA/KVM kern.maxfiles=204800 -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 13:46: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 BCF1F106564A for ; Mon, 21 Apr 2008 13:46:47 +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 1D4B78FC27 for ; Mon, 21 Apr 2008 13:46:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 15796 invoked from network); 21 Apr 2008 12:51:35 -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 ; 21 Apr 2008 12:51:35 -0000 Message-ID: <480C9AC6.8090802@freebsd.org> Date: Mon, 21 Apr 2008 15:46:46 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Mark Hills References: <20080420025010.GJ73016@server.vk2pj.dyndns.org> <480BBD7E.8010700@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 21 Apr 2008 13:46:47 -0000 Mark Hills wrote: > On Mon, 21 Apr 2008, Andre Oppermann wrote: > >> Mark Hills wrote: >>> On Sun, 20 Apr 2008, Peter Jeremy wrote: > >>>> I can't explain the problem but it definitely looks like a resource >>>> starvation issue within the kernel. >>> >>> I've traced the source of the ETIMEDOUT within the kernel to >>> tcp_timer_rexmt() in tcp_timer.c: >>> >>> if (++tp->t_rxtshift > TCP_MAXRXTSHIFT) { >>> tp->t_rxtshift = TCP_MAXRXTSHIFT; >>> tcpstat.tcps_timeoutdrop++; >>> tp = tcp_drop(tp, tp->t_softerror ? >>> tp->t_softerror : ETIMEDOUT); >>> goto out; >>> } >> >> Yes, this is related to either lack of mbufs to create a segment >> or a problem in sending it. That may be full interface queue, a >> bandwidth manager (dummynet) or some firewall internally rejecting >> the segment (ipfw, pf). Do you run any firewall in stateful mode? > > There's no firewall running. > >>> I'm new to FreeBSD, but it seems to implies that it's reaching a >>> limit of a number of retransmits of sending ACKs on the TCP >>> connection receiving the inbound data? But I checked this using >>> tcpdump on the server and could see no retransmissions. >> >> When you have internal problems the segment never makes it to the >> wire and thus you wont see it in tcpdump. >> >> Please report the output of 'netstat -s -p tcp' and 'netstat -m'. > > Posted below. You can see it it in there: "131 connections dropped by > rexmit timeout" > >>> As a test, I ran a simulation with the necessary changes to increase >>> TCP_MAXRXTSHIFT (including adding appropriate entries to >>> tcp_sync_backoff[] and tcp_backoff[]) and it appeared I was able to >>> reduce the frequency of the problem occurring, but not to a usable >>> level. >> >> Possible causes are timers that fire too early. Resource starvation >> (you are doing a lot of traffic). Or of course some bug in the code. > > As I said in my original email, the data transfer doesn't stop or > splutter, it's simply cut mid-flow. Sounds like something happening > prematurely. > > Thanks for the help, The output doesn't show any obvious problems. I have to write some debug code to run on your system. I'll do that later today if time permits. Otherwise tomorrow. -- Andre > Mark > > > > $ netstat -m > 14632/8543/23175 mbufs in use (current/cache/total) > 504/4036/4540/25600 mbuf clusters in use (current/cache/total/max) > 504/3976 mbuf+clusters out of packet secondary zone in use (current/cache) > 12550/250/12800/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 54866K/11207K/66073K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/6/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > $ netstat -s -p tcp > tcp: > 3408601864 packets sent > 3382078274 data packets (1431587515 bytes) > 454189057 data packets (1209708476 bytes) retransmitted > 14969051 data packets unnecessarily retransmitted > 0 resends initiated by MTU discovery > 2216740 ack-only packets (9863 delayed) > 0 URG only packets > 0 window probe packets > 273815 window update packets > 35946 control packets > 2372591976 packets received > 1991632669 acks (for 2122913190 bytes) > 16032443 duplicate acks > 0 acks for unsent data > 1719033 packets (1781984933 bytes) received in-sequence > 1404 completely duplicate packets (197042 bytes) > 1 old duplicate packet > 54 packets with some dup. data (6403 bytes duped) > 9858 out-of-order packets (9314285 bytes) > 0 packets (0 bytes) of data after window > 0 window probes > 363132176 window update packets > 3 packets received after close > 0 discarded for bad checksums > 0 discarded for bad header offset fields > 0 discarded because packet too short > 635 discarded due to memory problems > 39 connection requests > 86333 connection accepts > 0 bad connection attempts > 2256 listen queue overflows > 8557 ignored RSTs in the windows > 86369 connections established (including accepts) > 83380 connections closed (including 31174 drops) > 74004 connections updated cached RTT on close > 74612 connections updated cached RTT variance on close > 74591 connections updated cached ssthresh on close > 3 embryonic connections dropped > 1979184038 segments updated rtt (of 1729113221 attempts) > 110108313 retransmit timeouts > 131 connections dropped by rexmit timeout > 1 persist timeout > 0 connections dropped by persist timeout > 0 Connections (fin_wait_2) dropped because of timeout > 23 keepalive timeouts > 22 keepalive probes sent > 1 connection dropped by keepalive > 320 correct ACK header predictions > 1638923 correct data packet header predictions > 87976 syncache entries added > 182 retransmitted > 111 dupsyn > 13061 dropped > 86333 completed > 8907 bucket overflow > 0 cache overflow > 1 reset > 0 stale > 2256 aborted > 0 badack > 0 unreach > 0 zone failures > 101037 cookies sent > 9521 cookies received > 36888 SACK recovery episodes > 68139 segment rexmits in SACK recovery episodes > 98390670 byte rexmits in SACK recovery episodes > 243196 SACK options (SACK blocks) received > 2853 SACK options (SACK blocks) sent > 0 SACK scoreboard overflow > > From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 13:50:05 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 B89C0106566B for ; Mon, 21 Apr 2008 13:50:05 +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 ACB738FC23 for ; Mon, 21 Apr 2008 13:50:05 +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 m3LDo55t013929 for ; Mon, 21 Apr 2008 13:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3LDo5MA013928; Mon, 21 Apr 2008 13:50:05 GMT (envelope-from gnats) Date: Mon, 21 Apr 2008 13:50:05 GMT Message-Id: <200804211350.m3LDo5MA013928@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Neil Hoggarth Cc: Subject: kern/122928: [em] interface watchdog timeouts and stops receiving packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Neil Hoggarth List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2008 13:50:05 -0000 The following reply was made to PR kern/122928; it has been noted by GNATS. From: Neil Hoggarth To: bug-followup@FreeBSD.org Cc: Subject: kern/122928: [em] interface watchdog timeouts and stops receiving packets Date: Mon, 21 Apr 2008 14:16:12 +0100 (BST) On Sun, 20 Apr 2008, vwe@FreeBSD.org wrote: > Neil: Please additionally provide output of `ifconfig em0' and `sysctl hw.em' The output of "ifconfig em0" looks like this: em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:0e:0c:06:c2:3a inet 10.0.0.7 netmask 0xff000000 broadcast 10.255.255.255 media: Ethernet autoselect (1000baseTX ) status: active "sysctl hw.em" gives an "unknown oid" error. "sysctl dev.em" gives: dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 dev.em.0.%driver: em dev.em.0.%location: slot=9 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x100e subvendor=0x8086 subdevice=0x002e class=0x020000 dev.em.0.%parent: pci2 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 14:54:35 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 BF95A106567A; Mon, 21 Apr 2008 14:54:35 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 51D788FC38; Mon, 21 Apr 2008 14:54:34 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.2/jtpda-5.4) with ESMTP id m3LEqvJi033518 ; Mon, 21 Apr 2008 16:53:20 +0200 (CEST) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id m3LEquFm020255 ; Mon, 21 Apr 2008 16:52:56 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id m3LEqtqB020252; Mon, 21 Apr 2008 16:52:55 +0200 (MEST) (envelope-from arno) To: Kris Kennaway References: <20080421094718.GY25623@hub.freebsd.org> From: "Arno J. Klaassen" Date: 21 Apr 2008 16:52:55 +0200 In-Reply-To: <20080421094718.GY25623@hub.freebsd.org> Message-ID: Lines: 43 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.164]); Mon, 21 Apr 2008 16:53:22 +0200 (CEST) X-Virus-Scanned: ClamAV 0.92/6863/Mon Apr 21 14:55:32 2008 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 480CAA5C.006 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 480CAA5C.006/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: stable@FreeBSD.ORG, David Wolfskill , Clayton Milos , net@FreeBSD.ORG Subject: Re: nfs-server silent data corruption 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, 21 Apr 2008 14:54:35 -0000 Kris Kennaway writes: > On Mon, Apr 21, 2008 at 01:02:33AM +0200, Arno J. Klaassen wrote: > > > I didn't stress-test this MB for a while, but last time I did was > > with 7-PRELEASE/RC?/CANTremember-exactly-but-close-to-release > > and all worked great > > > > I did add 2G ECC to the 2nd CPU since, though I doubt that interferes > > with NFS. > > Uh, you're getting server-side data corruption, it could definitely be > because of the memory you added. yop, though I'm still not convinced the memory is bad (the very same Kingston ECC as the 2*1G in use for about half a year already) : I added it directly to the 2nd CPU (diagram on page 9 of http://www.tyan.com/manuals/m_s2895_101.pdf) and the problem seems to be the interaction between nfe0 and powerd .... : - if I stop powerd, problems go away - I let run powerd but turn of txcsum and tso4 on the interface, the problem is a lot harder to produce (if ever this gives a hint to anyone) Device is : nfe0@pci0:0:10:0: class=0x068000 card=0x289510f1 chip=0x005710de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce4 Ultra NVidia Network Bus Enumerator' class = bridge cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 (this is with the default BIOS setting " LAN Bridge Enabled", disabling that setting makes pciconf say "class = network" but does not influence my problem) I will restart my tests now by populating all 4G to only CPU1 and say whether that matters. Best, Arno From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 16:00:20 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 320FF106567C for ; Mon, 21 Apr 2008 16:00:20 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id D5F5E8FC0A for ; Mon, 21 Apr 2008 16:00:16 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 7DF491CC033; Mon, 21 Apr 2008 08:43:33 -0700 (PDT) Date: Mon, 21 Apr 2008 08:43:33 -0700 From: Jeremy Chadwick To: "Arno J. Klaassen" Message-ID: <20080421154333.GA96237@eos.sc1.parodius.com> References: <20080421094718.GY25623@hub.freebsd.org> 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) Cc: Clayton Milos , Kris Kennaway , stable@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: nfs-server silent data corruption 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, 21 Apr 2008 16:00:20 -0000 On Mon, Apr 21, 2008 at 04:52:55PM +0200, Arno J. Klaassen wrote: > Kris Kennaway writes: > > Uh, you're getting server-side data corruption, it could definitely be > > because of the memory you added. > > yop, though I'm still not convinced the memory is bad (the very same > Kingston ECC as the 2*1G in use for about half a year already) : Can you download and run memtest86 on this system, with the added 2G ECC insalled? memtest86 doesn't guarantee showing signs of memory problems, but in most cases it'll start spewing errors almost immediately. One thing I did notice in the motherboard manual below is something called "Hammer Configuration". It appears to default to 800MHz, but there's an "Auto" choice. Does using Auto fix anything? > I added it directly to the 2nd CPU (diagram on page 9 of > http://www.tyan.com/manuals/m_s2895_101.pdf) and the problem > seems to be the interaction between nfe0 and powerd .... : That board is the weirdest thing I've seen in years. Two separate CPUs using a single (shared) memory controller, two separate (and different!) nVidia chipsets, a SMSC I/O controller probably used for serial and parallel I/O, two separate nVidia NICs with Marvell PHYs (yet somehow you can bridge the two NICs and PHYs?), two separate PCI-e busses (each associated with a separate nVidia chipset), two separate PCI-X busses... the list continues. I know you don't need opinions at this point, but what a behemoth. I can't imagine that thing running reliably. > - if I stop powerd, problems go away This would imply that clock frequency stepping is somehow attributing itself to the corruption. I don't see any BIOS options for controlling things related to AMD's Cool-n-Quiet or PowerNow! feature, which is usually what handles this. > - I let run powerd but turn of txcsum and tso4 on the interface, > the problem is a lot harder to produce (if ever this gives > a hint to anyone) Possibly shared interrupts are causing problems? MSI/MSI-X doing something odd? Have you tried disabling MSI/MSI-X and see if it makes a difference? Can you boot the machine in verbose mode, and put the dmesg up somewhere? > Device is : > > nfe0@pci0:0:10:0: class=0x068000 card=0x289510f1 chip=0x005710de rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'nForce4 Ultra NVidia Network Bus Enumerator' > class = bridge > cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > > (this is with the default BIOS setting " LAN Bridge Enabled", disabling > that setting makes pciconf say "class = network" but does not influence > my problem) I think you mean "MAC LAN Bridge", according to the motherboard manual. I'm not even sure what that really does; somehow trunks the two NICs together to give you the equivalent of 2000mbit of traffic? I don't know. Does the corruption you see go away if you install a separate NIC (e.g. an Intel NIC) in a PCI or PCI-e slot, and disable the onboard NICs (should be "MAC LAN: Disable" on both the primary and slave)? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 16:40:55 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 DB9E31065671 for ; Mon, 21 Apr 2008 16:40:55 +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 65D758FC12 for ; Mon, 21 Apr 2008 16:40:55 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-25-183.bredband.comhem.se ([83.253.25.183]:60065 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Jnyoy-0002cG-91 for net@FreeBSD.ORG; Mon, 21 Apr 2008 18:24:51 +0200 Received: (qmail 1566 invoked from network); 21 Apr 2008 18:24:46 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 21 Apr 2008 18:24:46 +0200 Received: (qmail 32854 invoked by uid 1001); 21 Apr 2008 18:24:46 +0200 Date: Mon, 21 Apr 2008 18:24:45 +0200 From: Erik Trulsson To: Jeremy Chadwick Message-ID: <20080421162445.GA32697@owl.midgard.homeip.net> Mail-Followup-To: Jeremy Chadwick , "Arno J. Klaassen" , Clayton Milos , Kris Kennaway , stable@FreeBSD.ORG, net@FreeBSD.ORG References: <20080421094718.GY25623@hub.freebsd.org> <20080421154333.GA96237@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080421154333.GA96237@eos.sc1.parodius.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Originating-IP: 83.253.25.183 X-Scan-Result: No virus found in message 1Jnyoy-0002cG-91. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Jnyoy-0002cG-91 3da064f924c13e72c6b314df5abcf5af Cc: Clayton Milos , Kris Kennaway , stable@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: nfs-server silent data corruption 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, 21 Apr 2008 16:40:55 -0000 On Mon, Apr 21, 2008 at 08:43:33AM -0700, Jeremy Chadwick wrote: > On Mon, Apr 21, 2008 at 04:52:55PM +0200, Arno J. Klaassen wrote: > > Kris Kennaway writes: > > > Uh, you're getting server-side data corruption, it could definitely be > > > because of the memory you added. > > > > yop, though I'm still not convinced the memory is bad (the very same > > Kingston ECC as the 2*1G in use for about half a year already) : > > Can you download and run memtest86 on this system, with the added 2G ECC > insalled? memtest86 doesn't guarantee showing signs of memory problems, > but in most cases it'll start spewing errors almost immediately. > > One thing I did notice in the motherboard manual below is something > called "Hammer Configuration". It appears to default to 800MHz, but > there's an "Auto" choice. Does using Auto fix anything? > > > I added it directly to the 2nd CPU (diagram on page 9 of > > http://www.tyan.com/manuals/m_s2895_101.pdf) and the problem > > seems to be the interaction between nfe0 and powerd .... : > > That board is the weirdest thing I've seen in years. > > Two separate CPUs using a single (shared) memory controller, No. Each CPU contains its own memory controller (just like all AMD's Opteron/Athlon64 CPUs does.) > two > separate (and different!) nVidia chipsets, More like one chipset consisting of several physical chips. (Which is actually quite common. The most common division is a "nortbridge/southbridge" division, but other ways are possible too.) The only unusual thing is that there are several chips connected directly to the CPUs, instead of having the CPUs talk to a single chip which in turn talks to another chip which can easily create bottlenecks. > a SMSC I/O controller > probably used for serial and parallel I/O Just like almost all other motherboards. >, two separate nVidia NICs with > Marvell PHYs (yet somehow you can bridge the two NICs and PHYs?) What is so wierd about that? If you want to have more than one ethernet connection, then you normally have more than one NIC. Bridging can easily (and commonly) be done over separate NICs. >, two > separate PCI-e busses (each associated with a separate nVidia chipset), Since it is always the case that each PCI-E slot or PCI-E device sits on its own bus I fail to see anything strange about that. (And it is actually very common to have the PCI-E slots on motherboards be connected to different chips.) > two separate PCI-X busses... the list continues. Having more than one PCI-X bus used to be fairly common on server boards for performance reasons. Nowadays PCI-X is slowly being replaced with PCI-E so on the latest generation of serverboards there are usually no more than one PCI-X bus. > > I know you don't need opinions at this point, but what a behemoth. I > can't imagine that thing running reliably. I would rather say it is a quite elegant design for a high-end motherboard intended for server/workstation installations. It is a dual-socket Opteron board. Each Opteron has its own memory-controller and uses HyperTransport to connect to other components. Each dual-socket Opteron has three HyperTransport links available. One from each CPU will be needed to the other CPU, leaving two links from each CPU available to connect to other chips. From that starting point it is a fairly obvious design. To maximise the available bandwidth one would want to spread out the chips over these links, which this motherboard does fairly well, using three of the four available links. (And hanging the most important things from CPU0, so you can actually use the board even if you have only one CPU installed.) As for reliability I see no particular reason for that board to be less reliable than any other multi-CPU board. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 17:28:48 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 C23571065670; Mon, 21 Apr 2008 17:28:48 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id B36CB8FC13; Mon, 21 Apr 2008 17:28:48 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 6D9671CC038; Mon, 21 Apr 2008 10:28:48 -0700 (PDT) Date: Mon, 21 Apr 2008 10:28:48 -0700 From: Jeremy Chadwick To: "Arno J. Klaassen" , Clayton Milos , Kris Kennaway , stable@FreeBSD.ORG, net@FreeBSD.ORG Message-ID: <20080421172848.GA872@eos.sc1.parodius.com> References: <20080421094718.GY25623@hub.freebsd.org> <20080421154333.GA96237@eos.sc1.parodius.com> <20080421162445.GA32697@owl.midgard.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080421162445.GA32697@owl.midgard.homeip.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: nfs-server silent data corruption 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, 21 Apr 2008 17:28:48 -0000 On Mon, Apr 21, 2008 at 06:24:45PM +0200, Erik Trulsson wrote: > As for reliability I see no particular reason for that board to be less > reliable than any other multi-CPU board. Sorry for my complete and total opinionated noise, then. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 20:38:51 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 C96FB106566C for ; Mon, 21 Apr 2008 20:38:51 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 6550E8FC12 for ; Mon, 21 Apr 2008 20:38:51 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id 7B51C6274 for ; Tue, 22 Apr 2008 00:21:17 +0400 (MSD) Date: Tue, 22 Apr 2008 00:20:38 +0400 From: Igor Sysoev To: freebsd-net@FreeBSD.org Message-ID: <20080421202038.GK54256@rambler-co.ru> References: <20071116154019.GE93422@rambler-co.ru> <20071117065908.T65479@delplex.bde.org> <20071117071053.GA18091@rambler-co.ru> <20071117194615.L67319@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20071117194615.L67319@delplex.bde.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: bge loader tunables 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, 21 Apr 2008 20:38:52 -0000 On Sat, Nov 17, 2007 at 09:13:50PM +1100, Bruce Evans wrote: > On Sat, 17 Nov 2007, Igor Sysoev wrote: > > >On Sat, Nov 17, 2007 at 08:30:58AM +1100, Bruce Evans wrote: > > > >>On Fri, 16 Nov 2007, Igor Sysoev wrote: > >> > >>>The attached patch creates the following bge loader tunables: > >> > >>I plan to commit old work to do this using sysctls. Tunables are > >>harder to use and aren't needed since changes to the defaults aren't > >>needed for booting. I also implemented dynamic tuning for rx coal > >>parameters so that the sysctls are mostly not needed. Ask for patches > >>if you want to test this extensively. > > > >Yes, I can test your patches on 6.2 and 7.0. > >Now bge set the coalescing parameters at attach time. > >Do the sysctl's allow to change them on-the-fly ? > >How does rx dynamic tuning work ? > >Could it be turned off ? > > OK, the patch is enclosed at the end, in 2 versions: > - all my patches for bge (with lots of debugging cruft and half-baked > fixes for 5705+ sysctls. > - edited version with only the coalescing parameter changes. > > I haven't used it under 6.2, but have used a similar version in ~5.2, > and it should work in 6.2 except for the 5705+ sysctl fixes. > > bge actually sets parameters at init time, and it initializes whenever the > link is brought back up, so the parameters can be changed using > "ifconfig bgeN down up". Several network drivers have interrupt moderation > parameters that can be changed in this way, but it is painful to change > the link status like that, so I have a sysctl dev.bge.N.program_coal to > apply the current parameters to the hardware. The other sysctls to change > the parameters don't apply immediately, except the one for the rx tuning > max interrupt rate, since applying the changed parameters to the hardware > takes more code than a SYSCTL_INT(), and it is sometimes necessary to > change all the parameters together atomically. > > Dynamic tuning works by monitoring the current rx packet rate and > increasing the active rx_max_coal_bds so that the ratio rate> / rx_max_coal_bds is usually <= the specified max rx interrupt > rate. rx_coal_ticks is set to the constant value of the inverse of > the specified max rx interrupt rate (in ticks) on transition to dynamic > mode but IIRC is not changed when the dynamic rate is changed (not > always changing it automatically allows adjusting it independently of > the rate but is often not what is wanted). The transition has some > bias towards lower latency over too many interrupts, so that short > bursts don't increase the latency. I think this simple algorithm is > good enough provided the load (in rx packets/second) doesn't oscillate > rapidly. > > Dynamic tuning requires efficient reprogramming of at least one of the > hardware coal registers so that the tuning can respond rapidly to changes. > I have 2 methods for this: > - bge_careful_coal = 1 avoids using uses a potentially very long > busy-wait loop in the interrupt handler by giving up on reprogramming > the host coalescing engine (HCE) if the HCE seems to be busy. Docs > seem to require waiting for up to several milliseconds for the HCE > to stablilize, and it is not clear if it is possible for the HCE to > never stabilize because packets are streaming in. (I don't have > proper docs.) This seems to always work (the HCE is never busy) > for rx_max_coal_bds, but something near here didn't work for > changing rx_coal_ticks in an old version. > - bge_careful_coal = 0 avoids the loop by writing to the rx_max_coal_bds > register without waiting for the HCE. This seems to work too. It > isn't critical for the HCE to see the change immediately or even > for it to be seen at all (missed changes might do more than give a > huge interrupt rate for too long), but it is important for the > change to not break the engine. > There is no sysctl for this of for some other hackish parameters. The > source must be edited to change this from 1 to 0. > > Dynamic tuning is turned off by setting the dynamic max interrupt > frequency to 0. Then rx_coal_ticks is reset to 150, and the active > rx_max_coal_bds is restored to the static value. Finally I have tested your second (without debug stuff) patch in production environment (~45K in/out packets) on FreeBSD 7.0-STABLE. I think it should be commited. I use my usual static settings in /etc/sysctl.conf: dev.bge.0.dyncoal_max_intr_freq=0 # dev.bge.0.rx_coal_ticks=500 dev.bge.0.tx_coal_ticks=10000 dev.bge.0.rx_max_coal_bds=64 dev.bge.0.tx_max_coal_bds=128 # apply the above parameters dev.bge.0.program_coal=0 and have about only 1700-1900 interrupts per second. The only issue was at boot time: dev.bge.0.dyncoal_max_intr_freq: 10000 -> 0 dev.bge.0.rx_coal_ticks: 0 -> 500 dev.bge.0.tx_coal_ticks: 1000000 -> 10000 dev.bge.0.rx_max_coal_bds: 128 -> 64 dev.bge.0.tx_max_coal_bds: 384 -> 128 ... bge0: flags =8843 metric 0 mtu 1500 options=9b ... Local package initialization: ... dev.bge.0.rx_coal_ticks: 150 -> 500 When disabling dyncoal_max_intr_freq at bge UPing resets rx_coal_ticks to 150. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 21:46:58 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 63CC41065679; Mon, 21 Apr 2008 21:46:58 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 157BD8FC36; Mon, 21 Apr 2008 21:46:57 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.2/jtpda-5.4) with ESMTP id m3LLksTv015607 ; Mon, 21 Apr 2008 23:46:54 +0200 (CEST) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id m3LLkqNM022119 ; Mon, 21 Apr 2008 23:46:52 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id m3LLkqOd022116; Mon, 21 Apr 2008 23:46:52 +0200 (MEST) (envelope-from arno) To: Jeremy Chadwick References: <20080421094718.GY25623@hub.freebsd.org> <20080421154333.GA96237@eos.sc1.parodius.com> From: "Arno J. Klaassen" Date: 21 Apr 2008 23:46:52 +0200 In-Reply-To: <20080421154333.GA96237@eos.sc1.parodius.com> Message-ID: Lines: 106 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.168]); Mon, 21 Apr 2008 23:46:55 +0200 (CEST) X-Virus-Scanned: ClamAV 0.92/6865/Mon Apr 21 17:43:29 2008 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 480D0B4E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 480D0B4E.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ X-j-chkmail-Score: MSGID : 480D0B4E.000 on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.014 -> S=0.014 X-j-chkmail-Status: Ham Cc: Clayton Milos , Mike Tancsa , stable@freebsd.org, net@freebsd.org Subject: Re: nfs-server silent data corruption 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, 21 Apr 2008 21:46:58 -0000 re, Jeremy Chadwick writes: > On Mon, Apr 21, 2008 at 04:52:55PM +0200, Arno J. Klaassen wrote: > > Kris Kennaway writes: > > > Uh, you're getting server-side data corruption, it could definitely be > > > because of the memory you added. > > > > yop, though I'm still not convinced the memory is bad (the very same > > Kingston ECC as the 2*1G in use for about half a year already) : > > Can you download and run memtest86 on this system, with the added 2G ECC > insalled? memtest86 doesn't guarantee showing signs of memory problems, > but in most cases it'll start spewing errors almost immediately. it finished in a bit less than 3 hours without a single error/warning I feel pretty confident all memory is fine > One thing I did notice in the motherboard manual below is something > called "Hammer Configuration". It appears to default to 800MHz, but > there's an "Auto" choice. Does using Auto fix anything? Nope > > I added it directly to the 2nd CPU (diagram on page 9 of > > http://www.tyan.com/manuals/m_s2895_101.pdf) and the problem > > seems to be the interaction between nfe0 and powerd .... : > > That board is the weirdest thing I've seen in years. ;) I agree I lifted (?) my eye-brows the first time I saw that diagram > Two separate CPUs using a single (shared) memory controller, two > separate (and different!) nVidia chipsets, a SMSC I/O controller > probably used for serial and parallel I/O, two separate nVidia NICs with > Marvell PHYs (yet somehow you can bridge the two NICs and PHYs?), two > separate PCI-e busses (each associated with a separate nVidia chipset), > two separate PCI-X busses... the list continues. some may say "it's just four wheels, an engine and a steer", she looks different compared to most others > I know you don't need opinions at this point, but what a behemoth. I > can't imagine that thing running reliably. though it does ;) (till the day I decided she deserved a -stable upgrade and 2 more gigs ...) > > - if I stop powerd, problems go away > > This would imply that clock frequency stepping is somehow attributing > itself to the corruption. I don't see any BIOS options for controlling > things related to AMD's Cool-n-Quiet or PowerNow! feature, which is > usually what handles this. you can turn it on/off; anyway, the problem *seems* easy to reproduce when freq drops quickly form 2600Mhz to 1000Mhz .... I just inspected a few corrupted copies, but out of 10-200Mbytes just 1 byte was 0 iso \t > > - I let run powerd but turn of txcsum and tso4 on the interface, > > the problem is a lot harder to produce (if ever this gives > > a hint to anyone) > > Possibly shared interrupts are causing problems? don't think so; I first had two Promise TX4 cards in this box iso the Marvell 8port card; since I had problems with TX4 some time ago I first suspected them. The board is still running memtest86, but from the dmesg I posted I don't see a shared irq. > MSI/MSI-X doing > something odd? Have you tried disabling MSI/MSI-X and see if it makes a > difference? MSI is disabled as is PCI-e Error reporting (or something like that) > > I think you mean "MAC LAN Bridge", according to the motherboard manual. > I'm not even sure what that really does; somehow trunks the two NICs > together to give you the equivalent of 2000mbit of traffic? I don't > know. probably; I never tried ;) I need the second NIC for a seperate subnet > Does the corruption you see go away if you install a separate NIC (e.g. > an Intel NIC) in a PCI or PCI-e slot, and disable the onboard NICs > (should be "MAC LAN: Disable" on both the primary and slave)? Don't have one available right now (for a 2U server). I will test if I do not find another solution. Thanx, Arno From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 23:38:46 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 05F7C1065670; Mon, 21 Apr 2008 23:38:46 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id CBFF58FC0C; Mon, 21 Apr 2008 23:38:45 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.11.16.99] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 21 Apr 2008 16:08:19 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 2C5F2486; Mon, 21 Apr 2008 15:50:14 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.11.18.52]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 1232645D; Mon, 21 Apr 2008 15:50:14 -0700 (PDT) Received: from mail-irva-13.broadcom.com (mail-irva-13.broadcom.com [10.11.16.103]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id GUN32433; Mon, 21 Apr 2008 15:49:55 -0700 (PDT) Received: from NT-IRVA-0751.brcm.ad.broadcom.com (nt-irva-0751 [10.8.194.65]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 4A20D74D00; Mon, 21 Apr 2008 15:49:55 -0700 (PDT) Received: from IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) by NT-IRVA-0751.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 15:49:55 -0700 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.9.200.129]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 21 Apr 2008 15:49:55 -0700 From: "David Christensen" To: "rihad@mail.ru" , "freebsd-net@freebsd.org" Date: Mon, 21 Apr 2008 15:49:56 -0700 Thread-Topic: bce(4) polling support? Thread-Index: AcijnLUaSOte75lEQtWSrQtSQUZY3gAZSAPQ Message-ID: <5D267A3F22FD854F8F48B3D2B523819324F08AA497@IRVEXCHCCR01.corp.ad.broadcom.com> References: <480C5679.8060904@mail.ru> In-Reply-To: <480C5679.8060904@mail.ru> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 21 Apr 2008 22:49:55.0179 (UTC) FILETIME=[0475FBB0:01C8A402] X-WSS-ID: 6413C1E84YC29810355-02-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-drivers@freebsd.org" , "freebsd-hardware@freebsd.org" Subject: RE: bce(4) polling 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: Mon, 21 Apr 2008 23:38:46 -0000 > Just wondering if someone's been working on POLLING support for bce(4) > Broadcom NetXtreme II (BCM5706/BCM5708) PCI/PCIe Gigabit Ethernet > adapter driver? AFAIK late in 2006 brueffer@ decided[*] to remove the > erroneous polling(4) man entry claiming bce support... and that's it. > Any advancements since then? > > [*] http://monkey.org/freebsd/archive/freebsd-net/200612/msg00004.html The only advancement is that I am taking the current code out of the driver since it's never really been tested or validated. No current plans to add the support back in any time soon. Dave From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 12:32: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 8AFAA106566C for ; Tue, 22 Apr 2008 12:32:16 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 35F928FC15 for ; Tue, 22 Apr 2008 12:32:16 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id 9B8305EA6; Tue, 22 Apr 2008 16:32:14 +0400 (MSD) Date: Tue, 22 Apr 2008 16:31:34 +0400 From: Igor Sysoev To: freebsd-net@FreeBSD.org Message-ID: <20080422123134.GK60108@rambler-co.ru> References: <20071116154019.GE93422@rambler-co.ru> <20071117065908.T65479@delplex.bde.org> <20071117071053.GA18091@rambler-co.ru> <20071117194615.L67319@delplex.bde.org> <20080421202038.GK54256@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20080421202038.GK54256@rambler-co.ru> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: bge loader tunables 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, 22 Apr 2008 12:32:16 -0000 On Tue, Apr 22, 2008 at 12:20:38AM +0400, Igor Sysoev wrote: > Finally I have tested your second (without debug stuff) patch in > production environment (~45K in/out packets) on FreeBSD 7.0-STABLE. > I think it should be commited. > > I use my usual static settings in /etc/sysctl.conf: > > dev.bge.0.dyncoal_max_intr_freq=0 > # > dev.bge.0.rx_coal_ticks=500 > dev.bge.0.tx_coal_ticks=10000 > dev.bge.0.rx_max_coal_bds=64 > dev.bge.0.tx_max_coal_bds=128 > # apply the above parameters > dev.bge.0.program_coal=0 > > and have about only 1700-1900 interrupts per second. > > The only issue was at boot time: > > dev.bge.0.dyncoal_max_intr_freq: 10000 -> 0 > dev.bge.0.rx_coal_ticks: 0 -> 500 > dev.bge.0.tx_coal_ticks: 1000000 -> 10000 > dev.bge.0.rx_max_coal_bds: 128 -> 64 > dev.bge.0.tx_max_coal_bds: 384 -> 128 > ... > bge0: flags =8843 metric 0 mtu 1500 > options=9b > ... > Local package initialization: > ... > dev.bge.0.rx_coal_ticks: 150 -> 500 > > When disabling dyncoal_max_intr_freq at bge UPing resets rx_coal_ticks to 150. I has to use dev.bge.0.program_coal=1 in /etc/sysctl.conf, otherwise /etc/rc.d/sysctl does not call it at all. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 13:46: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 31B89106566B; Tue, 22 Apr 2008 13:46:30 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from n120.sc0.he.tucows.com (smtpout1098.sc0.he.tucows.com [64.97.144.98]) by mx1.freebsd.org (Postfix) with ESMTP id E28FB8FC16; Tue, 22 Apr 2008 13:46:29 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from sc0-out03.emaildefenseservice.com (64.97.131.2) by n120.sc0.he.tucows.com (7.2.069.1) id 476BFC81017CE7C5; Tue, 22 Apr 2008 13:46:29 +0000 X-SpamScore: 2 X-Spamcatcher-Summary: 2, 0, 0, 19ae3dd2d0a2a85b, fe71ce1fe1bfd227, eagletree@hughes.net, -, RULES_HIT:355:379:541:564:599:601:945:966:967:973:980:988:989:1028:1260:1261:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1766:1792:2194:2196:2199:2200:2377:2393:2525:2551:2553:2559:2563:2682:2685:2693:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3354:3636:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:4250: 4362:4385:4860:5007:6119:7652:7679:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none, TSO:0 X-Spamcatcher-Explanation: Received: from [192.168.0.3] (dpc6744118153.direcpc.com [67.44.118.153]) (Authenticated sender: eagletree@hughes.net) by sc0-out03.emaildefenseservice.com (Postfix) with ESMTP; Tue, 22 Apr 2008 13:46:22 +0000 (UTC) In-Reply-To: References: <48087C98.8060600@delphij.net> <382258DB-13B8-4108-B8F4-157F247A7E4B@hughes.net> <20080420103258.D67663@fledge.watson.org> <33AC96BF-B9AC-4303-9597-80BC341B7309@hughes.net> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chris Pratt Date: Tue, 22 Apr 2008 06:35:38 -0700 To: gnn@freebsd.org X-Mailer: Apple Mail (2.753) Cc: Robert Watson , net@freebsd.org Subject: Re: zonelimit issues... 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, 22 Apr 2008 13:46:30 -0000 On Apr 21, 2008, at 12:43 AM, gnn@freebsd.org wrote: > ...snip > > Well there are plenty of us motivated to get at these issues. Can you > do me a favor and characterize your traffic a bit? Is it mostly TCP, The traffic that seems to take us out is TCP port 80. I'll make a generalized guess but it does seem to follow. We freeze on one of two dramatically heavy use days for our industry (Sunday and Monday evening). The hang will actually occur on Monday or Tuesday following these days if sufficient traffic hits us. It has not always followed this pattern but most frequently. There is always a high presence of high frequency attacks of various sorts. For example referer spam posts which hit us hard on our busy evenings. So it is TCP and I would presume we usually have the establishment of many useless sessions that could cause us to bump up against limits and cause exhaustion coupled with our real traffic peaks. This thread has given me several things to try and I'm adjusting (e.g., nmbclusters) upward to see what happens. I should also mention that this system has the natural limitations on it's traffic ceiling of two T1s on two NICs and a 3rd LAN NIC fielding continuous round-robin mysql replication and rsync style mirroring. It uses two bge interfaces and one server type em interface. It's always troubled me that the zonelimit issues have always been associated with higher volume circuits (in what I've read). But since our issue is very directly related to traffic levels and seem to occur at times where my monitors show us way over committed on the two outward facing T1s, I'm still going to proceed with the adjustments and see if it increases our survivability. Thanks for your time on this. > or heavily UDP or some sort of mix? The issues I see are UDP based, > which is less surprising as UDP has no backpressure and it is easy to > over commit the system by upping the socket buffer space allocated > without upping the number of clusters to compensate. > > Best, > George > > _______________________________________________ > 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 22 15:20: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 EBD541065670 for ; Tue, 22 Apr 2008 15:20:04 +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 C65588FC24 for ; Tue, 22 Apr 2008 15:20:04 +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 m3MFK4r1046160 for ; Tue, 22 Apr 2008 15:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3MFK4K8046159; Tue, 22 Apr 2008 15:20:04 GMT (envelope-from gnats) Date: Tue, 22 Apr 2008 15:20:04 GMT Message-Id: <200804221520.m3MFK4K8046159@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: petunin1@legis.krsn.ru Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: petunin1@legis.krsn.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2008 15:20:05 -0000 The following reply was made to PR kern/122839; it has been noted by GNATS. From: petunin1@legis.krsn.ru To: bug-followup@FreeBSD.org, 4pr@legis.krsn.ru, bms@FreeBSD.org Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Tue, 22 Apr 2008 22:52:53 +0800 Hi. I cold't find any rtl8139 based adapters at me, so i tryed to play with 3com 3c905-tx (rev. A, as printed on the board, with controller chip "Parallel Tasking 3com 40-0336-004 9750s 04749555 LUCENT 40-03364" ) and OFFICE CONNECT 3csoho100-tx (also rev. a with controller chip "Parallel tasking II perfomance 3com 40-0483-004 0111t 42433437 AGERE 40-04834") The system detected both of them as XL0 and XL1 network devices. And, with first card (3com 3c905-tx) xl0 multicast task routing started working just fine and as expected. But with another card (soho office connect) multicast routnig still do not working, and problem seems to be exact the same as with em and msk drivers. (mrouting working only in promiscious mode). I've downloaded latest intel's driver for FreeBSD7 (6.8.7) and tryed to use it, but with no luck. Problem still exist. So, as it seems to me, it is not a em driver problem. I fink, it is imposiible, what such different drivers, as xl, em and msk were was broken simultaneously and identically. As my colleague says, when we both take a brief look at the source codes of em driver, it seems some card have a hardware filter, and some do not have it. So, if the card's filter programmed correctly (by the driver), multicast working task working just fine, and if not, we have a problems. On latest intel's driver 6.8.7 we have commented a few string on the code, after what, multicast routing started to work correctly. But i fink, it's a wrong way, so i asking for help again, if someone can help me to investigate the source of the problem and fix it by the right way. What we have changed: central-gw# diff if_em.c.orig if_em.c 2337c2337 < if (mcnt >= MAX_NUM_MULTICAST_ADDRESSES) { --- > // if (mcnt >= MAX_NUM_MULTICAST_ADDRESSES) { 2341,2343c2341,2343 < } else < e1000_update_mc_addr_list(&adapter->hw, mta, < mcnt, 1, adapter->hw.mac.rar_entry_count); --- > // } else > // e1000_update_mc_addr_list(&adapter->hw, mta, > // mcnt, 1, adapter->hw.mac.rar_entry_count); in that part of if_em.c file: /********************************************************************* * Multicast Update * * This routine is called whenever multicast address list is updated. * **********************************************************************/ static void em_set_multi(struct adapter *adapter) { struct ifnet *ifp = adapter->ifp; struct ifmultiaddr *ifma; u32 reg_rctl = 0; u8 mta[512]; /* Largest MTS is 4096 bits */ int mcnt = 0; IOCTL_DEBUGOUT("em_set_multi: begin"); if (adapter->hw.mac.type == e1000_82542 && adapter->hw.revision_id == E1000_REVISION_2) { reg_rctl = E1000_READ_REG(&adapter->hw, E1000_RCTL); if (adapter->hw.bus.pci_cmd_word & CMD_MEM_WRT_INVALIDATE) e1000_pci_clear_mwi(&adapter->hw); reg_rctl |= E1000_RCTL_RST; E1000_WRITE_REG(&adapter->hw, E1000_RCTL, reg_rctl); msec_delay(5); } IF_ADDR_LOCK(ifp); TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { if (ifma->ifma_addr->sa_family != AF_LINK) continue; if (mcnt == MAX_NUM_MULTICAST_ADDRESSES) break; bcopy(LLADDR((struct sockaddr_dl *)ifma->ifma_addr), &mta[mcnt * ETH_ADDR_LEN], ETH_ADDR_LEN); mcnt++; } IF_ADDR_UNLOCK(ifp); // if (mcnt >= MAX_NUM_MULTICAST_ADDRESSES) { reg_rctl = E1000_READ_REG(&adapter->hw, E1000_RCTL); reg_rctl |= E1000_RCTL_MPE; E1000_WRITE_REG(&adapter->hw, E1000_RCTL, reg_rctl); // } else // e1000_update_mc_addr_list(&adapter->hw, mta, // mcnt, 1, adapter->hw.mac.rar_entry_count); if (adapter->hw.mac.type == e1000_82542 && adapter->hw.revision_id == E1000_REVISION_2) { reg_rctl = E1000_READ_REG(&adapter->hw, E1000_RCTL); reg_rctl &= ~E1000_RCTL_RST; E1000_WRITE_REG(&adapter->hw, E1000_RCTL, reg_rctl); msec_delay(5); if (adapter->hw.bus.pci_cmd_word & CMD_MEM_WRT_INVALIDATE) e1000_pci_set_mwi(&adapter->hw); } } Thank you From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 16:00: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 7E3241065670 for ; Tue, 22 Apr 2008 16:00:04 +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 549A18FC17 for ; Tue, 22 Apr 2008 16:00:04 +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 m3MG04bq049136 for ; Tue, 22 Apr 2008 16:00:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3MG04Ym049135; Tue, 22 Apr 2008 16:00:04 GMT (envelope-from gnats) Date: Tue, 22 Apr 2008 16:00:04 GMT Message-Id: <200804221600.m3MG04Ym049135@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Bruce M. Simpson" Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Bruce M. Simpson" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2008 16:00:04 -0000 The following reply was made to PR kern/122839; it has been noted by GNATS. From: "Bruce M. Simpson" To: petunin1@legis.krsn.ru Cc: bug-followup@FreeBSD.org, 4pr@legis.krsn.ru Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Tue, 22 Apr 2008 16:39:01 +0100 petunin1@legis.krsn.ru wrote: > ... > So, as it seems to me, it is not a em driver problem. I fink, it is > imposiible, what such different drivers, as xl, em and msk were was broken > simultaneously and identically. > Without seeing reproducible results, I couldn't comment either way. > As my colleague says, when we both take a brief look at the source codes > of em driver, it seems some card have a hardware filter, and some do not > have it. So, if the card's filter programmed correctly (by the driver), > multicast working task working just fine, and if not, we have a problems. > Yes. It's regrettable that not all devices support the IFF_ALLMULTI feature, nor that it is supported correctly and consistently where it is supported. For example, wi(4) has never supported IFF_ALLMULTI correctly. The network stack has no notion that a card with IFF_MULTICAST capability can't support IFF_ALLMULTI. The way to fix it is to add support for emulating it using IFF_PROMISC. This was part of the motivation behind the M_PROMISC change to ether_input() last year, which allows the input path to tell if it received frames which it otherwise wouldn't. It was largely added to avoid introducing layer 2 loops with vlan(4) and if_bridge(4). This use of IFF_PROMISC has to be reference counted however. What would also help in tidying that piece of code up would be to get rid of the special case of carp(4)'s emulated addresses by tying this into a common API. Unfortunately I don't have free time to actually do this work at the moment, but I am happy to review patches. > On latest intel's driver 6.8.7 we have commented a few string on the code, > after what, multicast routing started to work correctly. But i fink, it's > a wrong way, so i asking for help again, if someone can help me to > investigate the source of the problem and fix it by the right way. > Tony Ackerman (tackerman@FreeBSD.org) is still listed as em(4) maintainer according to MAINTAINERS, last I heard Jack Vogel (jfv@FreeBSD.org) was actually involved. The MAINTAINERS file should probably be updated. It is probably best if you contact Jack about em(4) directly. Thanks. BMS From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 16:03:27 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 A093E106564A for ; Tue, 22 Apr 2008 16:03:27 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [IPv6:2001:418:1::39]) by mx1.freebsd.org (Postfix) with ESMTP id 72E868FC17 for ; Tue, 22 Apr 2008 16:03:27 +0000 (UTC) (envelope-from randy@psg.com) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JoKxq-000Obi-V3 for freebsd-net@freebsd.org; Tue, 22 Apr 2008 16:03:27 +0000 Message-ID: <480E0C4D.30909@psg.com> Date: Wed, 23 Apr 2008 01:03:25 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: FreeBSD Net X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: ifconfig ath0 unable to get channel information 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, 22 Apr 2008 16:03:27 -0000 current of Apr 21 23:09 gmt. soekris 5501 with metrix minipci. this worked in build of 31 march. # ifconfig ath0 channel 11 ssid rgnet-aden wep wepkey thirteenletrs weptxkey 1 mediaopt hostap up ifconfig: unable to get channel information # ifconfig ath0 channel 11 ssid rgnet-aden wep wepkey thirteenletrs weptxkey 1 ifconfig: unable to get channel information hostapd not running as just wep nothing fancy yet kernel built with # Wireless NIC cards device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. boots as May 21 00:01:30 soek0 kernel: ath0: mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on pci0 May 21 00:01:30 soek0 kernel: ath0: [ITHREAD] May 21 00:01:30 soek0 kernel: ath0: WARNING: using obsoleted if_watchdog interfa ce May 21 00:01:30 soek0 kernel: ath0: mac 5.9 phy 4.3 radio 3.6 i can see it bouncing trying to come up # athstats 30929 data frames received 14 mib overflow interrupts 0M current transmit rate 20586 rx failed 'cuz of bad CRC 689 rx failed 'cuz of PHY err 689 CCK restart 1 switched default/rx antenna Antenna profile: [1] tx 0 rx 30929 randy From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 16:37: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 80B4E1065670 for ; Tue, 22 Apr 2008 16:37:55 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 313C48FC15 for ; Tue, 22 Apr 2008 16:37:55 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id BE0D62BC56; Wed, 23 Apr 2008 04:19:25 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciL56IDdWH1s; Wed, 23 Apr 2008 04:19:21 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Wed, 23 Apr 2008 04:19:21 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id E9F141142D; Wed, 23 Apr 2008 04:19:18 +1200 (NZST) Date: Wed, 23 Apr 2008 04:19:18 +1200 From: Andrew Thompson To: Randy Bush Message-ID: <20080422161918.GC83310@citylink.fud.org.nz> References: <480E0C4D.30909@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <480E0C4D.30909@psg.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD Net Subject: Re: ifconfig ath0 unable to get channel information 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, 22 Apr 2008 16:37:55 -0000 On Wed, Apr 23, 2008 at 01:03:25AM +0900, Randy Bush wrote: > current of Apr 21 23:09 gmt. soekris 5501 with metrix minipci. this > worked in build of 31 march. > > # ifconfig ath0 channel 11 ssid rgnet-aden wep wepkey thirteenletrs > weptxkey 1 mediaopt hostap up > ifconfig: unable to get channel information > # ifconfig ath0 channel 11 ssid rgnet-aden wep wepkey thirteenletrs > weptxkey 1 > ifconfig: unable to get channel information Wireless has been updated for vap (multi-bss) support, see http://lists.freebsd.org/pipermail/freebsd-current/2008-April/085012.html What you need to do is 'ifconfig wlan0 create wlandev ath0' and then use the wlan0 interface as you did before. Andrew From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 16:58:38 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 A726D106566B for ; Tue, 22 Apr 2008 16:58:38 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id DA0CD8FC0A for ; Tue, 22 Apr 2008 16:58:37 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 1681 invoked from network); 22 Apr 2008 16:58:36 -0000 Received: from unknown (HELO ?10.0.0.199?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 22 Apr 2008 16:58:36 -0000 Message-ID: <480E1933.30501@acm.poly.edu> Date: Tue, 22 Apr 2008 12:58:27 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------050102030107010209070406" Subject: if_bridge/if_em packet corruption on last bridged em interface in SPAN 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: Tue, 22 Apr 2008 16:58:38 -0000 This is a multi-part message in MIME format. --------------050102030107010209070406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, list. We needed to replicate a gigabit SPAN port on a Cisco switch, and, due to the fact that gigabit Ethernet hubs don't seem to exist and that other devices that perform a similar function are costly, I've built my own in the form of a FreeBSD 7.0-RELEASE/amd64 machine. Its motherboard is an MSI K9A2 Platinum and its CPU an AMD Athlon X2 BE-2400. It has four dual-port PCI-E Intel gigabit Ethernet controllers, one single-port PCI-E Intel gigabit Ethernet controller, and one PCI Intel gigabit Ethernet controller. There is an if_bridge device with em4 added to it via "addm" and the eight other em interfaces added to it via "span". So, all traffic received on em4 should be sent out all other em interfaces. To test out the functionality, I used the em4 interface to generate some light ICMP traffic and made sure it could be seen on the other interfaces. I noticed that the last interface on the bridge was sending out slightly corrupted traffic. By last interface, I mean em0 here: bridge0: flags=8843 metric 0 mtu 1500 ether 6a:14:34:4f:87:45 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: em4 flags=143 member: em9 flags=8 member: em8 flags=8 member: em7 flags=8 member: em6 flags=8 member: em5 flags=8 member: em3 flags=8 member: em2 flags=8 member: em1 flags=8 member: em0 flags=8 By slightly corrupted, I mean this: 12:37:36.807117 IP 10.0.0.106 > 10.0.0.1: ICMP echo request, id 23557, seq 139, length 64 12:37:36.807436 IP truncated-ip - 21420 bytes missing! 10.0.0.1 > 10.0.0.106: ICMP echo reply, id 23557, seq 139, length 21484 12:37:37.808061 IP 10.0.0.106 > 10.0.0.1: ICMP echo request, id 23557, seq 140, length 64 12:37:37.808441 IP truncated-ip - 21420 bytes missing! 10.0.0.1 > 10.0.0.106: ICMP echo reply, id 23557, seq 140, length 21484 12:37:37.963351 STP 802.1d, Config, Flags [none], bridge-id 8000.00:03:9f:8d:38:07.8009, length 43 12:37:38.809115 IP 10.0.0.106 > 10.0.0.1: ICMP echo request, id 23557, seq 141, length 64 12:37:38.809329 IP truncated-ip - 21420 bytes missing! 10.0.0.1 > 10.0.0.106: ICMP echo reply, id 23557, seq 141, length 21484 12:37:39.810008 IP 10.0.0.106 > 10.0.0.1: ICMP echo request, id 23557, seq 142, length 64 12:37:39.810333 IP truncated-ip - 16300 bytes missing! 10.0.0.1 > 10.0.0.106: ICMP echo reply, id 23557, seq 142, length 16364 12:37:39.963378 STP 802.1d, Config, Flags [none], bridge-id 8000.00:03:9f:8d:38:07.8009, length 43 12:37:40.811013 IP 10.0.0.106 > 10.0.0.1: ICMP echo request, id 23557, seq 143, length 64 12:37:40.811402 IP truncated-ip - 21420 bytes missing! 10.0.0.1 > 10.0.0.106: ICMP echo reply, id 23557, seq 143, length 21484 The corruption goes away when I run "tcpdump -n -i em0" and returns when I kill it. If I remove em0 from the bridge, the corruption begins to occur with em1 (when it previously did not), and so forth--it always happens with the last interface on the bridge. The machine runs a GENERIC kernel. Attached are its dmesg, pciconf -lv, and ifconfig output. Thanks. -Boris --------------050102030107010209070406 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #0: Wed Apr 16 20:08:13 UTC 2008 root@:/usr/obj/usr/src/sys/HUB Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) X2 Dual Core Processor BE-2400 (2300.18-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 2140438528 (2041 MB) avail memory = 2065874944 (1970 MB) ACPI APIC Table: <122107 APIC0947> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard acpi0: <122107 RSDT0947> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 em0: port 0x8800-0x881f mem 0xfdee0000-0xfdefffff,0xfdec0000-0xfdedffff irq 18 at device 0.0 on pci1 em0: Using MSI interrupt em0: Ethernet address: 00:15:17:71:40:b0 em0: [FILTER] em1: port 0x8400-0x841f mem 0xfde80000-0xfde9ffff,0xfde60000-0xfde7ffff irq 19 at device 0.1 on pci1 em1: Using MSI interrupt em1: Ethernet address: 00:15:17:71:40:b1 em1: [FILTER] pcib2: at device 3.0 on pci0 pci2: on pcib2 em2: port 0x9800-0x981f mem 0xfdfe0000-0xfdffffff,0xfdfc0000-0xfdfdffff irq 19 at device 0.0 on pci2 em2: Using MSI interrupt em2: Ethernet address: 00:15:17:71:3f:64 em2: [FILTER] em3: port 0x9400-0x941f mem 0xfdf80000-0xfdf9ffff,0xfdf60000-0xfdf7ffff irq 16 at device 0.1 on pci2 em3: Using MSI interrupt em3: Ethernet address: 00:15:17:71:3f:65 em3: [FILTER] pcib3: at device 4.0 on pci0 pci3: on pcib3 em4: port 0xa800-0xa81f mem 0xfe0e0000-0xfe0fffff,0xfe0c0000-0xfe0dffff irq 16 at device 0.0 on pci3 em4: Using MSI interrupt em4: Ethernet address: 00:15:17:6a:ff:81 em4: [FILTER] pcib4: at device 5.0 on pci0 pci4: on pcib4 re0: port 0xb800-0xb8ff mem 0xfe1ff000-0xfe1fffff irq 17 at device 0.0 on pci4 re0: Using 2 MSI messages miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:92:af:d7:ae re0: [FILTER] re0: [FILTER] pcib5: at device 11.0 on pci0 pci5: on pcib5 em5: port 0xc800-0xc81f mem 0xfe2e0000-0xfe2fffff,0xfe2c0000-0xfe2dffff irq 19 at device 0.0 on pci5 em5: Using MSI interrupt em5: Ethernet address: 00:15:17:71:45:6e em5: [FILTER] em6: port 0xc400-0xc41f mem 0xfe280000-0xfe29ffff,0xfe260000-0xfe27ffff irq 16 at device 0.1 on pci5 em6: Using MSI interrupt em6: Ethernet address: 00:15:17:71:45:6f em6: [FILTER] pcib6: at device 12.0 on pci0 pci6: on pcib6 em7: port 0xd800-0xd81f mem 0xfe3e0000-0xfe3fffff,0xfe3c0000-0xfe3dffff irq 16 at device 0.0 on pci6 em7: Using MSI interrupt em7: Ethernet address: 00:15:17:71:45:4c em7: [FILTER] em8: port 0xd400-0xd41f mem 0xfe380000-0xfe39ffff,0xfe360000-0xfe37ffff irq 17 at device 0.1 on pci6 em8: Using MSI interrupt em8: Ethernet address: 00:15:17:71:45:4d em8: [FILTER] pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib7: at device 20.4 on pci0 pci7: on pcib7 vgapci0: mem 0xfe400000-0xfe7fffff,0xfebe0000-0xfebeffff irq 22 at device 2.0 on pci7 em9: port 0xe400-0xe43f mem 0xfeba0000-0xfebbffff,0xfeb80000-0xfeb9ffff irq 21 at device 3.0 on pci7 em9: Ethernet address: 00:1b:21:10:1e:bb em9: [FILTER] acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled ad0: FAILURE - SET_MULTI status=51 error=4 ad0: 9787MB at ata0-master UDMA100 ad1: FAILURE - SET_MULTI status=51 error=4 ad1: 9787MB at ata0-slave UDMA100 SMP: AP CPU #1 Launched! GEOM_MIRROR: Device mirror/boot launched (2/2). Trying to mount root from ufs:/dev/mirror/boots1 bridge0: Ethernet address: 6a:14:34:4f:87:45 em4: link state changed to UP --------------050102030107010209070406 Content-Type: text/plain; name="ifconfig.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ifconfig.txt" em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:71:40:b0 media: Ethernet autoselect status: no carrier em1: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:71:40:b1 media: Ethernet autoselect status: no carrier em2: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:71:3f:64 media: Ethernet autoselect status: no carrier em3: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:71:3f:65 media: Ethernet autoselect status: no carrier em4: flags=8943 metric 0 mtu 1500 options=198 ether 00:15:17:6a:ff:81 inet 10.0.0.106 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet autoselect (100baseTX ) status: active re0: flags=8802 metric 0 mtu 1500 options=9b ether 00:1d:92:af:d7:ae media: Ethernet autoselect (10baseT/UTP ) status: no carrier em5: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:71:45:6e media: Ethernet autoselect status: no carrier em6: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:71:45:6f media: Ethernet autoselect status: no carrier em7: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:71:45:4c media: Ethernet autoselect status: no carrier em8: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:71:45:4d media: Ethernet autoselect status: no carrier em9: flags=8843 metric 0 mtu 1500 options=9b ether 00:1b:21:10:1e:bb media: Ethernet autoselect status: no carrier lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 bridge0: flags=8843 metric 0 mtu 1500 ether 6a:14:34:4f:87:45 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: em4 flags=143 member: em9 flags=8 member: em8 flags=8 member: em7 flags=8 member: em6 flags=8 member: em5 flags=8 member: em3 flags=8 member: em2 flags=8 member: em1 flags=8 member: em0 flags=8 --------------050102030107010209070406 Content-Type: text/plain; name="pciconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pciconf.txt" hostb0@pci0:0:0:0: class=0x060000 card=0x59561002 chip=0x59561002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RD790 GFX Dual Slot' class = bridge subclass = HOST-PCI pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' device = 'RD790 PCI to PCI bridge (external gfx0 port A)' class = bridge subclass = PCI-PCI pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' device = 'RD790 PCI to PCI bridge (external gfx0 port B)' class = bridge subclass = PCI-PCI pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' class = bridge subclass = PCI-PCI pcib4@pci0:0:5:0: class=0x060400 card=0x59561002 chip=0x597b1002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' device = 'RD790 PCI to PCI bridge (PCIe gpp port B)' class = bridge subclass = PCI-PCI pcib5@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' device = 'RD790 PCI to PCI bridge (external gfx1 port A)' class = bridge subclass = PCI-PCI pcib6@pci0:0:12:0: class=0x060400 card=0x59561002 chip=0x59811002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' device = 'RD790 PCI to PCI bridge (external gfx1 port B)' class = bridge subclass = PCI-PCI none0@pci0:0:20:0: class=0x0c0500 card=0x73761462 chip=0x43851002 rev=0x14 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'IXP SB600 SMBUS Controller' class = serial bus subclass = SMBus atapci0@pci0:0:20:1: class=0x01018a card=0x73761462 chip=0x438c1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'IXP SB600 ATA Controller' class = mass storage subclass = ATA isab0@pci0:0:20:3: class=0x060100 card=0x73761462 chip=0x438d1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'IXP SB600 PCI to LPC Bridge' class = bridge subclass = PCI-ISA pcib7@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' device = 'IXP SB600 PCI to PCI Bridge' class = bridge subclass = PCI-PCI hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron Address Map' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI em0@pci0:1:0:0: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet em1@pci0:1:0:1: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet em2@pci0:2:0:0: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet em3@pci0:2:0:1: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet em4@pci0:3:0:0: class=0x020000 card=0x10828086 chip=0x107d8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet re0@pci0:4:0:0: class=0x020000 card=0x376c1462 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet em5@pci0:5:0:0: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet em6@pci0:5:0:1: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet em7@pci0:6:0:0: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet em8@pci0:6:0:1: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet vgapci0@pci0:7:2:0: class=0x030000 card=0x00000000 chip=0x96601023 rev=0xd3 hdr=0x00 vendor = 'Trident Microsystems' device = 'TGUI9660XGi/968x/938x GUI Accelerator' class = display subclass = VGA em9@pci0:7:3:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 GT' class = network subclass = ethernet --------------050102030107010209070406-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 17:38: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 310031065672 for ; Tue, 22 Apr 2008 17:38:32 +0000 (UTC) (envelope-from vijjus@rocketmail.com) Received: from web33502.mail.mud.yahoo.com (web33502.mail.mud.yahoo.com [68.142.206.151]) by mx1.freebsd.org (Postfix) with SMTP id E03B68FC12 for ; Tue, 22 Apr 2008 17:38:31 +0000 (UTC) (envelope-from vijjus@rocketmail.com) Received: (qmail 20728 invoked by uid 60001); 22 Apr 2008 17:38:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=S0wvPjaMfotF/ECyLHvlJ4Hcpo39A02fpkoAvvCIaK0LCNFJlyGgV/+4sbu0CPx4Bsy95Cb1rQYxAju7jbJGiXjP1axdrW+0QsV3sZhRkA3qnteKv0ICpHMXq8k0oPmk0NBqhRd8SH83VwCbSQ+CbQDCqY8DGJIwjZzzMEUwInY=; X-YMail-OSG: C_aUJWwVM1lVI9pZk.pBmBj7TOzjAIy4Qu3myfP8wk.E87MzCcs7aYgDhTisG27jiQ-- Received: from [198.95.226.230] by web33502.mail.mud.yahoo.com via HTTP; Tue, 22 Apr 2008 10:38:31 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Tue, 22 Apr 2008 10:38:31 -0700 (PDT) From: vijay singh To: Robert Watson , Brooks Davis MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <340035.20572.qm@web33502.mail.mud.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: Regarding if_alloc() 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, 22 Apr 2008 17:38:32 -0000 ----- Original Message ---- From: Robert Watson To: Brooks Davis Cc: vijay singh ; freebsd-net@freebsd.org Sent: Sunday, April 20, 2008 2:27:15 AM Subject: Re: Regarding if_alloc() On Fri, 18 Apr 2008, Brooks Davis wrote: > On Thu, Apr 17, 2008 at 06:35:23PM -0700, vijay singh wrote: >> Hi all. How do we avoid a race in populating the ifindex_table? Id this is >> a TODO, as it seems from the code below, would it be acceptable if I wrote >> a patch and reused the ifnet_lock [IFNET_WLOCK, IFNET_WUNLOCK]? > > Locking if_index management with ifnet_lock should be ok. Ideally we should > probably be using ALLOC_UNR(9) to manage if_indexes instead of this rather > expensive loop. > > Be aware, that if_index generation is least of the issues in this area. The > if_grow() call is much riskier since it changes the value of the global > ifnet pointer which I'm not sure we can afford to lock. It would be worth > experimenting with rmlocks to see what the impact if of locking would be. > > I'm serious tempted to kill if_grow in favor of some sort of if_index_max > tunable. I've seen a number of reports of panics that may well be traceable to races in if_index handling, and have looked a bit at possible fixes. Quite a few uses of if_index are inherently racy, as they rely on stability of the index value, which of course can't be guaranteed with removable interfaces. I think a reasonable interim fix would be to protect all use of the byindex arrays using the ifnet lock, but remember that the read methods, not just the write methods, need protection, and as such should move from being macros in if_var.h to functions in if.c. if_grow is probably OK if this is done right, but it will need to be set up to drop the lock, grow, re-aquire, and re-validate assumptions (i.e., repeat the search for a free index and loop if it fails to find one). Once the read methods are using the lock also, we should seriously consider converting it to an rwlock. We can probably also un-publicize at least one of the byindex lookup routines (the dev lookup, which is needed only in if.c). This would prevent races on modifying and evaluating the index array, but not on disappearing cdevs and ifnets, which are a separate problem, and one that probably is exercised significanty less. The reports I've seen appear to have only to do with pulling the array out from other consumers while in use. >> Robert, I am working on the patch, but I had a few questions. If we drop the lock while if_grow() is running, how do we prevent a second caller, blocked in if_alloc() to start scanning the ifindex_table, and end up deciding to grow it again. In other words, we need to stall the ifindex_table scan in if_alloc() till if_grow() has achieved finished. Since if_grow() will be called relatively infrequently, should we consider holding the lock through the routine? Your comments and suggestions are welcome. -vijay ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 17:40: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 D1F67106564A; Tue, 22 Apr 2008 17:40:01 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6D87F8FC20; Tue, 22 Apr 2008 17:40:01 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m3MHeDxH033078; Tue, 22 Apr 2008 12:40:13 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m3MHeDDv033077; Tue, 22 Apr 2008 12:40:13 -0500 (CDT) (envelope-from brooks) Date: Tue, 22 Apr 2008 12:40:13 -0500 From: Brooks Davis To: vijay singh Message-ID: <20080422174013.GA31959@lor.one-eyed-alien.net> References: <340035.20572.qm@web33502.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <340035.20572.qm@web33502.mail.mud.yahoo.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 22 Apr 2008 12:40:13 -0500 (CDT) Cc: freebsd-net@FreeBSD.org, Brooks Davis , Robert Watson Subject: Re: Regarding if_alloc() 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, 22 Apr 2008 17:40:01 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 22, 2008 at 10:38:31AM -0700, vijay singh wrote: >=20 >=20 > ----- Original Message ---- > From: Robert Watson > To: Brooks Davis > Cc: vijay singh ; freebsd-net@freebsd.org > Sent: Sunday, April 20, 2008 2:27:15 AM > Subject: Re: Regarding if_alloc() >=20 >=20 > On Fri, 18 Apr 2008, Brooks Davis wrote: >=20 > > On Thu, Apr 17, 2008 at 06:35:23PM -0700, vijay singh wrote: > >> Hi all. How do we avoid a race in populating the ifindex_table? Id thi= s is=20 > >> a TODO, as it seems from the code below, would it be acceptable if I w= rote=20 > >> a patch and reused the ifnet_lock [IFNET_WLOCK, IFNET_WUNLOCK]? > > > > Locking if_index management with ifnet_lock should be ok. Ideally we s= hould=20 > > probably be using ALLOC_UNR(9) to manage if_indexes instead of this rat= her=20 > > expensive loop. > > > > Be aware, that if_index generation is least of the issues in this area.= The=20 > > if_grow() call is much riskier since it changes the value of the global= =20 > > ifnet pointer which I'm not sure we can afford to lock. It would be wo= rth=20 > > experimenting with rmlocks to see what the impact if of locking would b= e. > > > > I'm serious tempted to kill if_grow in favor of some sort of if_index_m= ax=20 > > tunable. >=20 > I've seen a number of reports of panics that may well be traceable to rac= es in=20 > if_index handling, and have looked a bit at possible fixes. Quite a few = uses=20 > of if_index are inherently racy, as they rely on stability of the index v= alue,=20 > which of course can't be guaranteed with removable interfaces. >=20 > I think a reasonable interim fix would be to protect all use of the byind= ex=20 > arrays using the ifnet lock, but remember that the read methods, not just= the=20 > write methods, need protection, and as such should move from being macros= in=20 > if_var.h to functions in if.c. if_grow is probably OK if this is done ri= ght,=20 > but it will need to be set up to drop the lock, grow, re-aquire, and=20 > re-validate assumptions (i.e., repeat the search for a free index and loo= p if=20 > it fails to find one). Once the read methods are using the lock also, we= =20 > should seriously consider converting it to an rwlock. We can probably al= so=20 > un-publicize at least one of the byindex lookup routines (the dev lookup,= =20 > which is needed only in if.c). >=20 > This would prevent races on modifying and evaluating the index array, but= not=20 > on disappearing cdevs and ifnets, which are a separate problem, and one t= hat=20 > probably is exercised significanty less. The reports I've seen appear to= have=20 > only to do with pulling the array out from other consumers while in use. >=20 >=20 > >> >=20 > Robert, I am working on the patch, but I had a few questions. If we > drop the lock while if_grow() is running, how do we prevent a second > caller, blocked in if_alloc() to start scanning the ifindex_table, and > end up deciding to grow it again. In other words, we need to stall > the ifindex_table scan in if_alloc() till if_grow() has achieved > finished. Since if_grow() will be called relatively infrequently, > should we consider holding the lock through the routine? Your comments > and suggestions are welcome. You can't hold locks over malloc calls. -- Brooks --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIDiL8XY6L6fI4GtQRApcjAKDTm1GAm9tEPH6EL/jolHaUEim7OwCguqWB UeYxLu9bgMC7YRaV8g772yo= =kqLE -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 19:51:27 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 9178B106575A; Tue, 22 Apr 2008 19:51:27 +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 2FCB08FC1C; Tue, 22 Apr 2008 19:51:26 +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 4920446B60; Tue, 22 Apr 2008 15:51:25 -0400 (EDT) Date: Tue, 22 Apr 2008 20:51:25 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: vijay singh In-Reply-To: <340035.20572.qm@web33502.mail.mud.yahoo.com> Message-ID: <20080422204551.P2206@fledge.watson.org> References: <340035.20572.qm@web33502.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Brooks Davis Subject: Re: Regarding if_alloc() 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, 22 Apr 2008 19:51:27 -0000 On Tue, 22 Apr 2008, vijay singh wrote: > Robert, I am working on the patch, but I had a few questions. If we drop the > lock while if_grow() is running, how do we prevent a second caller, blocked > in if_alloc() to start scanning the ifindex_table, and end up deciding to > grow it again. In other words, we need to stall the ifindex_table scan in > if_alloc() till if_grow() has achieved finished. Since if_grow() will be > called relatively infrequently, should we consider holding the lock through > the routine? Your comments and suggestions are welcome. Vijay, if_grow() will be called only infrequently, but we do need to handle it correctly. Usually code of this sort handles races in the following sort of optimistic way: LOCK(); while (need space) { LOCK(); allocate new space; UNLOCK(); if (new space > old space) install new space, free old space; else free new space; } use space; UNLOCK(); Basically, you need to gracefully handle the case where you released the lock, allocated the space, re-acquired the lock, and discovered someone else had done the same. The reason you need a while loop is that you may have rather seriously lost the race -- someone else may have allocated space, and then several someone elses may have then used the sapce, leaving you with less memory than you need, but still needing to allocate yet more memory. The above is not starvation free, but in practice the byindex table doesn't grow all that much, and should never trigger the race anyway :-). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 19:55: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 6F672106566B for ; Tue, 22 Apr 2008 19:55:04 +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 264978FC1A for ; Tue, 22 Apr 2008 19:55:03 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JoOZy-0003Vf-BU for freebsd-net@freebsd.org; Tue, 22 Apr 2008 19:55:02 +0000 Received: from 89-172-63-116.adsl.net.t-com.hr ([89.172.63.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Apr 2008 19:55:02 +0000 Received: from ivoras by 89-172-63-116.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Apr 2008 19:55:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Tue, 22 Apr 2008 21:54:47 +0200 Lines: 37 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB9DEE65892A2EA953EB4ABAC" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-63-116.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) X-Enigmail-Version: 0.95.6 Sender: news Cc: freebsd-questions@freebsd.org Subject: USB wireless AP? 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, 22 Apr 2008 19:55:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB9DEE65892A2EA953EB4ABAC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I'm planning to set up an AP by adding an USB wifi card to a 7.0-RELEASE = machine, and I'm interested in a couple of things: - First, hardware compatibility - AFAIK only some cards support AP mode? = Can anyone recommend such USB wireless hardware, preferably in terms of=20 product names instead of chip names? I see the following cards in a=20 local store: BANDRIDGE CWN4002G, CANYON WF-518D, CANYON WF-518, LINKSYS=20 WUSB54GC. - Are there any tips & tricks additional to the instructions on=20 http://www.freebsd.org/doc/en/books/handbook/network-wireless.html ? --------------enigB9DEE65892A2EA953EB4ABAC 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 iD8DBQFIDkKNldnAQVacBcgRAoYcAKCTDWrobh2tXa+6P5MvWWrVUX7ZSgCg/kmV AkNG2fZ0UIO+fYMe09PUlpw= =aq0X -----END PGP SIGNATURE----- --------------enigB9DEE65892A2EA953EB4ABAC-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 20:11:57 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 59C5B1065676 for ; Tue, 22 Apr 2008 20:11:57 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6C76B8FC0A for ; Tue, 22 Apr 2008 20:11:56 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 3945 invoked from network); 22 Apr 2008 20:11:55 -0000 Received: from unknown (HELO ?10.0.0.199?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 22 Apr 2008 20:11:55 -0000 Message-ID: <480E4681.5030608@acm.poly.edu> Date: Tue, 22 Apr 2008 16:11:45 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.9 (X11/20071208) 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, freebsd-questions@freebsd.org Subject: Re: USB wireless AP? 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, 22 Apr 2008 20:11:57 -0000 Do you know about http://ralink.rapla.net/? The RT2500-based cards listed there are supported by the ural(4) driver. There's a discouraging comment about using them for access points in the man page, though: CAVEATS The ural driver does not support automatic adaptation of the transmit speed in IBSS and HostAP operating modes. -Boris Ivan Voras wrote: > Hi, > > I'm planning to set up an AP by adding an USB wifi card to a > 7.0-RELEASE machine, and I'm interested in a couple of things: > > - First, hardware compatibility - AFAIK only some cards support AP > mode? Can anyone recommend such USB wireless hardware, preferably in > terms of product names instead of chip names? I see the following > cards in a local store: BANDRIDGE CWN4002G, CANYON WF-518D, CANYON > WF-518, LINKSYS WUSB54GC. > > - Are there any tips & tricks additional to the instructions on > http://www.freebsd.org/doc/en/books/handbook/network-wireless.html ? > From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 20:18: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 6F1C61065675 for ; Tue, 22 Apr 2008 20:18:24 +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 267A98FC16 for ; Tue, 22 Apr 2008 20:18:24 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JoOwU-0004gV-3a for freebsd-net@freebsd.org; Tue, 22 Apr 2008 20:18:18 +0000 Received: from 89-172-63-116.adsl.net.t-com.hr ([89.172.63.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Apr 2008 20:18:18 +0000 Received: from ivoras by 89-172-63-116.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Apr 2008 20:18:18 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Tue, 22 Apr 2008 22:18:05 +0200 Lines: 39 Message-ID: References: <480E4681.5030608@acm.poly.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig29A7FE6FEE728F2AB473D2CF" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-63-116.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) In-Reply-To: <480E4681.5030608@acm.poly.edu> X-Enigmail-Version: 0.95.6 Sender: news Cc: freebsd-questions@freebsd.org Subject: Re: USB wireless AP? 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, 22 Apr 2008 20:18:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig29A7FE6FEE728F2AB473D2CF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Boris Kochergin wrote: > Do you know about http://ralink.rapla.net/? The RT2500-based cards=20 > listed there are supported by the ural(4) driver. There's a discouragin= g=20 > comment about using them for access points in the man page, though: >=20 > CAVEATS > The ural driver does not support automatic adaptation of the transm= it > speed in IBSS and HostAP operating modes. That's too bad - it seems the Linsys' card is supported by ural. I=20 looked around for Linux information on the same topic, and given the=20 problems they have, I think I'll even settle for IBSS. Are there any=20 practical differences between HOSTAP and IBSS when used by a very small=20 number of users? --------------enig29A7FE6FEE728F2AB473D2CF 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 iD8DBQFIDkf+ldnAQVacBcgRAgt4AKDWZHLUDPHksoYZBhxRfC3hQfq6gQCfSQyw 4cDp1EvlD8+2UR8iViPJy9k= =ZCcm -----END PGP SIGNATURE----- --------------enig29A7FE6FEE728F2AB473D2CF-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 22:50: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 A87B41065676 for ; Tue, 22 Apr 2008 22:50:03 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0D98FC19 for ; Tue, 22 Apr 2008 22:50:03 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 5210 invoked from network); 22 Apr 2008 22:50:02 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 22 Apr 2008 22:50:02 -0000 Message-ID: <480E6B90.7090200@acm.poly.edu> Date: Tue, 22 Apr 2008 18:49:52 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <480E4681.5030608@acm.poly.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: USB wireless AP? 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, 22 Apr 2008 22:50:03 -0000 Ivan Voras wrote: > Boris Kochergin wrote: >> Do you know about http://ralink.rapla.net/? The RT2500-based cards >> listed there are supported by the ural(4) driver. There's a >> discouraging comment about using them for access points in the man >> page, though: >> >> CAVEATS >> The ural driver does not support automatic adaptation of the >> transmit >> speed in IBSS and HostAP operating modes. > > That's too bad - it seems the Linsys' card is supported by ural. I > looked around for Linux information on the same topic, and given the > problems they have, I think I'll even settle for IBSS. Are there any > practical differences between HOSTAP and IBSS when used by a very > small number of users? > > I've never used IBSS, but I have enough spare 802.11 hardware to try it out. I'll let you know. -Boris From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 23:47: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 06AA5106564A for ; Tue, 22 Apr 2008 23:47:13 +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 7ADAE8FC0A for ; Tue, 22 Apr 2008 23:47:12 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 46825 invoked from network); 22 Apr 2008 22:51:45 -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 ; 22 Apr 2008 22:51:45 -0000 Message-ID: <480E7901.5000804@freebsd.org> Date: Wed, 23 Apr 2008 01:47:13 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Mark Hills References: <20080420025010.GJ73016@server.vk2pj.dyndns.org> <480BBD7E.8010700@freebsd.org> <480C9AC6.8090802@freebsd.org> In-Reply-To: <480C9AC6.8090802@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 22 Apr 2008 23:47:13 -0000 Andre Oppermann wrote: > Mark Hills wrote: >> On Mon, 21 Apr 2008, Andre Oppermann wrote: >> >>> Mark Hills wrote: >>>> On Sun, 20 Apr 2008, Peter Jeremy wrote: >> >>>>> I can't explain the problem but it definitely looks like a resource >>>>> starvation issue within the kernel. >>>> >>>> I've traced the source of the ETIMEDOUT within the kernel to >>>> tcp_timer_rexmt() in tcp_timer.c: >>>> >>>> if (++tp->t_rxtshift > TCP_MAXRXTSHIFT) { >>>> tp->t_rxtshift = TCP_MAXRXTSHIFT; >>>> tcpstat.tcps_timeoutdrop++; >>>> tp = tcp_drop(tp, tp->t_softerror ? >>>> tp->t_softerror : ETIMEDOUT); >>>> goto out; >>>> } >>> >>> Yes, this is related to either lack of mbufs to create a segment >>> or a problem in sending it. That may be full interface queue, a >>> bandwidth manager (dummynet) or some firewall internally rejecting >>> the segment (ipfw, pf). Do you run any firewall in stateful mode? >> >> There's no firewall running. >> >>>> I'm new to FreeBSD, but it seems to implies that it's reaching a >>>> limit of a number of retransmits of sending ACKs on the TCP >>>> connection receiving the inbound data? But I checked this using >>>> tcpdump on the server and could see no retransmissions. >>> >>> When you have internal problems the segment never makes it to the >>> wire and thus you wont see it in tcpdump. >>> >>> Please report the output of 'netstat -s -p tcp' and 'netstat -m'. >> >> Posted below. You can see it it in there: "131 connections dropped by >> rexmit timeout" >> >>>> As a test, I ran a simulation with the necessary changes to increase >>>> TCP_MAXRXTSHIFT (including adding appropriate entries to >>>> tcp_sync_backoff[] and tcp_backoff[]) and it appeared I was able to >>>> reduce the frequency of the problem occurring, but not to a usable >>>> level. >>> >>> Possible causes are timers that fire too early. Resource starvation >>> (you are doing a lot of traffic). Or of course some bug in the code. >> >> As I said in my original email, the data transfer doesn't stop or >> splutter, it's simply cut mid-flow. Sounds like something happening >> prematurely. >> >> Thanks for the help, > > The output doesn't show any obvious problems. I have to write some > debug code to run on your system. I'll do that later today if time > permits. Otherwise tomorrow. http://people.freebsd.org/~andre/tcp_output-error-log.diff Please apply this patch and enable the sysctl net.inet.tcp.log_debug=1 and report any output. You likely get some (normal) noise from syncache. What we are looking for is reports from tcp_output. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Apr 23 05:31:04 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 AA0241065670; Wed, 23 Apr 2008 05:31:04 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id A0F528FC17; Wed, 23 Apr 2008 05:31:04 +0000 (UTC) (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 m3N5V0hu073780; Tue, 22 Apr 2008 22:31:04 -0700 (PDT) (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 m3N5UtaP051259; Tue, 22 Apr 2008 22:30:55 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from xxxu000142.ocv.ne.jp.neville-neil.com (xxxu000142.ocv.ne.jp [203.205.0.142]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m3N5UsBa076781; Tue, 22 Apr 2008 22:30:55 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Wed, 23 Apr 2008 14:30:50 +0900 Message-ID: From: gnn@freebsd.org To: Chris Pratt In-Reply-To: References: <48087C98.8060600@delphij.net> <382258DB-13B8-4108-B8F4-157F247A7E4B@hughes.net> <20080420103258.D67663@fledge.watson.org> <33AC96BF-B9AC-4303-9597-80BC341B7309@hughes.net> 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 Cc: Robert Watson , net@freebsd.org Subject: Re: zonelimit issues... 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, 23 Apr 2008 05:31:04 -0000 At Tue, 22 Apr 2008 06:35:38 -0700, Chris Pratt wrote: > > > On Apr 21, 2008, at 12:43 AM, gnn@freebsd.org wrote: > > > ...snip > > > > Well there are plenty of us motivated to get at these issues. Can you > > do me a favor and characterize your traffic a bit? Is it mostly TCP, > > The traffic that seems to take us out is TCP port 80. I'll make a > generalized guess but it does seem to follow. We freeze on one of > two dramatically heavy use days for our industry (Sunday and Monday > evening). The hang will actually occur on Monday or Tuesday > following these days if sufficient traffic hits us. It has not > always followed this pattern but most frequently. There is always a > high presence of high frequency attacks of various sorts. For > example referer spam posts which hit us hard on our busy > evenings. So it is TCP and I would presume we usually have the > establishment of many useless sessions that could cause us to bump > up against limits and cause exhaustion coupled with our real traffic > peaks. > Interesting, but with TCP it should be easier to tune this, in particular because TCP has backoff once a packet drops. I gather you are using facilities, like accept filters, that make it easy to drop less useful traffic? > This thread has given me several things to try and I'm adjusting (e.g., > nmbclusters) upward to see what happens. Sounds good. Using netstat -m and netstat -an are a good way to watch this issue. -m is the number of mbufs/clusters in use and -an will show you all sockets, but what you want to check on s the number of bytes in the recv and send socket buffers, which are the 2nd and 3rd columns. > I should also mention that this system has the natural limitations > on it's traffic ceiling of two T1s on two NICs and a 3rd LAN NIC > fielding continuous round-robin mysql replication and rsync style > mirroring. It uses two bge interfaces and one server type em > interface. It's always troubled me that the zonelimit issues have > always been associated with higher volume circuits (in what I've > read). But since our issue is very directly related to traffic > levels and seem to occur at times where my monitors show us way over > committed on the two outward facing T1s, I'm still going to proceed > with the adjustments and see if it increases our survivability. Since zonelimit is a state reached when your system is out of resources it makes sense that the higher the traffic the sooner you'll reach it. > Thanks for your time on this. > No problem, it's what I like to do :-) Best, George From owner-freebsd-net@FreeBSD.ORG Wed Apr 23 08:49:30 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 9CA24106566B for ; Wed, 23 Apr 2008 08:49:30 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 5A94F8FC19 for ; Wed, 23 Apr 2008 08:49:30 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so732251anc.13 for ; Wed, 23 Apr 2008 01:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=/S7hZSOH1yRhwP2zBFmX3tIZCjsUHCUE6qoAGiOkgLo=; b=R6w82DS8bxt1/6AOlhWRB1baN+k3Vb70temTy5pnKmP4zcSlnkdpKGgODYm39Qfk9GUNZ6CeBmdei41Kdx2GLdf/qcXH5V7CLYR2BCvWLSslLPTU13dj3ZVravu5A9LvXka2n6tVq/Xn39UWkXYPxJ/2aXzEpvufNmnr/rR1e14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SP35IeOvi5BxS3A/eokJIGs3wiE1vPXZcGoo3OFrHrRq/TUps/EdzUS1qOMpziqZjfySGpccPUyHzJQbgJfsGZkKjTu3grzjRnT/OuQ0gA/evzZmXEbW7RL2LwugU8myZjp4xPsb10R9Y/Iw2/56zBhUikocvKVKzjwpdG1C45A= Received: by 10.100.194.5 with SMTP id r5mr2232867anf.146.1208938830944; Wed, 23 Apr 2008 01:20:30 -0700 (PDT) Received: by 10.100.48.5 with HTTP; Wed, 23 Apr 2008 01:20:30 -0700 (PDT) Message-ID: Date: Wed, 23 Apr 2008 16:20:30 +0800 From: "Sepherosa Ziehau" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <480E4681.5030608@acm.poly.edu> Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: USB wireless AP? 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, 23 Apr 2008 08:49:30 -0000 On Wed, Apr 23, 2008 at 4:18 AM, Ivan Voras wrote: > Boris Kochergin wrote: > > > Do you know about http://ralink.rapla.net/? The RT2500-based cards listed > there are supported by the ural(4) driver. There's a discouraging comment > about using them for access points in the man page, though: > > > > CAVEATS > > The ural driver does not support automatic adaptation of the transmit > > speed in IBSS and HostAP operating modes. In HOSTAP mode, you can have one roaming STA, or you can have several STAs if they stay in almost same TX/RX condition. This limitation is primarily due to ural (same applies to rum) hardware does not have per-packet (or at least per-peer) TX try/fail counters. This can't be fixd by driver. Best Regards, sephe -- Live Free or Die From owner-freebsd-net@FreeBSD.ORG Wed Apr 23 13:50: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 651FF106566C for ; Wed, 23 Apr 2008 13:50:04 +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 45BB38FC17 for ; Wed, 23 Apr 2008 13:50:04 +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 m3NDo3Uj075548 for ; Wed, 23 Apr 2008 13: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 m3NDo37x075547; Wed, 23 Apr 2008 13:50:03 GMT (envelope-from gnats) Date: Wed, 23 Apr 2008 13:50:03 GMT Message-Id: <200804231350.m3NDo37x075547@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Tomas Svensson Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tomas Svensson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2008 13:50:04 -0000 The following reply was made to PR kern/122839; it has been noted by GNATS. From: Tomas Svensson To: bug-followup@FreeBSD.org, 4pr@legis.krsn.ru Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Wed, 23 Apr 2008 15:16:56 +0200 There is an obvious bug in the em driver regarding promiscuous multicast (ALLMULTI), and I believe the following is the correct solution: Index: if_em.c =================================================================== RCS file: /usr/local/cvsroot/FreeBSD7/sys/dev/em/if_em.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 if_em.c --- if_em.c 3 Mar 2008 13:50:01 -0000 1.1.1.1 +++ if_em.c 23 Apr 2008 10:43:23 -0000 @@ -1080,7 +1080,7 @@ if (ifp->if_flags & IFF_UP) { if ((ifp->if_drv_flags & IFF_DRV_RUNNING)) { if ((ifp->if_flags ^ adapter->if_flags) & - IFF_PROMISC) { + (IFF_PROMISC | IFF_ALLMULTI)) { em_disable_promisc(adapter); em_set_promisc(adapter); } It fixes the problem for me on FreeBSD 7.0 and FreeBSD 6.2. Best regards, -Tomas From owner-freebsd-net@FreeBSD.ORG Wed Apr 23 17:12: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 3A5DD1065675; Wed, 23 Apr 2008 17:12:44 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 06DD78FC15; Wed, 23 Apr 2008 17:12:43 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.73.129] (jn@stealth.jnielsen.net [74.218.226.254]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id m3NGbskI009888; Wed, 23 Apr 2008 12:37:56 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-questions@freebsd.org Date: Wed, 23 Apr 2008 12:37:52 -0400 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804231237.52953.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, Ivan Voras Subject: Re: USB wireless AP? 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, 23 Apr 2008 17:12:44 -0000 On Wednesday 23 April 2008 11:57:28 am Ivan Voras wrote: > I've found a perfect match for my needs: D-Link DWL-G122, with the > "rum" driver. Not a single problem so far, everything works as > documented. Truly a plug and play experience. > > I'm just curious about one more thing: I wish to set up a "b/g" > network, so both b and g devices can connect. Apparently this is set up > via the "mode" argument to ifconfig, which accepts "11g" and "11b" but > not the obvious "11bg". Any pointers on this? You can either omit the "mode" argument altogether and get both supported by default, or just specify "11g", which will also support both. I typically omit the mode unless I want to limit things to only 11b. JN From owner-freebsd-net@FreeBSD.ORG Wed Apr 23 19:54: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 C5F04106567B for ; Wed, 23 Apr 2008 19:54:14 +0000 (UTC) (envelope-from yusheng.huang@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6A68FC15 for ; Wed, 23 Apr 2008 19:54:14 +0000 (UTC) (envelope-from yusheng.huang@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id m3NJbWx4029142 for ; Wed, 23 Apr 2008 12:37:33 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Apr 2008 12:37:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2861 TCP Congestion Window Validation Thread-Index: AcileXaUNFycIbGdSlyDu9UaEQavSw== From: "Huang, Yusheng" To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: RFC 2861 TCP Congestion Window Validation 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, 23 Apr 2008 19:54:14 -0000 Hi, =20 I was wondering if "RFC 2861 TCP Congestion Window Validation" been implemented in FreeBSD? =20 Thanks! =20 -yusheng =20 From owner-freebsd-net@FreeBSD.ORG Wed Apr 23 20:15: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 8CFD6106567C for ; Wed, 23 Apr 2008 20:15:16 +0000 (UTC) (envelope-from js@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.freebsd.org (Postfix) with ESMTP id D56708FC1A for ; Wed, 23 Apr 2008 20:15:15 +0000 (UTC) (envelope-from js@saltmine.radix.net) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id m3NJSFkE017529; Wed, 23 Apr 2008 15:28:15 -0400 (EDT) Received: (from root@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id m3NJSE89017526; Wed, 23 Apr 2008 15:28:14 -0400 (EDT) Received: from mail1.radix.net (mail1.radix.net [207.192.128.31]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id m3MMp1kE028166 for ; Tue, 22 Apr 2008 18:51:01 -0400 (EDT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail1.radix.net (8.13.4/8.13.4) with ESMTP id m3MMp0wp028596 for ; Tue, 22 Apr 2008 18:51:01 -0400 (EDT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 325E515849F; Tue, 22 Apr 2008 22:50:09 +0000 (UTC) (envelope-from owner-freebsd-questions@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id C244910656B2; Tue, 22 Apr 2008 22:50:08 +0000 (UTC) (envelope-from owner-freebsd-questions@freebsd.org) Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A61DF1065670 for ; Tue, 22 Apr 2008 22:50:03 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4BCCE8FC15 for ; Tue, 22 Apr 2008 22:50:03 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 5210 invoked from network); 22 Apr 2008 22:50:02 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 22 Apr 2008 22:50:02 -0000 Message-ID: <480E6B90.7090200@acm.poly.edu> Date: Tue, 22 Apr 2008 18:49:52 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <480E4681.5030608@acm.poly.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-questions@freebsd.org Errors-To: owner-freebsd-questions@freebsd.org Cc: freebsd-net@freebsd.org Subject: Re: USB wireless AP? 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: Wed, 23 Apr 2008 20:15:16 -0000 Ivan Voras wrote: > Boris Kochergin wrote: >> Do you know about http://ralink.rapla.net/? The RT2500-based cards >> listed there are supported by the ural(4) driver. There's a >> discouraging comment about using them for access points in the man >> page, though: >> >> CAVEATS >> The ural driver does not support automatic adaptation of the >> transmit >> speed in IBSS and HostAP operating modes. > > That's too bad - it seems the Linsys' card is supported by ural. I > looked around for Linux information on the same topic, and given the > problems they have, I think I'll even settle for IBSS. Are there any > practical differences between HOSTAP and IBSS when used by a very > small number of users? > > I've never used IBSS, but I have enough spare 802.11 hardware to try it out. I'll let you know. -Boris _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 00:04: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 F34C5106567A; Thu, 24 Apr 2008 00:04:00 +0000 (UTC) (envelope-from mark@pogo.org.uk) Received: from metheny.ijneb.com (unknown [IPv6:2001:ba8:0:1ba:214:22ff:feb1:2693]) by mx1.freebsd.org (Postfix) with ESMTP id 9980B8FC15; Thu, 24 Apr 2008 00:04:00 +0000 (UTC) (envelope-from mark@pogo.org.uk) Received: from localhost ([127.0.0.1] ident=mark) by metheny.ijneb.com with esmtp (Exim 4.69) (envelope-from ) id 1JoowP-0007MP-GA; Thu, 24 Apr 2008 01:03:57 +0100 Date: Thu, 24 Apr 2008 01:03:57 +0100 (BST) From: Mark Hills To: Andre Oppermann In-Reply-To: <480E7901.5000804@freebsd.org> Message-ID: References: <20080420025010.GJ73016@server.vk2pj.dyndns.org> <480BBD7E.8010700@freebsd.org> <480C9AC6.8090802@freebsd.org> <480E7901.5000804@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: mark@pogo.org.uk Cc: Peter Jeremy , freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 24 Apr 2008 00:04:01 -0000 On Wed, 23 Apr 2008, Andre Oppermann wrote: > http://people.freebsd.org/~andre/tcp_output-error-log.diff > > Please apply this patch and enable the sysctl net.inet.tcp.log_debug=1 > and report any output. You likely get some (normal) noise from syncache. > What we are looking for is reports from tcp_output. Hi Andre, I've applied the patch and tested. Aside from syncache noise, I get a constant stream of 'error 55' (ENOBUFS?), once the number of connection gets to around 150 at 192kbps. TCP: [192.168.5.43]:52153 to [192.168.5.40]:8080; tcp_output: error 55 while sending 192.168.5.40 is the IP address of this host, running the server. I tried to correlate the point of the application receiving ETIMEDOUT with these messages, but that is tricky as it seems to be outputting a lot of messages, and multiple messages over eachother (see below). Because of the mention of no buffer space available, I checked the values of net.inet.tcp.sendbuf* and recvbuf*, and increased the max values with no effect. When I get time I will modify the kernel to print errors which aren't ENOBUFS to see if there are any others. But in the meantime, this sounds like a problem to me. Is that correct? Mark :8080; tcp_output: error 55 while sending TCP: [192.168.5.42]:57384T CtPo: [[119922..116688..55..4402]]::85048400;1 ttoc p[_1o9u2t.p1u6t8:. 5e.r4r0o]r: 8080;5 5t cwp_hoiultep uste:n deirnrgor 55 while sending TCP: [192.168.5.42]:57382 to [192.168.5.40]:8080; tcp_output: error 55 while sending TCP: [192.168.5.42]:57381 to [192.168.5.40]:8080; tcp_output: error 55 while sending TCP: [192.168.5.42]:57380 to [192.168.5.40]:8080; tcp_output: error 55 while sending From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 07:32: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 498B71065678 for ; Thu, 24 Apr 2008 07:32:45 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from svarun.infrax.si (syssvarun.infrax.si [89.212.81.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0B48FC18 for ; Thu, 24 Apr 2008 07:32:44 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from localhost (sysSvarun.infrax.si [89.212.81.4]) by svarun.infrax.si (Postfix) with ESMTP id 492E424AA3A for ; Thu, 24 Apr 2008 09:16:39 +0200 (CEST) Received: from svarun.infrax.si ([89.212.81.4]) by localhost (svarun.infrax.si [89.212.81.4]) (amavisd-maia, port 10024) with ESMTP id 93020-03 for ; Thu, 24 Apr 2008 09:16:32 +0200 (CEST) Received: from [192.168.15.2] (lk.84.20.249.154.dc.cable.static.lj-kabel.net [84.20.249.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejko@infrax.si) by svarun.infrax.si (Postfix) with ESMTP id 5D05C24A8AD for ; Thu, 24 Apr 2008 09:16:32 +0200 (CEST) Message-ID: <481033CC.5060508@skoberne.net> Date: Thu, 24 Apr 2008 09:16:28 +0200 From: =?ISO-8859-2?Q?Nejc_=A9koberne?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Subject: Jailed Samba not getting broadcasts 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, 24 Apr 2008 07:32:45 -0000 Hello, I am trying to run Samba server inside a jail and use NetBIOS broadcasts. Is there any way to let Samba "see" the broadcasts even if it is running in a jail? One guy at freebsd-questions hinted that jailed processes cannot see the broadcasts. If this is not possible at the moment, how about in future? Thanks, Nejc From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 08:33: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 104581065673 for ; Thu, 24 Apr 2008 08:33:59 +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 902C88FC12 for ; Thu, 24 Apr 2008 08:33:58 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 8845 invoked from network); 24 Apr 2008 07:38:16 -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 ; 24 Apr 2008 07:38:16 -0000 Message-ID: <481045F8.7090904@freebsd.org> Date: Thu, 24 Apr 2008 10:34:00 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Mark Hills References: <20080420025010.GJ73016@server.vk2pj.dyndns.org> <480BBD7E.8010700@freebsd.org> <480C9AC6.8090802@freebsd.org> <480E7901.5000804@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 24 Apr 2008 08:33:59 -0000 Mark Hills wrote: > On Wed, 23 Apr 2008, Andre Oppermann wrote: > >> http://people.freebsd.org/~andre/tcp_output-error-log.diff >> >> Please apply this patch and enable the sysctl net.inet.tcp.log_debug=1 >> and report any output. You likely get some (normal) noise from syncache. >> What we are looking for is reports from tcp_output. > > Hi Andre, I've applied the patch and tested. > > Aside from syncache noise, I get a constant stream of 'error 55' > (ENOBUFS?), once the number of connection gets to around 150 at 192kbps. > > TCP: [192.168.5.43]:52153 to [192.168.5.40]:8080; tcp_output: error 55 > while sending > > 192.168.5.40 is the IP address of this host, running the server. > > I tried to correlate the point of the application receiving ETIMEDOUT > with these messages, but that is tricky as it seems to be outputting a > lot of messages, and multiple messages over eachother (see below). > > Because of the mention of no buffer space available, I checked the > values of net.inet.tcp.sendbuf* and recvbuf*, and increased the max > values with no effect. > > When I get time I will modify the kernel to print errors which aren't > ENOBUFS to see if there are any others. But in the meantime, this sounds > like a problem to me. Is that correct? Yes. I'll investigate why you get ENOBUFS here despite your netstat -m output not showing any request denied. -- Andre > Mark > > > :8080; tcp_output: error 55 while sending > TCP: [192.168.5.42]:57384T CtPo: > [[119922..116688..55..4402]]::85048400;1 ttoc p[_1o9u2t.p1u6t8:. > 5e.r4r0o]r: 8080;5 5t cwp_hoiultep uste:n deirnrgor 55 while sending > TCP: [192.168.5.42]:57382 to [192.168.5.40]:8080; tcp_output: error 55 > while sending > TCP: [192.168.5.42]:57381 to [192.168.5.40]:8080; tcp_output: error 55 > while sending > TCP: [192.168.5.42]:57380 to [192.168.5.40]:8080; tcp_output: error 55 > while sending > > > From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 08:42: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 5EE5F106564A for ; Thu, 24 Apr 2008 08:42:49 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from svarun.infrax.si (syssvarun.infrax.si [89.212.81.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2A5618FC1B for ; Thu, 24 Apr 2008 08:42:49 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from localhost (sysSvarun.infrax.si [89.212.81.4]) by svarun.infrax.si (Postfix) with ESMTP id 5739824AA72 for ; Thu, 24 Apr 2008 10:42:47 +0200 (CEST) Received: from svarun.infrax.si ([89.212.81.4]) by localhost (svarun.infrax.si [89.212.81.4]) (amavisd-maia, port 10024) with ESMTP id 75186-09 for ; Thu, 24 Apr 2008 10:42:42 +0200 (CEST) Received: from [192.168.15.2] (lk.84.20.249.154.dc.cable.static.lj-kabel.net [84.20.249.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejko@infrax.si) by svarun.infrax.si (Postfix) with ESMTP id DCF7A24AA71 for ; Thu, 24 Apr 2008 10:42:42 +0200 (CEST) Message-ID: <481047FF.4080707@skoberne.net> Date: Thu, 24 Apr 2008 10:42:39 +0200 From: =?windows-1252?Q?Nejc_=8Akoberne?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <254549.19682.qm@web46005.mail.sp1.yahoo.com> In-Reply-To: <254549.19682.qm@web46005.mail.sp1.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Subject: Re: Jailed Samba not getting broadcasts 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, 24 Apr 2008 08:42:49 -0000 Hello Dewayne, > I have encountered a similar problem, when I configured a SAMBA PDC over > the wan (through IPSEC of course). You might like to consider using > these in your smb.conf: > hosts allow = 10.1. 10.2. > remote announce = 10.1.1.255 10.2.1.255 > remote browse sync = 10.1.1.255 10.2.1.255 I have tried that, but no luck. Still can't resolve the NetBIOS name using solely NetBIOS broadcasts. > If that doesn't solve the need, then perhaps you should modify > /etc/devfs.rules in your base system, to behave a little more > promiscuously, and include something like: > [devfsrules_samba_jail=6] > add include $devfsrules_hide_all > add include $devfsrules_unhide_basic > add include $devfsrules_unhide_login > add path bpf0 unhide I also tried that. Of course I also configured "devfsrules_samba_jail" policy for my jail. So now I can also tcpdump in my jail. But still, those broadcasts seem to be ignored by samba (although I can see them with tcpdump). This works for you? > Note the latter opens a potential security hole if someone breaches > samba jail, providing a means to tcpdump (...) your network This is not a great concern for me since this will be running locally. Thanks a lot for your help, Nejc From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 08:50: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 C1F251065707 for ; Thu, 24 Apr 2008 08:50:07 +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 9DC778FC2C for ; Thu, 24 Apr 2008 08:50: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 E48FD41C7A9; Thu, 24 Apr 2008 10:50: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 PbvHqRmBIzQb; Thu, 24 Apr 2008 10:50:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 9FE6941C7A8; Thu, 24 Apr 2008 10:50: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 77AB644487F; Thu, 24 Apr 2008 08:49:29 +0000 (UTC) Date: Thu, 24 Apr 2008 08:49:28 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: =?windows-1252?Q?Nejc_=8Akoberne?= In-Reply-To: <481047FF.4080707@skoberne.net> Message-ID: <20080424084727.G66744@maildrop.int.zabbadoz.net> References: <254549.19682.qm@web46005.mail.sp1.yahoo.com> <481047FF.4080707@skoberne.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Jailed Samba not getting broadcasts 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, 24 Apr 2008 08:50:07 -0000 On Thu, 24 Apr 2008, Nejc ?koberne wrote: Hi, > .. > seem to > be ignored by samba (although I can see them with tcpdump). This works for > you? so what kind of setup do you have? is the jail IP on a real interface or on loopback? is the jail IP an alias or a primary IP? what netmask does ifconfig show for this IP? Are you running single-IP jail as shipped with FreeBSD, or are you running with patches? /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 09:27:15 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 6B7611065689 for ; Thu, 24 Apr 2008 09:27:15 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from svarun.infrax.si (syssvarun.infrax.si [89.212.81.4]) by mx1.freebsd.org (Postfix) with ESMTP id 399308FC1E for ; Thu, 24 Apr 2008 09:27:15 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from localhost (sysSvarun.infrax.si [89.212.81.4]) by svarun.infrax.si (Postfix) with ESMTP id 5482924AA71; Thu, 24 Apr 2008 11:27:13 +0200 (CEST) Received: from svarun.infrax.si ([89.212.81.4]) by localhost (svarun.infrax.si [89.212.81.4]) (amavisd-maia, port 10024) with ESMTP id 32447-05; Thu, 24 Apr 2008 11:27:08 +0200 (CEST) Received: from [192.168.15.2] (lk.84.20.249.154.dc.cable.static.lj-kabel.net [84.20.249.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejko@infrax.si) by svarun.infrax.si (Postfix) with ESMTP id 96AC724AA3A; Thu, 24 Apr 2008 11:27:08 +0200 (CEST) Message-ID: <48105269.4040303@skoberne.net> Date: Thu, 24 Apr 2008 11:27:05 +0200 From: =?windows-1252?Q?Nejc_=8Akoberne?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <254549.19682.qm@web46005.mail.sp1.yahoo.com> <481047FF.4080707@skoberne.net> <20080424084727.G66744@maildrop.int.zabbadoz.net> In-Reply-To: <20080424084727.G66744@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Cc: freebsd-net@freebsd.org Subject: Re: Jailed Samba not getting broadcasts 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, 24 Apr 2008 09:27:15 -0000 Hi, > so what kind of setup do you have? Sorry, forgot to provide it. I am running latest Samba 3 on FreeBSD 7.0 server. You can get my smb.conf here: http://stuff.skoberne.net/smb.conf (without "remote" entries suggested by Dewayne) My rc.conf (relevant lines): ifconfig_rl0="192.168.15.198 netmask 255.255.255.0" jail_enable="YES" jail_sysvipc_allow="YES" jail_socket_unixiproute_only="NO" #=---------------------------- Jails ---------------------------=# jail_list="samba" #=--------------------------------------------------------------=# jail_samba_rootdir="/usr/jail/samba" jail_samba_hostname="samba.domain.local" jail_samba_ip="192.168.15.201" jail_samba_interface="rl0" jail_samba_devfs_enable="YES" jail_samba_procfs_enable="YES" jail_samba_devfs_ruleset="devfsrules_samba_jail" #=--------------------------------------------------------------=# My /etc/devfs.rules: [devfsrules_samba_jail=6] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login add path bpf0 unhide > is the jail IP on a real interface or on loopback? Real interface. "rl0" in my case. > is the jail IP an alias or a primary IP? Alias - how to make it primary IP? > what netmask does ifconfig show for this IP? Host: rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:40:f4:27:7e:a8 inet 192.168.15.198 netmask 0xffffff00 broadcast 192.168.15.255 inet 192.168.15.201 netmask 0xffffffff broadcast 192.168.15.201 media: Ethernet autoselect (100baseTX ) status: active Jail: rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:40:f4:27:7e:a8 inet 192.168.15.201 netmask 0xffffffff broadcast 192.168.15.201 media: Ethernet autoselect (100baseTX ) status: active Hmm, I guess this is the reason why Samba doesn't see the broadcasts - the mask in the jail is /32, not /24. I read somewhere this cannot be changed? > Are you running single-IP jail as shipped with FreeBSD, or are you > running with patches? Single ip jail. No patches. Thanks a lot, Nejc From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 09:33: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 A33071065684 for ; Thu, 24 Apr 2008 09:33:39 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from svarun.infrax.si (syssvarun.infrax.si [89.212.81.4]) by mx1.freebsd.org (Postfix) with ESMTP id 724928FC21 for ; Thu, 24 Apr 2008 09:33:39 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from localhost (sysSvarun.infrax.si [89.212.81.4]) by svarun.infrax.si (Postfix) with ESMTP id 1289F24A9F8; Thu, 24 Apr 2008 11:33:38 +0200 (CEST) Received: from svarun.infrax.si ([89.212.81.4]) by localhost (svarun.infrax.si [89.212.81.4]) (amavisd-maia, port 10024) with ESMTP id 51834-02; Thu, 24 Apr 2008 11:33:34 +0200 (CEST) Received: from [192.168.15.2] (lk.84.20.249.154.dc.cable.static.lj-kabel.net [84.20.249.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejko@infrax.si) by svarun.infrax.si (Postfix) with ESMTP id F1BF024A8AD; Thu, 24 Apr 2008 11:33:33 +0200 (CEST) Message-ID: <481053EA.3010705@skoberne.net> Date: Thu, 24 Apr 2008 11:33:30 +0200 From: =?windows-1252?Q?Nejc_=8Akoberne?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dewayne Geraghty , freebsd-net@freebsd.org References: <222904.28587.qm@web46005.mail.sp1.yahoo.com> In-Reply-To: <222904.28587.qm@web46005.mail.sp1.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Cc: Subject: Re: Jailed Samba not getting broadcasts 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, 24 Apr 2008 09:33:39 -0000 Hey, > The firewalling allows UDP137,138; TCP 139,445; and WINS is defined on > the client end; so name resolution occurs via the PDC. I'm afraid that Maybe this is the reason why it works for you. I don't want to use WINS, only NetBIOS broadcasts. Windows machines have no WINS server set up. Thanks, Nejc From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 09:42: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 AF6991065687 for ; Thu, 24 Apr 2008 09:42:52 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from svarun.infrax.si (syssvarun.infrax.si [89.212.81.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7FA278FC12 for ; Thu, 24 Apr 2008 09:42:52 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from localhost (sysSvarun.infrax.si [89.212.81.4]) by svarun.infrax.si (Postfix) with ESMTP id 6059624A9F8; Thu, 24 Apr 2008 11:42:50 +0200 (CEST) Received: from svarun.infrax.si ([89.212.81.4]) by localhost (svarun.infrax.si [89.212.81.4]) (amavisd-maia, port 10024) with ESMTP id 66224-02; Thu, 24 Apr 2008 11:42:40 +0200 (CEST) Received: from [192.168.15.2] (lk.84.20.249.154.dc.cable.static.lj-kabel.net [84.20.249.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejko@infrax.si) by svarun.infrax.si (Postfix) with ESMTP id 1C33824A8AD; Thu, 24 Apr 2008 11:42:40 +0200 (CEST) Message-ID: <4810560C.5060107@skoberne.net> Date: Thu, 24 Apr 2008 11:42:36 +0200 From: =?windows-1252?Q?Nejc_=8Akoberne?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dewayne Geraghty , freebsd-net@freebsd.org References: <249262.97716.qm@web46015.mail.sp1.yahoo.com> In-Reply-To: <249262.97716.qm@web46015.mail.sp1.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Cc: Subject: Re: Jailed Samba not getting broadcasts 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, 24 Apr 2008 09:42:52 -0000 Hey, > I think you've answered the question. Thanks Bjorn, I setup samba > within a jail a few years ago and had forgotten the interface setup. > Nejc, this is my interface config, the jail is at 10.1.2.46 > inside: flags=8843 mtu 1500 > options=1b > inet 10.1.2.2 netmask 0xffff0000 broadcast 10.1.255.255 > inet 10.1.5.88 netmask 0xffffffff broadcast 10.1.5.88 > inet 10.1.2.46 netmask 0xffffff00 broadcast 10.1.2.255 > ether 00:40:63:e4:5b:50 > media: Ethernet autoselect (1000baseTX ) > Enjoy :) Even if I answered my question, I still don't know how to set up this. :) Where can I configure the mask of the jail IP? How do you do it? Thanks, Nejc From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 09:50:00 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 35EC5106564A for ; Thu, 24 Apr 2008 09:50:00 +0000 (UTC) (envelope-from dewayne_freebsd@yahoo.com) Received: from n58.bullet.mail.sp1.yahoo.com (n58.bullet.mail.sp1.yahoo.com [98.136.44.46]) by mx1.freebsd.org (Postfix) with SMTP id 35B708FC16 for ; Thu, 24 Apr 2008 09:50:00 +0000 (UTC) (envelope-from dewayne_freebsd@yahoo.com) Received: from [216.252.122.217] by n58.bullet.mail.sp1.yahoo.com with NNFMP; 24 Apr 2008 09:37:31 -0000 Received: from [69.147.84.88] by t2.bullet.sp1.yahoo.com with NNFMP; 24 Apr 2008 09:37:31 -0000 Received: from [127.0.0.1] by omp204.mail.sp1.yahoo.com with NNFMP; 24 Apr 2008 09:37:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 372757.18857.bm@omp204.mail.sp1.yahoo.com Received: (qmail 5947 invoked by uid 60001); 24 Apr 2008 09:37:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=1l9iEKKTDu3Wcb35UTruyPnbEqReZSHugfX4WcAll6je0iFVxFSilv4OuYPqKGXGAyzc8wFnzlJZQZStpL688PbhfQU7lUglXbnnaJrbvrpAOA0IDb2uG72NeoO4uEo8PycHeqQ18NdlMWz5aPikNaQnRQ4eP2P+yWgT8YmxOkU=; X-YMail-OSG: 8p2jPggVM1mxpit2xI5mm297oqhWmaM.ebYBpRhHiFumKCYd9wMACm6p6LG1GVfxyZY7Yr5_qtUpciABdm.XbRLt5Wxdh8y7Nw-- Received: from [58.172.113.127] by web46015.mail.sp1.yahoo.com via HTTP; Thu, 24 Apr 2008 02:37:30 PDT Date: Thu, 24 Apr 2008 02:37:30 -0700 (PDT) From: Dewayne Geraghty To: Nejc "Škoberne" , "Bjoern A. Zeeb" In-Reply-To: <48105269.4040303@skoberne.net> MIME-Version: 1.0 Message-ID: <249262.97716.qm@web46015.mail.sp1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Jailed Samba not getting broadcasts 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, 24 Apr 2008 09:50:00 -0000 Nejc Škoberne wrote: Hi, > so what kind of setup do you have? Sorry, forgot to provide it. I am running latest Samba 3 on FreeBSD 7.0 server. You can get my smb.conf here: http://stuff.skoberne.net/smb.conf (without "remote" entries suggested by Dewayne) My rc.conf (relevant lines): ifconfig_rl0="192.168.15.198 netmask 255.255.255.0" jail_enable="YES" jail_sysvipc_allow="YES" jail_socket_unixiproute_only="NO" #=---------------------------- Jails ---------------------------=# jail_list="samba" #=--------------------------------------------------------------=# jail_samba_rootdir="/usr/jail/samba" jail_samba_hostname="samba.domain.local" jail_samba_ip="192.168.15.201" jail_samba_interface="rl0" jail_samba_devfs_enable="YES" jail_samba_procfs_enable="YES" jail_samba_devfs_ruleset="devfsrules_samba_jail" #=--------------------------------------------------------------=# My /etc/devfs.rules: [devfsrules_samba_jail=6] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login add path bpf0 unhide > is the jail IP on a real interface or on loopback? Real interface. "rl0" in my case. > is the jail IP an alias or a primary IP? Alias - how to make it primary IP? > what netmask does ifconfig show for this IP? Host: rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:40:f4:27:7e:a8 inet 192.168.15.198 netmask 0xffffff00 broadcast 192.168.15.255 inet 192.168.15.201 netmask 0xffffffff broadcast 192.168.15.201 media: Ethernet autoselect (100baseTX ) status: active Jail: rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:40:f4:27:7e:a8 inet 192.168.15.201 netmask 0xffffffff broadcast 192.168.15.201 media: Ethernet autoselect (100baseTX ) status: active Hmm, I guess this is the reason why Samba doesn't see the broadcasts - the mask in the jail is /32, not /24. I read somewhere this cannot be changed? > Are you running single-IP jail as shipped with FreeBSD, or are you > running with patches? Single ip jail. No patches. Thanks a lot, Nejc _______________________________________________ I think you've answered the question. Thanks Bjorn, I setup samba within a jail a few years ago and had forgotten the interface setup. Nejc, this is my interface config, the jail is at 10.1.2.46 inside: flags=8843 mtu 1500 options=1b inet 10.1.2.2 netmask 0xffff0000 broadcast 10.1.255.255 inet 10.1.5.88 netmask 0xffffffff broadcast 10.1.5.88 inet 10.1.2.46 netmask 0xffffff00 broadcast 10.1.2.255 ether 00:40:63:e4:5b:50 media: Ethernet autoselect (1000baseTX ) Enjoy :) --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 10:30:00 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 017521065673 for ; Thu, 24 Apr 2008 10:30:00 +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 8E7E88FC23 for ; Thu, 24 Apr 2008 10:29:58 +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 ESMTP id UAA14968; Thu, 24 Apr 2008 20:29:44 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 24 Apr 2008 20:29:43 +1000 (EST) From: Ian Smith To: =?windows-1252?Q?Nejc_=8Akoberne?= In-Reply-To: <48105269.4040303@skoberne.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: Jailed Samba not getting broadcasts 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, 24 Apr 2008 10:30:00 -0000 On Thu, 24 Apr 2008, [windows-1252] Nejc Škoberne wrote: > > what netmask does ifconfig show for this IP? > > Host: > > rl0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:40:f4:27:7e:a8 > inet 192.168.15.198 netmask 0xffffff00 broadcast 192.168.15.255 > inet 192.168.15.201 netmask 0xffffffff broadcast 192.168.15.201 > media: Ethernet autoselect (100baseTX ) > status: active > > Jail: > > rl0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:40:f4:27:7e:a8 > inet 192.168.15.201 netmask 0xffffffff broadcast 192.168.15.201 > media: Ethernet autoselect (100baseTX ) > status: active > > Hmm, I guess this is the reason why Samba doesn't see the broadcasts - the mask > in the jail is /32, not /24. I read somewhere this cannot be changed? I can't help wondering what would happen if you assigned the single jail IP to be the subnet's broadcast address, in this case 192.168.15.255 ? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 11:04: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 BBBF2106566C for ; Thu, 24 Apr 2008 11:04:07 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from svarun.infrax.si (syssvarun.infrax.si [89.212.81.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE658FC21 for ; Thu, 24 Apr 2008 11:04:07 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from localhost (sysSvarun.infrax.si [89.212.81.4]) by svarun.infrax.si (Postfix) with ESMTP id C976E24AA3A; Thu, 24 Apr 2008 13:04:04 +0200 (CEST) Received: from svarun.infrax.si ([89.212.81.4]) by localhost (svarun.infrax.si [89.212.81.4]) (amavisd-maia, port 10024) with ESMTP id 41843-10; Thu, 24 Apr 2008 13:04:00 +0200 (CEST) Received: from [192.168.15.2] (lk.84.20.249.154.dc.cable.static.lj-kabel.net [84.20.249.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejko@infrax.si) by svarun.infrax.si (Postfix) with ESMTP id 9D41424A9F8; Thu, 24 Apr 2008 13:04:00 +0200 (CEST) Message-ID: <4810691D.6050904@skoberne.net> Date: Thu, 24 Apr 2008 13:03:57 +0200 From: =?windows-1252?Q?Nejc_=8Akoberne?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Ian Smith , freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Cc: Subject: Re: Jailed Samba not getting broadcasts 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, 24 Apr 2008 11:04:07 -0000 Hey, > I can't help wondering what would happen if you assigned the single jail > IP to be the subnet's broadcast address, in this case 192.168.15.255 ? You mean if I did this: jail_samba_ip="192.168.15.255" ? I can't even ssh to the host then? And it doesn't work. Nejc From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 11:26: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 181B51065682 for ; Thu, 24 Apr 2008 11:26:32 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id E26778FC46 for ; Thu, 24 Apr 2008 11:26:31 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id E1C8619E023; Thu, 24 Apr 2008 13:26:30 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 99CEE19E019; Thu, 24 Apr 2008 13:26:28 +0200 (CEST) Message-ID: <48106E76.7030503@quip.cz> Date: Thu, 24 Apr 2008 13:26:46 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: =?windows-1252?Q?Nejc_=8Akoberne?= References: <254549.19682.qm@web46005.mail.sp1.yahoo.com> <481047FF.4080707@skoberne.net> <20080424084727.G66744@maildrop.int.zabbadoz.net> <48105269.4040303@skoberne.net> In-Reply-To: <48105269.4040303@skoberne.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: Jailed Samba not getting broadcasts 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, 24 Apr 2008 11:26:32 -0000 Nejc Škoberne wrote: > Hi, > >> so what kind of setup do you have? > > > Sorry, forgot to provide it. I am running latest Samba 3 on FreeBSD 7.0 > server. > You can get my smb.conf here: > > http://stuff.skoberne.net/smb.conf (without "remote" entries suggested > by Dewayne) > > My rc.conf (relevant lines): > > ifconfig_rl0="192.168.15.198 netmask 255.255.255.0" > jail_enable="YES" > jail_sysvipc_allow="YES" > jail_socket_unixiproute_only="NO" > > #=---------------------------- Jails ---------------------------=# > jail_list="samba" > #=--------------------------------------------------------------=# > jail_samba_rootdir="/usr/jail/samba" > jail_samba_hostname="samba.domain.local" > jail_samba_ip="192.168.15.201" > jail_samba_interface="rl0" > jail_samba_devfs_enable="YES" > jail_samba_procfs_enable="YES" > jail_samba_devfs_ruleset="devfsrules_samba_jail" > #=--------------------------------------------------------------=# Try not to use jail_samba_interface="rl0" for "auto aliasing" and add ifconfig_rl0_alias0="inet 192.168.15.201 netmask 255.255.255.0" This should give you inet 192.168.15.201 netmask 0xffffffff broadcast 192.168.15.255 in the ifconfig output (after restart) Miroslav Lachman From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 11:44:22 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 1F7721065670 for ; Thu, 24 Apr 2008 11:44:22 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from svarun.infrax.si (syssvarun.infrax.si [89.212.81.4]) by mx1.freebsd.org (Postfix) with ESMTP id E09C48FC1B for ; Thu, 24 Apr 2008 11:44:21 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from localhost (sysSvarun.infrax.si [89.212.81.4]) by svarun.infrax.si (Postfix) with ESMTP id 37E2724AA77; Thu, 24 Apr 2008 13:44:20 +0200 (CEST) Received: from svarun.infrax.si ([89.212.81.4]) by localhost (svarun.infrax.si [89.212.81.4]) (amavisd-maia, port 10024) with ESMTP id 13653-03; Thu, 24 Apr 2008 13:44:14 +0200 (CEST) Received: from [192.168.15.2] (lk.84.20.249.154.dc.cable.static.lj-kabel.net [84.20.249.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejko@infrax.si) by svarun.infrax.si (Postfix) with ESMTP id 41A2424AA3A; Thu, 24 Apr 2008 13:44:14 +0200 (CEST) Message-ID: <4810728A.8090902@skoberne.net> Date: Thu, 24 Apr 2008 13:44:10 +0200 From: =?windows-1252?Q?Nejc_=8Akoberne?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <254549.19682.qm@web46005.mail.sp1.yahoo.com> <481047FF.4080707@skoberne.net> <20080424084727.G66744@maildrop.int.zabbadoz.net> <48105269.4040303@skoberne.net> <48106E76.7030503@quip.cz> In-Reply-To: <48106E76.7030503@quip.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: Jailed Samba not getting broadcasts 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, 24 Apr 2008 11:44:22 -0000 Hello, > Try not to use jail_samba_interface="rl0" for "auto aliasing" and add > > ifconfig_rl0_alias0="inet 192.168.15.201 netmask 255.255.255.0" > > This should give you > inet 192.168.15.201 netmask 0xffffffff broadcast 192.168.15.255 > in the ifconfig output (after restart) Okay. Now I can see this from inside the jail: rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:40:f4:27:7e:a8 inet 192.168.15.201 netmask 0xffffff00 broadcast 192.168.15.255 media: Ethernet autoselect (100baseTX ) status: active and this on the host: rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:40:f4:27:7e:a8 inet 192.168.15.198 netmask 0xffffff00 broadcast 192.168.15.255 inet 192.168.15.201 netmask 0xffffff00 broadcast 192.168.15.255 media: Ethernet autoselect (100baseTX ) status: active So the netmask is correct now, I guess. But nevertheless, it still doesn't work. I simply cannot access my Samba directly by name (\\freebsd) but I can access it via IP (\\192.168.15.201) normally. My rc.conf is now as follows (the relevant lines): ifconfig_rl0="192.168.15.198 netmask 255.255.255.0" ifconfig_rl0_alias0="192.168.15.201 netmask 255.255.255.0" defaultrouter="192.168.15.1" jail_enable="YES" jail_sysvipc_allow="YES" jail_socket_unixiproute_only="NO" #=---------------------------- Jails ---------------------------=# jail_list="samba" #=--------------------------------------------------------------=# jail_samba_rootdir="/usr/jail/samba" jail_samba_hostname="samba.infrax.local" jail_samba_ip="192.168.15.201" #jail_samba_interface="rl0" jail_samba_devfs_enable="YES" jail_samba_procfs_enable="YES" jail_samba_devfs_ruleset="devfsrules_samba_jail" #=--------------------------------------------------------------=# Any other ideas? Thanks, Nejc From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 11:53: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 BBC3F106564A; Thu, 24 Apr 2008 11:53:23 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from svarun.infrax.si (syssvarun.infrax.si [89.212.81.4]) by mx1.freebsd.org (Postfix) with ESMTP id 83D058FC1A; Thu, 24 Apr 2008 11:53:23 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from localhost (sysSvarun.infrax.si [89.212.81.4]) by svarun.infrax.si (Postfix) with ESMTP id 26CB224A8AD; Thu, 24 Apr 2008 13:53:22 +0200 (CEST) Received: from svarun.infrax.si ([89.212.81.4]) by localhost (svarun.infrax.si [89.212.81.4]) (amavisd-maia, port 10024) with ESMTP id 27508-02; Thu, 24 Apr 2008 13:53:15 +0200 (CEST) Received: from [192.168.15.2] (lk.84.20.249.154.dc.cable.static.lj-kabel.net [84.20.249.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejko@infrax.si) by svarun.infrax.si (Postfix) with ESMTP id 356FB24A9F8; Thu, 24 Apr 2008 13:53:15 +0200 (CEST) Message-ID: <481074A7.1080504@skoberne.net> Date: Thu, 24 Apr 2008 13:53:11 +0200 From: =?ISO-8859-2?Q?Nejc_=A9koberne?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Johan Hendriks , User Questions References: <47F54BB3.1080801@skoberne.net><48071F0E.2020002@skoberne.net> <57200BF94E69E54880C9BB1AF714BBCB5DDDB1@w2003s01.double-l.local> <480DB0E2.3070202@skoberne.net><60553.203.127.42.92.1208860527.squirrel@www.superhero.nl> <480EFF60.3040901@skoberne.net> <57200BF94E69E54880C9BB1AF714BBCB5DDDE0@w2003s01.double-l.local> <481072B5.8020607@skoberne.net> <57200BF94E69E54880C9BB1AF714BBCB5DDDE1@w2003s01.double-l.local> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DDDE1@w2003s01.double-l.local> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 7.0 jail and Samba 3 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, 24 Apr 2008 11:53:23 -0000 Hey, > ifconfig_rl0_alias0="192.168.15.201 netmask 255.255.255.0" > > the mask of an alias ipadres needs to be 32 bits. > I do not now if this solves your problem but it needs to be 32 bits. > > ifconfig_rl0_alias0="192.168.15.201 netmask 255.255.255.255" I tried with 24 bits - it doesn't work one way or the other. Thanks, Nejc From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 11:56:10 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 B8FFA1065680 for ; Thu, 24 Apr 2008 11:56:10 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id D07878FC1B for ; Thu, 24 Apr 2008 11:55:07 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1358420nfb.33 for ; Thu, 24 Apr 2008 04:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=glTQsqWgz7SkDLFKmdyE85fFmdTroK4PNsbcVfDYhts=; b=NfXqCRaWMXhsbDYpM/BTY3lZLD3hri71MNePb2nsGDzMqjktIEI4BOKpteZ26jdeOTI2ApFTA3N+HJXt2UZG79IGToLYEae/cqFU9hdWpfDVD+jjh0nxouRMPQp49ZqWGZSPekGxXPO6NplYeKp0kYhFiUxCOBAq1RwC7h+pvG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=KuSpoAGT5PwWa0EDN/DN9ZadY424eHXF/EFhYCbwjBioSNZYJLxpOBW/4hZKOVjHep7I8C7qGgvKky8AAhtSS11gpU7izrBbMgunYtEtN6Ld9EXUbKOypIOFTy94l6/XL3CCob8WJ19eKMNSo2bpX/gbKAUC5W35IP8qdpXuBJI= Received: by 10.210.141.4 with SMTP id o4mr706915ebd.30.1209038077853; Thu, 24 Apr 2008 04:54:37 -0700 (PDT) Received: from ?172.17.1.29? ( [193.136.24.128]) by mx.google.com with ESMTPS id x6sm425081gvf.0.2008.04.24.04.54.36 (version=SSLv3 cipher=OTHER); Thu, 24 Apr 2008 04:54:37 -0700 (PDT) Message-Id: <29629BB0-DD8E-44E6-94B5-EAD238B45B4E@FreeBSD.org> From: Rui Paulo To: "Huang, Yusheng" In-Reply-To: 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: Thu, 24 Apr 2008 12:54:34 +0100 References: X-Mailer: Apple Mail (2.919.2) Sender: Rui Paulo Cc: freebsd-net@freebsd.org Subject: Re: RFC 2861 TCP Congestion Window Validation 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, 24 Apr 2008 11:56:10 -0000 On 23 Apr 2008, at 20:37, Huang, Yusheng wrote: > Hi, > > > > I was wondering if "RFC 2861 TCP Congestion Window Validation" been > implemented in FreeBSD? > > > > Thanks! The authors of the RFC quote HPF99. HPF99, according to the RFC, has implementation information regarding to FreeBSD 3.2 (I haven't read HPF99). So, to answer your question, it seems that cwnd validation was implemented by some folks already, but FreeBSD doesn't have RFC 2861 support. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 12:01: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 6850A106566B for ; Thu, 24 Apr 2008 12:01:59 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id 21AE98FC22 for ; Thu, 24 Apr 2008 12:01:58 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from onob5.irc.local ([192.168.2.33]) by mail1.cil.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 13:49:55 +0200 Message-ID: <481073BB.4020808@ide.resurscentrum.se> Date: Thu, 24 Apr 2008 13:49:15 +0200 From: Jon Otterholm User-Agent: Thunderbird 2.0.0.9 (X11/20071216) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2008 11:49:55.0842 (UTC) FILETIME=[50A7EE20:01C8A601] Subject: RE: Incompatibility between dummynet and PF rdr 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, 24 Apr 2008 12:01:59 -0000 Hi. Has anyone got a solution to the rdr-problem when using PF together with Dummynet/IPFW? I found this thread from 2006 which describes the problem in detail: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2006-07/msg00048.html //Jon From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 12:13: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 92976106566C for ; Thu, 24 Apr 2008 12:13:32 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: from pearl.ibctech.ca (pearl.ibctech.ca [208.70.104.210]) by mx1.freebsd.org (Postfix) with ESMTP id 461118FC25 for ; Thu, 24 Apr 2008 12:13:32 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: (qmail 74032 invoked by uid 1002); 24 Apr 2008 12:13:31 -0000 Received: from iaccounts@ibctech.ca by pearl.ibctech.ca by uid 89 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(208.70.104.100):. Processed in 0.067943 secs); 24 Apr 2008 12:13:31 -0000 Received: from unknown (HELO ?192.168.30.110?) (steve@ibctech.ca@208.70.104.100) by pearl.ibctech.ca with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Apr 2008 12:13:30 -0000 Message-ID: <481078F6.9010108@ibctech.ca> Date: Thu, 24 Apr 2008 08:11:34 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Baldur Gislason References: <4808A15E.4030007@ibctech.ca> <20080418133417.GA66873@gremlin.foo.is> In-Reply-To: <20080418133417.GA66873@gremlin.foo.is> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPIP tunnel behind NAT 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, 24 Apr 2008 12:13:32 -0000 Baldur Gislason wrote: > It'll work fine. I've done this several times before. Hmmm. I still can't seem to get this setup to work. The FreeBSD box is in behind a Fortigate 200 unit. > However I've also had NAT implementations which didn't work this way but > this one should definitely work. Are there any ports that need to be opened on the Fortigate to allow the tunnel traffic through? There appears to be no place in the Fortigate to pass protocol 41 traffic. Thanks, Steve From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 12:19:30 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 49B57106564A for ; Thu, 24 Apr 2008 12:19:30 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 24C8E8FC1E for ; Thu, 24 Apr 2008 12:19:29 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id D846219E023; Thu, 24 Apr 2008 14:19:28 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id BF53219E019; Thu, 24 Apr 2008 14:19:26 +0200 (CEST) Message-ID: <48107AE0.9010903@quip.cz> Date: Thu, 24 Apr 2008 14:19:44 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Johan Hendriks References: <47F54BB3.1080801@skoberne.net><48071F0E.2020002@skoberne.net> <57200BF94E69E54880C9BB1AF714BBCB5DDDB1@w2003s01.double-l.local> <480DB0E2.3070202@skoberne.net><60553.203.127.42.92.1208860527.squirrel@www.superhero.nl> <480EFF60.3040901@skoberne.net> <57200BF94E69E54880C9BB1AF714BBCB5DDDE0@w2003s01.double-l.local> <481072B5.8020607@skoberne.net> <57200BF94E69E54880C9BB1AF714BBCB5DDDE1@w2003s01.double-l.local> <481074A7.1080504@skoberne.net> In-Reply-To: <481074A7.1080504@skoberne.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, =?ISO-8859-2?Q?Nejc_=A9koberne?= Subject: Re: FreeBSD 7.0 jail and Samba 3 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, 24 Apr 2008 12:19:30 -0000 Nejc ©koberne wrote: > Hey, > >> ifconfig_rl0_alias0="192.168.15.201 netmask 255.255.255.0" >> >> the mask of an alias ipadres needs to be 32 bits. >> I do not now if this solves your problem but it needs to be 32 bits. >> >> ifconfig_rl0_alias0="192.168.15.201 netmask 255.255.255.255" Can you explain why it needs to be 32 bits? I have both setups (24 and 32) and both seems to works fine. (I am not running Samba) > I tried with 24 bits - it doesn't work one way or the other. > > Thanks, > Nejc From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 14:08:05 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 507C3106566B for ; Thu, 24 Apr 2008 14:08:05 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 31E3D8FC13 for ; Thu, 24 Apr 2008 14:08:05 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: by an-out-0708.google.com with SMTP id c14so898505anc.13 for ; Thu, 24 Apr 2008 07:07:59 -0700 (PDT) Received: by 10.100.58.19 with SMTP id g19mr5360414ana.44.1209044346169; Thu, 24 Apr 2008 06:39:06 -0700 (PDT) Received: by 10.100.210.19 with HTTP; Thu, 24 Apr 2008 06:39:06 -0700 (PDT) Message-ID: Date: Thu, 24 Apr 2008 10:39:06 -0300 From: "Victor Hugo Bilouro" Sender: bilouro@bilouro.com To: freebsd-net@freebsd.org In-Reply-To: <29629BB0-DD8E-44E6-94B5-EAD238B45B4E@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29629BB0-DD8E-44E6-94B5-EAD238B45B4E@FreeBSD.org> X-Google-Sender-Auth: 9c3220b9da964570 Subject: Re: RFC 2861 TCP Congestion Window Validation 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, 24 Apr 2008 14:08:05 -0000 Hello, I=B4m from Brazil, new here and people call me Bilouro. I=B4m participating of GSoc, with project TCP/IP regression test suite(tcptest) with mentoring of George (gnn). On 4/24/08, Rui Paulo wrote: > > On 23 Apr 2008, at 20:37, Huang, Yusheng wrote: > > > Hi, > > > > I was wondering if "RFC 2861 TCP Congestion Window Validation" been > > implemented in FreeBSD? > > > > Thanks! > > > The authors of the RFC quote HPF99. HPF99, according to the RFC, has > implementation information regarding to FreeBSD 3.2 (I haven't read HPF99= ). > So, to answer your question, it seems that cwnd validation was implemente= d > by some folks already, but FreeBSD doesn't have RFC 2861 support. > tcptest is intended to be used as a tool for conformance test, btw, It can aid the RFC 2861 implementation, but there is a long time to get there, I=B4m still planning, gsoc just started! Best --=20 Victor Hugo Bilouro FreeBSD! From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 14:24: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 19D6B106564A for ; Thu, 24 Apr 2008 14:24:36 +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 BA6BD8FC17 for ; Thu, 24 Apr 2008 14:24:34 +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 ESMTP id AAA21334; Fri, 25 Apr 2008 00:24:25 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 25 Apr 2008 00:24:24 +1000 (EST) From: Ian Smith To: =?windows-1252?Q?Nejc_=8Akoberne?= In-Reply-To: <4810691D.6050904@skoberne.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Cc: freebsd-net@freebsd.org Subject: Re: Jailed Samba not getting broadcasts 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, 24 Apr 2008 14:24:36 -0000 On Thu, 24 Apr 2008, [windows-1252] Nejc Škoberne wrote: > > I can't help wondering what would happen if you assigned the single jail > > IP to be the subnet's broadcast address, in this case 192.168.15.255 ? > > You mean if I did this: > > jail_samba_ip="192.168.15.255" > > ? I can't even ssh to the host then? And it doesn't work. Ok, thanks. Probably best that it doesn't, on reflection. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 14:39:55 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 29B94106566B; Thu, 24 Apr 2008 14:39:55 +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 1D3F98FC1E; Thu, 24 Apr 2008 14:39:55 +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 m3OEdsIZ031968; Thu, 24 Apr 2008 14:39:54 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3OEdsC7031962; Thu, 24 Apr 2008 14:39:54 GMT (envelope-from linimon) Date: Thu, 24 Apr 2008 14:39:54 GMT Message-Id: <200804241439.m3OEdsC7031962@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/123053: [re] re(4) unsupported hardware revision 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, 24 Apr 2008 14:39:55 -0000 Old Synopsis: re(4) unsupported hardware revision New Synopsis: [re] re(4) unsupported hardware revision Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Apr 24 14:39:41 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123053 From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 14:50:51 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 4BF82106564A for ; Thu, 24 Apr 2008 14:50:51 +0000 (UTC) (envelope-from martes@mgwigglesworth.com) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by mx1.freebsd.org (Postfix) with ESMTP id 2797F8FC0C for ; Thu, 24 Apr 2008 14:50:51 +0000 (UTC) (envelope-from martes@mgwigglesworth.com) Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id m3OEooQn019011 for ; Thu, 24 Apr 2008 10:50:50 -0400 Received: (qmail 16958 invoked by uid 78); 24 Apr 2008 14:50:49 -0000 Received: from unknown (HELO ?192.168.10.27?) (martes@mgwigglesworth.com@76.182.161.209) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 24 Apr 2008 14:50:49 -0000 From: Martes G Wigglesworth To: Jon Otterholm In-Reply-To: <481073BB.4020808@ide.resurscentrum.se> References: <481073BB.4020808@ide.resurscentrum.se> Content-Type: text/plain Organization: M.G.Wigglesworth,LLC Date: Thu, 24 Apr 2008 10:49:17 -0400 Message-Id: <1209048557.10040.96.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0-2mdv2008.0 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: RE: Incompatibility between dummynet and PF rdr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martes@mgwigglesworth.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2008 14:50:51 -0000 Sorry to respond off-topic, however, why would you need Packet Filter, if you were using ipfw and dummynet? On Thu, 2008-04-24 at 13:49 +0200, Jon Otterholm wrote: > Hi. > > Has anyone got a solution to the rdr-problem when using PF together with > Dummynet/IPFW? > > I found this thread from 2006 which describes the problem in detail: > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2006-07/msg00048.html > > //Jon > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 15:33: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 AA9D41065676; Thu, 24 Apr 2008 15:33:31 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from webmail14.yandex.ru (webmail14.yandex.ru [213.180.200.21]) by mx1.freebsd.org (Postfix) with ESMTP id 48ED98FC1A; Thu, 24 Apr 2008 15:33:31 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (webmail14) by mail.yandex.ru id S1130609AbYDXPdX for (+ 4 others); Thu, 24 Apr 2008 19:33:23 +0400 X-Yandex-Spam: 0 Received: from [77.72.136.70] ([77.72.136.70]) by mail.yandex.ru with HTTP; Thu, 24 Apr 2008 19:33:21 +0400 From: "Andrey V. Elsukov" To: linimon@freebsd.org, "Pyun YongHyeon" , "Martin Matuska" In-Reply-To: 9060000000219295039 References: 9060000000219295039 MIME-Version: 1.0 Message-Id: <1785861209051201@webmail14.yandex.ru> Date: Thu, 24 Apr 2008 19:33:21 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/123053: [re] re(4) unsupported hardware revision 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, 24 Apr 2008 15:33:31 -0000 24.04.08, 18:39, linimon@FreeBSD.org: > Old Synopsis: re(4) unsupported hardware revision > New Synopsis: [re] re(4) unsupported hardware revision > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Thu Apr 24 14:39:41 UTC 2008 > Responsible-Changed-Why: > Over to maintainer(s). > http://www.freebsd.org/cgi/query-pr.cgi?pr=123053 Hi, Martin. Can you try this patch? http://butcher.heavennet.ru/re.spin4.patch It's originally written by yongari@, but I didn't get response from the guy which has this hardware. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 15: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 3D942106564A for ; Thu, 24 Apr 2008 15: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 472788FC17 for ; Thu, 24 Apr 2008 15: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 m3OFo39E036590 for ; Thu, 24 Apr 2008 15: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 m3OFo3PI036589; Thu, 24 Apr 2008 15:50:03 GMT (envelope-from gnats) Date: Thu, 24 Apr 2008 15:50:03 GMT Message-Id: <200804241550.m3OFo3PI036589@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Martin Matuska Cc: Subject: Re: kern/123053: [re] re(4) unsupported hardware revision X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Matuska List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2008 15:50:03 -0000 The following reply was made to PR kern/123053; it has been noted by GNATS. From: Martin Matuska To: bug-followup@FreeBSD.org, mm@FreeBSD.org Cc: Subject: Re: kern/123053: [re] re(4) unsupported hardware revision Date: Thu, 24 Apr 2008 17:39:54 +0200 This seems to be another 8168, I am successfully running the following patch= : Index: src/sys/dev/re/if_re.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v retrieving revision 1.95.2.18 diff -u -r1.95.2.18 if_re.c --- src/sys/dev/re/if_re.c=0922 Apr 2008 06:14:56 -0000=091.95.2.18 +++ src/sys/dev/re/if_re.c=0924 Apr 2008 15:33:36 -0000 @@ -184,6 +184,8 @@ =09=09"RealTek 8168/8111B PCIe Gigabit Ethernet" }, =09{ RT_VENDORID, RT_DEVICEID_8168, RL_HWREV_8168_SPIN3, =09=09"RealTek 8168/8111B PCIe Gigabit Ethernet" }, +=09{ RT_VENDORID, RT_DEVICEID_8168, RL_HWREV_8168_SPIN4, +=09=09"RealTek 8168/8111B PCIe Gigabit Ethernet" }, =09{ RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8169, =09=09"RealTek 8169 Gigabit Ethernet" }, =09{ RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8169S, @@ -225,6 +227,7 @@ =09{ RL_HWREV_8101E, RL_8169, "8101E"}, =09{ RL_HWREV_8168_SPIN2, RL_8169, "8168"}, =09{ RL_HWREV_8168_SPIN3, RL_8169, "8168"}, +=09{ RL_HWREV_8168_SPIN4, RL_8169, "8168"}, =09{ 0, 0, NULL } }; @@ -697,6 +700,7 @@ =09case RL_HWREV_8168_SPIN1: =09case RL_HWREV_8168_SPIN2: =09case RL_HWREV_8168_SPIN3: +=09case RL_HWREV_8168_SPIN4: =09=09CSR_WRITE_4(sc, RL_MAR0, bswap32(hashes[1])); =09=09CSR_WRITE_4(sc, RL_MAR4, bswap32(hashes[0])); =09=09break; @@ -1305,6 +1309,7 @@ =09=09=09case RL_HWREV_8169_8110SC: =09=09=09case RL_HWREV_8168_SPIN2: =09=09=09case RL_HWREV_8168_SPIN3: +=09=09=09case RL_HWREV_8168_SPIN4: =09=09=09=09re_gmii_writereg(dev, 1, 0x1f, 0); =09=09=09=09re_gmii_writereg(dev, 1, 0x0e, 0); =09=09=09=09break; Index: src/sys/pci/if_rlreg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/pci/if_rlreg.h,v retrieving revision 1.67.2.7 diff -u -r1.67.2.7 if_rlreg.h --- src/sys/pci/if_rlreg.h=0922 Apr 2008 06:13:05 -0000=091.67.2.7 +++ src/sys/pci/if_rlreg.h=0924 Apr 2008 15:33:36 -0000 @@ -161,6 +161,7 @@ #define RL_HWREV_8101E=09=090x34000000 #define RL_HWREV_8168_SPIN2=090x38000000 #define RL_HWREV_8168_SPIN3=090x38400000 +#define RL_HWREV_8168_SPIN4=090x3c000000 #define RL_HWREV_8139=09=090x60000000 #define RL_HWREV_8139A=09=090x70000000 #define RL_HWREV_8139AG=09=090x70800000 From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 16:46:44 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 428561065670; Thu, 24 Apr 2008 16:46:44 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from spork.qfe3.net (spork.qfe3.net [212.13.207.101]) by mx1.freebsd.org (Postfix) with ESMTP id 16CF28FC19; Thu, 24 Apr 2008 16:46:43 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from [81.104.123.28] (helo=voi.aagh.net) by spork.qfe3.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1Jp4Je-000CgU-RR; Thu, 24 Apr 2008 17:28:58 +0100 Received: from freaky by voi.aagh.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jp4Je-000DEx-L8; Thu, 24 Apr 2008 17:28:58 +0100 Date: Thu, 24 Apr 2008 17:28:58 +0100 From: Thomas Hurst To: Jeremy Chadwick Message-ID: <20080424162858.GA46157@voi.aagh.net> Mail-Followup-To: Jeremy Chadwick , "Arno J. Klaassen" , Clayton Milos , Kris Kennaway , stable@FreeBSD.ORG, net@FreeBSD.ORG References: <20080421094718.GY25623@hub.freebsd.org> <20080421154333.GA96237@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080421154333.GA96237@eos.sc1.parodius.com> Organization: Not much. User-Agent: Mutt/1.5.17 (2007-11-01) Sender: Thomas Hurst Cc: Clayton Milos , Kris Kennaway , stable@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: nfs-server silent data corruption 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, 24 Apr 2008 16:46:44 -0000 * Jeremy Chadwick (koitsu@freebsd.org) wrote: > > I added it directly to the 2nd CPU (diagram on page 9 of > > http://www.tyan.com/manuals/m_s2895_101.pdf) and the problem > > seems to be the interaction between nfe0 and powerd .... : > > That board is the weirdest thing I've seen in years. K8WE's a very popular workstation board. I've been using one for years. > Two separate CPUs using a single (shared) memory controller, Er, no. Where are you getting that? 4 DIMMs are connected per CPU, though it's hardly strange to only have one, just cheap and nasty. > two separate (and different!) nVidia chipsets, a SMSC I/O controller > probably used for serial and parallel I/O, Er, so? Sun X4x00 M2's do exactly the same; they run a 2200 off one CPU and a 2050 off another (via an AMD 8132 no less). !M2's did much the same with a pair of AMD 8131's. They use SMSC IO controllers too: http://www.sun.com/servers/entry/x4100/arch-wp.pdf http://www.sun.com/servers/netra/x4200/wp.pdf We've used dozens of these systems in production in various configurations for years wuthout a problem. > two separate nVidia NICs with Marvell PHYs (yet somehow you can bridge > the two NICs and PHYs?), They're not seperate, they hang off the same chip according to the linked document. They are nve nonsense, though, not worth using imo. > two separate PCI-e busses (each associated with a separate nVidia > chipset), two separate PCI-X busses... the list continues. Again, nothing surprising. Each CPU gets its own bus via its own HT link. Back in the day when the K8WE was first released, this was the only way to get a pair of 16x PCIe slots. > I know you don't need opinions at this point, but what a behemoth. I > can't imagine that thing running reliably. The only stability problems I've experience have been the occasional lockup using PowerNow since migrating from dual single core to dual dual core. -- Thomas 'Freaky' Hurst http://hur.st/ From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 18:10: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 4DC04106564A for ; Thu, 24 Apr 2008 18:10:41 +0000 (UTC) (envelope-from baldur@foo.is) Received: from gremlin.foo.is (gremlin.foo.is [194.105.250.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1EBB48FC1D for ; Thu, 24 Apr 2008 18:10:41 +0000 (UTC) (envelope-from baldur@foo.is) Received: from 127.0.0.1 (localhost.foo.is [127.0.0.1]) by injector.foo.is (Postfix) with SMTP id 25120DA883; Thu, 24 Apr 2008 18:10:39 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on gremlin.foo.is X-Spam-Level: X-Spam-Status: No, score=-2.6 required=6.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.1.7 Received: by gremlin.foo.is (Postfix, from userid 1000) id F30BCDA87E; Thu, 24 Apr 2008 18:10:35 +0000 (GMT) Date: Thu, 24 Apr 2008 18:10:35 +0000 From: Baldur Gislason To: Steve Bertrand Message-ID: <20080424181035.GC66873@gremlin.foo.is> References: <4808A15E.4030007@ibctech.ca> <20080418133417.GA66873@gremlin.foo.is> <481078F6.9010108@ibctech.ca> In-Reply-To: <481078F6.9010108@ibctech.ca> User-Agent: Mutt/1.4.2.2i X-Sanitizer: Foo MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Cc: freebsd-net@freebsd.org Subject: Re: IPIP tunnel behind NAT 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, 24 Apr 2008 18:10:41 -0000 You need to do do a one-to-one NAT, so protocol 94 (IPIP) packets get forwarded. It's not TCP or UDP, so no ports there. Alternatively, you can set up a NAT traversing IPSEC-in-UDP tunnel, but that requires a kernel patch. Baldur On Thu, Apr 24, 2008 at 08:11:34AM -0400, Steve Bertrand wrote: > Baldur Gislason wrote: > >It'll work fine. I've done this several times before. > > Hmmm. I still can't seem to get this setup to work. The FreeBSD box is > in behind a Fortigate 200 unit. > > >However I've also had NAT implementations which didn't work this way but > >this one should definitely work. > > Are there any ports that need to be opened on the Fortigate to allow the > tunnel traffic through? There appears to be no place in the Fortigate to > pass protocol 41 traffic. > > Thanks, > > Steve > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 18:44:18 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 99B2A106566C; Thu, 24 Apr 2008 18:44:18 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 6820E8FC1E; Thu, 24 Apr 2008 18:44:18 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id 8AFFE5C7E; Thu, 24 Apr 2008 22:44:06 +0400 (MSD) Date: Thu, 24 Apr 2008 22:43:25 +0400 From: Igor Sysoev To: gnn@freebsd.org Message-ID: <20080424184325.GA48394@rambler-co.ru> References: <20080420102827.U67663@fledge.watson.org> <20080421112753.GD44915@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20080421112753.GD44915@rambler-co.ru> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Robert Watson , net@freebsd.org Subject: Re: zonelimit issues... 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, 24 Apr 2008 18:44:18 -0000 On Mon, Apr 21, 2008 at 03:27:53PM +0400, Igor Sysoev wrote: > The problem that FreeBSD has small KVA space: only 2G even on amd64 32G > machines. > > So with > > vm.kmem_size=1G > # 64M KVA > kern.maxbcache=64M > # 4M KVA > kern.ipc.maxpipekva=4M > > > I can use something like this: > > # 256M KVA/KVM > kern.ipc.nmbjumbop=64000 > # 216M KVA/KVM > kern.ipc.nmbclusters=98304 > # 162M KVA/KVM > kern.ipc.maxsockets=163840 > # 8M KVA/KVM > net.inet.tcp.maxtcptw=163840 > # 24M KVA/KVM > kern.maxfiles=204800 Actually, on amd64 it is possible to increase KVM up to 1.8G without boot time panic: vm.kmem_size=1844M # 64M KVA kern.maxbcache=64M # 4M KVA kern.ipc.maxpipekva=4M Without descreasing kern.maxbcache (200M by default) and kern.ipc.maxpipekva (~40M by default) you can get only about 1.5G. So with 1.8G KVM I able to set # 4G phys, 2G KVA, 1.8G KVM # # 750M KVA/KVM kern.ipc.nmbjumbop=192000 # 504M KVA/KVM kern.ipc.nmbclusters=229376 # 334M KVA/KVM kern.ipc.maxsockets=204800 # 8M KVA/KVM net.inet.tcp.maxtcptw=163840 # 24M KVA/KVM kern.maxfiles=204800 Now KVA is split as kernel code 8M kmem_map 1844M buffer_map 64M pager_map 32M exec_map 4.2M pipe_map 4M ??? 60M vm.kvm_free 32M I leave unused spare 32M free KVA (vm.kvm_free) because some map (unknown for me) after pipe_map may grow slightly. If vm.kvm_free will become 0, kernel will panic. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 23:41: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 6401B1065672 for ; Thu, 24 Apr 2008 23:41: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 DBF448FC0A for ; Thu, 24 Apr 2008 23:41:30 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JpB49-0006vh-Ll for freebsd-net@freebsd.org; Thu, 24 Apr 2008 23:41:25 +0000 Received: from 78-1-87-118.adsl.net.t-com.hr ([78.1.87.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Apr 2008 23:41:25 +0000 Received: from ivoras by 78-1-87-118.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Apr 2008 23:41:25 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 25 Apr 2008 01:41:11 +0200 Lines: 141 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig37DB66D30CD2617D7E72E027" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-87-118.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) X-Enigmail-Version: 0.95.6 Sender: news Subject: Connecting P1i to FreeBSD 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, 24 Apr 2008 23:41:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig37DB66D30CD2617D7E72E027 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I'd like to connect SE P1i (a "smartphone" device) to FreeBSD, in any=20 possible way, via wireless (WLAN). The symptoms are that it just reports = "Connection failed" no matter what I do. Acquired data so far: 0) I'm trying adhoc mode without any authorization, for now, just to get = it working 1) The same wifi adapter (USB, D-Link DWL-G122) works ok with Windows XP = with adhoc mode (i.e. the device connects/associates to the computer,=20 can exchange network traffic, etc; in Windows I can bridge the wifi=20 device to the network card, etc. - in effect, no problems) 2) There's no way the same devices succeeds in talking when the wifi=20 adapter is on FreeBSD. The adapter is run via the rum driver. 2a) The "scan network" action on the device lists the WLAN SSID on the=20 computer; also "ifconfig rum0 list sta" on FreeBSD shows the device's MAC= =2E 3) A third machine, a laptop, can connect to the FreeBSD machine,=20 everything works. 3a) Apparently SE P1i is quirky with its WLAN support, but somehow it=20 knows how to talk to Windows. Here's a debug trace from the FreeBSD machine (wlandebug -i rum0 +debug=20 +scan +assoc +node +xrate +rate +input +output +auth) during the=20 unsuccessful connection attempt. The "...1d" MAC is from the P1i. rum0: received probe_req from 00:1c:a4:75:63:1d rssi 27 rum0: [00:1c:a4:75:63:1d] recv probe req rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574)=20 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 [00:1c:a4:75:63:1d] send probe_resp on channel 6 rum0: received probe_req from 00:1c:a4:75:63:1d rssi 27 rum0: [00:1c:a4:75:63:1d] recv probe req rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574)=20 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 [00:1c:a4:75:63:1d] send probe_resp on channel 6 rum0: received probe_req from 00:1c:a4:75:63:1d rssi 25 rum0: [00:1c:a4:75:63:1d] recv probe req rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574)=20 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 [00:1c:a4:75:63:1d] send probe_resp on channel 6 rum0: received probe_req from 00:1c:a4:75:63:1d rssi 25 rum0: [00:1c:a4:75:63:1d] recv probe req rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574)=20 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 [00:1c:a4:75:63:1d] send probe_resp on channel 6 rum0: received probe_req from 00:1c:a4:75:63:1d rssi 25 rum0: [00:1c:a4:75:63:1d] recv probe req rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574)=20 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 [00:1c:a4:75:63:1d] send probe_resp on channel 6 rum0: received probe_req from 00:1c:a4:75:63:1d rssi 25 rum0: [00:1c:a4:75:63:1d] recv probe req rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574)=20 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 [00:1c:a4:75:63:1d] send probe_resp on channel 6 rum0: received probe_req from 00:1c:a4:75:63:1d rssi 25 rum0: [00:1c:a4:75:63:1d] recv probe req rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574)=20 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 [00:1c:a4:75:63:1d] send probe_resp on channel 6 rum0: received probe_req from 00:1c:a4:75:63:1d rssi 25 rum0: [00:1c:a4:75:63:1d] recv probe req rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574)=20 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 [00:1c:a4:75:63:1d] send probe_resp on channel 6 rum0: [00:1c:a4:75:63:1d] probe station due to inactivity rum0: [00:1c:a4:75:63:1d] send null data frame on channel 6, pwr mgt dis rum0: [00:1c:a4:75:63:1d] probe station due to inactivity rum0: [00:1c:a4:75:63:1d] send null data frame on channel 6, pwr mgt dis rum0: [00:1c:a4:75:63:1d] station timed out due to inactivity (refcnt 1) rum0: [00:1c:a4:75:63:1d] station with aid 0 leaves rum0: node_reclaim: remove 0xc250b000<00:1c:a4:75:63:1d> from neighbor=20 table, refcnt 1 rum0: _ieee80211_free_node 0xc250b000<00:1c:a4:75:63:1d> in table The last 8 messages appear long after the device itself has stopped=20 trying and declared it unconnectable. I don't know enough of wifi implementation to draw solid conclusions but = this seems to me like the device is ignoring information given to it by=20 the FreeBSD-run adapter and is retrying several times until it gives up. Here's ifconfig for rum0: rum0: flags=3D108843=20 metric 0 mtu 1500 ether 00:1c:f0:9d:08:b3 inet 10.0.0.3 netmask 0xffffff00 broadcast 10.0.0.255 media: IEEE 802.11 Wireless Ethernet autoselect =20 (autoselect ) status: associated ssid C1 channel 6 (2437 Mhz 11g) bssid 9a:04:a0:16:24:54 authmode OPEN privacy OFF txpower 50 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS here's "ifconfig rum0 list sta": ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 00:1c:f0:9d:08:b3 0 6 1M 15.5 0 0 80 I A 00:1c:a4:75:63:1d 0 6 1M 14.5 0 2 96 A Is the difference in CAPS significant? Obviously, I can't influence the=20 device in any way to configure itself, but when it scans the available=20 SSIDs, it knows this one is in "ad-hoc" mode and has the correct channel = listed. Any ideas what to try next? Fiddling with adhoc/hostap modes, 11b and=20 11g modes, authentication, etc. doesn't work. Even long shots are=20 appreciated. This is on RELENG_7. --------------enig37DB66D30CD2617D7E72E027 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 iD8DBQFIERqdldnAQVacBcgRAgZOAJ92QI5he5YvgwcuQTgVo1ahnR9Q8ACdHahW xV1i5p0Hu29XIG1wmDsbns4= =IWnU -----END PGP SIGNATURE----- --------------enig37DB66D30CD2617D7E72E027-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 25 04:43:30 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 D2F4A106566B; Fri, 25 Apr 2008 04:43:30 +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 728468FC1C; Fri, 25 Apr 2008 04:43:30 +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 m3P4hUx1000202; Fri, 25 Apr 2008 04:43:30 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3P4hUGj000198; Fri, 25 Apr 2008 04:43:30 GMT (envelope-from linimon) Date: Fri, 25 Apr 2008 04:43:30 GMT Message-Id: <200804250443.m3P4hUGj000198@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/123066: [ipsec] [panic] kernel trap with ipsec 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, 25 Apr 2008 04:43:30 -0000 Old Synopsis: kernel trap with ipsec New Synopsis: [ipsec] [panic] kernel trap with ipsec Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Apr 25 04:42:50 UTC 2008 Responsible-Changed-Why: Reclassify and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=123066 From owner-freebsd-net@FreeBSD.ORG Fri Apr 25 05:50: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 4A4F71065673 for ; Fri, 25 Apr 2008 05:50:04 +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 327518FC1F for ; Fri, 25 Apr 2008 05:50:04 +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 m3P5o4o4010355 for ; Fri, 25 Apr 2008 05:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3P5o4f1010354; Fri, 25 Apr 2008 05:50:04 GMT (envelope-from gnats) Date: Fri, 25 Apr 2008 05:50:04 GMT Message-Id: <200804250550.m3P5o4f1010354@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Kris Kennaway Cc: Subject: Re: misc/123066: kernel trap with ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kris Kennaway List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2008 05:50:04 -0000 The following reply was made to PR kern/123066; it has been noted by GNATS. From: Kris Kennaway To: Mihail Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: misc/123066: kernel trap with ipsec Date: Fri, 25 Apr 2008 05:46:54 +0000 On Fri, Apr 25, 2008 at 04:13:40AM +0000, Mihail wrote: > (kgdb) backtrace > #0 doadump () at pcpu.h:195 > #1 0xc075df57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc075e219 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc0a9766c in trap_fatal (frame=0xc884e934, eva=3621180904) > at /usr/src/sys/i386/i386/trap.c:899 > #4 0xc0a978f0 in trap_pfault (frame=0xc884e934, usermode=0, eva=3621180904) > at /usr/src/sys/i386/i386/trap.c:812 > #5 0xc0a9829c in trap (frame=0xc884e934) at /usr/src/sys/i386/i386/trap.c:490 > #6 0xc0a7e21b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc0a952f6 in generic_bcopy () at /usr/src/sys/i386/i386/support.s:498 > Previous frame inner to this frame (corrupt stack?) Unfortunately we need the rest of the stack. Can you either try to reproduce with DDB in the kernel and obtain a stack trace from there, or if this is not possible then try recompiling the kernel with -O instead of -O2 which tends to produce better stack traces. Kris From owner-freebsd-net@FreeBSD.ORG Fri Apr 25 06:50: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 602F110656F9 for ; Fri, 25 Apr 2008 06:50:42 +0000 (UTC) (envelope-from ianbrn@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB828FC22 for ; Fri, 25 Apr 2008 06:50:40 +0000 (UTC) (envelope-from ianbrn@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so3819665fgg.35 for ; Thu, 24 Apr 2008 23:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=3VBOC1mOg66G2KD6av8b+rv5CKMkeOkLui8JyzW+os4=; b=TlBNd9TUB5XqQdrbal/HrkkHwwCGKBdhF8IdwvHWZjlQGA6aGo9Ev+hetXnHK8MPjLzXNEWrBwhcn3UVtNVnp+OMbiLC95ve3acyvOZZEWAKdZE2YXQkJWubtQoUMiibPT26RBPBIZKrRbCv69dLtfvcwLuOXiVlTEwN8HRWXas= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=QqicHUO2Qdr6Sy6gLSLRqIIUUYnwDeIiayMmtsr7IDQATnlZ0epAB4RLZtwiCbM4CT5sJASw9gn1mD/N6fsVPKhIcLr8rw1UdNzY/OaMSO8RxC6dKm2hliEGF1xG/4NVfkQjyr2G0r/pWYoT6xmI9JzPzJiULEvYJIrXf4PrLwU= Received: by 10.86.90.13 with SMTP id n13mr424796fgb.64.1209104723225; Thu, 24 Apr 2008 23:25:23 -0700 (PDT) Received: by 10.86.33.3 with HTTP; Thu, 24 Apr 2008 23:25:23 -0700 (PDT) Message-ID: Date: Fri, 25 Apr 2008 09:25:23 +0300 From: "Ian Brown" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Pim6sd daemon and global addresses 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, 25 Apr 2008 06:50:42 -0000 Hello, from man pim6sd: "pim6sd requires the node running the daemon to have an IPv6 global address.". Does that mean that it must have an IPv6 address which it address has a global type? Namely, must it be an address which starts with a global prefix, like 2001::....? Or, if I will set a multicast address thus: ff::43/64 ; it's scope is Global; is it regarded an IPv6 global address? Second: is there a way to prevent the pim6sd daemon to send the PIM hello messages, which it does regularly ? Any help will be appreciated. Regards, Ian From owner-freebsd-net@FreeBSD.ORG Fri Apr 25 06:54: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 4B583106564A for ; Fri, 25 Apr 2008 06:54:25 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id EDE368FC1A for ; Fri, 25 Apr 2008 06:54:24 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so991240anc.13 for ; Thu, 24 Apr 2008 23:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=G2UV48nK8n0K/iSdTy2WuWgxI9xDrXrZyC3auxAd7xI=; b=Q8+BtJOux9TrQ23lpqsx40Ht5Y7w+pdijVQy9/vpldX6CMnmxlailVkbEs8yb4qT77GWY/QwWNymPRDBI0t5EYknkw/mOdxFDyLU1ja26tYJZtmZyZmGVPiqNrUXz4VBq2QF0McjRj15zBK4b6m9soETEFXO+jYuxdce+YGlACs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Knc54fzwUYDws4pB8qX4S8kBWsmlEWldo/DKB1n9PQEmgX33A4T/X2S8/258MBFGm9vLD9UR523pafxOAzeuYnJl2kH4q0J6tcfUZgZeAYILJIttrCdWtUh2ALmIwSCFwkKL0w4j0AyzsUp31XDz8qpNZgfUN2pwZoZw53e+jg0= Received: by 10.101.70.5 with SMTP id x5mr6965526ank.93.1209106464080; Thu, 24 Apr 2008 23:54:24 -0700 (PDT) Received: by 10.100.48.5 with HTTP; Thu, 24 Apr 2008 23:54:23 -0700 (PDT) Message-ID: Date: Fri, 25 Apr 2008 14:54:23 +0800 From: "Sepherosa Ziehau" To: freebsd-net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: Connecting P1i to FreeBSD 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, 25 Apr 2008 06:54:25 -0000 On Fri, Apr 25, 2008 at 7:41 AM, Ivan Voras wrote: > Hi, > > I'd like to connect SE P1i (a "smartphone" device) to FreeBSD, in any > possible way, via wireless (WLAN). The symptoms are that it just reports > "Connection failed" no matter what I do. > > Acquired data so far: > > 0) I'm trying adhoc mode without any authorization, for now, just to get it > working > 1) The same wifi adapter (USB, D-Link DWL-G122) works ok with Windows XP > with adhoc mode (i.e. the device connects/associates to the computer, can > exchange network traffic, etc; in Windows I can bridge the wifi device to > the network card, etc. - in effect, no problems) > 2) There's no way the same devices succeeds in talking when the wifi > adapter is on FreeBSD. The adapter is run via the rum driver. > 2a) The "scan network" action on the device lists the WLAN SSID on the > computer; also "ifconfig rum0 list sta" on FreeBSD shows the device's MAC. > 3) A third machine, a laptop, can connect to the FreeBSD machine, > everything works. > 3a) Apparently SE P1i is quirky with its WLAN support, but somehow it knows > how to talk to Windows. > > Here's a debug trace from the FreeBSD machine (wlandebug -i rum0 +debug > +scan +assoc +node +xrate +rate +input +output +auth) during the > unsuccessful connection attempt. The "...1d" MAC is from the P1i. > > rum0: received probe_req from 00:1c:a4:75:63:1d rssi 27 > rum0: [00:1c:a4:75:63:1d] recv probe req > rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574) > 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 > [00:1c:a4:75:63:1d] send probe_resp on channel 6 > rum0: received probe_req from 00:1c:a4:75:63:1d rssi 27 > rum0: [00:1c:a4:75:63:1d] recv probe req > rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574) > 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 > [00:1c:a4:75:63:1d] send probe_resp on channel 6 > rum0: received probe_req from 00:1c:a4:75:63:1d rssi 25 > rum0: [00:1c:a4:75:63:1d] recv probe req > rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574) > 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 > [00:1c:a4:75:63:1d] send probe_resp on channel 6 > rum0: received probe_req from 00:1c:a4:75:63:1d rssi 25 > rum0: [00:1c:a4:75:63:1d] recv probe req > rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574) > 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 > [00:1c:a4:75:63:1d] send probe_resp on channel 6 > rum0: received probe_req from 00:1c:a4:75:63:1d rssi 25 > rum0: [00:1c:a4:75:63:1d] recv probe req > rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574) > 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 > [00:1c:a4:75:63:1d] send probe_resp on channel 6 > rum0: received probe_req from 00:1c:a4:75:63:1d rssi 25 > rum0: [00:1c:a4:75:63:1d] recv probe req > rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574) > 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 > [00:1c:a4:75:63:1d] send probe_resp on channel 6 > rum0: received probe_req from 00:1c:a4:75:63:1d rssi 25 > rum0: [00:1c:a4:75:63:1d] recv probe req > rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574) > 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 > [00:1c:a4:75:63:1d] send probe_resp on channel 6 > rum0: received probe_req from 00:1c:a4:75:63:1d rssi 25 > rum0: [00:1c:a4:75:63:1d] recv probe req > rum0: ieee80211_ref_node (ieee80211_send_mgmt:1574) > 0xc250b000<00:1c:a4:75:63:1d> refcnt 3 > [00:1c:a4:75:63:1d] send probe_resp on channel 6 > rum0: [00:1c:a4:75:63:1d] probe station due to inactivity > rum0: [00:1c:a4:75:63:1d] send null data frame on channel 6, pwr mgt dis > rum0: [00:1c:a4:75:63:1d] probe station due to inactivity > rum0: [00:1c:a4:75:63:1d] send null data frame on channel 6, pwr mgt dis > rum0: [00:1c:a4:75:63:1d] station timed out due to inactivity (refcnt 1) > rum0: [00:1c:a4:75:63:1d] station with aid 0 leaves > rum0: node_reclaim: remove 0xc250b000<00:1c:a4:75:63:1d> from neighbor > table, refcnt 1 > rum0: _ieee80211_free_node 0xc250b000<00:1c:a4:75:63:1d> in table > > The last 8 messages appear long after the device itself has stopped trying > and declared it unconnectable. > > I don't know enough of wifi implementation to draw solid conclusions but > this seems to me like the device is ignoring information given to it by the > FreeBSD-run adapter and is retrying several times until it gives up. > > Here's ifconfig for rum0: > > rum0: flags=108843 > metric 0 mtu 1500 > ether 00:1c:f0:9d:08:b3 > inet 10.0.0.3 netmask 0xffffff00 broadcast 10.0.0.255 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect > ) > status: associated > ssid C1 channel 6 (2437 Mhz 11g) bssid 9a:04:a0:16:24:54 > authmode OPEN privacy OFF txpower 50 scanvalid 60 bgscan > bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 > protmode CTS > > here's "ifconfig rum0 list sta": > > ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG > 00:1c:f0:9d:08:b3 0 6 1M 15.5 0 0 80 I A > 00:1c:a4:75:63:1d 0 6 1M 14.5 0 2 96 A Are you sure that your device works under IBSS mode? BTW, it looks like you have third machine that is equipped with wireless device, so would you please grab a 802_11 tap when your device tries to connect to rum on your freebsd box: tcpdump -ni your_third_wlan_iface -y ieee802_11 -w dump.bin Best Regards, sephe -- Live Free or Die From owner-freebsd-net@FreeBSD.ORG Fri Apr 25 07:20: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 9FB141065674 for ; Fri, 25 Apr 2008 07:20: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 81DA68FC16 for ; Fri, 25 Apr 2008 07:20: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 m3P7K3A7019606 for ; Fri, 25 Apr 2008 07:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3P7K3Jk019605; Fri, 25 Apr 2008 07:20:03 GMT (envelope-from gnats) Date: Fri, 25 Apr 2008 07:20:03 GMT Message-Id: <200804250720.m3P7K3Jk019605@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: misha saf Cc: Subject: Re: misc/123066: kernel trap with ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: misha saf List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2008 07:20:03 -0000 The following reply was made to PR kern/123066; it has been noted by GNATS. From: misha saf To: Kris Kennaway Cc: Subject: Re: misc/123066: kernel trap with ipsec Date: Fri, 25 Apr 2008 10:59:33 +0400 * Kris Kennaway [Fri, 25 Apr 2008 05:46:54 +0000]: > On Fri, Apr 25, 2008 at 04:13:40AM +0000, Mihail wrote: > > > (kgdb) backtrace > > #0 doadump () at pcpu.h:195 > > #1 0xc075df57 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:409 > > #2 0xc075e219 in panic (fmt=Variable "fmt" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:563 > > #3 0xc0a9766c in trap_fatal (frame=0xc884e934, eva=3621180904) > > at /usr/src/sys/i386/i386/trap.c:899 > > #4 0xc0a978f0 in trap_pfault (frame=0xc884e934, usermode=0, > eva=3621180904) > > at /usr/src/sys/i386/i386/trap.c:812 > > #5 0xc0a9829c in trap (frame=0xc884e934) at > /usr/src/sys/i386/i386/trap.c:490 > > #6 0xc0a7e21b in calltrap () at > /usr/src/sys/i386/i386/exception.s:139 > > #7 0xc0a952f6 in generic_bcopy () at > /usr/src/sys/i386/i386/support.s:498 > > Previous frame inner to this frame (corrupt stack?) > > Unfortunately we need the rest of the stack. Can you either try to > reproduce with DDB in the kernel and obtain a stack trace from there, > or if this is not possible then try recompiling the kernel with -O > instead of -O2 which tends to produce better stack traces. > > Kris > (kgdb) info registers eax 0x15e6c9c0 367446464 ecx 0x1 1 edx 0xfbc 4028 ebx 0x4 4 esp 0xc1c8c300 0xc1c8c300 ebp 0xc884e9d8 0xc884e9d8 esi 0xc1f00c28 -1041232856 edi 0xd7d6d5e8 -673786392 eip 0xc0a952f6 0xc0a952f6 eflags 0x10202 66050 cs 0x20 32 ss 0xc1f00c00 -1041232896 ds 0x28 40 es 0x28 40 fs 0x8 8 gs 0x0 0 (kgdb) x/12xw 0xc1c8c300 0xc1c8c300: 0xcfcecdcc 0xd3d2d1d0 0xd7d6d5d4 0x00000024 0xc1c8c310: 0xdfdedddc 0xe3e2e1e0 0xe7e6e5e4 0xebeae9e8 0xc1c8c320: 0xefeeedfc 0xf3f2f1f0 0xf7f6f5f4 0xfbfaf9f8 That's all needed info ? From owner-freebsd-net@FreeBSD.ORG Fri Apr 25 10:20:05 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 6B76C10656B0 for ; Fri, 25 Apr 2008 10:20:05 +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 468458FC78 for ; Fri, 25 Apr 2008 10:20:05 +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 m3PAK5P1033529 for ; Fri, 25 Apr 2008 10:20:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3PAK57B033528; Fri, 25 Apr 2008 10:20:05 GMT (envelope-from gnats) Date: Fri, 25 Apr 2008 10:20:05 GMT Message-Id: <200804251020.m3PAK57B033528@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: linimon@lonesome.com (Mark Linimon) Cc: Subject: Re: kern/123053: [re] re(4) unsupported hardware revision X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2008 10:20:05 -0000 The following reply was made to PR kern/123053; it has been noted by GNATS. From: linimon@lonesome.com (Mark Linimon) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/123053: [re] re(4) unsupported hardware revision Date: Fri, 25 Apr 2008 05:17:45 -0500 ----- Forwarded message from Eric F Crist ----- From: Eric F Crist To: linimon@FreeBSD.org Subject: kern/123053 Cc: freebsd-drivers@freebsd.org Andrey, I've applied the patch to a 7.0-RELEASE-p1 source tree and rebooted my system. The card comes UP ok, but shows the following when connected to a 100BaseT/ Full Duplex switch port: re0: flags=8802 metric 0 mtu 1500 options=9b ether 00:1f:c6:52:7b:80 media: Ethernet autoselect (10baseT/UTP ) status: active Once I've assigned an IP to the interface, however, it comes up correctly and seems to function just fine. Is there any load testing I should perform for you folks? re0: flags=8843 metric 0 mtu 1500 options=9b ether 00:1f:c6:52:7b:80 inet 10.0.0.38 netmask 0xffff0000 broadcast 10.0.255.255 media: Ethernet autoselect (100baseTX ) status: active ----- Eric F Crist Secure Computing Networks ----- End forwarded message ----- From owner-freebsd-net@FreeBSD.ORG Fri Apr 25 12:42:43 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 ECB4610656B6 for ; Fri, 25 Apr 2008 12:42:43 +0000 (UTC) (envelope-from valeranew@ukr.net) Received: from ffe7.ukr.net (ffe7.ukr.net [195.214.192.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6C30E8FC15 for ; Fri, 25 Apr 2008 12:42:43 +0000 (UTC) (envelope-from valeranew@ukr.net) Received: from mail by ffe7.ukr.net with local ID 1JpMww-0000pa-1L for freebsd-net@freebsd.org; Fri, 25 Apr 2008 15:22:46 +0300 MIME-Version: 1.0 To: freebsd-net@freebsd.org From: "Valerij Solovyov" X-Life: is great, enjoy it! X-Mailer: freemail.ukr.net mPOP 3.4.1 X-Originating-Ip: [193.238.153.7] X-Browser: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.8.1.12) Gecko/20080505 Firefox/2.0.0.12 Message-Id: Date: Fri, 25 Apr 2008 15:22:46 +0300 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD7+ipfw+Vlan 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, 25 Apr 2008 12:42:44 -0000 Hello. I use for router: Dlink DES-3016 + intel Pro/1000XT + Pentium4 + FreeBSD # uname -r 7.0-RC1 I use: 6.2-RELEASE-p11 for my vpn-server and this router with kernel option if_bridge. In that time I have 5 NIC's, and my router was switch with shaper. But one month ago my VPN-server began hang up. Befor hang up I recive by squid message: Socket Failure The system returned:     (24) Too many open files AND when I try to reboot or write whatever freeBSD couldn't write letter and nothing more. In my VPN-server I use ipfw + dummynet too. After this I decide do router from my bridge with FreeBSD. I rebuild kernel. I after that my VPN-server has uptime ten days (before less then one day). But my router began hang up. Before this problem's I use Dlink DES-2108 as swtitch more than 1 year. #cat /etc/rc.conf ifconfig_em0="inet 172.168.1.1  netmask 255.255.255.0" ifconfig_vr0="inet 10.11.25.13 netmask 255.255.0.0" defaultrouter="10.11.25.1" cloned_interfaces="vlan1 vlan2 vlan3 vlan4 vlan5 vlan6 vlan7 vlan8 vlan9 vlan10" ifconfig_vlan1="inet 10.12.1.1 netmask 255.255.255.0 vlan 3 vlandev em0" ifconfig_vlan2="inet 10.13.1.1 netmask 255.255.255.0 vlan 4 vlandev em0" ifconfig_vlan3="inet 10.14.1.1 netmask 255.255.255.0 vlan 5 vlandev em0" ifconfig_vlan4="inet 10.15.1.1 netmask 255.255.255.0 vlan 6 vlandev em0" gateway_enable="YES" rpcbind_enable="NO" ipfw_enable="YES" ipfw_enable="YES" ipfw_type="OPEN" pf_enable="YES" pf_rules="/etc/pf.conf" router_enable="NO" #########dhcp################# dhcpd_enable="YES" dhcpd_flags="-q" dhcpd_ifaces="vlan1 vlan2 vlan3 vlan4" dhcpd_chroot_enable="YES" dhcpd_conf="/usr/local/etc/dhcpd.conf"   dhcpd_devfs_enable="YES" dhcpd_jail_enable="NO" # cat /etc/sysctl.conf kern.maxfiles=128000 kern.maxfilesperproc=65000 kern.ipc.somaxconn=32768 net.inet.ip.intr_queue_maxlen=200 kern.ipc.maxsockbuf=1048576 net.inet.tcp.sendspace=65535 net.inet.tcp.recvspace=32768 net.inet.udp.recvspace=655350 net.inet.icmp.drop_redirect=1 net.inet.udp.blackhole=2 net.inet.tcp.blackhole=2 net.inet.tcp.msl=7500 kern.ipc.maxsockets=204800 # cat /etc/pf.conf scrub in all pass in all pass out all #pftop pfTop: Up State 1-30/578, View: default, Order: none, Cache: 10000 14:18:08 # pfctl -s info Status: Enabled for 0 days 00:27:07           Debug: Urgent State Table                          Total             Rate   current entries                      566   searches                         8512194         5231.8/s   inserts                            21525           13.2/s   removals                           20959           12.9/s Counters   match                            4340001         2667.5/s   bad-offset                             0            0.0/s   fragment                               0            0.0/s   short                                  0            0.0/s   normalize                              0            0.0/s   memory                                 0            0.0/s   bad-timestamp                          0            0.0/s   congestion                             0            0.0/s   ip-option                              0            0.0/s   proto-cksum                            1            0.0/s   state-mismatch                        31            0.0/s   state-insert                           0            0.0/s   state-limit                            0            0.0/s   src-limit                              0            0.0/s   synproxy                               0            0.0/s #ipfw show 00008 13848862  8065556536 allow gre from any to any 00009        0           0 allow udp from any to any dst-port 500 00010    17332     1051156 allow tcp from any to any dst-port 1023,1723 00011        0           0 allow esp from any to any 00024        0           0 allow udp from 0.0.0.0 2054 to 0.0.0.0 00025        0           0 deny icmp from any to any in icmptypes 5,9,13,14,15,16,17 00026        0           0 deny tcp from any to me in tcpflags syn,fin,! ack 00027        0           0 deny tcp from any to me in tcpflags syn,fin,! ack,psh,urg 00028        0           0 deny tcp from any to me in tcpflags fin,! ack,psh,urg 00203     4263      581066 pipe 12 ip from 10.11.25.1 to any via vlan1 00204     2763      147041 pipe 12 ip from any to 10.11.25.1 via vlan1 00205  5944333  5438517982 pipe 13 ip from any to any via vlan1 00206      1585      240264 pipe 14 ip from 10.11.25.1 to any via vlan2 00207     859       52217 pipe 14 ip from any to 10.11.25.1 via vlan2 00208  19187     5468180 pipe 15 ip from any to any via vlan2 00209     0      0 pipe 16 ip from 10.11.25.1 to any via vlan3 00210     0      0 pipe 16 ip from any to 10.11.25.1 via vlan3 00211  0  0 pipe 17 ip from any to any via vlan3 [root@f7RC1 /usr/src/sys/i386/conf]# cat ROUTER cpu             I686_CPU ident           ROUTER options         SCHED_ULE options IPFIREWALL options IPFIREWALL_VERBOSE #options IPDIVERT options IPFIREWALL_FORWARD #options IPV6FIREWALL #options IPV6FIREWALL_VERBOSE options DUMMYNET options DEVICE_POLLING I create Vlan's on DES-3016, with differents VID: DES-3016:4#show vlan Command: show vlan .... VID             : 3          VLAN Name       : 3 VLAN Type       : static Member ports    : 1,7 Static ports    : 1,7 Tagged ports    : 1 Untagged ports  : 7 VID             : 4          VLAN Name       : 4 VLAN Type       : static Member ports    : 1,8 Static ports    : 1,8 Tagged ports    : 1 Untagged ports  : 8 VID             : 5          VLAN Name       : 5 VLAN Type       : static Member ports    : 1,9 Static ports    : 1,9 Tagged ports    : 1 Untagged ports  : 9 ............ Total Entries  : 10 From owner-freebsd-net@FreeBSD.ORG Fri Apr 25 12: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 8ADF7106566C for ; Fri, 25 Apr 2008 12: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 62B608FC18 for ; Fri, 25 Apr 2008 12: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 m3PCo3Vu045616 for ; Fri, 25 Apr 2008 12: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 m3PCo3UR045615; Fri, 25 Apr 2008 12:50:03 GMT (envelope-from gnats) Date: Fri, 25 Apr 2008 12:50:03 GMT Message-Id: <200804251250.m3PCo3UR045615@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Eric F Crist Cc: Subject: Re: kern/123053 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric F Crist List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2008 12:50:03 -0000 The following reply was made to PR kern/123053; it has been noted by GNATS. From: Eric F Crist To: pyunyh@gmail.com Cc: linimon@FreeBSD.org, freebsd-drivers@FreeBSD.org, bug-followup@freebsd.org Subject: Re: kern/123053 Date: Fri, 25 Apr 2008 07:29:01 -0500 On Apr 24, 2008, at 7:25 PM, Pyun YongHyeon wrote: > On Thu, Apr 24, 2008 at 05:54:13PM -0500, Eric F Crist wrote: >> Andrey, >> >> I've applied the patch to a 7.0-RELEASE-p1 source tree and rebooted >> my >> system. The card comes UP ok, but shows the following when connected >> to a 100BaseT/ Full Duplex switch port: >> > > By chance, are you referring to kern/123053? That's what the subject of the email says... > >> re0: flags=8802 metric 0 mtu 1500 >> options=9b >> ether 00:1f:c6:52:7b:80 >> media: Ethernet autoselect (10baseT/UTP ) >> status: active >> >> Once I've assigned an IP to the interface, however, it comes up >> correctly and seems to function just fine. Is there any load testing > > I think, that's normal. > >> I should perform for you folks? >> > > Try one of network benchmarks in ports/benchmarks if you want. > >> re0: flags=8843 metric 0 mtu >> 1500 >> options=9b >> ether 00:1f:c6:52:7b:80 >> inet 10.0.0.38 netmask 0xffff0000 broadcast 10.0.255.255 >> media: Ethernet autoselect (100baseTX ) >> status: active I've run some benchmarks, and they seemed to go pretty badly. After running a few, I realized that I still had two network interfaces up, (em0, and the testing re0), I did an ifconfig em0 down, and was unable to connect in or out from the remaining re0. Perhaps this code isn't all the way complete. Eric ----- Eric F Crist Secure Computing Networks From owner-freebsd-net@FreeBSD.ORG Fri Apr 25 16:17:01 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 79CD4106564A for ; Fri, 25 Apr 2008 16:17:01 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 297BF8FC14 for ; Fri, 25 Apr 2008 16:17:00 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9506F7318D; Fri, 25 Apr 2008 18:00:39 +0200 (CEST) Date: Fri, 25 Apr 2008 18:00:39 +0200 From: Luigi Rizzo To: net@freebsd.org, current@freebsd.org Message-ID: <20080425160039.GA65918@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: 'nfe' stalls (analysis and partial solution) 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, 25 Apr 2008 16:17:01 -0000 just for the record and the mail archives - i have been experiencing a lot of unrecovered stalls of the network card with the 'nfe' driver under heavy load (this was on 7.0-i386 and 7.0-amd64, but it is hardware related so it cross-platform). After 2-3 days of investigation, and with the help of Pyun YongHyeon (yongari) i finally managed to pin down the problem and start working on a solution. I would be grateful if others can report of similar problems with the 'nfe' driver so we can see if the patch we can come up with also fix their problem. THE PROBLEM: under heavy load (e.g. full speed ssh transfers, disk activity, Xwindows...) causing the receive ring to fill up, it seems that some nfe-supported cards (at least the MCP67) enter a state where they stop looking at the ring buffers and drop incoming packets. The driver does not recover from the error so you manually have to 'ifconfig down; ifconfig up' the interface to restart receiving. SOLUTION: I have not yet determined the exact conditions causing the error, so as a temporary workaround i am calling nfe_init_locked() every from the watchdog routine every time a receive error of some kind is experienced. I definitely need to apply stricter checks on the error condition, but some more extra card reset is certainly better than losing contact with the machine. Unfortunately there is no documentation on this behaviour of the card, and the linux driver (forcedeth) has no error checking/recovery at all so it is of no help. cheers luigi From owner-freebsd-net@FreeBSD.ORG Fri Apr 25 19:43:41 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 146FF106566C for ; Fri, 25 Apr 2008 19:43:41 +0000 (UTC) (envelope-from SRS0=cd4a9d400e82bedad4d633473a864a6647e785d3=682=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 8B7D78FC1C for ; Fri, 25 Apr 2008 19:43:40 +0000 (UTC) (envelope-from SRS0=cd4a9d400e82bedad4d633473a864a6647e785d3=682=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id FXQ99437 for ; Fri, 25 Apr 2008 12:43:37 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id AFB7245010 for ; Fri, 25 Apr 2008 12:43:37 -0700 (PDT) To: net@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1209152617_37085P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 25 Apr 2008 12:43:37 -0700 From: "Kevin Oberman" Message-Id: <20080425194337.AFB7245010@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; X-Sender: X-To_Name: X-To_Domain: freebsd.org X-To: net@freebsd.org X-To_Email: net@freebsd.org X-To_Alias: net Cc: Subject: ipfw can't be disabled for IPv56 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, 25 Apr 2008 19:43:41 -0000 --==_Exmh_1209152617_37085P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Running 7-STABLE of April 10, if I disable the firewall ('sysctl net.inet.ip.fw.enable=0'), IPv4 traffic passes, but IPv6 will not. I had to add a "allow ip from any to any" rule to get IPv6 to work pass traffic. (Since I was accessing the system in question via IPv6, this was a bit annoying!) Am I missing anything? The rc.subr script for ipfw just sets the sysctl I did when it stops the firewall. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1209152617_37085P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIEjRpkn3rs5h7N1ERAqZrAKC2lanklFoXJgk/RdnZroJs9BEsawCeJNHf yxopoc5z6LW6YwRj5M8paWY= =sclA -----END PGP SIGNATURE----- --==_Exmh_1209152617_37085P-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 25 20:16:48 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 A4DC8106564A for ; Fri, 25 Apr 2008 20:16:48 +0000 (UTC) (envelope-from tobias@netconsultoria.com.br) Received: from srv1.netconsultoria.com.br (srv1.netconsultoria.com.br [189.1.176.252]) by mx1.freebsd.org (Postfix) with ESMTP id 30A238FC1B for ; Fri, 25 Apr 2008 20:16:47 +0000 (UTC) (envelope-from tobias@netconsultoria.com.br) Received: from [172.16.16.100] (mailgw.ntelecom.com.br [189.1.176.249]) (authenticated bits=0) by srv1.netconsultoria.com.br (8.13.8/8.13.3) with ESMTP id m3PJmgNd031890; Fri, 25 Apr 2008 16:48:42 -0300 (BRT) (envelope-from tobias@netconsultoria.com.br) Message-ID: <4812359E.5040800@netconsultoria.com.br> Date: Fri, 25 Apr 2008 16:48:46 -0300 From: "Tobias P. Santos" User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Kevin Oberman References: <20080425194337.AFB7245010@ptavv.es.net> In-Reply-To: <20080425194337.AFB7245010@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.7/6938/Fri Apr 25 14:01:47 2008 on srv1.netconsultoria.com.br X-Virus-Status: Clean Cc: net@freebsd.org Subject: Re: ipfw can't be disabled for IPv56 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, 25 Apr 2008 20:16:48 -0000 Kevin Oberman wrote: > Running 7-STABLE of April 10, if I disable the firewall ('sysctl > net.inet.ip.fw.enable=0'), IPv4 traffic passes, but IPv6 will not. I had > to add a "allow ip from any to any" rule to get IPv6 to work pass > traffic. (Since I was accessing the system in question via IPv6, this > was a bit annoying!) > > Am I missing anything? The rc.subr script for ipfw just sets the sysctl I > did when it stops the firewall. # sysctl -a | grep fw net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.static_count: 8 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.dyn_count: 0 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 1 net.inet.ip.fw.debug: 1 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.enable: 1 net.link.ether.ipfw: 0 net.inet6.ip6.fw.enable: 1 <------------ voila!!! net.inet6.ip6.fw.debug: 1 net.inet6.ip6.fw.verbose: 1 net.inet6.ip6.fw.verbose_limit: 0 net.inet6.ip6.fw.deny_unknown_exthdrs: 1 From owner-freebsd-net@FreeBSD.ORG Fri Apr 25 21:16:26 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 D50F7106566B for ; Fri, 25 Apr 2008 21:16:26 +0000 (UTC) (envelope-from SRS0=cd4a9d400e82bedad4d633473a864a6647e785d3=682=es.net=oberman@es.net) Received: from postal1.es.net (postal3.es.net [IPv6:2001:400:14:3::8]) by mx1.freebsd.org (Postfix) with ESMTP id 434F88FC17 for ; Fri, 25 Apr 2008 21:16:26 +0000 (UTC) (envelope-from SRS0=cd4a9d400e82bedad4d633473a864a6647e785d3=682=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id FZP08422; Fri, 25 Apr 2008 14:16:22 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 302CB45010; Fri, 25 Apr 2008 14:16:22 -0700 (PDT) To: "Tobias P. Santos" In-Reply-To: Your message of "Fri, 25 Apr 2008 16:48:46 -0300." <4812359E.5040800@netconsultoria.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1209158182_37085P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 25 Apr 2008 14:16:22 -0700 From: "Kevin Oberman" Message-Id: <20080425211622.302CB45010@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ;; X-Sender: X-To_Name: Tobias P. Santos X-To_Domain: netconsultoria.com.br X-To: "Tobias P. Santos" X-To_Email: tobias@netconsultoria.com.br X-To_Alias: tobias Cc: net@freebsd.org Subject: Re: ipfw can't be disabled for IPv56 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, 25 Apr 2008 21:16:26 -0000 --==_Exmh_1209158182_37085P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Fri, 25 Apr 2008 16:48:46 -0300 > From: "Tobias P. Santos" > > Kevin Oberman wrote: > > Running 7-STABLE of April 10, if I disable the firewall ('sysctl > > net.inet.ip.fw.enable=0'), IPv4 traffic passes, but IPv6 will not. I had > > to add a "allow ip from any to any" rule to get IPv6 to work pass > > traffic. (Since I was accessing the system in question via IPv6, this > > was a bit annoying!) > > > > Am I missing anything? The rc.subr script for ipfw just sets the sysctl I > > did when it stops the firewall. > > > # sysctl -a | grep fw > net.inet.ip.fw.dyn_keepalive: 1 > net.inet.ip.fw.dyn_short_lifetime: 5 > net.inet.ip.fw.dyn_udp_lifetime: 10 > net.inet.ip.fw.dyn_rst_lifetime: 1 > net.inet.ip.fw.dyn_fin_lifetime: 1 > net.inet.ip.fw.dyn_syn_lifetime: 20 > net.inet.ip.fw.dyn_ack_lifetime: 300 > net.inet.ip.fw.static_count: 8 > net.inet.ip.fw.dyn_max: 4096 > net.inet.ip.fw.dyn_count: 0 > net.inet.ip.fw.curr_dyn_buckets: 256 > net.inet.ip.fw.dyn_buckets: 256 > net.inet.ip.fw.verbose_limit: 0 > net.inet.ip.fw.verbose: 1 > net.inet.ip.fw.debug: 1 > net.inet.ip.fw.one_pass: 1 > net.inet.ip.fw.autoinc_step: 100 > net.inet.ip.fw.enable: 1 > net.link.ether.ipfw: 0 > net.inet6.ip6.fw.enable: 1 <------------ voila!!! > net.inet6.ip6.fw.debug: 1 > net.inet6.ip6.fw.verbose: 1 > net.inet6.ip6.fw.verbose_limit: 0 > net.inet6.ip6.fw.deny_unknown_exthdrs: 1 > Thanks! I need to file a PR to get that into the rc script. I should have looked for a inet6 specific sysctl for this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1209158182_37085P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIEkomkn3rs5h7N1ERAt6IAJ0dvSZCWJX/b6h794zE3G2MOhOpHgCgmSXx Uc9+vjWY+tvDXxOw0fTyD+k= =GQ0W -----END PGP SIGNATURE----- --==_Exmh_1209158182_37085P-- From owner-freebsd-net@FreeBSD.ORG Sat Apr 26 01:10: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 19E1B1065687 for ; Sat, 26 Apr 2008 01:10:04 +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 183878FC0C for ; Sat, 26 Apr 2008 01:10:04 +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 m3Q1A3tP006002 for ; Sat, 26 Apr 2008 01:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3Q1A3aW006000; Sat, 26 Apr 2008 01:10:03 GMT (envelope-from gnats) Date: Sat, 26 Apr 2008 01:10:03 GMT Message-Id: <200804260110.m3Q1A3aW006000@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: hotlips Internet admin Cc: Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hotlips Internet admin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2008 01:10:04 -0000 The following reply was made to PR kern/122875; it has been noted by GNATS. From: hotlips Internet admin To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: bug-followup@FreeBSD.org Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) Date: Fri, 25 Apr 2008 20:50:51 -0400 (EDT) On Fri, 18 Apr 2008 FreeBSD-gnats-submit@FreeBSD.org wrote: |Thank you very much for your problem report. |It has the internal identification `kern/122875'. |The individual assigned to look at your |report is: freebsd-bugs. | |You can access the state of your problem report at any time |via this link: | |http://www.freebsd.org/cgi/query-pr.cgi?pr=122875 | |>Category: kern |>Responsible: freebsd-bugs |>Synopsis: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) |>Arrival-Date: Fri Apr 18 02:20:00 UTC 2008 this also happens in FreeBSD 6.3-STABLE I depend heavily on rpc.rstatd as a part of monitoring servers and firewalls etc., so this is a serious issue for me until I can get a fix or work-around Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@GTS.Infra-service.CA From owner-freebsd-net@FreeBSD.ORG Sat Apr 26 01:10: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 2F8D51065674 for ; Sat, 26 Apr 2008 01:10:06 +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 2A27C8FC12 for ; Sat, 26 Apr 2008 01:10:06 +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 m3Q1A5ax006014 for ; Sat, 26 Apr 2008 01:10:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3Q1A5Nk006013; Sat, 26 Apr 2008 01:10:05 GMT (envelope-from gnats) Date: Sat, 26 Apr 2008 01:10:05 GMT Message-Id: <200804260110.m3Q1A5Nk006013@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: hotlips Internet admin Cc: Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hotlips Internet admin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2008 01:10:06 -0000 The following reply was made to PR kern/122875; it has been noted by GNATS. From: hotlips Internet admin To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: bug-followup@FreeBSD.org Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) Date: Fri, 25 Apr 2008 20:50:51 -0400 (EDT) On Fri, 18 Apr 2008 FreeBSD-gnats-submit@FreeBSD.org wrote: |Thank you very much for your problem report. |It has the internal identification `kern/122875'. |The individual assigned to look at your |report is: freebsd-bugs. | |You can access the state of your problem report at any time |via this link: | |http://www.freebsd.org/cgi/query-pr.cgi?pr=122875 | |>Category: kern |>Responsible: freebsd-bugs |>Synopsis: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) |>Arrival-Date: Fri Apr 18 02:20:00 UTC 2008 this also happens in FreeBSD 6.3-STABLE I depend heavily on rpc.rstatd as a part of monitoring servers and firewalls etc., so this is a serious issue for me until I can get a fix or work-around Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@GTS.Infra-service.CA From owner-freebsd-net@FreeBSD.ORG Sat Apr 26 05:59:09 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 61A0B1065670 for ; Sat, 26 Apr 2008 05:59:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 31CBC8FC19 for ; Sat, 26 Apr 2008 05:59:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2559364rvf.43 for ; Fri, 25 Apr 2008 22:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=tukGEHgedY6AJn0UMDGx8RoGE2MIlDhTbrp1jv8qNnk=; b=AJ9PKah7vIo6/tgug2Abx6SAf0/fVQe6l403WL1NMZOT5fJNzsGwdQ3Ipgwl5RAMy+fYFlSkT2Zh1ADvJnsnLr6AeaYvAXhL2CODnd6jGxTT/5+VLlXdRxha74Qo/UHBwQQOJnoL7fjFjjWxFJM7n8cHR1w4avkedII+hKQM6VQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=eshLT7AOcAT8x6j3+j1Us3mMh3+PleIKBZMrd954NArD+RwcMBDMHUoab7P4xeSOYy57beAU/I4y0T4vpcdC/CM64dptgO+9tzTifhUHdNsPVt95bDd1FQMBjHfkDywGQot3c4XrJ+1xjsi1l9kJxzjJKwYMazYksYR2/Sy5TJU= Received: by 10.141.74.17 with SMTP id b17mr868166rvl.234.1209188025543; Fri, 25 Apr 2008 22:33:45 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id k2sm3286231rvb.6.2008.04.25.22.33.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Apr 2008 22:33:43 -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 m3Q5XcuV067902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Apr 2008 14:33:38 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m3Q5XbFo067901; Sat, 26 Apr 2008 14:33:37 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 26 Apr 2008 14:33:37 +0900 From: Pyun YongHyeon To: Luigi Rizzo Message-ID: <20080426053337.GE67361@cdnetworks.co.kr> References: <20080425160039.GA65918@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080425160039.GA65918@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org, net@freebsd.org Subject: Re: 'nfe' stalls (analysis and partial solution) 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: Sat, 26 Apr 2008 05:59:09 -0000 On Fri, Apr 25, 2008 at 06:00:39PM +0200, Luigi Rizzo wrote: > just for the record and the mail archives - i have been experiencing > a lot of unrecovered stalls of the network card with the 'nfe' > driver under heavy load (this was on 7.0-i386 and 7.0-amd64, but > it is hardware related so it cross-platform). > > After 2-3 days of investigation, and with the help of > Pyun YongHyeon (yongari) i finally managed to pin down the > problem and start working on a solution. > > I would be grateful if others can report of similar problems > with the 'nfe' driver so we can see if the patch we can come > up with also fix their problem. > > THE PROBLEM: > under heavy load (e.g. full speed ssh transfers, disk activity, > Xwindows...) causing the receive ring to fill up, it seems that > some nfe-supported cards (at least the MCP67) enter a state where > they stop looking at the ring buffers and drop incoming packets. > > The driver does not recover from the error so you manually have > to 'ifconfig down; ifconfig up' the interface to restart > receiving. > I tried to reprocude this on CK804 MCP9 hardware but nfe(4) recovered successfully from this Rx ring full condition. Of course, I still don't know how to reliably reproduce Rx stalls but just Rx ring full condition doesn't seem to trigger Rx stalls on CK804 MCP9. As Luigi said, it's also possible only some NVIDIA chips can have this issue. If you happen to see this issue please let us know what chip/model you have. The Rx ring full condition could be easily triggered by sending lots of UDP packets with network benchmark programs. In order to increase the possibility of the Rx ring full condition, running buildworld while benchmark test is in progress would certainly trigger the condition. > SOLUTION: > I have not yet determined the exact conditions causing the error, > so as a temporary workaround i am calling nfe_init_locked() every > from the watchdog routine every time a receive error of some kind > is experienced. > > I definitely need to apply stricter checks on the error condition, > but some more extra card reset is certainly better than losing contact > with the machine. Unfortunately there is no documentation on this > behaviour of the card, and the linux driver (forcedeth) has no > error checking/recovery at all so it is of no help. > > cheers > luigi -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Sat Apr 26 07:51:31 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 DCEE91065678 for ; Sat, 26 Apr 2008 07:51:31 +0000 (UTC) (envelope-from vova@sw.ru) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id 80AB08FC19 for ; Sat, 26 Apr 2008 07:51:31 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru (user2.netvox.ru [193.19.83.2]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id m3Q7BDpP007784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Apr 2008 11:11:14 +0400 (MSD) Received: from vova by vbook.fbsd.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JpeYy-0000me-Ju; Sat, 26 Apr 2008 11:11:12 +0400 From: Vladimir Grebenschikov To: Roland Smith In-Reply-To: <20080425160047.GC86456@slackbox.xs4all.nl> References: <1209126314.1519.36.camel@localhost> <20080425160047.GC86456@slackbox.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Sat, 26 Apr 2008 11:11:11 +0400 Message-Id: <1209193871.2000.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: stable@freebsd.org, freebsd-net Subject: Re: Crash with recent kernel on wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2008 07:51:31 -0000 On Fri, 2008-04-25 at 18:00 +0200, Roland Smith wrote: > On Fri, Apr 25, 2008 at 04:25:14PM +0400, Vladimir Grebenschikov wrote: > > Hi > > > > Recently I've upgraded 7-STABLE: Mar 11 -> Apr 24 > > > > Everything was fine until I've tried to configure wireless (ath driver, > > WPA) > > It crashes every time after interface becomes UP, > > (I've seen associated in ifconfig output before crash), but before dhcp > > finished to get IP. > You should use the kernel image with the debugging symbols here. If > you > build and install a kernel, you get two kernel images on 7.x; > 1) /boot/kernel/kernel (your regular kernel) > 2) /boot/kernel/kernel.symbols (with the debug symbols) Hm, I've thought before, that it will show back-trace even without debug symbols. Anyway, gdb still complains about "linker_file" and "not as structure pointer" But shows stop point. Not much info here :( cat /var/crash/info.44 Dump header from device /dev/ad0s2b Architecture: i386 Architecture Version: 2 Dump Length: 190091264B (181 MB) Blocksize: 512 Dumptime: Sat Apr 26 10:50:05 2008 Hostname: vbook.fbsd.ru Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-STABLE #3: Sat Apr 26 10:20:31 MSD 2008 root@vbook.fbsd.ru:/usr/src/sys/i386/compile/VBOOK Panic String: page fault Dump Parity: 4236056142 Bounds: 44 Dump Status: good kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.44 [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". No struct type named linker_file. No struct type named linker_file. No struct type named linker_file. No struct type named linker_file. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0542757 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 #2 0xc0542a53 in panic (fmt=Variable "fmt" is not available.) at ../../../kern/kern_shutdown.c:572 #3 0xc06a8870 in trap_fatal () #4 0xc06a8c2a in trap_pfault () #5 0xc06a957e in trap () #6 0xc068e80b in calltrap () #7 0xc58b68d5 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Most of crashes even failed to save vmdump due to double faults. Looks like it is really related to wireless code. Effect happens only at my home WiFi network and does not happens at work (WPA-PSK vs PEAP) and always current process in nmbd (broadcasting ?). Crash happens with both 4BSD and ULE schedulers. My system have dual-core Intel x86 CPU (SMP kernel) > Roland -- Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Sat Apr 26 09:02:53 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 A4342106564A; Sat, 26 Apr 2008 09:02:53 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3A48FC1A; Sat, 26 Apr 2008 09:02:53 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3C04F7318D; Sat, 26 Apr 2008 11:05:12 +0200 (CEST) Date: Sat, 26 Apr 2008 11:05:12 +0200 From: Luigi Rizzo To: net@freebsd.org, current@freebsd.org Message-ID: <20080426090512.GB74094@onelab2.iet.unipi.it> References: <20080425160039.GA65918@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080425160039.GA65918@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: 'nfe' stalls (analysis and partial solution) 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, 26 Apr 2008 09:02:53 -0000 On Fri, Apr 25, 2008 at 06:00:39PM +0200, Luigi Rizzo wrote: > just for the record and the mail archives - i have been experiencing > a lot of unrecovered stalls of the network card with the 'nfe' > driver under heavy load (this was on 7.0-i386 and 7.0-amd64, but > it is hardware related so it cross-platform). > > After 2-3 days of investigation, and with the help of > Pyun YongHyeon (yongari) i finally managed to pin down the > problem and start working on a solution. > > I would be grateful if others can report of similar problems > with the 'nfe' driver so we can see if the patch we can come > up with also fix their problem. followup: a patch to address the problem is available at http://info.iet.unipi.it/~luigi/FreeBSD/ (current version is http://info.iet.unipi.it/~luigi/FreeBSD/nfe-20080426.1044.diff but it might change with time as we get more details or info on how to deal with this problem). cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Apr 26 13:09:08 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 758) id 34B5F1065677; Sat, 26 Apr 2008 13:09:08 +0000 (UTC) Date: Sat, 26 Apr 2008 13:09:08 +0000 From: Kris Kennaway To: misha saf Message-ID: <20080426130908.GE47671@hub.freebsd.org> References: <200804250720.m3P7K3Jk019605@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200804250720.m3P7K3Jk019605@freefall.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@FreeBSD.org Subject: Re: misc/123066: kernel trap with ipsec 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, 26 Apr 2008 13:09:08 -0000 On Fri, Apr 25, 2008 at 07:20:03AM +0000, misha saf wrote: > The following reply was made to PR kern/123066; it has been noted by GNATS. > > From: misha saf > To: Kris Kennaway > Cc: > Subject: Re: misc/123066: kernel trap with ipsec > Date: Fri, 25 Apr 2008 10:59:33 +0400 > > * Kris Kennaway [Fri, 25 Apr 2008 05:46:54 +0000]: > > On Fri, Apr 25, 2008 at 04:13:40AM +0000, Mihail wrote: > > > > > (kgdb) backtrace > > > #0 doadump () at pcpu.h:195 > > > #1 0xc075df57 in boot (howto=260) at > > /usr/src/sys/kern/kern_shutdown.c:409 > > > #2 0xc075e219 in panic (fmt=Variable "fmt" is not available. > > > ) at /usr/src/sys/kern/kern_shutdown.c:563 > > > #3 0xc0a9766c in trap_fatal (frame=0xc884e934, eva=3621180904) > > > at /usr/src/sys/i386/i386/trap.c:899 > > > #4 0xc0a978f0 in trap_pfault (frame=0xc884e934, usermode=0, > > eva=3621180904) > > > at /usr/src/sys/i386/i386/trap.c:812 > > > #5 0xc0a9829c in trap (frame=0xc884e934) at > > /usr/src/sys/i386/i386/trap.c:490 > > > #6 0xc0a7e21b in calltrap () at > > /usr/src/sys/i386/i386/exception.s:139 > > > #7 0xc0a952f6 in generic_bcopy () at > > /usr/src/sys/i386/i386/support.s:498 > > > Previous frame inner to this frame (corrupt stack?) > > > > Unfortunately we need the rest of the stack. Can you either try to > > reproduce with DDB in the kernel and obtain a stack trace from there, > > or if this is not possible then try recompiling the kernel with -O > > instead of -O2 which tends to produce better stack traces. > > > > Kris > That's all needed info ? No, stack frames 8 and beyond contained the important parts of the stack trace, but were not displayed by gdb. What we need is what I explained above. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe From owner-freebsd-net@FreeBSD.ORG Sat Apr 26 15:44: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 3364A1065670 for ; Sat, 26 Apr 2008 15:44:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 11AB58FC19 for ; Sat, 26 Apr 2008 15:44:37 +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, 26 Apr 2008 11:25:39 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id EEDC22D6006 for ; Sat, 26 Apr 2008 08:44:32 -0700 (PDT) Message-ID: <48134DDE.9010306@elischer.org> Date: Sat, 26 Apr 2008 08:44:30 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Multiple routing tables in action... 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, 26 Apr 2008 15:44:37 -0000 A little progress report From a recently installed (6.3) machine.... (plus patches) wsa02:julian 9] setfib -0 netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.28.14.1 UGS 0 788 bce1 127.0.0.1 127.0.0.1 UH 0 379 lo0 172.28.5/24 172.28.14.1 UGS 0 10 bce1 172.28.6.32/28 link#2 UC 0 0 em0 172.28.6.33 00:15:2b:46:56:90 UHLW 1 0 em0 1190 172.28.14/24 link#6 UC 0 0 bce1 172.28.14.1 00:04:23:b5:a9:2b UHLW 3 0 bce1 1117 wsa02:julian 10] setfib -1 netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.28.6.33 UGS 0 0 em0 1.1.1/28 172.28.6.33 UGS 0 0 em0 127.0.0.1 127.0.0.1 UH 0 1 lo0 172.28.5/24 172.28.6.33 UGS 0 6 em0 172.28.6.32/28 link#2 UC 0 0 em0 172.28.6.33 00:15:2b:46:56:90 UHLW 4 6 em0 1182 wsa02:rjulian 11] From owner-freebsd-net@FreeBSD.ORG Sat Apr 26 18:37: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 187D41065676 for ; Sat, 26 Apr 2008 18:37:41 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id 9FAE98FC1E for ; Sat, 26 Apr 2008 18:37:40 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so6645765pyb.10 for ; Sat, 26 Apr 2008 11:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9gtdv0j6svObq5UIDDbAfSY+RRm1lh82XyA0H6ptQFE=; b=AE+bsC5zCEn8o3wGxua+Diw3rCrE0RhLJP4l9fm0WsB0y40mBu3W6QluAwZaGF47duiMpWmuhzC+GxIiZgwbSNnnCYARWNCigV9RvIz35W6ikXc7u3LtXaYhnysMIxNVFPa+fFXYt2ZrKsuDuXCTLo94FIx2hWfDGrxGgtq/GQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nGPWUTlX60W3x7u/PL+CLkXX5iJurOFaV3zveUjuxwvrwHxNhpVt460VBLe6BFqemIfJjpoAh5a+wNxzGeMR3Ss+JxL2l+Zx+yQd1YE4t6ZybSSDyFnaQ1V+0ZLszTOzwZs8c19iFPBggXBDJjWjEcgKsybZQAskBXO8Ek96P4g= Received: by 10.142.47.6 with SMTP id u6mr1559299wfu.159.1209233345456; Sat, 26 Apr 2008 11:09:05 -0700 (PDT) Received: by 10.142.127.17 with HTTP; Sat, 26 Apr 2008 11:09:05 -0700 (PDT) Message-ID: Date: Sat, 26 Apr 2008 21:09:05 +0300 From: "Ivo Vachkov" To: "FreeBSD Net" In-Reply-To: <48134DDE.9010306@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48134DDE.9010306@elischer.org> Subject: Re: Multiple routing tables in action... 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, 26 Apr 2008 18:37:41 -0000 when do we get to see those patches ? :) On Sat, Apr 26, 2008 at 6:44 PM, Julian Elischer wrote: > A little progress report > > From a recently installed (6.3) machine.... (plus patches) > > wsa02:julian 9] setfib -0 netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 172.28.14.1 UGS 0 788 bce1 > 127.0.0.1 127.0.0.1 UH 0 379 lo0 > 172.28.5/24 172.28.14.1 UGS 0 10 bce1 > 172.28.6.32/28 link#2 UC 0 0 em0 > 172.28.6.33 00:15:2b:46:56:90 UHLW 1 0 em0 1190 > 172.28.14/24 link#6 UC 0 0 bce1 > 172.28.14.1 00:04:23:b5:a9:2b UHLW 3 0 bce1 1117 > wsa02:julian 10] setfib -1 netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 172.28.6.33 UGS 0 0 em0 > 1.1.1/28 172.28.6.33 UGS 0 0 em0 > 127.0.0.1 127.0.0.1 UH 0 1 lo0 > 172.28.5/24 172.28.6.33 UGS 0 6 em0 > 172.28.6.32/28 link#2 UC 0 0 em0 > 172.28.6.33 00:15:2b:46:56:90 UHLW 4 6 em0 1182 > wsa02:rjulian 11] > > _______________________________________________ > 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" > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From owner-freebsd-net@FreeBSD.ORG Sat Apr 26 23:04: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 41F491065670 for ; Sat, 26 Apr 2008 23:04:21 +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 1C3258FC0A for ; Sat, 26 Apr 2008 23:04:20 +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, 26 Apr 2008 18:45:53 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 4E7202D601B; Sat, 26 Apr 2008 16:04:19 -0700 (PDT) Message-ID: <4813B4F2.9030402@elischer.org> Date: Sat, 26 Apr 2008 16:04:18 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ivo Vachkov References: <48134DDE.9010306@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Multiple routing tables in action... 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, 26 Apr 2008 23:04:21 -0000 Ivo Vachkov wrote: > when do we get to see those patches ? :) for -current: http://www.freebsd.org/~julian/mrt.diff for releng_6: http://www.freebsd.org/~julian/mrt6.diff > > On Sat, Apr 26, 2008 at 6:44 PM, Julian Elischer wrote: >> A little progress report >> >> From a recently installed (6.3) machine.... (plus patches) >> >> wsa02:julian 9] setfib -0 netstat -rn >> Routing tables >> >> Internet: >> Destination Gateway Flags Refs Use Netif Expire >> default 172.28.14.1 UGS 0 788 bce1 >> 127.0.0.1 127.0.0.1 UH 0 379 lo0 >> 172.28.5/24 172.28.14.1 UGS 0 10 bce1 >> 172.28.6.32/28 link#2 UC 0 0 em0 >> 172.28.6.33 00:15:2b:46:56:90 UHLW 1 0 em0 1190 >> 172.28.14/24 link#6 UC 0 0 bce1 >> 172.28.14.1 00:04:23:b5:a9:2b UHLW 3 0 bce1 1117 >> wsa02:julian 10] setfib -1 netstat -rn >> Routing tables >> >> Internet: >> Destination Gateway Flags Refs Use Netif Expire >> default 172.28.6.33 UGS 0 0 em0 >> 1.1.1/28 172.28.6.33 UGS 0 0 em0 >> 127.0.0.1 127.0.0.1 UH 0 1 lo0 >> 172.28.5/24 172.28.6.33 UGS 0 6 em0 >> 172.28.6.32/28 link#2 UC 0 0 em0 >> 172.28.6.33 00:15:2b:46:56:90 UHLW 4 6 em0 1182 >> wsa02:rjulian 11] >> >> _______________________________________________ >> 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 26 23:26: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 EEA67106566C for ; Sat, 26 Apr 2008 23:26: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 65C758FC23 for ; Sat, 26 Apr 2008 23:26:29 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jptmi-0000QI-RO for freebsd-net@freebsd.org; Sat, 26 Apr 2008 23:26:24 +0000 Received: from 78-1-98-246.adsl.net.t-com.hr ([78.1.98.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 26 Apr 2008 23:26:24 +0000 Received: from ivoras by 78-1-98-246.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 26 Apr 2008 23:26:24 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Sun, 27 Apr 2008 01:26:08 +0200 Lines: 189 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCEFACFF7774272DB9F86AA68" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-98-246.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: Connecting P1i to FreeBSD 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, 26 Apr 2008 23:26:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCEFACFF7774272DB9F86AA68 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Sepherosa Ziehau wrote: > Are you sure that your device works under IBSS mode? Yes, since Windows doesn't support creating an AP from the card, and it=20 connects to Windows. Unless there are other modes that can do the same=20 thing... > BTW, it looks like you have third machine that is equipped with > wireless device, so would you please grab a 802_11 tap when your > device tries to connect to rum on your freebsd box: > tcpdump -ni your_third_wlan_iface -y ieee802_11 -w dump.bin [nomenclature: let's call the FreeBSD machine with the rum interface,=20 the one I wish to associate the device with, the "gateway" and the other = one the "laptop"]. I have a scan from the the laptop, but apparently it doesn't record all=20 - only beacons and probe responses are in the dump and only from two=20 nodes - my own and one of the neighbours' (but it's a noisy neigbourhood = and the device finds at least three more APs. Here's a sample: 23:08:30.832242 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0*=20 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY 23:08:30.844990 Beacon (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0* 18.0=20 24.0 36.0 54.0 Mbit] ESS CH: 6, PRIVACY 23:08:31.011276 Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 = 12.0 18.0 Mbit] CH: 2 23:08:31.461225 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0*=20 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY 23:08:31.641185 Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 = 12.0 18.0 Mbit] CH: 2 23:08:32.272083 Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 = 12.0 18.0 Mbit] CH: 2 23:08:32.721339 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0*=20 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY 23:08:32.902988 Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 = 12.0 18.0 Mbit] CH: 2 23:08:33.351839 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0*=20 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY 23:08:33.533886 Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 = 12.0 18.0 Mbit] CH: 2 23:08:33.938823 Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 = 12.0 18.0 Mbit] CH: 2 23:08:33.940424 Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 = 12.0 18.0 Mbit] CH: 2 23:08:33.942064 Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 = 12.0 18.0 Mbit] CH: 2 23:08:33.944436 Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 = 12.0 18.0 Mbit] CH: 2 23:08:33.949696 Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 = 12.0 18.0 Mbit] CH: 2 23:08:33.953018 Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 = 12.0 18.0 Mbit] CH: 2 23:08:33.955180 Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 = 12.0 18.0 Mbit] CH: 2 Additionally, I've recorded from the gateway machine: 01:13:53.812038 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:13:53.812072 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:13:54.442969 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:13:54.442993 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:13:55.073911 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:13:55.073931 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:13:55.705028 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:13:55.705049 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:13:56.335801 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:13:56.335821 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:13:56.966747 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:13:56.966767 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:13:57.597697 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:13:57.597721 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:13:58.228636 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:13:58.228656 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:13:58.859586 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:13:58.859607 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:13:59.490529 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:13:59.490550 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:14:00.120474 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:14:00.120495 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:14:00.713427 0us Probe Request (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* Mbit]= 01:14:00.713446 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:14:00.751416 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:14:00.751435 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:14:01.383364 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:14:01.383384 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:14:02.014315 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:14:02.014338 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:14:02.644945 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:14:02.644970 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:14:02.790241 0us Probe Request (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* Mbit]= 01:14:02.790255 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 01:14:03.275200 0us Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0=20 18.0 Mbit] 01:14:03.275219 0us Probe Response (bsd7adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 = 9.0 12.0 18.0 Mbit] CH: 2 Raw scans are here: http://ivoras.sharanet.org/stuff/scans.tgz --------------enigCEFACFF7774272DB9F86AA68 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 iD8DBQFIE7oWldnAQVacBcgRAhpWAJ90vLNUtKcoijzCIBlvlY3gYGhQtACfXaO2 WpBl+1dTB5HRCn3qw4rVLk4= =QrdM -----END PGP SIGNATURE----- --------------enigCEFACFF7774272DB9F86AA68-- From owner-freebsd-net@FreeBSD.ORG Sat Apr 26 23:52:53 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 E9F9B106564A for ; Sat, 26 Apr 2008 23:52:53 +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 73E5D8FC1B for ; Sat, 26 Apr 2008 23:52:53 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JpuCJ-0001Q1-Sz for freebsd-net@freebsd.org; Sat, 26 Apr 2008 23:52:51 +0000 Received: from 78-1-98-246.adsl.net.t-com.hr ([78.1.98.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 26 Apr 2008 23:52:51 +0000 Received: from ivoras by 78-1-98-246.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 26 Apr 2008 23:52:51 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Sun, 27 Apr 2008 01:52:42 +0200 Lines: 123 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEAC39D8C3AF1F61FEDD593A9" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-98-246.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: Connecting P1i to FreeBSD 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, 26 Apr 2008 23:52:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEAC39D8C3AF1F61FEDD593A9 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > Sepherosa Ziehau wrote: >=20 >> Are you sure that your device works under IBSS mode? >=20 > Yes, since Windows doesn't support creating an AP from the card, and it= =20 > connects to Windows. Unless there are other modes that can do the same = > thing... Actually there is a difference; here's a dump from laptop where the=20 device connects to the Windows machine: 23:49:18.013539 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:18.045340 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVA= CY 23:49:18.148408 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:18.374477 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:18.377198 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:18.379066 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0*=20 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY 23:49:18.659907 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVA= CY 23:49:18.734842 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:18.762218 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVA= CY 23:49:19.005423 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:19.008301 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0*=20 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY 23:49:19.026747 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:19.366882 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:19.376645 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVA= CY 23:49:19.411652 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:19.636460 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:19.637575 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:19.888667 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVA= CY 23:49:19.990770 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVA= CY 23:49:19.997530 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:20.268038 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:20.269293 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:20.271670 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0*=20 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY 23:49:20.274467 Beacon (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0* 18.0=20 24.0 36.0 54.0 Mbit] ESS CH: 6, PRIVACY 23:49:20.297986 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVA= CY 23:49:20.492967 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:20.502751 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVA= CY 23:49:20.629491 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:20.707738 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVA= CY 23:49:20.899123 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:20.901458 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:20.989459 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:21.124700 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:21.219413 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVA= CY 23:49:21.259747 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:21.321793 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVA= CY 23:49:21.530624 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:21.531691 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6,=20 PRIVACY 23:49:21.533326 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0*=20 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY 23:49:21.833759 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVA= CY I didn't get the "Beacon" entries before. I expected to see actual data=20 packets in tcpdump, but I assume they are not in the dump because we're=20 only looking at the 802.11 events with -y ieee802_11? Other than this, all the other oddities are the same, and hopefully=20 insignificant. --------------enigEAC39D8C3AF1F61FEDD593A9 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 iD8DBQFIE8BLldnAQVacBcgRAtDHAKC8djlpCsH8Q3hbW+zmZ98LWK1aLQCg3Ib9 1kbZ9PaWvAEs4f+sLlID+FQ= =V4Cn -----END PGP SIGNATURE----- --------------enigEAC39D8C3AF1F61FEDD593A9--