From owner-freebsd-net@FreeBSD.ORG Mon Jul 17 11:02:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFB8816A516 for ; Mon, 17 Jul 2006 11:02:58 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 989FA43D46 for ; Mon, 17 Jul 2006 11:02:58 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6HB2wnu071594 for ; Mon, 17 Jul 2006 11:02:58 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6HB2uT8071590 for freebsd-net@freebsd.org; Mon, 17 Jul 2006 11:02:56 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 17 Jul 2006 11:02:56 GMT Message-Id: <200607171102.k6HB2uT8071590@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 17 Jul 2006 11:02:58 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2006/01/30] kern/92552 net A serious bug in most network drivers fro f [2006/02/12] kern/93220 net [inet6] nd6_lookup: failed to add route f o [2006/07/12] kern/100172 net [arp] Transfer of large file fails with h 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit o [2006/04/03] kern/95267 net packet drops periodically appear 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 17 11:54:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6711016A4DE for ; Mon, 17 Jul 2006 11:54:54 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id D185E43D53 for ; Mon, 17 Jul 2006 11:54:53 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 17 Jul 2006 04:54:53 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6HBsr68002481 for ; Mon, 17 Jul 2006 04:54:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6HBsrJi001148 for ; Mon, 17 Jul 2006 04:54:53 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 04:54:53 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 04:54:52 -0700 Message-ID: <44BB7A92.9080008@cisco.com> Date: Mon, 17 Jul 2006 07:54:58 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2006 11:54:53.0065 (UTC) FILETIME=[D08C4F90:01C6A997] DKIM-Signature: a=rsa-sha1; q=dns; l=243; t=1153137293; x=1154001293; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:SCTP; X=v=3Dcisco.com=3B=20h=3D0Jl4XtltVIX4NVQMAcVRN0XNvT4=3D; b=OFBuuy3Ekk6gNkzKQOTa2zS++IJ3WsstnqAbMj8yTVZKIlapQHSyg8hW+Q+gzsrlb8pz0wx9 +yr9hjawtC1hNc4Xm9I/kXtb69JEPPlC1hs1A6hyaWvfkRzOhQLgsaFJ; Authentication-Results: sj-dkim-2.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Subject: SCTP 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, 17 Jul 2006 11:54:54 -0000 All: Just a friendly reminder/prod... if you have started testing SCTP.. thats great (any feedback?).. and if you have not .. please do so :-D R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Mon Jul 17 17:06:16 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F40C16A4E5; Mon, 17 Jul 2006 17:06:16 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EC3843D67; Mon, 17 Jul 2006 17:06:15 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k6HH6DUj041286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jul 2006 13:06:14 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k6HH67Dv019025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2006 13:06:08 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: net@freebsd.org, isp@freebsd.org Date: Mon, 17 Jul 2006 13:06:01 -0400 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607171306.01882.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1600/Sat Jul 15 11:03:46 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: Subject: forcing FTP-uploaded files to be of certain types only 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, 17 Jul 2006 17:06:16 -0000 Hello! We run an FTP server for the customers to upload their data (usually -- giant core-files and database-dumps). Sometimes they forget compress them, however, wasting many gigabytes of our server's space... How hard would it be to make the stock FreeBSD FTP-server to examine the first, say, 100Kb of the uploaded file and interrupt transfer if the file is of a prohibited or is not of an allowed type? Anything under 100Kb is fine, I guess, and 100Kb is more than enough to detect compression or lack thereof... Thanks for ideas! -mi From owner-freebsd-net@FreeBSD.ORG Mon Jul 17 17:49:49 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C088516A4DE; Mon, 17 Jul 2006 17:49:49 +0000 (UTC) (envelope-from ormandj@corenode.com) Received: from zone2.corenode.com (zone2.corenode.com [66.91.129.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 672F743D70; Mon, 17 Jul 2006 17:49:45 +0000 (GMT) (envelope-from ormandj@corenode.com) Received: from corenode.com ([127.0.0.1]) by zone2.corenode.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J2K00F356XXAL10@zone2.corenode.com>; Mon, 17 Jul 2006 07:51:33 -1000 (HST) Received: from [132.160.192.10] by zone2.corenode.com (mshttpd); Mon, 17 Jul 2006 07:51:33 -1000 Date: Mon, 17 Jul 2006 07:51:33 -1000 From: "David J. Orman" In-reply-to: <200607171306.01882.mi+mx@aldan.algebra.com> To: Mikhail Teterin Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-3.04 (built Jul 15 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <200607171306.01882.mi+mx@aldan.algebra.com> Cc: isp@freebsd.org, net@freebsd.org Subject: Re: forcing FTP-uploaded files to be of certain types only 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, 17 Jul 2006 17:49:49 -0000 The stock ftp server? If you can't base the prohibitions on file extension alone (such as the 100kb example you made) then you're going to have to modify the source of the ftp daemon yourself. Size, extension, etc - those are relatively easy limits to impliment. Actual file typing by examination of the first 100kb isn't easy, and it isn't part of the core functionality AFAIK. You'll have to write that. In fact, I'm not aware of any ftp server that does what you're asking. Maybe it would be better to examine files periodically that were uploaded via a simple program, and anything that isn't allowed, destroy. You could also make it compress things that weren't compressed to begin with, etc etc etc. Good luck, David ----- Original Message ----- From: Mikhail Teterin Date: Monday, July 17, 2006 7:06 am Subject: forcing FTP-uploaded files to be of certain types only > Hello! > > We run an FTP server for the customers to upload their data > (usually -- giant > core-files and database-dumps). > > Sometimes they forget compress them, however, wasting many > gigabytes of our > server's space... > > How hard would it be to make the stock FreeBSD FTP-server to > examine the > first, say, 100Kb of the uploaded file and interrupt transfer if > the file is > of a prohibited or is not of an allowed type? > > Anything under 100Kb is fine, I guess, and 100Kb is more than > enough to detect > compression or lack thereof... > > Thanks for ideas! > > -mi > _______________________________________________ > freebsd-isp@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-isp > To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Jul 17 17:58:34 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AFD116A4DF; Mon, 17 Jul 2006 17:58:34 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id A91B943D46; Mon, 17 Jul 2006 17:58:33 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k6HHwLck041417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jul 2006 13:58:31 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k6HHwFaU019730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2006 13:58:16 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: "David J. Orman" Date: Mon, 17 Jul 2006 13:58:09 -0400 User-Agent: KMail/1.9.1 References: <200607171306.01882.mi+mx@aldan.algebra.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200607171358.09943.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1600/Sat Jul 15 11:03:46 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: isp@freebsd.org, net@freebsd.org Subject: Re: forcing FTP-uploaded files to be of certain types only 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, 17 Jul 2006 17:58:34 -0000 понед╕лок 17 липень 2006 13:51, David J. Orman написав: > The stock ftp server? If you can't base the prohibitions on file extension > alone (such as the 100kb example you made) then you're going to have to > modify the source of the ftp daemon yourself. Size, extension, etc - those > are relatively easy limits to impliment. Actual file typing by examination > of the first 100kb isn't easy, and it isn't part of the core functionality > AFAIK. You'll have to write that. In fact, I'm not aware of any ftp server > that does what you're asking. I was hoping for some sort of plugin-API for the server... Determining the file's type is not really hard -- file(1) does just that. I'm not looking to prevent _malicious_ users -- just the ignorant ones. We don't mind LARGE files -- some of those are legitimate. We just want them to be compressed before being uploaded. In fact, checking for this is even easier, than the usual byte-sniffing done by file(1) -- just try to compress those first 100K. If the result is smaller than 50K, the whole gets rejected :-) > Maybe it would be better to examine files periodically that were uploaded > via a simple program, and anything that isn't allowed, destroy. No, destruction is not an option :-) > You could also make it compress things that weren't compressed to begin > with, etc etc etc. Yeah, and we are doing that now -- kind of. But I would like an educational message sent to the uploader instead: "Transfer aborted: please compress large files before uploading"... -mi From owner-freebsd-net@FreeBSD.ORG Mon Jul 17 18:07:19 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EED016A4DA; Mon, 17 Jul 2006 18:07:19 +0000 (UTC) (envelope-from ormandj@corenode.com) Received: from zone2.corenode.com (zone2.corenode.com [66.91.129.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6B9443D46; Mon, 17 Jul 2006 18:07:18 +0000 (GMT) (envelope-from ormandj@corenode.com) Received: from corenode.com ([127.0.0.1]) by zone2.corenode.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J2K00F3Z7RDAL10@zone2.corenode.com>; Mon, 17 Jul 2006 08:09:13 -1000 (HST) Received: from [132.160.192.10] by zone2.corenode.com (mshttpd); Mon, 17 Jul 2006 08:09:13 -1000 Date: Mon, 17 Jul 2006 08:09:13 -1000 From: "David J. Orman" In-reply-to: <200607171358.09943.mi+mx@aldan.algebra.com> To: Mikhail Teterin Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-3.04 (built Jul 15 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <200607171306.01882.mi+mx@aldan.algebra.com> <200607171358.09943.mi+mx@aldan.algebra.com> Cc: isp@freebsd.org, net@freebsd.org Subject: Re: forcing FTP-uploaded files to be of certain types only 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, 17 Jul 2006 18:07:19 -0000 ----- Original Message ----- From: Mikhail Teterin Date: Monday, July 17, 2006 7:58 am Subject: Re: forcing FTP-uploaded files to be of certain types only > I was hoping for some sort of plugin-API for the server... > Determining the > file's type is not really hard -- file(1) does just that. I'm not > looking to > prevent _malicious_ users -- just the ignorant ones. Ok, I see what you're interested in. I don't believe the stock FBSD server has a plugin API. Try something like ProFTPD, if you are comfortable writing a module that accesses external programs. I wouldn't do that myself, too much room for exploits, but you could always use the algorithm from file(1) in your module, as it is BSD licensed. > We don't mind LARGE files -- some of those are legitimate. We just > want them > to be compressed before being uploaded. In fact, checking for this > is even > easier, than the usual byte-sniffing done by file(1) -- just try to > compress > those first 100K. If the result is smaller than 50K, the whole gets > rejected :-) That could lead to many DoS attacks, high load, etc - but as you said you trust the users, I suspect this is not an issue to you. I personally code with security in mind no matter the situation, but you decide what is best for you. :) > No, destruction is not an option :-) Awww, that's my favorite part! ;) > Yeah, and we are doing that now -- kind of. But I would like an > educational > message sent to the uploader instead: "Transfer aborted: please > compress > large files before uploading"... Now that I understand your situation better, I see what you are attempting to do. You'll likely need something like ProFTPD to accomplish what you're asking, I don't believe the stock FTP server has the functionality/modular design necessary. Something you might want to consider - simply compressing all files recieved on the ftp server, regardless of type/previous compression. Since it sounds like you wan't worry about DoSing, malicious users, etc - and I am assuming this is on the internal network only - and also security is not your concern - simply compressing all files wouldn't hurt anything. It'll only gain you a few % on the previously compressed files, but it will take care of the uncompressed files in the process. Re-training users can be quite dificult, CPU hours costs much less than human hours. :) Either way, it sounds like you can accomplish your task. I'd personally write a module with built in file(1) type functionality myself, and not access file(1) as an external program. All of the options above, should work - however. You'll need a different FTP daemon though if you want to write a module. :) Best wishes, David From owner-freebsd-net@FreeBSD.ORG Mon Jul 17 18:24:31 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EF7616A4EB; Mon, 17 Jul 2006 18:24:31 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7598043D46; Mon, 17 Jul 2006 18:24:30 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k6HIONe9041492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jul 2006 14:24:25 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k6HIOHI6020041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2006 14:24:17 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: "David J. Orman" Date: Mon, 17 Jul 2006 14:24:11 -0400 User-Agent: KMail/1.9.1 References: <200607171306.01882.mi+mx@aldan.algebra.com> <200607171358.09943.mi+mx@aldan.algebra.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200607171424.11726.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1600/Sat Jul 15 11:03:46 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: isp@freebsd.org, net@freebsd.org Subject: Re: forcing FTP-uploaded files to be of certain types only 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, 17 Jul 2006 18:24:31 -0000 понед╕лок 17 липень 2006 14:09, David J. Orman написав: > That could lead to many DoS attacks, high load, etc - but as you said you > trust the users, I suspect this is not an issue to you. I personally code > with security in mind no matter the situation, but you decide what is best > for you. :) Well, it is not hard to compress 100K (that are still in RAM) on a modern CPU. And we can just as well try 8K. It is, probably, easier, than to, say, look up an article in a database -- something web-servers do many times per second :-) Our FTP uploads happen far less often -- only 10-20 times per day... The probability of a DoS of the full filesystem is far more likely (actually happened a few times), than the DoS of overloading the CPU (and inetd takes care of not starting too many too often). Thanks a lot for your recommendations! -mi From owner-freebsd-net@FreeBSD.ORG Mon Jul 17 18:27:41 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 388AB16A4E0; Mon, 17 Jul 2006 18:27:41 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 922C643D45; Mon, 17 Jul 2006 18:27:40 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k6HIRbdU041498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jul 2006 14:27:38 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k6HIRW8s020098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2006 14:27:32 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: "David J. Orman" Date: Mon, 17 Jul 2006 14:27:26 -0400 User-Agent: KMail/1.9.1 References: <200607171306.01882.mi+mx@aldan.algebra.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200607171427.26699.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1600/Sat Jul 15 11:03:46 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: isp@freebsd.org, net@freebsd.org Subject: ftpd vs. lukemftpd (forcing FTP-uploaded ...) 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, 17 Jul 2006 18:27:41 -0000 понед╕лок 17 липень 2006 13:51, David J. Orman написав: > The stock ftp server? BTW, what is the stock ftp server on 6-stable? I see two -- ftpd and lukemftpd and both are installed... Is there a web-page with comparision somewhere, perhaps? Thanks! -mi From owner-freebsd-net@FreeBSD.ORG Mon Jul 17 18:57:06 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6718D16A4E2; Mon, 17 Jul 2006 18:57:06 +0000 (UTC) (envelope-from ormandj@corenode.com) Received: from zone2.corenode.com (zone2.corenode.com [66.91.129.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id D300743D45; Mon, 17 Jul 2006 18:57:01 +0000 (GMT) (envelope-from ormandj@corenode.com) Received: from corenode.com ([127.0.0.1]) by zone2.corenode.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J2K00F6MA26AL10@zone2.corenode.com>; Mon, 17 Jul 2006 08:58:54 -1000 (HST) Received: from [132.160.192.10] by zone2.corenode.com (mshttpd); Mon, 17 Jul 2006 08:58:54 -1000 Date: Mon, 17 Jul 2006 08:58:54 -1000 From: "David J. Orman" In-reply-to: <200607171427.26699.mi+mx@aldan.algebra.com> To: Mikhail Teterin Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-3.04 (built Jul 15 2005) Content-type: text/plain; charset=utf-8 Content-language: en Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: en Priority: normal References: <200607171306.01882.mi+mx@aldan.algebra.com> <200607171427.26699.mi+mx@aldan.algebra.com> Cc: isp@freebsd.org, net@freebsd.org Subject: Re: ftpd vs. lukemftpd (forcing FTP-uploaded ...) 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, 17 Jul 2006 18:57:06 -0000 Whichever version you are calling=2C is the version you are using=2E If = you=27re starting it via inetd=2C it=27s probably using plain =22ftpd=22= - so just figure out which daemon that one is=2E I personally do not kn= ow what actual ftp server =22ftpd=22 is=2C never used it and never check= ed=2C I don=27t allow FTP traffic for security reasons=2E As to a website with comparisons on ftp servers=2C I=27ve looked in the = past=2C and never found anything I liked (and realized what a junk proto= col FTP is to begin with=2E=2E) SFTP or some kind of ssh-based file tran= sfer is more workable=2C I personally use the built-in SSH daemon to han= dle file transfer for users=2E Hopefully somebody else will chime in who knows more about the FTPD inte= rnals of FBSD and also has a nice comparison for you=2E Good luck once a= gain=2E David ----- Original Message ----- From=3A Mikhail Teterin =3Cmi+mx=40aldan=2Ealgebra=2Ecom=3E Date=3A Monday=2C July 17=2C 2006 8=3A27 am Subject=3A ftpd vs=2E lukemftpd (forcing FTP-uploaded =2E=2E=2E) =3E =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=C4=A6=EF=BF=BD=EF=BF=BD=EF=BF=BD= 17 =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD 2006 13=3A51=2C= David J=2E Orman =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD= =EF=BF=BD=3A =3E =3E The stock ftp server=3F =3E = =3E BTW=2C what is the stock ftp server on 6-stable=3F I see two -- ftpd= = =3E and lukemftpd = =3E and both are installed=2E=2E=2E =3E = =3E Is there a web-page with comparision somewhere=2C perhaps=3F Thanks!= =3E = =3E -mi =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E freebsd-isp=40freebsd=2Eorg mailing list =3E http=3A//lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-isp =3E To unsubscribe=2C send any mail to =22freebsd-isp-unsubscribe=40free= bsd=2Eorg=22 =3E From owner-freebsd-net@FreeBSD.ORG Mon Jul 17 19:17:01 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2B5016A5B2 for ; Mon, 17 Jul 2006 19:17:01 +0000 (UTC) (envelope-from james@infinityprosports.com) Received: from mail1.infinityprosports.com (mail1.infinityprosports.com [67.18.186.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 662FD43D5D for ; Mon, 17 Jul 2006 19:16:52 +0000 (GMT) (envelope-from james@infinityprosports.com) Received: (qmail 49298 invoked by uid 89); 17 Jul 2006 19:16:51 -0000 Received: from unknown (HELO ?192.168.0.157?) (james@infinityprosports.com@209.189.249.98) by mail1.infinityprosports.com with ESMTPA; 17 Jul 2006 19:16:51 -0000 Message-ID: <44BBE21B.8070606@infinityprosports.com> Date: Mon, 17 Jul 2006 14:16:43 -0500 From: James Ryan User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: mi+mx@aldan.algebra.com References: <200607171306.01882.mi+mx@aldan.algebra.com> <200607171427.26699.mi+mx@aldan.algebra.com> In-Reply-To: <200607171427.26699.mi+mx@aldan.algebra.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: isp@freebsd.org, net@freebsd.org Subject: Re: ftpd vs. lukemftpd (forcing FTP-uploaded ...) 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, 17 Jul 2006 19:17:02 -0000 Mikhail Teterin wrote: > понед╕лок 17 липень 2006 13:51, David J. Orman написав: >> The stock ftp server? > > BTW, what is the stock ftp server on 6-stable? I see two -- ftpd and lukemftpd > and both are installed... > > Is there a web-page with comparision somewhere, perhaps? Thanks! > > -mi > _______________________________________________ > freebsd-isp@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-isp > To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" I am not aware of a stock FTP server that can accomplish what you are asking for, at least without modifying the source or writing a plug-in of some sort. You may have already thought of this, but my 2-cents is: If you don't mind waiting until the file finishes transferring to examine it, you could 1) turn on verbose logging (ftpd -ll for stock ftpd; other ftp servers have better logging though), 2) log directly to a named pipe, 3) attach a simple script at the other end that determines what the uploaded file is and deletes it accordingly. I would not recommend using ftpd for this; as I recall, and somebody correct me if I am wrong, it does not always log the complete path to an uploaded file. I'd suggest ProFTPd instead; it's CustomLog feature allows you to specify your own log format (like Apache). This means you can make a convenient string to regex, such as "date|user|action|file". Good luck, James -- James Ryan Infinity Pro Sports http://www.infinityprosports.com em: james@infinityprosports.com From owner-freebsd-net@FreeBSD.ORG Mon Jul 17 19:35:48 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C71C16A4DD; Mon, 17 Jul 2006 19:35:48 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DEF143D55; Mon, 17 Jul 2006 19:35:45 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k6HJZXEt041680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jul 2006 15:35:43 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k6HJZRcs020891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2006 15:35:28 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: James Ryan Date: Mon, 17 Jul 2006 15:35:21 -0400 User-Agent: KMail/1.9.1 References: <200607171306.01882.mi+mx@aldan.algebra.com> <200607171427.26699.mi+mx@aldan.algebra.com> <44BBE21B.8070606@infinityprosports.com> In-Reply-To: <44BBE21B.8070606@infinityprosports.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200607171535.21813.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1600/Sat Jul 15 11:03:46 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: isp@freebsd.org, net@freebsd.org Subject: Re: ftpd vs. lukemftpd (forcing FTP-uploaded ...) 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, 17 Jul 2006 19:35:48 -0000 понед╕лок 17 липень 2006 15:16, James Ryan написав: > If you don't mind waiting until the file finishes transferring to > examine it But I do, actually. The files we deal with measure in gigabytes, and take a while to transfer even over fat pipes. Rejecting the uncompressed ones right away is better, than after the initiator has come back from his lunch. > This means you can make a convenient string to regex, such as "date|user| > action|file". With any kind of post-transfer verification, there is no reliable way to notify the user of his/her failure... I think, the quick rejection should delivered via the FTProtocol itself, so the user's FTP-client shows it -- instantly. -mi From owner-freebsd-net@FreeBSD.ORG Tue Jul 18 10:19:01 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E67716A4DE for ; Tue, 18 Jul 2006 10:19:01 +0000 (UTC) (envelope-from nike_d@cytexbg.com) Received: from mail.interbgc.com (mx04.cablebg.net [217.9.224.232]) by mx1.FreeBSD.org (Postfix) with SMTP id D178E43D45 for ; Tue, 18 Jul 2006 10:18:59 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: (qmail 7550 invoked from network); 18 Jul 2006 10:18:57 -0000 Received: from nike_d@cytexbg.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(0.1/8.0):. Processed in 1.294881 secs); 18 Jul 2006 10:18:57 -0000 X-Spam-Status: No, hits=0.1 required=8.0 Received: from niked.ddns.cablebg.net (HELO tormentor.totalterror.net) (85.130.14.211) by mx04.interbgc.com with SMTP; 18 Jul 2006 10:18:56 -0000 Received: (qmail 4215 invoked from network); 18 Jul 2006 10:18:55 -0000 Received: from unknown (HELO ?10.0.0.3?) (10.0.0.3) by tormentor.totalterror.net with SMTP; 18 Jul 2006 10:18:55 -0000 Message-ID: <44BCB58E.8010707@cytexbg.com> Date: Tue, 18 Jul 2006 13:18:54 +0300 From: Niki Denev User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: stable@freebsd.org, net@freebsd.org X-Enigmail-Version: 0.94.0.0 OpenPGP: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: ural(4) deassociates if no activity (possible wpa_supplicant problem) 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, 18 Jul 2006 10:19:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I've noticed something very interesing while using a ural(4) usb wifi device. When i plug the usb device, and there is absolutely no network activity, exactly after five minutes the device deassociates from the access point. I've put some debug printf's in ural_newstate and when i plug the device, i get several IEEE80211_S_SCAN state changes, then i gets from IEEE80211_S_AUTH to ASSOC and then RUN. Nothing wrong here, but exactly after five minutes of no activity (measured with stopwatch) i get a state transition from IEEE80211_S_RUN to IEEE80211_S_AUTH and it stays that way, until i remove/insert the device again or send HUP to wpa_supplicant and restart dhclient. This looks maybe like wpa_supplicant problem, and i think i've had similar problems with ath(4) mini-pci card and card bus ral(3), but as far as i remember the period of inactivity was much greater with them (i'll try to test this on these cards too when i have access to them again) Regards, - --niki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvLWOHNAJ/fLbfrkRAkSbAJ90SYFCkdtjEw3hckrQ/B2O0geWHgCgoj5j gF7/O+dMKdNUrvFydNODQrE= =piip -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Jul 18 10:26:36 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D26916A4DD for ; Tue, 18 Jul 2006 10:26:36 +0000 (UTC) (envelope-from nike_d@cytexbg.com) Received: from mail.interbgc.com (mx02.interbgc.com [217.9.224.227]) by mx1.FreeBSD.org (Postfix) with SMTP id BAFEC43D7B for ; Tue, 18 Jul 2006 10:26:27 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: (qmail 12928 invoked from network); 18 Jul 2006 10:26:25 -0000 Received: from nike_d@cytexbg.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(0.1/8.0):. Processed in 1.478931 secs); 18 Jul 2006 10:26:25 -0000 X-Spam-Status: No, hits=0.1 required=8.0 Received: from niked.ddns.cablebg.net (HELO tormentor.totalterror.net) (85.130.14.211) by mx02.interbgc.com with SMTP; 18 Jul 2006 10:26:23 -0000 Received: (qmail 5136 invoked from network); 18 Jul 2006 10:26:23 -0000 Received: from unknown (HELO ?10.0.0.3?) (10.0.0.3) by tormentor.totalterror.net with SMTP; 18 Jul 2006 10:26:23 -0000 Message-ID: <44BCB74E.5020307@cytexbg.com> Date: Tue, 18 Jul 2006 13:26:22 +0300 From: Niki Denev User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: stable@freebsd.org References: <44BCB58E.8010707@cytexbg.com> In-Reply-To: <44BCB58E.8010707@cytexbg.com> X-Enigmail-Version: 0.94.0.0 OpenPGP: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: ural(4) deassociates if no activity (possible wpa_supplicant problem) 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, 18 Jul 2006 10:26:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Niki Denev wrote: > Hello, > > I've noticed something very interesing while using a ural(4) usb wifi device. > > When i plug the usb device, and there is absolutely no network activity, exactly > after five minutes the device deassociates from the access point. > > I've put some debug printf's in ural_newstate and when i plug the device, > i get several IEEE80211_S_SCAN state changes, > then i gets from IEEE80211_S_AUTH to ASSOC and then RUN. > Nothing wrong here, but exactly after five minutes of no activity (measured > with stopwatch) i get a state transition from IEEE80211_S_RUN to IEEE80211_S_AUTH > and it stays that way, until i remove/insert the device again or send HUP to > wpa_supplicant and restart dhclient. > > This looks maybe like wpa_supplicant problem, and i think i've had similar problems with > ath(4) mini-pci card and card bus ral(3), but as far as i remember the period of > inactivity was much greater with them (i'll try to test this on these cards too when > i have access to them again) > > > Regards, > --niki Well, after a few more moments investigating the problem it seems that dhclient is to blame. If i don't start it i don't get disconnected, and also i noticed that the five minute interval matches the dhclient renewal period of 300 seconds. So the logical question is, why dhclient makes my ural(4) adapter deassociate, and what i can do to prevent this :) Thanks! - --niki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvLdOHNAJ/fLbfrkRAnt+AKCnpfDdSucSccRTm4Qmg4ONVWQqzwCgygJp EE+HPPMAbzIhMOsHO6Q+f6o= =NXMO -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Jul 18 12:55:53 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 803D716A4DA; Tue, 18 Jul 2006 12:55:53 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from rune.pobox.com (rune.pobox.com [208.210.124.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB99843D53; Tue, 18 Jul 2006 12:55:52 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id D05B17A3E9; Tue, 18 Jul 2006 08:56:13 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 4644C1EB68; Tue, 18 Jul 2006 08:56:11 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1G2p75-0006xS-NP; Tue, 18 Jul 2006 13:55:47 +0100 Date: Tue, 18 Jul 2006 13:55:47 +0100 From: Brian Candler To: Mikhail Teterin Message-ID: <20060718125547.GB26642@uk.tiscali.com> References: <200607171306.01882.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607171306.01882.mi+mx@aldan.algebra.com> User-Agent: Mutt/1.4.2.1i Cc: isp@freebsd.org, net@freebsd.org Subject: Re: forcing FTP-uploaded files to be of certain types only 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, 18 Jul 2006 12:55:53 -0000 On Mon, Jul 17, 2006 at 01:06:01PM -0400, Mikhail Teterin wrote: > How hard would it be to make the stock FreeBSD FTP-server to examine the > first, say, 100Kb of the uploaded file and interrupt transfer if the file is > of a prohibited or is not of an allowed type? > > Anything under 100Kb is fine, I guess, and 100Kb is more than enough to detect > compression or lack thereof... I think the first few bytes should be enough to tell you if it's a gzip, pkzip or compress archive: $ gzip -c -9 /etc/services | head -c64 | file - /dev/stdin: gzip compressed data, was "services", from Unix, max compression $ compress -c /etc/services | head -c64 | file - /dev/stdin: compress'd data 16 bits $ zip - /etc/services | head -c64 | file - adding: etc/services /dev/stdin: Zip archive data, at least v2.0 to extract How wedded are you to FTP? If this was a HTTP 'PUT' then a simple CGI could read in 100 bytes, check it is compressed (e.g. with libmagic), then copy through the rest of the file. The result from the PUT can be a HTML page saying "all OK" or "please compress your data first" Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Tue Jul 18 13:15:19 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC4FB16A4E8; Tue, 18 Jul 2006 13:15:19 +0000 (UTC) (envelope-from regnauld@catpipe.net) Received: from moof.catpipe.net (moof.catpipe.net [195.249.214.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A0E843D66; Tue, 18 Jul 2006 13:15:16 +0000 (GMT) (envelope-from regnauld@catpipe.net) Received: from localhost (moof.catpipe.net [195.249.214.130]) by localhost.catpipe.net (Postfix) with ESMTP id 4115463464C; Tue, 18 Jul 2006 15:15:15 +0200 (CEST) Received: from moof.catpipe.net ([195.249.214.130]) by localhost (moof.catpipe.net [195.249.214.130]) (amavisd-new, port 10024) with ESMTP id 68061-09; Tue, 18 Jul 2006 15:15:14 +0200 (CEST) Received: from vinyl.catpipe.net (vinyl.catpipe.net [195.249.214.189]) by moof.catpipe.net (Postfix) with ESMTP id 70F89634641; Tue, 18 Jul 2006 15:15:13 +0200 (CEST) Received: by vinyl.catpipe.net (Postfix, from userid 1006) id 375CA78C31; Tue, 18 Jul 2006 15:11:25 +0200 (CEST) Date: Tue, 18 Jul 2006 15:11:25 +0200 From: Phil Regnauld To: Brian Candler Message-ID: <20060718131124.GB75090@catpipe.net> References: <200607171306.01882.mi+mx@aldan.algebra.com> <20060718125547.GB26642@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060718125547.GB26642@uk.tiscali.com> X-Operating-System: FreeBSD 6.1-PRERELEASE i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at catpipe.net Cc: Mikhail Teterin , isp@freebsd.org, net@freebsd.org Subject: Re: forcing FTP-uploaded files to be of certain types only 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, 18 Jul 2006 13:15:19 -0000 Brian Candler (B.Candler) writes: > How wedded are you to FTP? If this was a HTTP 'PUT' then a simple CGI could > read in 100 bytes, check it is compressed (e.g. with libmagic), then copy > through the rest of the file. The result from the PUT can be a HTML page > saying "all OK" or "please compress your data first" A reverse FTP proxy (squid might or might not support FTP proxying on "PUT", to be checked) with an external handler. Around 50 lines of Perl ought to do the trick. From owner-freebsd-net@FreeBSD.ORG Tue Jul 18 19:03:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5424316A4DE for ; Tue, 18 Jul 2006 19:03:23 +0000 (UTC) (envelope-from wiresncode@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA21143D6B for ; Tue, 18 Jul 2006 19:03:21 +0000 (GMT) (envelope-from wiresncode@gmail.com) Received: by wr-out-0506.google.com with SMTP id 67so110545wri for ; Tue, 18 Jul 2006 12:03:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Svry7NnAjfmq9JdEQdaB9iGvdtSr3UN/9LAg3yPmKIb02zxdAe/aYhgcQimS51Sc1/fKjlehzbNOk+RskJrm7g7/BVsw95NGbOrGnttfejgWn6je9YfLa+UU8S/7S/nuhS+O/HsUnLQo6mWpeQe+b11PEBQM3/n46FnBK6yz+dM= Received: by 10.65.219.3 with SMTP id w3mr1156800qbq; Tue, 18 Jul 2006 12:03:20 -0700 (PDT) Received: by 10.64.21.10 with HTTP; Tue, 18 Jul 2006 12:03:20 -0700 (PDT) Message-ID: <9050f13e0607181203r610da712kc506507b4f90b77c@mail.gmail.com> Date: Tue, 18 Jul 2006 12:03:20 -0700 From: "Tom Parker" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Possible inconsistency in the use of in6_delmulti() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tom@wiresncode.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 19:03:23 -0000 Hi, New to the list here, but fairly familiar with the innards of (at least an older) version of the fbsd networking code. I'm fortunate in my ability to run purify on a simulated instance of our ported version of the networking code. Purify has picked up a problem that I'm a bit mystified as how it can be fixed. It is present in current versions also, I'm interested in any comments people have (I think ours is 4.4 vintage, but it is hard to tell). As far as I can tell, in most calling paths when in6_delmulti() is called, it is done after the in6_multi_mship structure has been removed from the im6o_memberships list in the relevant PCB. This applies to in6_ifdetach(), in6_pcbpurgeif0, ip6_setmoptions() etc. However in in6_purgeaddr() in6_delmulti is called straight off. I'm not sure if we've violated some usage convention, but purify is telling me this causes access violations when we then leave the same group using setsockopt(). in6_purgeaddr is called when we remove the address from the interface. This should be possible in a real kernel. Add a multicast address to an interface, open a socket and listen to the address, then remove the address from the interface. Am I missing something here or is this a nasty problem in both the kernel and our stack port? Thanks, Tom ================= Tom Parker tom@wiresncode.com From owner-freebsd-net@FreeBSD.ORG Tue Jul 18 19:08:15 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42DFB16A4DA for ; Tue, 18 Jul 2006 19:08:15 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E04943D5C for ; Tue, 18 Jul 2006 19:07:53 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so1377nfc for ; Tue, 18 Jul 2006 12:07:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=rjiNdBji+fnmIJ28MD8uvctiiHZr3jfVg5yVIJYaDP/nnB56gKFk63Y0PrwNImTQxMm+Xax1KdSJ0+K2mjONh51WID744g/0hDtwq1ZpWQ8NEO8A5cdSAo8Mrhq+w7To4YgoepWMHtvkg3zl/yyAkRwlznI266Pu79ZhrrLrmSo= Received: by 10.49.55.13 with SMTP id h13mr985993nfk; Tue, 18 Jul 2006 12:07:52 -0700 (PDT) Received: from roadrunner.q.local ( [217.185.119.201]) by mx.gmail.com with ESMTP id a23sm1137331nfc.2006.07.18.12.07.46; Tue, 18 Jul 2006 12:07:52 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.6/8.13.6) with ESMTP id k6IJ80sg003570; Tue, 18 Jul 2006 21:08:01 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.6/8.13.6/Submit) id k6IItErc003195; Tue, 18 Jul 2006 20:55:14 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Tue, 18 Jul 2006 20:55:14 +0200 From: Ulrich Spoerlein To: Niki Denev Message-ID: <20060718185514.GA998@roadrunner.buck.local> Mail-Followup-To: Niki Denev , stable@freebsd.org, net@freebsd.org References: <44BCB58E.8010707@cytexbg.com> <44BCB74E.5020307@cytexbg.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <44BCB74E.5020307@cytexbg.com> Cc: stable@freebsd.org, net@freebsd.org Subject: Re: ural(4) deassociates if no activity (possible wpa_supplicant problem) 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, 18 Jul 2006 19:08:15 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Niki Denev wrote: > Well, after a few more moments investigating the problem it seems that dh= client is to blame. > If i don't start it i don't get disconnected, and also i noticed that the= five minute interval > matches the dhclient renewal period of 300 seconds. >=20 > So the logical question is, why dhclient makes my ural(4) adapter deassoc= iate, and what i can > do to prevent this :) Hmm, interesting. I'm using ural(4) as an AP and connect to it via ipw(4) and simple WEP. It is very unstable and will wedge the AP (running 6.1) after several minutes. I can't give you more details, as it is a rather complex setup and I would have to isolate the problem first (is it WEP, is it bridge(4), etc.) Ulrich Spoerlein --=20 PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEvS6S524iJyD+6d0RAlFdAJ9dGGQR0jUlqTdwLf7XVTIUSoF8cQCfXTFA sJM6X8DRuYqe1L377z+7Z/A= =aKQn -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 18 19:29:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ABA716A4DE for ; Tue, 18 Jul 2006 19:29:58 +0000 (UTC) (envelope-from yb@bashibuzuk.net) Received: from a.6f2.net (a.6f2.net [213.189.5.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7EBC43D46 for ; Tue, 18 Jul 2006 19:29:57 +0000 (GMT) (envelope-from yb@bashibuzuk.net) Received: by a.6f2.net (Postfix, from userid 66) id 374E1BF906D; Tue, 18 Jul 2006 21:29:56 +0200 (CEST) Received: by cc.bashibuzuk.net (Postfix, from userid 1001) id 343D6C05B; Tue, 18 Jul 2006 21:30:26 +0200 (CEST) Date: Tue, 18 Jul 2006 21:30:26 +0200 From: Yann Berthier To: Randall Stewart Message-ID: <20060718193026.GA1687@bashibuzuk.net> References: <44BB7A92.9080008@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44BB7A92.9080008@cisco.com> X-Operating-System: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: SCTP 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, 18 Jul 2006 19:29:58 -0000 Hello, On Mon, 17 Jul 2006, at 07:54, Randall Stewart wrote: > All: > > Just a friendly reminder/prod... if you have started > testing SCTP.. thats great (any feedback?).. As said last time, i've been using sctp with netflow records between a router and a freebsd box - perhaps not the most useful test, but it's the only 'real life' test i found. if you have other ideas ... anyway, the only way to have more exposure is to have more sctp ready applications, and a good way to have it happen is to commit your patch, right :) -- http://flowog.6f2.net/ - A NetFlow collecting house From owner-freebsd-net@FreeBSD.ORG Tue Jul 18 20:23:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD37A16A6AA for ; Tue, 18 Jul 2006 20:23:36 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2C7B43D70 for ; Tue, 18 Jul 2006 20:23:27 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so106621uge for ; Tue, 18 Jul 2006 13:23:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uOzH6H0y/uLpIH8c4W7XV0U1WasI7Tn0oN2YbN1WG4wysu0kj4f7XnRmoa1ehDWkK3L11s6BrTiuSTMsPR+TvzM90ROK40ifAmt1U64qK9szxZ0MzL93PJbf7M3Q3S+Snm5PSon3J/gyiIf3qqMmPlUMxPO21ziwmv8cRIZpy50= Received: by 10.78.156.6 with SMTP id d6mr1742287hue; Tue, 18 Jul 2006 13:23:26 -0700 (PDT) Received: by 10.78.70.15 with HTTP; Tue, 18 Jul 2006 13:23:26 -0700 (PDT) Message-ID: Date: Tue, 18 Jul 2006 22:23:26 +0200 From: "Pawel Worach" To: "Randall Stewart" In-Reply-To: <44BB7A92.9080008@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44BB7A92.9080008@cisco.com> Cc: freebsd-net@freebsd.org Subject: Re: SCTP 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, 18 Jul 2006 20:23:37 -0000 On 7/17/06, Randall Stewart wrote: > All: > > Just a friendly reminder/prod... if you have started > testing SCTP.. thats great (any feedback?).. > and if you have not .. please do so :-D Hi, I played around a bit with NetPIPE, FreeBSD-CURRENT in one end and Linux 2.6.17 in the other over a gigabit crossover cable network, 1500 MTU. FreeBSD crashes after a while. I do have MAC enabled (no policy modules loaded at the time), it looks like it is involved. I think I can reproduce this, made it happen on both attempts. For the record, I modified the patch a bit to make it compile, the syscalls numbers collide with new threading syscalls added recently, so I moved the thr syscalls up a notch. And I removed this #ifdef MAC part of the patch due to duplicate sctp_bad labels. +#ifdef MAC +sctp_bad: +#endif + sctp_bad: + free(iov, M_IOV); Any more info I can provide ? ~/sctp/np> ./NPsctp -h 192.168.10.1 ... 68: 16384 bytes 71 times --> 179.87 Mbps in 694.94 usec 69: 16387 bytes 71 times --> 178.78 Mbps in 699.33 usec 70: 24573 bytes 71 times --> 198.43 Mbps in 944.80 usec 71: 24576 bytes 70 times --> 199.18 Mbps in 941.35 usec 72: 24579 bytes 70 times --> 198.82 Mbps in 943.19 usec 73: 32765 bytes 35 times --> 210.05 Mbps in 1190.07 usec 74: 32768 bytes 42 times --> 208.48 Mbps in 1199.15 usec 75: 32771 bytes 41 times --> 208.00 Mbps in 1202.03 usec 76: 49149 bytes 41 times --> 234.43 Mbps in 1599.55 usec 77: 49152 bytes 41 times --> 300.20 Mbps in 1249.17 usec 78: 49155 bytes 53 times --> 299.66 Mbps in 1251.51 usec 79: 65533 bytes 26 times --> 4.77 Mbps in 104844.52 usec 80: 65536 bytes 3 times --> 3.70 Mbps in 135258.48 usec 81: 65539 bytes 3 times --> 3.70 Mbps in 135257.16 usec 82: 98301 bytes 3 times --> 7.36 Mbps in 101946.00 usec 83: 98304 bytes 3 times --> 7.36 Mbps in 101923.51 usec 84: 98307 bytes 3 times --> 7.36 Mbps in 101945.48 usec 85: 131069 bytes 3 times --> [stalls here] then a couple of seconds later... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc06a7e16 stack pointer = 0x28:0xd35e5174 frame pointer = 0x28:0xd35e5174 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi1: net) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(c078488a,c07e2500,c07790c0,d35e5028,100,...) at kdb_backtrace+0x2e panic(c07790c0,c079de93,c2466a70,1,1,...) at panic+0xb7 trap_fatal(d35e5134,0,2,8,e5df6f6e,...) at trap_fatal+0x342 trap_pfault(d35e5134,0,0,0,0,...) at trap_pfault+0x245 trap(8,ffff0028,7fff0028,c104db80,0,...) at trap+0x3e3 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc06a7e16, esp = 0xd35e5174, ebp = 0xd35e5174 --- mac_labelzone_dtor(0,14,0,0,0,...) at mac_labelzone_dtor+0x6 uma_zfree_arg(c104db80,0,0,d35e51d0,c06acfc4,...) at uma_zfree_arg+0x2f mac_labelzone_free(0) at mac_labelzone_free+0x22 mac_socket_label_free(0,c2ad4000,d35e5200,c0587da8,c2ad4000,...) at mac_socket_label_free+0x94 mac_destroy_socket(c2ad4000,40,0,c2ad4000,4,...) at mac_destroy_socket+0x18 sodealloc(c2ad4000,c2ad4000,0,0,4,...) at sodealloc+0x168 sofree(c2ad4000,0,0,0,c10372c8,...) at sofree+0x311 sctp_inpcb_free(c2c98000,0,0,d35e52b4,c060c90d,...) at sctp_inpcb_free+0x10d6 sctp_free_assoc(c2c98000,c2cad958,0,c2cafcd0,d35e534c,...) at sctp_free_assoc+0x1a5b sctp_handle_shutdown_complete(c2cf3830,c2cad958,c2cafcd0,d35e534c,c0754bbe,...) at sctp_handle_shutdown_complete+0x228 sctp_process_control(c2cea500,14,d35e5bb8,24,c2cf3824,...) at sctp_process_control+0x1388 sctp_common_input_processing(d35e5c30,14,20,24,c2cf3824,...) at sctp_common_input_processing+0x87 sctp_input(c2cea500,14,c255c800,1,0,...) at sctp_input+0x383 ip_input(c2cea500,d35e5c88,c0553c65,8,0,...) at ip_input+0x70c netisr_processqueue(c07e75b8,c2467870,c2467870,c24668d0,d35e5ce4,...) at netisr_processqueue+0xe9 swi_net(0,c2467870,80246,b9669622,c2467870,...) at swi_net+0x12f ithread_execute_handlers(c24668d0,c2463500,c24668d0,c2467870,c24668d0,...) at ithread_execute_handlers+0x188 ithread_loop(c2433ad0,d35e5d38,0,0,c2433ad0,...) at ithread_loop+0x76 fork_exit(c051d900,c2433ad0,d35e5d38) at fork_exit+0x7f fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd35e5d6c, ebp = 0 --- Uptime: 27m28s Physical memory: 502 MB Dumping 68 MB: 53 37 21 5 #0 doadump () at pcpu.h:166 166 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:166 #1 0xc053c0b4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc053c42d in panic (fmt=0xc07790c0 "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc074a2d2 in trap_fatal (frame=0xd35e5134, eva=0) at /usr/src/sys/i386/i386/trap.c:869 #4 0xc0749f65 in trap_pfault (frame=0xd35e5134, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:778 #5 0xc0749ab3 in trap (frame= {tf_fs = 8, tf_es = -65496, tf_ds = 2147418152, tf_edi = -1056646272, tf_esi = 0, tf_ebp = -748793484, tf_isp = -748793504, tf_ebx = 0, tf_edx = 0, tf_ecx = 4, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1066762730, tf_cs = 32, tf_eflags = 66178, tf_esp = -748793432, tf_ss = -1066463889}) at /usr/src/sys/i386/i386/trap.c:463 #6 0xc0738cfa in calltrap () at /usr/src/sys/i386/i386/exception.s:138 #7 0xc06a7e16 in mac_labelzone_dtor (mem=0x0, size=20, arg=0x0) at /usr/src/sys/security/mac/mac_label.c:74 #8 0xc06f0d6f in uma_zfree_arg (zone=0xc104db80, item=0x0, udata=0x0) at /usr/src/sys/vm/uma_core.c:2263 #9 0xc06a7e72 in mac_labelzone_free (label=0x0) at uma.h:303 #10 0xc06acfc4 in mac_socket_label_free (label=0x0) at /usr/src/sys/security/mac/mac_socket.c:151 #11 0xc06ad088 in mac_destroy_socket (socket=0xc2ad4000) ---Type to continue, or q to quit--- at /usr/src/sys/security/mac/mac_socket.c:168 #12 0xc0587da8 in sodealloc (so=0xc2ad4000) at /usr/src/sys/kern/uipc_socket.c:291 #13 0xc0588971 in sofree (so=0xc2ad4000) at /usr/src/sys/kern/uipc_socket.c:592 #14 0xc0604986 in sctp_inpcb_free (inp=0xc2c98000, immediate=0) at /usr/src/sys/netinet/sctp_pcb.c:2582 #15 0xc060817b in sctp_free_assoc (inp=0xc2c98000, stcb=0xc2cad958, from_inpcbfree=0) at /usr/src/sys/netinet/sctp_pcb.c:3896 #16 0xc0617b58 in sctp_handle_shutdown_complete (cp=0xc2cf3830, stcb=0xc2cad958, net=0x0) at /usr/src/sys/netinet/sctp_input.c:2500 #17 0xc061a7d8 in sctp_process_control (m=0xc2cea500, iphlen=20, offset=0xd35e5bb8, length=36, sh=0xc2cf3824, ch=0xc2cf3830, inp=0xc2c98000, stcb=0xc2cad958, netp=0xd35e5bd0, fwd_tsn_seen=0xd35e5b98) at /usr/src/sys/netinet/sctp_input.c:4267 #18 0xc061ad87 in sctp_common_input_processing (mm=0xd35e5c30, iphlen=20, offset=32, length=36, sh=0xc2cf3824, ch=0xc2cf3830, inp=0xc2c98000, stcb=0xc2cad958, net=0xc2cafcd0, ecn_bits=2 '\002') at /usr/src/sys/netinet/sctp_input.c:4583 #19 0xc061b5e3 in sctp_input (m=0xc2cea500, off=20) at /usr/src/sys/netinet/sctp_input.c:4994 #20 0xc05ec1ec in ip_input (m=0xc2cea500) at /usr/src/sys/netinet/ip_input.c:658 #21 0xc05d2de9 in netisr_processqueue (ni=0xc07e75b8) ---Type to continue, or q to quit--- at /usr/src/sys/net/netisr.c:236 #22 0xc05d305f in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 #23 0xc051d808 in ithread_execute_handlers (p=0xc24668d0, ie=0xc2463500) at /usr/src/sys/kern/kern_intr.c:662 #24 0xc051d976 in ithread_loop (arg=0xc2433ad0) at /usr/src/sys/kern/kern_intr.c:745 #25 0xc051c38f in fork_exit (callout=0xc051d900 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:822 #26 0xc0738d5c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:199 -- Pawel From owner-freebsd-net@FreeBSD.ORG Tue Jul 18 21:57:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A56AF16A4DA for ; Tue, 18 Jul 2006 21:57:45 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id C659B43D4C for ; Tue, 18 Jul 2006 21:57:44 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so24032uge for ; Tue, 18 Jul 2006 14:57:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NqhkPPU+o3jAYNNloP7nm+9Ke/9+nEVjo91xD3/usoT/4RwLuppnxfvBfzqZt8qR9FKHF3yOTwreSGnPA+1ELsSa9YMr0sWHuPzZ0zBMzuUuMGRLuErAqX0wfmZsjBycbqfsD6Tal6cnsGIrXglX9BnbpPXaZ1uLOHIaTC2dIOo= Received: by 10.78.167.12 with SMTP id p12mr20814hue; Tue, 18 Jul 2006 14:57:43 -0700 (PDT) Received: by 10.78.70.15 with HTTP; Tue, 18 Jul 2006 14:57:42 -0700 (PDT) Message-ID: Date: Tue, 18 Jul 2006 23:57:42 +0200 From: "Pawel Worach" To: "Randall Stewart" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44BB7A92.9080008@cisco.com> Cc: freebsd-net@freebsd.org Subject: Re: SCTP 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, 18 Jul 2006 21:57:45 -0000 On 7/18/06, Pawel Worach wrote: > On 7/17/06, Randall Stewart wrote: > > All: > > > > Just a friendly reminder/prod... if you have started > > testing SCTP.. thats great (any feedback?).. > > and if you have not .. please do so :-D > > Hi, > > I played around a bit with NetPIPE, FreeBSD-CURRENT in one end and > Linux 2.6.17 in the other over a gigabit crossover cable network, 1500 > MTU. FreeBSD crashes after a while. I do have MAC enabled (no policy > modules loaded at the time), it looks like it is involved. I think I > can reproduce this, made it happen on both attempts. > And I removed MAC and I get another panic. No idea if directly related to SCTP. panic: sbdrop KDB: stack backtrace: kdb_backtrace(c0761224,c07bd400,c07649ee,d5b14a10,100,...) at kdb_backtrace+0x2e panic(c07649ee,c2b42d24,0,0,0,...) at panic+0xb7 sbdrop_locked(c2aaf9d0,10c19,0,c05250f9,c2aaf9d0,...) at sbdrop_locked+0x46 sbflush_locked(c2aaf9d0,c2b42b70,0,0,3041,...) at sbflush_locked+0x54 sbrelease_locked(c2aaf9d0,c2aaf914,d5b14a88,c05eb388,c2b42b70,...) at sbrelease_locked+0x12 sofree(c2aaf914,d5b14ae4,4,d5b14ab4,c073ce8c,...) at sofree+0x2a3 soclose(c2aaf914,d5b14b24,0,d5b14ae0,c059d652,...) at soclose+0x3ff soo_close(c27305a0,c275bbd0,d5b14af8,c05a9798,c27305a0,...) at soo_close+0x7d fdrop_locked(c27305a0,c275bbd0,c0722f76,d5b14be0,4) at fdrop_locked+0xf0 fdrop(c27305a0,c275bbd0,c2720924,0,c275bbd0,d5b14be0,0,0,0,c06d1e2b,c2720924,c2b41374,c175b040,d5b14b68,c06e2c12,4,c29b7514,28111000,d5b14c5c,c06d39f2,d5b14be0,80,c2b41374,5,0) at fdrop+0x5f closef(c27305a0,c275bbd0,c25c4a00,d5b14c64,0,...) at closef+0x542 fdfree(c275bbd0,c078e240,2,c053e2e6,c275bbd0,...) at fdfree+0x756 exit1(c275bbd0,19100,d5b14d30,c0727af3,c275bbd0,...) at exit1+0x660 sys_exit(c275bbd0,d5b14d04,4,c275bbd0,d5b14d30,...) at sys_exit+0x1d syscall(bfbf003b,82b003b,bfbc003b,bfbfe910,82c4000,...) at syscall+0x3d3 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280e87ef, esp = 0xbfbc002c, ebp = 0xbfbc0038 --- Uptime: 10m15s Physical memory: 502 MB Dumping 84 MB: 69 53 37 21 5 #0 doadump () at pcpu.h:166 166 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:166 #1 0xc0535b44 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0535ebd in panic (fmt=0xc07649ee "sbdrop") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc05876b6 in sbdrop_locked (sb=0xc2aaf9d0, len=68633) at /usr/src/sys/kern/uipc_socket2.c:1002 #4 0xc0587574 in sbflush_locked (sb=0xc2aaf9d0) at /usr/src/sys/kern/uipc_socket2.c:969 #5 0xc0586952 in sbrelease_locked (sb=0xc2aaf9d0, so=0x0) at /usr/src/sys/kern/uipc_socket2.c:469 #6 0xc0581603 in sofree (so=0xc2aaf914) at /usr/src/sys/kern/uipc_socket.c:587 #7 0xc0581a8f in soclose (so=0xc2aaf914) at /usr/src/sys/kern/uipc_socket.c:662 #8 0xc056b9bd in soo_close (fp=0xc27305a0, td=0xc275bbd0) at /usr/src/sys/kern/sys_socket.c:317 #9 0xc050be00 in fdrop_locked (fp=0xc27305a0, td=0x0) at file.h:296 #10 0xc050bcff in fdrop (fp=0xc27305a0, td=0x0) at /usr/src/sys/kern/kern_descrip.c:2156 #11 0xc0509b42 in closef (fp=0xc27305a0, td=0xc275bbd0) at /usr/src/sys/kern/kern_descrip.c:1971 #12 0xc0508396 in fdfree (td=0xc275bbd0) at /usr/src/sys/kern/kern_descrip.c:1653 #13 0xc0514620 in exit1 (td=0xc275bbd0, rv=102656) ---Type to continue, or q to quit--- at /usr/src/sys/kern/kern_exit.c:280 #14 0xc0513fbd in sys_exit (td=0x0, uap=0x0) at /usr/src/sys/kern/kern_exit.c:101 #15 0xc0727af3 in syscall (frame= {tf_fs = -1078001605, tf_es = 137035835, tf_ds = -1078198213, tf_edi = -1077942000, tf_esi = 137117696, tf_ebp = -1078198216, tf_isp = -709800604, tf_ebx = 672598776, tf_edx = 0, tf_ecx = 3, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 672040943, tf_cs = 51, tf_eflags = 646, tf_esp = -1078198228, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:1015 #16 0xc071613f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:191 #17 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 3 #3 0xc05876b6 in sbdrop_locked (sb=0xc2aaf9d0, len=68633) at /usr/src/sys/kern/uipc_socket2.c:1002 1002 panic("sbdrop"); (kgdb) list 997 998 next = (m = sb->sb_mb) ? m->m_nextpkt : 0; 999 while (len > 0) { 1000 if (m == 0) { 1001 if (next == 0) 1002 panic("sbdrop"); 1003 m = next; 1004 next = m->m_nextpkt; 1005 continue; 1006 } (kgdb) I also ran across this in the middle of things... this likely should have a new thread. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xa0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc06444be stack pointer = 0x28:0xd5b3bc24 frame pointer = 0x28:0xd5b3bc40 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1169 (ssh) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(c0761224,c07bd400,c0755b24,d5b3bad8,100,...) at kdb_backtrace+0x2e panic(c0755b24,c0779cd1,c2a9e3d4,1,1,...) at panic+0xb7 trap_fatal(d5b3bbe4,a0,2,8,0,...) at trap_fatal+0x342 trap_pfault(d5b3bbe4,0,a0,c29e5434,a0,...) at trap_pfault+0x245 trap(8,c0760028,c0760028,c079aed4,c29e53e4,...) at trap+0x3e3 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc06444be, esp = 0xd5b3bc24, ebp = 0xd5b3bc40 --- udp_shutdown(c29e53e4,0,d5b3bd04,c29c3a20,d5b3bc84,...) at udp_shutdown+0x1e soshutdown(c29e53e4,2,d5b3bc74,0,d5b3bdd0,...) at soshutdown+0x41 shutdown(c29c3a20,d5b3bd04,8,16,d5b3bd30,...) at shutdown+0xad syscall(82a003b,bfbf003b,bfbf003b,0,2,...) at syscall+0x3d3 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (134, FreeBSD ELF32, shutdown), eip = 0x2826c327, esp = 0xbfbfe9fc, ebp = 0xbfbfea18 --- Uptime: 13m47s Physical memory: 502 MB Dumping 46 MB: 31 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) 15 #0 doadump () at pcpu.h:166 166 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:166 #1 0xc0535b44 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0535ebd in panic (fmt=0xc0755b24 "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc07276b2 in trap_fatal (frame=0xd5b3bbe4, eva=160) at /usr/src/sys/i386/i386/trap.c:869 #4 0xc0727345 in trap_pfault (frame=0xd5b3bbe4, usermode=0, eva=160) at /usr/src/sys/i386/i386/trap.c:778 #5 0xc0726e93 in trap (frame= {tf_fs = 8, tf_es = -1066008536, tf_ds = -1066008536, tf_edi = -1065767212, tf_esi = -1029811228, tf_ebp = -709641152, tf_isp = -709641200, tf_ebx = 0, tf_edx = -1029948896, tf_ecx = 4, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = -1067170626, tf_cs = 32, tf_eflags = 66198, tf_esp = 0, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:463 #6 0xc07160ea in calltrap () at /usr/src/sys/i386/i386/exception.s:138 #7 0xc06444be in udp_shutdown (so=0xc29e53e4) at atomic.h:146 #8 0xc0583bf1 in soshutdown (so=0xc29e53e4, how=2) at /usr/src/sys/kern/uipc_socket.c:1810 #9 0xc058a07d in shutdown (td=0xc29c3a20, uap=0xd5b3bd04) at /usr/src/sys/kern/uipc_syscalls.c:1328 #10 0xc0727af3 in syscall (frame= {tf_fs = 136970299, tf_es = -1078001605, tf_ds = -1078001605, tf_edi = 0, tf_esi = 2, tf_ebp = -1077941736, tf_isp = -709640860, tf_ebx = 671968624, tf_ed---Type to continue, or q to quit--- x = 0, tf_ecx = 2, tf_eax = 134, tf_trapno = 22, tf_err = 2, tf_eip = 673628967, tf_cs = 51, tf_eflags = 582, tf_esp = -1077941764, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:1015 #11 0xc071613f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:191 #12 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) -- Pawel From owner-freebsd-net@FreeBSD.ORG Wed Jul 19 11:35:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C7D716A4DE for ; Wed, 19 Jul 2006 11:35:18 +0000 (UTC) (envelope-from freebsd_nettest@yahoo.co.in) Received: from web7803.mail.in.yahoo.com (web7803.mail.in.yahoo.com [202.86.4.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 68E8B43D49 for ; Wed, 19 Jul 2006 11:35:17 +0000 (GMT) (envelope-from freebsd_nettest@yahoo.co.in) Received: (qmail 62164 invoked by uid 60001); 19 Jul 2006 11:35:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Z7bQS7sFwWnPMy52DiGcxk+t8aVqAeo2/D1BjqM1iDfxK3kiehAAy/YlPzluKE7YZ1mYchH4gbJmyl11bnvv/Uqlj5MMlmj1fv10xSq8Xse01sRiof6kcgL00Ics5wVdTUaoJHS4z9r7SB6fj5UlcdeK/Km1oJ1gCIeOx3Ug8AE= ; Message-ID: <20060719113515.62162.qmail@web7803.mail.in.yahoo.com> Received: from [66.93.138.34] by web7803.mail.in.yahoo.com via HTTP; Wed, 19 Jul 2006 12:35:15 BST Date: Wed, 19 Jul 2006 12:35:15 +0100 (BST) From: freebsd nettest To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Supporting Multicast in Network driver 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, 19 Jul 2006 11:35:18 -0000 Hi, I would like to support MULTICAST in my network driver. I have define a function set_multi which will extract the Ethernet multicast address and update the corresponding hardware register. This function is called in the SIOCADDMULTI and SIOCDELMULTI ioctl case. I used following user level program to test the multicast functionality of the driver. When I run the user level program, I could see that the control comes to SIOCADDMULTI ioctl and the correct Ethernet Multicast Mac address is added. After that when I try to ping the Multicast IP address from remote machine, the ping is not responding. Do I need to do any thing extra apart from update the Ethernet Multicast address? User level program: #include #include #include #include #include //#include #include //#include #include int main(int argc, char *argv[]) { struct ip_mreq mreqn; int s; struct in_addr ip; if (argc != 3) { fprintf(stderr, "usage: %s \n", argv[0]); exit(1); } if((s = socket(PF_INET, SOCK_DGRAM, 0)) < 0) { perror("socket"); exit(1); } memset(&mreqn, 0, sizeof(mreqn)); inet_aton(argv[1], &(mreqn.imr_interface)); /* mreqn.imr_interface = ip; */ if (inet_pton(AF_INET, argv[2], &mreqn.imr_multiaddr) <= 0) { fprintf(stderr, "%s: \"%s\" invalid group address\n", argv[0],argv[2]); exit(1); } if (setsockopt(s, 0, IP_ADD_MEMBERSHIP,&mreqn,sizeof mreqn) < 0) { perror("IP_ADD_MEMBERSHIP"); exit(1); } printf("joined group %s on %s (pausing...)\n", argv[2], argv[1]); fflush(stdout); pause(); } Thanks --------------------------------- Find out what India is talking about on Yahoo! Answers India. Send FREE SMS from New Yahoo! Messenger to Mobile: Download NOW! From owner-freebsd-net@FreeBSD.ORG Wed Jul 19 13:09:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28F1516A4DE for ; Wed, 19 Jul 2006 13:09:52 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0315E43D5F for ; Wed, 19 Jul 2006 13:09:48 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k6JD9mik026884; Wed, 19 Jul 2006 06:09:48 -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]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k6JD9d88006348; Wed, 19 Jul 2006 06:09:39 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Wed, 19 Jul 2006 22:09:36 +0900 Message-ID: From: gnn@freebsd.org To: "Tom Parker" In-Reply-To: <9050f13e0607181203r610da712kc506507b4f90b77c@mail.gmail.com> References: <9050f13e0607181203r610da712kc506507b4f90b77c@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.6.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Possible inconsistency in the use of in6_delmulti() 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, 19 Jul 2006 13:09:52 -0000 At Tue, 18 Jul 2006 12:03:20 -0700, Tom Parker wrote: > > Hi, > > New to the list here, but fairly familiar with the innards of (at > least an older) version of the fbsd networking code. I'm fortunate in > my ability to run purify on a simulated instance of our ported version > of the networking code. Purify has picked up a problem that I'm a bit > mystified as how it can be fixed. It is present in current versions > also, I'm interested in any comments people have (I think ours is 4.4 > vintage, but it is hard to tell). > > As far as I can tell, in most calling paths when in6_delmulti() is > called, it is done after the in6_multi_mship structure has been > removed from the im6o_memberships list in the relevant PCB. This > applies to in6_ifdetach(), in6_pcbpurgeif0, ip6_setmoptions() etc. > However in in6_purgeaddr() in6_delmulti is called straight off. I'm > not sure if we've violated some usage convention, but purify is > telling me this causes access violations when we then leave the same > group using setsockopt(). in6_purgeaddr is called when we remove the > address from the interface. > > This should be possible in a real kernel. Add a multicast address to > an interface, open a socket and listen to the address, then remove the > address from the interface. > > Am I missing something here or is this a nasty problem in both the > kernel and our stack port? > It sounds like a bug to me. Can you file a PR? Thanks, George From owner-freebsd-net@FreeBSD.ORG Wed Jul 19 13:20:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A7E116A4DE for ; Wed, 19 Jul 2006 13:20:16 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0549B43D46 for ; Wed, 19 Jul 2006 13:20:15 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 19 Jul 2006 06:20:17 -0700 X-IronPort-AV: i="4.06,260,1149490800"; d="scan'208"; a="306673142:sNHT25335380" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6JDKFZ4014467; Wed, 19 Jul 2006 06:20:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6JDKF79006668; Wed, 19 Jul 2006 06:20:15 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Jul 2006 06:20:15 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 06:20:14 -0700 Message-ID: <44BE3194.1080601@cisco.com> Date: Wed, 19 Jul 2006 09:20:20 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yann Berthier References: <44BB7A92.9080008@cisco.com> <20060718193026.GA1687@bashibuzuk.net> In-Reply-To: <20060718193026.GA1687@bashibuzuk.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2006 13:20:14.0918 (UTC) FILETIME=[123C8E60:01C6AB36] DKIM-Signature: a=rsa-sha1; q=dns; l=937; t=1153315215; x=1154179215; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20SCTP; X=v=3Dcisco.com=3B=20h=3DeFwn8yHouLxYzxwWS0cbAORTlr0=3D; b=eIGTI81Hk3M7peAQTh33lZEDNThcwc/H5YVQAT8Ru81Ifxt44RQyzrm69/RQWdzEK32K47jQ ykr/6L7WWeMmm2GHJCt3xOXCK6hZ9MNgwI3ZEArMQgrgfUcWhxa67SZT; Authentication-Results: sj-dkim-6.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org Subject: Re: SCTP 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, 19 Jul 2006 13:20:16 -0000 Yann Berthier wrote: > Hello, > > On Mon, 17 Jul 2006, at 07:54, Randall Stewart wrote: > > >>All: >> >>Just a friendly reminder/prod... if you have started >>testing SCTP.. thats great (any feedback?).. > > > As said last time, i've been using sctp with netflow records between > a router and a freebsd box - perhaps not the most useful test, but > it's the only 'real life' test i found. if you have other ideas ... > anyway, the only way to have more exposure is to have more sctp ready > applications, and a good way to have it happen is to commit your > patch, right :) Of course.. You can also find a patch for apache to use SCTP and a firebird version that can take advantage of it at: http://pel.cis.udel.edu/ R > > -- > http://flowog.6f2.net/ - A NetFlow collecting house > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Jul 19 13:34:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D3BF16A4DA for ; Wed, 19 Jul 2006 13:34:24 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20A7543D49 for ; Wed, 19 Jul 2006 13:34:22 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 19 Jul 2006 06:34:23 -0700 X-IronPort-AV: i="4.06,260,1149490800"; d="scan'208"; a="330011425:sNHT29662100" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6JDYMel020671; Wed, 19 Jul 2006 06:34:22 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6JDYMiB002744; Wed, 19 Jul 2006 06:34:22 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 06:34:22 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 06:34:21 -0700 Message-ID: <44BE34E2.7070603@cisco.com> Date: Wed, 19 Jul 2006 09:34:26 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Worach References: <44BB7A92.9080008@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2006 13:34:21.0553 (UTC) FILETIME=[0ADECE10:01C6AB38] DKIM-Signature: a=rsa-sha1; q=dns; l=9534; t=1153316062; x=1154180062; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20SCTP; X=v=3Dcisco.com=3B=20h=3DeFwn8yHouLxYzxwWS0cbAORTlr0=3D; b=GWl/aIYnhQ+f+dByKrzv/wQ0R+K4EQajnhMzn2A9WFoCX3mBAt6yihiJRsmrCeuRDVArZzmn X0s+OHZyY3E7LNjmPz3iPk5BQ7PIn08jbuKHex4+EenJRmpLRB/lpURm; Authentication-Results: sj-dkim-1.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org Subject: Re: SCTP 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, 19 Jul 2006 13:34:24 -0000 Pawel: I see at least one thing wrong with the sctp_sendmsg() code... I just recently added the iov.... and the order of where bad:/ bad2:/ bad1: goes is wrong.. Now, the MAC stuff I have never enabled (at least I don't think so).. and I see that in this trace it seems the MAC stuff is calling to deallocate the socket directly... I am not sure if the crash is related to the wrong bad calls.. which would do a free() when it should not on the iov.. that can't be good.. but also not sure of the deallocate() stuff... The bad stuff is easy to fix.. and I will get a new patch prepared.. (I also will see if I can't update to current again.. and thus eliminate your syscall conflict).. But I want to look a bit into this mac_destroy_socket() path... R Pawel Worach wrote: > On 7/17/06, Randall Stewart wrote: > >> All: >> >> Just a friendly reminder/prod... if you have started >> testing SCTP.. thats great (any feedback?).. >> and if you have not .. please do so :-D > > > Hi, > > I played around a bit with NetPIPE, FreeBSD-CURRENT in one end and > Linux 2.6.17 in the other over a gigabit crossover cable network, 1500 > MTU. FreeBSD crashes after a while. I do have MAC enabled (no policy > modules loaded at the time), it looks like it is involved. I think I > can reproduce this, made it happen on both attempts. > > For the record, I modified the patch a bit to make it compile, the > syscalls numbers collide with new threading syscalls added recently, > so I moved the thr syscalls up a notch. And I removed this #ifdef MAC > part of the patch due to duplicate sctp_bad labels. > > +#ifdef MAC > +sctp_bad: > +#endif > + sctp_bad: > + free(iov, M_IOV); > > Any more info I can provide ? > > ~/sctp/np> ./NPsctp -h 192.168.10.1 > ... > 68: 16384 bytes 71 times --> 179.87 Mbps in 694.94 usec > 69: 16387 bytes 71 times --> 178.78 Mbps in 699.33 usec > 70: 24573 bytes 71 times --> 198.43 Mbps in 944.80 usec > 71: 24576 bytes 70 times --> 199.18 Mbps in 941.35 usec > 72: 24579 bytes 70 times --> 198.82 Mbps in 943.19 usec > 73: 32765 bytes 35 times --> 210.05 Mbps in 1190.07 usec > 74: 32768 bytes 42 times --> 208.48 Mbps in 1199.15 usec > 75: 32771 bytes 41 times --> 208.00 Mbps in 1202.03 usec > 76: 49149 bytes 41 times --> 234.43 Mbps in 1599.55 usec > 77: 49152 bytes 41 times --> 300.20 Mbps in 1249.17 usec > 78: 49155 bytes 53 times --> 299.66 Mbps in 1251.51 usec > 79: 65533 bytes 26 times --> 4.77 Mbps in 104844.52 usec > 80: 65536 bytes 3 times --> 3.70 Mbps in 135258.48 usec > 81: 65539 bytes 3 times --> 3.70 Mbps in 135257.16 usec > 82: 98301 bytes 3 times --> 7.36 Mbps in 101946.00 usec > 83: 98304 bytes 3 times --> 7.36 Mbps in 101923.51 usec > 84: 98307 bytes 3 times --> 7.36 Mbps in 101945.48 usec > 85: 131069 bytes 3 times --> [stalls here] > > then a couple of seconds later... > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc06a7e16 > stack pointer = 0x28:0xd35e5174 > frame pointer = 0x28:0xd35e5174 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (swi1: net) > trap number = 12 > panic: page fault > KDB: stack backtrace: > kdb_backtrace(c078488a,c07e2500,c07790c0,d35e5028,100,...) at > kdb_backtrace+0x2e > panic(c07790c0,c079de93,c2466a70,1,1,...) at panic+0xb7 > trap_fatal(d35e5134,0,2,8,e5df6f6e,...) at trap_fatal+0x342 > trap_pfault(d35e5134,0,0,0,0,...) at trap_pfault+0x245 > trap(8,ffff0028,7fff0028,c104db80,0,...) at trap+0x3e3 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc06a7e16, esp = 0xd35e5174, ebp = 0xd35e5174 --- > mac_labelzone_dtor(0,14,0,0,0,...) at mac_labelzone_dtor+0x6 > uma_zfree_arg(c104db80,0,0,d35e51d0,c06acfc4,...) at uma_zfree_arg+0x2f > mac_labelzone_free(0) at mac_labelzone_free+0x22 > mac_socket_label_free(0,c2ad4000,d35e5200,c0587da8,c2ad4000,...) at > mac_socket_label_free+0x94 > mac_destroy_socket(c2ad4000,40,0,c2ad4000,4,...) at mac_destroy_socket+0x18 > sodealloc(c2ad4000,c2ad4000,0,0,4,...) at sodealloc+0x168 > sofree(c2ad4000,0,0,0,c10372c8,...) at sofree+0x311 > sctp_inpcb_free(c2c98000,0,0,d35e52b4,c060c90d,...) at > sctp_inpcb_free+0x10d6 > sctp_free_assoc(c2c98000,c2cad958,0,c2cafcd0,d35e534c,...) at > sctp_free_assoc+0x1a5b > sctp_handle_shutdown_complete(c2cf3830,c2cad958,c2cafcd0,d35e534c,c0754bbe,...) > > at sctp_handle_shutdown_complete+0x228 > sctp_process_control(c2cea500,14,d35e5bb8,24,c2cf3824,...) at > sctp_process_control+0x1388 > sctp_common_input_processing(d35e5c30,14,20,24,c2cf3824,...) at > sctp_common_input_processing+0x87 > sctp_input(c2cea500,14,c255c800,1,0,...) at sctp_input+0x383 > ip_input(c2cea500,d35e5c88,c0553c65,8,0,...) at ip_input+0x70c > netisr_processqueue(c07e75b8,c2467870,c2467870,c24668d0,d35e5ce4,...) > at netisr_processqueue+0xe9 > swi_net(0,c2467870,80246,b9669622,c2467870,...) at swi_net+0x12f > ithread_execute_handlers(c24668d0,c2463500,c24668d0,c2467870,c24668d0,...) > at ithread_execute_handlers+0x188 > ithread_loop(c2433ad0,d35e5d38,0,0,c2433ad0,...) at ithread_loop+0x76 > fork_exit(c051d900,c2433ad0,d35e5d38) at fork_exit+0x7f > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xd35e5d6c, ebp = 0 --- > Uptime: 27m28s > Physical memory: 502 MB > Dumping 68 MB: 53 37 21 5 > > #0 doadump () at pcpu.h:166 > 166 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:166 > #1 0xc053c0b4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc053c42d in panic (fmt=0xc07790c0 "%s") > at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc074a2d2 in trap_fatal (frame=0xd35e5134, eva=0) > at /usr/src/sys/i386/i386/trap.c:869 > #4 0xc0749f65 in trap_pfault (frame=0xd35e5134, usermode=0, eva=0) > at /usr/src/sys/i386/i386/trap.c:778 > #5 0xc0749ab3 in trap (frame= > {tf_fs = 8, tf_es = -65496, tf_ds = 2147418152, tf_edi = > -1056646272, tf_esi = 0, tf_ebp = -748793484, tf_isp = -748793504, > tf_ebx = 0, tf_edx = 0, tf_ecx = 4, tf_eax = 0, tf_trapno = 12, tf_err > = 2, tf_eip = -1066762730, tf_cs = 32, tf_eflags = 66178, tf_esp = > -748793432, tf_ss = -1066463889}) > at /usr/src/sys/i386/i386/trap.c:463 > #6 0xc0738cfa in calltrap () at /usr/src/sys/i386/i386/exception.s:138 > #7 0xc06a7e16 in mac_labelzone_dtor (mem=0x0, size=20, arg=0x0) > at /usr/src/sys/security/mac/mac_label.c:74 > #8 0xc06f0d6f in uma_zfree_arg (zone=0xc104db80, item=0x0, udata=0x0) > at /usr/src/sys/vm/uma_core.c:2263 > #9 0xc06a7e72 in mac_labelzone_free (label=0x0) at uma.h:303 > #10 0xc06acfc4 in mac_socket_label_free (label=0x0) > at /usr/src/sys/security/mac/mac_socket.c:151 > #11 0xc06ad088 in mac_destroy_socket (socket=0xc2ad4000) > ---Type to continue, or q to quit--- > at /usr/src/sys/security/mac/mac_socket.c:168 > #12 0xc0587da8 in sodealloc (so=0xc2ad4000) > at /usr/src/sys/kern/uipc_socket.c:291 > #13 0xc0588971 in sofree (so=0xc2ad4000) at > /usr/src/sys/kern/uipc_socket.c:592 > #14 0xc0604986 in sctp_inpcb_free (inp=0xc2c98000, immediate=0) > at /usr/src/sys/netinet/sctp_pcb.c:2582 > #15 0xc060817b in sctp_free_assoc (inp=0xc2c98000, stcb=0xc2cad958, > from_inpcbfree=0) at /usr/src/sys/netinet/sctp_pcb.c:3896 > #16 0xc0617b58 in sctp_handle_shutdown_complete (cp=0xc2cf3830, > stcb=0xc2cad958, net=0x0) at /usr/src/sys/netinet/sctp_input.c:2500 > #17 0xc061a7d8 in sctp_process_control (m=0xc2cea500, iphlen=20, > offset=0xd35e5bb8, length=36, sh=0xc2cf3824, ch=0xc2cf3830, > inp=0xc2c98000, stcb=0xc2cad958, netp=0xd35e5bd0, > fwd_tsn_seen=0xd35e5b98) > at /usr/src/sys/netinet/sctp_input.c:4267 > #18 0xc061ad87 in sctp_common_input_processing (mm=0xd35e5c30, iphlen=20, > offset=32, length=36, sh=0xc2cf3824, ch=0xc2cf3830, inp=0xc2c98000, > stcb=0xc2cad958, net=0xc2cafcd0, ecn_bits=2 '\002') > at /usr/src/sys/netinet/sctp_input.c:4583 > #19 0xc061b5e3 in sctp_input (m=0xc2cea500, off=20) > at /usr/src/sys/netinet/sctp_input.c:4994 > #20 0xc05ec1ec in ip_input (m=0xc2cea500) > at /usr/src/sys/netinet/ip_input.c:658 > #21 0xc05d2de9 in netisr_processqueue (ni=0xc07e75b8) > ---Type to continue, or q to quit--- > at /usr/src/sys/net/netisr.c:236 > #22 0xc05d305f in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 > #23 0xc051d808 in ithread_execute_handlers (p=0xc24668d0, ie=0xc2463500) > at /usr/src/sys/kern/kern_intr.c:662 > #24 0xc051d976 in ithread_loop (arg=0xc2433ad0) > at /usr/src/sys/kern/kern_intr.c:745 > #25 0xc051c38f in fork_exit (callout=0xc051d900 , arg=0x0, > frame=0x0) at /usr/src/sys/kern/kern_fork.c:822 > #26 0xc0738d5c in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:199 > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Jul 19 13:39:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7474F16A4DA for ; Wed, 19 Jul 2006 13:39:39 +0000 (UTC) (envelope-from freebsd_nettest@yahoo.co.in) Received: from web7814.mail.in.yahoo.com (web7814.mail.in.yahoo.com [202.86.4.71]) by mx1.FreeBSD.org (Postfix) with SMTP id 5E60343D46 for ; Wed, 19 Jul 2006 13:39:38 +0000 (GMT) (envelope-from freebsd_nettest@yahoo.co.in) Received: (qmail 23168 invoked by uid 60001); 19 Jul 2006 13:39:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YnJLnFx28m6SjOXtAppgg6LN7/It3zGwNqQSo/hHk2IwG5rGAOXkvemglJTrHPJ6tIl++dcDUa9NMmHUSotzuyUPlYgmKoyxba3I8IIP7TgdzqZFnvEnqkIvBMaAk7exV8yJZ3qpdZVrrpIo52BitOKF0I3vEKUdSuCfq2cmSHM= ; Message-ID: <20060719133936.23166.qmail@web7814.mail.in.yahoo.com> Received: from [66.93.138.34] by web7814.mail.in.yahoo.com via HTTP; Wed, 19 Jul 2006 14:39:36 BST Date: Wed, 19 Jul 2006 14:39:36 +0100 (BST) From: freebsd nettest To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Testing of Multicast support on fxp and bge driver. 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, 19 Jul 2006 13:39:39 -0000 Hi all, I was trying to test the Multicast support of bge and fxp driver using the following user level program. #include #include #include #include #include //#include #include //#include #include int main(int argc, char *argv[]) { struct ip_mreq mreqn; int s; struct in_addr ip; if (argc != 3) { fprintf(stderr, "usage: %s \n", argv[0]); exit(1); } if((s = socket(PF_INET, SOCK_DGRAM, 0)) < 0) { perror("socket"); exit(1); } memset(&mreqn, 0, sizeof(mreqn)); inet_aton(argv[1], &(mreqn.imr_interface)); /* mreqn.imr_interface = ip; */ if (inet_pton(AF_INET, argv[2], &mreqn.imr_multiaddr) <= 0) { fprintf(stderr, "%s: \"%s\" invalid group address\n", argv[0],argv[2]); exit(1); } if (setsockopt(s, 0, IP_ADD_MEMBERSHIP,&mreqn,sizeof mreqn) < 0) { perror("IP_ADD_MEMBERSHIP"); exit(1); } printf("joined group %s on %s (pausing...)\n", argv[2], argv[1]); fflush(stdout); pause(); } On test machine: [root@FBSD6-AMD]# ./a.out bge0 224.1.1.37 joined group 224.1.1.37 on bge0 (pausing...) On remote machine: -bash-3.00# ping -i xge2 224.1.1.37 no answer from 224.1.1.37 The ping is failing. I tried the same test on fxp (intel interface) also. The ping to the multicast IP is not working. am I doing the correct steps? Do I need to check any firewall setting that prevent the multicast packets?? Please advice, if I miss something in the testing. Thanks, --------------------------------- Find out what India is talking about on Yahoo! Answers India. Send FREE SMS from New Yahoo! Messenger to Mobile: Download NOW! From owner-freebsd-net@FreeBSD.ORG Wed Jul 19 14:16:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63FE416A4DA for ; Wed, 19 Jul 2006 14:16:45 +0000 (UTC) (envelope-from pavol@cierny.sk) Received: from pavol.slovenska.sk (t0uch.slovenska.sk [212.5.219.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53DFB43D6B for ; Wed, 19 Jul 2006 14:16:40 +0000 (GMT) (envelope-from pavol@cierny.sk) Received: (qmail 46721 invoked by uid 98); 19 Jul 2006 14:16:38 -0000 Received: from 87.197.150.27 by pavol.slovenska.sk (envelope-from , uid 82) with qmail-scanner-1.25 (uvscan: v4.4.00/v4786. spamassassin: 3.0.2. Clear:RC:0(87.197.150.27):SA:0(1.0/5.0):. Processed in 1.39167 secs); 19 Jul 2006 14:16:38 -0000 X-Spam-Status: No, hits=1.0 required=5.0 X-Spam-Level: + X-Qmail-Scanner-Mail-From: pavol@cierny.sk via pavol.slovenska.sk X-Qmail-Scanner: 1.25 (Clear:RC:0(87.197.150.27):SA:0(1.0/5.0):. Processed in 1.39167 secs) Received: from unknown (HELO adsl-d27.87-197-150.telecom.sk) (scorp@87.197.150.27) by ns.slovenska.sk with AES256-SHA encrypted SMTP; 19 Jul 2006 14:16:37 -0000 Date: Wed, 19 Jul 2006 16:16:32 +0200 From: =?Windows-1250?Q?Pavol_=C8ierny?= X-Mailer: The Bat! (v3.5.30) Professional Organization: WEBY.SLOVENSKA.SK X-Priority: 3 (Normal) Message-ID: <679510527.20060719161632@cierny.sk> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1250 Content-Transfer-Encoding: 8bit Subject: Broadcom 5780 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?Windows-1250?Q?Pavol_=C8ierny?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 14:16:45 -0000 Hello, has anyone information about implementing Broadcom 5780 to the bge driver? Just bought a Fujitsu-Siemens RX220 server, and the NICs don't work :( --- Best regards Pavol хierny From owner-freebsd-net@FreeBSD.ORG Wed Jul 19 14:22:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68E2416A4DA for ; Wed, 19 Jul 2006 14:22:33 +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 020C843D4C for ; Wed, 19 Jul 2006 14:22:32 +0000 (GMT) (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 CDFD5DA848; Wed, 19 Jul 2006 14:22:31 +0000 (GMT) Received: by gremlin.foo.is (Postfix, from userid 1000) id DA768DA842; Wed, 19 Jul 2006 14:22:27 +0000 (GMT) Date: Wed, 19 Jul 2006 14:22:27 +0000 From: Baldur Gislason To: freebsd nettest Message-ID: <20060719142227.GE36671@gremlin.foo.is> References: <20060719133936.23166.qmail@web7814.mail.in.yahoo.com> In-Reply-To: <20060719133936.23166.qmail@web7814.mail.in.yahoo.com> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on gremlin.foo.is X-Spam-Level: X-Spam-Status: No, score=-5.9 required=6.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: Foo MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Cc: freebsd-net@freebsd.org Subject: Re: Testing of Multicast support on fxp and bge driver. 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, 19 Jul 2006 14:22:33 -0000 try sysctl net.inet.icmp.bmcastecho=1 Baldur On Wed, Jul 19, 2006 at 02:39:36PM +0100, freebsd nettest wrote: > Hi all, > > I was trying to test the Multicast support of bge and fxp driver using the following user level program. > > #include > #include > #include > #include > #include > //#include > #include > //#include > #include > int > main(int argc, char *argv[]) > { > struct ip_mreq mreqn; > int s; > struct in_addr ip; > if (argc != 3) { > fprintf(stderr, "usage: %s \n", argv[0]); > exit(1); > } > if((s = socket(PF_INET, SOCK_DGRAM, 0)) < 0) { > perror("socket"); > exit(1); > } > memset(&mreqn, 0, sizeof(mreqn)); > inet_aton(argv[1], &(mreqn.imr_interface)); > /* mreqn.imr_interface = ip; */ > > if (inet_pton(AF_INET, argv[2], &mreqn.imr_multiaddr) <= 0) { > fprintf(stderr, "%s: \"%s\" invalid group address\n", argv[0],argv[2]); > exit(1); > } > if (setsockopt(s, 0, IP_ADD_MEMBERSHIP,&mreqn,sizeof mreqn) < 0) { > perror("IP_ADD_MEMBERSHIP"); > exit(1); > } > printf("joined group %s on %s (pausing...)\n", argv[2], argv[1]); fflush(stdout); > pause(); > } > > > On test machine: > [root@FBSD6-AMD]# ./a.out bge0 224.1.1.37 > joined group 224.1.1.37 on bge0 (pausing...) > > > On remote machine: > -bash-3.00# ping -i xge2 224.1.1.37 > no answer from 224.1.1.37 > > > The ping is failing. I tried the same test on fxp (intel interface) also. The ping to the multicast IP is not working. am I doing the correct steps? Do I need to check any firewall setting that prevent the multicast packets?? > > Please advice, if I miss something in the testing. > > Thanks, > > > --------------------------------- > Find out what India is talking about on Yahoo! Answers India. > Send FREE SMS from New Yahoo! Messenger to Mobile: Download NOW! > _______________________________________________ > 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 Wed Jul 19 15:17:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA7F216A4DA for ; Wed, 19 Jul 2006 15:17:24 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E48043D4C for ; Wed, 19 Jul 2006 15:17:23 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 19 Jul 2006 08:17:24 -0700 X-IronPort-AV: i="4.06,260,1149490800"; d="scan'208"; a="435186806:sNHT30312156" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6JFHKWx021723; Wed, 19 Jul 2006 08:17:20 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6JFHK2D029818; Wed, 19 Jul 2006 08:17:20 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Jul 2006 08:17:20 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 08:17:19 -0700 Message-ID: <44BE4D01.3070300@cisco.com> Date: Wed, 19 Jul 2006 11:17:21 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Worach References: <44BB7A92.9080008@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2006 15:17:20.0078 (UTC) FILETIME=[6D8EE6E0:01C6AB46] DKIM-Signature: a=rsa-sha1; q=dns; l=9659; t=1153322243; x=1154186243; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20SCTP; X=v=3Dcisco.com=3B=20h=3DeFwn8yHouLxYzxwWS0cbAORTlr0=3D; b=De1WrPzgaZZmN4N6/5yzHj5vnoyK235lhZOgVsK1cmZILmGLiwNTzElP16b3IkFV1QH4WBlW YDxHuYCK+Zdu30J4g0TzQCOL6HZxBi6tM7jq7fS77HYVw0/4p17FI+QG; Authentication-Results: sj-dkim-4.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org Subject: Re: SCTP 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, 19 Jul 2006 15:17:24 -0000 Pawel: Ok, I have verified that even with my patch I can recreate this one.. have not tried the mac one yet (I will fix this first :-D) I do think its an SCTP problem.. it looks to me like an accounting issue... sb_cc or sb_mbcnt is left with a value (at a guess) when we never use the sb_mb pointers... so it panics.. In theory sb_cc and sb_mbcnt should be zero at cleanup.. so some where a bug crept in from the last time I played with netpipe :-0 Should have a patch later today hopefully.. of course I am now trying to get kgdb to build.. I have not done a buildworld in a while and of course there have been changes and the old kgdb will not read the core.. some nice error... sigh... I hate to go down the build-world rat-hole.. at least after the last time I did this it took me a long time to recover... but I will jump in with both feet :-D R Pawel Worach wrote: > On 7/18/06, Pawel Worach wrote: > >> On 7/17/06, Randall Stewart wrote: >> > All: >> > >> > Just a friendly reminder/prod... if you have started >> > testing SCTP.. thats great (any feedback?).. >> > and if you have not .. please do so :-D >> >> Hi, >> >> I played around a bit with NetPIPE, FreeBSD-CURRENT in one end and >> Linux 2.6.17 in the other over a gigabit crossover cable network, 1500 >> MTU. FreeBSD crashes after a while. I do have MAC enabled (no policy >> modules loaded at the time), it looks like it is involved. I think I >> can reproduce this, made it happen on both attempts. >> > > And I removed MAC and I get another panic. No idea if directly related > to SCTP. > > panic: sbdrop > KDB: stack backtrace: > kdb_backtrace(c0761224,c07bd400,c07649ee,d5b14a10,100,...) at > kdb_backtrace+0x2e > panic(c07649ee,c2b42d24,0,0,0,...) at panic+0xb7 > sbdrop_locked(c2aaf9d0,10c19,0,c05250f9,c2aaf9d0,...) at sbdrop_locked+0x46 > sbflush_locked(c2aaf9d0,c2b42b70,0,0,3041,...) at sbflush_locked+0x54 > sbrelease_locked(c2aaf9d0,c2aaf914,d5b14a88,c05eb388,c2b42b70,...) at > sbrelease_locked+0x12 > sofree(c2aaf914,d5b14ae4,4,d5b14ab4,c073ce8c,...) at sofree+0x2a3 > soclose(c2aaf914,d5b14b24,0,d5b14ae0,c059d652,...) at soclose+0x3ff > soo_close(c27305a0,c275bbd0,d5b14af8,c05a9798,c27305a0,...) at > soo_close+0x7d > fdrop_locked(c27305a0,c275bbd0,c0722f76,d5b14be0,4) at fdrop_locked+0xf0 > fdrop(c27305a0,c275bbd0,c2720924,0,c275bbd0,d5b14be0,0,0,0,c06d1e2b,c2720924,c2b41374,c175b040,d5b14b68,c06e2c12,4,c29b7514,28111000,d5b14c5c,c06d39f2,d5b14be0,80,c2b41374,5,0) > > at fdrop+0x5f > closef(c27305a0,c275bbd0,c25c4a00,d5b14c64,0,...) at closef+0x542 > fdfree(c275bbd0,c078e240,2,c053e2e6,c275bbd0,...) at fdfree+0x756 > exit1(c275bbd0,19100,d5b14d30,c0727af3,c275bbd0,...) at exit1+0x660 > sys_exit(c275bbd0,d5b14d04,4,c275bbd0,d5b14d30,...) at sys_exit+0x1d > syscall(bfbf003b,82b003b,bfbc003b,bfbfe910,82c4000,...) at syscall+0x3d3 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280e87ef, esp = > 0xbfbc002c, ebp = 0xbfbc0038 --- > Uptime: 10m15s > Physical memory: 502 MB > Dumping 84 MB: 69 53 37 21 5 > > #0 doadump () at pcpu.h:166 > 166 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:166 > #1 0xc0535b44 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc0535ebd in panic (fmt=0xc07649ee "sbdrop") > at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc05876b6 in sbdrop_locked (sb=0xc2aaf9d0, len=68633) > at /usr/src/sys/kern/uipc_socket2.c:1002 > #4 0xc0587574 in sbflush_locked (sb=0xc2aaf9d0) > at /usr/src/sys/kern/uipc_socket2.c:969 > #5 0xc0586952 in sbrelease_locked (sb=0xc2aaf9d0, so=0x0) > at /usr/src/sys/kern/uipc_socket2.c:469 > #6 0xc0581603 in sofree (so=0xc2aaf914) at > /usr/src/sys/kern/uipc_socket.c:587 > #7 0xc0581a8f in soclose (so=0xc2aaf914) > at /usr/src/sys/kern/uipc_socket.c:662 > #8 0xc056b9bd in soo_close (fp=0xc27305a0, td=0xc275bbd0) > at /usr/src/sys/kern/sys_socket.c:317 > #9 0xc050be00 in fdrop_locked (fp=0xc27305a0, td=0x0) at file.h:296 > #10 0xc050bcff in fdrop (fp=0xc27305a0, td=0x0) > at /usr/src/sys/kern/kern_descrip.c:2156 > #11 0xc0509b42 in closef (fp=0xc27305a0, td=0xc275bbd0) > at /usr/src/sys/kern/kern_descrip.c:1971 > #12 0xc0508396 in fdfree (td=0xc275bbd0) > at /usr/src/sys/kern/kern_descrip.c:1653 > #13 0xc0514620 in exit1 (td=0xc275bbd0, rv=102656) > ---Type to continue, or q to quit--- > at /usr/src/sys/kern/kern_exit.c:280 > #14 0xc0513fbd in sys_exit (td=0x0, uap=0x0) > at /usr/src/sys/kern/kern_exit.c:101 > #15 0xc0727af3 in syscall (frame= > {tf_fs = -1078001605, tf_es = 137035835, tf_ds = -1078198213, > tf_edi = -1077942000, tf_esi = 137117696, tf_ebp = -1078198216, tf_isp > = -709800604, tf_ebx = 672598776, tf_edx = 0, tf_ecx = 3, tf_eax = 1, > tf_trapno = 12, tf_err = 2, tf_eip = 672040943, tf_cs = 51, tf_eflags > = 646, tf_esp = -1078198228, tf_ss = 59}) at > /usr/src/sys/i386/i386/trap.c:1015 > #16 0xc071613f in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:191 > #17 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) f 3 > #3 0xc05876b6 in sbdrop_locked (sb=0xc2aaf9d0, len=68633) > at /usr/src/sys/kern/uipc_socket2.c:1002 > 1002 panic("sbdrop"); > (kgdb) list > 997 > 998 next = (m = sb->sb_mb) ? m->m_nextpkt : 0; > 999 while (len > 0) { > 1000 if (m == 0) { > 1001 if (next == 0) > 1002 panic("sbdrop"); > 1003 m = next; > 1004 next = m->m_nextpkt; > 1005 continue; > 1006 } > (kgdb) > > I also ran across this in the middle of things... this likely should > have a new thread. > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xa0 > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc06444be > stack pointer = 0x28:0xd5b3bc24 > frame pointer = 0x28:0xd5b3bc40 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1169 (ssh) > trap number = 12 > panic: page fault > KDB: stack backtrace: > kdb_backtrace(c0761224,c07bd400,c0755b24,d5b3bad8,100,...) at > kdb_backtrace+0x2e > panic(c0755b24,c0779cd1,c2a9e3d4,1,1,...) at panic+0xb7 > trap_fatal(d5b3bbe4,a0,2,8,0,...) at trap_fatal+0x342 > trap_pfault(d5b3bbe4,0,a0,c29e5434,a0,...) at trap_pfault+0x245 > trap(8,c0760028,c0760028,c079aed4,c29e53e4,...) at trap+0x3e3 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc06444be, esp = 0xd5b3bc24, ebp = 0xd5b3bc40 --- > udp_shutdown(c29e53e4,0,d5b3bd04,c29c3a20,d5b3bc84,...) at > udp_shutdown+0x1e > soshutdown(c29e53e4,2,d5b3bc74,0,d5b3bdd0,...) at soshutdown+0x41 > shutdown(c29c3a20,d5b3bd04,8,16,d5b3bd30,...) at shutdown+0xad > syscall(82a003b,bfbf003b,bfbf003b,0,2,...) at syscall+0x3d3 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (134, FreeBSD ELF32, shutdown), eip = 0x2826c327, esp = > 0xbfbfe9fc, ebp = 0xbfbfea18 --- > Uptime: 13m47s > Physical memory: 502 MB > Dumping 46 MB: 31 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to > abort) 15 > > #0 doadump () at pcpu.h:166 > 166 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:166 > #1 0xc0535b44 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc0535ebd in panic (fmt=0xc0755b24 "%s") > at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc07276b2 in trap_fatal (frame=0xd5b3bbe4, eva=160) > at /usr/src/sys/i386/i386/trap.c:869 > #4 0xc0727345 in trap_pfault (frame=0xd5b3bbe4, usermode=0, eva=160) > at /usr/src/sys/i386/i386/trap.c:778 > #5 0xc0726e93 in trap (frame= > {tf_fs = 8, tf_es = -1066008536, tf_ds = -1066008536, tf_edi = > -1065767212, tf_esi = -1029811228, tf_ebp = -709641152, tf_isp = > -709641200, tf_ebx = 0, tf_edx = -1029948896, tf_ecx = 4, tf_eax = 4, > tf_trapno = 12, tf_err = 2, tf_eip = -1067170626, tf_cs = 32, > tf_eflags = 66198, tf_esp = 0, tf_ss = 0}) > at /usr/src/sys/i386/i386/trap.c:463 > #6 0xc07160ea in calltrap () at /usr/src/sys/i386/i386/exception.s:138 > #7 0xc06444be in udp_shutdown (so=0xc29e53e4) at atomic.h:146 > #8 0xc0583bf1 in soshutdown (so=0xc29e53e4, how=2) > at /usr/src/sys/kern/uipc_socket.c:1810 > #9 0xc058a07d in shutdown (td=0xc29c3a20, uap=0xd5b3bd04) > at /usr/src/sys/kern/uipc_syscalls.c:1328 > #10 0xc0727af3 in syscall (frame= > {tf_fs = 136970299, tf_es = -1078001605, tf_ds = -1078001605, > tf_edi = 0, tf_esi = 2, tf_ebp = -1077941736, tf_isp = -709640860, > tf_ebx = 671968624, tf_ed---Type to continue, or q > to quit--- > x = 0, tf_ecx = 2, tf_eax = 134, tf_trapno = 22, tf_err = 2, tf_eip = > 673628967, tf_cs = 51, tf_eflags = 582, tf_esp = -1077941764, tf_ss = > 59}) > at /usr/src/sys/i386/i386/trap.c:1015 > #11 0xc071613f in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:191 > #12 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Jul 19 18:36:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5A2E16A4E1 for ; Wed, 19 Jul 2006 18:36:32 +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 EB05243D45 for ; Wed, 19 Jul 2006 18:36:31 +0000 (GMT) (envelope-from davidch@broadcom.com) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 19 Jul 2006 11:36:21 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 8DD8C2B1; Wed, 19 Jul 2006 11:36:21 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 6956A2AF; Wed, 19 Jul 2006 11:36:21 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DZP24839; Wed, 19 Jul 2006 11:36:18 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 7456F69CA5; Wed, 19 Jul 2006 11:36:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Jul 2006 11:36:17 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD903019542C6@NT-IRVA-0750.brcm.ad.broadcom.com> Thread-Topic: Broadcom 5780 Thread-Index: AcarPgm34ZLmCxh2Tn+AEWNG9jjm+gAI9wvg From: "David (Controller AE) Christensen" To: "=?iso-8859-2?Q?Pavol_=C8ierny?=" , freebsd-net@freebsd.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006071907; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230382E34344245373931442E303037342D412D; ENG=IBF; TS=20060719183623; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006071907_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68A0A42F4I851385853-01-01 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Broadcom 5780 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, 19 Jul 2006 18:36:33 -0000 Pavol, The 5780 is functionally equivalent to the 5714. Support for the 5780 = was added to -CURRENT on June 29, 2006 in version 1.135 of if_bge.c. Dave=20 > -----Original Message----- > From: owner-freebsd-net@freebsd.org=20 > [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Pavol Cierny > Sent: Wednesday, July 19, 2006 7:17 AM > To: freebsd-net@freebsd.org > Subject: Broadcom 5780 >=20 > Hello, >=20 > has anyone information about implementing Broadcom 5780 to the bge > driver? >=20 > Just bought a Fujitsu-Siemens RX220 server, and the NICs don't work :( >=20 >=20 >=20 >=20 >=20 > --- > Best regards > Pavol =C8ierny >=20 > _______________________________________________ > 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" >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Wed Jul 19 18:43:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F14A316A4DD for ; Wed, 19 Jul 2006 18:43:07 +0000 (UTC) (envelope-from pavol@cierny.sk) Received: from pavol.slovenska.sk (t0uch.slovenska.sk [212.5.219.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9F6143D6A for ; Wed, 19 Jul 2006 18:43:03 +0000 (GMT) (envelope-from pavol@cierny.sk) Received: (qmail 28233 invoked by uid 98); 19 Jul 2006 18:43:02 -0000 Received: from 87.197.133.63 by pavol.slovenska.sk (envelope-from , uid 82) with qmail-scanner-1.25 (uvscan: v4.4.00/v4786. spamassassin: 3.0.2. Clear:RC:0(87.197.133.63):SA:0(1.0/5.0):. Processed in 0.818698 secs); 19 Jul 2006 18:43:02 -0000 X-Spam-Status: No, hits=1.0 required=5.0 X-Spam-Level: + X-Qmail-Scanner-Mail-From: pavol@cierny.sk via pavol.slovenska.sk X-Qmail-Scanner: 1.25 (Clear:RC:0(87.197.133.63):SA:0(1.0/5.0):. Processed in 0.818698 secs) Received: from unknown (HELO adsl-d63.87-197-133.telecom.sk) (scorp@87.197.133.63) by ns.slovenska.sk with AES256-SHA encrypted SMTP; 19 Jul 2006 18:43:01 -0000 Date: Wed, 19 Jul 2006 20:42:56 +0200 From: =?ISO-8859-2?Q?Pavol_=C8ierny?= X-Mailer: The Bat! (v3.5.30) Professional Organization: WEBY.SLOVENSKA.SK X-Priority: 3 (Normal) Message-ID: <697732381.20060719204256@cierny.sk> To: "David (Controller AE) Christensen" In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD903019542C6@NT-IRVA-0750.brcm.ad.broadcom.com> References: <09BFF2FA5EAB4A45B6655E151BBDD903019542C6@NT-IRVA-0750.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Broadcom 5780 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-2?Q?Pavol_=C8ierny?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 18:43:08 -0000 Thanks for the info. Any chances it get's into STABLE in a near term? Could I use the driver code and compile it in STABLE? :) --- S pozdravom Pavol хierny > Pavol, > The 5780 is functionally equivalent to the 5714. Support for the > 5780 was added to -CURRENT on June 29, 2006 in version 1.135 of > if_bge.c. > Dave >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org >> [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Pavol Cierny >> Sent: Wednesday, July 19, 2006 7:17 AM >> To: freebsd-net@freebsd.org >> Subject: Broadcom 5780 >> >> Hello, >> >> has anyone information about implementing Broadcom 5780 to the bge >> driver? >> >> Just bought a Fujitsu-Siemens RX220 server, and the NICs don't work :( >> >> >> >> >> >> --- >> Best regards >> Pavol хierny >> >> _______________________________________________ >> 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" >> >> > _______________________________________________ > 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 Wed Jul 19 21:44:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F6A416A4DA for ; Wed, 19 Jul 2006 21:44:34 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id C447643D46 for ; Wed, 19 Jul 2006 21:44:33 +0000 (GMT) (envelope-from davidch@broadcom.com) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 19 Jul 2006 14:44:23 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B3C7A2B1; Wed, 19 Jul 2006 14:44:23 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 8DCE62B0; Wed, 19 Jul 2006 14:44:23 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DZP71784; Wed, 19 Jul 2006 14:44:23 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 3498869CA3; Wed, 19 Jul 2006 14:44:23 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Jul 2006 14:44:22 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90301954339@NT-IRVA-0750.brcm.ad.broadcom.com> Thread-Topic: Broadcom 5780 Thread-Index: AcarYzjy2og4DTyJToqEzwLG0yK3VAAGTSaA From: "David (Controller AE) Christensen" To: "=?iso-8859-2?Q?Pavol_=C8ierny?=" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006071911; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230342E34344245413533302E303034422D412D; ENG=IBF; TS=20060719214425; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006071911_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68A0783D0HW58611540-01-01 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: RE: Broadcom 5780 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, 19 Jul 2006 21:44:34 -0000 I don't maintain that driver so I don't know the answer to that. Dave=20 > -----Original Message----- > From: Pavol =C8ierny [mailto:pavol@cierny.sk]=20 > Sent: Wednesday, July 19, 2006 11:43 AM > To: David (Controller AE) Christensen > Cc: freebsd-net@freebsd.org > Subject: Re: Broadcom 5780 >=20 > Thanks for the info. >=20 > Any chances it get's into STABLE in a near term? > Could I use the driver code and compile it in STABLE? :) >=20 > --- > S pozdravom > Pavol =C8ierny >=20 >=20 > > Pavol, >=20 > > The 5780 is functionally equivalent to the 5714. Support for the > > 5780 was added to -CURRENT on June 29, 2006 in version 1.135 of > > if_bge.c. >=20 > > Dave=20 >=20 > >> -----Original Message----- > >> From: owner-freebsd-net@freebsd.org=20 > >> [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Pavol Cierny > >> Sent: Wednesday, July 19, 2006 7:17 AM > >> To: freebsd-net@freebsd.org > >> Subject: Broadcom 5780 > >>=20 > >> Hello, > >>=20 > >> has anyone information about implementing Broadcom 5780 to the bge > >> driver? > >>=20 > >> Just bought a Fujitsu-Siemens RX220 server, and the NICs=20 > don't work :( > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >> --- > >> Best regards > >> Pavol =C8ierny > >>=20 > >> _______________________________________________ > >> 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" > >>=20 > >>=20 >=20 > > _______________________________________________ > > 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" >=20 >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 00:18:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 546C116A4DD for ; Thu, 20 Jul 2006 00:18:01 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB71B43D4C for ; Thu, 20 Jul 2006 00:17:46 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 19 Jul 2006 17:17:48 -0700 X-IronPort-AV: i="4.07,158,1151910000"; d="scan'208"; a="306823478:sNHT24635692" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6K0HkuE008798; Wed, 19 Jul 2006 17:17:46 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6K0Hk79026207; Wed, 19 Jul 2006 17:17:46 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 17:17:46 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 17:17:45 -0700 Message-ID: <44BECBAE.4080007@cisco.com> Date: Wed, 19 Jul 2006 20:17:50 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Worach References: <44BB7A92.9080008@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2006 00:17:45.0968 (UTC) FILETIME=[ECE50F00:01C6AB91] DKIM-Signature: a=rsa-sha1; q=dns; l=542; t=1153354666; x=1154218666; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20SCTP; X=v=3Dcisco.com=3B=20h=3DeFwn8yHouLxYzxwWS0cbAORTlr0=3D; b=wA4IXxNTcamwpNJMmEMG8WgMtwiivggzb0CzKUx2oKGJ9hWQK3qItS2qLhJp3U0mq9HUkAvg rtc33PtF0NvKq97x02kzYsZ2JnNCW08PZQANldglWERNhZk5jN3obmTv; Authentication-Results: sj-dkim-8.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org Subject: Re: SCTP 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, 20 Jul 2006 00:18:01 -0000 Pawel/All: You will now find a new patch available either by clicking: http://www.sctp.org/cvs_diff.July19.bz2 Or you can find it at http://www.sctp.org/ Hanging off the download page has patch-2. This is current to this evening's CVS and fixes the issues Pawel saw.. I still don't like the performance on my SMP machine and think there may be some locking contentions going on.. I will try to look into this tommorrow :-0 R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 02:30:30 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B541216A4DD for ; Thu, 20 Jul 2006 02:30:30 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3561E43D49 for ; Thu, 20 Jul 2006 02:30:30 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k6K2UQmS006865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jul 2006 22:30:27 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k6K2UKSp042678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 22:30:21 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: net@freebsd.org Date: Wed, 19 Jul 2006 22:30:14 -0400 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607192230.14939.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1609/Wed Jul 19 08:13:27 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: dg@dglawrence.com Subject: complement to sendfile()? 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, 20 Jul 2006 02:30:30 -0000 Hello! My program receives data from the socket and writes it to a file -- with the usual read()/write() tedium. Is there anything zero-copying like sendfile() for the socket->file direction? In fact, sendfile's API may allow to use it in any direction, but the manual is quite explicit, that the second (destination) argument must be socket. recvfile()? Thanks! -mi From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 02:51:31 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14A1216A4DD for ; Thu, 20 Jul 2006 02:51:31 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (dsl-230-156.ipns.com [209.210.230.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C6AB43D5F for ; Thu, 20 Jul 2006 02:51:30 +0000 (GMT) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.13.6/8.13.3) with ESMTP id k6K2o4P8095931; Wed, 19 Jul 2006 19:50:04 -0700 (PDT) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.13.6/8.13.3/Submit) id k6K2o3Lt095910; Wed, 19 Jul 2006 19:50:03 -0700 (PDT) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Wed, 19 Jul 2006 19:50:03 -0700 From: "David G. Lawrence" To: Mikhail Teterin Message-ID: <20060720025003.GF924@tnn.dglawrence.com> References: <200607192230.14939.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607192230.14939.mi+mx@aldan.algebra.com> Cc: net@freebsd.org Subject: Re: complement to sendfile()? 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, 20 Jul 2006 02:51:31 -0000 > Hello! > > My program receives data from the socket and writes it to a file -- with the > usual read()/write() tedium. > > Is there anything zero-copying like sendfile() for the socket->file direction? > > In fact, sendfile's API may allow to use it in any direction, but the manual > is quite explicit, that the second (destination) argument must be socket. > > recvfile()? Thanks! sendfile() could be extended to allow arbitrary file descriptor types as the source and destination, but the zero-copy nature of it can only work in the file to socket direction. This is because network buffers can be made out of filesystem buffers (file->network direction), but for the network to file direction network packets arrive non-deterministically. With the right network hardware it would in theory be possible to have the TCP code run on the network card and it could DMA the TCP stream directly into file buffers. If pigs had wings, they could fly. :-) -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 03:17:14 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1788E16A4DA for ; Thu, 20 Jul 2006 03:17:14 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78BE043D55 for ; Thu, 20 Jul 2006 03:17:13 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k6K3H7QH006990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jul 2006 23:17:11 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k6K3H12o043110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 23:17:02 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: "David G. Lawrence" Date: Wed, 19 Jul 2006 23:16:55 -0400 User-Agent: KMail/1.9.1 References: <200607192230.14939.mi+mx@aldan.algebra.com> <20060720025003.GF924@tnn.dglawrence.com> In-Reply-To: <20060720025003.GF924@tnn.dglawrence.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200607192316.56157.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1609/Wed Jul 19 08:13:27 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: net@freebsd.org Subject: Re: complement to sendfile()? 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, 20 Jul 2006 03:17:14 -0000 середа 19 липень 2006 22:50, David G. Lawrence написав: >    sendfile() could be extended to allow arbitrary file descriptor types as > the source and destination, but the zero-copy nature of it can only work > in the file to socket direction. This is because network buffers can be > made out of filesystem buffers (file->network direction), but for the > network to file direction network packets arrive non-deterministically. > With the right network hardware it would in theory be possible to have the > TCP code run on the network card and it could DMA the TCP stream directly > into file buffers. If pigs had wings, they could fly. :-) Ok, so zero-copy may not work, but one-copy would still be better, than the usual two-copy. Am I right? With the usual read/write method, data is read from the network card to kernel's buffers, from there to the application buffer, and from there to the filesystem. That's two copies, no? Having mmap-ed the output file, I could read from the socket directly into the mmap-returned "buffer", but writing via. mmap appears to be implemented pessimally in FreeBSD and breaks horrendously if the output file happens to be accessed via NFS. Thanks! -mi From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 04:36:19 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27C1B16A4DE for ; Thu, 20 Jul 2006 04:36:19 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (dsl-230-156.ipns.com [209.210.230.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACCEE43D5C for ; Thu, 20 Jul 2006 04:36:12 +0000 (GMT) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.13.6/8.13.3) with ESMTP id k6K4Z26O021839; Wed, 19 Jul 2006 21:35:02 -0700 (PDT) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.13.6/8.13.3/Submit) id k6K4Z1Dp021832; Wed, 19 Jul 2006 21:35:01 -0700 (PDT) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Wed, 19 Jul 2006 21:35:01 -0700 From: "David G. Lawrence" To: Mikhail Teterin Message-ID: <20060720043501.GG924@tnn.dglawrence.com> References: <200607192230.14939.mi+mx@aldan.algebra.com> <20060720025003.GF924@tnn.dglawrence.com> <200607192316.56157.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607192316.56157.mi+mx@aldan.algebra.com> Cc: net@freebsd.org Subject: Re: complement to sendfile()? 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, 20 Jul 2006 04:36:19 -0000 > ?????? 19 ?????? 2006 22:50, David G. Lawrence ???????: > > ? ?sendfile() could be extended to allow arbitrary file descriptor types as > > the source and destination, but the zero-copy nature of it can only work > > in the file to socket direction. This is because network buffers can be > > made out of filesystem buffers (file->network direction), but for the > > network to file direction network packets arrive non-deterministically. > > With the right network hardware it would in theory be possible to have the > > TCP code run on the network card and it could DMA the TCP stream directly > > into file buffers. If pigs had wings, they could fly. :-) > > Ok, so zero-copy may not work, but one-copy would still be better, than the > usual two-copy. > > Am I right? With the usual read/write method, data is read from the network > card to kernel's buffers, from there to the application buffer, and from > there to the filesystem. That's two copies, no? Yes, you are right. A few other cool things that could be done with sendfile include: o Full duplex zero-copy socket to socket sends. This could be used on (e.g Squid) proxy servers, for example, to connect two (inside/outside) TCP streams. Plus an "ASYNC" flag to make it all happen in the background inside the kernel (returning immediately to the proxy application). o An "APPEND" flag that allows sendfile to block at the end of file, waiting for more data to be written to it (as long as someone has the file open for append). This would be very useful in some real-time audio/video streaming applications (like the one I'm working on right now :-)). -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 09:32:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 778DE16A500 for ; Thu, 20 Jul 2006 09:32:06 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F56943D53 for ; Thu, 20 Jul 2006 09:32:05 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k6K9Vn7p046543 for ; Thu, 20 Jul 2006 02:31:50 -0700 (PDT) Date: Thu, 20 Jul 2006 18:31:46 +0900 Message-ID: From: gnn@freebsd.org To: freebsd-net@freebsd.org User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.6.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Packet Construction and Protocol Testing... 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, 20 Jul 2006 09:32:06 -0000 Hi, Sorry for the length of this email but I figured I'd get this out early in case there was anyone else who wanted to play with this. I have now gotten out version 0.1 of the Packet Construction Set. This is a set of Python libraries which make writing protocol testing software much easier. Of course, you have to know Python, but many people do, and I favor it strongly over other scripting choices. The Summer of Code student I'm working with has also been using this library, with favorable results. The Source Forge page is here: http://sourceforge.net/projects/pcs and the shar files submitted to get the ports created are now on: http://www.freebsd.org/~gnn/pcs.port.shar http://www.freebsd.org/~gnn/py-pypcap.shar The point of all this is to be able to write better protocol level tests for our network stack. Examples are in the scripts/ and tests/ directories of the package but a quick snippet may give a good idea of what I'm getting at: def test_icmpv4_ping(self): ip = ipv4() ip.version = 4 ip.hlen = 5 ip.tos = 0 ip.length = 84 ip.id = 1 ip.flags = 0 ip.offset = 0 ip.ttl = 33 ip.protocol = IPPROTO_ICMP ip.src = 2130706433 ip.dst = 2130706433 icmp = icmpv4() icmp.type = 8 icmp.code = 0 icmp.cksum = 0 echo = icmpv4echo() echo.id = 32767 echo.seq = 1 lo = localhost() lo.type = 2 packet = Chain([lo, ip, icmp, echo]) input = PcapConnector("lo0") input.setfilter("icmp") output = PcapConnector("lo0") assert (ip != None) out = output.write(packet.bytes, 88) assert (out == 88) This code sends a quick and dirty, ICMPv4 ping packet on localhost. The point of all this is to be able to specify packets easly (see pcs/packets/xxx.py) and then to treat the packet as an object. I intend to write up a paper on this stuff as well. There is currently a simple manual (PDF and LaTeX) in the package. Later, George From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 14:40:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FDDE16A4DA; Thu, 20 Jul 2006 14:40:58 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37A0F43D69; Thu, 20 Jul 2006 14:40:52 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 9CC6E5D44; Thu, 20 Jul 2006 10:40:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8gtimgyFjC1; Thu, 20 Jul 2006 10:40:50 -0400 (EDT) Received: from [192.168.1.251] (pool-68-161-117-245.ny325.east.verizon.net [68.161.117.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 13ACE5D3A; Thu, 20 Jul 2006 10:40:50 -0400 (EDT) Message-ID: <44BF95E9.2030102@mac.com> Date: Thu, 20 Jul 2006 10:40:41 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: gnn@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Packet Construction and Protocol Testing... 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, 20 Jul 2006 14:40:58 -0000 Hi-- gnn@freebsd.org wrote: [ ... ] > The Source Forge page is here: > > http://sourceforge.net/projects/pcs > > and the shar files submitted to get the ports created are now on: > > http://www.freebsd.org/~gnn/pcs.port.shar > http://www.freebsd.org/~gnn/py-pypcap.shar This strikes me as a pretty cool thing, thank you for putting the source out there...given a bit of free time, I'd like to at least test this, if not contribute. [1] :-) The port is missing a dependency on net/py-pcap, BTW, which makes most of the tests fail if one simply downloads the shar file and tries to run them: # cd /tmp/pcs/work/pcs-0.1/tests && python icmpv4test.py ====================================================================== ERROR: Test the underlying __compare__ functionality of the ---------------------------------------------------------------------- Traceback (most recent call last): File "icmpv4test.py", line 81, in test_icmpv4_compare file = PcapConnector("loopping.out") File "../pcs/__init__.py", line 446, in __init__ from pcap import pcap ImportError: No module named pcap [ ... ] -------------- Here's a simple patch for the port Makefile, although maybe someone might want to create a ${PYPCAP} in bsd.python.mk (similar to ${PYXML} and so forth) instead: --- pcs/Makefile.old Thu Jul 20 10:21:45 2006 +++ pcs/Makefile Thu Jul 20 10:33:40 2006 @@ -15,6 +15,8 @@ MAINTAINER= gnn@FreeBSD.org COMMENT= Protocol Construction Set +RUN_DEPENDS= ${PYTHON_SITELIBDIR}/pcap.py:${PORTSDIR}/net/py-pcap + USE_PYTHON= yes USE_PYDISTUTILS= yes USE_PYTHON_PREFIX= yes -- -Chuck [1]: If I could only get net/py-pcap to build, I might be able to do a little more... :-) From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 14:48:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6F1816A4E2; Thu, 20 Jul 2006 14:48:18 +0000 (UTC) (envelope-from arr@watson.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id D850A43D58; Thu, 20 Jul 2006 14:48:16 +0000 (GMT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.13.6/8.13.6) with ESMTP id k6KEmE9t095277; Thu, 20 Jul 2006 10:48:14 -0400 (EDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.13.6/8.13.6/Submit) with ESMTP id k6KEmEfC095274; Thu, 20 Jul 2006 10:48:14 -0400 (EDT) (envelope-from arr@watson.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Thu, 20 Jul 2006 10:48:14 -0400 (EDT) From: "Andrew R. Reiter" To: gnn@freebsd.org In-Reply-To: Message-ID: <20060720104748.R94787@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Packet Construction and Protocol Testing... 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, 20 Jul 2006 14:48:18 -0000 Aren't there already tools for doing this -- libnet / libdnet that both have py wrappers? On Thu, 20 Jul 2006, gnn@freebsd.org wrote: :Hi, : :Sorry for the length of this email but I figured I'd get this out :early in case there was anyone else who wanted to play with this. : :I have now gotten out version 0.1 of the Packet Construction Set. :This is a set of Python libraries which make writing protocol testing :software much easier. Of course, you have to know Python, but many :people do, and I favor it strongly over other scripting choices. The :Summer of Code student I'm working with has also been using this :library, with favorable results. : :The Source Forge page is here: : :http://sourceforge.net/projects/pcs : :and the shar files submitted to get the ports created are now on: : :http://www.freebsd.org/~gnn/pcs.port.shar :http://www.freebsd.org/~gnn/py-pypcap.shar : :The point of all this is to be able to write better protocol level :tests for our network stack. Examples are in the scripts/ and tests/ :directories of the package but a quick snippet may give a good idea of :what I'm getting at: : : def test_icmpv4_ping(self): : ip = ipv4() : ip.version = 4 : ip.hlen = 5 : ip.tos = 0 : ip.length = 84 : ip.id = 1 : ip.flags = 0 : ip.offset = 0 : ip.ttl = 33 : ip.protocol = IPPROTO_ICMP : ip.src = 2130706433 : ip.dst = 2130706433 : : icmp = icmpv4() : icmp.type = 8 : icmp.code = 0 : icmp.cksum = 0 : : echo = icmpv4echo() : echo.id = 32767 : echo.seq = 1 : : lo = localhost() : lo.type = 2 : packet = Chain([lo, ip, icmp, echo]) : : input = PcapConnector("lo0") : input.setfilter("icmp") : : output = PcapConnector("lo0") : assert (ip != None) : : out = output.write(packet.bytes, 88) : assert (out == 88) : :This code sends a quick and dirty, ICMPv4 ping packet on localhost. :The point of all this is to be able to specify packets easly (see :pcs/packets/xxx.py) and then to treat the packet as an object. : :I intend to write up a paper on this stuff as well. There is :currently a simple manual (PDF and LaTeX) in the package. : :Later, :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" : : -- arr@watson.org From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 16:06:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D3C616A4DF for ; Thu, 20 Jul 2006 16:06:16 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from mail.logital.it (85-18-201-99.ip.fastwebnet.it [85.18.201.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D12F43D77 for ; Thu, 20 Jul 2006 16:06:10 +0000 (GMT) (envelope-from aturetta@commit.it) Received: from [192.168.42.11] ([192.168.42.11]) (authenticated bits=0) by mail.logital.it (8.13.7/8.13.7) with ESMTP id k6KG67J2048159 for ; Thu, 20 Jul 2006 18:06:08 +0200 (CEST) (envelope-from aturetta@commit.it) Message-ID: <44BFA9EA.8070707@commit.it> Date: Thu, 20 Jul 2006 18:06:02 +0200 From: Angelo Turetta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on mail.logital.it X-Virus-Status: Clean Subject: Query for current status of TCP optimization project 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, 20 Jul 2006 16:06:16 -0000 I've not been able to find follow-up reports on the project referenced at: http://people.freebsd.org/~andre/tcpoptimization.html Has this been merged to the main CVS tree? Or is the result visible in some P4 branch? Thanks, Angelo Turetta - Italy From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 16:59:21 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4768D16A4DE for ; Thu, 20 Jul 2006 16:59:20 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ECDD43D4C for ; Thu, 20 Jul 2006 16:59:20 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.66]) by a50.ironport.com with ESMTP; 20 Jul 2006 09:59:19 -0700 Message-ID: <44BFB667.60106@elischer.org> Date: Thu, 20 Jul 2006 09:59:19 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David G. Lawrence" References: <200607192230.14939.mi+mx@aldan.algebra.com> <20060720025003.GF924@tnn.dglawrence.com> In-Reply-To: <20060720025003.GF924@tnn.dglawrence.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mikhail Teterin , net@freebsd.org Subject: Re: complement to sendfile()? 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, 20 Jul 2006 16:59:21 -0000 David G. Lawrence wrote: >>Hello! >> >>My program receives data from the socket and writes it to a file -- with the >>usual read()/write() tedium. >> >>Is there anything zero-copying like sendfile() for the socket->file direction? >> >>In fact, sendfile's API may allow to use it in any direction, but the manual >>is quite explicit, that the second (destination) argument must be socket. >> >>recvfile()? Thanks! >> >> > > sendfile() could be extended to allow arbitrary file descriptor types as >the source and destination, but the zero-copy nature of it can only work >in the file to socket direction. This is because network buffers can be made >out of filesystem buffers (file->network direction), but for the network to >file direction network packets arrive non-deterministically. With the right >network hardware it would in theory be possible to have the TCP code run >on the network card and it could DMA the TCP stream directly into file >buffers. If pigs had wings, they could fly. :-) > > We used to do something like this in BSD4.3 (not FreeBSD 4.3) in 1991, but we used a propriatary filesystem and a proprietary protocol that knew each other's data types. >-DG > >David G. Lawrence >President >Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 >The FreeBSD Project - http://www.freebsd.org >Pave the road of life with opportunities. >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 18:11:46 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CA0B16A4DA for ; Thu, 20 Jul 2006 18:11:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1796F43D53 for ; Thu, 20 Jul 2006 18:11:45 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id c63so880767pyc for ; Thu, 20 Jul 2006 11:11:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R4reoWroUOvLgFaxm/REdfYa6zvOAybozS2hnAG8UqM4P5n2Oofqow8TTM84o58dtxZfSPj26543+8YSdkPQlHmouSu7QxLBzhYqRgU6r1ugiRA9D42VVJUcwhu7XNMkecCCD6mOAFU3RAQdntrunHpEpCfgVeWSr7CwrUAXyFY= Received: by 10.35.41.12 with SMTP id t12mr1493022pyj; Thu, 20 Jul 2006 11:11:45 -0700 (PDT) Received: by 10.35.119.14 with HTTP; Thu, 20 Jul 2006 11:11:44 -0700 (PDT) Message-ID: <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com> Date: Thu, 20 Jul 2006 11:11:44 -0700 From: "Jack Vogel" To: "Julian Elischer" In-Reply-To: <44BFB667.60106@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200607192230.14939.mi+mx@aldan.algebra.com> <20060720025003.GF924@tnn.dglawrence.com> <44BFB667.60106@elischer.org> Cc: Mikhail Teterin , jfvogel@gmail.com, "David G. Lawrence" , net@freebsd.org Subject: Re: complement to sendfile()? 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, 20 Jul 2006 18:11:46 -0000 We, myself and Prafulla Deuskar at Intel LAD, have a driver and stack changes that support Intel's new I/OAT DMA hardware. This is a DMA engine in the chipset. There is potential to use the hardware in a number of ways, what we have right now is a receive-side async dma assist from tcp_input() to soreceive(). The engine copies from the mbufs direct to user buffers asynchronously, and only requires the client process to be woken when its buffers are full. The stack changes to support this are relatively small, mainly we need to pin user buffers and provide a pointer down to the stack in order to process them, and of course the core driver for the engine. Similar work was done for Linux and is in the 2.6.18 kernel. We see as much as a 20% improvement in CPU utilization when doing a sustained iperf test. We are hoping to get this code into CURRENT soon if there is interest. Cheers, Jack On 7/20/06, Julian Elischer wrote: > David G. Lawrence wrote: > > >>Hello! > >> > >>My program receives data from the socket and writes it to a file -- with the > >>usual read()/write() tedium. > >> > >>Is there anything zero-copying like sendfile() for the socket->file direction? > >> > >>In fact, sendfile's API may allow to use it in any direction, but the manual > >>is quite explicit, that the second (destination) argument must be socket. > >> > >>recvfile()? Thanks! > >> > >> > > > > sendfile() could be extended to allow arbitrary file descriptor types as > >the source and destination, but the zero-copy nature of it can only work > >in the file to socket direction. This is because network buffers can be made > >out of filesystem buffers (file->network direction), but for the network to > >file direction network packets arrive non-deterministically. With the right > >network hardware it would in theory be possible to have the TCP code run > >on the network card and it could DMA the TCP stream directly into file > >buffers. If pigs had wings, they could fly. :-) > > > > > > > We used to do something like this in BSD4.3 (not FreeBSD 4.3) in 1991, > but we used > a propriatary filesystem and a proprietary protocol that knew each > other's data types. > > >-DG > > > >David G. Lawrence > >President > >Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 > >The FreeBSD Project - http://www.freebsd.org > >Pave the road of life with opportunities. From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 18:21:58 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2293616A4DA; Thu, 20 Jul 2006 18:21:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33D8743D49; Thu, 20 Jul 2006 18:21:57 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.66]) by a50.ironport.com with ESMTP; 20 Jul 2006 11:21:53 -0700 Message-ID: <44BFC9C0.6030606@elischer.org> Date: Thu, 20 Jul 2006 11:21:52 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jack Vogel References: <200607192230.14939.mi+mx@aldan.algebra.com> <20060720025003.GF924@tnn.dglawrence.com> <44BFB667.60106@elischer.org> <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com> In-Reply-To: <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mikhail Teterin , "David G. Lawrence" , net@freebsd.org Subject: Re: complement to sendfile()? 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, 20 Jul 2006 18:21:58 -0000 Jack Vogel wrote: > We, myself and Prafulla Deuskar at Intel LAD, have a driver and stack > changes that support Intel's new I/OAT DMA hardware. This is a > DMA engine in the chipset. shades of the old PC with the built in DMA on hte motherboard.... :-) > There is potential to use the hardware > in a number of ways, what we have right now is a receive-side > async dma assist from tcp_input() to soreceive(). The engine > copies from the mbufs direct to user buffers asynchronously, > and only requires the client process to be woken when its > buffers are full. The stack changes to support this are relatively > small, mainly we need to pin user buffers and provide a pointer > down to the stack in order to process them, and of course the > core driver for the engine. > > Similar work was done for Linux and is in the 2.6.18 kernel. > > We see as much as a 20% improvement in CPU utilization > when doing a sustained iperf test. > > We are hoping to get this code into CURRENT soon if there > is interest. > > Cheers, > > Jack > > > > On 7/20/06, Julian Elischer wrote: > >> David G. Lawrence wrote: >> >> >>Hello! >> >> >> >>My program receives data from the socket and writes it to a file -- >> with the >> >>usual read()/write() tedium. >> >> >> >>Is there anything zero-copying like sendfile() for the socket->file >> direction? >> >> >> >>In fact, sendfile's API may allow to use it in any direction, but >> the manual >> >>is quite explicit, that the second (destination) argument must be >> socket. >> >> >> >>recvfile()? Thanks! >> >> >> >> >> > >> > sendfile() could be extended to allow arbitrary file descriptor >> types as >> >the source and destination, but the zero-copy nature of it can only >> work >> >in the file to socket direction. This is because network buffers can >> be made >> >out of filesystem buffers (file->network direction), but for the >> network to >> >file direction network packets arrive non-deterministically. With >> the right >> >network hardware it would in theory be possible to have the TCP code >> run >> >on the network card and it could DMA the TCP stream directly into file >> >buffers. If pigs had wings, they could fly. :-) >> > >> > >> >> >> We used to do something like this in BSD4.3 (not FreeBSD 4.3) in 1991, >> but we used >> a propriatary filesystem and a proprietary protocol that knew each >> other's data types. >> >> >-DG >> > >> >David G. Lawrence >> >President >> >Download Technologies, Inc. - http://www.downloadtech.com - (866) >> 399 8500 >> >The FreeBSD Project - http://www.freebsd.org >> >Pave the road of life with opportunities. > From owner-freebsd-net@FreeBSD.ORG Thu Jul 20 19:39:53 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B7DF16A4DE; Thu, 20 Jul 2006 19:39:53 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3E1043D46; Thu, 20 Jul 2006 19:39:52 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k6KJdhx5009894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jul 2006 15:39:43 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k6KJdbXc085538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jul 2006 15:39:38 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: "Jack Vogel" Date: Thu, 20 Jul 2006 15:39:30 -0400 User-Agent: KMail/1.9.1 References: <200607192230.14939.mi+mx@aldan.algebra.com> <44BFB667.60106@elischer.org> <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com> In-Reply-To: <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200607201539.31591.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1610/Thu Jul 20 02:32:33 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: net@freebsd.org, Julian Elischer , "David G. Lawrence" Subject: Re: complement to sendfile()? 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, 20 Jul 2006 19:39:53 -0000 четвер 20 липень 2006 14:11, Jack Vogel написав: > Similar work was done for Linux and is in the 2.6.18 kernel. > > We see as much as a 20% improvement in CPU utilization > when doing a sustained iperf test. > > We are hoping to get this code into CURRENT soon if there > is interest. There is. I'm using an Intel's network card, albeit inside an Opteron-based server :-) -mi From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 02:47:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8775E16A4DE for ; Fri, 21 Jul 2006 02:47:17 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2156C43D45 for ; Fri, 21 Jul 2006 02:47:17 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k6L2lAKv078417; Thu, 20 Jul 2006 19:47:10 -0700 (PDT) Date: Fri, 21 Jul 2006 11:10:58 +0900 Message-ID: From: gnn@freebsd.org To: Chuck Swiger In-Reply-To: <44BF95E9.2030102@mac.com> References: <44BF95E9.2030102@mac.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.6.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Packet Construction and Protocol Testing... 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, 21 Jul 2006 02:47:17 -0000 At Thu, 20 Jul 2006 10:40:41 -0400, Chuck Swiger wrote: > This strikes me as a pretty cool thing, thank you for putting the source out > there...given a bit of free time, I'd like to at least test this, if not > contribute. [1] :-) Thanks :-) > The port is missing a dependency on net/py-pcap, BTW, which makes most of the > tests fail if one simply downloads the shar file and tries to run them: > For now I wanted to make them separate though the documentation points out that you can't use the PCAP connector without py-pypcap. I may add the dependency in a future release. Thanks, for the patch! > [1]: If I could only get net/py-pcap to build, I might be able to do a little > more... :-) You only need net/py-pypcap, but if that's what you meant please let me know what the build problem is. Later, George From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 02:47:28 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8652E16A689 for ; Fri, 21 Jul 2006 02:47:28 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D98D43D55 for ; Fri, 21 Jul 2006 02:47:27 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k6L2l4T5002390; Thu, 20 Jul 2006 19:47:09 -0700 (PDT) Date: Fri, 21 Jul 2006 11:05:40 +0900 Message-ID: From: gnn@freebsd.org To: "Andrew R. Reiter" In-Reply-To: <20060720104748.R94787@fledge.watson.org> References: <20060720104748.R94787@fledge.watson.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.6.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Packet Construction and Protocol Testing... 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, 21 Jul 2006 02:47:28 -0000 At Thu, 20 Jul 2006 10:48:14 -0400 (EDT), Andrew R. Reiter wrote: > > > Aren't there already tools for doing this -- libnet / libdnet that both > have py wrappers? I looked at all those, and more, but they miss an important point. That is, in PCS you define a packet like this (from pcs/packets/ipv4.py): def __init__(self, bytes = None): """ define the fields of an IPv4 packet, from RFC 791 This version does not include options.""" version = pcs.Field("version", 4, default = 4) hlen = pcs.Field("hlen", 4) tos = pcs.Field("tos", 8) length = pcs.Field("length", 16) id = pcs.Field("id", 16) flags = pcs.Field("flags", 3) offset = pcs.Field("offset", 13) ttl = pcs.Field("ttl", 8, default = 64) protocol = pcs.Field("protocol", 8) checksum = pcs.Field("checksum", 16) src = pcs.Field("src", 32) dst = pcs.Field("dst", 32) pcs.Packet.__init__(self, [version, hlen, tos, length, id, flags, offset, ttl, protocol, checksum, src, dst], bytes = bytes) # Description MUST be set after the PCS layer init self.description = "IPv4" which creates a properties in the object to hold the named field. This is what makes it possible to do: ip = ipv4() ip.ttl = 64 ip.src = inet_pton("128.32.1.1") etc. in your program. Also note that the bit lengths can be odd, such as getting the 13 bit offset field. So, PCS is doing all the packing and unpacking of the bytes for you. I intend to put in automatic bounds checking in an upcoming version. There is much more about this in the documentation, docs/pcs.pdf in the package. Future versions will allow import/export to various formats as well, such as XML, so that defining packets will be even easier as will writing tools. Later, George From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 08:13:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F73616A4DE for ; Fri, 21 Jul 2006 08:13:24 +0000 (UTC) (envelope-from trashy_bumper@yahoo.com) Received: from web36304.mail.mud.yahoo.com (web36304.mail.mud.yahoo.com [209.191.84.234]) by mx1.FreeBSD.org (Postfix) with SMTP id B427D43D49 for ; Fri, 21 Jul 2006 08:13:23 +0000 (GMT) (envelope-from trashy_bumper@yahoo.com) Received: (qmail 13051 invoked by uid 60001); 21 Jul 2006 08:13:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LCSoDNYzrMfcJodBfPzIY2nw3bH/6OFjB1dorcMnHVz3F3NGaYa+9uGKmZf0om6SmKHo7V39Y1RYJ0wGaRYLqT7xR5zEFKd8q6zmvQnqLTRUuINJhe+0qL0Lz0y6gGFMqwBAZPvFix2/UfUhbDXBIO6HgeIgKTZKoLSv/b8EymY= ; Message-ID: <20060721081323.13049.qmail@web36304.mail.mud.yahoo.com> Received: from [213.227.200.244] by web36304.mail.mud.yahoo.com via HTTP; Fri, 21 Jul 2006 01:13:23 PDT Date: Fri, 21 Jul 2006 01:13:23 -0700 (PDT) From: Nash Nipples To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Packet Construction and Protocol Testing... 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, 21 Jul 2006 08:13:24 -0000 Okay, why not make it in C on the day 2 if not on the day 1 because u will still want to do that on day x.? plus the core point about constructing dirty packets is to gain understanding of the process. i mean its very important to understand how do u form a binary stream with a set of consequent decimals and read it back in. saying (in 1 bit octals) 324 303 262 241 002 000 004 000 000 000 000 000 000 000 000 000 may mean nothing to u, but NOT to the interface driver or whichever thing handles the socket writes (which on my opinion could be just a hook in a driver event table, but yea, i dont know what process handles the socket(2) write(2) system call) because somehow its a cut off in the manual. "DESCRIPTION The socket() system call creates an endpoint for communication and returns a descriptor." what to? is this a bug in freedom of information design? if not that is a good challenge and i accept it but creating tools people "do not know how" but "let me try" is like giving an icecream to a dog. dont let it lose on the carpet right? Just thought to give u a few ideas. thats it Nash gnn@freebsd.org wrote: At Thu, 20 Jul 2006 10:40:41 -0400, Chuck Swiger wrote: > This strikes me as a pretty cool thing, thank you for putting the source out > there...given a bit of free time, I'd like to at least test this, if not > contribute. [1] :-) Thanks :-) > The port is missing a dependency on net/py-pcap, BTW, which makes most of the > tests fail if one simply downloads the shar file and tries to run them: > For now I wanted to make them separate though the documentation points out that you can't use the PCAP connector without py-pypcap. I may add the dependency in a future release. Thanks, for the patch! > [1]: If I could only get net/py-pcap to build, I might be able to do a little > more... :-) You only need net/py-pypcap, but if that's what you meant please let me know what the build problem is. Later, 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" --------------------------------- See the all-new, redesigned Yahoo.com. Check it out. --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 08:23:55 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F20D16A4DF for ; Fri, 21 Jul 2006 08:23:55 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88A1743D45 for ; Fri, 21 Jul 2006 08:23:53 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k6L8NDdq088395; Fri, 21 Jul 2006 11:23:13 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Fri, 21 Jul 2006 11:23:13 +0300 (EEST) From: Dmitry Pryanishnikov To: Jack Vogel In-Reply-To: <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com> Message-ID: <20060721111838.M77932@atlantis.atlantis.dp.ua> References: <200607192230.14939.mi+mx@aldan.algebra.com> <20060720025003.GF924@tnn.dglawrence.com> <44BFB667.60106@elischer.org> <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mikhail Teterin , net@freebsd.org, Julian Elischer , "David G. Lawrence" Subject: Re: complement to sendfile()? 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, 21 Jul 2006 08:23:55 -0000 Hello! On Thu, 20 Jul 2006, Jack Vogel wrote: > We, myself and Prafulla Deuskar at Intel LAD, have a driver and stack > changes that support Intel's new I/OAT DMA hardware. This is a > DMA engine in the chipset. There is potential to use the hardware > > We are hoping to get this code into CURRENT soon if there > is interest. Sure there is an interest, spare CPU cycles are never superfluous in production environment! What hardware (NICs/chipsets) supports this I/OAT DMA engine? Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 08:44:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3898416A4DA for ; Fri, 21 Jul 2006 08:44:20 +0000 (UTC) (envelope-from ronald.hasudungan@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id C382943D46 for ; Fri, 21 Jul 2006 08:44:19 +0000 (GMT) (envelope-from ronald.hasudungan@gmail.com) Received: by wr-out-0506.google.com with SMTP id 36so335122wra for ; Fri, 21 Jul 2006 01:44:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Z8Ls841mO4AnaaGGN4SgXI3Ht5jMzq2hLHWvZVcllLHBDUtuafMKfkjScdVr60+EZ1fWzDCSIoKcL7uj1jrUEmOM5U4cYTZ+XxQWfT1vHsJPDvL3WM+0VKhw60Dni0jFsC28pl3hrQe5C14ZPMwlnbQT+hWVBjo4WF2HqtfMex8= Received: by 10.65.219.2 with SMTP id w2mr386043qbq; Fri, 21 Jul 2006 01:44:19 -0700 (PDT) Received: by 10.64.253.8 with HTTP; Fri, 21 Jul 2006 01:44:19 -0700 (PDT) Message-ID: Date: Fri, 21 Jul 2006 15:44:19 +0700 From: "Ronald Hasudungan Simanjuntak" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: squid ipv6 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, 21 Jul 2006 08:44:20 -0000 Hello all.... Is anybody here have experience build and install squid to work in dual stack (ipv6 & ipv4) mode ? -regards- From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 15:47:31 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA37F16A4DD for ; Fri, 21 Jul 2006 15:47:31 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6D9943D5F for ; Fri, 21 Jul 2006 15:47:29 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so1252602pyb for ; Fri, 21 Jul 2006 08:47:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eEcD04bX1Qaz28ZN/AJOssFcsxs8Xm21ZomLMo5t6gRHpiv0fbvBsAbQW1r9dWqYS5WfsoyaeOo3HdVbL8G6FzfpRL2/XtX+CMVbboqamDiAiaYw/eKVVgqmLCszixz9KkNr3KawoW64DfJqIWi3AvpXxpYumfI4G3GoZ79D90A= Received: by 10.35.127.7 with SMTP id e7mr1389696pyn; Fri, 21 Jul 2006 08:47:28 -0700 (PDT) Received: by 10.35.119.14 with HTTP; Fri, 21 Jul 2006 08:47:28 -0700 (PDT) Message-ID: <2a41acea0607210847m15a77af8n5c2cf10007b4609f@mail.gmail.com> Date: Fri, 21 Jul 2006 08:47:28 -0700 From: "Jack Vogel" To: "Dmitry Pryanishnikov" In-Reply-To: <20060721111838.M77932@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200607192230.14939.mi+mx@aldan.algebra.com> <20060720025003.GF924@tnn.dglawrence.com> <44BFB667.60106@elischer.org> <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com> <20060721111838.M77932@atlantis.atlantis.dp.ua> Cc: Mikhail Teterin , net@freebsd.org, Julian Elischer , "David G. Lawrence" Subject: Re: complement to sendfile()? 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, 21 Jul 2006 15:47:32 -0000 On 7/21/06, Dmitry Pryanishnikov wrote: > > Hello! > > On Thu, 20 Jul 2006, Jack Vogel wrote: > > We, myself and Prafulla Deuskar at Intel LAD, have a driver and stack > > changes that support Intel's new I/OAT DMA hardware. This is a > > DMA engine in the chipset. There is potential to use the hardware > > > > We are hoping to get this code into CURRENT soon if there > > is interest. > > Sure there is an interest, spare CPU cycles are never superfluous > in production environment! What hardware (NICs/chipsets) supports this > I/OAT DMA engine? > > Sincerely, Dmitry Its part of the Intel Blackford chipset, so for instance Supermicro has a motherboard and servers with it. I havent looked at what OEMs have systems available now, but I imagine most the big OEMs will have systems with this chipset and Woodcrest CPUs soon. Cheeers, Jack From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 15:50:00 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24F7A16A4DE for ; Fri, 21 Jul 2006 15:50:00 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AE8043D64 for ; Fri, 21 Jul 2006 15:49:53 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so1253457pyb for ; Fri, 21 Jul 2006 08:49:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cgDuxUnqJaDYKCgfRSguU4BcBymirUOtF3ZLMgpBsq7i5/HnR/hD9lMZEfB4wTEkt+Xen77XV13sTWoEB+f/qyrYFHFDJUiv4xIxaSrwzP/d/MLmH+7dMCE8V3rnYRMkyB9Lu0IYgPynjTOdpA4v0VCQ5bb35x64hYtdpefYFm8= Received: by 10.35.51.6 with SMTP id d6mr1442382pyk; Fri, 21 Jul 2006 08:49:53 -0700 (PDT) Received: by 10.35.119.14 with HTTP; Fri, 21 Jul 2006 08:49:52 -0700 (PDT) Message-ID: <2a41acea0607210849k6ad6693ey1d683910d81e9d41@mail.gmail.com> Date: Fri, 21 Jul 2006 08:49:52 -0700 From: "Jack Vogel" To: "Dmitry Pryanishnikov" In-Reply-To: <20060721111838.M77932@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200607192230.14939.mi+mx@aldan.algebra.com> <20060720025003.GF924@tnn.dglawrence.com> <44BFB667.60106@elischer.org> <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com> <20060721111838.M77932@atlantis.atlantis.dp.ua> Cc: Mikhail Teterin , net@freebsd.org, Julian Elischer , "David G. Lawrence" Subject: Re: complement to sendfile()? 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, 21 Jul 2006 15:50:00 -0000 On 7/21/06, Dmitry Pryanishnikov wrote: > > Hello! > > On Thu, 20 Jul 2006, Jack Vogel wrote: > > We, myself and Prafulla Deuskar at Intel LAD, have a driver and stack > > changes that support Intel's new I/OAT DMA hardware. This is a > > DMA engine in the chipset. There is potential to use the hardware > > > > We are hoping to get this code into CURRENT soon if there > > is interest. > > Sure there is an interest, spare CPU cycles are never superfluous > in production environment! What hardware (NICs/chipsets) supports this > I/OAT DMA engine? Oh, and there is nothing changed in the NIC and its driver, this is just stack changes together with the chipset dma driver I wrote, so any NIC on a system will benefit. Jack From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 16:23:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E570716A4DE; Fri, 21 Jul 2006 16:23:15 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 554FE43D46; Fri, 21 Jul 2006 16:23:15 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id A564F5DD8; Fri, 21 Jul 2006 12:23:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8DO96BBptb2; Fri, 21 Jul 2006 12:23:10 -0400 (EDT) Received: from [199.103.21.238] (pan.codefab.com [199.103.21.238]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 882C15D44; Fri, 21 Jul 2006 12:23:10 -0400 (EDT) In-Reply-To: References: <44BF95E9.2030102@mac.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3724C08A-4ADD-4294-8953-A4ADA2326577@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Fri, 21 Jul 2006 12:23:06 -0400 To: gnn@freebsd.org X-Mailer: Apple Mail (2.752.2) Cc: freebsd-net@freebsd.org Subject: Re: Packet Construction and Protocol Testing... 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, 21 Jul 2006 16:23:16 -0000 On Jul 20, 2006, at 10:10 PM, gnn@freebsd.org wrote: >> [1]: If I could only get net/py-pcap to build, I might be able to >> do a little >> more... :-) > > You only need net/py-pypcap, but if that's what you meant please let > me know what the build problem is. Interesting-- basicly, your tests commonly use a construct like "from pcap import pcap", which isn't working here with either port: 35-pi# cd /usr/ports/net/py-pcap 36-pi# make ===> Extracting for py24-pcap-0.5 => MD5 Checksum OK for pylibpcap-0.5.tar.gz. => SHA256 Checksum OK for pylibpcap-0.5.tar.gz. => MD5 Checksum OK for pylibpcap-doc.i.1.4. => SHA256 Checksum OK for pylibpcap-doc.i.1.4. install -o root -g wheel -m 444 /usr/ports/distfiles/pylibpcap-doc.i. 1.4 /usr/ports/net/py-pcap/work/pylibpcap-0.5/doc.i ===> Patching for py24-pcap-0.5 ===> Applying FreeBSD patches for py24-pcap-0.5 ===> py24-pcap-0.5 depends on executable: swig - found ===> py24-pcap-0.5 depends on file: /usr/local/bin/python - found ===> Configuring for py24-pcap-0.5 /usr/local/lib/python2.4/distutils/dist.py:222: UserWarning: 'licence' distribution option is deprecated; use 'license' warnings.warn(msg) running config ===> Building for py24-pcap-0.5 /usr/local/lib/python2.4/distutils/dist.py:222: UserWarning: 'licence' distribution option is deprecated; use 'license' warnings.warn(msg) running build running build_ext building '_pcapmodule' extension generating constants.c from mk-constants.py swig -python -shadow -ISWIG -o pcap.c pcap.i pcap.i:72: Warning(124): Specifying the language name in %typemap is deprecated - use #ifdef SWIG instead. pcap.i:77: Warning(124): Specifying the language name in %typemap is deprecated - use #ifdef SWIG instead. pcap.i:82: Warning(124): Specifying the language name in %typemap is deprecated - use #ifdef SWIG instead. creating build creating build/temp.freebsd-5.5-PRERELEASE-i386-2.4 cc -fno-strict-aliasing -DNDEBUG -O -pipe -march=pentium - D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 -O -pipe - march=pentium -fPIC -DSWIG_COBJECT_TYPES -I/usr/local/include/ python2.4 -c pcap.c -o build/temp.freebsd-5.5-PRERELEASE-i386-2.4/pcap.o pcap.c: In function `init_pcap': pcap.c:4220: warning: passing arg 2 of `SWIG_Python_InstallConstants' discards qualifiers from pointer target type pcap.c:4230: warning: passing arg 3 of `PyModule_AddStringConstant' discards qualifiers from pointer target type cc -fno-strict-aliasing -DNDEBUG -O -pipe -march=pentium - D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 -O -pipe - march=pentium -fPIC -DSWIG_COBJECT_TYPES -I/usr/local/include/ python2.4 -c pcap_interface.c -o build/temp.freebsd-5.5-PRERELEASE- i386-2.4/pcap_interface.o cc -fno-strict-aliasing -DNDEBUG -O -pipe -march=pentium - D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 -O -pipe - march=pentium -fPIC -DSWIG_COBJECT_TYPES -I/usr/local/include/ python2.4 -c exception.c -o build/temp.freebsd-5.5-PRERELEASE- i386-2.4/exception.o cc -fno-strict-aliasing -DNDEBUG -O -pipe -march=pentium - D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 -O -pipe - march=pentium -fPIC -DSWIG_COBJECT_TYPES -I/usr/local/include/ python2.4 -c error.c -o build/temp.freebsd-5.5-PRERELEASE-i386-2.4/ error.o creating build/lib.freebsd-5.5-PRERELEASE-i386-2.4 cc -shared -pthread -O -pipe -march=pentium build/temp.freebsd-5.5- PRERELEASE-i386-2.4/pcap.o build/temp.freebsd-5.5-PRERELEASE-i386-2.4/ pcap_interface.o build/temp.freebsd-5.5-PRERELEASE-i386-2.4/ exception.o build/temp.freebsd-5.5-PRERELEASE-i386-2.4/error.o -lpcap -o build/lib.freebsd-5.5-PRERELEASE-i386-2.4/_pcapmodule.so running build_py copying pcap.py -> build/lib.freebsd-5.5-PRERELEASE-i386-2.4 5.61s real 4.65s user 0.86s system 98% 37-pi# make install ===> Installing for py24-pcap-0.5 ===> py24-pcap-0.5 depends on file: /usr/local/bin/python - found ===> Generating temporary packing list ===> Checking if net/py-pcap already installed /usr/local/lib/python2.4/distutils/dist.py:222: UserWarning: 'licence' distribution option is deprecated; use 'license' warnings.warn(msg) running install running build running build_ext running build_py running install_lib copying build/lib.freebsd-5.5-PRERELEASE-i386-2.4/_pcapmodule.so -> / usr/local/lib/python2.4/site-packages copying build/lib.freebsd-5.5-PRERELEASE-i386-2.4/pcap.py -> /usr/ local/lib/python2.4/site-packages byte-compiling /usr/local/lib/python2.4/site-packages/pcap.py to pcap.pyc writing byte-compilation script '/tmp/tmpv6RYOP.py' /usr/local/bin/python -O /tmp/tmpv6RYOP.py removing /tmp/tmpv6RYOP.py ===> Registering installation for py24-pcap-0.5 38-pi# python /usr/ports/net/py-pcap Python 2.4.3 (#2, May 15 2006, 15:15:09) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import pcap >>> from pcap import pcap Traceback (most recent call last): File "", line 1, in ? ImportError: cannot import name pcap >>> 39-pi# make deinstall ===> Deinstalling for net/py-pcap ===> Deinstalling py24-pcap-0.5 40-pi# cd ../py-pypcap 41-pi# make deinstall ===> Deinstalling for net/py-pypcap ===> py24-pypcap not installed, skipping 42-pi# make install ===> Installing for py24-pypcap-1.1 ===> py24-pypcap-1.1 depends on file: /usr/local/bin/python - found ===> Generating temporary packing list ===> Checking if net/py-pypcap already installed python setup.py install running install running build running build_ext running install_lib copying build/lib.freebsd-5.5-PRERELEASE-i386-2.4/pcap.so -> /usr/ local/lib/python2.4/site-packages ===> Registering installation for py24-pypcap-1.1 43-pi# python Python 2.4.3 (#2, May 15 2006, 15:15:09) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import pcap Traceback (most recent call last): File "", line 1, in ? ImportError: /usr/local/lib/python2.4/site-packages/pcap.so: Undefined symbol "pcap_inject" >>> 44-pi# grep -l pcap_inject /usr/lib/libpcap* 45-pi# nm -g /usr/local/lib/python2.4/site-packages/pcap.so | grep pcap_inject U pcap_inject Thanks for your time, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 17:14:27 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A8F416A513 for ; Fri, 21 Jul 2006 17:14:27 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24B1D43D70 for ; Fri, 21 Jul 2006 17:14:16 +0000 (GMT) (envelope-from brett@lariat.net) Received: from Anne (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id LAA02160 for ; Fri, 21 Jul 2006 11:14:13 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <7.0.1.0.2.20060721105813.0971ae90@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 21 Jul 2006 11:13:47 -0600 To: net@freebsd.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Multiple NAT router 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, 21 Jul 2006 17:14:27 -0000 I have an application in which I'd like a FreeBSD router to have multiple, isolated LANS attached to it, each with the same address space. The FreeBSD box would take the place of multiple NAT routers. For example, I might want to have three internal Ethernet interfaces on the FreeBSD box. Each would be connected to a LAN whose internal addresses are 192.168.0.0/24. The FreeBSD box would do NAT for all of them, and of course they could not "see" one another. The alternatives, of course, would be to install multiple NAT routers -- which would be a waste -- or to number the LANs differently. But the organization for which I'm doing this wants everything about each LAN to be absolutely standard (printers at the same static addresses, etc.) so that their IT guys can walk in and know exactly how everything's numbered. Is it possible to do a "hydra headed" router such as this with FreeBSD? I'm not sure that FreeBSD's natd is equipped to sort incoming packets for multiple, identically numbered LANs properly, because it would have to remember interface names as well as addresses. Also, there would be the question of how one would connect inward to the machines on the LANs, since "ping 192.168.0.100" would be ambiguous. (Perhaps one could do it from a jail. In fact, perhaps the virtual NAT routers could be set up in jails....) --Brett Glass From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 17:42:28 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD0EB16A4E0 for ; Fri, 21 Jul 2006 17:42:28 +0000 (UTC) (envelope-from clemun@gmail.com) Received: from gruik.clem1.be (clem1.be [81.56.211.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A16843D45 for ; Fri, 21 Jul 2006 17:42:26 +0000 (GMT) (envelope-from clemun@gmail.com) Received: from [192.168.2.5] (pouik.clem1.be [192.168.2.5]) by gruik.clem1.be (8.13.5.20060308/8.13.4) with ESMTP id k6LHgtDV006150 for ; Fri, 21 Jul 2006 19:42:56 +0200 (CEST) Message-ID: <44C11242.9090300@gmail.com> Date: Fri, 21 Jul 2006 19:43:30 +0200 From: =?ISO-8859-1?Q?Cl=E9ment_Lecigne?= User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <44BF95E9.2030102@mac.com> <3724C08A-4ADD-4294-8953-A4ADA2326577@mac.com> In-Reply-To: <3724C08A-4ADD-4294-8953-A4ADA2326577@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Packet Construction and Protocol Testing... 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, 21 Jul 2006 17:42:28 -0000 Hey, Charles Swiger wrote: > On Jul 20, 2006, at 10:10 PM, gnn@freebsd.org wrote: >>> [1]: If I could only get net/py-pcap to build, I might be able to do >>> a little >>> more... :-) >> >> You only need net/py-pypcap, but if that's what you meant please let >> me know what the build problem is. > (...) > > 44-pi# grep -l pcap_inject /usr/lib/libpcap* > 45-pi# nm -g /usr/local/lib/python2.4/site-packages/pcap.so | grep > pcap_inject > U pcap_inject Have you disable bpf support ? Which version of libpcap do you use ? The problem seems due to your libpcap library which doesn't have the pcap_inject() API. Personally, I've just tried the py-pypcap port from George and it works well. i.e, I was able to inject packets... Best regards, - Clem From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 18:13:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56E0F16A4DA for ; Fri, 21 Jul 2006 18:13:03 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC33043D46 for ; Fri, 21 Jul 2006 18:13:02 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 100845D49; Fri, 21 Jul 2006 14:13:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgdruzJgEbUi; Fri, 21 Jul 2006 14:12:53 -0400 (EDT) Received: from [199.103.21.238] (pan.codefab.com [199.103.21.238]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id B8A895C12; Fri, 21 Jul 2006 14:12:53 -0400 (EDT) In-Reply-To: <44C11242.9090300@gmail.com> References: <44BF95E9.2030102@mac.com> <3724C08A-4ADD-4294-8953-A4ADA2326577@mac.com> <44C11242.9090300@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Charles Swiger Date: Fri, 21 Jul 2006 14:12:51 -0400 To: =?ISO-8859-1?Q?Cl=E9ment_Lecigne?= X-Mailer: Apple Mail (2.752.2) Cc: freebsd-net@freebsd.org Subject: Re: Packet Construction and Protocol Testing... 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, 21 Jul 2006 18:13:03 -0000 On Jul 21, 2006, at 1:43 PM, Cl=E9ment Lecigne wrote: >> 44-pi# grep -l pcap_inject /usr/lib/libpcap* >> 45-pi# nm -g /usr/local/lib/python2.4/site-packages/pcap.so | grep =20= >> pcap_inject >> U pcap_inject > > Have you disable bpf support ? Which version of libpcap do you use ? No, bpf is compiled into the kernel, and C code which uses libpcap =20 seems to work fine: 1-pi# ident /usr/lib/libpcap.a /usr/lib/libpcap.a: $Header: /tcpdump/master/libpcap/bpf_dump.c,v 1.13.2.1 =20 2003/11/15 23:26:37 guy Exp $ $Header: /tcpdump/master/libpcap/bpf_image.c,v 1.25.2.1 =20 2003/11/15 23:26:38 guy Exp $ $Header: /tcpdump/master/libpcap/etherent.c,v 1.21.6.1 =20 2003/11/15 23:26:38 guy Exp $ $Header: /tcpdump/master/libpcap/scanner.l,v 1.95.2.3 =20 2004/03/28 21:45:33 fenner Exp $ $Header: /tcpdump/master/libpcap/savefile.c,v 1.92.2.11 =20 2004/03/11 23:46:14 guy Exp $ $Header: /tcpdump/master/libpcap/nametoaddr.c,v 1.68.2.3 =20 2003/11/19 18:13:48 guy Exp $ $Header: /tcpdump/master/libpcap/optimize.c,v 1.76.2.3 =20 2003/12/22 00:26:36 guy Exp $ $Header: /tcpdump/master/libpcap/gencode.c,v 1.193.2.8 =20 2004/03/29 20:53:47 guy Exp $ $FreeBSD: src/usr.bin/yacc/skeleton.c,v 1.37 2003/02/12 =20 18:03:55 davidc Exp $ $Header: /tcpdump/master/libpcap/grammar.y,v 1.79.2.3 =20 2004/03/28 21:45:32 fenner Exp $ $Header: /tcpdump/master/libpcap/fad-getad.c,v 1.7.2.2 =20 2004/03/11 23:04:52 guy Exp $ $Header: /tcpdump/master/libpcap/inet.c,v 1.58.2.1 2003/11/15 =20 23:26:41 guy Exp $ $Header: /tcpdump/master/libpcap/pcap-bpf.c,v 1.67.2.4 =20 2003/11/22 00:06:28 guy Exp $ $Header: /tcpdump/master/libpcap/bpf/net/bpf_filter.c,v =20 1.43.2.1 2003/11/15 23:26:49 guy Exp $ $Header: /tcpdump/master/libpcap/pcap.c,v 1.63.2.9 2004/03/25 =20 22:40:52 guy Exp $ > The problem seems due to your libpcap library which doesn't have =20 > the pcap_inject() API. > > Personally, I've just tried the py-pypcap port from George and it =20 > works well. i.e, I was able to inject packets... Interesting...thanks for the reply. --=20 -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 18:14:32 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDC8516A4DE for ; Fri, 21 Jul 2006 18:14:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1143343D60 for ; Fri, 21 Jul 2006 18:14:30 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.58]) by a50.ironport.com with ESMTP; 21 Jul 2006 11:14:24 -0700 Message-ID: <44C11974.7000001@elischer.org> Date: Fri, 21 Jul 2006 11:14:12 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Glass References: <7.0.1.0.2.20060721105813.0971ae90@lariat.net> In-Reply-To: <7.0.1.0.2.20060721105813.0971ae90@lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Multiple NAT router 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, 21 Jul 2006 18:14:32 -0000 Brett Glass wrote: > I have an application in which I'd like a FreeBSD router to have > multiple, isolated LANS attached to it, each with the same address > space. The FreeBSD box would take the place of multiple NAT routers. > > For example, I might want to have three internal Ethernet interfaces > on the FreeBSD box. Each would be connected to a LAN whose internal > addresses are 192.168.0.0/24. The FreeBSD box would do NAT for all of > them, and of course they could not "see" one another. > > The alternatives, of course, would be to install multiple NAT routers > -- which would be a waste -- or to number the LANs differently. But > the organization for which I'm doing this wants everything about each > LAN to be absolutely standard (printers at the same static addresses, > etc.) so that their IT guys can walk in and know exactly how > everything's numbered. > > Is it possible to do a "hydra headed" router such as this with > FreeBSD? I'm not sure that FreeBSD's natd is equipped to sort incoming > packets for multiple, identically numbered LANs properly, because it > would have to remember interface names as well as addresses. Also, > there would be the question of how one would connect inward to the > machines on the LANs, since "ping 192.168.0.100" would be ambiguous. > (Perhaps one could do it from a jail. In fact, perhaps the virtual NAT > routers could be set up in jails....) yes I have done this (though with 2 nets) but it was some time ago and it's very hazy as to how it was done. I think it went something like this: run a separate natd ON DIFFERENT PORTS for each inteface and use ipfw to forward packets only to the appropriate natd only when they transition in or out of the appropriate interface. i.e # All packets come here ipfw add 10 allow ip from any to any via lo0 ipfw add 11 drop ip from any to 127.0.0.1 ipfw add 12 drop ip from 127.0.0.1 to any # Only non local packets come here ipfw add 50 skipto 100 ip from any to any in ipfw add 51 skipto 150 ip from any to any out # Shouldn't happen ipfw drop ip from any to any # only incoming packets come here ipfw add 100 [special preprocessing for all incoming packets] ipfw add 110 skipto 1000 ip from any to any recv fxp0 ipfw add 111 skipto 2000 ip from any to any recv fxp1 ipfw add 112 skipto 3000 ip from any to any recv fxp2 ipfw add 149 skipto 200 ip from any to any # only outgoing packets come here ipfw add 150 [special preprocessing for all outgoing packets] ipfw add 160 skipto 4000 ip from any to any xmit fxp0 ipfw add 161 skipto 5000 ip from any to any xmit fxp1 ipfw add 162 skipto 6000 ip from any to any xmit fxp2 # not traversing one of the interesting interfaces, just accept it. (or do other processing) ipfw add 200 allow ip from any to any # Now we handle each interface/direction specifically ipfw add 1000 [ any special preprocessing for fxp0 incoming packets] ipfw add 1010 divert 5001 ip from any to any ipfw add 1011 [special postprocessing for fxp0 incoming packets(after nat)] ipfw add 1020 skipto 10000 ip from any to any ipfw add 2000 [ any special preprocessing for fxp1 incoming packets] ipfw add 2010 divert 5002 ip from any to any ipfw add 2011 [special postprocessing for fxp1 incoming packets(after nat)] ipfw add 2020 skipto 10000 ip from any to any ipfw add 3000 [ any special preprocessing for fxp2 incoming packets] ipfw add 3010 divert 5003 ip from any to any ipfw add 3011 [special postprocessing for fxp2 incoming packets(after nat)] ipfw add 3020 skipto 10000 ip from any to any ipfw add 4000 [ any special preprocessing for fxp0 outgoing packets] ipfw add 4010 divert 5001 ip from any to any ipfw add 4011 [special postprocessing for fxp0 outgoing packets(after nat)] ipfw add 4020 skipto 11000 ip from any to any ipfw add 5000 [ any special preprocessing for fxp1 outgoing packets] ipfw add 5010 divert 5002 ip from any to any ipfw add 5011 [special postprocessing for fxp1 outgoing packets(after nat)] ipfw add 5020 skipto 11000 ip from any to any ipfw add 6000 [ any special preprocessing for fxp2 outgoing packets] ipfw add 6010 divert 5003 ip from any to any ipfw add 6011 [special postprocessing for fxp2 outgoing packets(after nat)] ipfw add 6020 skipto 11000 ip from any to any # All incoming packets come here after NAT (not ones that didn't get natted) ipfw add 10000 [any further processing needed after natting incoming packets] [...] ipfw add 10999 skipto 20000 ip from any to any # All outgoing (post NAT) packets come here ipfw add 11000 [ any further processing needed after natting outgoing packets] # All Nat'd packets come here ipfw add 20000 accept ip from any to any The for each natd I guess you have a separate natd.conf which translates it to a different part of a 10.x.x.x address thus 192.168.0.x <-> 10.100.1.x for fxp0 192.168.0.x <-> 10.100.2.x for fxp1 192.168.0.x <-> 10.100.3.x for fxp2 it occurs to me that this would make all 3 interfaces appear to be on the same net on the central host which would be a problem, so I think, in fact I remember that you needed one other machine on each net to be involved and act as a router.. (hmm need vimage to do this properly I think). hmm maybe you can't do it.. I remmeber now I had multiple nat machines. what a waste of email this was! Anyone have ideas how to get around the fact that all the interfaces would appear the same? (other than vimage) > > --Brett Glass > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 19:19:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D0BE16A4DA for ; Fri, 21 Jul 2006 19:19:19 +0000 (UTC) (envelope-from troglocan@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3DBB43D49 for ; Fri, 21 Jul 2006 19:19:18 +0000 (GMT) (envelope-from troglocan@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so1315448pyb for ; Fri, 21 Jul 2006 12:19:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uofsq0scFX14C2UjfhogGbFDMWXWdgAeNnUHQYEqpja64YCNMYV8lwalMLd3Hp+uMNWOXFeoYTwyg3xPXGo44kZoem/cMfOFpXLjKHnropaPjArNE1k8LmBUqeJixTLD9Hlvc4NSNltnVUBy1mxWCtuhJ7F15zJRpxmgg5zJ29I= Received: by 10.35.88.17 with SMTP id q17mr1754352pyl; Fri, 21 Jul 2006 12:17:39 -0700 (PDT) Received: by 10.35.111.10 with HTTP; Fri, 21 Jul 2006 12:17:39 -0700 (PDT) Message-ID: <27b46d880607211217v76a42db6re5a22d3b704020ff@mail.gmail.com> Date: Fri, 21 Jul 2006 21:17:39 +0200 From: troglocan To: "gnn@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-net@freebsd.org Subject: Re: Packet Construction and Protocol Testing... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: troglocan@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 19:19:19 -0000 Hi, Sorry for the late reply, I just read the thread. Did you take a look at Scapy (http://www.secdev.org/scapy). It does exactly (and more) what you are trying to do ... a+ ps : also, Scapy6 (http://namabiiru.hongo.wide.ad.jp/scapy6/) provides extension of Scapy for IPv6 (some parts of what is advertised on main page are currently being reviewed and have been extracted of main file temporarily). On 7/20/06, gnn@freebsd.org wrote: > Hi, > > Sorry for the length of this email but I figured I'd get this out > early in case there was anyone else who wanted to play with this. > > I have now gotten out version 0.1 of the Packet Construction Set. > This is a set of Python libraries which make writing protocol testing > software much easier. From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 19:30:38 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 940C616A4ED for ; Fri, 21 Jul 2006 19:30:38 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0DFB43D66 for ; Fri, 21 Jul 2006 19:30:34 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k6LJTs1R079999; Fri, 21 Jul 2006 22:29:58 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Fri, 21 Jul 2006 22:29:54 +0300 (EEST) From: Dmitry Pryanishnikov To: Jack Vogel In-Reply-To: <2a41acea0607210849k6ad6693ey1d683910d81e9d41@mail.gmail.com> Message-ID: <20060721211810.A19671@atlantis.atlantis.dp.ua> References: <200607192230.14939.mi+mx@aldan.algebra.com> <20060720025003.GF924@tnn.dglawrence.com> <44BFB667.60106@elischer.org> <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com> <20060721111838.M77932@atlantis.atlantis.dp.ua> <2a41acea0607210849k6ad6693ey1d683910d81e9d41@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mikhail Teterin , net@freebsd.org, Julian Elischer , "David G. Lawrence" Subject: Re: complement to sendfile()? 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, 21 Jul 2006 19:30:38 -0000 Hello! On Fri, 21 Jul 2006, Jack Vogel wrote: >> Sure there is an interest, spare CPU cycles are never superfluous >> in production environment! What hardware (NICs/chipsets) supports this >> I/OAT DMA engine? > Its part of the Intel Blackford chipset, so for instance Supermicro has a > motherboard and servers with it. > > Oh, and there is nothing changed in the NIC and its driver, this is just > stack changes together with the chipset dma driver I wrote, so any > NIC on a system will benefit. Aha, so DMA engine is in the main motherboard chipset, not in NIC? Well, I see, Blackford is the codename for Intel 5000P / 5000V, isn't it? These chipsets are rather new, so I suspect that testing audience for this new feature will not be wide enough for now, but the feature itself is definitely useful, so future FreeBSD users will greatly appreciate it's support IMHO. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Jul 21 23:07:58 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D464016A4DE for ; Fri, 21 Jul 2006 23:07:58 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7669E43D46 for ; Fri, 21 Jul 2006 23:07:58 +0000 (GMT) (envelope-from mattjreimer@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so1367131pyb for ; Fri, 21 Jul 2006 16:07:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EvH94dAxnaZVBBNR+Sq9Wjo1g4u7Ru21B8lZ6sUqYjcPC4e54qzk+A/TJ87r5kDimL9rq+pHrqiKCjd4ypb4Dm4jxBG3F+1RVNO6RgdSVz3ZgsXxF2U1Fq6/4eRE2lG8zkUr+L4LhfbB36ViLcCMDK1RD/blTRVOaz+mlX+SGY4= Received: by 10.35.18.18 with SMTP id v18mr2094502pyi; Fri, 21 Jul 2006 16:06:26 -0700 (PDT) Received: by 10.35.63.7 with HTTP; Fri, 21 Jul 2006 16:06:26 -0700 (PDT) Message-ID: Date: Fri, 21 Jul 2006 16:06:26 -0700 From: "Matt Reimer" To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: What should happen when mbufs/mbuf clusters are exhausted? 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, 21 Jul 2006 23:07:58 -0000 What should happen when mbufs/mbuf clusters are exhausted? Are packets dropped, does the kernel panic, or hang, or ...? Does RELENG_4 behave differently than RELENG_6 or HEAD when mbufs/clusters are exhausted? I know that 5.3 and later allocate and free mbufs/clusters dynamically, but are these newer versions more robust in the face of allocation failures? I thought I read once that they were, but I would like to make sure. Thanks in advance. Matt From owner-freebsd-net@FreeBSD.ORG Sat Jul 22 03:07:57 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8F6C16A4DE for ; Sat, 22 Jul 2006 03:07:57 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35D3243D49 for ; Sat, 22 Jul 2006 03:07:57 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k6M37jhu046785; Fri, 21 Jul 2006 20:07:45 -0700 (PDT) Date: Sat, 22 Jul 2006 12:07:39 +0900 Message-ID: From: gnn@FreeBSD.ORG To: troglocan In-Reply-To: <27b46d880607211217v76a42db6re5a22d3b704020ff@mail.gmail.com> References: <27b46d880607211217v76a42db6re5a22d3b704020ff@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.6.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@FreeBSD.ORG Subject: Re: Packet Construction and Protocol Testing... 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, 22 Jul 2006 03:07:57 -0000 At Fri, 21 Jul 2006 21:17:39 +0200, troglocan wrote: > > Hi, > > Sorry for the late reply, I just read the thread. Did you take a look > at Scapy (http://www.secdev.org/scapy). It does exactly (and more) > what you are trying to do ... > > a+ > > ps : also, Scapy6 (http://namabiiru.hongo.wide.ad.jp/scapy6/) provides > extension of Scapy for IPv6 (some parts of what is advertised on main > page are currently being reviewed and have been extracted of main file > temporarily). > Yup, looked at it. A single file, hard to maintain, and does not support creating arbitrary packets in the way PCS does, but it does have some interesting features. Thanks, George From owner-freebsd-net@FreeBSD.ORG Sat Jul 22 03:08:50 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFF1F16A4DD for ; Sat, 22 Jul 2006 03:08:50 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2-b.corp.dcn.yahoo.com (mrout2-b.corp.dcn.yahoo.com [216.109.112.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AEC343D45 for ; Sat, 22 Jul 2006 03:08:49 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k6M38eec073652; Fri, 21 Jul 2006 20:08:41 -0700 (PDT) Date: Sat, 22 Jul 2006 12:08:34 +0900 Message-ID: From: "George V. Neville-Neil" To: Charles Swiger In-Reply-To: References: <44BF95E9.2030102@mac.com> <3724C08A-4ADD-4294-8953-A4ADA2326577@mac.com> <44C11242.9090300@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.6.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Cl=E9ment?= Lecigne , freebsd-net@FreeBSD.org Subject: Re: Packet Construction and Protocol Testing... 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, 22 Jul 2006 03:08:51 -0000 At Fri, 21 Jul 2006 14:12:51 -0400, Charles Swiger wrote: >=20 > On Jul 21, 2006, at 1:43 PM, Cl=C2=81=C3=A9ment Lecigne wrote: > >> 44-pi# grep -l pcap_inject /usr/lib/libpcap* > >> 45-pi# nm -g /usr/local/lib/python2.4/site-packages/pcap.so | grep =20 > >> pcap_inject > >> U pcap_inject > > > > Have you disable bpf support ? Which version of libpcap do you use ? >=20 > No, bpf is compiled into the kernel, and C code which uses libpcap =20 > seems to work fine: I believe you need the latest pcap from ports. That's what I use. Best, George