From owner-freebsd-net@FreeBSD.ORG Sun Dec 7 17:40:06 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F7A21065691 for ; Sun, 7 Dec 2008 17:40:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 148038FC12 for ; Sun, 7 Dec 2008 17:40:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB7He5Jh083822 for ; Sun, 7 Dec 2008 17:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB7He5P4083821; Sun, 7 Dec 2008 17:40:05 GMT (envelope-from gnats) Date: Sun, 7 Dec 2008 17:40:05 GMT Message-Id: <200812071740.mB7He5P4083821@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Marius Strobl Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marius Strobl List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 17:40:06 -0000 The following reply was made to PR kern/128833; it has been noted by GNATS. From: Marius Strobl To: freebsd@amc-os.com Cc: "bug-followup@FreeBSD.org" Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Sun, 7 Dec 2008 18:36:26 +0100 Aurélien, could you please verify that the patch at: http://people.freebsd.org/~marius/bge_5701b5_pcix.diff solves your problem? Thanks, Marius From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 00:48:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A1C81065670 for ; Mon, 8 Dec 2008 00:48:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id E5F638FC16 for ; Mon, 8 Dec 2008 00:48:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so932726rvf.43 for ; Sun, 07 Dec 2008 16:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=BfI6O3VPlCWDAQ9330wVNw6dM7mA7KAWWPIMZGZ2SRA=; b=XOkUSHXJEiGM96b02H/KPMAekec+6k/x1AnT7iMZuaDOZCkxKRydlN5Ua5h6OHhvi5 hOemFs76+qtTj2AGQ1c74ngJwwF68YM9WbH6RodxuU1ezO25KgJyG/F5jNzQYK+nLFk0 6An2ZMftWjTZlrVk80MKntG6zd2NnoGob1V3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=UpsLqixewWUNceCWvLvDN52b2byrot/KMvNiJd87KHmBKibh6pLjB9u07U5sB3nlUm ZJJWKl4TvIMrZsPtrUMDeoeWCDQncyyOf3zkZNAuLiDu9fCSg0K7384aEn+kn+8O7+A0 7ex/AbPGS4M4WCSe+MRuRmxlDxpUknHE4TISo= Received: by 10.141.48.10 with SMTP id a10mr1346483rvk.266.1228697290607; Sun, 07 Dec 2008 16:48:10 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k2sm24984229rvb.1.2008.12.07.16.48.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 07 Dec 2008 16:48:08 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mB80m2PQ029786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 09:48:02 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mB80m2Aj029785; Mon, 8 Dec 2008 09:48:02 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 8 Dec 2008 09:48:02 +0900 From: Pyun YongHyeon To: Vladimir Ermakov Message-ID: <20081208004802.GB29560@cdnetworks.co.kr> References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: vlan support trouble in if_sis driver ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 00:48:11 -0000 On Sat, Dec 06, 2008 at 09:55:52PM +0300, Vladimir Ermakov wrote: > > I don't have sis(4) hardwares so I'm not sure it's bug. Since you > > see Ierrs on parent interface sis0, I guess the hardware might set > > a giant bit when it receives VLAN frames. Driver might think it > > received errored frames which in turn make driver drop these VLAN > > frames. > > Thanks, your patch fixes a problem with the card (sis). > in the output of netstat no errors and files downloaded through fget > Good. Would you show me the output of "pciconf -lcv"? If I don't see any oddities in the output, I would commit the patch. > what tests need to try? > If parent interface sis0 still works as expected(i.e. without VLAN) there is no need to test other cases, I guess. > /Vladimir Ermakov -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 06:33:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09940106564A for ; Mon, 8 Dec 2008 06:33:29 +0000 (UTC) (envelope-from numardbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id C35E58FC1F for ; Mon, 8 Dec 2008 06:33:28 +0000 (UTC) (envelope-from numardbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so920835rvb.7 for ; Sun, 07 Dec 2008 22:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:face:mime-version :content-type:content-transfer-encoding; bh=lLTPdOZ2przohBhZU4JyN0uoyuYoZTX4x3kAr6KH9o4=; b=YgoBkg7C0NI0ccSjM2jGuC2LROIFzH63Wwr+lJ7zJhmK9lBBlaDf4dZOgCotbO14vZ d6OruJnSyfq9aRoyLJpHEPDLZPbhaAANqt0cagR9pBCA1zgg3N9hoW75SjLxeTyPBPgD KqR6AiE/khnaE5kxV7OZ0gOy10aOGKleQ8Va0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :face:mime-version:content-type:content-transfer-encoding; b=BNNjE2u/UGP3tqmHzpOTvajt/ua09O9qZIO7tWMbtCgD+2iBtBGlnyzbbRoDylDFMQ 66itxd6cXC9nwT2In5fLHZXOMjgUZM2E7aDOVKI4qzlJ9qWlWNQ6P/91cT1s7dZS6PDm zAPBEvVl5N3Z19aDslx6va6kBh0SJLcZ+REdI= Received: by 10.141.170.10 with SMTP id x10mr1496646rvo.5.1228716784576; Sun, 07 Dec 2008 22:13:04 -0800 (PST) Received: from ayiin (124-170-44-86.dyn.iinet.net.au [124.170.44.86]) by mx.google.com with ESMTPS id b8sm25575188rvf.3.2008.12.07.22.12.58 (version=SSLv3 cipher=RC4-MD5); Sun, 07 Dec 2008 22:13:03 -0800 (PST) Date: Mon, 8 Dec 2008 17:12:45 +1100 From: Norberto Meijome To: freebsd-net@freebsd.org Message-ID: <20081208171245.4271ca86@ayiin> In-Reply-To: <200812050913.00889.fjwcash@gmail.com> References: <49376544.70006@redhat.com> <20081204070239.X80401@maildrop.int.zabbadoz.net> <4938DF2A.6080409@unile.it> <200812050913.00889.fjwcash@gmail.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Virtual machine on freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 06:33:29 -0000 On Fri, 5 Dec 2008 09:13:00 -0800 Freddie Cash wrote: > On December 4, 2008 11:58 pm Antonio Tommasi wrote: > > Hi to all, > > i want to install a virtual machine on my FreeBSD 7.0 box. Can you tell > > me which is the better sofware to do this? Antonio, you would have received more answers if you asked in the right forum ( questions@). > > For a FreeBSD host, QEmu is the best supported option. > > There's also Win4BSD, which is a customised/modified version of QEmu. I've > seen several reports online of this being better/faster than QEmu. I've > never personally been able to get it to work, though. Works ok, though I don't think it's that so much faster than QEmu that makes it worth going through the effort of recreating your VMs.... YMMV. > > And that's pretty much it if you want full-OS virtualisation (ie, the VMs > have their own OS). If you don't need that, and just want to run multiple > FreeBSD setups on one host, have a look at jail(8). > - VMWare Workstation {very old version} is in ports. You need an *old* license from vmware...no idea how well it works. - http://wiki.freebsd.org/FreeBSD/Xen - still not production ready. Check the archives of questions@ for more threads on this subject. cheers, B _________________________ {Beto|Norberto|Numard} Meijome If you were supposed to understand it, we wouldn't call it 'code'. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 07:58:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0477106564A for ; Mon, 8 Dec 2008 07:58:39 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 7876B8FC20 for ; Mon, 8 Dec 2008 07:58:39 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by an-out-0708.google.com with SMTP id b6so399522ana.13 for ; Sun, 07 Dec 2008 23:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=l/em+kQa44V9ddAEajJrX//OTkWtjc713bmeZs/OdWM=; b=GU24iVmqwDLmSC6r3MsJbmJQxw1JrMBUQYgmbrPGg6yJHh310USoVsza/F5dsgEMmI jdSaTCsrDpkrf/ioFry4SvA1k5IPk5/NKtwdUvfqZth2leBBWmLqq288kJf9en8NCa5i ETWKNMpaf3+wATVdEuuhmJoHbNZzxlBNLTb+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=frjuHimPPP47a6X/V1+D6/JyBEp5is8JRy/N2rupT1HtGxipgSp+1EfEc358JHF6lu +sls6bhoR2HvLHb5PwHHFSoIO/5jtkMabxuKhiqhExURy5t5ZcB9KNNPgl3YX+X6mcH4 X0xSFln71uDKfNdcv3HoMaG56O+i+aGtt6+r0= Received: by 10.100.225.19 with SMTP id x19mr1286533ang.122.1228721301081; Sun, 07 Dec 2008 23:28:21 -0800 (PST) Received: from ?192.168.2.2? (cpe-70-112-179-136.austin.res.rr.com [70.112.179.136]) by mx.google.com with ESMTPS id b14sm5059567ana.12.2008.12.07.23.28.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 07 Dec 2008 23:28:20 -0800 (PST) From: Ferner Cilloniz To: freebsd-net@freebsd.org Content-Type: text/plain Date: Mon, 08 Dec 2008 01:28:21 +0000 Message-Id: <1228699701.4940.2.camel@mobiliare.Belkin> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Subject: FreeBSD kernel module and sending udp packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 07:58:39 -0000 Hello everyone. I need help with documentation concerning how to send a udp or tcp packet from a kernel module. I have found this information for Linux but not for FreeBSD. Please help me. Thank you :) From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 08:13:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C6B8106564A for ; Mon, 8 Dec 2008 08:13:43 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id 149B48FC16 for ; Mon, 8 Dec 2008 08:13:42 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by an-out-0708.google.com with SMTP id b6so400602ana.13 for ; Mon, 08 Dec 2008 00:13:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=jS9T1ge/82rBbOXof1w7128ScivvyE2AJ4QAAfKZkPg=; b=iv6BTivONM2bf3/vGReMQHzJsO/JkElvO7NI+4tk9jG+4wIO0atbLuPrYdo1w4KCI8 JzBns3sF7vpLT6SFCs48ARpSkOAm6qRceH+Lqy9W3x9dG7A+Xn4yHTeTWhwk2PX7dzs4 1ZZu2xYdcptA4mkSAAKgpw550ppYUtMVv2AGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=wNQvHgK+OEFhuVH4wxNCJRpwnZ01+cIzoTw71pLOAUfGBG9D6RshRSCgHC1uaeAG/l 5Df3FUSLKAoQIhhiB0nh3Oa/L6AFukkhJD8jqiG0wrp3lh8yhO9SRWkbBcnlOy7h6t9r MaeAN4cFbqFu8c0bnJppR38bbOX5HAp2ynZww= Received: by 10.100.138.17 with SMTP id l17mr1310244and.65.1228724022236; Mon, 08 Dec 2008 00:13:42 -0800 (PST) Received: from ?192.168.2.2? (cpe-70-112-179-136.austin.res.rr.com [70.112.179.136]) by mx.google.com with ESMTPS id c28sm8597095anc.7.2008.12.08.00.13.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Dec 2008 00:13:41 -0800 (PST) From: Ferner Cilloniz To: Julian Elischer In-Reply-To: <493CD5AB.8030303@elischer.org> References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> Content-Type: text/plain Date: Mon, 08 Dec 2008 02:13:42 +0000 Message-Id: <1228702422.4940.7.camel@mobiliare.Belkin> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD kernel module and sending udp packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 08:13:43 -0000 Thanks for the reply. I read something about that but I didn't understand what was being said. Can you please help me in understanding. I have googled for sample code and didn't find anything useful. Can you, or anyone else, please help me understand this? Thanks again :) On Mon, 2008-12-08 at 00:07 -0800, Julian Elischer wrote: > Ferner Cilloniz wrote: > > Hello everyone. > > > > I need help with documentation concerning how to send a udp or tcp > > packet from a kernel module. I have found this information for Linux but > > not for FreeBSD. > > > > Please help me. > > you could give your module a netgraph interface. Then it can connect > directly to the ng_ksocket node type and use that. as a nin-kernel socket. > > > > > > > Thank you :) > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 08:20:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ECBD1065670 for ; Mon, 8 Dec 2008 08:20:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 2D0328FC22 for ; Mon, 8 Dec 2008 08:20:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 1381D24AD; Mon, 8 Dec 2008 00:07:19 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 5D8CE2D6017; Mon, 8 Dec 2008 00:07:06 -0800 (PST) Message-ID: <493CD5AB.8030303@elischer.org> Date: Mon, 08 Dec 2008 00:07:07 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Ferner Cilloniz References: <1228699701.4940.2.camel@mobiliare.Belkin> In-Reply-To: <1228699701.4940.2.camel@mobiliare.Belkin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD kernel module and sending udp packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 08:20:04 -0000 Ferner Cilloniz wrote: > Hello everyone. > > I need help with documentation concerning how to send a udp or tcp > packet from a kernel module. I have found this information for Linux but > not for FreeBSD. > > Please help me. you could give your module a netgraph interface. Then it can connect directly to the ng_ksocket node type and use that. as a nin-kernel socket. > > Thank you :) > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 08:23:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 217061065670 for ; Mon, 8 Dec 2008 08:23:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 0968A8FC1A for ; Mon, 8 Dec 2008 08:23:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 4EB1124AD; Mon, 8 Dec 2008 00:23:57 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id DDAF32D600D; Mon, 8 Dec 2008 00:23:39 -0800 (PST) Message-ID: <493CD98D.7000909@elischer.org> Date: Mon, 08 Dec 2008 00:23:41 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Ferner Cilloniz References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> In-Reply-To: <1228702422.4940.7.camel@mobiliare.Belkin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD kernel module and sending udp packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 08:23:40 -0000 Ferner Cilloniz wrote: > Thanks for the reply. I read something about that but I didn't > understand what was being said. > > Can you please help me in understanding. I have googled for sample code > and didn't find anything useful. Can you, or anyone else, please help me > understand this? http://people.freebsd.org/~julian/netgraph.html > > Thanks again :) > > On Mon, 2008-12-08 at 00:07 -0800, Julian Elischer wrote: >> Ferner Cilloniz wrote: >>> Hello everyone. >>> >>> I need help with documentation concerning how to send a udp or tcp >>> packet from a kernel module. I have found this information for Linux but >>> not for FreeBSD. >>> >>> Please help me. >> you could give your module a netgraph interface. Then it can connect >> directly to the ng_ksocket node type and use that. as a nin-kernel socket. >> >> >> >>> Thank you :) >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 08:32:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3444106564A for ; Mon, 8 Dec 2008 08:32:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outq.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id BB65A8FC1A for ; Mon, 8 Dec 2008 08:32:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 44D0624AD; Mon, 8 Dec 2008 00:32:24 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id B63392D6004; Mon, 8 Dec 2008 00:32:13 -0800 (PST) Message-ID: <493CDB8F.7040709@elischer.org> Date: Mon, 08 Dec 2008 00:32:15 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Ferner Cilloniz References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> <493CD98D.7000909@elischer.org> In-Reply-To: <493CD98D.7000909@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD kernel module and sending udp packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 08:32:12 -0000 Julian Elischer wrote: > Ferner Cilloniz wrote: >> Thanks for the reply. I read something about that but I didn't >> understand what was being said. >> >> Can you please help me in understanding. I have googled for sample code >> and didn't find anything useful. Can you, or anyone else, please help me >> understand this? > > http://people.freebsd.org/~julian/netgraph.html I should add: http://fxr.watson.org/fxr/source/netgraph/ng_sample.c as a pointer to netgraph sources. From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 08:47:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB1A7106564A for ; Mon, 8 Dec 2008 08:47:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outx.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id BEF168FC19 for ; Mon, 8 Dec 2008 08:47:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 8F2CC24B6 for ; Mon, 8 Dec 2008 00:48:09 -0800 (PST) X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 647292D601D for ; Mon, 8 Dec 2008 00:47:55 -0800 (PST) Message-ID: <493CDF3C.5030608@elischer.org> Date: Mon, 08 Dec 2008 00:47:56 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: FreeBSD Net Content-Type: multipart/mixed; boundary="------------030705070707060304090701" Subject: Vimage howto 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, 08 Dec 2008 08:47:54 -0000 This is a multi-part message in MIME format. --------------030705070707060304090701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Well not completely, but I've had a number of questions over the last few months about what it is, so, as Marko and I have written the following "how to virtualize your module" document, I've been directing people to it. After another couple of questions I think this could do with wider distribition.. It is available at: http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/vimage/porting_to_vimage.txt but I include it here for popular enjoyment. Please contact me or Marko if you have any questions or suggestions on this. --------------030705070707060304090701 Content-Type: text/plain; name="porting_to_vimage.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="porting_to_vimage.txt" =================== Vimage: what is it? =================== Vimage is a framework in the BSD kernel which allows a co-operating module to operate on multiple independent instances of its state so that it can participate in a virtual machine / virtual environment scenario. The implementation approach taken by the vimage framwork is a replacement of selected global state variables with constructs that allow for the virtualized state to be stored and resolved in appropriate instances of module-specific container structures. The code operating on virtualized state has to conform to a set of rules described further below, among other things in order to allow for all the changes to be conditionally compilable, i.e. permitting the virtualized code to fall back to operation on global state. The most visible change throughout the existing code is typically replacement of direct references to global variables with macros; foo_bar thus becomes V_foo_bar. V_foo_bar macros will resolve back to foo_bar global in default kernel builds, and alternatively to some_base_pointer->_foo_bar for "options VIMAGE" kernel configs. Prepending of "V_" prefixes to variable references helps in visual discrimination between global and virtualized state. The framework extends the sysctl infrastructure to support access to virtualized state through introduction of the SYSCTL_V family of macros; those also automatically fall back to their standard SYSCTL counterparts in default kernel builds. Transparent kldsym(2) lookups are provided to virtualized variables explicitly marked for visibility to kldsym interface, which permits userland binaries such as netstat to operate unmodified on "options VIMAGE" kernels, though this may have wide security implications. The vimage struct is currently primarily a placeholder for pointers to module-specific struct instances; currently V_NET (networking), V_CPU (CPU scheduling), and V_PROCG (jail-style interprocess protection) major module classes are defined. Each vimage module may or may not be further split into minor or submodules; the networking subsystem (vimage id V_NET; struct vnet) in particular is organized in submodules such as VNET_MOD_NET (mandatory shared infrastructure: routing tables, interface lists etc.); VNET_MOD_INET (IPv4 state including transport protocols); VNET_MOD_INET6, VNET_MOD_IPSEC, VNET_MOD_IPFW, VNET_MOD_NETGRAPH etc. The speciality of VNET submodules is in that they not only provide storage for virtualized data, but also enforce ordering of initialization and cleanup. Hence, not all submodules must necessarily allocate private storage for their specific data; they may be defined solely for to support proper initialization ordering. Each process is associated with a vimage, and vimages currently hang off of ucred-s. This relationship defines a process's administrative affinity to a vimage and thus indirectly to all of its modules (NET, CPU, PROCG) as well as to any submodules. All network interfaces and sockets hold pointers back to their parent vnets; this relationship is obviously entirely independent from proc->ucred->vimage bindings. Hence, when a process opens a socket, the socket will get bound to a vnet instance hanging off of proc->ucred->vimage->vnet, but once such a socket->vnet binding gets established, it cannot be changed for the entire socket lifetime. Certain classes of network interfaces (Ethernet in particular) can be assigned from one vnet to another at any time. By definition all vnets are are independent and can communicate only if they are explicitly provided with communication paths; currently only netgraph can be used to establish inter-vnet datapaths. In network traffic processing the vnet affinity is defined either by the inbound interface or by the socket / pcb -> vnet binding. However, there are many functions in the network stack that cannot implicitly fetch the vnet context from their standard arguments. Instead of explicitly extending argument lists of such functions with a struct vnet *, a per-thread variable td_vnet was introduced, which can be fetched via the curvnet macro (#define curvnet curthread->td_vnet). The curvnet context has to be set on entry to the network stack (socket operations, packet reception, or timer-driven functions) and cleared on exit. This must be done via provided CURVNET_SET() / CURVNET_RESTORE() family of macros, which allow for "stacking" of curvnet context setting and provide additional debugging info in INVARIANTS kernel configs. In most cases however a developer writing virtualized code will not have to set / restore the curvnet context unless the code would include timer-driven events, given that those are inherently vnet-contextless on entry. Converting / virtualizing existing code ======================================= There are several steps need in virtualisation. 1/ decide whether the module needs to be virtualised. if the module is a driver for specific hardware, it makes sense that there be only one instance of the driver as there is only one piece of physical hardware. There are changes in the networking code to allow physical (or virtual) interfaces to be moved between vnets. This generally requires NO changes to the network drivers of the classes covered (e.g. ethernet). 2/ decide if your module is part of one of the major module groups. These are currently V_NET V_PROCG V_CPU. The reader will note that the descriptions below use the acronym VNET a lot. The vimage system has been at this time broken into a number of subsections. One of these is the "VNET" group. The idea of these subsections is that they might be individually selected as virtualizable in a particular virtual machine instance. As an example, in a virtualization, one might to allocate a couple of processors to it, but keep the same filesystem and network setup, or alternatively to share processors but to have virtualised networking. 3/ If the module is to be virtualised, decide which attributes of the module should be virtualised. For example, It may make sense that there be a single central pool of "struct foo" and a single uma zone for them to come from, with a single lock guarding it. It might also make sense if the "foo_debug" sysctl controls all the instances at once, while on the other hand, the "foo_mode" sysctl might make better sense if it were controllable on a virtual system by virtual system basis. 4/ Work out what global variables and structures are to be virtualised to achieve the behaviour required for part #3. 5/ Work out for all the code paths through the module, how the path entering the module can divine which virtual environment it is on. Some examples: * Since interfaces are all assigned to one vnet or another, an incoming packet has a pointer to the receive interface, which in turn has a pointer back to the vnet. Often "curvnet" will already have been set by the time your code is called anyhow. * Similarly, on any request from outside the kernel, (direct or indirect) the current thread has a way to get to the current virtual environment instance via td->ucred->vimage. For existing sockets the vnet context must be used via so->so_vnet since td->ucred->vimage might change after socket creation. * Timer initiated actions usually have a (void *) argument which points to some private structure for the module. It should be possible to add a pointer to the appropriate module instance into whatever structure that points to. * Sometimes an action (timer trigerred or trigerred by module load or unload simply has to check all the vimage or module instances. There are macro (pairs) for this which will iterate through all the VNET or VPROCG instances. This covers most of the cases, however in some cases it may still be required for the module to stash away the virtual environment instance somewhere, and make associated changes in the code. 6/ Add the code described below to the files that make up the module Details: temp. note: for module FOO add a definition for VNET_MOD_FOO in sys/vimage.h. This will eventually be dynamically assigned. For now these instructions refer mainly to VNET and not VCPU, VPROCG etc. Symbols defined in other modules that have been virtualised will have been moved to a module-specific virtualisation structure. It will be defined in a .h file for just this purpose. If a module will never export virtualise symbols beyond it's borders, then this structure may well just be in a common include file for that module. As an example, common networking (but not protocol) variables have been moved to a file called net/vnet.h, but the gre module has simply added the virtualisation structure to if_gre.h as no code outside the gre interface will access those values. Accesses to virtualised symbols are achieved via macros, which generally are of the same name as the original symbol but with a "V_" prepended, thus the head of the interface list, called 'ifnet' is replaced whereever used with "V_ifnet". In SCTP, because the code is shared with other OS's they are replaced with a macro MODULE_GLOBAL(modulename, symbol). In the current version of vimage, when VIMAGE is not compiled into the kernel, the macros evaluate to a direct reference to the symbol. In future versions it will evaluate to a global version of the virtualisation structure with the offset to the entry in quesiton, which will result in a single direct memory reference, so that the speed will be as it is now. When VIMAGE is compiled in, the macro will evaluate to an access to an element in a structure pointed to by a local varible. For this reason, it is necessary to also add, at the beginning of these functions another macro that will instantiate this local variable and point it at the correct place. As an example, prior to using the "V_ifnet" structure in a program block, we must add the following macro at the head of a code block enclosing the references to set up module-specific base pointer variable: INIT_VNET_NET(initial_value); /* initial value is usually curvnet */ When VIMAGE is not defined, this will evaluate to nothing but when it IS defined, it will evaluate to: struct vnet_net *vnet_net = (initial_value); The initial value is usually something like "curvnet" which in turn is a macro that derives the vnet affinity from the current thread. It could also be (m->m_ifp->if_vnet) if we were receiving an mbuf. In the case where it is just one function in a module calling another (static), the porter might decide to simply pass the local variable as an argument, rather than to reevaluate it in the function, but should be prepared to cope with the fact that the code might be compiled in the "no-VIMAGE" manner (in which case the argument would be marked as "unused"). Usually, when a packet enters the system it is carried through the processing path via a single thread, and that thread will set its virtual environment reference to that indicated by the packet on picking up that new packet. This means that in the normal inbound processing path as well as the outgoing process path the current thread can be used to indicate the current virtual environment. In the case of timer initiated events, best practice would also be to set the current virtual module reference to that indicated calculated by whatever way that would be done, so that any functions called could rely on the current thread being a good reference for the correct virtual module. When a new VNET submodule is defined for virtualisation, the following structure defining macro is used to define it to the framework. #define VNET_MOD_DECLARE(m_name_uc, m_name_lc, m_iattach, m_idetach, \ m_dependson, m_symmap) \ static const struct vnet_modinfo vnet_##m_name_lc##_modinfo = { \ .vmi_id = VNET_MOD_##m_name_uc, \ .vmi_dependson = VNET_MOD_##m_dependson, \ .vmi_name = #m_name_lc, \ .vmi_iattach = m_iattach, \ .vmi_idetach = m_idetach, \ .vmi_struct_size = \ sizeof(struct vnet_##m_name_lc), \ .vmi_symmap = m_symmap \ The ID we allocated in the temporary first step in "Details" is the first entry here; eventually this should be automatically done by module name. The DEPENDSON field tells us the order that modules should be initialised in a new virtual environment. This may later need to be changed to a list of text module names for dynamic calculation. The rest of the fields are self explanatory, with the exception of the symmap entry. The symmap allows us to intercept calls by libkvm to the linker when it is looking up symbols and to redirect it dynamically. this allows for example "netstat -r" to find the routing tables for THIS virtual environment. (of course that won't work for core dumps). (XXX *needs thought *) As example of virtualising a dummy module named the FOO module the following code might be added to a special vfoo.h or at least to the exisitng foo.h file: ======================================================== #ifndef _DIR_VFOO_H_ #define _DIR_VFOO_H_ #include /* for struct foo_bar */ #define INIT_VNET_FOO(vnet) \ INIT_FROM_VNET(vnet, VNET_MOD_FOO, \ struct vnet_foo, vnet_foo) #define VNET_FOO(sym) VSYM(vnet_foo, sym) #if (defined(VIMAGE) || defined(FUTURE)) struct vnet_foo { int _foo_counter struct foo_bar _foo_barx; }; #endif /* Symbol translation macros */ #define V_foo_counter VNET_FOO(foo_counter) #define V_foo_barx VNET_FOO(foo_barx) #endif /* !_FOO_VFOO_H_ */ ========================================================= For each time the foo module is initiated for a new virtual environment, the foo_bar structure must be initiated, so a new foo_creator and destructor functions are defined for the module. The Module will call these when a new virtual environment is created or destroyed. The constructor must be called once for the base machine when the system is booted, even when options VIMAGE is not defined. ==================== in module foo.c ====== #include "opt_vimage.h" [...] #include [...] #include [...] #ifndef VIMAGE /* initially the globals would have been here, * and for now we will leave them here when not using VIMAGE. * In the future we will instead have a static version of the structure. */ # if defined(FUTURE) struct vnet_foo vnet_foo_globals; # else /* !FUTURE */ int foo_counter = 0; struct foo_bar foo_barx = {}; # endif /* !FUTURE */ #endif /* !VIMAGE */ [...] #if (defined(VIMAGE) || defined(FUTURE)) static vnet_attach_fn vnet_foo_iattach; static vnet_detach_fn vnet_foo_idetach; #endif #ifdef VIMAGE /* If we have symbols we need to divert for libkvm * then put them in here. We may not need to do anything if * the symbols are not used by libkvm. */ static struct vnet_symmap vnet_net_symmap[] = { VNET_SYMMAP(foo, foo_counter), VNET_SYMMAP(foo, foo_barx), VNET_SYMMAP_END }; /* * Declare our module and state that we want to be done after the * loopback interface is initialised for the virtual environment. */ VNET_MOD_DECLARE(FOO, foo, vnet_foo_iattach, vnet_foo_idetach, LOIF, vnet_foo_symmap) #endif /* VIMAGE */ [...] /* a pre-exisiting 'foo' function that will be converted. */ void foo_work(void) { INIT_VNET_FOO(curvnet); /* Add this at the front */ V_foo_counter++; /* add "V_" to the front of the symbol */ [...] V_foo_barx.mumble = V_foo_counter; /* and here too */ [...] } /* * A function which on entry has no idea of which vnet it is on * and needs to look at them all for some reason. * NOTE! if this code is running in a thread that * does nothing else, or otherwise doesn't care about which * vnet it is on then the steps that save and restore the previous vnet * need not be done. (Marked with /* XXX */) */ void foo_tick(void) { VNET_ITERATOR_DECL(vnet_iter); [...] [...] VNET_LIST_RLOCK(); VNET_LIST_FOREACH(vnet_iter) { CURVNET_SET(vnet_iter); INIT_VNET_NET(vnet_iter); [...] do work, including calling code that assumes we have curvnet set. [...] CURVNET_RESTORE(); } VNET_LIST_RUNLOCK(); [...] } #if (defined(VIMAGE) || defined(FUTURE)) static int vnet_foo_iattach(const void *unused) { INIT_VNET_FOO(curvnet); V_foo_counter = 0; bzero (&V_foo_barx, sizeof (V_foo_barx)); return 0; } #endif #ifdef VIMAGE static int vnet_foo_idetach(const void *unused) { INIT_VNET_FOO(curvnet); /* prove we are ready to remove the module */ /* code here to do work required */ return 0; } #endif /* VIMAGE */ /* * Handle loading and unloading for this code. * The only thing we need to link into is the NETISR strucure. */ static int foo_mod_event(module_t mod, int event, void *data) { int error = 0; switch (event) { case MOD_LOAD: /* Initialize everything. */ /* put your code here */ #ifdef VIMAGE /* This will do the work for each vortual environment. */ vnet_mod_register(&vnet_foo_modinfo); #else /* !VIMAGE */ #ifdef FUTURE /* otherwise do the initialisation directly */ vnet_foo_iattach(NULL); #else /* !FUTURE */ /* otherwise the intialisation is done statically */ #endif /* !FUTURE */ #endif /* !VIMAGE */ break; case MOD_UNLOAD: /* You can't unload it because an interface may be using it. */ /* this needs work */ /* Should refuse to unload if any virtual environment */ /* are using this still. */ /* MARKO, fill in here */ error = EBUSY; break; default: error = EOPNOTSUPP; break; } return (error); } --------------030705070707060304090701-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 09:55:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3497106567C for ; Mon, 8 Dec 2008 09:55:21 +0000 (UTC) (envelope-from jiabwang@redhat.com) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by mx1.freebsd.org (Postfix) with ESMTP id 812438FC29 for ; Mon, 8 Dec 2008 09:55:21 +0000 (UTC) (envelope-from jiabwang@redhat.com) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mB89tLTV002551 for ; Mon, 8 Dec 2008 04:55:21 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mB89tKRa012281 for ; Mon, 8 Dec 2008 04:55:20 -0500 Received: from [10.66.65.20] (dhcp-65-20.nay.redhat.com [10.66.65.20]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mB89tIa1021113 for ; Mon, 8 Dec 2008 04:55:19 -0500 Message-ID: <493CEF35.7050009@redhat.com> Date: Mon, 08 Dec 2008 17:56:05 +0800 From: wang_jiabo User-Agent: Thunderbird 2.0.0.14 (X11/20080515) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Subject: [snmpd]could you tell me how to open upd6 port 161 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, 08 Dec 2008 09:55:21 -0000 Hello, all: could you help me how to open inet6 udp port 161 of snmpd agent as a listen port Thanks jiabo From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 10:16:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAE7A1065675 for ; Mon, 8 Dec 2008 10:16:51 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 77BEF8FC16 for ; Mon, 8 Dec 2008 10:16:51 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so413565eyi.7 for ; Mon, 08 Dec 2008 02:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=eePLHbckbbsqag/IQPm3HA3MM19VMUkiE1N1za1HCHU=; b=gDj98NEpu5m2mQA89WACg+KW3pIfbq5BiQFOlyOF+viegKs7LCE8Xbv3bO8QCuMFVW 1Sb3OPm5Ugz28dXNLbfErP6PXGuSRWQPB7HNOAhD0W3PIWc7KhztXDXu7VF9/5v2MbZf pSgyBdZxsYMwTTIUy8rKp+45/eTfoUswDj4tQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=le8d2xdorQQpAGwA0xMXYMd8N9zm/bSr8XU6w+CVFTaWkvoiOVJ0OTcWitmNbIvcWV itSUWyfB4YkOLuW5l+HatXYzsI6gy9eKinph2ZScoBDBCMV/Dig5TszSGa8wpcayYO7H irfiR3nDSv0Ih9giyVNXRPypmFTlIshf0JBgI= Received: by 10.210.66.1 with SMTP id o1mr3402200eba.174.1228731410117; Mon, 08 Dec 2008 02:16:50 -0800 (PST) Received: from localhost.localdomain ([213.152.137.42]) by mx.google.com with ESMTPS id 7sm1737363eyg.22.2008.12.08.02.16.48 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Dec 2008 02:16:49 -0800 (PST) Message-ID: <493CF424.4040206@gmail.com> Date: Mon, 08 Dec 2008 13:17:08 +0300 From: Vladimir Ermakov User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: pyunyh@gmail.com References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> <20081208004802.GB29560@cdnetworks.co.kr> In-Reply-To: <20081208004802.GB29560@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: vlan support trouble in if_sis 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: Mon, 08 Dec 2008 10:16:52 -0000 Pyun YongHyeon wrote: > Good. Would you show me the output of "pciconf -lcv"? > If I don't see any oddities in the output, I would commit the > patch. > > > what tests need to try? > > > > If parent interface sis0 still works as expected(i.e. without VLAN) > there is no need to test other cases, I guess. > > OK # pciconf -lvc ... sis0@pci0:0:4:0: class=0x020000 card=0xe0001458 chip=0x09001039 rev=0x90 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS900 sis 900 and integrated lan' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 ... /Vladimir Ermakov From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 11:07:00 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 152F61065673 for ; Mon, 8 Dec 2008 11:07:00 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0238F8FC1B for ; Mon, 8 Dec 2008 11:07:00 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB8B6x0S014339 for ; Mon, 8 Dec 2008 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB8B6x8o014335 for freebsd-net@FreeBSD.org; Mon, 8 Dec 2008 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Dec 2008 11:06:59 GMT Message-Id: <200812081106.mB8B6x8o014335@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 11:07:00 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working f kern/129074 net [ppp] [panic] kernel panic with pppoe_server o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o kern/128833 net [bge] Network packets corrupted when bge card is in 64 o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 196 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 16:21:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B8531065686 for ; Mon, 8 Dec 2008 16:21:39 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 033748FC18 for ; Mon, 8 Dec 2008 16:21:38 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5ACD71E339B; Mon, 8 Dec 2008 11:04:31 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 08 Dec 2008 11:04:31 -0500 X-Sasl-enc: jeY4L0jd03k748oW4D0kB5mNeJp8eleBDUnLcqt8spys 1228752270 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id BB3CED2C0; Mon, 8 Dec 2008 11:04:30 -0500 (EST) Message-ID: <493D458D.1000308@FreeBSD.org> Date: Mon, 08 Dec 2008 16:04:29 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.18 (X11/20081205) MIME-Version: 1.0 To: Julian Elischer References: <493CDF3C.5030608@elischer.org> In-Reply-To: <493CDF3C.5030608@elischer.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Vimage howto 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, 08 Dec 2008 16:21:39 -0000 Julian, Thank you (and Marko) very much for preparing this document. The VIMAGE import has had me at something of an impasse re: the IGMPv3 branch and clearly written documentation is a big help indeed. Julian Elischer wrote: > Well not completely, but I've had a number of questions over the > last few months about what it is, so, as Marko and I have written > the following "how to virtualize your module" document, I've been > directing people to it. After another couple of questions I think > this could do with wider distribition.. Thank you also for providing it here on the list, as opposed to relying on Perforce alone. Whilst I understand committers rate p4 for experimental work in the FreeBSD sphere, sadly it is simply not accessible to the not-so-silent majority in the FreeBSD sphere who are not committers, which makes its continued use questionable at best. regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 18:13:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD6151065672 for ; Mon, 8 Dec 2008 18:13:28 +0000 (UTC) (envelope-from espartano.mail@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 6EAC48FC13 for ; Mon, 8 Dec 2008 18:13:28 +0000 (UTC) (envelope-from espartano.mail@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so688744ugs.39 for ; Mon, 08 Dec 2008 10:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=upmNI13DKJa/cmAjRe0GvhpKAv/YRY6FhZn+3bz63sM=; b=w0H9J9sN8KpTPbpHHS9hD69MeFSUlJzsHI5FxbYaAaQoQWl7SsDLXcvNUsH2nXUQMo hAAzYaNn+WI4ZMFIYAv83IiE6dpiG228KM4gNL8UIn6k+/KkYkAKxBpAbqKgF80k6I9k lMGSs7t9jl7N5LXwSrGVqi9W15Akk5urVLrvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=nTPSSy0uAmdupxVmiXVHDeTMeMgEANyq/AWXsOl6mDbCneXG8nZAnPkQF6TBTxESWe i4l7BiVKOkpXou8J72hTMF4xaELSz6+GXDkiEwnxZ2q/5fZT+SOvauoq7PO+tPZxn97G nFXhokiqyqQQHGVcKsLYLstV27z+vw5Q7diKI= Received: by 10.86.100.19 with SMTP id x19mr2806338fgb.18.1228758676128; Mon, 08 Dec 2008 09:51:16 -0800 (PST) Received: by 10.86.62.18 with HTTP; Mon, 8 Dec 2008 09:51:16 -0800 (PST) Message-ID: Date: Mon, 8 Dec 2008 11:51:16 -0600 From: Espartano To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Driver Iwn in FreeBSD 7.1 ? 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, 08 Dec 2008 18:13:28 -0000 Hi list, Someone know if the driver iwn will be officially included in FreeBSD 7.1 ? -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 18:47:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 715BF1065673 for ; Mon, 8 Dec 2008 18:47:21 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id 403438FC17 for ; Mon, 8 Dec 2008 18:47:21 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1286970rvf.43 for ; Mon, 08 Dec 2008 10:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=CnCIwhjvxlC9qO9uABAwZaRa21OZZZ3mE+mVQVhX4Ks=; b=b34XKtKZl/sAb7bMniaJbkCmaYZG0XuWImBWDhBOPvMV6/XEtuh5tyYZRCg7HRAcSZ VdRQ5BEo9PbMojnC/YkgKVptLJbXwjH8R3+4JRZweBU79FAGEM4w4yVTYdnhGyOXDYsK lO9UgvvbBQk6wVro85UvUCcSpAWOCq4zfy17g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=sTvzdr/6sr2MluhPdfjg+3q8Eg99k1VYABszOiyIXwvToBh4+6uJ2Yr0xXqQuQyEli ulzhGoq3lzPTSAe3ymUyh8um1/ZMaB1hj+S0WUImZf7/0YlRkLIQZbTn1fU3wmiAEloK yobqJJnHXcEZE3aBl9a2GCxJfzzF44+iVMAVk= Received: by 10.140.141.16 with SMTP id o16mr1786542rvd.138.1228762040846; Mon, 08 Dec 2008 10:47:20 -0800 (PST) Received: from ?128.62.218.56? (w-mob400-128-62-218-56.public.utexas.edu [128.62.218.56]) by mx.google.com with ESMTPS id l31sm27130917rvb.2.2008.12.08.10.47.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Dec 2008 10:47:19 -0800 (PST) From: Ferner Cilloniz To: Julian Elischer In-Reply-To: <493CD98D.7000909@elischer.org> References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> <493CD98D.7000909@elischer.org> Content-Type: text/plain Date: Mon, 08 Dec 2008 12:47:17 +0000 Message-Id: <1228740437.4956.1.camel@mobiliare> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD kernel module and sending udp packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 18:47:21 -0000 Hi Julian. I'm very happy for your help. I have read the guide to netgraph and find it very interesting :) I still dont understand when you say "you could give your module a netgraph interface." Can you please explain this a little more please? Thanks. On Mon, 2008-12-08 at 00:23 -0800, Julian Elischer wrote: > Ferner Cilloniz wrote: > > Thanks for the reply. I read something about that but I didn't > > understand what was being said. > > > > Can you please help me in understanding. I have googled for sample code > > and didn't find anything useful. Can you, or anyone else, please help me > > understand this? > > http://people.freebsd.org/~julian/netgraph.html > > > > > Thanks again :) > > > > On Mon, 2008-12-08 at 00:07 -0800, Julian Elischer wrote: > >> Ferner Cilloniz wrote: > >>> Hello everyone. > >>> > >>> I need help with documentation concerning how to send a udp or tcp > >>> packet from a kernel module. I have found this information for Linux but > >>> not for FreeBSD. > >>> > >>> Please help me. > >> you could give your module a netgraph interface. Then it can connect > >> directly to the ng_ksocket node type and use that. as a nin-kernel socket. > >> > >> > >> > >>> Thank you :) > >>> > >>> _______________________________________________ > >>> 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" > > > -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 19:32:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 870561065670 for ; Mon, 8 Dec 2008 19:32:12 +0000 (UTC) (envelope-from prvs=julian=2217c4452@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 710D98FC1A for ; Mon, 8 Dec 2008 19:32:12 +0000 (UTC) (envelope-from prvs=julian=2217c4452@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 08 Dec 2008 11:03:10 -0800 Message-ID: <493D6F6E.4020900@elischer.org> Date: Mon, 08 Dec 2008 11:03:10 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Ferner Cilloniz References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> <493CD98D.7000909@elischer.org> <1228740437.4956.1.camel@mobiliare> In-Reply-To: <1228740437.4956.1.camel@mobiliare> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD kernel module and sending udp packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 19:32:12 -0000 Ferner Cilloniz wrote: > Hi Julian. I'm very happy for your help. I have read the guide to > netgraph and find it very interesting :) > > I still dont understand when you say "you could give your module a > netgraph interface." > > Can you please explain this a little more please? You indicated that you were going to be writing your own module. your module should include the interface functions indicated in ng_sample.c That will allow your module to be hooked up to the other netgraph modules in whatever orrder you want, and that includes the ng_ksocket module that would allow your module to sned and receive data through the in-kernel socket. > > Thanks. > > On Mon, 2008-12-08 at 00:23 -0800, Julian Elischer wrote: >> Ferner Cilloniz wrote: >>> Thanks for the reply. I read something about that but I didn't >>> understand what was being said. >>> >>> Can you please help me in understanding. I have googled for sample code >>> and didn't find anything useful. Can you, or anyone else, please help me >>> understand this? >> http://people.freebsd.org/~julian/netgraph.html >> >>> Thanks again :) >>> >>> On Mon, 2008-12-08 at 00:07 -0800, Julian Elischer wrote: >>>> Ferner Cilloniz wrote: >>>>> Hello everyone. >>>>> >>>>> I need help with documentation concerning how to send a udp or tcp >>>>> packet from a kernel module. I have found this information for Linux but >>>>> not for FreeBSD. >>>>> >>>>> Please help me. >>>> you could give your module a netgraph interface. Then it can connect >>>> directly to the ng_ksocket node type and use that. as an in-kernel socket. >>>> >>>> >>>> >>>>> Thank you :) >>>>> >>>>> _______________________________________________ >>>>> freebsd-net@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 21:05:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C202F1065672 for ; Mon, 8 Dec 2008 21:05:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 7A7DC8FC20 for ; Mon, 8 Dec 2008 21:05:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 82B4C41C64C; Mon, 8 Dec 2008 22:05:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id HcWUZ1XRNaDJ; Mon, 8 Dec 2008 22:05:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 1C78941C65E; Mon, 8 Dec 2008 22:05:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 564B24448DD; Mon, 8 Dec 2008 21:02:00 +0000 (UTC) Date: Mon, 8 Dec 2008 21:02:00 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Frank Behrens In-Reply-To: <200812031220.mB3CK204015947@post.behrens.de> Message-ID: <20081208205426.V80401@maildrop.int.zabbadoz.net> References: <200811280653.mAS6r1P3014050@post.behrens.de> <200812031220.mB3CK204015947@post.behrens.de> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Problem with new source address selection 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, 08 Dec 2008 21:05:06 -0000 On Wed, 3 Dec 2008, Frank Behrens wrote: Hi, > As I mentioned earlier I believe the main problem is IPSEC itself, > where we don't have an interface for tunneled connections. So I made > a workaround with a dummy loopback device. So I have a question to > the network specialists: Is there no other solution? Am I the only > stupid man, who wants to tunnel a subnet with private address range > via IPSEC? No, you aren't. Let me try to explain a bit further why I don't think it's an IPsec problem (at least not in first place). Asume you'd not run IPsec but communicate with the people directly (with valid IPs). Instead of having policies to control the traffic you are using simple IP filters on each side. So now in your network topology, with your setup, with the destination not being on a directly connected network, what would source address selection pick as outgoing IP (obviously w/o the hack with the route to the loopback)? Would that IP match your policy and thus would the peer permit it in its firewall? >> When it comes to the source address selection I am tempted to answer >> with: I am willing to still allow this in 7 to not break production >> setups but I am inclined to not change HEAD and keep the behavior >> dropped there. See patch below, which basically is what you had with >> the version check and the if (ia == NULL) check to not blindly overwrite >> if we had found anything closer (untested). > > Thanks, I will try this. I am still discussing things, or rather have the question queued with someone but we are all a bit busy atm. Did you try the patch and did it work for you as expected? If so I'll add it to my repo and the next jail patch. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 21:15:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF36F106564A for ; Mon, 8 Dec 2008 21:15:13 +0000 (UTC) (envelope-from ericx@vineyard.net) Received: from vineyard.net (k1.vineyard.net [204.17.195.90]) by mx1.freebsd.org (Postfix) with ESMTP id 89C5B8FC13 for ; Mon, 8 Dec 2008 21:15:13 +0000 (UTC) (envelope-from ericx@vineyard.net) Received: from localhost (loopback [127.0.0.1]) by vineyard.net (Postfix) with ESMTP id E2EC591521; Mon, 8 Dec 2008 15:57:41 -0500 (EST) X-Virus-Scanned: by AMaViS-king1 at Vineyard.NET Received: from vineyard.net ([127.0.0.1]) by localhost (king1.vineyard.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lAlpwY1Ro+Ck; Mon, 8 Dec 2008 15:57:41 -0500 (EST) Received: from [204.17.195.104] (fortiva.vineyard.net [204.17.195.104]) by vineyard.net (Postfix) with ESMTP id 9D15091504; Mon, 8 Dec 2008 15:57:41 -0500 (EST) Message-ID: <493D8A3F.6040502@vineyard.net> Date: Mon, 08 Dec 2008 15:57:35 -0500 From: "Eric W. Bates" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ipfw policy routing esp 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, 08 Dec 2008 21:15:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have a bewildering problem attempting to policy route esp traffic. We have 2 up steam internet sources: a routable T1 and a cable modem. The cable modem provides better bandwidth so while we default to the T1, we use policy routing to send some of our traffic out the cable modem. In particular we use the cable modem for all the port 80 traffic via squid. squid's source IP is the one belonging to the cable network and we have the following ipfw rule for the policy route: ${fwcmd} add 64902 fwd ${cable_gw} ip from ${net_wan3_local} to any cable_gw is the cable company's router. net_wan3_local is the cable company's IP on our external interface. This works great for all port 80 tcp traffic. To this we added some IPSec. Racoon is hanging off the same ${net_wan3_local} and the udp port 500 traffic passes in and out thru the cable interface as we hoped. The bewildering part is that while the esp traffic can demonstrably be seen to be hitting the policy route rule, those packets continue to pass out the default route to the T1 rather than being forwarded to the cable router as we want. Any thoughts? Is this a known problem? Thank you for your time. - -- Eric W. Bates ericx@vineyard.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJPYo/D1roJTQ4LlERAp//AJ9C5VFQWk0Q5iwKVD6elTItny8pLgCbB5Tn 9a3/ut3rswi7nPs10nCkk9s= =wW3o -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 21:15:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8AFD1065679 for ; Mon, 8 Dec 2008 21:15:13 +0000 (UTC) (envelope-from ericx@vineyard.net) Received: from vineyard.net (k1.vineyard.net [204.17.195.90]) by mx1.freebsd.org (Postfix) with ESMTP id 89DE08FC14 for ; Mon, 8 Dec 2008 21:15:13 +0000 (UTC) (envelope-from ericx@vineyard.net) Received: from localhost (loopback [127.0.0.1]) by vineyard.net (Postfix) with ESMTP id 1E55B91522 for ; Mon, 8 Dec 2008 16:06:27 -0500 (EST) X-Virus-Scanned: by AMaViS-king1 at Vineyard.NET Received: from vineyard.net ([127.0.0.1]) by localhost (king1.vineyard.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qJg59neyiwoy for ; Mon, 8 Dec 2008 16:06:26 -0500 (EST) Received: from [204.17.195.104] (fortiva.vineyard.net [204.17.195.104]) by vineyard.net (Postfix) with ESMTP id D9A0B91517 for ; Mon, 8 Dec 2008 16:06:26 -0500 (EST) Message-ID: <493D8C4C.5030105@vineyard.net> Date: Mon, 08 Dec 2008 16:06:20 -0500 From: "Eric W. Bates" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Fwd: ipfw policy routing esp] 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, 08 Dec 2008 21:15:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I forgot to mention: we are using 6.2-RELEASE-p1. - -------- Original Message -------- Subject: ipfw policy routing esp Date: Mon, 08 Dec 2008 15:57:35 -0500 From: Eric W. Bates To: freebsd-net@freebsd.org We have a bewildering problem attempting to policy route esp traffic. We have 2 up steam internet sources: a routable T1 and a cable modem. The cable modem provides better bandwidth so while we default to the T1, we use policy routing to send some of our traffic out the cable modem. In particular we use the cable modem for all the port 80 traffic via squid. squid's source IP is the one belonging to the cable network and we have the following ipfw rule for the policy route: ${fwcmd} add 64902 fwd ${cable_gw} ip from ${net_wan3_local} to any cable_gw is the cable company's router. net_wan3_local is the cable company's IP on our external interface. This works great for all port 80 tcp traffic. To this we added some IPSec. Racoon is hanging off the same ${net_wan3_local} and the udp port 500 traffic passes in and out thru the cable interface as we hoped. The bewildering part is that while the esp traffic can demonstrably be seen to be hitting the policy route rule, those packets continue to pass out the default route to the T1 rather than being forwarded to the cable router as we want. Any thoughts? Is this a known problem? Thank you for your time. - -- Eric W. Bates ericx@vineyard.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJPYxMD1roJTQ4LlERAoDTAKDJPqrxuz0hOPrAPJFS67Aduqw66gCgseE6 XOj2frj9zTFp70UcQcuBgQA= =qa+4 -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 21:53:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 994291065673 for ; Mon, 8 Dec 2008 21:53:59 +0000 (UTC) (envelope-from prvs=julian=2217c4452@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 845368FC17 for ; Mon, 8 Dec 2008 21:53:59 +0000 (UTC) (envelope-from prvs=julian=2217c4452@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 08 Dec 2008 13:54:00 -0800 Message-ID: <493D9777.8070508@elischer.org> Date: Mon, 08 Dec 2008 13:53:59 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: "Eric W. Bates" References: <493D8A3F.6040502@vineyard.net> In-Reply-To: <493D8A3F.6040502@vineyard.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ipfw policy routing esp 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, 08 Dec 2008 21:53:59 -0000 Eric W. Bates wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We have a bewildering problem attempting to policy route esp traffic. > > We have 2 up steam internet sources: a routable T1 and a cable modem. > The cable modem provides better bandwidth so while we default to the T1, > we use policy routing to send some of our traffic out the cable modem. > > In particular we use the cable modem for all the port 80 traffic via > squid. squid's source IP is the one belonging to the cable network and > we have the following ipfw rule for the policy route: > > ${fwcmd} add 64902 fwd ${cable_gw} ip from ${net_wan3_local} to any > > cable_gw is the cable company's router. > net_wan3_local is the cable company's IP on our external interface. > > This works great for all port 80 tcp traffic. > > To this we added some IPSec. Racoon is hanging off the same > ${net_wan3_local} and the udp port 500 traffic passes in and out thru > the cable interface as we hoped. > > The bewildering part is that while the esp traffic can demonstrably be > seen to be hitting the policy route rule, those packets continue to pass > out the default route to the T1 rather than being forwarded to the cable > router as we want. > > Any thoughts? > Is this a known problem. There are definitely some oddnesses with IPSEC encapsulation and routes etc. If you are using 7.1-PRERELEASE or 8 you might consider using setfib to assign a separate routing table to the tcp traffic. > > Thank you for your time. > > - -- > Eric W. Bates > ericx@vineyard.net > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJPYo/D1roJTQ4LlERAp//AJ9C5VFQWk0Q5iwKVD6elTItny8pLgCbB5Tn > 9a3/ut3rswi7nPs10nCkk9s= > =wW3o > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 22:05:17 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBA1B106564A; Mon, 8 Dec 2008 22:05:17 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A1E1D8FC08; Mon, 8 Dec 2008 22:05:17 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB8M5HmI020506; Mon, 8 Dec 2008 22:05:17 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB8M5HLu020502; Mon, 8 Dec 2008 22:05:17 GMT (envelope-from linimon) Date: Mon, 8 Dec 2008 22:05:17 GMT Message-Id: <200812082205.mB8M5HLu020502@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) 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, 08 Dec 2008 22:05:17 -0000 Old Synopsis: Kernel panic with EtherIP (may be related to SVN commit 178025) New Synopsis: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 8 22:04:09 UTC 2008 Responsible-Changed-Why: Possibly net-related. http://www.freebsd.org/cgi/query-pr.cgi?pr=129508 From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 22:21:48 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 881EA1065670 for ; Mon, 8 Dec 2008 22:21:48 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 304C38FC14 for ; Mon, 8 Dec 2008 22:21:47 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by an-out-0708.google.com with SMTP id b6so562185ana.13 for ; Mon, 08 Dec 2008 14:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=4Jd15gcpxlfb+8oqZOeA4Mn/1/yFoUCLAb7WcUlt21o=; b=wRTJ9XA17kbCjpS3ADhoL3YmkY73rPrclyXJzM7MU6M1IggO1/a3aO24i1vCtoT/U7 ElK1jah/YgGm9J1w+q9mLM1437I8giMKjC7BFunYuP6Y70vNpxnVJJbWFcuFyme0Ji9B 7O3JpfSOhvWMG7Es4x/NXPD9YQPn63GRVsdoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=Au6JWsetSS//aTT4sej8qKM1V1GxM2Bv8cSNQjJpmhfRMguaWNIgaxXBI+UQbUYvn6 yJdHNcFuBgg99az4e2UvViJ6QrK2P8hTsQWOxIal+9syvaHYuaGXq8meyHn3DtfDM0Cw Hhr75FCPKv/e2PA9YtK6Za+dhZS8El1tMEUvE= Received: by 10.100.207.14 with SMTP id e14mr1778095ang.60.1228774907005; Mon, 08 Dec 2008 14:21:47 -0800 (PST) Received: from ?192.168.2.2? (cpe-70-112-179-136.austin.res.rr.com [70.112.179.136]) by mx.google.com with ESMTPS id c23sm9301103ana.15.2008.12.08.14.21.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Dec 2008 14:21:45 -0800 (PST) From: Ferner Cilloniz To: Julian Elischer In-Reply-To: <493D6F6E.4020900@elischer.org> References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> <493CD98D.7000909@elischer.org> <1228740437.4956.1.camel@mobiliare> <493D6F6E.4020900@elischer.org> Content-Type: text/plain Date: Mon, 08 Dec 2008 16:21:44 +0000 Message-Id: <1228753304.4948.6.camel@mobiliare.Belkin> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD kernel module and sending udp packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 22:21:48 -0000 Yes I am writing my own loadable kernel module such that I can send a UDP packet when i tell it to by issuing a homemade system call. I have been looking at /usr/src/sys/netgraph/ng_sample.c Am i supposed to implement the functions in that file? I am a little lost. I only want to send a UDP packet and in that file I see functions concerning receiving. Is there any other way? Thanks Julian and everyone else. On Mon, 2008-12-08 at 11:03 -0800, Julian Elischer wrote: > Ferner Cilloniz wrote: > > Hi Julian. I'm very happy for your help. I have read the guide to > > netgraph and find it very interesting :) > > > > I still dont understand when you say "you could give your module a > > netgraph interface." > > > > Can you please explain this a little more please? > > > You indicated that you were going to be writing your own module. > your module should include the interface functions indicated in > ng_sample.c > > That will allow your module to be hooked up to the other netgraph > modules in whatever orrder you want, and that includes the ng_ksocket > module that would allow your module to sned and receive data through > the in-kernel socket. > > > > > > Thanks. > > > > On Mon, 2008-12-08 at 00:23 -0800, Julian Elischer wrote: > >> Ferner Cilloniz wrote: > >>> Thanks for the reply. I read something about that but I didn't > >>> understand what was being said. > >>> > >>> Can you please help me in understanding. I have googled for sample code > >>> and didn't find anything useful. Can you, or anyone else, please help me > >>> understand this? > >> http://people.freebsd.org/~julian/netgraph.html > >> > >>> Thanks again :) > >>> > >>> On Mon, 2008-12-08 at 00:07 -0800, Julian Elischer wrote: > >>>> Ferner Cilloniz wrote: > >>>>> Hello everyone. > >>>>> > >>>>> I need help with documentation concerning how to send a udp or tcp > >>>>> packet from a kernel module. I have found this information for Linux but > >>>>> not for FreeBSD. > >>>>> > >>>>> Please help me. > >>>> you could give your module a netgraph interface. Then it can connect > >>>> directly to the ng_ksocket node type and use that. as an in-kernel socket. > >>>> > >>>> > >>>> > >>>>> Thank you :) > >>>>> > >>>>> _______________________________________________ > >>>>> 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" > -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 22:22:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 835131065676 for ; Mon, 8 Dec 2008 22:22:28 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 49DE28FC14 for ; Mon, 8 Dec 2008 22:22:28 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 92639 invoked from network); 8 Dec 2008 21:55:46 -0000 Received: from unknown (HELO ?10.0.0.135?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 8 Dec 2008 21:55:46 -0000 Message-ID: <493D97D5.8090908@acm.poly.edu> Date: Mon, 08 Dec 2008 16:55:33 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.17 (X11/20081117) MIME-Version: 1.0 To: Eugene Grosbein , freebsd-net@freebsd.org References: <47C428EC.3090909@acm.poly.edu> <20080226162307.GA80931@svzserv.kemerovo.su> <47C4439A.9050502@acm.poly.edu> <20080226175616.GC1509@heff.fud.org.nz> <47C4FB54.FF2F89EF@kuzbass.ru> <48C00372.8030600@acm.poly.edu> <20080904164949.GA76939@svzserv.kemerovo.su> <4900D086.2000703@acm.poly.edu> <20081024042123.GA45452@svzserv.kemerovo.su> In-Reply-To: <20081024042123.GA45452@svzserv.kemerovo.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: if_gif/if_bridge 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: Mon, 08 Dec 2008 22:22:28 -0000 Eugene Grosbein wrote: > On Thu, Oct 23, 2008 at 03:29:10PM -0400, Boris Kochergin wrote: > > >> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:241 >> 241 dumptid = curthread->td_tid; >> (kgdb) where >> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:241 >> #1 0xc05583ef in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 >> #2 0xc0558861 in panic (fmt=Could not find the frame base for "panic". >> ) at /usr/src/sys/kern/kern_shutdown.c:563 >> #3 0xc07c033d in trap_fatal (frame=0xe9f3f63c, eva=12) at >> /usr/src/sys/i386/i386/trap.c:899 >> #4 0xc07bfee0 in trap_pfault (frame=0xe9f3f63c, usermode=0, eva=12) at >> /usr/src/sys/i386/i386/trap.c:812 >> #5 0xc07bf79d in trap (frame=0xe9f3f63c) at >> /usr/src/sys/i386/i386/trap.c:490 >> #6 0xc079ed4b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >> #7 0xc05bfb83 in m_copym (m=0x0, off0=1500, len=20, wait=1) at >> /usr/src/sys/kern/uipc_mbuf.c:538 >> #8 0xc065c536 in ip_fragment (ip=0xc60fabe8, m_frag=0xe9f3f7a8, >> mtu=1500, if_hwassist_flags=0, sw_csum=769) at >> /usr/src/sys/netinet/ip_output.c:726 >> #9 0xc065bf35 in ip_output (m=0xc60fab00, opt=0x0, ro=0xc589dd24, >> flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:565 >> #10 0xc064c431 in in_gif_output (ifp=0xc58a9000, family=18, >> m=0xc60fab00) at /usr/src/sys/netinet/in_gif.c:228 >> #11 0xc06321c3 in gif_output (ifp=0xc58a9000, m=0xc60f9900, >> dst=0xc58b52a0, rt=0x0) at /usr/src/sys/net/if_gif.c:455 >> #12 0xc0631e29 in gif_start (ifp=0xc58a9000) at >> /usr/src/sys/net/if_gif.c:352 >> #13 0xc06297a9 in bridge_enqueue (sc=0xc58d6600, dst_ifp=0xc58a9000, >> m=0x0) at /usr/src/sys/net/if_bridge.c:1714 >> #14 0xc062b80e in bridge_broadcast (sc=0xc58d6600, src_if=0xc58a3400, >> m=0xc60f9900, runfilt=1) at /usr/src/sys/net/if_bridge.c:2394 >> #15 0xc062a5e4 in bridge_forward (sc=0xc58d6600, sbif=0xc56f3600, >> m=0xc60f9900) at /usr/src/sys/net/if_bridge.c:2018 >> #16 0xc062af00 in bridge_input (ifp=0xc58a3400, m=0xc614e700) at >> /usr/src/sys/net/if_bridge.c:2189 >> #17 0xc06324dd in gif_input (m=0xc614e700, af=18, ifp=0xc58a3400) at >> /usr/src/sys/net/if_gif.c:564 >> #18 0xc064c89e in in_gif_input (m=0xc614e700, off=20) at >> /usr/src/sys/netinet/in_gif.c:326 >> #19 0xc0653f85 in encap4_input (m=0xc614e700, off=20) at >> /usr/src/sys/netinet/ip_encap.c:191 >> #20 0xc065819f in ip_input (m=0xc614e700) at >> /usr/src/sys/netinet/ip_input.c:665 >> #21 0xc06346ba in netisr_dispatch (num=2, m=0xc614e700) at >> /usr/src/sys/net/netisr.c:185 >> #22 0xc0630918 in ether_demux (ifp=0xc56bc000, m=0xc614e700) at >> /usr/src/sys/net/if_ethersubr.c:834 >> #23 0xc06306e2 in ether_input (ifp=0xc56bc000, m=0xc614e700) at >> /usr/src/sys/net/if_ethersubr.c:692 >> #24 0xc0704874 in xl_rxeof (sc=0xc56ed000) at /usr/src/sys/pci/if_xl.c:2062 >> #25 0xc070531e in xl_intr (arg=0xc56ed000) at /usr/src/sys/pci/if_xl.c:2298 >> #26 0xc05328a0 in ithread_execute_handlers (p=0xc56ec2ac, ie=0xc55e3d00) >> at /usr/src/sys/kern/kern_intr.c:1036 >> #27 0xc0532a63 in ithread_loop (arg=0xc56f2430) at >> /usr/src/sys/kern/kern_intr.c:1121 >> #28 0xc0530b8c in fork_exit (callout=0xc05329e0 , >> arg=0xc56f2430, frame=0xe9f3fd38) at /usr/src/sys/kern/kern_fork.c:781 >> #29 0xc079edc0 in fork_trampoline () at >> /usr/src/sys/i386/i386/exception.s:205 >> > > Very nice backtrace. If your system runs without patches, > you should send PR with all details included (system version, > interface configuration, backtrace and how-to-repeat recipe. > Please report back PR number once you get it. > > Eugene Grosbein > _______________________________________________ > 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" > I've encountered the problem on a machine running RELENG_7 without the patch and have filed a PR. Its number is 129508. Thanks. -Boris From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 23:22:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC8D5106568A for ; Mon, 8 Dec 2008 23:22:55 +0000 (UTC) (envelope-from prvs=julian=2217c4452@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id D5FBE8FC0C for ; Mon, 8 Dec 2008 23:22:55 +0000 (UTC) (envelope-from prvs=julian=2217c4452@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 08 Dec 2008 15:22:56 -0800 Message-ID: <493DAC50.5060501@elischer.org> Date: Mon, 08 Dec 2008 15:22:56 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Ferner Cilloniz References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> <493CD98D.7000909@elischer.org> <1228740437.4956.1.camel@mobiliare> <493D6F6E.4020900@elischer.org> <1228753304.4948.6.camel@mobiliare.Belkin> In-Reply-To: <1228753304.4948.6.camel@mobiliare.Belkin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD kernel module and sending udp packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 23:22:56 -0000 Ferner Cilloniz wrote: > Yes I am writing my own loadable kernel module such that I can send a > UDP packet when i tell it to by issuing a homemade system call. > > I have been looking at /usr/src/sys/netgraph/ng_sample.c > > Am i supposed to implement the functions in that file? I am a little > lost. I only want to send a UDP packet and in that file I see functions > concerning receiving. > > Is there any other way? > > Thanks Julian and everyone else. > If you won't receive, then just don't implement it :-) on the other hand if you are really only doing packet level output then maybe you would look at ng_source.c which simply acts as a source of packets you need to give a bit more details to what you want to do..\ From owner-freebsd-net@FreeBSD.ORG Mon Dec 8 23:29:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64DC3106564A for ; Mon, 8 Dec 2008 23:29:07 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 147128FC19 for ; Mon, 8 Dec 2008 23:29:06 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so568799yxb.13 for ; Mon, 08 Dec 2008 15:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=cgBf5v8auq4tswgxmFhwZIUGOF8y2q1hpS58jjzstAo=; b=kkVhzvfv1nIn2CV/ap3/L8FS/PMs2U5/E51B7UZNH0FYQDGk1QxbFWh1aHtWiBdMMv ZWUknmZIXJg6yeGRIhZKq+7BCu28X6w/xmA9APXcXRmB2LSPI8CORzngvTQ3bD65pfp8 UDeHmHZusckN08klsu/3zjSEx1jAaYJOVa1O4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=I37k5ZDNvOukly+I6IBldtORu+ufSZHxnFZ1B3b4TLhUH1sMulwcB73a0MEQ31VIs8 fXzUAMldwjhULUHo6KYb81gcV2Opmaq4jE1e912NiVlMap0S64Fd8fSFHWbJrKVNfZLy GAQyGfgEf4SuKKr93XHcjsxWkQ4P9XXaJ3FGw= Received: by 10.100.92.2 with SMTP id p2mr1814979anb.52.1228778946075; Mon, 08 Dec 2008 15:29:06 -0800 (PST) Received: from ?192.168.2.2? (cpe-70-112-179-136.austin.res.rr.com [70.112.179.136]) by mx.google.com with ESMTPS id c28sm6887111anc.47.2008.12.08.15.29.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Dec 2008 15:29:05 -0800 (PST) From: Ferner Cilloniz To: Julian Elischer In-Reply-To: <493DAC50.5060501@elischer.org> References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> <493CD98D.7000909@elischer.org> <1228740437.4956.1.camel@mobiliare> <493D6F6E.4020900@elischer.org> <1228753304.4948.6.camel@mobiliare.Belkin> <493DAC50.5060501@elischer.org> Content-Type: text/plain Date: Mon, 08 Dec 2008 17:29:04 +0000 Message-Id: <1228757344.4948.10.camel@mobiliare.Belkin> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD kernel module and sending udp packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 23:29:07 -0000 Julian, thank you for the reply and for the information :) What I am trying to is send data across the network. I have a created a system call such that i give it a string and the necesarry networking information and it will send it across the network. I just dont know where to start coding this because the information concerning this is very limited. Thank you. On Mon, 2008-12-08 at 15:22 -0800, Julian Elischer wrote: > /usr/src/sys/netgraph/ -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 04:05:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5570106564A for ; Tue, 9 Dec 2008 04:05:16 +0000 (UTC) (envelope-from espartano.mail@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 69F458FC16 for ; Tue, 9 Dec 2008 04:05:16 +0000 (UTC) (envelope-from espartano.mail@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1701354fgb.35 for ; Mon, 08 Dec 2008 20:05:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=CXxk3QNhiG3b4ldQHFkR9vujVS05WyKueFINzTnGHs4=; b=MTbCdFwSKjZ/k/BLYM8Dp73Zak/DnTOxX68r0I5PwCUCjdQWn2UvBg/ssq7seoxD/8 YvClMZd5xXV/bTDfiVX69qqofYOzeXMty8irISfWkHzHCNkXmkAJM3WKChoH7ZxQmMGD T0L3LModX88+qsPgkQToFdVmnfxjcDpSKsnAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=IHwP5SXHUNvIJjiZwl4di5otN/O97QgbGl19h46JQBtJS+S9z4Mj6WNZZ4Ml8GYE7p iTCkvinef0CcXyh+j4SLy1A6KSbSfgiy/nNJuIoyApwZ17kFEcybI05wKtdf8uxOHc3q 7vNkhRIJ/sxDQMp8HyBSCyl7W0B2246cZHxa0= Received: by 10.86.95.8 with SMTP id s8mr3047547fgb.79.1228795516157; Mon, 08 Dec 2008 20:05:16 -0800 (PST) Received: by 10.86.62.18 with HTTP; Mon, 8 Dec 2008 20:05:16 -0800 (PST) Message-ID: Date: Mon, 8 Dec 2008 22:05:16 -0600 From: Espartano To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: how to program a 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: Tue, 09 Dec 2008 04:05:16 -0000 hi people first and foremost apologize me for my bad english I have a little question, if i want to understand how work a net driver, what things i will need to learn? Actually i know how to program with C language in a basic level but i don't know nothing about hardware or computer organization, what topics i should study for gain knowledges about net-drivers ? or if someone can recommend me books about this topic i will be very thankful. thanks in advance. -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 04:31:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B28101065672 for ; Tue, 9 Dec 2008 04:31:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 7A3FB8FC17 for ; Tue, 9 Dec 2008 04:31:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1482820rvf.43 for ; Mon, 08 Dec 2008 20:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=eazfay8GmodgFP91cyVJUTkqIjOaKYCNDlmSJilLmhc=; b=I2rlq3E1XYvYcFzBzg6GZ7IvKHecjNRHyk51gHZkq42HKwZQmOwgWoBiJlk6ZLOr8z ZqV17b0XHyo6ocwP/ANIF7GYWJkZ73b1FYHPOOiKhhoSbaYLq6ctEeNywhUa8wyLu6cg NEAdHm/7pYoSD/ee+Se9r0/VMdqUb2OhD3P18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=oc+5TKz620Wr2/45Jyx3t9asGQ4ZjaMCNlct6jrYMqHCx3bzPaSImYZkzF763zOTry iUpHqBcEyXw5Z1R95hvOj6hTHOdk2rvas9DMGGsZg2GUs32SEcRIJUkPPNNAeU3ZYmOz LfH70UFQ9lvZMVn7Kku5w0h++O5/WXl0561qo= Received: by 10.140.226.14 with SMTP id y14mr2035431rvg.59.1228797099157; Mon, 08 Dec 2008 20:31:39 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k37sm8917006rvb.1.2008.12.08.20.31.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Dec 2008 20:31:38 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mB94VWFG034551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 13:31:32 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mB94VUSb034550; Tue, 9 Dec 2008 13:31:30 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 9 Dec 2008 13:31:30 +0900 From: Pyun YongHyeon To: Vladimir Ermakov Message-ID: <20081209043130.GC33723@cdnetworks.co.kr> References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> <20081208004802.GB29560@cdnetworks.co.kr> <493CF424.4040206@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <493CF424.4040206@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: vlan support trouble in if_sis driver ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 04:31:39 -0000 On Mon, Dec 08, 2008 at 01:17:08PM +0300, Vladimir Ermakov wrote: > Pyun YongHyeon wrote: > >Good. Would you show me the output of "pciconf -lcv"? > >If I don't see any oddities in the output, I would commit the > >patch. > > > > > what tests need to try? > > > > > > >If parent interface sis0 still works as expected(i.e. without VLAN) > >there is no need to test other cases, I guess. > > > > > OK > > # pciconf -lvc > ... > sis0@pci0:0:4:0: class=0x020000 card=0xe0001458 chip=0x09001039 > rev=0x90 hdr=0x00 > vendor = 'Silicon Integrated Systems (SiS)' > device = 'SiS900 sis 900 and integrated lan' > class = network > subclass = ethernet > cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 > ... > Thanks. Patch committed to HEAD(r185784). -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 05:04:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5EA8106564A for ; Tue, 9 Dec 2008 05:04:42 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5CD118FC18 for ; Tue, 9 Dec 2008 05:04:42 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 964E328449 for ; Tue, 9 Dec 2008 13:04:41 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id DBC94EC22B1; Tue, 9 Dec 2008 13:04:40 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id fn0oC-4d0AJu; Tue, 9 Dec 2008 13:04:36 +0800 (CST) Received: from charlie.delphij.net (c-67-180-38-12.hsd1.ca.comcast.net [67.180.38.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id D7E04EC1CC3; Tue, 9 Dec 2008 13:04:34 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=bmKNhEhh3W3k4uQmpDrL3nnbi8+HCy3E76Xgr+1glFvRaH3LLPbql7fyLEN0PG2Wz zUm25tzfH0RTDCrojSr0w== Message-ID: <493DFC60.2040305@delphij.net> Date: Mon, 08 Dec 2008 21:04:32 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Espartano References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: how to program a driver? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 05:04:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Espartano wrote: > hi people first and foremost apologize me for my bad english I have a > little question, if i want to understand how work a net driver, what > things i will need to learn? > > Actually i know how to program with C language in a basic level but i > don't know nothing about hardware or computer organization, what > topics i should study for gain knowledges about net-drivers ? or if > someone can recommend me books about this topic i will be very > thankful. I think you need some understanding on how the hardware is composed into a computer system, usually this is taught in freshmen days for a CS or EE major, and it's possible to learn yourself. Basically, NIC drivers implement common interfaces like probe, transfer data, callback when data is received, etc., this part would be easier if you do understand how things works and have data sheets at your hand. There is a book available to give you some ideas about how to write code for FreeBSD Kernel, <> which would help you to understand the basic concepts, etc. My personal suggestion is to start from a simple network driver and try start to get knowledge by tweaking some stuff and see what would happen. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk9/GAACgkQi+vbBBjt66Cv4wCfVKw9Wkqfzr/dQcqlQ6zQUDI6 DDYAn3UIGWs7RBw1VF+M4iHzlI8ZKTpq =8FQC -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 07:04:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47ABF1065678 for ; Tue, 9 Dec 2008 07:04:01 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id C51E68FC19 for ; Tue, 9 Dec 2008 07:04:00 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so608436eyi.7 for ; Mon, 08 Dec 2008 23:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=qp2W4jynYg6O3EI7ApHvrQA52Opy6iTQUVkT28sPwSs=; b=VbPjMn7TUK84uLAjt5hPUQ5Bh7yVWUiK2ql+UQyRa/WNKttelLkcH617GJiwGeiy2N QXhIGa1PqW2Sy6nitUKxaaD6/mhC5f0jT9GckwLSMZjS3NzeoF5N4UjR3Mh7Hz4+8hgR 8AvkfrWj/Oht0tqoiHuqnwHE2/JRKpJYyR3T0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Wc4WYNW8i3JeCU566kmYZjp/MErcarfN/iCNI7jzb8p9hlTzu8vllWoDeV7lNG+mA8 aHTV6bEOqtWKgZ47k1eKpMfk6yAk7DqqM7OqVjM44YnQ0wumSYy+GXY2S20qgu2Vyfw8 7AfvgxV3miYnVS/X2fQwPF/exBNJJziqNHLLI= Received: by 10.210.27.20 with SMTP id a20mr4541329eba.137.1228806239386; Mon, 08 Dec 2008 23:03:59 -0800 (PST) Received: from localhost.localdomain ([213.152.137.42]) by mx.google.com with ESMTPS id 3sm7028210eyj.41.2008.12.08.23.03.57 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Dec 2008 23:03:58 -0800 (PST) Message-ID: <493E1872.9010306@gmail.com> Date: Tue, 09 Dec 2008 10:04:18 +0300 From: Vladimir Ermakov User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: pyunyh@gmail.com References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> <20081208004802.GB29560@cdnetworks.co.kr> <493CF424.4040206@gmail.com> <20081209043130.GC33723@cdnetworks.co.kr> In-Reply-To: <20081209043130.GC33723@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: vlan support trouble in if_sis 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: Tue, 09 Dec 2008 07:04:01 -0000 Pyun YongHyeon wrote: > On Mon, Dec 08, 2008 at 01:17:08PM +0300, Vladimir Ermakov wrote: > > Pyun YongHyeon wrote: > > >Good. Would you show me the output of "pciconf -lcv"? > > >If I don't see any oddities in the output, I would commit the > > >patch. > > > > > > > what tests need to try? > > > > > > > > > >If parent interface sis0 still works as expected(i.e. without VLAN) > > >there is no need to test other cases, I guess. > > > > > > > > OK > > > > # pciconf -lvc > > ... > > sis0@pci0:0:4:0: class=0x020000 card=0xe0001458 chip=0x09001039 > > rev=0x90 hdr=0x00 > > vendor = 'Silicon Integrated Systems (SiS)' > > device = 'SiS900 sis 900 and integrated lan' > > class = network > > subclass = ethernet > > cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 > > ... > > > > Thanks. Patch committed to HEAD(r185784). > > MFC? /Vladimir Ermakov From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 08:42:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DD83106564A for ; Tue, 9 Dec 2008 08:42:44 +0000 (UTC) (envelope-from mlists08@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by mx1.freebsd.org (Postfix) with ESMTP id CBFB28FC16 for ; Tue, 9 Dec 2008 08:42:43 +0000 (UTC) (envelope-from mlists08@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so3929253fkk.11 for ; Tue, 09 Dec 2008 00:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=zuh1Pqc9uVInoRf2cOCqsN6aJ1NDZjcwLUQjUnVJldE=; b=evza8jbpgwegugbflLZl0IpEnO6HcPh89CMfLIUogD3DEA6rUPaoiW52isa1zP7GNn 2nIZ9cVhmrws9Wtk7ZJ0AOGTxwOSul2b2D61l0iHF81k/M0KzmonKBegpR9KIt3Fnb7i UraVWVATDb0Wp4zcIBEUi/QYq8aw5RImdsmpk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=XnObpsCTXrLxAcCB0lXHUERj56/St8KfKKGY8GFa8zNB6TIyPibHAIbv+3bjy+Cup/ H+SteTZ5n1rdNuMC6eKiZdjzXI3hPH0EFjIYJWya3KgKMZNOIzD3XbJUq/W9LqsPfPsG OxQggS8ks8er+BV8hfYCcYLXeMiwaACXHvCXU= Received: by 10.180.232.9 with SMTP id e9mr1552413bkh.198.1228810869671; Tue, 09 Dec 2008 00:21:09 -0800 (PST) Received: from midnight ([87.120.162.66]) by mx.google.com with ESMTPS id c28sm16506101fka.10.2008.12.09.00.21.05 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Dec 2008 00:21:08 -0800 (PST) Message-ID: <007a01c959d7$015f8e10$146ea8c0@midnight> From: "oklahoma" To: References: <493CEF35.7050009@redhat.com> Date: Tue, 9 Dec 2008 10:20:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: [snmpd]could you tell me how to open upd6 port 161 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, 09 Dec 2008 08:42:44 -0000 ----- Original Message ----- From: "wang_jiabo" To: Sent: Monday, December 08, 2008 11:56 AM Subject: [snmpd]could you tell me how to open upd6 port 161 > Hello, all: > could you help me how to open inet6 udp port 161 of snmpd agent as a > listen port Basically just start the deamon as root and it will listen to it's assigned by default port. If you want to change the port on wich snmpd listens - look around the configuration file for such option. If you have firewall - make appropriate rule set to allow in/out traffic to this port. It will be usefull to know what firewall you use. From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 08:50:00 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50A191065672; Tue, 9 Dec 2008 08:50:00 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 275418FC17; Tue, 9 Dec 2008 08:50:00 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB98o0Wa037068; Tue, 9 Dec 2008 08:50:00 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB98o0WX037064; Tue, 9 Dec 2008 08:50:00 GMT (envelope-from linimon) Date: Tue, 9 Dec 2008 08:50:00 GMT Message-Id: <200812090850.mB98o0WX037064@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/129517: [ipsec] [panic] double fault / stack overflow 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, 09 Dec 2008 08:50:00 -0000 Old Synopsis: Ipsec / panic: double fault / stack overflow New Synopsis: [ipsec] [panic] double fault / stack overflow Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Dec 9 08:49:40 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129517 From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 08:56:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F02E9106564A for ; Tue, 9 Dec 2008 08:56:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id C64E18FC0C for ; Tue, 9 Dec 2008 08:56:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 14A981E4A7A; Tue, 9 Dec 2008 03:56:16 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 09 Dec 2008 03:56:16 -0500 X-Sasl-enc: lfNhfZ81vAwJsYHL/VeWmx9rXx8gzRoRPRH0cxoUqDG6 1228812975 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7C5782B0B9; Tue, 9 Dec 2008 03:56:15 -0500 (EST) Message-ID: <493E32AE.5040907@FreeBSD.org> Date: Tue, 09 Dec 2008 08:56:14 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.18 (X11/20081205) MIME-Version: 1.0 To: Espartano References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: how to program a 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: Tue, 09 Dec 2008 08:56:17 -0000 Espartano wrote: > Actually i know how to program with C language in a basic level but i > don't know nothing about hardware or computer organization, what > topics i should study for gain knowledges about net-drivers ? or if > someone can recommend me books about this topic i will be very > thankful. > Try "The Indispensable PC Hardware Book" by Hans-Peter Messmer for a general overview of PC architecture. cheers BMS From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 09:20:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7963E1065672 for ; Tue, 9 Dec 2008 09:20:05 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4158FC14 for ; Tue, 9 Dec 2008 09:20:05 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id C7CA71E49A3; Tue, 9 Dec 2008 04:20:04 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 09 Dec 2008 04:20:04 -0500 X-Sasl-enc: Vv0WfW3vfRe49PWzpU6Qp/9pGUWKnw1JrzzLyJ1Pg91Z 1228814404 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 43E2C318B4; Tue, 9 Dec 2008 04:20:04 -0500 (EST) Message-ID: <493E3842.7030100@FreeBSD.org> Date: Tue, 09 Dec 2008 09:20:02 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.18 (X11/20081205) MIME-Version: 1.0 To: Espartano References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: how to program a 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: Tue, 09 Dec 2008 09:20:05 -0000 [Resend to list for everyone] Espartano wrote: > Actually i know how to program with C language in a basic level but i > don't know nothing about hardware or computer organization, what > topics i should study for gain knowledges about net-drivers ? or if > someone can recommend me books about this topic i will be very > thankful. > The seminal work is TCP/IP Illustrated Volume 2 (Gary Wright and W. Richard Stevens, Addison-Wesley). Whilst dated it will give you an overview of how all the parts in the BSD networking stack fit together. It really needs to be updated, however enough things are in flux right now that summarising all the changes would be difficult until say after FreeBSD 8.0 dust is settled. For computer architecture, probably best to learn PC architecture these days -- x86 is here to stay, kids, and Netbooks are something of a reactionary response triggered by the One-Laptop-Per-Child (OLPC) project. In my day, I learned 68000 assembly and C on the Amiga. Hans-Peter Messmer's "The Indispensable PC Hardware Book" is a huge book which cost me about 50 GBP new when I first bought it -- I was working in a reasonably well paid job at the time, but it can be found second hand no doubt around the world. Cover to cover it will tell you what you need to know about how the PC architecture fits together, but if you need more detail e.g. on stuff like FreeBSD network drivers, again, it's best to refer back to the source code itself. Hope this helps. cheers BMS From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 12:50:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C535106564A for ; Tue, 9 Dec 2008 12:50:29 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from mail.bestunion.it (mail.bestunion.it [85.18.201.87]) by mx1.freebsd.org (Postfix) with ESMTP id BA11A8FC08 for ; Tue, 9 Dec 2008 12:50:28 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from [192.168.44.66] (adsl-ull-141-22.51-151.net24.it [151.51.22.141]) (authenticated bits=0) by mail.lan.bestunion.it (8.14.3/8.14.3) with ESMTP id mB9CcLGD061343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Dec 2008 13:38:28 +0100 (CET) (envelope-from aturetta@commit.it) Message-ID: <493E66BD.6090907@commit.it> Date: Tue, 09 Dec 2008 13:38:21 +0100 From: Angelo Turetta User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on mail.bestunion.it X-Virus-Status: Clean Subject: Multiple routing table clarification 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, 09 Dec 2008 12:50:29 -0000 I need to run squid, serving different networks with different (potentially conflicting) IP address schemes. I read the original implementation notes for setfib/multiple routing tables: http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/julian/routing/plan.txt and I would like to ask for some clarifications: - is it possible for a single process to listen for TCP connections using more than one socket, each with its own 'fib'? - if I use ipfw rules to tag incoming traffic, can I force the fib on a incoming TCP connection to be different from the fib of the process/socket listening for that connection? Thanks for any help (oh, BTW, if somewhere more detailed howto/doc about this feature can be found, please forward any pointers) Angelo. From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 17:46:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3081B1065673; Tue, 9 Dec 2008 17:46:59 +0000 (UTC) (envelope-from csjp@freebsd.org) Received: from mx-02queue01.mts.net (mx-02queue01.mts.net [142.161.131.10]) by mx1.freebsd.org (Postfix) with ESMTP id AB4AE8FC08; Tue, 9 Dec 2008 17:46:58 +0000 (UTC) (envelope-from csjp@freebsd.org) Received: from wnpgmb021pw-sp03.mts.net ([10.204.128.23]) by mx-02mtaout02.mts.net with ESMTP id <20081209172904.KEHE3962.mx-02mtaout02.mts.net@wnpgmb021pw-sp03.mts.net>; Tue, 9 Dec 2008 11:29:04 -0600 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4EAK05PkmOoT/O/2dsb2JhbACBbM9ggwc X-IronPort-AV: E=Sophos;i="4.33,742,1220245200"; d="diff'?scan'208";a="49824639" Received: from wnpgmb1309w-ad05-63-206.dynamic.mts.net (HELO jnz.my.domain) ([142.161.63.206]) by wnpgmb021pw-sp03.mts.net with ESMTP; 09 Dec 2008 11:29:04 -0600 Received: from jnz.my.domain (localhost [127.0.0.1]) by jnz.my.domain (8.14.2/8.14.2) with ESMTP id mB9HT3iV072942; Tue, 9 Dec 2008 11:29:04 -0600 (CST) (envelope-from csjp@jnz.my.domain) Received: (from csjp@localhost) by jnz.my.domain (8.14.2/8.14.2/Submit) id mB9HT350072941; Tue, 9 Dec 2008 11:29:03 -0600 (CST) (envelope-from csjp) Date: Tue, 9 Dec 2008 11:29:03 -0600 From: Christian Peron To: freebsd-net@freebsd.org Message-ID: <20081209172903.GA72817@jnz.sqrt.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: imp@freebsd.org Subject: [patch] link state notifications for tun(4) 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, 09 Dec 2008 17:46:59 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I would like to propose a change for tun(4) but before I do, I would like to read any feedback this list might have. Basically we have a situation where we need to manually configure tunnel interfaces when a process opens them. We would like to hook into devd(8) for this. i.e. when we see tunX "linkup" call ifconfig as well, add some routes. The trouble is, tun(4) does not generate linkup/linkdown events. We would consider the tun device to be linked up when a process has it open, and linked down when the process closes it. Thoughts? --gBBFr7Ir9EOA20Yy Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="tun.diff" Index: if_tun.c =================================================================== --- if_tun.c (revision 185712) +++ if_tun.c (working copy) @@ -426,6 +426,7 @@ tp->tun_flags |= TUN_OPEN; mtx_unlock(&tp->tun_mtx); ifp = TUN2IFP(tp); + if_link_state_change(ifp, LINK_STATE_UP); TUNDEBUG(ifp, "open\n"); return (0); @@ -482,6 +483,7 @@ ifp->if_drv_flags &= ~IFF_DRV_RUNNING; splx(s); } + if_link_state_change(ifp, LINK_STATE_DOWN); CURVNET_RESTORE(); funsetown(&tp->tun_sigio); --gBBFr7Ir9EOA20Yy-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 17:58:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36C19106564A for ; Tue, 9 Dec 2008 17:58:57 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp01.cdmon.com (smtp01.cdmon.com [212.36.75.232]) by mx1.freebsd.org (Postfix) with ESMTP id ED3BA8FC1D for ; Tue, 9 Dec 2008 17:58:56 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) by smtp01.cdmon.com (Postfix) with ESMTP id 92C33F75AC for ; Tue, 9 Dec 2008 18:40:29 +0100 (CET) Message-ID: <493EAD8B.8040605@minibofh.org> Date: Tue, 09 Dec 2008 18:40:27 +0100 From: Jordi Espasa Clofent User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: start_if. comments X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 17:58:57 -0000 Hi all, I'm testing the use of /etc/start_if. instead the classical 'ifconfig....' in /etc/rc.conf. All seems work fine, but if I comment a line in /etc/start_if., any interface is loaded by the system! If I use $ cat /etc/start_if.nfe0 /sbin/ifconfig $1 inet netmask 255.255.254.0 /sbin/ifconfig $1 alias netmask 0xffffffff /sbin/ifconfig $1 alias netmask 0xffffffff all works fine. But if I use $ cat /etc/start_if.nfe0 /sbin/ifconfig $1 inet netmask 255.255.254.0 #/sbin/ifconfig $1 alias netmask 0xffffffff /sbin/ifconfig $1 alias netmask 0xffffffff any nfe0 associated interface is loaded! I don't understand this issue, because according to rc.conf: "If the /etc/start_if. file is present, it is read and executed by the sh(1) interpreter before configuring the interface as specified in the ifconfig_ and ifconfig__alias variables." and all of us know that sh(1) symbol of comment is always '#' żIs it normal or is it a bug? -- Thanks, Jordi Espasa Clofent From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 18:00:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ABB61065677 for ; Tue, 9 Dec 2008 18:00:28 +0000 (UTC) (envelope-from prvs=julian=2224d921f@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 05DC18FC08 for ; Tue, 9 Dec 2008 18:00:27 +0000 (UTC) (envelope-from prvs=julian=2224d921f@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.95]) by smtp-outbound.ironport.com with ESMTP; 09 Dec 2008 09:31:59 -0800 Message-ID: <493EAB8F.7090509@elischer.org> Date: Tue, 09 Dec 2008 09:31:59 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Angelo Turetta References: <493E66BD.6090907@commit.it> In-Reply-To: <493E66BD.6090907@commit.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Multiple routing table clarification 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, 09 Dec 2008 18:00:28 -0000 Angelo Turetta wrote: > I need to run squid, serving different networks with different > (potentially conflicting) IP address schemes. > > I read the original implementation notes for setfib/multiple routing > tables: > http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/julian/routing/plan.txt > > > and I would like to ask for some clarifications: > > - is it possible for a single process to listen for TCP connections > using more than one socket, each with its own 'fib'? yes, but only if you have source. you need to do a setsockopt(SOO_SETFIB,...) on each socket before you do the listen(). Otherwise all socekts from the same process get the same fib. > > - if I use ipfw rules to tag incoming traffic, can I force the fib on a > incoming TCP connection to be different from the fib of the > process/socket listening for that connection? no, the fib for a socket is set by the process that does the listen. HOWEVER I have been asked to add a feature where setting a fib of -1 on a socket will allow it to get its fib from the incoming SYN packet.. Ithink that would bewhat you are asking for. > > Thanks for any help (oh, BTW, if somewhere more detailed howto/doc about > this feature can be found, please forward any pointers) man 2 setsockopt man 1 setfib man 2 setfib > > Angelo. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 18:06:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56AC11065670 for ; Tue, 9 Dec 2008 18:06:53 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from mail.bestunion.it (mail.bestunion.it [85.18.201.87]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD8A8FC14 for ; Tue, 9 Dec 2008 18:06:51 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from [192.168.44.66] (adsl-ull-141-22.51-151.net24.it [151.51.22.141]) (authenticated bits=0) by mail.lan.bestunion.it (8.14.3/8.14.3) with ESMTP id mB9I6a9P070704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 19:06:45 +0100 (CET) (envelope-from aturetta@commit.it) Message-ID: <493EB3A7.40108@commit.it> Date: Tue, 09 Dec 2008 19:06:31 +0100 From: Angelo Turetta User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Julian Elischer References: <493E66BD.6090907@commit.it> <493EAB8F.7090509@elischer.org> In-Reply-To: <493EAB8F.7090509@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on mail.bestunion.it X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Multiple routing table clarification 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, 09 Dec 2008 18:06:53 -0000 Julian Elischer wrote: > Angelo Turetta wrote: >> - is it possible for a single process to listen for TCP connections >> using more than one socket, each with its own 'fib'? > > yes, but only if you have source. you need to do a > setsockopt(SOO_SETFIB,...) on each socket before you do the listen(). > Otherwise all socekts from the same process get the same fib. OK, shouldn't be too hard to hack squid for this. > HOWEVER I have been asked to add a feature where setting a fib of -1 > on a socket will allow it to get its fib from the incoming SYN packet.. > Ithink that would bewhat you are asking for. Yes, please! It would be much more general-purpose than hacking squid, of course if -1 be supported by setfib too... I can help test a patch on RELENG_7, whenever "someone" writes it ;-) Thanks a lot, Angelo Turetta From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 19:39:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C09F1065672 for ; Tue, 9 Dec 2008 19:39:02 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id B55B88FC0C for ; Tue, 9 Dec 2008 19:39:01 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so65346ywe.13 for ; Tue, 09 Dec 2008 11:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=XfXSJl7LDBrhBL46X3eDxyDJ7B9gvZTkgWQcCObT00M=; b=mTZ1adcbkSOrmQKa3JTCo62Adiu8Qt8EvZElRUIiAupC/BrEgTIkcTk1FN36IvoxUm NN0pVDbVdhNAYPINy0S+UCMGMtBdqB/SR3bG4s6kson2m9HZOkuvMVIBqL7DmtlFBatx aK/eU4VL6lKbZ5JaL2A1tCBj32czHyQjjkVA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=cdGuNIxXFIPpd2kUQcAJbTiH4HN0ak24dOGj9fPQATFYOgODq0Z0VKnauhrXyC1D7c FlXrYPY20XGpqnA5yo3NgE1WjHxiCDrWHi6Ze2XIRpXZ8CmwHO0ycZdnBXw8Op3vVl5e KFeJfoaUDx0EoNGKLQRW420SOfxVM/Mcb8xgg= Received: by 10.100.197.3 with SMTP id u3mr467393anf.64.1228851540879; Tue, 09 Dec 2008 11:39:00 -0800 (PST) Received: from ?192.168.2.2? (cpe-70-112-179-136.austin.res.rr.com [70.112.179.136]) by mx.google.com with ESMTPS id c14sm408774ana.18.2008.12.09.11.38.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Dec 2008 11:39:00 -0800 (PST) From: Ferner Cilloniz To: freebsd-net@freebsd.org Content-Type: text/plain Date: Tue, 09 Dec 2008 13:38:58 +0000 Message-Id: <1228829938.4948.27.camel@mobiliare.Belkin> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Subject: kldload telling not finding .ko file when it is indeed there 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, 09 Dec 2008 19:39:02 -0000 Hi everyone. I'm running into a problem where kldload is reporting that my .ko file is not found when it is indeed there. It is strange because when i comment out a call to the function sotoinpcb(struct socket *) it finds the .ko file and loads, but when i uncomment that line and try to load it, kldload reports that the .ko file is not found. What is going on? Thanks :) -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From owner-freebsd-net@FreeBSD.ORG Tue Dec 9 19:59:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 137B3106564A for ; Tue, 9 Dec 2008 19:59:46 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id D25F88FC12 for ; Tue, 9 Dec 2008 19:59:45 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.166.46] ([68.0.14.34]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id mB9JxicD020571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 14:59:44 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Ferner Cilloniz In-Reply-To: <1228829938.4948.27.camel@mobiliare.Belkin> References: <1228829938.4948.27.camel@mobiliare.Belkin> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-tm8M4BEICAWlXM4QI6QR" Organization: FreeBSD Date: Tue, 09 Dec 2008 14:59:35 -0500 Message-Id: <1228852775.9860.20.camel@squirrel.corp.cox.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-net@freebsd.org Subject: Re: kldload telling not finding .ko file when it is indeed there 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, 09 Dec 2008 19:59:46 -0000 --=-tm8M4BEICAWlXM4QI6QR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-12-09 at 13:38 +0000, Ferner Cilloniz wrote: > Hi everyone. >=20 > I'm running into a problem where kldload is reporting that my .ko file > is not found when it is indeed there. >=20 > It is strange because when i comment out a call to the function > sotoinpcb(struct socket *) it finds the .ko file and loads, but when i > uncomment that line and try to load it, kldload reports that the .ko > file is not found. >=20 > What is going on? I expect that the load is failing due to an undefined symbol and the error is just being obfuscated. robert. > Thanks :) >=20 --=-tm8M4BEICAWlXM4QI6QR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkk+zicACgkQM4TrQ4qfROPN9QCfcPv6mHCw8hVFz5e9D/vPMpds ntQAnjqJrhcM/V8fealWsN/UmtVzylfV =rXjX -----END PGP SIGNATURE----- --=-tm8M4BEICAWlXM4QI6QR-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 10 06:14:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06B6D106567C for ; Wed, 10 Dec 2008 06:14:31 +0000 (UTC) (envelope-from yamamoto436@oki.com) Received: from gwf1.oki.co.jp (gwf1.oki.co.jp [202.226.91.186]) by mx1.freebsd.org (Postfix) with ESMTP id C10848FC0C for ; Wed, 10 Dec 2008 06:14:30 +0000 (UTC) (envelope-from yamamoto436@oki.com) Received: by gwf1.oki.co.jp (Postfix, from userid 0) id E4235CF9F1; Wed, 10 Dec 2008 14:43:38 +0900 (JST) Received: from unknown [172.26.101.117] by gwf1.oki.co.jp with ESMTP id QAA12054; Wed, 10 Dec 2008 14:43:38 +0900 Received: from s111h117.dm1.oii.oki.co.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 044023A8004; Wed, 10 Dec 2008 14:43:36 +0900 (JST) Received: from aoi.bmc.oki.co.jp (aoi.bmc.oki.co.jp [172.19.235.54]) by s111h117.dm1.oii.oki.co.jp (Postfix) with ESMTP id E24743A8002; Wed, 10 Dec 2008 14:43:35 +0900 (JST) Received: from tulip.bmc.oki.co.jp (tulip [172.19.236.119]) by aoi.bmc.oki.co.jp (8.13.1/8.13.1) with ESMTP id mBA5hZt5018642; Wed, 10 Dec 2008 14:43:35 +0900 Received: from localhost (tulip.bmc.oki.co.jp [172.19.236.119]) by tulip.bmc.oki.co.jp (8.14.3/8.13.6) with ESMTP id mBA5hZMG039427; Wed, 10 Dec 2008 14:43:35 +0900 (JST) (envelope-from yamamoto436@oki.com) Date: Wed, 10 Dec 2008 14:43:34 +0900 (JST) Message-Id: <20081210.144334.88509243.yamamoto436@oki.com> To: freebsd-net@freebsd.org From: Hideki Yamamoto X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: watanabe439@oki.com Subject: MLDv2 on FreeBSD 7 (mcastread cannot work well) 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, 10 Dec 2008 06:14:31 -0000 Hi, I have compiled mcast-tools on FreeBSD 7. When running mcastread to send join to MLDv2 available router, the command output as follows: "Can't allocate socket" It seems that KERNEL cannot support MLDv2, source specific multicast on my environment. Are there any special kernel paramters to turn on MLDv2? Or are there any further documment on this matter? Thanks in advance. Best regards, Hideki Yamamoto ----------------------------------------------------------------------- Hideki YAMAMOTO yamamoto436@oki.com Software Development Department- 4, Development Division, OKI Networks Co., Ltd. (http://www.oki-networks.com/) Tel: +81-48-420-7012 FAX: +81-48-420-7138 ----------------------------------------------------------------------- From owner-freebsd-net@FreeBSD.ORG Wed Dec 10 06:14:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 561F0106564A for ; Wed, 10 Dec 2008 06:14:44 +0000 (UTC) (envelope-from stutiredboy@gmail.com) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id EFF3F8FC1E for ; Wed, 10 Dec 2008 06:14:43 +0000 (UTC) (envelope-from stutiredboy@gmail.com) Received: by gxk12 with SMTP id 12so412904gxk.19 for ; Tue, 09 Dec 2008 22:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=xU/WZwKag0XEej8ZuQu4vE142vB8fT0LzlTwZUfAweQ=; b=j5Gmys3eQdRbF8qQJ378r9c7WgoHZNbtnYyhBziNRUo4ccmeGLWkqGVqnHAcDLsbaF hrhYaG75YleAfEfdSza6iHwRc0j6d9kmjBUxPu/jI4d1EwtzP4nOsJmbMtBPADnTAgXu HP1rldtmI5EKRqMuMIUPkZjTp3B15JedMplEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=f2xieEaWO3gJ3OiB40Mr/1O1AAlcXg3RhAJW+Ovo3pvkzctHjhdTJB7aS8R3kchMQR Ued4MK6j81YEX1DuZ++s7p5T1svPshGjiu8YYsZdo1Hp0VKEz4ZRzI+A5naLRL07awFU xSMGAxkMjgkMuNiYYZtfk9tDYdHhA96ArEjl8= Received: by 10.151.144.15 with SMTP id w15mr1500708ybn.6.1228888131500; Tue, 09 Dec 2008 21:48:51 -0800 (PST) Received: by 10.150.98.17 with HTTP; Tue, 9 Dec 2008 21:48:51 -0800 (PST) Message-ID: Date: Wed, 10 Dec 2008 13:48:51 +0800 From: "=?GB2312?B?s8LQocn6?=" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [help]strange problem about gethostbyname/getaddrinfo 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, 10 Dec 2008 06:14:44 -0000 hi,all,we have a project which must resolv some domains in the server process our system in FreeBSD 6.2 or 6.3, the server process may open 7000+ sockets,not fork we have set the maxopensockets as 65536,as follows: kern.ipc.numopensockets: 4737 kern.ipc.maxsockets: 65536 socket: 356, 65538, 4737, 6747, 64793968 and the follow is our limit info: cputime unlimited filesize unlimited datasize 2621440 kbytes stacksize 65536 kbytes coredumpsize unlimited memoryuse unlimited vmemoryuse unlimited descriptors 655000 memorylocked unlimited maxproc 5547 sbsize unlimited I am sure we have set the /etc/reslov.conf correctly, I can resolve any legal domain use dig or gethostbyname or getaddrinfo in my another test program The problem is we found when the server porcess open 1000+ or higher sockets(but we can query any legal domain in the system normally), the gethostbyname or getaddrinfo might fetch nothing(sometimes the query is ok), the gethostbyname's return error is: errno=2,strerror=Host name lookup failure and the getaddrinfo's return error is: "hostname nor servname provided, or not known", /* EAI_NONAME */ we have tried to use the tcpdump to analyse the query packets, unluckily , we catch nothing, seem like that the program does not query anything(or get none dns server,even 127.0.0.1) , neither using gethostbyname nor getaddrinfo,and we also try set the query type as tcp and udp, the same disappointment result. The stranger thing is we have tried to run another demo process which have open 4000+ sockets, all work well..so the problem might not related to open too much sockets..and we found that, even we set the /etc/resolve.conf nothing, normally the gethostbyname/getaddrinfo will check 127.0.0.1, and we can get the query packets The server process's query is under a single process not multi threads Can anyone help me analyse the error/problem, which may raise this situation or any useful info, thanks very much ! From owner-freebsd-net@FreeBSD.ORG Wed Dec 10 07:04:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A053106564A for ; Wed, 10 Dec 2008 07:04:37 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp01.cdmon.com (smtp01.cdmon.com [212.36.75.232]) by mx1.freebsd.org (Postfix) with ESMTP id E0E728FC1F for ; Wed, 10 Dec 2008 07:04:36 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from jespasac.minibofh.org (unknown [84.77.66.237]) by smtp01.cdmon.com (Postfix) with ESMTP id 122D4F7613 for ; Wed, 10 Dec 2008 08:04:35 +0100 (CET) Message-ID: <493F69F6.9060802@minibofh.org> Date: Wed, 10 Dec 2008 08:04:22 +0100 From: Jordi Espasa Clofent User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <493EAD8B.8040605@minibofh.org> In-Reply-To: <493EAD8B.8040605@minibofh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: start_if. comments [SOLVED] 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, 10 Dec 2008 07:04:37 -0000 It seems that I'd the file open with ee(1) when I forced a reboot during my tests. Surely the fsck process deleted the file. If I re-create the file, all seems ok. Rare but true. -- Thanks, Jordi Espasa Clofent From owner-freebsd-net@FreeBSD.ORG Wed Dec 10 07:40:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0172F1065670; Wed, 10 Dec 2008 07:40:53 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E240E8FC17; Wed, 10 Dec 2008 07:40:52 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from freefall.freebsd.org (qingli@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBA7eqHB034925; Wed, 10 Dec 2008 07:40:52 GMT (envelope-from qingli@freefall.freebsd.org) Received: (from qingli@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBA7eqjO034924; Wed, 10 Dec 2008 07:40:52 GMT (envelope-from qingli) Date: Wed, 10 Dec 2008 07:40:52 GMT From: Qing Li Message-Id: <200812100740.mBA7eqjO034924@freefall.freebsd.org> To: current@freebsd.org Cc: freebsd-net@freebsd.org Subject: last call for L2/L3 rewrite code review 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, 10 Dec 2008 07:40:53 -0000 As you know the L2+L3 rewrite project (aka arp-v2) for both ARP and ND6 has been active for quite some time now. In a nutshell, the work removes the L2 tables (ARP and ND6) from the L3 routing table. This redesign simplifies the routing code and completely eliminates the route cloning concept. I discussed about this work at BSDCan 2007 and again at the recent devsummit at Google. I have requested code review and feedback since last May. It's becoming increasingly difficult to maintain a separate branch (p4 or svn) due to the high volume of new features' related commits. The integration and unit testing efforts increase in complexity by the week. We (Julian, Sam, Kip, Robert and I) discussed about a possible commit timeframe during the devsummit. And it seems now is as good as any because we all have overcommitted ourselves, and frankly speaking unless the feature is fully committed, getting the thorough code review and broader testing is simply unrealistic. I have been running the new arp-v2 kernel as a regular production machine on a daily basis, however, I am certain my testing is insufficient, which is another good reason to get the feature into the official -current tree. Putting a closure on this work will allow me to focus on developing additional networking features and completing my other backlog tasks for the project. Although the code will continue to evolve, on the other hand, the code is stable enough that I believe it is ready for general (-CURRENT) consumption. I would like to commit the code within a week if not sooner. Again, I would like to ask for your review and feedback. Flaming is fine, which I prefer getting the flames now rather than later. Quite a few developers have contributed to this project in the past: Glebius Smirnoff, Luigi Rizzo, Alessandro Cerri, and Andre Oppermann. And most recently: - Kip Macy revised the locking code completely, thus completing the last piece of the puzzle, Kip has also been conducting active functional testing - Sam Leffler has helped me improving/refactoring the code, and provided valuable reviews - Julian Elischer setup the perforce tree for me and has helped me maintaining that branch The latest patch that is generated out of Perforce without Kip Macy's locking modification is at http://people.freebsd.org/~qingli/arp-v2-p4-diff The complete P4 project tree is located at //depot/projects/arp-v2 The full project sits in the svn branch that is located at svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 Once this code is fully committed into -CURRENT, I will be on standby to fix any arp/nd6 related bugs. Kip Macy will be on standby to fix any locking related issues. Kip will also be acting as my backup when I'd be out partying. Thanks, -- Qing mailto: qingli@freebsd.org From owner-freebsd-net@FreeBSD.ORG Wed Dec 10 07:58:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 990F3106564A for ; Wed, 10 Dec 2008 07:58:41 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 3412E8FC0C for ; Wed, 10 Dec 2008 07:58:40 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id C736FB0380C2 for ; Wed, 10 Dec 2008 02:58:39 -0500 (EST) Thread-Index: AclanRylrvC/+HYfR6+3LR41qsXklA== Received: from limbo.int.dllstx01.us.it.verio.net ([10.10.10.11]) by iad-wprd-xchw01.corp.verio.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Dec 2008 02:58:39 -0500 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id EF33E8E295; Wed, 10 Dec 2008 01:58:38 -0600 (CST) Date: Wed, 10 Dec 2008 01:58:38 -0600 Content-Transfer-Encoding: 7bit From: "David DeSimone" To: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Importance: normal Priority: normal Message-ID: <20081210075838.GB12948@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Precedence: bulk User-Agent: Mutt/1.5.9i X-OriginalArrivalTime: 10 Dec 2008 07:58:39.0296 (UTC) FILETIME=[1C998C00:01C95A9D] Subject: Re: [help]strange problem about gethostbyname/getaddrinfo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 07:58:41 -0000 wrote: > > The problem is we found when the server porcess open 1000+ or higher > sockets(but we can query any legal domain in the system normally), the > gethostbyname or getaddrinfo might fetch nothing(sometimes the query > is ok), the gethostbyname's return error is: errno=2,strerror=Host > name lookup failure It sounds like the resolver library is running into a 1024-descriptor limit. From select(2): NOTES The default size of FD_SETSIZE is currently 1024. In order to accommo- date programs which might potentially use a larger number of open files with select(), it is possible to increase this size by having the program define FD_SETSIZE before the inclusion of any header which includes . Unfortunately you might have to rebuild the resolver library itself in order for it to be able to query file descriptors larger than 1024. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Wed Dec 10 08:14:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E58501065673 for ; Wed, 10 Dec 2008 08:14:37 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (unknown [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9DBF08FC0C for ; Wed, 10 Dec 2008 08:14:37 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ume@ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id mBA8EPim050110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 17:14:31 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 10 Dec 2008 17:14:25 +0900 Message-ID: From: Hajimu UMEMOTO To: "David DeSimone" In-Reply-To: <20081210075838.GB12948@verio.net> References: <20081210075838.GB12948@verio.net> User-Agent: xcite1.58> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.3 (amd64-portbld-freebsd7.1) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 7.1-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Wed, 10 Dec 2008 17:14:31 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org Subject: Re: [help]strange problem about gethostbyname/getaddrinfo 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, 10 Dec 2008 08:14:38 -0000 Hi, >>>>> On Wed, 10 Dec 2008 01:58:38 -0600 >>>>> "David DeSimone" said: fox> It sounds like the resolver library is running into a 1024-descriptor fox> limit. From select(2): Our resolver doesn't use select(2) but use kqueue(2). So, we don't have this limitation. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Wed Dec 10 08:28:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14C00106564A; Wed, 10 Dec 2008 08:28:20 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id B27978FC1E; Wed, 10 Dec 2008 08:28:19 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=keSpl9tdPK79Ej23nSOnP3111KEqk+B781DzzTKtIAlR39s7qHK/BOo5CgIIt+EeQe9thvnN6HaCWiHpqpmc89/AY2wdp5TQgH3Htl4ANT5gF0Nhl05fxdNuDE2KiJ42ABNiSuq+Z4vf/29eqYgpPmHiRuuSA1cYbJl/WXv28Wc=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1LAKQc-0002ZL-Dn; Wed, 10 Dec 2008 11:28:18 +0300 Date: Wed, 10 Dec 2008 11:28:17 +0300 From: Eygene Ryabinkin To: VANHULLEBUS Yvan Message-ID: References: <49349E26.30002@redhat.com> <20081203082549.GA62889@zeninc.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YttKMwf6abDJOSyE" Content-Disposition: inline In-Reply-To: <20081203082549.GA62889@zeninc.net> Sender: rea-fbsd@codelabs.ru Cc: freebsd-net@freebsd.org, Christian Weisgerber , gnn@freebsd.org Subject: Re: [ipsec] aes-ctr question 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, 10 Dec 2008 08:28:20 -0000 --YttKMwf6abDJOSyE Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yvan, good day. Wed, Dec 03, 2008 at 09:25:49AM +0100, VANHULLEBUS Yvan wrote: > On Wed, Dec 03, 2008 at 10:54:55AM +0300, Eygene Ryabinkin wrote: > [...] > > Good catch. Perhaps setkey should be extended to warn the user about > > this neat. The patch is attached. George, people, what do you think > > about it? >=20 > If we're going to add security warnings in setkey, we could just put a > warning when using static keys (so basically put a warning for "add" > command....). In general -- you're perfectly right: people should use IKE and company. But CTR mode is particularily evil in respect to the nonce sinsitivity: for the given key and initialization vector it will produce the same gamma (running key in English terminology) used for encryption and decryption. But we seem to be more-or-less safe here: IV is generated randomly, so one will have 2^64 different initialization vectors for a single passphrase. Sooo, the issue seems to be of a less value, but still -- it is here. And for passive attacker who has access to all CTR mode sessions with static keys will be rather simple to analyze for the gamma coincidence: providing that the first bytes of the packets to be encrypted are the same (think UDP/TCP header of something simular), then it should just XOR the stream beginnings and wait when the bits that correspond to the same (constant) bits of the payload will be zeroed. Sufficient number of zeros will indicate gamma coincidence and one can focus on further fun with such streams. Of course, I may be missing something. --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --YttKMwf6abDJOSyE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk/faEACgkQthUKNsbL7YjQ5wCgtIylNp1663zN1UAqaSguoOj2 RJAAoKDTQmFOZ0SOi6mwpWCI8RAUEYh5 =agz9 -----END PGP SIGNATURE----- --YttKMwf6abDJOSyE-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 10 09:10:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 837E81065670 for ; Wed, 10 Dec 2008 09:10:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3805A8FC1B for ; Wed, 10 Dec 2008 09:10:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 3623C41C615; Wed, 10 Dec 2008 10:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 52ZzB2rBQcmu; Wed, 10 Dec 2008 10:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id D762941C62F; Wed, 10 Dec 2008 10:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 0FF4D4448DD; Wed, 10 Dec 2008 09:09:59 +0000 (UTC) Date: Wed, 10 Dec 2008 09:09:59 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Qing Li In-Reply-To: <200812100740.mBA7eqjO034924@freefall.freebsd.org> Message-ID: <20081210090429.G97918@maildrop.int.zabbadoz.net> References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, FreeBSD current mailing list Subject: Re: last call for L2/L3 rewrite code review 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, 10 Dec 2008 09:10:08 -0000 On Wed, 10 Dec 2008, Qing Li wrote: Hi, > It's becoming increasingly difficult to maintain a separate > branch (p4 or svn) due to the high volume of new features' > related commits. The integration and unit testing efforts > increase in complexity by the week. [..] > I would like to commit the code within > a week if not sooner. I think waiting another few days would be good, so end of the weekend or something seems realistic, but not so before. The reason I am asking is that people are still seeing panics from the rnh locking and aren't even able to boot machines. Mixng route locking bugs with this rewrite will be painful. As I hope that the rnh bugs will be solved within 2-3 days things would be good for getting this monster in:) > The complete P4 project tree is located at > > //depot/projects/arp-v2 > > The full project sits in the svn branch that is located at > > svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 Which of the two is the one to track the next days or are you going to keep them in sync? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Wed Dec 10 09:30:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 209FD106567A for ; Wed, 10 Dec 2008 09:30:36 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id E34BE8FC26 for ; Wed, 10 Dec 2008 09:30:35 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so321174rvf.43 for ; Wed, 10 Dec 2008 01:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=IQWAr2//dmZ7s4JNLSsg4MIAV1LfhLmqcaB/N0tApFU=; b=PwbjpLM0T1EpDIdU+jBis2zoRPKmo2wEgzzkIMeF5+68QqITreYbZRdcR1iZl5hCZk Xa8lpi4DcsDXF58eZu2zxZXMSOHFNiqUBC614AwEmmn0bwU0YL7S1/WXstvMpRkbfLwp SR12GYTZyllGSELM/Y2x3NYTQhlafUQQKYnrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=qGrM6WjhuLLHoJJC27rzPNRzynj0+AmSKP2e5U/W3m0sSHcdDtivXIWtvyxp1HJs2l mOS1D8vQJj5AgyfO2oaLHe4XCMoKEHEXSnUVfevZjfv7dgHiikFzPGfsspHiE7Ixw07m 2QPvreZzh42dlRy7Gh2o9pFjpYCDslPQeR5DE= Received: by 10.140.158.4 with SMTP id g4mr557447rve.160.1228901435578; Wed, 10 Dec 2008 01:30:35 -0800 (PST) Received: by 10.141.142.3 with HTTP; Wed, 10 Dec 2008 01:30:35 -0800 (PST) Message-ID: <3c1674c90812100130y5433403akc68f72a5086b921c@mail.gmail.com> Date: Wed, 10 Dec 2008 01:30:35 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Bjoern A. Zeeb" In-Reply-To: <20081210090429.G97918@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> <20081210090429.G97918@maildrop.int.zabbadoz.net> X-Google-Sender-Auth: 7b65664b5d1bd8ef Cc: Qing Li , FreeBSD current mailing list , freebsd-net@freebsd.org Subject: Re: last call for L2/L3 rewrite code review 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, 10 Dec 2008 09:30:36 -0000 > The reason I am asking is that people are still seeing panics from > the rnh locking and aren't even able to boot machines. I have not seen this. Please tell me where this occurs. > Mixng route > locking bugs with this rewrite will be painful. As I hope that the > rnh bugs will be solved within 2-3 days things would be good for > getting this monster in:) To the best of my knowledge, the few bugs that have occurred have been fixed within a day of them being reported. >> svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 > > Which of the two is the one to track the next days or are you going to > keep them in sync? > The svn branch will be the one that is kept up to date with all fixes. I will be IFC'ing in to it once a day. Thanks, Kip From owner-freebsd-net@FreeBSD.ORG Wed Dec 10 10:21:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1B081065670; Wed, 10 Dec 2008 10:21:20 +0000 (UTC) (envelope-from zec@icir.org) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by mx1.freebsd.org (Postfix) with ESMTP id 4EFB58FC1C; Wed, 10 Dec 2008 10:21:20 +0000 (UTC) (envelope-from zec@icir.org) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id mBAA9sgo021825; Wed, 10 Dec 2008 11:09:54 +0100 (CET) Received: from [192.168.200.110] ([161.53.19.79]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Dec 2008 11:09:21 +0100 From: Marko Zec To: freebsd-net@freebsd.org Date: Wed, 10 Dec 2008 11:09:14 +0100 User-Agent: KMail/1.9.7 References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> <20081210090429.G97918@maildrop.int.zabbadoz.net> <3c1674c90812100130y5433403akc68f72a5086b921c@mail.gmail.com> In-Reply-To: <3c1674c90812100130y5433403akc68f72a5086b921c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812101109.14851.zec@icir.org> X-OriginalArrivalTime: 10 Dec 2008 10:09:21.0300 (UTC) FILETIME=[5ECC6540:01C95AAF] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Cc: FreeBSD current mailing list , "Bjoern A. Zeeb" , Kip Macy , Qing Li Subject: Re: last call for L2/L3 rewrite code review 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, 10 Dec 2008 10:21:20 -0000 On Wednesday 10 December 2008 10:30:35 Kip Macy wrote: > > The reason I am asking is that people are still seeing panics from > > the rnh locking and aren't even able to boot machines. > > I have not seen this. Please tell me where this occurs. I had a machine with defaultrouter from /etc/rc.conf pointing to a gateway which wasn't directly reachable, so the machine would panic before going multiuser. Nevertheless I can confirm that your change 185849 just resolved this issue, thanks a lot for a quick fix! Marko > > Mixng route > > locking bugs with this rewrite will be painful. As I hope that the > > rnh bugs will be solved within 2-3 days things would be good for > > getting this monster in:) > > To the best of my knowledge, the few bugs that have occurred have > been fixed within a day of them being reported. > > >> svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 > > > > Which of the two is the one to track the next days or are you going > > to keep them in sync? > > The svn branch will be the one that is kept up to date with all > fixes. I will be IFC'ing in to it once a day. > > Thanks, > Kip > _______________________________________________ > 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 Dec 11 11:10:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A45C31065677 for ; Thu, 11 Dec 2008 11:10:34 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from smtp.teledomenet.gr (smtp.teledomenet.gr [213.142.128.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5EC148FC08 for ; Thu, 11 Dec 2008 11:10:34 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: by smtp.teledomenet.gr (Postfix, from userid 58) id CFD9314209A; Thu, 11 Dec 2008 12:51:21 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on smtp.teledomenet.gr X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 Received: from iris.teledomenet.local (unknown [192.168.1.71]) by smtp.teledomenet.gr (Postfix) with ESMTP id CCC1114205A for ; Thu, 11 Dec 2008 12:51:18 +0200 (EET) From: Nikos Vassiliadis To: freebsd-net@freebsd.org Date: Thu, 11 Dec 2008 12:50:37 +0200 User-Agent: KMail/1.9.10 X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812111250.38046.nvass@teledomenet.gr> Subject: ng_bridge + ng_ksocket 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, 11 Dec 2008 11:10:34 -0000 Hello, I would like to create an ethernet over UDP tunnel. For my purposes, using ng_bridge and ng_ksocket seem fine. The problem is that the peer address/port is not known, since it will be behind a NAT device and will have a dynamically assigned IP address. In userspace I would use something like recvfrom() to get the peer address. I don't know what to do for ngctl and ng_ksocket. Any suggestions? Is this doable? Is there something I can do to circumvent the problem? Thanks in advance, Nikos From owner-freebsd-net@FreeBSD.ORG Thu Dec 11 12:28:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02CC21065672 for ; Thu, 11 Dec 2008 12:28:29 +0000 (UTC) (envelope-from nrml@att.net) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by mx1.freebsd.org (Postfix) with SMTP id CF3958FC16 for ; Thu, 11 Dec 2008 12:28:28 +0000 (UTC) (envelope-from nrml@att.net) Received: (qmail 16732 invoked from network); 11 Dec 2008 12:01:48 -0000 Received: from unknown (HELO Inbox) (nrml@173.117.132.218 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 11 Dec 2008 12:01:47 -0000 X-YMail-OSG: MY1KCJ8VM1kXXhY0W2bp.t8plyfyegTgQk1pBLxdHd.y1zh.6My_xtY.8Y6JvaSu1iXMYBTE.8CjiMZ_yYH0ARO3W8qOf7UvAUtMlvmD7LpDVN.j9TEpFtz84yXxCTLmTAc- X-Yahoo-Newman-Property: ymail-3 MIME-Version: 1.0 content-class: From: Gabe Date: Thu, 11 Dec 2008 04:02:01 -0800 Importance: normal X-Priority: 3 To: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Message-Id: <20081211122828.CF3958FC16@mx1.freebsd.org> Subject: NAT-T + ipsec integration 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, 11 Dec 2008 12:28:29 -0000 Hello all Does anyone know how to enable nat traversal on freebsd? I've got a site to site ipsec tunnel setup but clients behind the nat can't= vpn through it. Any help would be appreciated. Thanks /gabe= From owner-freebsd-net@FreeBSD.ORG Thu Dec 11 12:39:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F1D310656D5 for ; Thu, 11 Dec 2008 12:39:41 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5FCD78FC08 for ; Thu, 11 Dec 2008 12:39:41 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 653DB2798B8; Thu, 11 Dec 2008 13:39:39 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id C193217054; Thu, 11 Dec 2008 13:39:58 +0100 (CET) Date: Thu, 11 Dec 2008 13:39:58 +0100 From: VANHULLEBUS Yvan To: Gabe Message-ID: <20081211123958.GA5332@zeninc.net> References: <20081211122828.CF3958FC16@mx1.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081211122828.CF3958FC16@mx1.freebsd.org> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: NAT-T + ipsec integration 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, 11 Dec 2008 12:39:41 -0000 On Thu, Dec 11, 2008 at 04:02:01AM -0800, Gabe wrote: > Hello all Hi. > Does anyone know how to enable nat traversal on freebsd? > > I've got a site to site ipsec tunnel setup but clients behind the > nat can't vpn through it. Any help would be appreciated. Actually, you can apply a patch to src/sys and recompile your kernel with IPSEC_NAT_T options. Patches are available here: http://people.freebsd.org/~vanhu/NAT-T/ You can also try to play with Perforce's branch, but it is still work in progress to have a cleaned up version of PFKey interface (it may work, but I just started to set up some testing hosts). To answer the question some people may ask in this thread: the whole patch should be included in TRUNK as soon as PFKey cleanup will be done (which means "implemented + heavilly tested + reviewed"). Yvan. From owner-freebsd-net@FreeBSD.ORG Thu Dec 11 12:50:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E81161065672 for ; Thu, 11 Dec 2008 12:50:41 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 7FABC8FC17 for ; Thu, 11 Dec 2008 12:50:41 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mBBCoeOP099217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 11 Dec 2008 07:50:40 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1228999840; h=Message-Id:From:To:In-Reply-To:Content-Type: Mime-Version:Subject:Date:References:X-Mailer; b=p6Tt01SimSQEYYSqo0 +5olaZKHbzBExlSxmBG7S8CPgF+YI7RZ2UezFzactNljknNnha/IKILM4h3E1mPKBPc g== Message-Id: <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> From: Randall Stewart To: freebsd-net In-Reply-To: <200811201450.30016.max@love2party.net> Content-Type: multipart/mixed; boundary=Apple-Mail-25--562946916 Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 11 Dec 2008 07:50:39 -0500 References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> X-Mailer: Apple Mail (2.929.2) Subject: Heads up --- Thinking about UDP and tunneling 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, 11 Dec 2008 12:50:42 -0000 --Apple-Mail-25--562946916 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All: Ok here is what I have come up with.. going along the lines of Max's suggestion.. its pretty clean I think. Comments would be most welcome.. The only thing possibly a bit dodgy is that 1) UDP has no per-protocol block. 2) Instead of creating one, I am using the block pointer in the inp as the function pointer for the tunneling. What this means if we EVERY did add a per protocol structure for UDP we would need to move the function pointer in there.. The nice thing it does is make it so we have no structural changes to the code... i.e. complete compatibility... no changes to inp or other UDP structures :-) Here is the patch.. please send comments ;-D --Apple-Mail-25--562946916 Content-Disposition: attachment; filename=diff_for_udp Content-Type: application/octet-stream; x-unix-mode=0644; name="diff_for_udp" Content-Transfer-Encoding: 7bit Index: netinet/udp_var.h =================================================================== --- netinet/udp_var.h (revision 185928) +++ netinet/udp_var.h (working copy) @@ -107,6 +107,10 @@ void udp_input(struct mbuf *, int); struct inpcb *udp_notify(struct inpcb *inp, int errno); int udp_shutdown(struct socket *so); + + +typedef void(*udp_tunnel_function)(struct mbuf *, int off); +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function f); #endif #endif Index: netinet/udp_usrreq.c =================================================================== --- netinet/udp_usrreq.c (revision 185928) +++ netinet/udp_usrreq.c (working copy) @@ -563,6 +563,18 @@ INP_RUNLOCK(inp); goto badunlocked; } + if (inp->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function tunnel_func; + tunnel_func = (udp_tunnel_function)inp->inp_ppcb; + INP_RUNLOCK(inp); + tunnel_func(m, iphlen); + return; + } udp_append(inp, ip, m, iphlen + sizeof(struct udphdr), &udp_in); INP_RUNLOCK(inp); return; @@ -1138,10 +1150,45 @@ INP_INFO_WUNLOCK(&V_udbinfo); inp->inp_vflag |= INP_IPV4; inp->inp_ip_ttl = V_ip_defttl; + /* + * UDP does not have a per-protocol + * pcb (inp->inp_ppcb). We use this + * pointer for kernel tunneling pointer. + * If we ever need to have a protocol + * block we will need to move this + * function pointer there. Null + * in this pointer means "do the normal + * thing". + */ + inp->inp_ppcb = NULL; INP_WUNLOCK(inp); return (0); } +int +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function f) +{ + struct inpcb *inp; + inp = (struct inpcb *)so->so_pcb; + + if (so->so_type != SOCK_DGRAM) { + /* Not UDP socket... sorry */ + return (ENOTSUP); + } + if (inp == NULL) { + /* NULL INP? */ + return (EINVAL); + } + if (inp->inp_lport == 0) { + /* Not bound */ + return (EINVAL); + } + INP_WLOCK(inp); + inp->inp_ppcb = f; + INP_WUNLOCK(inp); + return (0); +} + static int udp_bind(struct socket *so, struct sockaddr *nam, struct thread *td) { Index: netinet6/udp6_usrreq.c =================================================================== --- netinet6/udp6_usrreq.c (revision 185928) +++ netinet6/udp6_usrreq.c (working copy) @@ -354,6 +354,18 @@ } INP_RLOCK(inp); INP_INFO_RUNLOCK(&V_udbinfo); + if (inp->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function tunnel_func; + tunnel_func = (udp_tunnel_function)inp->inp_ppcb; + INP_RUNLOCK(inp); + tunnel_func(m, off); + return (IPPROTO_DONE); + } udp6_append(inp, m, off, &fromsa); INP_RUNLOCK(inp); return (IPPROTO_DONE); --Apple-Mail-25--562946916 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Nov 20, 2008, at 8:50 AM, Max Laier wrote: > On Thursday 20 November 2008 14:00:11 Randall Stewart wrote: >> On Nov 19, 2008, at 5:33 PM, Julian Elischer wrote: >>>> Its not new, its the same ip header.. >>>> Its just you go into the mbuf chain and take out >>>> the udp header... >>> >>> well you can't do that at the socket buffer becasue you've discarded >>> the IP header. It may not even be in the mbufs you have. (though >>> it's >>> unlikely). After you've processed the UDP part the IP part is gone >>> so >>> you'd need to intercept the packet way earlier and then do your >>> own UDP processing, (or maybe attach the IP header onto it with a >>> tag). >> >> One would definitely have to do some work in udp_input() not a lot >> from >> what I can tell... but it would take some work. >> >> Maybe good course is to use the socket(9) stuff, but add an option >> that can set a "by-pass function" if the socket is udp... right >> after you establish the INP the packet goes to, if the function is >> set, you engage the bypass... > > This sounds reasonable. One would only have to replace calls to > udp_append in > udp_input with the by-pass function et voila. Should be clean > enough. There > might be some problems with holding the socket lock, though. > > For the record, I don't like all the UDP-tunneling madness either, > but it > seems that we are stuck with it ... so we should at least try to > come up with > a somewhat reasonable implementation for this hackery. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) --Apple-Mail-25--562946916-- From owner-freebsd-net@FreeBSD.ORG Thu Dec 11 13:12:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D05271065679 for ; Thu, 11 Dec 2008 13:12:19 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 635B58FC14 for ; Thu, 11 Dec 2008 13:12:19 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-005-194.pools.arcor-ip.net [88.66.5.194]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1LAlKz2dPk-00010q; Thu, 11 Dec 2008 14:12:17 +0100 Received: (qmail 51615 invoked from network); 11 Dec 2008 13:12:17 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 11 Dec 2008 13:12:17 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Thu, 11 Dec 2008 14:12:16 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> In-Reply-To: <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812111412.16757.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+8Rb0BzuksPsKU390lT3sqaCh3cGcO1+IUk1o 0fuzwiOtjOjgjcoSfIGxtt9Flmh5khJVGHNNqd8VU+sPrc0TgR /B1RPy60iHCuB0BY3WzDw== Cc: Randall Stewart Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 11 Dec 2008 13:12:19 -0000 On Thursday 11 December 2008 13:50:39 Randall Stewart wrote: > All: > > Ok here is what I have come up with.. going along the > lines of Max's suggestion.. its pretty clean I think. > > Comments would be most welcome.. > > The only thing possibly a bit dodgy is that > > 1) UDP has no per-protocol block. > 2) Instead of creating one, I am using the block pointer in the inp > as the function pointer for the tunneling. > > What this means if we EVERY did add a per protocol structure for > UDP we would need to move the function pointer in there.. > > The nice thing it does is make it so we have no structural changes to > the code... i.e. complete compatibility... no changes to inp or > other UDP structures :-) > > > Here is the patch.. please send comments ;-D I like it, though I have no idea what the implications of using the block pointer might be. One thing about the patch: What about the multi-/broadcast cases? I think if we introduce this, we want to make sure it works there as well - no? And finally, is there a potential race with setting the function and data arriving at the socket - should udp_set_kernel_tunneling maybe check that the socket isn't bound yet? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Thu Dec 11 13:31:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58A861065670 for ; Thu, 11 Dec 2008 13:31:33 +0000 (UTC) (envelope-from nrml@att.net) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by mx1.freebsd.org (Postfix) with SMTP id 080C58FC12 for ; Thu, 11 Dec 2008 13:31:32 +0000 (UTC) (envelope-from nrml@att.net) Received: (qmail 33263 invoked from network); 11 Dec 2008 13:31:31 -0000 Received: from unknown (HELO Inbox) (nrml@173.117.132.218 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 11 Dec 2008 13:31:30 -0000 X-YMail-OSG: nqCpSOoVM1ki8L9M47_cR.MJUBFPXfZ1pJz7YMKyP8vivraZVupztu7quK8dpmigr30QXaBQn3tim8roHoch_rVMuk3ot5o8r_0_80aV.lYnbyzGIxFtnYGRuu1UZ.JIm6jO3gLbO.vXfDOYP9Ldi0F_ X-Yahoo-Newman-Property: ymail-3 MIME-Version: 1.0 content-class: From: Gabe Date: Thu, 11 Dec 2008 05:31:44 -0800 Importance: normal X-Priority: 3 To: VANHULLEBUS Yvan Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Message-Id: <20081211133133.080C58FC12@mx1.freebsd.org> Cc: freebsd-net@freebsd.org Subject: RE: NAT-T + ipsec integration 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, 11 Dec 2008 13:31:33 -0000 Ok recompiling now. Hopefully it works fine. I'll report back. Thanks. -----Original Message----- From: VANHULLEBUS Yvan Sent: Thursday, December 11, 2008 4:39 AM To: Gabe Cc: freebsd-net@freebsd.org Subject: Re: NAT-T + ipsec integration On Thu, Dec 11, 2008 at 04:02:01AM -0800, Gabe wrote: > Hello all Hi. > Does anyone know how to enable nat traversal on freebsd? >=20 > I've got a site to site ipsec tunnel setup but clients behind the > nat can't vpn through it. Any help would be appreciated. Actually, you can apply a patch to src/sys and recompile your kernel with IPSEC_NAT_T options. Patches are available here: http://people.freebsd.org/~vanhu/NAT-T/ You can also try to play with Perforce's branch, but it is still work in progress to have a cleaned up version of PFKey interface (it may work, but I just started to set up some testing hosts). To answer the question some people may ask in this thread: the whole patch should be included in TRUNK as soon as PFKey cleanup will be done (which means "implemented + heavilly tested + reviewed"). Yvan. _______________________________________________ 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 Dec 11 14:56:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB7E6106567C for ; Thu, 11 Dec 2008 14:56:32 +0000 (UTC) (envelope-from adeepv@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by mx1.freebsd.org (Postfix) with ESMTP id 820218FC1C for ; Thu, 11 Dec 2008 14:56:32 +0000 (UTC) (envelope-from adeepv@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so1069930rne.12 for ; Thu, 11 Dec 2008 06:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=AXpRRwvxuwsHpG+4YGWvyBrht7Xz+0cN6ro2R2FfVL8=; b=hNvwWJCaS726IKVpC0E2XiBrrHy5Hx5BEqyciY/TXXCW+9aUSJSZl2fyyp6qEzlBFr DzDSF/BwE1jdRw7UrEgnhuQpGz9c0EnymrU82VDipfJ5S+Cxw7NER3zUihKNZT2w7TH6 TcoYcGuU4GHdJnch8Zll1y6nIlcfsWRQWKMMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=e2jUe/tpUcPTyfXWDJwbVjSu2ySvgBNyhcjEHTy0PoX3eiqqzEiHjOy68//YJqgqGv l9QM23pmfM6k5iIA3Uo2AeN9DscBuBW0ujdcUflna52Q2j2gsSDdzsB4s0/0Ojm96inI HODgU3eOnWgpSgaPxm1yoOj49aN8LPt3j5yik= Received: by 10.150.53.2 with SMTP id b2mr4336810yba.167.1229005783618; Thu, 11 Dec 2008 06:29:43 -0800 (PST) Received: by 10.151.49.21 with HTTP; Thu, 11 Dec 2008 06:29:43 -0800 (PST) Message-ID: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> Date: Thu, 11 Dec 2008 16:29:43 +0200 From: "Vyacheslav Bocharov" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: strange problem with ifconfig alias 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, 11 Dec 2008 14:56:32 -0000 Hello. I have strange problem with ifconfig: I can't add ip address to interface: root@chip# route get 195.3.245.xx route to: 195.3.245.xx destination: default mask: default gateway: gadget interface: vlan10 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 root@chip# ifconfig |grep 195.3.245. root@chip# root@chip# ifconfig em1 alias 195.3.245.xx/30 ifconfig: ioctl (SIOCAIFADDR): File exists root@chip# route get 195.3.245.xx route to: 195.3.245.xx destination: 195.3.245.xx-1 mask: 255.255.255.252 interface: em1 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 -3 root@chip# ifconfig em1 |grep 195.3.245. root@chip# -- Vyacheslav Bocharov From owner-freebsd-net@FreeBSD.ORG Thu Dec 11 18:11:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 303341065672 for ; Thu, 11 Dec 2008 18:11:47 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 07C278FC1A for ; Thu, 11 Dec 2008 18:11:46 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 322A31E6B0D; Thu, 11 Dec 2008 13:11:46 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 11 Dec 2008 13:11:46 -0500 X-Sasl-enc: nRMOf3RTvCWnMfagVJy+y65TRHRFHndQDotmbIwCBxc+ 1229019105 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 8F11E2C78A; Thu, 11 Dec 2008 13:11:45 -0500 (EST) Message-ID: <494157DF.6030802@FreeBSD.org> Date: Thu, 11 Dec 2008 18:11:43 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.18 (X11/20081205) MIME-Version: 1.0 To: Randall Stewart References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> In-Reply-To: <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 11 Dec 2008 18:11:47 -0000 Hi, I am missing context of what Max's suggestion was, do you have a reference to an old email thread? Style bugs: * needs style(9) and whitespace cleanup. * C typedefs should be suffixed with _t for consistency with other kernel typedefs. * Function typedefs usually named like foo_func_t (see other subsystems) Have you looked at m_apply() ? It already exists for stuff like this i.e. functions which act on an mbuf chain, although it doesn't necessarily expect chain heads. cheers BMS From owner-freebsd-net@FreeBSD.ORG Thu Dec 11 18:18:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 096E31065680; Thu, 11 Dec 2008 18:18:34 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id D38BD8FC1D; Thu, 11 Dec 2008 18:18:33 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 659181E6DF7; Thu, 11 Dec 2008 13:18:33 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 11 Dec 2008 13:18:33 -0500 X-Sasl-enc: 0/L1gkxbnjobDAH76arPK1cWctvbZsQxXGLhGnZwFSGk 1229019512 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id A052613B10; Thu, 11 Dec 2008 13:18:32 -0500 (EST) Message-ID: <49415977.6010307@FreeBSD.org> Date: Thu, 11 Dec 2008 18:18:31 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.18 (X11/20081205) MIME-Version: 1.0 To: Qing Li References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> In-Reply-To: <200812100740.mBA7eqjO034924@freefall.freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: last call for L2/L3 rewrite code review 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, 11 Dec 2008 18:18:34 -0000 Hi, Just skimming this I notice it uses the if_afdata[AF_INET] pointer purely for lltbl purposes; this clashes with the IGMPv3 code drop. Please look in the bms_netdev branch, where I introduce a 'struct ip_ifinfo' to make more general use of that slot. IGMPv3 needs to store per-interface state for AF_INET, so this slot really needs to be shared with other AF_INET stuff. Looks like it needs to be updated for VIMAGE also, hopefully others more familiar with this can help -- I am busy enough with non-programming activity as it is to get up to speed on this, although I have at least managed to print Julian's write-up... Other than that, it looks like a much needed improvement and we are all very grateful for our work on this. thanks BMS From owner-freebsd-net@FreeBSD.ORG Thu Dec 11 21:38:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01594106564A; Thu, 11 Dec 2008 21:38:06 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 24B298FC22; Thu, 11 Dec 2008 21:38:04 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1047701rvf.43 for ; Thu, 11 Dec 2008 13:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=6PtEuUNqYyP9mJFuKpNjjXDfyp2LXS8p+viVpNCdBMY=; b=E1XLX6jejNFgbsSHorze3uM42F7ZTU4q4KlxftgmCydwV+KgfK3xCn21fqk74AT0OU IcH82x2gsWE/LgrOcekuK4W5/c+tGihnWm6p0SXF8y03BgTTpBmedRGPjLVk8Q7rG+al K++PHlMCUE4rHnNJjx2XVM11N+vizAr4/Omd8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=lNATF6M/VdcPELMlWs0NkvfjOa9GpVdtpAhDX+cKGeJrCGhbsoLqkLTIQL+gZGTlmG 4ZeJmfISQUBR29GhDEWVEFT9SVw35qHVNixUrnH3SEdS6/l/JoKHhyMf5irS+K13ShCt tT0QTCchsmiV75QtDNpH/xMuT/7g/xHM7pDVg= Received: by 10.141.48.6 with SMTP id a6mr1504265rvk.36.1229031484656; Thu, 11 Dec 2008 13:38:04 -0800 (PST) Received: by 10.141.142.3 with HTTP; Thu, 11 Dec 2008 13:38:04 -0800 (PST) Message-ID: <3c1674c90812111338p69c33bd5sa26315cba4981011@mail.gmail.com> Date: Thu, 11 Dec 2008 13:38:04 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Bruce M. Simpson" In-Reply-To: <49415977.6010307@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> <49415977.6010307@FreeBSD.org> X-Google-Sender-Auth: 1449877b1265c4a8 Cc: Qing Li , current@freebsd.org, freebsd-net@freebsd.org Subject: Re: last call for L2/L3 rewrite code review 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, 11 Dec 2008 21:38:06 -0000 I think that you're request to not monopolize the AF_INET slot is reasonable. Do you intend to merge bms_netdev before 8 branches (I'm guessing this coming summer)? Cheers, Kip On Thu, Dec 11, 2008 at 10:18 AM, Bruce M. Simpson wrote: > Hi, > > Just skimming this I notice it uses the if_afdata[AF_INET] pointer purely > for lltbl purposes; this clashes with the IGMPv3 code drop. > > Please look in the bms_netdev branch, where I introduce a 'struct ip_ifinfo' > to make more general use of that slot. IGMPv3 needs to store per-interface > state for AF_INET, so this slot really needs to be shared with other AF_INET > stuff. > > Looks like it needs to be updated for VIMAGE also, hopefully others more > familiar with this can help -- I am busy enough with non-programming > activity as it is to get up to speed on this, although I have at least > managed to print Julian's write-up... > > Other than that, it looks like a much needed improvement and we are all very > grateful for our work on this. > > thanks > BMS > _______________________________________________ > 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" > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From owner-freebsd-net@FreeBSD.ORG Thu Dec 11 22:23:09 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22B92106564A; Thu, 11 Dec 2008 22:23:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EDBEA8FC1A; Thu, 11 Dec 2008 22:23:08 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBBMN8Cq098459; Thu, 11 Dec 2008 22:23:08 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBBMN8qk098455; Thu, 11 Dec 2008 22:23:08 GMT (envelope-from linimon) Date: Thu, 11 Dec 2008 22:23:08 GMT Message-Id: <200812112223.mBBMN8qk098455@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. 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, 11 Dec 2008 22:23:09 -0000 Old Synopsis: Netgear WG311v3 (ndis) causes kenel trap at boot. New Synopsis: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 11 22:22:26 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129580 From owner-freebsd-net@FreeBSD.ORG Thu Dec 11 23:20:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA843106568A for ; Thu, 11 Dec 2008 23:20:05 +0000 (UTC) (envelope-from mamruoc@gmail.com) Received: from outbound-mail-157.bluehost.com (outbound-mail-157.bluehost.com [67.222.39.37]) by mx1.freebsd.org (Postfix) with SMTP id B5DB48FC14 for ; Thu, 11 Dec 2008 23:20:05 +0000 (UTC) (envelope-from mamruoc@gmail.com) Received: (qmail 26715 invoked by uid 0); 11 Dec 2008 22:52:53 -0000 Received: from unknown (HELO host279.hostmonster.com) (74.220.215.79) by outboundproxy5.bluehost.com with SMTP; 11 Dec 2008 22:52:53 -0000 Received: from 217-14-12-49-dhcp-osl.bbse.no ([217.14.12.49] helo=appuru.bbse.no) by host279.hostmonster.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LAuPM-0001C9-UH; Thu, 11 Dec 2008 15:53:25 -0700 Message-ID: <494199E2.5050806@gmail.com> Date: Thu, 11 Dec 2008 23:53:22 +0100 From: Mam Ruoc User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> In-Reply-To: <20081129065950.GG99324@cdnetworks.co.kr> Content-Type: multipart/mixed; boundary="------------060806090504090207030205" X-Identified-User: {2972:host279.hostmonster.com:toancuon:hoanglai.no} {sentby:smtp auth 217.14.12.49 authed with toan+hoanglai.no} Cc: freebsd-net@freebsd.org Subject: Re: vge driver does not work on a VIA EPIA EN12000EG 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, 11 Dec 2008 23:20:05 -0000 This is a multi-part message in MIME format. --------------060806090504090207030205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pyun YongHyeon wrote: > I think there was a similar report. Would you show me the output of > "pciconf -lcv"? I finally got an SSD disk instead of the CF/IDE. The output is attached. > For a long time I wanted to clean up vge(4). Unfortunately the PCI > NIC I have seem to broken so I guess it's hard to complete the > cleanup. You can get a WIP(now stalled) in the following URL. Note, > the driver may be chatty due to various debugging statements and it > may not work at all for your controller. I guess that I should recompile the whole src tree, or is the driver enough? I am new to FreeBSD, could anybody help? Mam --------------060806090504090207030205 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="pciconf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pciconf" FreeBSD test 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 hostb0@pci0:0:0:0: class=0x060000 card=0xaa081106 chip=0x03141106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'CN700/VN800/P4M800CE/Pro Host Bridge' class = bridge subclass = HOST-PCI cap 02[80] = AGP v3 8x 4x SBA disabled cap 01[50] = powerspec 2 supports D0 D3 current D0 hostb1@pci0:0:0:1: class=0x060000 card=0x00000000 chip=0x13141106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'CN700/VN800/P4M800CE/Pro Standard Host Bridge' class = bridge subclass = HOST-PCI hostb2@pci0:0:0:2: class=0x060000 card=0x00000000 chip=0x23141106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'CN700/VN800/P4M800CE/Pro Standard Host Bridge' class = bridge subclass = HOST-PCI hostb3@pci0:0:0:3: class=0x060000 card=0x00000000 chip=0x32081106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'P4X800 CPU to PCI Bridge' class = bridge subclass = HOST-PCI hostb4@pci0:0:0:4: class=0x060000 card=0x00000000 chip=0x43141106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'CN700/VN800/P4M800CE/Pro Host Bridge' class = bridge subclass = HOST-PCI hostb5@pci0:0:0:7: class=0x060000 card=0x00000000 chip=0x73141106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'CN700/VN800/P4M800CE/Pro Host Bridge' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x00000000 chip=0xb1981106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies Inc' device = 'ProSavageDDR P4X600,Apollo KT400/A/600 CPU to AGP Bridge' class = bridge subclass = PCI-PCI cap 01[70] = powerspec 2 supports D0 D1 D3 current D0 fwohci0@pci0:0:13:0: class=0x0c0010 card=0x30441106 chip=0x30441106 rev=0x80 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6306 VIA Fire II IEEE-1394 OHCI Link Layer Controller' class = serial bus subclass = FireWire cap 01[50] = powerspec 2 supports D0 D2 D3 current D0 vge0@pci0:0:14:0: class=0x020000 card=0x01101106 chip=0x31191106 rev=0x11 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6120/VT6121/VT6122 'Velocity' Gigabit Ethernet Controllers' class = network subclass = ethernet cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 atapci0@pci0:0:15:0: class=0x01018f card=0x31491106 chip=0x31491106 rev=0x80 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8237 VT6410 SATA RAID Controller' class = mass storage subclass = ATA cap 01[c0] = powerspec 2 supports D0 D3 current D0 atapci1@pci0:0:15:1: class=0x01018a card=0x05711106 chip=0x05711106 rev=0x06 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C586A/B/VT82C686/A/B/VT823x/A/C Bus Master IDE Controller' class = mass storage subclass = ATA cap 01[c0] = powerspec 2 supports D0 D3 current D0 uhci0@pci0:0:16:0: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host Controller' class = serial bus subclass = USB cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 uhci1@pci0:0:16:1: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host Controller' class = serial bus subclass = USB cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 uhci2@pci0:0:16:2: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host Controller' class = serial bus subclass = USB cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 ehci0@pci0:0:16:4: class=0x0c0320 card=0x31041106 chip=0x31041106 rev=0x86 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6202/12 USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 isab0@pci0:0:17:0: class=0x060100 card=0xaa081106 chip=0x32271106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8237 PCI-to-ISA Bridge' class = bridge subclass = PCI-ISA cap 01[c0] = powerspec 2 supports D0 D3 current D0 em0@pci0:0:20:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 GT' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction vgapci0@pci0:1:0:0: class=0x030000 card=0x33441106 chip=0x33441106 rev=0x01 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'P4M800PRO&8237R VIA/S3G UniChrome Pro IGP' class = display subclass = VGA cap 01[60] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 02[70] = AGP v3 8x 4x SBA disabled --------------060806090504090207030205-- From owner-freebsd-net@FreeBSD.ORG Thu Dec 11 23:54:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5893D106564A for ; Thu, 11 Dec 2008 23:54:32 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 0FB398FC08 for ; Thu, 11 Dec 2008 23:54:31 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by an-out-0708.google.com with SMTP id c2so420650anc.13 for ; Thu, 11 Dec 2008 15:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=A5GWPQegcAxr91opeKGVJ0VLAbocrfmF45qAKiS1XO4=; b=MGvNakFxOEQNS5IXOMWO8uL9W81xfnLJbaKFrNXYqGwdF9hxUpXkaBo1MTvEkpL7nV Vh04i1ehhl7W5sYE3RmMahb2TLGtBuv29/LUApKUbVbbx8AZ7GhXT/0IUwC8xz8OPrWH zFZCet7NSYD5KHZK/IycMlQagoBSUYzV6MbDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=L+KYX+I7Xe6Nr5nRtP7V53yX0PMuYjBDBZTMrOM9zM4f6QM0P01GW1dLK5ErQn+/TD 6W1c0mXlWjQEu9IMLtTQPG7lo5tR7d+3hDn5y38DNHRu1hMCUvGTvJUEO+5UWzlKOne/ reg76/VoNlXWkk2DtLKttqw6iE0hbPfpDyZCk= Received: by 10.100.189.10 with SMTP id m10mr2487242anf.118.1229039671312; Thu, 11 Dec 2008 15:54:31 -0800 (PST) Received: from ?192.168.2.2? (cpe-70-112-179-136.austin.res.rr.com [70.112.179.136]) by mx.google.com with ESMTPS id c29sm4671334anc.29.2008.12.11.15.54.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 15:54:30 -0800 (PST) From: Ferner Cilloniz To: freebsd-net@freebsd.org Content-Type: text/plain Date: Thu, 11 Dec 2008 17:54:29 +0000 Message-Id: <1229018069.4966.1.camel@mobiliare.Belkin> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Subject: freebsd system calls 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, 11 Dec 2008 23:54:32 -0000 Hello everyone. I am interested in looking at the code for system calls in FreeBSD, like read, etc. In which directory can i find them? I have tried grepping /usr/src/sys. Thanks :) -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 00:01:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 194621065673 for ; Fri, 12 Dec 2008 00:01:55 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id E17D48FC2D for ; Fri, 12 Dec 2008 00:01:54 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so2144431rvb.4 for ; Thu, 11 Dec 2008 16:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=OCOCudU8JbLwlpw4nc0Kbi33kk+EUo881X365Zyn98c=; b=xWZ9ge66QKPEsG+bh3od5YZTMDrV0wkTOtMHBqN18pEPigHXH9m2sLrOdleedhhKjz oeNLUBJtRUrQYTq4Rr/MW6wCqvwotvKtEWjaGr2onVuBZq7QIqsqcz387gYLPcxNBZmQ 1MD8PMpfLWVne30Mw9EORtQmoea+l1PcYkrAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=TAM/fsukdfaA4vn3jKd4tSKCVT9EaGWfAQjosi73pZUxNSQoBpgWJLk+NBV6nP3Ydr NRT/htXXw1h71qptp0y6tVFMLUGQvjpH/LWE79Khhu+ik3iRQsCgqlhs4sWl8VZTT4++ R35IPgY1XeE/EAIE/SMyYcslosWCbi0ZLLVjM= Received: by 10.140.172.21 with SMTP id u21mr1564340rve.177.1229040114097; Thu, 11 Dec 2008 16:01:54 -0800 (PST) Received: by 10.141.142.3 with HTTP; Thu, 11 Dec 2008 16:01:54 -0800 (PST) Message-ID: <3c1674c90812111601u27415582j385c865d32ca233d@mail.gmail.com> Date: Thu, 11 Dec 2008 16:01:54 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 2b29f37c79181858 Subject: native ATM users 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, 12 Dec 2008 00:01:55 -0000 Native ATM relies on the use of route cloning for managing virtual circuits. Support for route cloning will be removed from the kernel in the near future. I thus need to determine how many users of NATM there are and their availability for testing changes. Thanks, Kip From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 00:07:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CF241065672 for ; Fri, 12 Dec 2008 00:07:36 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 20E6B8FC1E for ; Fri, 12 Dec 2008 00:07:35 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-058-254.pools.arcor-ip.net [88.66.58.254]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1LAvZ81a6i-0004IF; Fri, 12 Dec 2008 01:07:34 +0100 Received: (qmail 59382 invoked from network); 12 Dec 2008 00:07:33 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by mx.laiers.local with SMTP; 12 Dec 2008 00:07:33 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Fri, 12 Dec 2008 01:07:32 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <1229018069.4966.1.camel@mobiliare.Belkin> In-Reply-To: <1229018069.4966.1.camel@mobiliare.Belkin> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812120107.33230.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/46S0TDDVyI+zB9L47IIFFbgvNId3YlbuLKqO 8pcDNNKz4SNqoJWyhIJKaOH2gFmE22JfdX57jIEvTwv8C9Ov5S ZIpfrZa5a/c/ANU5pCrSA== Cc: Ferner Cilloniz Subject: Re: freebsd system calls 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, 12 Dec 2008 00:07:36 -0000 On Thursday 11 December 2008 18:54:29 Ferner Cilloniz wrote: > Hello everyone. > > I am interested in looking at the code for system calls in FreeBSD, like > read, etc. > > In which directory can i find them? I have tried grepping /usr/src/sys. src/sys/kern mostly ... "grep ^read *" should get you started. For the C function names take a look as syscalls.master in the same directory. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 01:40:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75D82106564A for ; Fri, 12 Dec 2008 01:40:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id 03B908FC18 for ; Fri, 12 Dec 2008 01:40:19 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1137968rvf.43 for ; Thu, 11 Dec 2008 17:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=NOCX1Si5NBCi7nvxlGXKVSymLzgwNmOqS0RMAyWw2X4=; b=w+TgYS3pCAbNOexJc8yRDnDEWZ9nbdyWx0h2E4pZCtr+1+o6tIzhJjeg6tQZGATzOu WeI1A84LPoWv9kxx0kfwrHLPPccU3Hc9MdqT7+U44QhE5xiLeZfYyYPyESn7xnLBL8fv Zbzy1p4J//buMmdEVjQxbOhQ8XCewhuV6P0Po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Trh1jNPEN11D4m9ilZYHmeenw+BuKLYZulWaS0beaJy201W7SM30nkdtcSX+fJWD5m MOFlx1ewNbsfl/JDDHa7mlCEb6aNcVflVYHCPARyYdXARJR4SlLNJTKiccbOJrQMfzCs fTxFNNZ36YnCIBvectg+9lLvbFRgsUJkS4DoQ= Received: by 10.141.211.5 with SMTP id n5mr1621551rvq.19.1229046019655; Thu, 11 Dec 2008 17:40:19 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k2sm3603080rvb.8.2008.12.11.17.40.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 17:40:18 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBC1eB36047183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 10:40:11 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBC1eBcN047182; Fri, 12 Dec 2008 10:40:11 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 12 Dec 2008 10:40:11 +0900 From: Pyun YongHyeon To: Vladimir Ermakov Message-ID: <20081212014011.GG46707@cdnetworks.co.kr> References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> <20081208004802.GB29560@cdnetworks.co.kr> <493CF424.4040206@gmail.com> <20081209043130.GC33723@cdnetworks.co.kr> <493E1872.9010306@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <493E1872.9010306@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: vlan support trouble in if_sis driver ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 01:40:20 -0000 On Tue, Dec 09, 2008 at 10:04:18AM +0300, Vladimir Ermakov wrote: > Pyun YongHyeon wrote: > >On Mon, Dec 08, 2008 at 01:17:08PM +0300, Vladimir Ermakov wrote: > > > Pyun YongHyeon wrote: > > > >Good. Would you show me the output of "pciconf -lcv"? > > > >If I don't see any oddities in the output, I would commit the > > > >patch. > > > > > > > > > what tests need to try? > > > > > > > > > > > > >If parent interface sis0 still works as expected(i.e. without VLAN) > > > >there is no need to test other cases, I guess. > > > > > > > > > > > OK > > > > > > # pciconf -lvc > > > ... > > > sis0@pci0:0:4:0: class=0x020000 card=0xe0001458 chip=0x09001039 > > > rev=0x90 hdr=0x00 > > > vendor = 'Silicon Integrated Systems (SiS)' > > > device = 'SiS900 sis 900 and integrated lan' > > > class = network > > > subclass = ethernet > > > cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 > > > ... > > > > > > >Thanks. Patch committed to HEAD(r185784). > > > > > MFC? > sis(4) supports two kind of controllers. One was made by SiS and the other was manufactured by National Semiconductor. So I think we need test report for NatSemi DP83815 case prior to MFC. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 01:58:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FC99106564A for ; Fri, 12 Dec 2008 01:58:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id EB87B8FC0C for ; Fri, 12 Dec 2008 01:58:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1144369rvf.43 for ; Thu, 11 Dec 2008 17:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=CgYEIhxmNsu8ntrjfI/FNPBV7g0aUTpGRAw+6FEKQps=; b=CjNIhzs+qcBTHjUy5Bhf2XzuYTm33r/qD0pAwxOyPZUZQG3YyxCiLA1JHFpLF6GQUZ LctcpTFjowMgcoLY09sQcKMUgAXrE8bsoBo1vChEAfSseL/7kxV6a5BKtQixC3TPl4+3 2kwC02WEpgKuL52+EduYOcN9AjiZovXTLZ/p0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=oJmvbEyrRYj3PE1nby6MyJYkBgojj3hoO+JeRh+XGYaCOCbo6O4GaG461uFATPgIgd zwx88BUpYlgRMurUVlLEzWdOwBC5XL51Ova95e9tOhrTtL0pOfXPppbSEbtpX3lARN42 ezK0z7GJNUVIgyvIX8+mvqeb984jJ7Y+yO/pg= Received: by 10.140.187.10 with SMTP id k10mr1606627rvf.264.1229047129641; Thu, 11 Dec 2008 17:58:49 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id b8sm7134080rvf.3.2008.12.11.17.58.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 17:58:48 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBC1wgEC047258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 10:58:42 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBC1wgqn047257; Fri, 12 Dec 2008 10:58:42 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 12 Dec 2008 10:58:42 +0900 From: Pyun YongHyeon To: Mam Ruoc Message-ID: <20081212015842.GH46707@cdnetworks.co.kr> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494199E2.5050806@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: vge driver does not work on a VIA EPIA EN12000EG X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 01:58:50 -0000 On Thu, Dec 11, 2008 at 11:53:22PM +0100, Mam Ruoc wrote: > Pyun YongHyeon wrote: > >I think there was a similar report. Would you show me the output of > >"pciconf -lcv"? > > I finally got an SSD disk instead of the CF/IDE. The output is attached. > > >For a long time I wanted to clean up vge(4). Unfortunately the PCI > >NIC I have seem to broken so I guess it's hard to complete the > >cleanup. You can get a WIP(now stalled) in the following URL. Note, > >the driver may be chatty due to various debugging statements and it > >may not work at all for your controller. > > I guess that I should recompile the whole src tree, or is the driver > enough? I am new to FreeBSD, could anybody help? If you use vge(4) kernel module, rebuilding vge(4) is enough. If vge(4) is statically linked to kernel, rebuilding kernel is necessary(i.e. not whole source tree). I've added some macros to make it build on 7.0-RELEASE. So if you already fetched sources, please refetch it from the following URL. http://people.freebsd.org/~yongari/vge/if_vge.c http://people.freebsd.org/~yongari/vge/if_vgereg.h http://people.freebsd.org/~yongari/vge/if_vgevar.h -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 02:05:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AFCB1065676 for ; Fri, 12 Dec 2008 02:05:03 +0000 (UTC) (envelope-from mamruoc@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id BEF178FC13 for ; Fri, 12 Dec 2008 02:05:02 +0000 (UTC) (envelope-from mamruoc@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so218155nfh.33 for ; Thu, 11 Dec 2008 18:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=uWMGsMbmxwvOH7eTgbDukztOKeQbcOn5FZEi0LjQycE=; b=WG9tI/eeyyWDOzYACg3eXHaUeci5hWoUlmYCojveOaJuARFSMqUn+oUf8IjCQzb6ak 5b8Vis4kMOu+5+gDAz/Q5JM71XSNwaYHrWLE+97eDxbjsDwBpp7kDZUNQEAgEqRP5VEl v0S0grJ56wIe8x058yf3D3A6rAU7DqKowisOo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=egKUZnwageAeTn5yQdYRJeBisFA7VR2jW48NPxDRwWI+7FjXQiNTWbxQNYEZDPT3FL kbRs2VzFzbL/6XUwRzrNwZNqsyxWREJ6k6XzcKAiAdZyIFZi+CLWVP8jqiMpOHc1DToM 53yI5/yz5JfUtdc54OtdqVqYbgGyKhm/iWTSk= Received: by 10.210.56.7 with SMTP id e7mr3526033eba.32.1229047501023; Thu, 11 Dec 2008 18:05:01 -0800 (PST) Received: from appuru-2.local (217-14-12-232-dhcp-osl.bbse.no [217.14.12.232]) by mx.google.com with ESMTPS id 20sm49155eyk.44.2008.12.11.18.05.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 18:05:00 -0800 (PST) Message-ID: <4941C6BF.4080809@gmail.com> Date: Fri, 12 Dec 2008 03:04:47 +0100 From: Mam Ruoc User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> <20081212015842.GH46707@cdnetworks.co.kr> In-Reply-To: <20081212015842.GH46707@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: vge driver does not work on a VIA EPIA EN12000EG 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, 12 Dec 2008 02:05:03 -0000 Pyun YongHyeon wrote: > If you use vge(4) kernel module, rebuilding vge(4) is enough. > If vge(4) is statically linked to kernel, rebuilding kernel is > necessary(i.e. not whole source tree). Sorry for being stupid, but I did just install a clean install of FreeBSD 7.0, kernel or driver only? If driver only, how do I do that? Mam From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 02:16:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1599D1065675 for ; Fri, 12 Dec 2008 02:16:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id CEE348FC1A for ; Fri, 12 Dec 2008 02:16:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1150556rvf.43 for ; Thu, 11 Dec 2008 18:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=n5nKjrBf8QycEVXJLYMUmfW3CZ8tRvsYRbxTzqvEWwY=; b=HqRMq0v+YgqJhVA8VHdj3i9piVoA29/JeEvpE9qjVwDbESbfh8po5kJ5tqQHLKFT9W z2cwbzqphcqs34hwdy0ZcrQ35SCQrgHmFRrTXDDLwPleKW03QnPyGGoDexvn248OLK8v 99w+xuA/iqFT+iyN2RU4uMt8EpjD7rHjX+svE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=d+w/CCmqH48NxtmFP2Px6iNLJFieu3Y7xaTE+He65zZemreZt9l7ihTduVyCzWL8L8 whTryNHqlOCcRjnX3t7taW0mbj5i0BVR9k7vo3BzTUc0zKvdeow2bCkwUDnS1Z/+Vk1s G7ldwFowZ37YWceuYXJcFquj6MYF4qR9uypIo= Received: by 10.141.28.4 with SMTP id f4mr1623746rvj.164.1229048169219; Thu, 11 Dec 2008 18:16:09 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id l31sm7174079rvb.2.2008.12.11.18.15.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 18:15:56 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBC2FoPb047350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 11:15:50 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBC2FnUu047349; Fri, 12 Dec 2008 11:15:49 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 12 Dec 2008 11:15:49 +0900 From: Pyun YongHyeon To: Mam Ruoc Message-ID: <20081212021549.GJ46707@cdnetworks.co.kr> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> <20081212015842.GH46707@cdnetworks.co.kr> <4941C6BF.4080809@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4941C6BF.4080809@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: vge driver does not work on a VIA EPIA EN12000EG X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 02:16:10 -0000 On Fri, Dec 12, 2008 at 03:04:47AM +0100, Mam Ruoc wrote: > Pyun YongHyeon wrote: > >If you use vge(4) kernel module, rebuilding vge(4) is enough. > >If vge(4) is statically linked to kernel, rebuilding kernel is > >necessary(i.e. not whole source tree). > > Sorry for being stupid, but I did just install a clean install of > FreeBSD 7.0, kernel or driver only? > > If driver only, how do I do that? > First save your old vge sources and download the the files. #cd /usr/src/sys/dev/vge #cp -p if_vge.c if_vge.c.orig #cp -p if_vgereg.h if_vgereg.h.orig #cp -p if_vgevar.h if_vgevar.h.orig #fetch http://people.freebsd.org/~yongari/vge/if_vge.c #fetch http://people.freebsd.org/~yongari/vge/if_vgereg.h #fetch http://people.freebsd.org/~yongari/vge/if_vgevar.h And rebuild kernel and then reboot. You don't need to reinstall FreeBSD. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 02:59:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE3831065672; Fri, 12 Dec 2008 02:59:29 +0000 (UTC) (envelope-from scaron@umich.edu) Received: from deathandthemaiden.mr.itd.umich.edu (deathandthemaiden.mr.itd.umich.edu [141.211.14.22]) by mx1.freebsd.org (Postfix) with ESMTP id 453C38FC0C; Fri, 12 Dec 2008 02:59:29 +0000 (UTC) (envelope-from scaron@umich.edu) Received: FROM beowulf.web.itd.umich.edu (beowulf.web.itd.umich.edu [141.211.13.153]) BY deathandthemaiden.mr.itd.umich.edu ID 4941CDD8.B51FC.450 ; 11 Dec 2008 21:35:04 -0500 Received: (from www@localhost) by beowulf.web.itd.umich.edu () id mBC2Z3CZ024918; Thu, 11 Dec 2008 21:35:03 -0500 Received: from arbo-1-core-1.diablonet.net (arbo-1-core-1.diablonet.net [75.144.70.41]) by web.mail.umich.edu (Horde Framework) with HTTP; Thu, 11 Dec 2008 21:35:03 -0500 Message-ID: <20081211213503.154712aj9y9bl2a8@web.mail.umich.edu> Date: Thu, 11 Dec 2008 21:35:03 -0500 From: Sean Thomas Caron To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.2) X-Remote-Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 X-IMP-Server: 141.211.13.216 (beowulf) X-Originating-IP: 75.144.70.41 X-Originating-User: scaron Cc: scaron@freebsd.org, kmacy@freebsd.org Subject: Re: native ATM users 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, 12 Dec 2008 02:59:30 -0000 Hi Kip, I am currently using NATM on FreeBSD/sparc64 with FORE PCA-200E boards. It is a little buggy but it works and I am hoping to continue along with it as long as I can. :) -Sean From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 03:03:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE205106564A for ; Fri, 12 Dec 2008 03:03:59 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 8BA398FC24 for ; Fri, 12 Dec 2008 03:03:59 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so586829ywe.13 for ; Thu, 11 Dec 2008 19:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=K4XrcIVLGheN8zpjkuY8BVkpBEFUHw+ZkpZHMM4Xeys=; b=Ry+4sWDSFVPqI0ceWqQqSu8qns/6Vj24VJK93tZR93KglkJVlwLRJvHe4IBDfX50n9 hXzJ6P+0jOp0kR5Wenp2wXfWDHNqo4X3dT76eAeQ6f+Zt7h8lJwheqKMIHIn7fwrIOqZ SODh+/Tmob78VcQCpuv2Jrc8/AtG0flNK+nKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=C93O/JzHn60WhABWWo83jAWWeDTtYZ/y7vw1D8ZCQBeAUBLJl4lX1QrefQLiaha+5V YtDRK+Ci6VUQaSTeSnYvpAw24ffo5WNc/K/l7sYafZ9uDPniouGo/KafOjvNqZEBHG8D SYEiRHt+tUczwXYysIBdExwETq29JKYWsCXLg= Received: by 10.100.174.13 with SMTP id w13mr2565315ane.141.1229051038809; Thu, 11 Dec 2008 19:03:58 -0800 (PST) Received: by 10.100.33.6 with HTTP; Thu, 11 Dec 2008 19:03:58 -0800 (PST) Message-ID: <3c1674c90812111903o34ef8770vcda21b94b9b07ece@mail.gmail.com> Date: Thu, 11 Dec 2008 19:03:58 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Sean Thomas Caron" In-Reply-To: <20081211213503.154712aj9y9bl2a8@web.mail.umich.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081211213503.154712aj9y9bl2a8@web.mail.umich.edu> X-Google-Sender-Auth: b87176a3153d4144 Cc: freebsd-net@freebsd.org, scaron@freebsd.org Subject: Re: native ATM users 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, 12 Dec 2008 03:04:00 -0000 On Thu, Dec 11, 2008 at 6:35 PM, Sean Thomas Caron wrote: > Hi Kip, > > I am currently using NATM on FreeBSD/sparc64 with FORE PCA-200E boards. It > is a little buggy but it works and I am hoping to continue along with it as > long as I can. :) Hi Sean, Thanks for the prompt response. Are you running -CURRENT with it? How long do you foresee using the hardware for? Have you had any direct interaction with the ATM code? Thanks, Kip From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 05:40:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 131E01065672 for ; Fri, 12 Dec 2008 05:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DD19C8FC08 for ; Fri, 12 Dec 2008 05:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBC5e3KE029129 for ; Fri, 12 Dec 2008 05:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBC5e3cd029128; Fri, 12 Dec 2008 05:40:03 GMT (envelope-from gnats) Date: Fri, 12 Dec 2008 05:40:03 GMT Message-Id: <200812120540.mBC5e3cd029128@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Glen Barber" Cc: Subject: Re: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Glen Barber List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 05:40:04 -0000 The following reply was made to PR kern/129580; it has been noted by GNATS. From: "Glen Barber" To: bug-followup@freebsd.org, glen.j.barber@gmail.com Cc: Subject: Re: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. Date: Fri, 12 Dec 2008 00:04:10 -0500 As it turns out, the problem is not related solely to 7.1-R*. I've had this happen last night on 6.4-RELEASE as well. Same problem with the same workaround. Regards, -- Glen Barber From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 06:36:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B21BB1065670 for ; Fri, 12 Dec 2008 06:36:21 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 6899F8FC14 for ; Fri, 12 Dec 2008 06:36:21 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so604597ywe.13 for ; Thu, 11 Dec 2008 22:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=KWEdx5muVkAgxuHT3oK93RvZ0lnuBSqN64ojjtfcEi8=; b=qDUQwFOGZ+6a0WdEOblKsedxrV8uiL61LzrhI5q71Zqj169/ls5jbl3tn3NgyPvvtE Rbe3ccv8Va72z8PvI5fozgpKKHRxAS3jwAiFYukptn6/pdP4xL/1EFLuDgTKLXamH+IX 2L9qiFid5RJ5fPx7RLwPNyuG/MDwCPCNMkykQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=G7TTpds5fJ+aGLg2+D1dNax5HiXzl+sVN2gjbJcu6dek08bIZAgiLuTJ7ZUkw0FNCk PIoQRFTTBuUU7yclTHwIP9C96SdSvvfimlJFwOnSDp5ITWXwVzET1GgOZFxrrhO6XTkl sHrZTtYix8Ffzm6Lhj/fwoTu73d009l6EYxlE= Received: by 10.100.109.13 with SMTP id h13mr2674041anc.21.1229063780659; Thu, 11 Dec 2008 22:36:20 -0800 (PST) Received: from ?192.168.2.2? (cpe-70-112-179-136.austin.res.rr.com [70.112.179.136]) by mx.google.com with ESMTPS id c37sm5090674ana.37.2008.12.11.22.36.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 22:36:20 -0800 (PST) From: Ferner Cilloniz To: freebsd-net@freebsd.org Content-Type: text/plain Date: Fri, 12 Dec 2008 00:36:17 +0000 Message-Id: <1229042178.4978.2.camel@mobiliare.Belkin> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Subject: warning: implicit declaration of function 'VOP_READDIR' 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, 12 Dec 2008 06:36:21 -0000 Hello everyone. Im trying to create a system call similar to getdirentries(). When compiling the module, i get the following error: ReadMod.c:160: warning: implicit declaration of function 'VOP_READDIR' I have included all the required header files. #include #include #include Any help will be greatly appreciated. Thanks :) -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 07:42:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A8DE1065673 for ; Fri, 12 Dec 2008 07:42:38 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id 558F18FC12 for ; Fri, 12 Dec 2008 07:42:38 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1235717wfg.7 for ; Thu, 11 Dec 2008 23:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:to:cc:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:organization :x-operation-sytem:from; bh=a6MWSgIr2HzxwpW3LFcQ1zM3ZAScQrKh6L4fuB6kzlU=; b=uDVjvlfD7OjYau+tmhO5zaBwbFL4ELDkTcBTpQqG1KfzGJvm3oqVYGR7OaaoGz1dBw 4LgIeWNF8QE83OvH/PfGd6ocYvrMRC/RXNbhB3I2j1cm4mEfK0Ld7FrAmOInz+3ObHer RCjALQSth/BC9geaFIjiIG16CMvYnOAXmIYfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem:from; b=Cv/fy0znw6zutyxeltj4Xrxgxa1i9g//A+nYQPxKbUD1RviiJpOMCCMKIB4dwaHvCm nC+T2qFkDh2KUla9KZIds0PhwYOKUNmarj6GGRlAS5fc0dH812S5dFC1bmKaNtK8rN8Z sTBwDI0iPuGdUVK9+3vazVnPs+6W/mYIxAZVE= Received: by 10.142.172.12 with SMTP id u12mr1211562wfe.285.1229067757612; Thu, 11 Dec 2008 23:42:37 -0800 (PST) Received: from freebsd.weongyo.org ([211.53.35.67]) by mx.google.com with ESMTPS id 27sm5028980wff.51.2008.12.11.23.42.34 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 23:42:36 -0800 (PST) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Fri, 12 Dec 2008 16:42:21 +0900 Date: Fri, 12 Dec 2008 16:42:21 +0900 To: Glen Barber Message-ID: <20081212074221.GA8907@freebsd.weongyo.org> Mail-Followup-To: Glen Barber , freebsd-net@freebsd.org References: <200812120540.mBC5e3cd029128@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200812120540.mBC5e3cd029128@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD From: Weongyo Jeong Cc: freebsd-net@freebsd.org Subject: Re: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. 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, 12 Dec 2008 07:42:38 -0000 On Fri, Dec 12, 2008 at 05:40:03AM +0000, Glen Barber wrote: > The following reply was made to PR kern/129580; it has been noted by GNATS. > > From: "Glen Barber" > To: bug-followup@freebsd.org, glen.j.barber@gmail.com > Cc: > Subject: Re: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. > Date: Fri, 12 Dec 2008 00:04:10 -0500 > > As it turns out, the problem is not related solely to 7.1-R*. > > I've had this happen last night on 6.4-RELEASE as well. Same problem > with the same workaround. Not related with ndis(4); AFAIK Netgear WG311v3 uses Marvell 88W8335 which is supported by malo(4) shipped with RELENG 7.1. regards, Weongyo Jeong From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 07:56:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C083D106564A for ; Fri, 12 Dec 2008 07:56:00 +0000 (UTC) (envelope-from adeepv@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 779888FC12 for ; Fri, 12 Dec 2008 07:56:00 +0000 (UTC) (envelope-from adeepv@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so610095ywe.13 for ; Thu, 11 Dec 2008 23:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=EQzfME8wRcxEwtaZEPF3GfHtEkqZJlMTF3ORVPGprx8=; b=ab0Z7mGVm68KgdtgeJDRogORcexxmCMTiINxzg/FcZgDCfoZgOn72Frj5wVmxpL/Eb Yg+mWWnXkQ9QkCdETyPehz6QCO6LMR+932GWK0OlOW6hWgLc9vPFhMVKzatTCgTXictU i1kFZ1OWl1uvlGoAYRetz/M84viDgWoWtq5ro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=wqjBZFhF9ayXKxmCFVzbPeGPQKeYEipKxQm/trkK9bw4ABgFbL/CMGjr9y1EwdxEqB WQdDcBw+G1WNfeuu9KL8DFcM5b+5UcNtL1txFEwV1nqB8bzb5GXB9Sf5O3LtOGaVHiN6 jGt/QSaZ7vePJmYuyCBRVxkVlNAUAXnnqOYLg= Received: by 10.150.202.9 with SMTP id z9mr5863587ybf.144.1229068559949; Thu, 11 Dec 2008 23:55:59 -0800 (PST) Received: by 10.151.49.21 with HTTP; Thu, 11 Dec 2008 23:55:59 -0800 (PST) Message-ID: <80861bfa0812112355o386ece39v76cb5cc0f69d5c75@mail.gmail.com> Date: Fri, 12 Dec 2008 09:55:59 +0200 From: "Vyacheslav Bocharov" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: crash in dummynet 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, 12 Dec 2008 07:56:01 -0000 I have frequent panics in dummynet module: Dec 12 08:27:58 chip syslogd: restart Dec 12 08:27:58 chip syslogd: kernel boot file is /boot/kernel/kernel Dec 12 08:27:58 chip kernel: Dec 12 08:27:58 chip kernel: Dec 12 08:27:58 chip kernel: Fatal trap 12: page fault while in kernel mode Dec 12 08:27:58 chip kernel: cpuid = 1; apic id = 01 Dec 12 08:27:58 chip kernel: fault virtual address = 0x10 Dec 12 08:27:58 chip kernel: fault code = supervisor read, page not present Dec 12 08:27:58 chip kernel: instruction pointer = 0x20:0xc06af1fd Dec 12 08:27:58 chip kernel: stack pointer = 0x28:0xe8733bd4 Dec 12 08:27:58 chip kernel: frame pointer = 0x28:0xe8733c18 Dec 12 08:27:58 chip kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Dec 12 08:27:58 chip kernel: = DPL 0, pres 1, def32 1, gran 1 Dec 12 08:27:58 chip kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Dec 12 08:27:58 chip kernel: current process = 48 (dummynet) Dec 12 08:27:58 chip kernel: trap number = 12 Dec 12 08:27:58 chip kernel: panic: page fault Dec 12 08:27:58 chip kernel: cpuid = 1 Dec 12 08:27:58 chip kernel: Uptime: 16h42m29s Dec 12 08:27:58 chip kernel: Physical memory: 3572 MB Dec 12 08:27:58 chip kernel: Dumping 227 MB: Dec 12 08:27:58 chip kernel: arp: 00:15:17:28:39:7f is using my IP address 10.200.216.1 on vlan24! Dec 12 08:27:58 chip kernel: Copyright (c) 1992-2008 The FreeBSD Project. Dec 12 08:27:58 chip kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Dec 12 08:27:58 chip kernel: The Regents of the University of California. All rights reserved. Dec 12 08:27:58 chip kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Dec 12 08:27:58 chip kernel: FreeBSD 7.1-PRERELEASE #3: Wed Dec 10 10:07:04 EET 2008 Dec 12 08:27:58 chip kernel: root@chip.lexi.net.ua:/usr/obj/usr/src/sys/chip Dec 12 08:27:58 chip kernel: module_register: module g_journal already exists! Dec 12 08:27:58 chip kernel: Module g_journal failed to register: 17 Dec 12 08:27:58 chip kernel: module_register: module g_mirror already exists! Dec 12 08:27:58 chip kernel: Module g_mirror failed to register: 17 Dec 12 08:27:58 chip kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Dec 12 08:27:58 chip kernel: CPU: Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz (1995.01-MHz 686-class CPU) Dec 12 08:27:58 chip kernel: Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Dec 12 08:27:58 chip kernel: Features=0xbfebfbff Dec 12 08:27:58 chip kernel: Features2=0xe39d Dec 12 08:27:58 chip kernel: AMD Features=0x20100000 Dec 12 08:27:58 chip kernel: AMD Features2=0x1 Dec 12 08:27:58 chip kernel: Cores per package: 2 Dec 12 08:27:58 chip kernel: real memory = 3755986944 (3581 MB) ... Dec 12 08:27:58 chip kernel: Checking for core dump on /dev/mirror/vpns1b... Dec 12 08:27:58 chip kernel: savecore: no dumps found Dec 12 08:27:58 chip savecore: no dumps found -- Vyacheslav Bocharov From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 09:20:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 012F11065673 for ; Fri, 12 Dec 2008 09:20:04 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA628FC12 for ; Fri, 12 Dec 2008 09:20:02 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 229581490; Fri, 12 Dec 2008 10:20:00 +0200 Message-ID: <49421EB0.7040205@mavhome.dp.ua> Date: Fri, 12 Dec 2008 10:20:00 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Nikos Vassiliadis References: <1229005383.00046904.1228994401@10.7.7.3> In-Reply-To: <1229005383.00046904.1228994401@10.7.7.3> Content-Type: multipart/mixed; boundary="------------060705090100070300010900" Cc: freebsd-net@freebsd.org Subject: Re: ng_bridge + ng_ksocket 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, 12 Dec 2008 09:20:04 -0000 This is a multi-part message in MIME format. --------------060705090100070300010900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nikos Vassiliadis wrote: > I would like to create an ethernet over UDP tunnel. For my > purposes, using ng_bridge and ng_ksocket seem fine. The > problem is that the peer address/port is not known, since > it will be behind a NAT device and will have a dynamically > assigned IP address. In userspace I would use something like > recvfrom() to get the peer address. I don't know what to do > for ngctl and ng_ksocket. Any suggestions? Is this doable? > Is there something I can do to circumvent the problem? Five years ago I had the same problem. In result, I have written a small program which monitor interface with libpcap and calls script to reconnect ng_ksocket to the new peer address/port when it changes. The code is old, dirty and was not used for a long time, but if you wish to try that way - it is attached. -- Alexander Motin --------------060705090100070300010900 Content-Type: text/plain; name="main.cc" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="main.cc" #ifdef HAVE_CONFIG_H #include #endif extern "C" { # include # include # include # include # include # include # include # include # include # include # include # include # include # include # include }; #include #include #include #include extern char *optarg; extern int optind; extern int optopt; extern int opterr; extern int optreset; char our_iface[5]; char our_addr[16]; int our_port; char our_script[128]; unsigned int cur_addr=0; unsigned int cur_port=0; void discard(int sig) { std::cerr << "ĐĎĚŐŢĹÎ ÓÉÇÎÁĚ" << std::endl; } void usage() { std::cout << "program -i iface -a addr -p port -s script" << std::endl; } int if_ip(register const u_char *buf, unsigned int size) { if (size < sizeof(struct ip)) { std::cerr << "it is too small (" << size << " bytes) to be an ip packet." << std::endl; return 1; } struct ip *ip = (struct ip*) buf; if (ip->ip_v != IPVERSION) { std::cerr << "ip ver != " << IPVERSION << ": discard " << size << "bytes" << std::endl; return 2; } if ((ip->ip_p == IPPROTO_UDP)&&((ntohs(ip->ip_off) & IP_OFFMASK) == 0)) { u_int hlen = ip->ip_hl * 4; u_char *cp = (u_char *)ip + hlen; unsigned int addr=ip->ip_src.s_addr; struct in_addr in; in.s_addr=addr; unsigned int port=ntohs(((struct udphdr *)cp)->uh_sport); if ((cur_addr!=addr) || (cur_port!=port)) { std::cerr << "CHANGED to " << inet_ntoa(in)<< ":" << port << std::endl; cur_addr=addr; cur_port=port; switch (fork()) { case 0: char tmp[128]; snprintf(tmp,128,"%s:%d",inet_ntoa(in),port); // std::cerr << our_script<<","<caplen)) { // validate Ether packet length return; } struct ether_header *p = (struct ether_header *)buf; if (ntohs(p->ether_type)==ETHERTYPE_IP) { if_ip(buf+sizeof(struct ether_header), h->caplen-sizeof(struct ether_header)); } return; } int main(int argc, char *argv[]) { int ch; while ((ch = getopt(argc, argv,"i:a:p:s:"))!=-1) { switch (ch) { case 'i': strncpy(our_iface,optarg,5); break; case 'a': strncpy(our_addr,optarg,16); break; case 'p': our_port = atoi(optarg); break; case 's': strncpy(our_script,optarg,128); break; case '?': default: usage(); return 1; } } //------------------------------------------- signal(SIGTERM, discard); siginterrupt(SIGTERM, 1); pcap_t *pd; char ebuf[PCAP_ERRBUF_SIZE]; /* open bpf with required snaplen */ if ((pd = pcap_open_live(our_iface, 100, 0/*no_promisc...*/, 10000, ebuf)) == NULL) { std::cerr<<"ĎŰÉÂËÁ pcap_open_live " < Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 790E9106568C; Fri, 12 Dec 2008 09:46:34 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 505988FC17; Fri, 12 Dec 2008 09:46:34 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBC9kYIa034768; Fri, 12 Dec 2008 09:46:34 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBC9kYgJ034764; Fri, 12 Dec 2008 09:46:34 GMT (envelope-from remko) Date: Fri, 12 Dec 2008 09:46:34 GMT Message-Id: <200812120946.mBC9kYgJ034764@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/129538: [if_rl]: rl driver does not work 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, 12 Dec 2008 09:46:34 -0000 Synopsis: [if_rl]: rl driver does not work Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Fri Dec 12 09:46:25 UTC 2008 Responsible-Changed-Why: REassign to -net http://www.freebsd.org/cgi/query-pr.cgi?pr=129538 From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 10:06:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B78A106564A for ; Fri, 12 Dec 2008 10:06:14 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-qy0-f18.google.com (mail-qy0-f18.google.com [209.85.221.18]) by mx1.freebsd.org (Postfix) with ESMTP id D38078FC13 for ; Fri, 12 Dec 2008 10:06:13 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by qyk11 with SMTP id 11so1750511qyk.19 for ; Fri, 12 Dec 2008 02:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=FqOQQtFNPWvVgN+91ptYwZecd5Qq1QnHdOhh99+qpF8=; b=BRDCil0Ejk3GDub/8At4JSWCUxArfaOPg2HJD4h85ov+YwNorI59q/igARc4ZajAEa iL3zemIrcBiLZxw2d34u8aOYP3GNOuX8X2rV1r6wa2B9SzOb9jjF49gEQAkZFEDIT9/I oDqyGBmx9t9bCZWPvJ0vZFw5rlgUPrwBSNxYg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=fhZiWc7cIVzwTABCcPVBE7jhH6yiP+oYdHcGp0ausCiZcH+lqbMkY+TzlleTQHqfwk G2WfPOZUpQ1tLdkx/HrgFVQfCB/n/xb8DxvEv5jr5/fcS0+1JwQsY5rPEuxuoB4W0Ake tzSgePP20AJ4FJZWp1g4E6DPzBgHta6E1s1Wg= Received: by 10.214.217.14 with SMTP id p14mr4861735qag.272.1229074625814; Fri, 12 Dec 2008 01:37:05 -0800 (PST) Received: from orion.hsd1.pa.comcast.net (c-71-230-240-241.hsd1.pa.comcast.net [71.230.240.241]) by mx.google.com with ESMTPS id 6sm3716224ywn.6.2008.12.12.01.37.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Dec 2008 01:37:05 -0800 (PST) Date: Fri, 12 Dec 2008 04:37:11 -0500 From: Glen Barber To: freebsd-net@freebsd.org Message-ID: <20081212093710.GA50649@orion.hsd1.pa.comcast.net> References: <200812120540.mBC5e3cd029128@freefall.freebsd.org> <20081212074221.GA8907@freebsd.weongyo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081212074221.GA8907@freebsd.weongyo.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. 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, 12 Dec 2008 10:06:14 -0000 Weongyo Jeong said: > On Fri, Dec 12, 2008 at 05:40:03AM +0000, Glen Barber wrote: > > The following reply was made to PR kern/129580; it has been noted by GNATS. > > > > From: "Glen Barber" > > To: bug-followup@freebsd.org, glen.j.barber@gmail.com > > Cc: > > Subject: Re: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. > > Date: Fri, 12 Dec 2008 00:04:10 -0500 > > > > As it turns out, the problem is not related solely to 7.1-R*. > > > > I've had this happen last night on 6.4-RELEASE as well. Same problem > > with the same workaround. > > Not related with ndis(4); AFAIK Netgear WG311v3 uses Marvell 88W8335 > which is supported by malo(4) shipped with RELENG 7.1. > I'm not currently running 7.1 at the moment, or I'd test this; however, this doesn't explain why it happens on 6.X also, unless there is a different driver I'm missing. I checked out the GENERIC kernel config to be sure, but didn't see anything. Regards, -- Glen Barber From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 10:21:14 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34BD61065676; Fri, 12 Dec 2008 10:21:14 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0B2858FC14; Fri, 12 Dec 2008 10:21:14 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (yongari@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBCALDCn065353; Fri, 12 Dec 2008 10:21:13 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBCALDgh065349; Fri, 12 Dec 2008 10:21:13 GMT (envelope-from yongari) Date: Fri, 12 Dec 2008 10:21:13 GMT Message-Id: <200812121021.mBCALDgh065349@freefall.freebsd.org> To: raichoo@googlemail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/129538: [if_rl]: rl driver does not work 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, 12 Dec 2008 10:21:14 -0000 Synopsis: [if_rl]: rl driver does not work State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Fri Dec 12 10:20:12 UTC 2008 State-Changed-Why: Would you show me the output of "ifconfig rl0" and dmesg information? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Fri Dec 12 10:20:12 UTC 2008 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=129538 From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 12:30:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 069901065670 for ; Fri, 12 Dec 2008 12:30:31 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from smtp.teledomenet.gr (smtp.teledomenet.gr [213.142.128.2]) by mx1.freebsd.org (Postfix) with ESMTP id AF57E8FC1A for ; Fri, 12 Dec 2008 12:30:30 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: by smtp.teledomenet.gr (Postfix, from userid 58) id ABA3B14209E; Fri, 12 Dec 2008 14:30:29 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on smtp.teledomenet.gr X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.5 Received: from iris.teledomenet.local (unknown [192.168.1.71]) by smtp.teledomenet.gr (Postfix) with ESMTP id B95F114208B; Fri, 12 Dec 2008 14:30:26 +0200 (EET) From: Nikos Vassiliadis To: Alexander Motin Date: Fri, 12 Dec 2008 14:29:37 +0200 User-Agent: KMail/1.9.10 References: <1229005383.00046904.1228994401@10.7.7.3> <49421EB0.7040205@mavhome.dp.ua> In-Reply-To: <49421EB0.7040205@mavhome.dp.ua> X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812121429.38205.nvass@teledomenet.gr> Cc: freebsd-net@freebsd.org Subject: Re: ng_bridge + ng_ksocket 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, 12 Dec 2008 12:30:31 -0000 On Friday 12 December 2008 10:20:00 Alexander Motin wrote: > Five years ago I had the same problem. In result, I have written a small > program which monitor interface with libpcap and calls script to > reconnect ng_ksocket to the new peer address/port when it changes. > > The code is old, dirty and was not used for a long time, but if you wish > to try that way - it is attached. It works, but I don't want go to down that road. I was hopping that I was missing something... Would you ever consider such a feature, totally unrelated to PPP, for mpd? Nikos From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 12:52:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EDB810656A8 for ; Fri, 12 Dec 2008 12:52:20 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id DA46D8FC1B for ; Fri, 12 Dec 2008 12:52:19 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by an-out-0708.google.com with SMTP id c2so500591anc.13 for ; Fri, 12 Dec 2008 04:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dpYyAqLRzu9V667y6HR8xaiHZ03PzQYYXXSZHV6ERIo=; b=NKBxBw3S3QkCuvtOAlbCj3b7DRABwjif3V7720D43GDezYmhMHJNW4MaJ59LHRwVbk zgwugYWELJiERRDqc4B24eKCHWDd9vsyd77yp0b0U0enbw+MG3b4g/+J0rW4mESAGYMc db0VxSX8t8C6Z80EyBgsWsJbJNIzDG5DT9+AA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Az+b42RvW0izOd0k2hLwQTOjTZHsgOlH7ZL/BHJOnPKMaCgLhC5utxaUvM/9wjz8kp tZPH/Mj7VwKJPznWuHw58LdA4Mz+tuussQSRZoKZit9oqD0Di45Y7qfadkVNEwSG0XOu tKyETTl8Pcib31cjPfXwzWwqe27Uu8cPhFxUA= Received: by 10.231.11.137 with SMTP id t9mr44989ibt.49.1229086338639; Fri, 12 Dec 2008 04:52:18 -0800 (PST) Received: by 10.231.18.139 with HTTP; Fri, 12 Dec 2008 04:52:18 -0800 (PST) Message-ID: <3a142e750812120452s2cd7c629m484261fba700610b@mail.gmail.com> Date: Fri, 12 Dec 2008 13:52:18 +0100 From: "Paul B. Mahol" To: "Vyacheslav Bocharov" In-Reply-To: <80861bfa0812112355o386ece39v76cb5cc0f69d5c75@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <80861bfa0812112355o386ece39v76cb5cc0f69d5c75@mail.gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: crash in dummynet 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, 12 Dec 2008 12:52:20 -0000 On 12/12/08, Vyacheslav Bocharov wrote: > I have frequent panics in dummynet module: > > Dec 12 08:27:58 chip syslogd: restart > Dec 12 08:27:58 chip syslogd: kernel boot file is /boot/kernel/kernel > Dec 12 08:27:58 chip kernel: > Dec 12 08:27:58 chip kernel: > Dec 12 08:27:58 chip kernel: Fatal trap 12: page fault while in kernel mode > Dec 12 08:27:58 chip kernel: cpuid = 1; apic id = 01 > Dec 12 08:27:58 chip kernel: fault virtual address = 0x10 > Dec 12 08:27:58 chip kernel: fault code = supervisor read, page not > present > Dec 12 08:27:58 chip kernel: instruction pointer = 0x20:0xc06af1fd > Dec 12 08:27:58 chip kernel: stack pointer = 0x28:0xe8733bd4 > Dec 12 08:27:58 chip kernel: frame pointer = 0x28:0xe8733c18 > Dec 12 08:27:58 chip kernel: code segment = base 0x0, limit > 0xfffff, type 0x1b > Dec 12 08:27:58 chip kernel: = DPL 0, pres 1, def32 1, gran 1 > Dec 12 08:27:58 chip kernel: processor eflags = interrupt enabled, resume, > IOPL = 0 > Dec 12 08:27:58 chip kernel: current process = 48 (dummynet) > Dec 12 08:27:58 chip kernel: trap number = 12 > Dec 12 08:27:58 chip kernel: panic: page fault > Dec 12 08:27:58 chip kernel: cpuid = 1 > Dec 12 08:27:58 chip kernel: Uptime: 16h42m29s > Dec 12 08:27:58 chip kernel: Physical memory: 3572 MB > Dec 12 08:27:58 chip kernel: Dumping 227 MB: backtrace? -- Paul From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 12:56:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC9121065670 for ; Fri, 12 Dec 2008 12:56:41 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 47B738FC14 for ; Fri, 12 Dec 2008 12:56:41 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mBCCudUC016156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Dec 2008 07:56:39 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1229086600; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=fHKZwADhMDRCi09w9f3IQvh4jXkleSG5F5jtgr6PKD24prNCxma1aMl 3nzXhw1UQNm4yVe4IH0ZIhqapkPuT+w== Message-Id: <11F9C4F4-E893-46DA-96C3-1984131159D6@lakerest.net> From: Randall Stewart To: Max Laier In-Reply-To: <200812111412.16757.max@love2party.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 07:56:38 -0500 References: <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <200812111412.16757.max@love2party.net> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net@freebsd.org Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 12 Dec 2008 12:56:41 -0000 On Dec 11, 2008, at 8:12 AM, Max Laier wrote: > On Thursday 11 December 2008 13:50:39 Randall Stewart wrote: >> All: >> >> Ok here is what I have come up with.. going along the >> lines of Max's suggestion.. its pretty clean I think. >> >> Comments would be most welcome.. >> >> The only thing possibly a bit dodgy is that >> >> 1) UDP has no per-protocol block. >> 2) Instead of creating one, I am using the block pointer in the inp >> as the function pointer for the tunneling. >> >> What this means if we EVERY did add a per protocol structure for >> UDP we would need to move the function pointer in there.. >> >> The nice thing it does is make it so we have no structural changes to >> the code... i.e. complete compatibility... no changes to inp or >> other UDP structures :-) >> >> >> Here is the patch.. please send comments ;-D > > I like it, though I have no idea what the implications of using the > block > pointer might be. > > One thing about the patch: What about the multi-/broadcast cases? > I think if > we introduce this, we want to make sure it works there as well - no? Hmm.. Well I don't know if I like the idea of the broadcast/ multicast... for tunneling.. Then again.. you may be right.. thinking on this DCCP can do multicast as well.. so let me go look at it. > > > And finally, is there a potential race with setting the function and > data > arriving at the socket - should udp_set_kernel_tunneling maybe check > that the > socket isn't bound yet? Yep, in fact I figured that out as I started trying to get SCTP to use this. We HAVE to have it un-bound when you do the set_kernel_tunneling function... that way you can make sure no packets have arrived for you BEFORE you bind. So I have removed the bind restriction. Another thing... kinda weird.. when I have this thing working with SCTP and I let the SCTP stack try to initialize the socket right away.. I get bogus results. The port is actually binding.. but yet it cant be sent to. If I unbind i.e. close the socket that got created.. then do a sysctl to re- add the same port.. all works fine. For now I am going to make SCTP NOT do this.. and have to add it to the sysctl's in /etc/sysctl.conf to add UDP tunneling. Only other solution would be a timer in the transport after startup to do this binding... I was wondering if I would see a race in the protocol stack initialization.. basically my guess is SCTP initializes ahead of UDP.. so its actually a wonder I did not crash ;-D R > > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > _______________________________________________ > 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" > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 12:59:49 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F3391065696; Fri, 12 Dec 2008 12:59:49 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 636FA8FC1B; Fri, 12 Dec 2008 12:59:48 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mBCCxlHS016193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Dec 2008 07:59:47 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1229086787; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=ah1cgAowEsdhSuhEWiM4BGx9tsfVqlBEPdCYkTN74rF5NQy4bMexPhu 8Frd2XiYd7QUkDP9GFC9JrDxUjvmhww== Message-Id: <57BBB796-7E00-4D96-BACE-1306FC4C1417@lakerest.net> From: Randall Stewart To: "Bruce M. Simpson" In-Reply-To: <494157DF.6030802@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 07:59:46 -0500 References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 12 Dec 2008 12:59:49 -0000 Bruce: On Dec 11, 2008, at 1:11 PM, Bruce M. Simpson wrote: > Hi, > > I am missing context of what Max's suggestion was, do you have a > reference to an old email thread? As to the context... Nov 18 2008 10:01 (am Eastern) I started a thread "Thinking about UDP and tunneling" > > > Style bugs: > * needs style(9) and whitespace cleanup. Hmm.. I thought I had got all this stuff... I actually (shudder) switched to vi since my emacs spacing always messes up.. in the SCTP code I have the s9indent function that fixes any issues.. but I did not want to run that on the udp src and cause other changes ... I will go back and look at the patch.. > > * C typedefs should be suffixed with _t for consistency with other > kernel typedefs. Good point I will fix the stuff to have _t in it :-) > > * Function typedefs usually named like foo_func_t (see other > subsystems) R > > > Have you looked at m_apply() ? It already exists for stuff like this > i.e. functions which act on an mbuf chain, although it doesn't > necessarily expect chain heads. > > cheers > BMS > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 13:38:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D941106564A for ; Fri, 12 Dec 2008 13:38:44 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0F77F8FC23 for ; Fri, 12 Dec 2008 13:38:43 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 229626059; Fri, 12 Dec 2008 15:38:42 +0200 Message-ID: <49426962.5070809@mavhome.dp.ua> Date: Fri, 12 Dec 2008 15:38:42 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Nikos Vassiliadis References: <1229005383.00046904.1228994401@10.7.7.3> <49421EB0.7040205@mavhome.dp.ua> <200812121429.38205.nvass@teledomenet.gr> In-Reply-To: <200812121429.38205.nvass@teledomenet.gr> Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ng_bridge + ng_ksocket 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, 12 Dec 2008 13:38:44 -0000 Nikos Vassiliadis wrote: > On Friday 12 December 2008 10:20:00 Alexander Motin wrote: >> Five years ago I had the same problem. In result, I have written a small >> program which monitor interface with libpcap and calls script to >> reconnect ng_ksocket to the new peer address/port when it changes. >> >> The code is old, dirty and was not used for a long time, but if you wish >> to try that way - it is attached. > > It works, but I don't want go to down that road. > I was hopping that I was missing something... > > Would you ever consider such a feature, totally unrelated > to PPP, for mpd? Feature of what? ksocket is just a building brick, not a complete end-user solution. It is just a netgraph wrapper around kernel socket implementation. It may be sufficient for trivial cases, but no more. UDP socket is connectionless, so it does not handle remote address change. If it is connected to some remote address/port it just will not receive any other packet. You need some daemon to handle any additional logic. One simple example I have send to you. Another one is MPD, implementing L2TP and PPP-over-UDP links. Mpd opens separate UDP socket in user-level which catches everything that wasn't caught by existing connected sockets in netgraph and dynamically creates and connects additional UDP sockets in netgraph to handle this traffic. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 13:46:32 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85643106564A; Fri, 12 Dec 2008 13:46:32 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 00CE18FC18; Fri, 12 Dec 2008 13:46:31 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mBCDkUZH017234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Dec 2008 08:46:31 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1229089591; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Mime-Version:Subject:Date:References:X-Mailer; b=PplwOYWEyNxbU8M7o8 2P9dylvTnuF/vokAoR7zUifbqGPUoSodXj5zqhSGBAODAVo+2hgvv1/z8DI6g+ea912 Q== Message-Id: <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> From: Randall Stewart To: "Bruce M. Simpson" In-Reply-To: <494157DF.6030802@FreeBSD.org> Content-Type: multipart/mixed; boundary=Apple-Mail-78--473196051 Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 08:46:30 -0500 References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 12 Dec 2008 13:46:32 -0000 --Apple-Mail-78--473196051 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Ok: Here is an updated patch it: 1) Fixes style9 issues (I hope.. I went back to vi and tried tabs :-0.. sigh one of these doys I will figure out why my .emacs settings just never cut it :-() 2) move to _t typedef 3) Allow multicast/broadcast to also be tunneled. 4) Binding is now no longer a requirement to set tunneling mode, in fact most protocols had better NOT have bound.. first set options, then bind :-) There was one thing I was a bit leary of for <3>. In the loop for going through all the inp's of UDP that are listening to a m-cast/b-cast I could not release the INP_INFO_LOCK() in other cases I make sure all locks are released when we call into the tunneling protocol. I think this will be ok as long as the tunnelee does not try to use the INP_INFO_LOCK of the UDP world... I know for SCTP this is a non-issue.. but it may be something we want to think about... not sure. If there are no serious objections I will submit this into head.. and followed behind it I will send in the changes so SCTP can be tunneled over this new mechanism :-) R --Apple-Mail-78--473196051 Content-Disposition: attachment; filename=new_udp_diff.txt Content-Type: text/plain; x-unix-mode=0644; name="new_udp_diff.txt" Content-Transfer-Encoding: 7bit Index: netinet/udp_usrreq.c =================================================================== --- netinet/udp_usrreq.c (revision 185928) +++ netinet/udp_usrreq.c (working copy) @@ -488,10 +488,25 @@ struct mbuf *n; n = m_copy(m, 0, M_COPYALL); - if (n != NULL) - udp_append(last, ip, n, iphlen + - sizeof(struct udphdr), &udp_in); - INP_RUNLOCK(last); + + if (last->inp_ppcb == NULL) { + if (n != NULL) + udp_append(last, ip, n, iphlen + + sizeof(struct udphdr), &udp_in); + INP_RUNLOCK(last); + } else { + /* Engage the tunneling protocol + * we will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't break :-( + */ + udp_tunnel_function_t tunnel_func; + + INP_RUNLOCK(last); + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, iphlen); + } } last = inp; /* @@ -516,10 +531,25 @@ V_udpstat.udps_noportbcast++; goto badheadlocked; } - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), - &udp_in); - INP_RUNLOCK(last); - INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb == NULL) { + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), + &udp_in); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } else { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, iphlen); + } return; } @@ -563,6 +593,18 @@ INP_RUNLOCK(inp); goto badunlocked; } + if (inp->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; + INP_RUNLOCK(inp); + tunnel_func(m, iphlen); + return; + } udp_append(inp, ip, m, iphlen + sizeof(struct udphdr), &udp_in); INP_RUNLOCK(inp); return; @@ -1138,10 +1180,41 @@ INP_INFO_WUNLOCK(&V_udbinfo); inp->inp_vflag |= INP_IPV4; inp->inp_ip_ttl = V_ip_defttl; + /* + * UDP does not have a per-protocol + * pcb (inp->inp_ppcb). We use this + * pointer for kernel tunneling pointer. + * If we ever need to have a protocol + * block we will need to move this + * function pointer there. Null + * in this pointer means "do the normal + * thing". + */ + inp->inp_ppcb = NULL; INP_WUNLOCK(inp); return (0); } +int +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f) +{ + struct inpcb *inp; + inp = (struct inpcb *)so->so_pcb; + + if (so->so_type != SOCK_DGRAM) { + /* Not UDP socket... sorry */ + return (ENOTSUP); + } + if (inp == NULL) { + /* NULL INP? */ + return (EINVAL); + } + INP_WLOCK(inp); + inp->inp_ppcb = f; + INP_WUNLOCK(inp); + return (0); +} + static int udp_bind(struct socket *so, struct sockaddr *nam, struct thread *td) { Index: netinet/udp_var.h =================================================================== --- netinet/udp_var.h (revision 185928) +++ netinet/udp_var.h (working copy) @@ -107,6 +107,10 @@ void udp_input(struct mbuf *, int); struct inpcb *udp_notify(struct inpcb *inp, int errno); int udp_shutdown(struct socket *so); + + +typedef void(*udp_tunnel_function_t)(struct mbuf *, int off); +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f); #endif #endif Index: netinet6/udp6_usrreq.c =================================================================== --- netinet6/udp6_usrreq.c (revision 185928) +++ netinet6/udp6_usrreq.c (working copy) @@ -286,9 +286,21 @@ struct mbuf *n; if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { - INP_RLOCK(last); - udp6_append(last, n, off, &fromsa); - INP_RUNLOCK(last); + if (last->inp_ppcb) { + /* Engage the tunneling protocol + * we will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't break :-( + */ + udp_tunnel_function_t tunnel_func; + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, off); + } else { + INP_RLOCK(last); + udp6_append(last, n, off, &fromsa); + INP_RUNLOCK(last); + } } } last = inp; @@ -317,6 +329,19 @@ } INP_RLOCK(last); INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, off); + return (IPPROTO_DONE); + } udp6_append(last, m, off, &fromsa); INP_RUNLOCK(last); return (IPPROTO_DONE); @@ -354,6 +379,18 @@ } INP_RLOCK(inp); INP_INFO_RUNLOCK(&V_udbinfo); + if (inp->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; + INP_RUNLOCK(inp); + tunnel_func(m, off); + return (IPPROTO_DONE); + } udp6_append(inp, m, off, &fromsa); INP_RUNLOCK(inp); return (IPPROTO_DONE); --Apple-Mail-78--473196051 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Dec 11, 2008, at 1:11 PM, Bruce M. Simpson wrote: > Hi, > > I am missing context of what Max's suggestion was, do you have a > reference to an old email thread? > > Style bugs: > * needs style(9) and whitespace cleanup. > * C typedefs should be suffixed with _t for consistency with other > kernel typedefs. > * Function typedefs usually named like foo_func_t (see other > subsystems) > > Have you looked at m_apply() ? It already exists for stuff like this > i.e. functions which act on an mbuf chain, although it doesn't > necessarily expect chain heads. > > cheers > BMS > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) --Apple-Mail-78--473196051-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 13:51:24 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 467F11065678 for ; Fri, 12 Dec 2008 13:51:24 +0000 (UTC) (envelope-from nrml@att.net) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by mx1.freebsd.org (Postfix) with SMTP id 115368FC24 for ; Fri, 12 Dec 2008 13:51:23 +0000 (UTC) (envelope-from nrml@att.net) Received: (qmail 85727 invoked from network); 12 Dec 2008 13:51:23 -0000 Received: from unknown (HELO Inbox) (nrml@70.1.142.145 with login) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 12 Dec 2008 13:51:21 -0000 X-YMail-OSG: uUcIyAIVM1lfHK534InIIkN5HE2.XLYXoWzX6bxyeKEiiLEWEUV1mK3VTGIggNjCJxs1ArRhXZfNmqIWPiAfb1LqozZsrauecCdFFibh36n1t_VnrB_gP0Qk5JoW6b2CAaQ.iRyqmQWL3LUS8ZHizvOX X-Yahoo-Newman-Property: ymail-3 MIME-Version: 1.0 content-class: From: Gabe Date: Fri, 12 Dec 2008 05:51:31 -0800 Importance: normal X-Priority: 3 To: VANHULLEBUS Yvan Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Message-Id: <20081212135124.115368FC24@mx1.freebsd.org> Cc: freebsd-net@freebsd.org Subject: RE: NAT-T + ipsec integration 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, 12 Dec 2008 13:51:24 -0000 So far so good... Should I be worried that the patch file names have 'test'= in them? -----Original Message----- From: Gabe Sent: Thursday, December 11, 2008 5:31 AM To: VANHULLEBUS Yvan Cc: freebsd-net@freebsd.org Subject: RE: NAT-T + ipsec integration Ok recompiling now. Hopefully it works fine. I'll report back. Thanks. -----Original Message----- From: VANHULLEBUS Yvan Sent: Thursday, December 11, 2008 4:39 AM To: Gabe Cc: freebsd-net@freebsd.org Subject: Re: NAT-T + ipsec integration On Thu, Dec 11, 2008 at 04:02:01AM -0800, Gabe wrote: > Hello all Hi. > Does anyone know how to enable nat traversal on freebsd? >=20 > I've got a site to site ipsec tunnel setup but clients behind the > nat can't vpn through it. Any help would be appreciated. Actually, you can apply a patch to src/sys and recompile your kernel with IPSEC_NAT_T options. Patches are available here: http://people.freebsd.org/~vanhu/NAT-T/ You can also try to play with Perforce's branch, but it is still work in progress to have a cleaned up version of PFKey interface (it may work, but I just started to set up some testing hosts). To answer the question some people may ask in this thread: the whole patch should be included in TRUNK as soon as PFKey cleanup will be done (which means "implemented + heavilly tested + reviewed"). Yvan. _______________________________________________ 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 Fri Dec 12 14:13:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA7B71065670 for ; Fri, 12 Dec 2008 14:13:26 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from smtp.teledomenet.gr (smtp.teledomenet.gr [213.142.128.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6FD248FC17 for ; Fri, 12 Dec 2008 14:13:26 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: by smtp.teledomenet.gr (Postfix, from userid 58) id 790CF142057; Fri, 12 Dec 2008 16:13:25 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on smtp.teledomenet.gr X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.5 Received: from iris.teledomenet.local (unknown [192.168.1.71]) by smtp.teledomenet.gr (Postfix) with ESMTP id B4610142045; Fri, 12 Dec 2008 16:13:22 +0200 (EET) From: Nikos Vassiliadis To: Alexander Motin Date: Fri, 12 Dec 2008 16:12:33 +0200 User-Agent: KMail/1.9.10 References: <1229005383.00046904.1228994401@10.7.7.3> <200812121429.38205.nvass@teledomenet.gr> <49426962.5070809@mavhome.dp.ua> In-Reply-To: <49426962.5070809@mavhome.dp.ua> X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812121612.34002.nvass@teledomenet.gr> Cc: freebsd-net@freebsd.org Subject: Re: ng_bridge + ng_ksocket 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, 12 Dec 2008 14:13:26 -0000 On Friday 12 December 2008 15:38:42 Alexander Motin wrote: > You need some daemon to handle any additional logic. One simple example > I have send to you. Another one is MPD, implementing L2TP and > PPP-over-UDP links. Mpd opens separate UDP socket in user-level which > catches everything that wasn't caught by existing connected sockets in > netgraph and dynamically creates and connects additional UDP sockets in > netgraph to handle this traffic. Yes, that's what I meant. If you would consider the possibility of adding L2 over UDP functionality to MPD. I am asking this, since you've already done things like this for MPD and I suspect that there are some bits already in place. Of course a simple "I don't want to" or "no time" would be a fine answer:) OTOH you could also say that ethernet over UDP is conceptually unrelated to PPP, which is what MPD does. Nikos From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 14:39:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C69931065672 for ; Fri, 12 Dec 2008 14:39:59 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 46ADF8FC21 for ; Fri, 12 Dec 2008 14:39:58 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 229633517; Fri, 12 Dec 2008 16:39:58 +0200 Message-ID: <494277BD.2030804@mavhome.dp.ua> Date: Fri, 12 Dec 2008 16:39:57 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Nikos Vassiliadis References: <1229005383.00046904.1228994401@10.7.7.3> <200812121429.38205.nvass@teledomenet.gr> <49426962.5070809@mavhome.dp.ua> <200812121612.34002.nvass@teledomenet.gr> In-Reply-To: <200812121612.34002.nvass@teledomenet.gr> Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ng_bridge + ng_ksocket 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, 12 Dec 2008 14:39:59 -0000 Nikos Vassiliadis wrote: > On Friday 12 December 2008 15:38:42 Alexander Motin wrote: >> You need some daemon to handle any additional logic. One simple example >> I have send to you. Another one is MPD, implementing L2TP and >> PPP-over-UDP links. Mpd opens separate UDP socket in user-level which >> catches everything that wasn't caught by existing connected sockets in >> netgraph and dynamically creates and connects additional UDP sockets in >> netgraph to handle this traffic. > > Yes, that's what I meant. If you would consider the possibility > of adding L2 over UDP functionality to MPD. I am asking this, > since you've already done things like this for MPD and I suspect > that there are some bits already in place. Of course a simple > "I don't want to" or "no time" would be a fine answer:) There is some L2 over PPP RFC exists which itself can be transported over UDP or whatever else. It surely has additional overhead, but instead gives many of native PPP bonuses like authentication, encryption, compression, etc. I was thinking about implementing it, but I haven't found any other existing implementation and so dropped it. > OTOH you could also say that ethernet over UDP is conceptually > unrelated to PPP, which is what MPD does. Indeed. MPD is a PPP daemon. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 14:52:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E98F81065673 for ; Fri, 12 Dec 2008 14:52:22 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id AA19C8FC22 for ; Fri, 12 Dec 2008 14:52:22 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id F405F2798B8; Fri, 12 Dec 2008 15:52:20 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id 8ED3E17051; Fri, 12 Dec 2008 15:53:00 +0100 (CET) Date: Fri, 12 Dec 2008 15:53:00 +0100 From: VANHULLEBUS Yvan To: Gabe Message-ID: <20081212145300.GA14254@zeninc.net> References: <20081212135124.115368FC24@mx1.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081212135124.115368FC24@mx1.freebsd.org> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: RE: NAT-T + ipsec integration 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, 12 Dec 2008 14:52:23 -0000 On Fri, Dec 12, 2008 at 05:51:31AM -0800, Gabe wrote: > So far so good... Should I be worried that the patch file names have 'test' in them? I can rename them if you want ;-) Patch for FreeBSD6 is stable enough to be used in production and to survive non regression test suite at NETASQ. Patch for FreeBSD7 is used by many people AFAIK, including my own IPsec gates which have tunnels up 24h/7. I called those versions "test" when I put them online because I only checked that they compile before releasing them. They have been much more tested since. Yvan. From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 14:58:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 097901065679 for ; Fri, 12 Dec 2008 14:58:07 +0000 (UTC) (envelope-from nrml@att.net) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by mx1.freebsd.org (Postfix) with SMTP id B11D88FC12 for ; Fri, 12 Dec 2008 14:58:06 +0000 (UTC) (envelope-from nrml@att.net) Received: (qmail 66302 invoked from network); 12 Dec 2008 14:58:06 -0000 Received: from unknown (HELO Inbox) (nrml@70.1.21.178 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 12 Dec 2008 14:58:05 -0000 X-YMail-OSG: KMRa2k8VM1nF4YYENL7cXyIzb6Shl8CZw3l6hLNdkRQO5RX3zd2L_.ZzXxUHU7SY3ibTtpNkbCjho9ipXYV5GQ8IBs.vJP8Wm40vlsUA97LWd94R.G11K1F5L7JaDtMYzUI79bS3YUI6piyUWVTJa7ZL X-Yahoo-Newman-Property: ymail-3 MIME-Version: 1.0 content-class: From: Gabe Date: Fri, 12 Dec 2008 06:58:17 -0800 Importance: normal X-Priority: 3 To: VANHULLEBUS Yvan Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Message-Id: <20081212145806.B11D88FC12@mx1.freebsd.org> Cc: freebsd-net@freebsd.org Subject: RE: RE: NAT-T + ipsec integration 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, 12 Dec 2008 14:58:07 -0000 Hehehe no I was just wondering. I'm running 7 and the patch installed just = fine. -----Original Message----- From: VANHULLEBUS Yvan Sent: Friday, December 12, 2008 6:53 AM To: Gabe Cc: freebsd-net@freebsd.org Subject: Re: RE: NAT-T + ipsec integration On Fri, Dec 12, 2008 at 05:51:31AM -0800, Gabe wrote: > So far so good... Should I be worried that the patch file names have 'tes= t' in them? I can rename them if you want ;-) Patch for FreeBSD6 is stable enough to be used in production and to survive non regression test suite at NETASQ. Patch for FreeBSD7 is used by many people AFAIK, including my own IPsec gates which have tunnels up 24h/7. I called those versions "test" when I put them online because I only checked that they compile before releasing them. They have been much more tested since. Yvan. _______________________________________________ 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 Dec 12 15:12:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B3B1065670 for ; Fri, 12 Dec 2008 15:12:38 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id 51C478FC08 for ; Fri, 12 Dec 2008 15:12:38 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by ewy14 with SMTP id 14so2090166ewy.19 for ; Fri, 12 Dec 2008 07:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=86YVM6yAu/u8OiMnKAT1DIhjzhpmJLX/UHluzD1KSCk=; b=MpVlUGj2H+Ug91E0jKnYFzCIS3TqaV67qvK3qdqEJ8YGthN3u0i++axhHizB9rnFpS etko052veKWv77Qxi+V/9jSImShJ2l02h9PdxpzpYXCddrdONAB/tfemnz0OPdWvXZXs iAr8werR1OW5/9pnlY0sKqqyiqc64w3dFy7Z0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=lQQ7yxSbtaU3yEJjXNyZK4Oee3gNtgdVUsWPhlvljpTJgJr1bsD3uu3L3b14awT4nh Unc+aBA9GzAzxpvaxBYsFQ+R04vGXQJAcrOqd2UuhDF2An4Y+MN6WINvXXbVvfNle0Xi DK1OnJSxSDrDbHvlYI0/zriqQ4M6fRHbaiMQ8= Received: by 10.210.54.17 with SMTP id c17mr918679eba.14.1229094757265; Fri, 12 Dec 2008 07:12:37 -0800 (PST) Received: from localhost.localdomain ([213.152.137.42]) by mx.google.com with ESMTPS id 7sm79903eyb.21.2008.12.12.07.12.35 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Dec 2008 07:12:36 -0800 (PST) Message-ID: <49427F7A.2020103@gmail.com> Date: Fri, 12 Dec 2008 18:12:58 +0300 From: Vladimir Ermakov User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: pyunyh@gmail.com References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> <20081208004802.GB29560@cdnetworks.co.kr> <493CF424.4040206@gmail.com> <20081209043130.GC33723@cdnetworks.co.kr> <493E1872.9010306@gmail.com> <20081212014011.GG46707@cdnetworks.co.kr> In-Reply-To: <20081212014011.GG46707@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: vlan support trouble in if_sis 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: Fri, 12 Dec 2008 15:12:38 -0000 Pyun YongHyeon wrote: > > > > > >Thanks. Patch committed to HEAD(r185784). > > > > > > > > MFC? > > > > sis(4) supports two kind of controllers. One was made by SiS and > the other was manufactured by National Semiconductor. So I think we > need test report for NatSemi DP83815 case prior to MFC. > > need a PR? /Vladimir Ermakov From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 15:17:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ACF01065670 for ; Fri, 12 Dec 2008 15:17:52 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from smtp.teledomenet.gr (smtp.teledomenet.gr [213.142.128.2]) by mx1.freebsd.org (Postfix) with ESMTP id D525A8FC12 for ; Fri, 12 Dec 2008 15:17:51 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: by smtp.teledomenet.gr (Postfix, from userid 58) id CBE01142086; Fri, 12 Dec 2008 17:17:50 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on smtp.teledomenet.gr X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.5 Received: from iris.teledomenet.local (unknown [192.168.1.71]) by smtp.teledomenet.gr (Postfix) with ESMTP id 6D466142047; Fri, 12 Dec 2008 17:17:48 +0200 (EET) From: Nikos Vassiliadis To: Alexander Motin Date: Fri, 12 Dec 2008 17:16:59 +0200 User-Agent: KMail/1.9.10 References: <1229005383.00046904.1228994401@10.7.7.3> <200812121612.34002.nvass@teledomenet.gr> <494277BD.2030804@mavhome.dp.ua> In-Reply-To: <494277BD.2030804@mavhome.dp.ua> X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812121716.59610.nvass@teledomenet.gr> Cc: freebsd-net@freebsd.org Subject: Re: ng_bridge + ng_ksocket 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, 12 Dec 2008 15:17:52 -0000 Thanks for the answers. Your hard work on MPD is much appreciated. Nikos From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 16:47:58 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5025A1065670 for ; Fri, 12 Dec 2008 16:47:58 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id CC1D38FC20 for ; Fri, 12 Dec 2008 16:47:57 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-107-112-105.carlnfd1.nsw.optusnet.com.au (c122-107-112-105.carlnfd1.nsw.optusnet.com.au [122.107.112.105]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mBCGlqxv008948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Dec 2008 03:47:55 +1100 Date: Sat, 13 Dec 2008 03:47:52 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Randall Stewart In-Reply-To: <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> Message-ID: <20081213030449.F2405@delplex.bde.org> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net , "Bruce M. Simpson" Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 12 Dec 2008 16:47:58 -0000 On Fri, 12 Dec 2008, Randall Stewart wrote: > Here is an updated patch it: > > 1) Fixes style9 issues (I hope.. I went back to vi and tried tabs :-0.. sigh > one of > these doys I will figure out why my .emacs settings just never cut it :-() Fraid not. % Index: netinet/udp_usrreq.c % =================================================================== % --- netinet/udp_usrreq.c (revision 185928) % +++ netinet/udp_usrreq.c (working copy) % @@ -488,10 +488,25 @@ % struct mbuf *n; % % n = m_copy(m, 0, M_COPYALL); % - if (n != NULL) % - udp_append(last, ip, n, iphlen + % - sizeof(struct udphdr), &udp_in); % - INP_RUNLOCK(last); % + Extra blank line. % + if (last->inp_ppcb == NULL) { % + if (n != NULL) % + udp_append(last, ip, n, iphlen + % + sizeof(struct udphdr), &udp_in); Line too long. % + INP_RUNLOCK(last); % + } else { % + /* Engage the tunneling protocol "/*" not on a line by itself. % + * we will have to leave the info_lock % + * up, since we are hunting through % + * multiple UDP inp's hope we don't break :-( Line too long. Defeats reasonable indentation of the rest of the comment. Missing punctuation after ":-(". % + */ % + udp_tunnel_function_t tunnel_func; Nested declaration. % + % + INP_RUNLOCK(last); % + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; Line too long. Typedef names involving functions normally use `func_t', not `function_t'. This is useful for reducing verboseness and resulting long lines but wouldn't fix the long line in the above, since everything in it is too verbose (in the middle there is an ugly cast whose only effect can be to avoid a warning ...). % @@ -516,10 +531,25 @@ % V_udpstat.udps_noportbcast++; % goto badheadlocked; % } % - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), % - &udp_in); % - INP_RUNLOCK(last); % - INP_INFO_RUNLOCK(&V_udbinfo); % + if (last->inp_ppcb == NULL) { % + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), % + &udp_in); % + INP_RUNLOCK(last); % + INP_INFO_RUNLOCK(&V_udbinfo); % + } else { % + /* Engage the tunneling protocol "/*" not on a line by itself. No comment on further instances of this % + * we must make sure all locks % + * are released when we call the % + * tunneling protocol. % + */ Long lines are ones longer than 80 characters. Splitting at 48 characters as in the above is not normal. % + udp_tunnel_function_t tunnel_func; Nested declaration. % @@ -563,6 +593,18 @@ % INP_RUNLOCK(inp); % goto badunlocked; % } % + if (inp->inp_ppcb) { % + /* Engage the tunneling protocol % + * we must make sure all locks % + * are released when we call the % + * tunneling protocol. % + */ More formatting for 48-column terminals. % + udp_tunnel_function_t tunnel_func; Nested declaration. Missing blank line after declarations. % ... % +int % +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f) % +{ % + struct inpcb *inp; % + inp = (struct inpcb *)so->so_pcb; Initialization in declaration. Not too bad here, but you don't do it for similar tunnel function pointer conversions. % + % + if (so->so_type != SOCK_DGRAM) { % + /* Not UDP socket... sorry */ Missing punctuation. % Index: netinet/udp_var.h % =================================================================== % --- netinet/udp_var.h (revision 185928) % +++ netinet/udp_var.h (working copy) % @@ -107,6 +107,10 @@ % void udp_input(struct mbuf *, int); % struct inpcb *udp_notify(struct inpcb *inp, int errno); % int udp_shutdown(struct socket *so); % + % + % +typedef void(*udp_tunnel_function_t)(struct mbuf *, int off); % +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f); I noticed this first in the initial patch. It has a style bug density of about 5 per line !-(: - 2 extra blank lines - typedef in the middle of (non-pointer non-typedef) prototypes - unsorted prototypes (at least the old 3 visible on the above are sorted) - new prototypes not indented normally though visible old ones all are - some parameters have names, some not. - style(9) says to always have names in the kernel, but this rule is usually violated - the first of the 3 visible old prototypes violates this rule - the first of the new prototypes violates this rule for the first of its 2 parameters only % #endif % % #endif % Index: netinet6/udp6_usrreq.c % =================================================================== % --- netinet6/udp6_usrreq.c (revision 185928) % +++ netinet6/udp6_usrreq.c (working copy) % @@ -286,9 +286,21 @@ % struct mbuf *n; % % if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { % - INP_RLOCK(last); % - udp6_append(last, n, off, &fromsa); % - INP_RUNLOCK(last); % + if (last->inp_ppcb) { % + /* Engage the tunneling protocol % + * we will have to leave the info_lock % + * up, since we are hunting through % + * multiple UDP inp's hope we don't break :-( % + */ Lines too long -- now formatting for 94-column terminals instead of 48-column ones using cut&pasted&indent. Missing punctuation (cut&paste). % + udp_tunnel_function_t tunnel_func; Nested declaration. Line too long. Missing blank line after declarations. % + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; Line too long. % + INP_RUNLOCK(last); % + tunnel_func(m, off); % + } else { % + INP_RLOCK(last); % + udp6_append(last, n, off, &fromsa); Line too long. % @@ -317,6 +329,19 @@ % } % INP_RLOCK(last); % INP_INFO_RUNLOCK(&V_udbinfo); % + if (last->inp_ppcb) { % + /* Engage the tunneling protocol % + * we must make sure all locks % + * are released when we call the % + * tunneling protocol. % + */ Now formatting for 56-column terminals. % @@ -354,6 +379,18 @@ % } % INP_RLOCK(inp); % INP_INFO_RUNLOCK(&V_udbinfo); % + if (inp->inp_ppcb) { % + /* Engage the tunneling protocol % + * we must make sure all locks % + * are released when we call the % + * tunneling protocol. % + */ Back to formatting for 48-column terminals. There are 6 near-copies of this comment. % + udp_tunnel_function_t tunnel_func; Nested declaration. Missing blank line after declaration. % + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; % + INP_RUNLOCK(inp); % + tunnel_func(m, off); Do you have to hold the lock to access inp->inp_ppcb? Otherwise you can avoid all the nested declarations and just use the pointer once. If the lock is needed, then what happens if the pointer changes after it is accessed? % + return (IPPROTO_DONE); % + } % udp6_append(inp, m, off, &fromsa); % INP_RUNLOCK(inp); % return (IPPROTO_DONE); Bruce From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 17:16:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06200106567A for ; Fri, 12 Dec 2008 17:16:16 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id 585DA8FC23 for ; Fri, 12 Dec 2008 17:16:14 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from aviko (aviko.aws-net.org.ua [192.168.32.4]) (authenticated bits=0) by alf.aws-net.org.ua (8.14.3/8.14.3) with ESMTP id mBCGjL3p061172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2008 18:45:21 +0200 (EET) (envelope-from artem@aws-net.org.ua) From: Artyom Viklenko Organization: Arto&Co. To: freebsd-net@freebsd.org Date: Fri, 12 Dec 2008 18:45:20 +0200 User-Agent: KMail/1.9.10 References: <20081211122828.CF3958FC16@mx1.freebsd.org> <20081211123958.GA5332@zeninc.net> In-Reply-To: <20081211123958.GA5332@zeninc.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200812121845.20262.artem@aws-net.org.ua> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (alf.aws-net.org.ua [192.168.32.61]); Fri, 12 Dec 2008 18:45:21 +0200 (EET) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on alf.aws-net.org.ua X-Virus-Status: Clean Subject: Re: NAT-T + ipsec integration 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, 12 Dec 2008 17:16:16 -0000 On Thursday 11 December 2008 14:39:58 VANHULLEBUS Yvan wrote: > On Thu, Dec 11, 2008 at 04:02:01AM -0800, Gabe wrote: > > Hello all > > Hi. > > > Does anyone know how to enable nat traversal on freebsd? > > > > I've got a site to site ipsec tunnel setup but clients behind the > > nat can't vpn through it. Any help would be appreciated. > > Actually, you can apply a patch to src/sys and recompile your kernel > with IPSEC_NAT_T options. > Patches are available here: > http://people.freebsd.org/~vanhu/NAT-T/ And what about patches for 6.4-RELEASE? > > > You can also try to play with Perforce's branch, but it is still work > in progress to have a cleaned up version of PFKey interface (it may > work, but I just started to set up some testing hosts). > > > > To answer the question some people may ask in this thread: the whole > patch should be included in TRUNK as soon as PFKey cleanup will be > done (which means "implemented + heavilly tested + reviewed"). > > > > Yvan. > _______________________________________________ > 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" --             Sincerely yours,                              Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem artem@viklenko.net   | ================================ FreeBSD: The Power to Serve   -  http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 17:18:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9F671065672 for ; Fri, 12 Dec 2008 17:18:38 +0000 (UTC) (envelope-from mamruoc@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id 20BE28FC1A for ; Fri, 12 Dec 2008 17:18:37 +0000 (UTC) (envelope-from mamruoc@gmail.com) Received: by ewy14 with SMTP id 14so2169066ewy.19 for ; Fri, 12 Dec 2008 09:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=jLPWEBELNq1Xfk92NckKAbTITJqXt1uHbgUdCnQmpnQ=; b=cWU6NfjlH7Ud4hIrWCX0B9wpyfzO82UTt2ZuXBN+/aN7GSntVyEBIM15nkT/crYvWH Tno2sUed/dtjINtkwswVhexzzWG5nJyCcPfRPB46NF9B23z1X0Dok1MMckATrUDTqIew VqLcl9OhS4DyzV08Ekftdwle/BpK5UfxHDrt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jddXmPqMstaRr2qP0idZcKrE91nGb+qzvM3wrd0+h7mZkJnxy2K4OgLmvI0lIgUq/A 1E6TUTQ0tqCfcaF0nzS4KkJ6ABCR/8vCnsriayse30AqV4LS0/eS81PATn6QxFF6QnSu LWZU88zbMn2bBqvSvOm8l5qKH9GEfyam5FJ4M= Received: by 10.210.88.7 with SMTP id l7mr1063946ebb.135.1229102316818; Fri, 12 Dec 2008 09:18:36 -0800 (PST) Received: from appuru.bbse.no (217-14-12-49-dhcp-osl.bbse.no [217.14.12.49]) by mx.google.com with ESMTPS id 7sm462051eyg.42.2008.12.12.09.18.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Dec 2008 09:18:36 -0800 (PST) Message-ID: <49429CEB.60607@gmail.com> Date: Fri, 12 Dec 2008 18:18:35 +0100 From: Mam Ruoc User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> <20081212015842.GH46707@cdnetworks.co.kr> <4941C6BF.4080809@gmail.com> <20081212021549.GJ46707@cdnetworks.co.kr> In-Reply-To: <20081212021549.GJ46707@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: vge driver does not work on a VIA EPIA EN12000EG 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, 12 Dec 2008 17:18:38 -0000 Pyun YongHyeon wrote: > And rebuild kernel and then reboot. You don't need to reinstall > FreeBSD. Oki, I have done that and rebooted, the driver seems to work better now: Dec 12 17:47:16 freebsd kernel: vge0: port 0xf800-0xf8ff mem 0xfdffe000-0xfdffe0ff irq 18 at device 14.0 on pci0 Dec 12 17:47:16 freebsd kernel: vge0: MSIX count : 0 Dec 12 17:47:16 freebsd kernel: vge0: MSI count : 0 Dec 12 17:47:16 freebsd kernel: miibus0: on vge0 Dec 12 17:47:16 freebsd kernel: vge0: Ethernet address: 00:40:63:e9:9a:1c Dec 12 17:47:16 freebsd kernel: vge0: [FILTER] What is the next step to be able to make this fix go into the FreeBSD 7.0 tree? Mam From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 17:19:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7958A106568D for ; Fri, 12 Dec 2008 17:19:30 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id E2F8B8FC1A for ; Fri, 12 Dec 2008 17:19:29 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-037-182.pools.arcor-ip.net [88.66.37.182]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1LBBfk2a9w-0002Cd; Fri, 12 Dec 2008 18:19:28 +0100 Received: (qmail 73472 invoked from network); 12 Dec 2008 17:19:28 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by mx.laiers.local with SMTP; 12 Dec 2008 17:19:28 -0000 From: Max Laier Organization: FreeBSD To: Randall Stewart Date: Fri, 12 Dec 2008 18:19:27 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <200812111412.16757.max@love2party.net> <11F9C4F4-E893-46DA-96C3-1984131159D6@lakerest.net> In-Reply-To: <11F9C4F4-E893-46DA-96C3-1984131159D6@lakerest.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812121819.27990.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18YhzMOgoHThNWg9Spu7GgipvDMtj5Aj/Hm5Mq 6psJ1K0WtUPMIQGVKb2KY/vryd/syEQIKA57cdBXmNhI8Y4qSq DRX1oD+Ikft+TOVRzR5FA== Cc: freebsd-net@freebsd.org Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 12 Dec 2008 17:19:30 -0000 On Friday 12 December 2008 13:56:38 Randall Stewart wrote: > On Dec 11, 2008, at 8:12 AM, Max Laier wrote: > > On Thursday 11 December 2008 13:50:39 Randall Stewart wrote: ... > Another thing... kinda weird.. when I have this thing working with > SCTP and I > let the SCTP stack try to initialize the socket right away.. I get bogus > results. The port is actually binding.. but yet it cant be sent to. If I > unbind i.e. close the socket that got created.. then do a sysctl to re- > add > the same port.. all works fine. > > For now I am going to make SCTP NOT do this.. and have to add it to the > sysctl's in /etc/sysctl.conf to add UDP tunneling. > > Only other solution would be a timer in the transport after startup to > do this binding... You can probably do a SYSINIT in SI_SUB_PROTO_DOMAIN around the middle and you should be golden. If it turns out that this is not late enough you can check sys/kernel.h for later SI_SUBs that might be fitting. > I was wondering if I would see a race in the protocol stack > initialization.. basically > my guess is SCTP initializes ahead of UDP.. so its actually a wonder I > did not crash ;-D -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 17:55:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46B991065676 for ; Fri, 12 Dec 2008 17:55:02 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 04DAD8FC19 for ; Fri, 12 Dec 2008 17:55:02 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from albator.zen.inc (albator.zen.inc [192.168.1.5]) by smtp.zeninc.net (smtpd) with ESMTP id 399302798B8 for ; Fri, 12 Dec 2008 18:55:01 +0100 (CET) Received: by albator.zen.inc (Postfix, from userid 1000) id 2BD267343B; Fri, 12 Dec 2008 18:55:01 +0100 (CET) Date: Fri, 12 Dec 2008 18:55:01 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20081212175500.GA2573@zeninc.net> References: <20081211122828.CF3958FC16@mx1.freebsd.org> <20081211123958.GA5332@zeninc.net> <200812121845.20262.artem@aws-net.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200812121845.20262.artem@aws-net.org.ua> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: NAT-T + ipsec integration 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, 12 Dec 2008 17:55:02 -0000 On Fri, Dec 12, 2008 at 06:45:20PM +0200, Artyom Viklenko wrote: > On Thursday 11 December 2008 14:39:58 VANHULLEBUS Yvan wrote: [....] > > Actually, you can apply a patch to src/sys and recompile your kernel > > with IPSEC_NAT_T options. > > Patches are available here: > > http://people.freebsd.org/~vanhu/NAT-T/ > > And what about patches for 6.4-RELEASE? I just not tested on 6.4 (almost all my devices moved to 7.x, and the remaining ones will stay in 6.3 for various reasons), but 6.3 patch should work on 6.4 if it compiles cleanly (I did NOT check every single kernel change between 6.3 and 6.4). If people can test it and see some compile/runtime problems, please report them, I'll try to fix them. Yvan. From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 18:47:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DA49106564A for ; Fri, 12 Dec 2008 18:47:26 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 30C868FC17 for ; Fri, 12 Dec 2008 18:47:25 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (4oilrprus0bihkl5@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id mBCIClxO064421; Fri, 12 Dec 2008 10:12:47 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id mBCICltC064420; Fri, 12 Dec 2008 10:12:47 -0800 (PST) (envelope-from jmg) Date: Fri, 12 Dec 2008 10:12:46 -0800 From: John-Mark Gurney To: Vyacheslav Bocharov Message-ID: <20081212181246.GG34842@funkthat.com> Mail-Followup-To: Vyacheslav Bocharov , freebsd-net@freebsd.org References: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hydrogen.funkthat.com [127.0.0.1]); Fri, 12 Dec 2008 10:12:47 -0800 (PST) Cc: freebsd-net@freebsd.org Subject: Re: strange problem with ifconfig alias 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, 12 Dec 2008 18:47:26 -0000 Vyacheslav Bocharov wrote this message on Thu, Dec 11, 2008 at 16:29 +0200: > I have strange problem with ifconfig: I can't add ip address to interface: Have you followed the instructions in the handbook: http://www.freebsd.org/doc/en/books/handbook/configtuning-virtual-hosts.html > root@chip# ifconfig em1 alias 195.3.245.xx/30 > ifconfig: ioctl (SIOCAIFADDR): File exists If there is already an ip in that range on the interface, you need to use: ifconfig em1 alias 195.3.245.xx/32 Next time include ifconfig -a so we know what addresses and interfaces you have. Makes diagnostics easier. P.S. This question is better targeted to -questions. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 18:50:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2F521065672 for ; Fri, 12 Dec 2008 18:50:14 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id B28DF8FC16 for ; Fri, 12 Dec 2008 18:50:14 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=pTPoLDtzUVd0mrxpCUl7J8vqnWACF21EdkhyMNGOsmwUD+hChv8xLlBk0jBtKfy3; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LBD5Z-0003aG-L9; Fri, 12 Dec 2008 13:50:13 -0500 Message-ID: <4942B264.5020607@earthlink.net> Date: Fri, 12 Dec 2008 13:50:12 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: VANHULLEBUS Yvan References: <20081211122828.CF3958FC16@mx1.freebsd.org> <20081211123958.GA5332@zeninc.net> <200812121845.20262.artem@aws-net.org.ua> <20081212175500.GA2573@zeninc.net> In-Reply-To: <20081212175500.GA2573@zeninc.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec793b002ce11d456fcefb770d83ed602ad6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: freebsd-net@freebsd.org Subject: Re: NAT-T + ipsec integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 18:50:15 -0000 VANHULLEBUS Yvan wrote: > On Fri, Dec 12, 2008 at 06:45:20PM +0200, Artyom Viklenko wrote: >> On Thursday 11 December 2008 14:39:58 VANHULLEBUS Yvan wrote: > [....] >>> Actually, you can apply a patch to src/sys and recompile your kernel >>> with IPSEC_NAT_T options. >>> Patches are available here: >>> http://people.freebsd.org/~vanhu/NAT-T/ >> And what about patches for 6.4-RELEASE? > > I just not tested on 6.4 (almost all my devices moved to 7.x, and the > remaining ones will stay in 6.3 for various reasons), but 6.3 patch > should work on 6.4 if it compiles cleanly (I did NOT check every > single kernel change between 6.3 and 6.4). > > If people can test it and see some compile/runtime problems, please > report them, I'll try to fix them. > > > > Yvan. > _______________________________________________ > 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" > Are there any restrictions for nat-t on freebsd-6, like number of vpns that can be natted? Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 18:57:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 138CF1065675 for ; Fri, 12 Dec 2008 18:57:02 +0000 (UTC) (envelope-from adeepv@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by mx1.freebsd.org (Postfix) with ESMTP id 915DD8FC14 for ; Fri, 12 Dec 2008 18:57:01 +0000 (UTC) (envelope-from adeepv@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so1522695fkk.11 for ; Fri, 12 Dec 2008 10:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:x-priority :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=P/431Ba3Nam+gP5qI5w4JXji9aujbhYvGimomUGUArQ=; b=XwRj12oY/A+ClLZl8sh7WaZ0bOMmCb1JIn/sETWaliuQj6FoppQj53hhFcfw6luYnv 00qERy5HFZ9dkwyoUrVrBgqG8pJOm62pqVzez1E/vT4+LIaNfPuHZydocV1xqQF7ktKJ O62lOkMcUVwbdH6EMXYAvp03ksJsUYKTevO/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:x-priority:message-id:to:cc:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; b=ggN3UrLKrqbBn4dJHkR2qDm5NGCJQYl/3r031cqJ7SU/XdlrRe1ZUjvunwIDVq+ycJ GMNqpOqF2HdHNcXFbxsQZMip+ve7I3SnhvYQa9awTGaO9a7Fj863y++z0wUj2cnQMwhC FLfdKVM89ZrRJq7rw9DpMRIYnBbWMCibMZSuk= Received: by 10.103.138.16 with SMTP id q16mr1879223mun.114.1229108220375; Fri, 12 Dec 2008 10:57:00 -0800 (PST) Received: from DEEP (217-201-124-91.pool.ukrtel.net [91.124.201.217]) by mx.google.com with ESMTPS id 25sm4255340mul.8.2008.12.12.10.56.58 (version=SSLv3 cipher=OTHER); Fri, 12 Dec 2008 10:56:59 -0800 (PST) Date: Fri, 12 Dec 2008 20:56:48 +0200 From: Vyacheslav Bocharov X-Priority: 3 (Normal) Message-ID: <566611296.20081212205648@gmail.com> To: John-Mark Gurney In-Reply-To: <20081212181246.GG34842@funkthat.com> References: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> <20081212181246.GG34842@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re[2]: strange problem with ifconfig alias X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vyacheslav Bocharov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 18:57:02 -0000 >> root@chip# ifconfig em1 alias 195.3.245.xx/30 >> ifconfig: ioctl (SIOCAIFADDR): File exists > If there is already an ip in that range on the interface, you need to use: > ifconfig em1 alias 195.3.245.xx/32 There are no other ip on any interfaces in that range > Next time include ifconfig -a so we know what addresses and interfaces > you have. Makes diagnostics easier. I have included in mail: root@chip# ifconfig |grep 195.3.245. root@chip# -- Vyacheslav mailto:adeepv@gmail.com From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 19:30:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 112DA1065672 for ; Fri, 12 Dec 2008 19:30:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id BFEC88FC1B for ; Fri, 12 Dec 2008 19:30:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id A593241C679; Fri, 12 Dec 2008 20:30:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id GF54-Tae05mX; Fri, 12 Dec 2008 20:30:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 3C8D141C67E; Fri, 12 Dec 2008 20:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 193664448DD; Fri, 12 Dec 2008 19:25:58 +0000 (UTC) Date: Fri, 12 Dec 2008 19:25:57 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Vyacheslav Bocharov In-Reply-To: <566611296.20081212205648@gmail.com> Message-ID: <20081212192435.L97918@maildrop.int.zabbadoz.net> References: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> <20081212181246.GG34842@funkthat.com> <566611296.20081212205648@gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re[2]: strange problem with ifconfig alias 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, 12 Dec 2008 19:30:09 -0000 On Fri, 12 Dec 2008, Vyacheslav Bocharov wrote: Hi, >>> root@chip# ifconfig em1 alias 195.3.245.xx/30 >>> ifconfig: ioctl (SIOCAIFADDR): File exists > >> If there is already an ip in that range on the interface, you need to use: >> ifconfig em1 alias 195.3.245.xx/32 > There are no other ip on any interfaces in that range > >> Next time include ifconfig -a so we know what addresses and interfaces >> you have. Makes diagnostics easier. > I have included in mail: > > root@chip# ifconfig |grep 195.3.245. > root@chip# which freebsd version are you using? /bz PS: parameters like alias belong to the end of the command (but that won't help you; just the general advise). -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 20:08:49 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BB9A1065672; Fri, 12 Dec 2008 20:08:49 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id CCF0C8FC12; Fri, 12 Dec 2008 20:08:48 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mBCK8i9v026264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Dec 2008 15:08:47 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1229112527; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=vhKRCJt8XHyXVrifqjrv7QuckLjjXFEW0eEW2oDmXxKaXzMgHH1egcW L3Bi0iosJctT9rBPbC0zkxskodbtsbA== Message-Id: <8835B402-CD0D-4246-ABD3-F2B1BB230820@lakerest.net> From: Randall Stewart To: Bruce Evans In-Reply-To: <20081213030449.F2405@delplex.bde.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 15:08:44 -0500 References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net , "Bruce M. Simpson" Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 12 Dec 2008 20:08:49 -0000 Well tell you what Bruce: How about if I just run the WHOLE file through s9indent... This will fix ALL my problems.. and of course "fix" the rest of the file too.. Unless you think its already in conformance (bet you its not) :-) R On Dec 12, 2008, at 11:47 AM, Bruce Evans wrote: > On Fri, 12 Dec 2008, Randall Stewart wrote: > >> Here is an updated patch it: >> >> 1) Fixes style9 issues (I hope.. I went back to vi and tried >> tabs :-0.. sigh one of >> these doys I will figure out why my .emacs settings just never cut >> it :-() > > Fraid not. > > % Index: netinet/udp_usrreq.c > % =================================================================== > % --- netinet/udp_usrreq.c (revision 185928) > % +++ netinet/udp_usrreq.c (working copy) > % @@ -488,10 +488,25 @@ > % struct mbuf *n; > % % n = m_copy(m, 0, M_COPYALL); > % - if (n != NULL) > % - udp_append(last, ip, n, iphlen + > % - sizeof(struct udphdr), &udp_in); > % - INP_RUNLOCK(last); > % + > > Extra blank line. > > % + if (last->inp_ppcb == NULL) { > % + if (n != NULL) > % + udp_append(last, ip, n, iphlen + > % + sizeof(struct udphdr), &udp_in); > > Line too long. > > % + INP_RUNLOCK(last); > % + } else { > % + /* Engage the tunneling protocol > > "/*" not on a line by itself. > > % + * we will have to leave the info_lock > % + * up, since we are hunting through % + * multiple UDP > inp's hope we don't break :-( > > Line too long. Defeats reasonable indentation of the rest of the > comment. > > Missing punctuation after ":-(". > > % + */ > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > % + > % + INP_RUNLOCK(last); > % + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; > > Line too long. > > Typedef names involving functions normally use `func_t', not > `function_t'. > This is useful for reducing verboseness and resulting long lines but > wouldn't > fix the long line in the above, since everything in it is too verbose > (in the middle there is an ugly cast whose only effect can be to > avoid a > warning ...). > > % @@ -516,10 +531,25 @@ > % V_udpstat.udps_noportbcast++; > % goto badheadlocked; > % } > % - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), > % - &udp_in); > % - INP_RUNLOCK(last); > % - INP_INFO_RUNLOCK(&V_udbinfo); > % + if (last->inp_ppcb == NULL) { > % + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), > % + &udp_in); > % + INP_RUNLOCK(last); > % + INP_INFO_RUNLOCK(&V_udbinfo); > % + } else { > % + /* Engage the tunneling protocol > > "/*" not on a line by itself. No comment on further instances of this > > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > Long lines are ones longer than 80 characters. Splitting at 48 > characters > as in the above is not normal. > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > % @@ -563,6 +593,18 @@ > % INP_RUNLOCK(inp); > % goto badunlocked; > % } > % + if (inp->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > More formatting for 48-column terminals. > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > Missing blank line after declarations. > > % ... > % +int > % +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t > f) > % +{ > % + struct inpcb *inp; > % + inp = (struct inpcb *)so->so_pcb; > > Initialization in declaration. Not too bad here, but you don't do > it for > similar tunnel function pointer conversions. > > % + > % + if (so->so_type != SOCK_DGRAM) { > % + /* Not UDP socket... sorry */ > > Missing punctuation. > > % Index: netinet/udp_var.h > % =================================================================== > % --- netinet/udp_var.h (revision 185928) > % +++ netinet/udp_var.h (working copy) > % @@ -107,6 +107,10 @@ > % void udp_input(struct mbuf *, int); > % struct inpcb *udp_notify(struct inpcb *inp, int errno); > % int udp_shutdown(struct socket *so); > % + > % + > % +typedef void(*udp_tunnel_function_t)(struct mbuf *, int off); > % +int udp_set_kernel_tunneling(struct socket *so, > udp_tunnel_function_t f); > > I noticed this first in the initial patch. It has a style bug > density of > about 5 per line !-(: > > - 2 extra blank lines > - typedef in the middle of (non-pointer non-typedef) prototypes > - unsorted prototypes (at least the old 3 visible on the above are > sorted) > - new prototypes not indented normally though visible old ones all are > - some parameters have names, some not. > - style(9) says to always have names in the kernel, but this rule > is usually > violated > - the first of the 3 visible old prototypes violates this rule > - the first of the new prototypes violates this rule for the first > of its > 2 parameters only > > % #endif > % % #endif > % Index: netinet6/udp6_usrreq.c > % =================================================================== > % --- netinet6/udp6_usrreq.c (revision 185928) > % +++ netinet6/udp6_usrreq.c (working copy) > % @@ -286,9 +286,21 @@ > % struct mbuf *n; > % % if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { > % - INP_RLOCK(last); > % - udp6_append(last, n, off, &fromsa); > % - INP_RUNLOCK(last); > % + if (last->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we will have to leave the info_lock > % + * up, since we are hunting through % + * multiple > UDP inp's hope we don't break :-( > % + */ > > Lines too long -- now formatting for 94-column terminals instead of > 48-column ones using cut&pasted&indent. > > Missing punctuation (cut&paste). > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > Line too long. > > Missing blank line after declarations. > > % + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; > > Line too long. > > % + INP_RUNLOCK(last); > % + tunnel_func(m, off); > % + } else { > % + INP_RLOCK(last); > % + udp6_append(last, n, off, &fromsa); > > Line too long. > > % @@ -317,6 +329,19 @@ > % } > % INP_RLOCK(last); > % INP_INFO_RUNLOCK(&V_udbinfo); > % + if (last->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > Now formatting for 56-column terminals. > > % @@ -354,6 +379,18 @@ > % } > % INP_RLOCK(inp); > % INP_INFO_RUNLOCK(&V_udbinfo); > % + if (inp->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > Back to formatting for 48-column terminals. > > There are 6 near-copies of this comment. > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > Missing blank line after declaration. > > % + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; > % + INP_RUNLOCK(inp); > % + tunnel_func(m, off); > > Do you have to hold the lock to access inp->inp_ppcb? Otherwise you > can > avoid all the nested declarations and just use the pointer once. If > the > lock is needed, then what happens if the pointer changes after it is > accessed? > > % + return (IPPROTO_DONE); > % + } > % udp6_append(inp, m, off, &fromsa); > % INP_RUNLOCK(inp); > % return (IPPROTO_DONE); > > Bruce > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 20:09:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB4CB1065677 for ; Fri, 12 Dec 2008 20:09:54 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 377768FC1B for ; Fri, 12 Dec 2008 20:09:54 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mBCK9r9Z026283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Dec 2008 15:09:53 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1229112593; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=XVUfLPPOPbX59IvjjAroCO3HpX1l39iGM/oh/EU131lXmzgb7A64d95 4DfY0HajAzIfGiXeoUe1068eg4MJz+w== Message-Id: <6CD72FAF-6D22-4BD2-AADD-AFF686539441@lakerest.net> From: Randall Stewart To: Max Laier In-Reply-To: <200812121819.27990.max@love2party.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 15:09:52 -0500 References: <200812111412.16757.max@love2party.net> <11F9C4F4-E893-46DA-96C3-1984131159D6@lakerest.net> <200812121819.27990.max@love2party.net> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net@freebsd.org Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 12 Dec 2008 20:09:54 -0000 On Dec 12, 2008, at 12:19 PM, Max Laier wrote: > On Friday 12 December 2008 13:56:38 Randall Stewart wrote: >> On Dec 11, 2008, at 8:12 AM, Max Laier wrote: >>> On Thursday 11 December 2008 13:50:39 Randall Stewart wrote: > ... >> Another thing... kinda weird.. when I have this thing working with >> SCTP and I >> let the SCTP stack try to initialize the socket right away.. I get >> bogus >> results. The port is actually binding.. but yet it cant be sent to. >> If I >> unbind i.e. close the socket that got created.. then do a sysctl to >> re- >> add >> the same port.. all works fine. >> >> For now I am going to make SCTP NOT do this.. and have to add it to >> the >> sysctl's in /etc/sysctl.conf to add UDP tunneling. >> >> Only other solution would be a timer in the transport after startup >> to >> do this binding... > > You can probably do a SYSINIT in SI_SUB_PROTO_DOMAIN around the > middle and you > should be golden. If it turns out that this is not late enough you > can check > sys/kernel.h for later SI_SUBs that might be fitting. Hmm, thats a way to go.. but for now I don't mind leaving it default to "off" and have to have someone configure it on in there /etc/sysctl.conf That way its on only when you WANT to allow UDP tunneling :-) R > > >> I was wondering if I would see a race in the protocol stack >> initialization.. basically >> my guess is SCTP initializes ahead of UDP.. so its actually a >> wonder I >> did not crash ;-D > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 20:27:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C38511065670 for ; Fri, 12 Dec 2008 20:27:35 +0000 (UTC) (envelope-from adeepv@gmail.com) Received: from mail-bw0-f14.google.com (mail-bw0-f14.google.com [209.85.218.14]) by mx1.freebsd.org (Postfix) with ESMTP id 21C688FC2C for ; Fri, 12 Dec 2008 20:27:34 +0000 (UTC) (envelope-from adeepv@gmail.com) Received: by bwz7 with SMTP id 7so3693672bwz.19 for ; Fri, 12 Dec 2008 12:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:x-priority :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=89mbGmd8gkdOhT1dP/Z7q5Ehr6eP6RyFjbR5W3evtf8=; b=qoK3+M/HkHK2zjI8Mfxnp2rYYfXF4aPpgTIdXvpKQFYUAfzchmTdJ+FPVST0ycVlPO qNYH8zipXeDX9XRpjbntpzffbDkXgQPpUrZ2nW5R0eRfssnm1tvEYwpdeXN9xbctLS0h R0lBMbUeQ0sapYq5tSft5RD5cPetVHK3TKY58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:x-priority:message-id:to:cc:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; b=nRz6th5cEsOGS3TannGJHSPhTJzg532T6hWP0GyPDXNHXwaXeGAB37BKuZvvs9p+b5 7rkGs9miMXHJrKgx45uED2SbuhSRFRdQKUbPaCIbwgv6bukUeizuXptJXrBvqm2OAMll TIXG+rugcW0bqSPtnT35FLUPs+k9ZaduuOPeo= Received: by 10.103.224.17 with SMTP id b17mr2016900mur.61.1229113574494; Fri, 12 Dec 2008 12:26:14 -0800 (PST) Received: from DEEP (217-201-124-91.pool.ukrtel.net [91.124.201.217]) by mx.google.com with ESMTPS id y37sm6982495mug.36.2008.12.12.12.26.12 (version=SSLv3 cipher=OTHER); Fri, 12 Dec 2008 12:26:13 -0800 (PST) Date: Fri, 12 Dec 2008 22:26:02 +0200 From: Vyacheslav Bocharov X-Priority: 3 (Normal) Message-ID: <308254201.20081212222602@gmail.com> To: "Bjoern A. Zeeb" In-Reply-To: <20081212192435.L97918@maildrop.int.zabbadoz.net> References: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> <20081212181246.GG34842@funkthat.com> <566611296.20081212205648@gmail.com> <20081212192435.L97918@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re[3]: strange problem with ifconfig alias X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vyacheslav Bocharov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 20:27:35 -0000 Çäđŕâńňâóéňĺ, Bjoern. Âű ďčńŕëč 12 äĺęŕáđ˙ 2008 ă., 21:25:57: > On Fri, 12 Dec 2008, Vyacheslav Bocharov wrote: > Hi, >>>> root@chip# ifconfig em1 alias 195.3.245.xx/30 >>>> ifconfig: ioctl (SIOCAIFADDR): File exists >> >>> If there is already an ip in that range on the interface, you need to use: >>> ifconfig em1 alias 195.3.245.xx/32 >> There are no other ip on any interfaces in that range >> >>> Next time include ifconfig -a so we know what addresses and interfaces >>> you have. Makes diagnostics easier. >> I have included in mail: >> >> root@chip# ifconfig |grep 195.3.245. >> root@chip# > which freebsd version are you using? > /bz > PS: parameters like alias belong to the end of the command (but that > won't help you; just the general advise). FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Wed Dec 10 10:07:04 EET 2008 i386 -- Ń óâŕćĺíčĺě, Vyacheslav mailto:adeepv@gmail.com From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 20:27:59 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 353C8106567B; Fri, 12 Dec 2008 20:27:59 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id AC3ED8FC1F; Fri, 12 Dec 2008 20:27:57 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mBCKRujJ026508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Dec 2008 15:27:56 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1229113676; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Mime-Version:Subject:Date:References:X-Mailer; b=080zG2ujyr9WSheoHQ gUDaUROUtG7uG/VqoaP1N5E2pZzzXevfMTlEDSGHazpWHZcvi/IVKY4HZ25h18Wb9eN w== Message-Id: From: Randall Stewart To: Bruce Evans In-Reply-To: <20081213030449.F2405@delplex.bde.org> Content-Type: multipart/mixed; boundary=Apple-Mail-90--449110523 Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 15:27:56 -0500 References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net , "Bruce M. Simpson" Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 12 Dec 2008 20:27:59 -0000 --Apple-Mail-90--449110523 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Bruce: So lets see: 1) I went ahead and fixed the comments.. even added a ! instead of :-( 2) No problem using func_t.. changed to that.. seems nicer :-D 3) Removed an extra cr or two you pointed out.. hopefully got them all. 4) I disagree with you on the cast... its not ugly.. it prevents us from having to have a per_pcb structure for UDP when all we need is one pointer. As I said in my first post.. it seemed like to much overhead, creating a zone for a single pointer... I am not adverse to casts .. but of course I guess I am just an old fart who has been around to many years writing code :-) 5) I ran s9indent.. and of course it found a lot of other things you missed.. but that is the way of s9indent I have found :-D R --Apple-Mail-90--449110523 Content-Disposition: attachment; filename=diff_with_s9 Content-Type: application/octet-stream; x-unix-mode=0644; name="diff_with_s9" Content-Transfer-Encoding: 7bit Index: netinet/udp_usrreq.c =================================================================== --- netinet/udp_usrreq.c (revision 185928) +++ netinet/udp_usrreq.c (working copy) @@ -97,7 +97,8 @@ */ #ifdef VIMAGE_GLOBALS -int udp_blackhole; +int udp_blackhole; + #endif /* @@ -106,11 +107,13 @@ * packets that would otherwise be discarded due to bad checksums, and may * cause problems (especially for NFS data blocks). */ -static int udp_cksum = 1; +static int udp_cksum = 1; + SYSCTL_INT(_net_inet_udp, UDPCTL_CHECKSUM, checksum, CTLFLAG_RW, &udp_cksum, 0, "compute udp checksum"); -int udp_log_in_vain = 0; +int udp_log_in_vain = 0; + SYSCTL_INT(_net_inet_udp, OID_AUTO, log_in_vain, CTLFLAG_RW, &udp_log_in_vain, 0, "Log all incoming UDP packets"); @@ -118,26 +121,28 @@ CTLFLAG_RW, udp_blackhole, 0, "Do not send port unreachables for refused connects"); -u_long udp_sendspace = 9216; /* really max datagram size */ - /* 40 1K datagrams */ +u_long udp_sendspace = 9216; /* really max datagram size */ + + /* 40 1K datagrams */ SYSCTL_ULONG(_net_inet_udp, UDPCTL_MAXDGRAM, maxdgram, CTLFLAG_RW, &udp_sendspace, 0, "Maximum outgoing UDP datagram size"); -u_long udp_recvspace = 40 * (1024 + +u_long udp_recvspace = 40 * (1024 + #ifdef INET6 - sizeof(struct sockaddr_in6) + sizeof(struct sockaddr_in6) #else - sizeof(struct sockaddr_in) + sizeof(struct sockaddr_in) #endif - ); +); SYSCTL_ULONG(_net_inet_udp, UDPCTL_RECVSPACE, recvspace, CTLFLAG_RW, &udp_recvspace, 0, "Maximum space for incoming UDP datagrams"); #ifdef VIMAGE_GLOBALS -struct inpcbhead udb; /* from udp_var.h */ -struct inpcbinfo udbinfo; -struct udpstat udpstat; /* from udp_var.h */ +struct inpcbhead udb; /* from udp_var.h */ +struct inpcbinfo udbinfo; +struct udpstat udpstat; /* from udp_var.h */ + #endif #ifndef UDBHASHSIZE @@ -148,9 +153,10 @@ CTLFLAG_RW, udpstat, udpstat, "UDP statistics (struct udpstat, netinet/udp_var.h)"); -static void udp_detach(struct socket *so); -static int udp_output(struct inpcb *, struct mbuf *, struct sockaddr *, - struct mbuf *, struct thread *); +static void udp_detach(struct socket *so); +static int +udp_output(struct inpcb *, struct mbuf *, struct sockaddr *, + struct mbuf *, struct thread *); static void udp_zone_change(void *tag) @@ -204,8 +210,10 @@ struct sockaddr *append_sa; struct socket *so; struct mbuf *opts = 0; + #ifdef INET6 struct sockaddr_in6 udp_in6; + #endif INP_RLOCK_ASSERT(inp); @@ -218,7 +226,7 @@ V_ipsec4stat.in_polvio++; return; } -#endif /* IPSEC */ +#endif /* IPSEC */ #ifdef MAC if (mac_inpcb_check_deliver(inp, n) != 0) { m_freem(n); @@ -271,8 +279,10 @@ int len; struct ip save_ip; struct sockaddr_in udp_in; + #ifdef IPFIREWALL_FORWARD struct m_tag *fwd_tag; + #endif ifp = m->m_pkthdr.rcvif; @@ -283,11 +293,10 @@ * user, and use on returned packets, but we don't yet have a way to * check the checksum with options still present. */ - if (iphlen > sizeof (struct ip)) { + if (iphlen > sizeof(struct ip)) { ip_stripoptions(m, (struct mbuf *)0); iphlen = sizeof(struct ip); } - /* * Get IP and UDP header together in first mbuf. */ @@ -330,7 +339,6 @@ m_adj(m, len - ip->ip_len); /* ip->ip_len = len; */ } - /* * Save a copy of the IP header in case we want restore it for * sending an ICMP error message in response. @@ -360,7 +368,7 @@ bcopy(((struct ipovly *)ip)->ih_x1, b, 9); bzero(((struct ipovly *)ip)->ih_x1, 9); ((struct ipovly *)ip)->ih_len = uh->uh_ulen; - uh_sum = in_cksum(m, len + sizeof (struct ip)); + uh_sum = in_cksum(m, len + sizeof(struct ip)); bcopy(b, ((struct ipovly *)ip)->ih_x1, 9); } if (uh_sum) { @@ -387,7 +395,8 @@ uh->uh_dport = ntohs(next_hop->sin_port); /* - * Remove the tag from the packet. We don't need it anymore. + * Remove the tag from the packet. We don't need it + * anymore. */ m_tag_delete(m, fwd_tag); } @@ -414,10 +423,11 @@ inp->inp_faddr.s_addr != ip->ip_src.s_addr) continue; /* - * XXX: Do not check source port of incoming datagram - * unless inp_connect() has been called to bind the - * fport part of the 4-tuple; the source could be - * trying to talk to us with an ephemeral port. + * XXX: Do not check source port of incoming + * datagram unless inp_connect() has been called to + * bind the fport part of the 4-tuple; the source + * could be trying to talk to us with an ephemeral + * port. */ if (inp->inp_fport != 0 && inp->inp_fport != uh->uh_sport) @@ -426,16 +436,16 @@ INP_RLOCK(inp); /* - * Handle socket delivery policy for any-source - * and source-specific multicast. [RFC3678] + * Handle socket delivery policy for any-source and + * source-specific multicast. [RFC3678] */ imo = inp->inp_moptions; if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) && imo != NULL) { - struct sockaddr_in sin; - struct in_msource *ims; - int blocked, mode; - size_t idx; + struct sockaddr_in sin; + struct in_msource *ims; + int blocked, mode; + size_t idx; bzero(&sin, sizeof(struct sockaddr_in)); sin.sin_len = sizeof(struct sockaddr_in); @@ -447,27 +457,29 @@ (struct sockaddr *)&sin); if (idx == -1) { /* - * No group membership for this socket. - * Do not bump udps_noportbcast, as - * this will happen further down. + * No group membership for this + * socket. Do not bump + * udps_noportbcast, as this will + * happen further down. */ blocked++; } else { /* - * Check for a multicast source filter - * entry on this socket for this group. - * MCAST_EXCLUDE is the default - * behaviour. It means default accept; - * entries, if present, denote sources - * to be excluded from delivery. + * Check for a multicast source + * filter entry on this socket for + * this group. MCAST_EXCLUDE is the + * default behaviour. It means + * default accept; entries, if + * present, denote sources to be + * excluded from delivery. */ ims = imo_match_source(imo, idx, (struct sockaddr *)&udp_in); mode = imo->imo_mfilters[idx].imf_fmode; if ((ims != NULL && - mode == MCAST_EXCLUDE) || + mode == MCAST_EXCLUDE) || (ims == NULL && - mode == MCAST_INCLUDE)) { + mode == MCAST_INCLUDE)) { #ifdef DIAGNOSTIC if (bootverbose) { printf("%s: blocked by" @@ -488,41 +500,72 @@ struct mbuf *n; n = m_copy(m, 0, M_COPYALL); - if (n != NULL) - udp_append(last, ip, n, iphlen + - sizeof(struct udphdr), &udp_in); - INP_RUNLOCK(last); + if (last->inp_ppcb == NULL) { + if (n != NULL) + udp_append(last, ip, n, iphlen + + sizeof(struct udphdr), &udp_in); + INP_RUNLOCK(last); + } else { + /* + * Engage the tunneling protocol we + * will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't + * break! + */ + udp_tunnel_func_t tunnel_func; + + INP_RUNLOCK(last); + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, iphlen); + } } last = inp; /* - * Don't look for additional matches if this one does - * not have either the SO_REUSEPORT or SO_REUSEADDR - * socket options set. This heuristic avoids - * searching through all pcbs in the common case of a - * non-shared port. It assumes that an application - * will never clear these options after setting them. + * Don't look for additional matches if this one + * does not have either the SO_REUSEPORT or + * SO_REUSEADDR socket options set. This heuristic + * avoids searching through all pcbs in the common + * case of a non-shared port. It assumes that an + * application will never clear these options after + * setting them. */ if ((last->inp_socket->so_options & - (SO_REUSEPORT|SO_REUSEADDR)) == 0) + (SO_REUSEPORT | SO_REUSEADDR)) == 0) break; } if (last == NULL) { /* - * No matching pcb found; discard datagram. (No need - * to send an ICMP Port Unreachable for a broadcast - * or multicast datgram.) + * No matching pcb found; discard datagram. (No + * need to send an ICMP Port Unreachable for a + * broadcast or multicast datgram.) */ V_udpstat.udps_noportbcast++; goto badheadlocked; } - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), - &udp_in); - INP_RUNLOCK(last); - INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb == NULL) { + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), + &udp_in); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } else { + /* + * Engage the tunneling protocol we must make sure + * all locks are released when we call the tunneling + * protocol. + */ + udp_tunnel_func_t tunnel_func; + + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, iphlen); + } return; } - /* * Locate pcb for datagram. */ @@ -530,7 +573,7 @@ ip->ip_dst, uh->uh_dport, 1, ifp); if (inp == NULL) { if (udp_log_in_vain) { - char buf[4*sizeof "123"]; + char buf[4 * sizeof "123"]; strcpy(buf, inet_ntoa(ip->ip_dst)); log(LOG_INFO, @@ -553,7 +596,6 @@ INP_INFO_RUNLOCK(&V_udbinfo); return; } - /* * Check the minimum TTL for socket. */ @@ -563,6 +605,18 @@ INP_RUNLOCK(inp); goto badunlocked; } + if (inp->inp_ppcb) { + /* + * Engage the tunneling protocol we must make sure all locks + * are released when we call the tunneling protocol. + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) inp->inp_ppcb; + INP_RUNLOCK(inp); + tunnel_func(m, iphlen); + return; + } udp_append(inp, ip, m, iphlen + sizeof(struct udphdr), &udp_in); INP_RUNLOCK(inp); return; @@ -586,8 +640,8 @@ /* * While udp_ctlinput() always calls udp_notify() with a read lock * when invoking it directly, in_pcbnotifyall() currently uses write - * locks due to sharing code with TCP. For now, accept either a read - * or a write lock, but a read lock is sufficient. + * locks due to sharing code with TCP. For now, accept either a + * read or a write lock, but a read lock is sufficient. */ INP_LOCK_ASSERT(inp); @@ -618,7 +672,7 @@ /* * Hostdead is ugly because it goes linearly through all PCBs. - * + * * XXX: We never get this from ICMP, otherwise it makes an excellent * DoS attack on machines with many connections. */ @@ -660,10 +714,9 @@ if (req->oldptr == 0) { n = V_udbinfo.ipi_count; req->oldidx = 2 * (sizeof xig) - + (n + n/8) * sizeof(struct xinpcb); + + (n + n / 8) * sizeof(struct xinpcb); return (0); } - if (req->newptr != 0) return (EPERM); @@ -676,7 +729,7 @@ INP_INFO_RUNLOCK(&V_udbinfo); error = sysctl_wire_old_buffer(req, 2 * (sizeof xig) - + n * sizeof(struct xinpcb)); + + n * sizeof(struct xinpcb)); if (error != 0) return (error); @@ -694,7 +747,7 @@ INP_INFO_RLOCK(&V_udbinfo); for (inp = LIST_FIRST(V_udbinfo.ipi_listhead), i = 0; inp && i < n; - inp = LIST_NEXT(inp, inp_list)) { + inp = LIST_NEXT(inp, inp_list)) { INP_RLOCK(inp); if (inp->inp_gencnt <= gencnt && cr_canseeinpcb(req->td->td_ucred, inp) == 0) @@ -710,6 +763,7 @@ INP_RLOCK(inp); if (inp->inp_gencnt <= gencnt) { struct xinpcb xi; + bzero(&xi, sizeof(xi)); xi.xi_len = sizeof xi; /* XXX should avoid extra copy */ @@ -725,9 +779,9 @@ if (!error) { /* * Give the user an updated idea of our state. If the - * generation differs from what we told her before, she knows - * that something happened while we were processing this - * request, and it might be necessary to retry. + * generation differs from what we told her before, she + * knows that something happened while we were processing + * this request, and it might be necessary to retry. */ INP_INFO_RLOCK(&V_udbinfo); xig.xig_gen = V_udbinfo.ipi_gencnt; @@ -760,7 +814,7 @@ return (error); INP_INFO_RLOCK(&V_udbinfo); inp = in_pcblookup_hash(&V_udbinfo, addrs[1].sin_addr, addrs[1].sin_port, - addrs[0].sin_addr, addrs[0].sin_port, 1, NULL); + addrs[0].sin_addr, addrs[0].sin_port, 1, NULL); if (inp != NULL) { INP_RLOCK(inp); INP_INFO_RUNLOCK(&V_udbinfo); @@ -781,7 +835,7 @@ } SYSCTL_PROC(_net_inet_udp, OID_AUTO, getcred, - CTLTYPE_OPAQUE|CTLFLAG_RW|CTLFLAG_PRISON, 0, 0, + CTLTYPE_OPAQUE | CTLFLAG_RW | CTLFLAG_PRISON, 0, 0, udp_getcred, "S,xucred", "Get the xucred of a UDP connection"); static int @@ -811,7 +865,6 @@ m_freem(m); return (EMSGSIZE); } - src.sin_family = 0; if (control != NULL) { /* @@ -863,20 +916,19 @@ m_freem(m); return (error); } - /* - * Depending on whether or not the application has bound or connected - * the socket, we may have to do varying levels of work. The optimal - * case is for a connected UDP socket, as a global lock isn't - * required at all. - * - * In order to decide which we need, we require stability of the - * inpcb binding, which we ensure by acquiring a read lock on the - * inpcb. This doesn't strictly follow the lock order, so we play - * the trylock and retry game; note that we may end up with more + * Depending on whether or not the application has bound or + * connected the socket, we may have to do varying levels of work. + * The optimal case is for a connected UDP socket, as a global lock + * isn't required at all. + * + * In order to decide which we need, we require stability of the inpcb + * binding, which we ensure by acquiring a read lock on the inpcb. + * This doesn't strictly follow the lock order, so we play the + * trylock and retry game; note that we may end up with more * conservative locks than required the second time around, so later - * assertions have to accept that. Further analysis of the number of - * misses under contention is required. + * assertions have to accept that. Further analysis of the number + * of misses under contention is required. */ sin = (struct sockaddr_in *)addr; INP_RLOCK(inp); @@ -887,10 +939,10 @@ INP_WLOCK(inp); unlock_udbinfo = 2; } else if ((sin != NULL && ( - (sin->sin_addr.s_addr == INADDR_ANY) || - (sin->sin_addr.s_addr == INADDR_BROADCAST) || - (inp->inp_laddr.s_addr == INADDR_ANY) || - (inp->inp_lport == 0))) || + (sin->sin_addr.s_addr == INADDR_ANY) || + (sin->sin_addr.s_addr == INADDR_BROADCAST) || + (inp->inp_laddr.s_addr == INADDR_ANY) || + (inp->inp_lport == 0))) || (src.sin_family == AF_INET)) { if (!INP_INFO_TRY_RLOCK(&V_udbinfo)) { INP_RUNLOCK(inp); @@ -912,7 +964,7 @@ INP_INFO_LOCK_ASSERT(&V_udbinfo); if ((lport == 0) || (laddr.s_addr == INADDR_ANY && - src.sin_addr.s_addr == INADDR_ANY)) { + src.sin_addr.s_addr == INADDR_ANY)) { error = EINVAL; goto release; } @@ -921,11 +973,10 @@ if (error) goto release; } - /* - * If a UDP socket has been connected, then a local address/port will - * have been selected and bound. - * + * If a UDP socket has been connected, then a local address/port + * will have been selected and bound. + * * If a UDP socket has not been connected to, then an explicit * destination address must be used, in which case a local * address/port may not have been selected and bound. @@ -936,7 +987,6 @@ error = EISCONN; goto release; } - /* * Jail may rewrite the destination address, so let it do * that before we use it. @@ -945,17 +995,17 @@ error = EINVAL; goto release; } - /* - * If a local address or port hasn't yet been selected, or if - * the destination address needs to be rewritten due to using - * a special INADDR_ constant, invoke in_pcbconnect_setup() - * to do the heavy lifting. Once a port is selected, we - * commit the binding back to the socket; we also commit the - * binding of the address if in jail. - * - * If we already have a valid binding and we're not - * requesting a destination address rewrite, use a fast path. + * If a local address or port hasn't yet been selected, or + * if the destination address needs to be rewritten due to + * using a special INADDR_ constant, invoke + * in_pcbconnect_setup() to do the heavy lifting. Once a + * port is selected, we commit the binding back to the + * socket; we also commit the binding of the address if in + * jail. + * + * If we already have a valid binding and we're not requesting + * a destination address rewrite, use a fast path. */ if (inp->inp_laddr.s_addr == INADDR_ANY || inp->inp_lport == 0 || @@ -1007,8 +1057,8 @@ /* * Calculate data length and get a mbuf for UDP, IP, and possible - * link-layer headers. Immediate slide the data pointer back forward - * since we won't use that space at this layer. + * link-layer headers. Immediate slide the data pointer back + * forward since we won't use that space at this layer. */ M_PREPEND(m, sizeof(struct udpiphdr) + max_linkhdr, M_DONTWAIT); if (m == NULL) { @@ -1020,8 +1070,8 @@ m->m_pkthdr.len -= max_linkhdr; /* - * Fill in mbuf with extended UDP header and addresses and length put - * into network format. + * Fill in mbuf with extended UDP header and addresses and length + * put into network format. */ ui = mtod(m, struct udpiphdr *); bzero(ui->ui_x1, sizeof(ui->ui_x1)); /* XXX still needed? */ @@ -1041,7 +1091,6 @@ ip = (struct ip *)&ui->ui_i; ip->ip_off |= IP_DF; } - ipflags = 0; if (inp->inp_socket->so_options & SO_DONTROUTE) ipflags |= IP_ROUTETOIF; @@ -1066,7 +1115,7 @@ m->m_pkthdr.csum_data = offsetof(struct udphdr, uh_sum); } else ui->ui_sum = 0; - ((struct ip *)ui)->ip_len = sizeof (struct udpiphdr) + len; + ((struct ip *)ui)->ip_len = sizeof(struct udpiphdr) + len; ((struct ip *)ui)->ip_ttl = inp->inp_ip_ttl; /* XXX */ ((struct ip *)ui)->ip_tos = inp->inp_ip_tos; /* XXX */ V_udpstat.udps_opackets++; @@ -1133,15 +1182,42 @@ INP_INFO_WUNLOCK(&V_udbinfo); return (error); } - inp = (struct inpcb *)so->so_pcb; INP_INFO_WUNLOCK(&V_udbinfo); inp->inp_vflag |= INP_IPV4; inp->inp_ip_ttl = V_ip_defttl; + /* + * UDP does not have a per-protocol pcb (inp->inp_ppcb). We use this + * pointer for kernel tunneling pointer. If we ever need to have a + * protocol block we will need to move this function pointer there. + * Null in this pointer means "do the normal thing". + */ + inp->inp_ppcb = NULL; INP_WUNLOCK(inp); return (0); } +int +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t f) +{ + struct inpcb *inp; + + inp = (struct inpcb *)so->so_pcb; + + if (so->so_type != SOCK_DGRAM) { + /* Not UDP socket... sorry */ + return (ENOTSUP); + } + if (inp == NULL) { + /* NULL INP? */ + return (EINVAL); + } + INP_WLOCK(inp); + inp->inp_ppcb = f; + INP_WUNLOCK(inp); + return (0); +} + static int udp_bind(struct socket *so, struct sockaddr *nam, struct thread *td) { @@ -1241,11 +1317,10 @@ INP_INFO_WUNLOCK(&V_udbinfo); return (ENOTCONN); } - in_pcbdisconnect(inp); inp->inp_laddr.s_addr = INADDR_ANY; SOCK_LOCK(so); - so->so_state &= ~SS_ISCONNECTED; /* XXX */ + so->so_state &= ~SS_ISCONNECTED; /* XXX */ SOCK_UNLOCK(so); INP_WUNLOCK(inp); INP_INFO_WUNLOCK(&V_udbinfo); @@ -1277,19 +1352,19 @@ } struct pr_usrreqs udp_usrreqs = { - .pru_abort = udp_abort, - .pru_attach = udp_attach, - .pru_bind = udp_bind, - .pru_connect = udp_connect, - .pru_control = in_control, - .pru_detach = udp_detach, - .pru_disconnect = udp_disconnect, - .pru_peeraddr = in_getpeeraddr, - .pru_send = udp_send, - .pru_soreceive = soreceive_dgram, - .pru_sosend = sosend_dgram, - .pru_shutdown = udp_shutdown, - .pru_sockaddr = in_getsockaddr, - .pru_sosetlabel = in_pcbsosetlabel, - .pru_close = udp_close, + .pru_abort = udp_abort, + .pru_attach = udp_attach, + .pru_bind = udp_bind, + .pru_connect = udp_connect, + .pru_control = in_control, + .pru_detach = udp_detach, + .pru_disconnect = udp_disconnect, + .pru_peeraddr = in_getpeeraddr, + .pru_send = udp_send, + .pru_soreceive = soreceive_dgram, + .pru_sosend = sosend_dgram, + .pru_shutdown = udp_shutdown, + .pru_sockaddr = in_getsockaddr, + .pru_sosetlabel = in_pcbsosetlabel, + .pru_close = udp_close, }; Index: netinet/udp_var.h =================================================================== --- netinet/udp_var.h (revision 185928) +++ netinet/udp_var.h (working copy) @@ -38,9 +38,10 @@ * UDP kernel structures and variables. */ struct udpiphdr { - struct ipovly ui_i; /* overlaid ip structure */ - struct udphdr ui_u; /* udp header */ + struct ipovly ui_i; /* overlaid ip structure */ + struct udphdr ui_u; /* udp header */ }; + #define ui_x1 ui_i.ih_x1 #define ui_pr ui_i.ih_pr #define ui_len ui_i.ih_len @@ -52,23 +53,23 @@ #define ui_sum ui_u.uh_sum struct udpstat { - /* input statistics: */ - u_long udps_ipackets; /* total input packets */ - u_long udps_hdrops; /* packet shorter than header */ - u_long udps_badsum; /* checksum error */ - u_long udps_nosum; /* no checksum */ - u_long udps_badlen; /* data length larger than packet */ - u_long udps_noport; /* no socket on port */ - u_long udps_noportbcast; /* of above, arrived as broadcast */ - u_long udps_fullsock; /* not delivered, input socket full */ - u_long udpps_pcbcachemiss; /* input packets missing pcb cache */ - u_long udpps_pcbhashmiss; /* input packets not for hashed pcb */ - /* output statistics: */ - u_long udps_opackets; /* total output packets */ - u_long udps_fastout; /* output packets on fast path */ + /* input statistics: */ + u_long udps_ipackets; /* total input packets */ + u_long udps_hdrops; /* packet shorter than header */ + u_long udps_badsum; /* checksum error */ + u_long udps_nosum; /* no checksum */ + u_long udps_badlen; /* data length larger than packet */ + u_long udps_noport; /* no socket on port */ + u_long udps_noportbcast;/* of above, arrived as broadcast */ + u_long udps_fullsock; /* not delivered, input socket full */ + u_long udpps_pcbcachemiss; /* input packets missing pcb cache */ + u_long udpps_pcbhashmiss; /* input packets not for hashed pcb */ + /* output statistics: */ + u_long udps_opackets; /* total output packets */ + u_long udps_fastout; /* output packets on fast path */ /* of no socket on port, arrived as multicast */ - u_long udps_noportmcast; - u_long udps_filtermcast; /* blocked by multicast filter */ + u_long udps_noportmcast; + u_long udps_filtermcast;/* blocked by multicast filter */ }; /* @@ -93,20 +94,25 @@ #ifdef _KERNEL SYSCTL_DECL(_net_inet_udp); -extern struct pr_usrreqs udp_usrreqs; -extern struct inpcbhead udb; -extern struct inpcbinfo udbinfo; -extern u_long udp_sendspace; -extern u_long udp_recvspace; -extern struct udpstat udpstat; -extern int udp_blackhole; -extern int udp_log_in_vain; +extern struct pr_usrreqs udp_usrreqs; +extern struct inpcbhead udb; +extern struct inpcbinfo udbinfo; +extern u_long udp_sendspace; +extern u_long udp_recvspace; +extern struct udpstat udpstat; +extern int udp_blackhole; +extern int udp_log_in_vain; -void udp_ctlinput(int, struct sockaddr *, void *); -void udp_init(void); -void udp_input(struct mbuf *, int); -struct inpcb *udp_notify(struct inpcb *inp, int errno); -int udp_shutdown(struct socket *so); +void udp_ctlinput(int, struct sockaddr *, void *); +void udp_init(void); +void udp_input(struct mbuf *, int); +struct inpcb *udp_notify(struct inpcb *inp, int errno); +int udp_shutdown(struct socket *so); + + +typedef void (*udp_tunnel_func_t) (struct mbuf *, int off); +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f); + #endif #endif Index: netinet6/udp6_usrreq.c =================================================================== --- netinet6/udp6_usrreq.c (revision 185928) +++ netinet6/udp6_usrreq.c (working copy) @@ -115,7 +115,7 @@ #ifdef IPSEC #include #include -#endif /* IPSEC */ +#endif /* IPSEC */ #include @@ -124,8 +124,8 @@ * Per RFC 768, August, 1980. */ -extern struct protosw inetsw[]; -static void udp6_detach(struct socket *so); +extern struct protosw inetsw[]; +static void udp6_detach(struct socket *so); static void udp6_append(struct inpcb *inp, struct mbuf *n, int off, @@ -145,7 +145,7 @@ V_ipsec6stat.in_polvio++; return; } -#endif /* IPSEC */ +#endif /* IPSEC */ #ifdef MAC if (mac_inpcb_check_deliver(inp, n) != 0) { m_freem(n); @@ -186,12 +186,11 @@ ip6 = mtod(m, struct ip6_hdr *); - if (faithprefix_p != NULL && (*faithprefix_p)(&ip6->ip6_dst)) { + if (faithprefix_p != NULL && (*faithprefix_p) (&ip6->ip6_dst)) { /* XXX send icmp6 host/port unreach? */ m_freem(m); return (IPPROTO_DONE); } - #ifndef PULLDOWN_TEST IP6_EXTHDR_CHECK(m, off, sizeof(struct udphdr), IPPROTO_DONE); ip6 = mtod(m, struct ip6_hdr *); @@ -217,7 +216,6 @@ V_udpstat.udps_badlen++; goto badunlocked; } - /* * Checksum extended UDP header and data. */ @@ -229,7 +227,6 @@ V_udpstat.udps_badsum++; goto badunlocked; } - /* * Construct sockaddr format source address. */ @@ -243,8 +240,8 @@ /* * In the event that laddr should be set to the link-local * address (this happens in RIPng), the multicast address - * specified in the received packet will not match laddr. To - * handle this situation, matching is relaxed if the + * specified in the received packet will not match laddr. + * To handle this situation, matching is relaxed if the * receiving interface is the same as one specified in the * socket and if the destination multicast address matches * one of the multicast groups specified in the socket. @@ -262,54 +259,72 @@ if (inp->in6p_lport != uh->uh_dport) continue; /* - * XXX: Do not check source port of incoming datagram - * unless inp_connect() has been called to bind the - * fport part of the 4-tuple; the source could be - * trying to talk to us with an ephemeral port. + * XXX: Do not check source port of incoming + * datagram unless inp_connect() has been called to + * bind the fport part of the 4-tuple; the source + * could be trying to talk to us with an ephemeral + * port. */ if (inp->inp_fport != 0 && inp->inp_fport != uh->uh_sport) continue; if (!IN6_IS_ADDR_UNSPECIFIED(&inp->in6p_laddr)) { if (!IN6_ARE_ADDR_EQUAL(&inp->in6p_laddr, - &ip6->ip6_dst)) + &ip6->ip6_dst)) continue; } if (!IN6_IS_ADDR_UNSPECIFIED(&inp->in6p_faddr)) { if (!IN6_ARE_ADDR_EQUAL(&inp->in6p_faddr, - &ip6->ip6_src) || + &ip6->ip6_src) || inp->in6p_fport != uh->uh_sport) continue; } - if (last != NULL) { struct mbuf *n; if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { - INP_RLOCK(last); - udp6_append(last, n, off, &fromsa); - INP_RUNLOCK(last); + if (last->inp_ppcb) { + /* + * Engage the tunneling + * protocol we will have to + * leave the info_lock up, + * since we are hunting + * through multiple UDP + * inp's hope we don't break + * :-( + */ + udp_tunnel_func tunnel_func; + + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, off); + } else { + INP_RLOCK(last); + udp6_append(last, n, off, &fromsa); + INP_RUNLOCK(last); + } } } last = inp; /* - * Don't look for additional matches if this one does - * not have either the SO_REUSEPORT or SO_REUSEADDR - * socket options set. This heuristic avoids - * searching through all pcbs in the common case of a - * non-shared port. It assumes that an application - * will never clear these options after setting them. + * Don't look for additional matches if this one + * does not have either the SO_REUSEPORT or + * SO_REUSEADDR socket options set. This heuristic + * avoids searching through all pcbs in the common + * case of a non-shared port. It assumes that an + * application will never clear these options after + * setting them. */ if ((last->inp_socket->so_options & - (SO_REUSEPORT|SO_REUSEADDR)) == 0) + (SO_REUSEPORT | SO_REUSEADDR)) == 0) break; } if (last == NULL) { /* - * No matching pcb found; discard datagram. (No need - * to send an ICMP Port Unreachable for a broadcast - * or multicast datgram.) + * No matching pcb found; discard datagram. (No + * need to send an ICMP Port Unreachable for a + * broadcast or multicast datgram.) */ V_udpstat.udps_noport++; V_udpstat.udps_noportmcast++; @@ -317,6 +332,19 @@ } INP_RLOCK(last); INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb) { + /* + * Engage the tunneling protocol we must make sure + * all locks are released when we call the tunneling + * protocol. + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) inp->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, off); + return (IPPROTO_DONE); + } udp6_append(last, m, off, &fromsa); INP_RUNLOCK(last); return (IPPROTO_DONE); @@ -354,6 +382,18 @@ } INP_RLOCK(inp); INP_INFO_RUNLOCK(&V_udbinfo); + if (inp->inp_ppcb) { + /* + * Engage the tunneling protocol we must make sure all locks + * are released when we call the tunneling protocol. + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) inp->inp_ppcb; + INP_RUNLOCK(inp); + tunnel_func(m, off); + return (IPPROTO_DONE); + } udp6_append(inp, m, off, &fromsa); INP_RUNLOCK(inp); return (IPPROTO_DONE); @@ -377,11 +417,11 @@ struct ip6ctlparam *ip6cp = NULL; const struct sockaddr_in6 *sa6_src = NULL; void *cmdarg; - struct inpcb *(*notify)(struct inpcb *, int) = udp_notify; + struct inpcb *(*notify) (struct inpcb *, int)= udp_notify; struct udp_portonly { u_int16_t uh_sport; u_int16_t uh_dport; - } *uhp; + } *uhp; if (sa->sa_family != AF_INET6 || sa->sa_len != sizeof(struct sockaddr_in6)) @@ -413,8 +453,8 @@ if (ip6) { /* - * XXX: We assume that when IPV6 is non NULL, - * M and OFF are valid. + * XXX: We assume that when IPV6 is non NULL, M and OFF are + * valid. */ /* Check if we can safely examine src and dst ports. */ @@ -424,11 +464,11 @@ bzero(&uh, sizeof(uh)); m_copydata(m, off, sizeof(*uhp), (caddr_t)&uh); - (void) in6_pcbnotify(&V_udbinfo, sa, uh.uh_dport, + (void)in6_pcbnotify(&V_udbinfo, sa, uh.uh_dport, (struct sockaddr *)ip6cp->ip6c_src, uh.uh_sport, cmd, cmdarg, notify); } else - (void) in6_pcbnotify(&V_udbinfo, sa, 0, + (void)in6_pcbnotify(&V_udbinfo, sa, 0, (const struct sockaddr *)sa6_src, 0, cmd, cmdarg, notify); } @@ -481,7 +521,7 @@ return (error); } -SYSCTL_PROC(_net_inet6_udp6, OID_AUTO, getcred, CTLTYPE_OPAQUE|CTLFLAG_RW, 0, +SYSCTL_PROC(_net_inet6_udp6, OID_AUTO, getcred, CTLTYPE_OPAQUE | CTLFLAG_RW, 0, 0, udp6_getcred, "S,xucred", "Get the xucred of a UDP6 connection"); static int @@ -520,15 +560,15 @@ * default zone IDs should be enabled. Unfortunately, some * applications do not behave as it should, so we need a * workaround. Even if an appropriate ID is not determined, - * we'll see if we can determine the outgoing interface. If we - * can, determine the zone ID based on the interface below. + * we'll see if we can determine the outgoing interface. If + * we can, determine the zone ID based on the interface + * below. */ if (sin6->sin6_scope_id == 0 && !V_ip6_use_defzone) scope_ambiguous = 1; if ((error = sa6_embedscope(sin6, V_ip6_use_defzone)) != 0) return (error); } - if (control) { if ((error = ip6_setpktopts(control, &opt, inp->in6p_outputopts, td->td_ucred, IPPROTO_UDP)) != 0) @@ -541,37 +581,35 @@ faddr = &sin6->sin6_addr; /* - * IPv4 version of udp_output calls in_pcbconnect in this case, - * which needs splnet and affects performance. - * Since we saw no essential reason for calling in_pcbconnect, - * we get rid of such kind of logic, and call in6_selectsrc - * and in6_pcbsetport in order to fill in the local address - * and the local port. + * IPv4 version of udp_output calls in_pcbconnect in this + * case, which needs splnet and affects performance. Since + * we saw no essential reason for calling in_pcbconnect, we + * get rid of such kind of logic, and call in6_selectsrc and + * in6_pcbsetport in order to fill in the local address and + * the local port. */ if (sin6->sin6_port == 0) { error = EADDRNOTAVAIL; goto release; } - if (!IN6_IS_ADDR_UNSPECIFIED(&inp->in6p_faddr)) { /* how about ::ffff:0.0.0.0 case? */ error = EISCONN; goto release; } + fport = sin6->sin6_port; /* allow 0 port */ - fport = sin6->sin6_port; /* allow 0 port */ - if (IN6_IS_ADDR_V4MAPPED(faddr)) { if ((inp->in6p_flags & IN6P_IPV6_V6ONLY)) { /* - * I believe we should explicitly discard the - * packet when mapped addresses are disabled, - * rather than send the packet as an IPv6 one. - * If we chose the latter approach, the packet - * might be sent out on the wire based on the - * default route, the situation which we'd - * probably want to avoid. - * (20010421 jinmei@kame.net) + * I believe we should explicitly discard + * the packet when mapped addresses are + * disabled, rather than send the packet as + * an IPv6 one. If we chose the latter + * approach, the packet might be sent out on + * the wire based on the default route, the + * situation which we'd probably want to + * avoid. (20010421 jinmei@kame.net) */ error = EINVAL; goto release; @@ -579,18 +617,16 @@ if (!IN6_IS_ADDR_UNSPECIFIED(&inp->in6p_laddr) && !IN6_IS_ADDR_V4MAPPED(&inp->in6p_laddr)) { /* - * when remote addr is an IPv4-mapped address, - * local addr should not be an IPv6 address, - * since you cannot determine how to map IPv6 - * source address to IPv4. + * when remote addr is an IPv4-mapped + * address, local addr should not be an IPv6 + * address, since you cannot determine how + * to map IPv6 source address to IPv4. */ error = EINVAL; goto release; } - af = AF_INET; } - if (!IN6_IS_ADDR_V4MAPPED(faddr)) { laddr = in6_selectsrc(sin6, optp, inp, NULL, td->td_ucred, &oifp, &error); @@ -619,9 +655,9 @@ /* * XXX: this case would happen when the * application sets the V6ONLY flag after - * connecting the foreign address. - * Such applications should be fixed, - * so we bark here. + * connecting the foreign address. Such + * applications should be fixed, so we bark + * here. */ log(LOG_INFO, "udp6_output: IPV6_V6ONLY " "option was set for a connected socket\n"); @@ -639,20 +675,19 @@ hlen = sizeof(struct ip); /* - * Calculate data length and get a mbuf - * for UDP and IP6 headers. + * Calculate data length and get a mbuf for UDP and IP6 headers. */ M_PREPEND(m, hlen + sizeof(struct udphdr), M_DONTWAIT); if (m == 0) { error = ENOBUFS; goto release; } - /* * Stuff checksum and output datagram. */ - udp6 = (struct udphdr *)(mtod(m, caddr_t) + hlen); - udp6->uh_sport = inp->in6p_lport; /* lport is always set in the PCB */ + udp6 = (struct udphdr *)(mtod(m, caddr_t)+hlen); + udp6->uh_sport = inp->in6p_lport; /* lport is always set in the + * PCB */ udp6->uh_dport = fport; if (plen <= 0xffff) udp6->uh_ulen = htons((u_short)plen); @@ -663,22 +698,21 @@ switch (af) { case AF_INET6: ip6 = mtod(m, struct ip6_hdr *); - ip6->ip6_flow = inp->in6p_flowinfo & IPV6_FLOWINFO_MASK; - ip6->ip6_vfc &= ~IPV6_VERSION_MASK; - ip6->ip6_vfc |= IPV6_VERSION; + ip6->ip6_flow = inp->in6p_flowinfo & IPV6_FLOWINFO_MASK; + ip6->ip6_vfc &= ~IPV6_VERSION_MASK; + ip6->ip6_vfc |= IPV6_VERSION; #if 0 /* ip6_plen will be filled in ip6_output. */ - ip6->ip6_plen = htons((u_short)plen); + ip6->ip6_plen = htons((u_short)plen); #endif - ip6->ip6_nxt = IPPROTO_UDP; - ip6->ip6_hlim = in6_selecthlim(inp, NULL); - ip6->ip6_src = *laddr; - ip6->ip6_dst = *faddr; + ip6->ip6_nxt = IPPROTO_UDP; + ip6->ip6_hlim = in6_selecthlim(inp, NULL); + ip6->ip6_src = *laddr; + ip6->ip6_dst = *faddr; if ((udp6->uh_sum = in6_cksum(m, IPPROTO_UDP, - sizeof(struct ip6_hdr), plen)) == 0) { + sizeof(struct ip6_hdr), plen)) == 0) { udp6->uh_sum = 0xffff; } - flags = 0; V_udpstat.udps_opackets++; @@ -716,7 +750,7 @@ struct pr_usrreqs *pru; pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs; - (*pru->pru_abort)(so); + (*pru->pru_abort) (so); return; } #endif @@ -761,10 +795,9 @@ inp->in6p_hops = -1; /* use kernel default */ inp->in6p_cksum = -1; /* just to be sure */ /* - * XXX: ugly!! - * IPv4 TTL initialization is necessary for an IPv6 socket as well, - * because the socket may be bound to an IPv6 wildcard address, - * which may match an IPv4-mapped IPv6 address. + * XXX: ugly!! IPv4 TTL initialization is necessary for an IPv6 + * socket as well, because the socket may be bound to an IPv6 + * wildcard address, which may match an IPv4-mapped IPv6 address. */ inp->inp_ip_ttl = V_ip_defttl; INP_WUNLOCK(inp); @@ -803,7 +836,6 @@ goto out; } } - error = in6_pcbbind(inp, nam, td->td_ucred); out: INP_WUNLOCK(inp); @@ -825,7 +857,7 @@ struct pr_usrreqs *pru; pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs; - (*pru->pru_disconnect)(so); + (*pru->pru_disconnect) (so); return; } #endif @@ -886,6 +918,7 @@ } if (td && jailed(td->td_ucred)) { struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)nam; + if (prison_remote_ip6(td->td_ucred, &sin6->sin6_addr) != 0) { error = EAFNOSUPPORT; goto out; @@ -940,7 +973,7 @@ struct pr_usrreqs *pru; pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs; - error = (*pru->pru_disconnect)(so); + error = (*pru->pru_disconnect) (so); goto out; } #endif @@ -949,11 +982,10 @@ error = ENOTCONN; goto out; } - in6_pcbdisconnect(inp); inp->in6p_laddr = in6addr_any; SOCK_LOCK(so); - so->so_state &= ~SS_ISCONNECTED; /* XXX */ + so->so_state &= ~SS_ISCONNECTED; /* XXX */ SOCK_UNLOCK(so); out: INP_WUNLOCK(inp); @@ -984,7 +1016,6 @@ goto bad; } } - #ifdef INET if ((inp->inp_flags & IN6P_IPV6_V6ONLY) == 0) { int hasv4addr; @@ -1005,18 +1036,17 @@ /* * When remote addr is IPv4-mapped address, * local addr should not be an IPv6 address; - * since you cannot determine how to map IPv6 - * source address to IPv4. + * since you cannot determine how to map + * IPv6 source address to IPv4. */ error = EINVAL; goto out; } - /* * XXXRW: We release UDP-layer locks before calling * udp_send() in order to avoid recursion. However, - * this does mean there is a short window where inp's - * fields are unstable. Could this lead to a + * this does mean there is a short window where + * inp's fields are unstable. Could this lead to a * potential race in which the factors causing us to * select the UDPv4 output routine are invalidated? */ @@ -1026,7 +1056,7 @@ in6_sin6_2_sin_in_sock(addr); pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs; /* addr will just be freed in sendit(). */ - return ((*pru->pru_send)(so, flags, m, addr, control, + return ((*pru->pru_send) (so, flags, m, addr, control, td)); } } @@ -1048,19 +1078,19 @@ } struct pr_usrreqs udp6_usrreqs = { - .pru_abort = udp6_abort, - .pru_attach = udp6_attach, - .pru_bind = udp6_bind, - .pru_connect = udp6_connect, - .pru_control = in6_control, - .pru_detach = udp6_detach, - .pru_disconnect = udp6_disconnect, - .pru_peeraddr = in6_mapped_peeraddr, - .pru_send = udp6_send, - .pru_shutdown = udp_shutdown, - .pru_sockaddr = in6_mapped_sockaddr, - .pru_soreceive = soreceive_dgram, - .pru_sosend = sosend_dgram, - .pru_sosetlabel = in_pcbsosetlabel, - .pru_close = udp6_close + .pru_abort = udp6_abort, + .pru_attach = udp6_attach, + .pru_bind = udp6_bind, + .pru_connect = udp6_connect, + .pru_control = in6_control, + .pru_detach = udp6_detach, + .pru_disconnect = udp6_disconnect, + .pru_peeraddr = in6_mapped_peeraddr, + .pru_send = udp6_send, + .pru_shutdown = udp_shutdown, + .pru_sockaddr = in6_mapped_sockaddr, + .pru_soreceive = soreceive_dgram, + .pru_sosend = sosend_dgram, + .pru_sosetlabel = in_pcbsosetlabel, + .pru_close = udp6_close }; --Apple-Mail-90--449110523 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Dec 12, 2008, at 11:47 AM, Bruce Evans wrote: > On Fri, 12 Dec 2008, Randall Stewart wrote: > >> Here is an updated patch it: >> >> 1) Fixes style9 issues (I hope.. I went back to vi and tried >> tabs :-0.. sigh one of >> these doys I will figure out why my .emacs settings just never cut >> it :-() > > Fraid not. > > % Index: netinet/udp_usrreq.c > % =================================================================== > % --- netinet/udp_usrreq.c (revision 185928) > % +++ netinet/udp_usrreq.c (working copy) > % @@ -488,10 +488,25 @@ > % struct mbuf *n; > % % n = m_copy(m, 0, M_COPYALL); > % - if (n != NULL) > % - udp_append(last, ip, n, iphlen + > % - sizeof(struct udphdr), &udp_in); > % - INP_RUNLOCK(last); > % + > > Extra blank line. > > % + if (last->inp_ppcb == NULL) { > % + if (n != NULL) > % + udp_append(last, ip, n, iphlen + > % + sizeof(struct udphdr), &udp_in); > > Line too long. > > % + INP_RUNLOCK(last); > % + } else { > % + /* Engage the tunneling protocol > > "/*" not on a line by itself. > > % + * we will have to leave the info_lock > % + * up, since we are hunting through % + * multiple UDP > inp's hope we don't break :-( > > Line too long. Defeats reasonable indentation of the rest of the > comment. > > Missing punctuation after ":-(". > > % + */ > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > % + > % + INP_RUNLOCK(last); > % + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; > > Line too long. > > Typedef names involving functions normally use `func_t', not > `function_t'. > This is useful for reducing verboseness and resulting long lines but > wouldn't > fix the long line in the above, since everything in it is too verbose > (in the middle there is an ugly cast whose only effect can be to > avoid a > warning ...). > > % @@ -516,10 +531,25 @@ > % V_udpstat.udps_noportbcast++; > % goto badheadlocked; > % } > % - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), > % - &udp_in); > % - INP_RUNLOCK(last); > % - INP_INFO_RUNLOCK(&V_udbinfo); > % + if (last->inp_ppcb == NULL) { > % + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), > % + &udp_in); > % + INP_RUNLOCK(last); > % + INP_INFO_RUNLOCK(&V_udbinfo); > % + } else { > % + /* Engage the tunneling protocol > > "/*" not on a line by itself. No comment on further instances of this > > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > Long lines are ones longer than 80 characters. Splitting at 48 > characters > as in the above is not normal. > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > % @@ -563,6 +593,18 @@ > % INP_RUNLOCK(inp); > % goto badunlocked; > % } > % + if (inp->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > More formatting for 48-column terminals. > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > Missing blank line after declarations. > > % ... > % +int > % +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t > f) > % +{ > % + struct inpcb *inp; > % + inp = (struct inpcb *)so->so_pcb; > > Initialization in declaration. Not too bad here, but you don't do > it for > similar tunnel function pointer conversions. > > % + > % + if (so->so_type != SOCK_DGRAM) { > % + /* Not UDP socket... sorry */ > > Missing punctuation. > > % Index: netinet/udp_var.h > % =================================================================== > % --- netinet/udp_var.h (revision 185928) > % +++ netinet/udp_var.h (working copy) > % @@ -107,6 +107,10 @@ > % void udp_input(struct mbuf *, int); > % struct inpcb *udp_notify(struct inpcb *inp, int errno); > % int udp_shutdown(struct socket *so); > % + > % + > % +typedef void(*udp_tunnel_function_t)(struct mbuf *, int off); > % +int udp_set_kernel_tunneling(struct socket *so, > udp_tunnel_function_t f); > > I noticed this first in the initial patch. It has a style bug > density of > about 5 per line !-(: > > - 2 extra blank lines > - typedef in the middle of (non-pointer non-typedef) prototypes > - unsorted prototypes (at least the old 3 visible on the above are > sorted) > - new prototypes not indented normally though visible old ones all are > - some parameters have names, some not. > - style(9) says to always have names in the kernel, but this rule > is usually > violated > - the first of the 3 visible old prototypes violates this rule > - the first of the new prototypes violates this rule for the first > of its > 2 parameters only > > % #endif > % % #endif > % Index: netinet6/udp6_usrreq.c > % =================================================================== > % --- netinet6/udp6_usrreq.c (revision 185928) > % +++ netinet6/udp6_usrreq.c (working copy) > % @@ -286,9 +286,21 @@ > % struct mbuf *n; > % % if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { > % - INP_RLOCK(last); > % - udp6_append(last, n, off, &fromsa); > % - INP_RUNLOCK(last); > % + if (last->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we will have to leave the info_lock > % + * up, since we are hunting through % + * multiple > UDP inp's hope we don't break :-( > % + */ > > Lines too long -- now formatting for 94-column terminals instead of > 48-column ones using cut&pasted&indent. > > Missing punctuation (cut&paste). > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > Line too long. > > Missing blank line after declarations. > > % + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; > > Line too long. > > % + INP_RUNLOCK(last); > % + tunnel_func(m, off); > % + } else { > % + INP_RLOCK(last); > % + udp6_append(last, n, off, &fromsa); > > Line too long. > > % @@ -317,6 +329,19 @@ > % } > % INP_RLOCK(last); > % INP_INFO_RUNLOCK(&V_udbinfo); > % + if (last->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > Now formatting for 56-column terminals. > > % @@ -354,6 +379,18 @@ > % } > % INP_RLOCK(inp); > % INP_INFO_RUNLOCK(&V_udbinfo); > % + if (inp->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > Back to formatting for 48-column terminals. > > There are 6 near-copies of this comment. > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > Missing blank line after declaration. > > % + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; > % + INP_RUNLOCK(inp); > % + tunnel_func(m, off); > > Do you have to hold the lock to access inp->inp_ppcb? Otherwise you > can > avoid all the nested declarations and just use the pointer once. If > the > lock is needed, then what happens if the pointer changes after it is > accessed? > > % + return (IPPROTO_DONE); > % + } > % udp6_append(inp, m, off, &fromsa); > % INP_RUNLOCK(inp); > % return (IPPROTO_DONE); > > Bruce > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) --Apple-Mail-90--449110523-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 20:42:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFDB1106564A for ; Fri, 12 Dec 2008 20:42:03 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id C1BD88FC14 for ; Fri, 12 Dec 2008 20:42:02 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [192.168.32.61]) by alf.aws-net.org.ua (8.14.3/8.14.3) with ESMTP id mBCKg0Bp094277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 22:42:00 +0200 (EET) (envelope-from artem@aws-net.org.ua) Date: Fri, 12 Dec 2008 22:41:55 +0200 (EET) From: Artyom Viklenko To: VANHULLEBUS Yvan In-Reply-To: <20081212175500.GA2573@zeninc.net> Message-ID: References: <20081211122828.CF3958FC16@mx1.freebsd.org> <20081211123958.GA5332@zeninc.net> <200812121845.20262.artem@aws-net.org.ua> <20081212175500.GA2573@zeninc.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (alf.aws-net.org.ua [192.168.32.61]); Fri, 12 Dec 2008 22:42:00 +0200 (EET) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on alf.aws-net.org.ua X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: NAT-T + ipsec integration 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, 12 Dec 2008 20:42:03 -0000 On Fri, 12 Dec 2008, VANHULLEBUS Yvan wrote: > On Fri, Dec 12, 2008 at 06:45:20PM +0200, Artyom Viklenko wrote: >> On Thursday 11 December 2008 14:39:58 VANHULLEBUS Yvan wrote: > [....] >>> Actually, you can apply a patch to src/sys and recompile your kernel >>> with IPSEC_NAT_T options. >>> Patches are available here: >>> http://people.freebsd.org/~vanhu/NAT-T/ >> >> And what about patches for 6.4-RELEASE? > > I just not tested on 6.4 (almost all my devices moved to 7.x, and the > remaining ones will stay in 6.3 for various reasons), but 6.3 patch > should work on 6.4 if it compiles cleanly (I did NOT check every > single kernel change between 6.3 and 6.4). > > If people can test it and see some compile/runtime problems, please > report them, I'll try to fix them. Just applied the patch to 6.4-RELEASE. Kernel was compiles successfully and ipsec-tools (racoon) also was compiled successufully with NAT-T. Racoon started and reported about NAT-T support. So far so good! Will try to run IPSec tunnel may be in couple of weeks. Thanks a lot! -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 22:43:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69D9D106564A for ; Fri, 12 Dec 2008 22:43:45 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 452858FC14 for ; Fri, 12 Dec 2008 22:43:44 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (61j03ey6j16sbzjd@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id mBCMhifW067351; Fri, 12 Dec 2008 14:43:44 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id mBCMhiOQ067350; Fri, 12 Dec 2008 14:43:44 -0800 (PST) (envelope-from jmg) Date: Fri, 12 Dec 2008 14:43:44 -0800 From: John-Mark Gurney To: Vyacheslav Bocharov Message-ID: <20081212224343.GH34842@funkthat.com> Mail-Followup-To: Vyacheslav Bocharov , freebsd-net@freebsd.org References: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> <20081212181246.GG34842@funkthat.com> <566611296.20081212205648@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <566611296.20081212205648@gmail.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hydrogen.funkthat.com [127.0.0.1]); Fri, 12 Dec 2008 14:43:44 -0800 (PST) Cc: freebsd-net@freebsd.org Subject: Re: strange problem with ifconfig alias 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, 12 Dec 2008 22:43:45 -0000 Vyacheslav Bocharov wrote this message on Fri, Dec 12, 2008 at 20:56 +0200: > >> root@chip# ifconfig em1 alias 195.3.245.xx/30 > >> ifconfig: ioctl (SIOCAIFADDR): File exists > > > If there is already an ip in that range on the interface, you need to use: > > ifconfig em1 alias 195.3.245.xx/32 > There are no other ip on any interfaces in that range > > > Next time include ifconfig -a so we know what addresses and interfaces ^^^^^^^^^^^ > > you have. Makes diagnostics easier. > I have included in mail: > > root@chip# ifconfig |grep 195.3.245. > root@chip# This is not ifconfig -a. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 01:37:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 191C21065673 for ; Sat, 13 Dec 2008 01:37:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id D12CD8FC19 for ; Sat, 13 Dec 2008 01:37:58 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so1634569rvb.1 for ; Fri, 12 Dec 2008 17:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=r8Go3GmpvczzI6GdNPxm+v+xDz9UI7sX/P32LRhwem8=; b=cdyYueZJyN/ChfARpXhL4wNk1KLBmHYJXJU7TgmzJNU/hdiKfIR2GsEowwsy9ExZzr qTH8dX3tPwv6dnRKgnmRYQBoNcJdanu0fG4UmDyo1jCDiPsasmwuJg7KhlcDYxIB/AXo 37MT7BFOzE4cVL3oiTpHZ08a04ZNh1vI+AnuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=d5pxLUx+W48q19TE4qm6bVdBh44xyZV1uDAibNnXW3j0ptGARLA+AbjHRQyZ41/gSO BEeQfEnWVP8IWsJOhop+gDw50B/b7z34YghkDrp/Cm1t0ZDnG/25UkZnoCwz68dD1P1b jb3/Ed8xwaCLRSaxUrZPUrYjUQsptMPyts9TI= Received: by 10.141.175.5 with SMTP id c5mr2214754rvp.243.1229132278485; Fri, 12 Dec 2008 17:37:58 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id g31sm6937252rvb.4.2008.12.12.17.37.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Dec 2008 17:37:56 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBD1boOc051526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Dec 2008 10:37:50 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBD1bo70051525; Sat, 13 Dec 2008 10:37:50 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 13 Dec 2008 10:37:50 +0900 From: Pyun YongHyeon To: Vladimir Ermakov Message-ID: <20081213013749.GB51320@cdnetworks.co.kr> References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> <20081208004802.GB29560@cdnetworks.co.kr> <493CF424.4040206@gmail.com> <20081209043130.GC33723@cdnetworks.co.kr> <493E1872.9010306@gmail.com> <20081212014011.GG46707@cdnetworks.co.kr> <49427F7A.2020103@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49427F7A.2020103@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: vlan support trouble in if_sis driver ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 01:37:59 -0000 On Fri, Dec 12, 2008 at 06:12:58PM +0300, Vladimir Ermakov wrote: > Pyun YongHyeon wrote: > > > > > > > >Thanks. Patch committed to HEAD(r185784). > > > > > > > > > > > MFC? > > > > > > >sis(4) supports two kind of controllers. One was made by SiS and > >the other was manufactured by National Semiconductor. So I think we > >need test report for NatSemi DP83815 case prior to MFC. > > > > > > need a PR? No. Since we're about to release 7.1 it would be even better to see whether the patch also fixes the VLAN issue on DP83815. At least I want to see no regression on DP83815. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 01:56:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22135106564A for ; Sat, 13 Dec 2008 01:56:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id DBD068FC08 for ; Sat, 13 Dec 2008 01:56:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1626258rvf.43 for ; Fri, 12 Dec 2008 17:56:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=kcMsXiRtWkmmP7XbhA/kY/LFM6vAiPbM2513Qt4fB8w=; b=F5I1auMutwCwALX9BF9QobglRSr7TrHMHdbEKB+hH0+mVqheFMqWI+nGklhn2o/A51 uOAPH+BlhKPEniQuqy3YLKd2+fJf5TEr+YQqv71KMTRwRw/BtXfZhl1NVxVeBy2t4MUd Z5swvLaWL1faH3iNxJUhKPHSEqXWNCnad2azU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=g2/nCrlH6Qth6D7TCU8vju2PZVS1mPCDCITJ426vrQLsr7yHIGkkP57dGSwdrY2hRU tJHG5LO6VKN8H/KCDlj9EHVtxyVkA4g/O1HC9RktkzSrEr65wlmsOrgZllmN76TWpi8p 2NiWF4ryPCCYDRUeTNcnNQYLaW1uKfphUra14= Received: by 10.141.151.18 with SMTP id d18mr2234894rvo.134.1229133392456; Fri, 12 Dec 2008 17:56:32 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id g31sm7015746rvb.4.2008.12.12.17.56.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Dec 2008 17:56:31 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBD1uMJ2051595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Dec 2008 10:56:22 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBD1uMNh051594; Sat, 13 Dec 2008 10:56:22 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 13 Dec 2008 10:56:22 +0900 From: Pyun YongHyeon To: Mam Ruoc Message-ID: <20081213015622.GD51320@cdnetworks.co.kr> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> <20081212015842.GH46707@cdnetworks.co.kr> <4941C6BF.4080809@gmail.com> <20081212021549.GJ46707@cdnetworks.co.kr> <49429CEB.60607@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49429CEB.60607@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: vge driver does not work on a VIA EPIA EN12000EG X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 01:56:33 -0000 On Fri, Dec 12, 2008 at 06:18:35PM +0100, Mam Ruoc wrote: > Pyun YongHyeon wrote: > >And rebuild kernel and then reboot. You don't need to reinstall > >FreeBSD. > > Oki, > > I have done that and rebooted, the driver seems to work better now: > > Dec 12 17:47:16 freebsd kernel: vge0: > port 0xf800-0xf8ff mem 0xfdffe000-0xfdffe0ff irq 18 at device 14.0 on pci0 > Dec 12 17:47:16 freebsd kernel: vge0: MSIX count : 0 > Dec 12 17:47:16 freebsd kernel: vge0: MSI count : 0 > Dec 12 17:47:16 freebsd kernel: miibus0: on vge0 > Dec 12 17:47:16 freebsd kernel: vge0: Ethernet address: 00:40:63:e9:9a:1c > Dec 12 17:47:16 freebsd kernel: vge0: [FILTER] > > What is the next step to be able to make this fix go into the FreeBSD > 7.0 tree? > I don't know. :-( As I said I no longer have working vge(4) hardware and it's hard to write/test driver without access to the hardware. The code you've tested contains changes related to MII operation mode and critical register configuration as well as other improvements. The driver still needs special handling in several edge cases and more code to track link state transition, interrupt moderation etc. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 02:55:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E1F0106564A for ; Sat, 13 Dec 2008 02:55:22 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2468FC1E for ; Sat, 13 Dec 2008 02:55:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mBD2tIcp075457; Sat, 13 Dec 2008 13:55:18 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 13 Dec 2008 13:55:18 +1100 (EST) From: Ian Smith To: Randall Stewart In-Reply-To: Message-ID: <20081213134248.W7599@sola.nimnet.asn.au> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net , "Bruce M. Simpson" Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 13 Dec 2008 02:55:22 -0000 On Fri, 12 Dec 2008, Randall Stewart wrote: > Bruce: > > So lets see: > > 1) I went ahead and fixed the comments.. even added a ! instead of :-( Personally: emoticons ARE punctuation; adding a period is totally anal. > 2) No problem using func_t.. changed to that.. seems nicer :-D I guess submitting patches for style(9) is considered a suicide method? Ian <&^}= From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 03:03:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D49061065675 for ; Sat, 13 Dec 2008 03:03:30 +0000 (UTC) (envelope-from mamruoc@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8068FC20 for ; Sat, 13 Dec 2008 03:03:30 +0000 (UTC) (envelope-from mamruoc@gmail.com) Received: by ewy14 with SMTP id 14so2406122ewy.19 for ; Fri, 12 Dec 2008 19:03:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=pQl8sJhBDScGVWn8m4ZgLZvgcU1gQm76v2wVgP2qsW0=; b=NuA6uA1dc6EPlteV1V2cH83fBcSASxnGoE48JTXYltJUq0BbKSb+5Qjz5v7aDeKhqK yu+vuf/esTG5VmUTouLsbBSoXzszf0Bt8LIPFDdqj5NjnBL+d2PPwsZAhqR4304eIl41 JfC+M42NcF3ljov+GK72XO3F4X3al0Lc8L2rg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=IW73hoabydArKjuyyhJ/qJoCee+EUZ3Fa/dR/M3Rd0j7kyim5GynVX2iqrsueoR0P3 Y8/vp62fpEyAa+IdBHjpwEbMCR0Q6we9fUCnqwzje2cUIi+YWm+ZwHqD9hH+nRvJjTae NbQnreQBZ9qOPKlYNC7GULjqSbzUQPY2pdrsQ= Received: by 10.210.59.14 with SMTP id h14mr1643695eba.8.1229137409078; Fri, 12 Dec 2008 19:03:29 -0800 (PST) Received: from appuru.bbse.no (217-14-12-49-dhcp-osl.bbse.no [217.14.12.49]) by mx.google.com with ESMTPS id 10sm157434eyd.46.2008.12.12.19.03.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Dec 2008 19:03:28 -0800 (PST) Message-ID: <494325FF.9040006@gmail.com> Date: Sat, 13 Dec 2008 04:03:27 +0100 From: Mam Ruoc User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> <20081212015842.GH46707@cdnetworks.co.kr> <4941C6BF.4080809@gmail.com> <20081212021549.GJ46707@cdnetworks.co.kr> <49429CEB.60607@gmail.com> <20081213015622.GD51320@cdnetworks.co.kr> In-Reply-To: <20081213015622.GD51320@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: vge driver does not work on a VIA EPIA EN12000EG 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, 13 Dec 2008 03:03:30 -0000 Pyun YongHyeon wrote: > I don't know. :-( > As I said I no longer have working vge(4) hardware and it's hard to > write/test driver without access to the hardware. The code you've > tested contains changes related to MII operation mode and critical > register configuration as well as other improvements. The driver > still needs special handling in several edge cases and more code > to track link state transition, interrupt moderation etc. Hm... So that means that FreeBSD from 7.0 does not support this chipset's NIC? I have to go for another *unix then. Thank you for your help anyway, hope the problem get solved sometime in the future. Mam From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 04:01:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD3401065672 for ; Sat, 13 Dec 2008 04:01:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id A14368FC1B for ; Sat, 13 Dec 2008 04:01:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1655138rvf.43 for ; Fri, 12 Dec 2008 20:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=/tIAtnyd72ibjpci9/f13bTxIqsDbZpCsTcseb0wKQo=; b=bc1tWQtfQ1F/Xxn92Bgf11ZJbFvV3NMUAzVXbQ5CgzjeT78ul6ZfjDMkf+rLRUS0ok FCjYSgEImi1IuwTiM9QKrcbaZ3fFFr1tIb3jnhFwvC9E8kIIABPMfyQ3YRhDvFzmyc3o yUqszVU9JzPcPetRBfwVgYcHdDP6+lAeFTGbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=SkZNv/AJGczaczQkThekMYdg6o9uGIoNvX34NjH0WIPiTV+yHdGPfqFA7Csl53lLMY H5ZrNQZWjPqjvuKRGaeXbY1EsmshXp5ZH3gNnypoPMw4vw6rLy4Fyx1Y+BT9CZ+3r6aR /Qsfmi6ny9w1HRhApA7hRSXTuiixS/bgF9oOM= Received: by 10.141.180.5 with SMTP id h5mr1345415rvp.281.1229140913620; Fri, 12 Dec 2008 20:01:53 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k2sm7214917rvb.8.2008.12.12.20.01.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Dec 2008 20:01:52 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBD41kpb052072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Dec 2008 13:01:46 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBD41jwS052071; Sat, 13 Dec 2008 13:01:45 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 13 Dec 2008 13:01:45 +0900 From: Pyun YongHyeon To: Mam Ruoc Message-ID: <20081213040145.GE51320@cdnetworks.co.kr> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> <20081212015842.GH46707@cdnetworks.co.kr> <4941C6BF.4080809@gmail.com> <20081212021549.GJ46707@cdnetworks.co.kr> <49429CEB.60607@gmail.com> <20081213015622.GD51320@cdnetworks.co.kr> <494325FF.9040006@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494325FF.9040006@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: vge driver does not work on a VIA EPIA EN12000EG X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 04:01:54 -0000 On Sat, Dec 13, 2008 at 04:03:27AM +0100, Mam Ruoc wrote: > Pyun YongHyeon wrote: > >I don't know. :-( > >As I said I no longer have working vge(4) hardware and it's hard to > >write/test driver without access to the hardware. The code you've > >tested contains changes related to MII operation mode and critical > >register configuration as well as other improvements. The driver > >still needs special handling in several edge cases and more code > >to track link state transition, interrupt moderation etc. > > Hm... > > So that means that FreeBSD from 7.0 does not support this chipset's NIC? > No, vge(4) supported all known VIA velocity cotrollers when it was written. Newer revisions of controller seem to require some special handling and the datasheet for recent controllers are not available to open source devlopers. > I have to go for another *unix then. > I don't know how well other open source OSes support VIA velocity controllers but the situation would be roughly same. For instance I don't see any special code for newer controllers in Linux. YMMV. > Thank you for your help anyway, hope the problem get solved sometime in > the future. > Yeah, I hope so and thanks for testing! -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 05:40:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41702106564A for ; Sat, 13 Dec 2008 05:40:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id C45B18FC12 for ; Sat, 13 Dec 2008 05:40:28 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mBD5eQa4004562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Dec 2008 16:40:27 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mBD5eQ62003337; Sat, 13 Dec 2008 16:40:26 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mBD5eQRt003336; Sat, 13 Dec 2008 16:40:26 +1100 (EST) (envelope-from peter) Date: Sat, 13 Dec 2008 16:40:26 +1100 From: Peter Jeremy To: Ian Smith Message-ID: <20081213054026.GF58682@server.vk2pj.dyndns.org> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> <20081213134248.W7599@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ON0CT8LY+wgE1XqS" Content-Disposition: inline In-Reply-To: <20081213134248.W7599@sola.nimnet.asn.au> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-net Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 13 Dec 2008 05:40:29 -0000 --ON0CT8LY+wgE1XqS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Dec-13 13:55:18 +1100, Ian Smith wrote: >I guess submitting patches for style(9) is considered a suicide method? Not necessarily but you need to have very good justification for any change. It's much easier to read a large corpus of code where the code is all written in one style. I suspect that no-one is happy with everything in style(9) but consistency is seen as more important. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --ON0CT8LY+wgE1XqS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklDSsoACgkQ/opHv/APuIf+nACaAvzUjeHB3DK2d/DNRUMdyrpB tyIAn3G80VCst6ol4tMStCm8mGrS5PoI =9czW -----END PGP SIGNATURE----- --ON0CT8LY+wgE1XqS-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 09:05:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1DBA1065670 for ; Sat, 13 Dec 2008 09:05:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 71E998FC21 for ; Sat, 13 Dec 2008 09:05:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mBD95O1s087048; Sat, 13 Dec 2008 20:05:24 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 13 Dec 2008 20:05:24 +1100 (EST) From: Ian Smith To: Peter Jeremy In-Reply-To: <20081213054026.GF58682@server.vk2pj.dyndns.org> Message-ID: <20081213195946.G7599@sola.nimnet.asn.au> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> <20081213134248.W7599@sola.nimnet.asn.au> <20081213054026.GF58682@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 13 Dec 2008 09:05:27 -0000 On Sat, 13 Dec 2008, Peter Jeremy wrote: > On 2008-Dec-13 13:55:18 +1100, Ian Smith wrote: > >I guess submitting patches for style(9) is considered a suicide method? > > Not necessarily but you need to have very good justification for any > change. It's much easier to read a large corpus of code where the > code is all written in one style. I suspect that no-one is happy > with everything in style(9) but consistency is seen as more important. No doubt. Apologies to all, especially Randall, for a flippant and off-topic post. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 10:05:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB6FC1065678 for ; Sat, 13 Dec 2008 10:05:53 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 87C698FC22 for ; Sat, 13 Dec 2008 10:05:53 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mBDA5pHU034598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 13 Dec 2008 05:05:52 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1229162752; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=lK9OUhrI2fheTyZUh3OoyjZL+i0xdXBI9CKEOzWcUGvQkKU3Zq2r4n6 9Fq6ttpq2V02MEwkOPoP7VUtoiGU6LQ== Message-Id: From: Randall Stewart To: Ian Smith In-Reply-To: <20081213195946.G7599@sola.nimnet.asn.au> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 13 Dec 2008 05:05:51 -0500 References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> <20081213134248.W7599@sola.nimnet.asn.au> <20081213054026.GF58682@server.vk2pj.dyndns.org> <20081213195946.G7599@sola.nimnet.asn.au> X-Mailer: Apple Mail (2.929.2) Cc: Peter Jeremy , freebsd-net Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 13 Dec 2008 10:05:54 -0000 Ian: No problem what so ever... My native style is CLOSE to style(9).. but it often is hard for me to get "all" the little twists. And with SCTP we have 2 other primary developers and a few other contributors that work on the windoz stuff and user space... so we depend on s9indent exclusively.. Being an old-fart its hard to change style... and when emacs does not help me it makes it even worse ;-0 I have noticed over the last few years my style has been evolving closer and closer to style9.. but after 28 years of writing kernel level C code style changes slowly :-0 (old dogs and all that). Actually unless you are looking for excess blank lines, missing "."'s in comments and minor nits... I think I am pretty close to style9.. not that I am perfect (thats why s9indent is a plus ;-D)... I try.. but like all of us I am not perfect by a LONG LONG way (just ask my wife :-D) I will let this hang here for a while.. I have to head up for U of Del for a PHd committee I am on... so I will see if over the next week or so anyone else throws flames out... (I am more concerned about the functioning of the code then the style actually.. but hey I understand some folks are "style nazi's" thats ok... thats probably why s9indent was invented ;-D) R On Dec 13, 2008, at 4:05 AM, Ian Smith wrote: > On Sat, 13 Dec 2008, Peter Jeremy wrote: >> On 2008-Dec-13 13:55:18 +1100, Ian Smith >> wrote: >>> I guess submitting patches for style(9) is considered a suicide >>> method? >> >> Not necessarily but you need to have very good justification for any >> change. It's much easier to read a large corpus of code where the >> code is all written in one style. I suspect that no-one is happy >> with everything in style(9) but consistency is seen as more >> important. > > No doubt. > > Apologies to all, especially Randall, for a flippant and off-topic > post. > > cheers, Ian > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 10:42:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6883B106564A; Sat, 13 Dec 2008 10:42:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id E1F798FC17; Sat, 13 Dec 2008 10:41:59 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-107-112-209.carlnfd1.nsw.optusnet.com.au [122.107.112.209]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mBDAftnF029828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Dec 2008 21:41:56 +1100 Date: Sat, 13 Dec 2008 21:41:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Randall Stewart In-Reply-To: <8835B402-CD0D-4246-ABD3-F2B1BB230820@lakerest.net> Message-ID: <20081213203723.A977@besplex.bde.org> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> <8835B402-CD0D-4246-ABD3-F2B1BB230820@lakerest.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net , "Bruce M. Simpson" Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 13 Dec 2008 10:42:00 -0000 On Fri, 12 Dec 2008, Randall Stewart wrote: > Well tell you what Bruce: > > How about if I just run the WHOLE file through s9indent... > > This will fix ALL my problems.. and of course "fix" the > rest of the file too.. Any automated conversion utility is very likely to introduce more bugs than it fixes. I haven't seen any that even try to work right. You would have to inspect every change and throw out most. With a working-right utility, you wouldn't have to do this since you would direct it to make only changes that you really want, including somehow restricting the changes to your new code. > Unless you think its already in conformance (bet you > its not) :-) According to my (buggy) knfometer utilty (just indent(1) with certain options followed by comparision of the size of the diff with the size of the original file): 94.325% udp_usrreq.c 80.452% udp_var.h 93.528% udp6_usrreq.c Anything above 90% is good and indicates that most of the changes are due to bugs in the conversion utility. In fact, indent seems to be making much the same wrong changes as your s9indent (I see the patch from that in a later reply -- I might respond to that too). Here is what indent does with udp_usrreq.c (the diff is larger than 5.675% of the file since it is -u2 while 5.675% is for a plain diff): % --- udp_usrreq.c.BAK 2008-12-13 09:49:18.398640000 +0000 % +++ udp_usrreq.c 2008-12-13 09:49:18.403640000 +0000 % @@ -99,4 +99,5 @@ % #ifdef VIMAGE_GLOBALS % int udp_blackhole; % + % #endif % Bug in indent. indent knows that it doesn't understand cpp directives so it tries not to touch them, but it still botches #endif by adding a blank line (and by misformatting any comment on #endif). % @@ -107,9 +108,11 @@ % * cause problems (especially for NFS data blocks). % */ % -static int udp_cksum = 1; % +static int udp_cksum = 1; Bug in indent, same as in s9indent. indent doesn't understand the arcane rule followed by the original code here, though I have directed it to indent by 1 tab after declaration-specificers. The problem is that indent knows that there are problems doing this for declaration-specifers longer than 7 characters (since the tab couldn't give the normal indent of 8 characters then), while the above code is happy to indent all the variable names to 16 characters. % + Bug in indent. Not shared by s9indent. The problem is that indent doesn't understand the ugly SYSCTL_INT() in the next statement. It thinks that SYSCTL_INT() is a function definition and has been directed to put a blank line before function definitions. % SYSCTL_INT(_net_inet_udp, UDPCTL_CHECKSUM, checksum, CTLFLAG_RW, &udp_cksum, % 0, "compute udp checksum"); % % int udp_log_in_vain = 0; % + Same bug as above. Now the indentation is unchanged though it is inconsistent with previous indentation, since the declaration-specifier is short. s9indent breaks the indentation here, since it doesn't understand or hasn't been directed that variable names should be indented by a tab (except in auto declarations). % SYSCTL_INT(_net_inet_udp, OID_AUTO, log_in_vain, CTLFLAG_RW, % &udp_log_in_vain, 0, "Log all incoming UDP packets"); % @@ -120,5 +123,6 @@ % % u_long udp_sendspace = 9216; /* really max datagram size */ % - /* 40 1K datagrams */ % + % + /* 40 1K datagrams */ Bug in indent, same as in s9indent. indent doesn't understand that the second comment is part of the first (which is a hard thing to understand), so it makes a mess. % SYSCTL_ULONG(_net_inet_udp, UDPCTL_MAXDGRAM, maxdgram, CTLFLAG_RW, % &udp_sendspace, 0, "Maximum outgoing UDP datagram size"); % @@ -126,9 +130,9 @@ % u_long udp_recvspace = 40 * (1024 + % #ifdef INET6 % - sizeof(struct sockaddr_in6) % + sizeof(struct sockaddr_in6) % #else % - sizeof(struct sockaddr_in) % + sizeof(struct sockaddr_in) % #endif % - ); % +); indent mangles the special formatting here, the same as s9indent. It is following the strict rules here (except the final ");" should be indented by 4 characters too), but the original code has fancy formatting that intentionally breaks the rules. The strict rules are also wrong. indent doesn't really understand initializers in declarations. For function calls, it would start the 4-character continuation indent at the start of the function name, but it doesn't have a corresponding rule for initalizers and indents relative to column 0. % % SYSCTL_ULONG(_net_inet_udp, UDPCTL_RECVSPACE, recvspace, CTLFLAG_RW, % @@ -136,7 +140,8 @@ % % #ifdef VIMAGE_GLOBALS % -struct inpcbhead udb; /* from udp_var.h */ % -struct inpcbinfo udbinfo; % -struct udpstat udpstat; /* from udp_var.h */ % +struct inpcbhead udb; /* from udp_var.h */ % +struct inpcbinfo udbinfo; % +struct udpstat udpstat; /* from udp_var.h */ indent only messes up the fancy indentation of the variable names here. s9indent does this too, and also messes up the indentation of the comments. indent preserves the 40-character indentation of the comments though they might appear to be changed due to mail and markup not aligning the start of the line to a tab position. s9indent changes the comment indentation to 32 characters. I direct indent to use 40 characters (-c41 -cd41) because checking lots of KNF code (all of kern and vi and some others) indicates that 40 characters is slightly more common than 32. udp_usrreq.c apparently uses 40 so knfometer likes it. % ... % @@ -149,7 +154,8 @@ % "UDP statistics (struct udpstat, netinet/udp_var.h)"); % % -static void udp_detach(struct socket *so); % -static int udp_output(struct inpcb *, struct mbuf *, struct sockaddr *, % - struct mbuf *, struct thread *); % +static void udp_detach(struct socket *so); % +static int % +udp_output(struct inpcb *, struct mbuf *, struct sockaddr *, % + struct mbuf *, struct thread *); indent doesn't understand protoytypes and mangles their original perfect KNF formatting unless they are short. It also doesn't understand line splitting, so it doesn't change the splitting point for udp_output() in the above ("struct mbuf *" now fits on the previous line). s9indent has the same bugs. % @@ -219,5 +227,5 @@ % return; % } % -#endif /* IPSEC */ % +#endif /* IPSEC */ Bug documented above. % #ifdef MAC % if (mac_inpcb_check_deliver(inp, n) != 0) { % @@ -272,6 +280,8 @@ % struct ip save_ip; % struct sockaddr_in udp_in; % + % #ifdef IPFIREWALL_FORWARD % struct m_tag *fwd_tag; % + % #endif indent also puts a bogus blank line before ifdef. % % @@ -284,9 +294,8 @@ % * check the checksum with options still present. % */ % - if (iphlen > sizeof (struct ip)) { % + if (iphlen > sizeof(struct ip)) { Here is the first change that is actually correct. % ip_stripoptions(m, (struct mbuf *)0); % iphlen = sizeof(struct ip); % } % - % /* % * Get IP and UDP header together in first mbuf. Always omitting optional blank lines is KNF, but I don't like it before block comments. % ... % @@ -361,5 +369,5 @@ % bzero(((struct ipovly *)ip)->ih_x1, 9); % ((struct ipovly *)ip)->ih_len = uh->uh_ulen; % - uh_sum = in_cksum(m, len + sizeof (struct ip)); % + uh_sum = in_cksum(m, len + sizeof(struct ip)); % bcopy(b, ((struct ipovly *)ip)->ih_x1, 9); % } Actually correct. % @@ -433,8 +441,8 @@ % if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) && % imo != NULL) { % - struct sockaddr_in sin; % - struct in_msource *ims; % - int blocked, mode; % - size_t idx; % + struct sockaddr_in sin; % + struct in_msource *ims; % + int blocked, mode; % + size_t idx; % % bzero(&sin, sizeof(struct sockaddr_in)); Correct again. Maybe only FreeBSD indent supports different indentation rules for local declarations. % @@ -466,7 +474,7 @@ % mode = imo->imo_mfilters[idx].imf_fmode; % if ((ims != NULL && % - mode == MCAST_EXCLUDE) || % + mode == MCAST_EXCLUDE) || % (ims == NULL && % - mode == MCAST_INCLUDE)) { % + mode == MCAST_INCLUDE)) { % #ifdef DIAGNOSTIC % if (bootverbose) { % @@ -504,5 +512,5 @@ % */ % if ((last->inp_socket->so_options & % - (SO_REUSEPORT|SO_REUSEADDR)) == 0) % + (SO_REUSEPORT | SO_REUSEADDR)) == 0) % break; % } All correct. % ... % @@ -531,5 +538,5 @@ % if (inp == NULL) { % if (udp_log_in_vain) { % - char buf[4*sizeof "123"]; % + char buf[4 * sizeof "123"]; Correct, but indent doesn't support adding the required parentheses here. % @@ -661,8 +667,7 @@ % n = V_udbinfo.ipi_count; % req->oldidx = 2 * (sizeof xig) % - + (n + n/8) * sizeof(struct xinpcb); % + + (n + n / 8) * sizeof(struct xinpcb); Correct but incomplete. indent doesn't support the style rule that requires the line split to occur after the operation instead of before. % return (0); % } % - % if (req->newptr != 0) % return (EPERM); Example of an optional blank line that should be removed. % [... lots more, mostly correct] % @@ -1278,18 +1276,18 @@ % % struct pr_usrreqs udp_usrreqs = { % - .pru_abort = udp_abort, % - .pru_attach = udp_attach, % - .pru_bind = udp_bind, % - .pru_connect = udp_connect, % - .pru_control = in_control, % - .pru_detach = udp_detach, % - .pru_disconnect = udp_disconnect, % - .pru_peeraddr = in_getpeeraddr, % - .pru_send = udp_send, % - .pru_soreceive = soreceive_dgram, % - .pru_sosend = sosend_dgram, % - .pru_shutdown = udp_shutdown, % - .pru_sockaddr = in_getsockaddr, % - .pru_sosetlabel = in_pcbsosetlabel, % - .pru_close = udp_close, % + .pru_abort = udp_abort, % + .pru_attach = udp_attach, % + .pru_bind = udp_bind, % + .pru_connect = udp_connect, % + .pru_control = in_control, % + .pru_detach = udp_detach, % + .pru_disconnect = udp_disconnect, % + .pru_peeraddr = in_getpeeraddr, % + .pru_send = udp_send, % + .pru_soreceive = soreceive_dgram, % + .pru_sosend = sosend_dgram, % + .pru_shutdown = udp_shutdown, % + .pru_sockaddr = in_getsockaddr, % + .pru_sosetlabel = in_pcbsosetlabel, % + .pru_close = udp_close, % }; indent doesn't understand the fancy formatting in the original code and makes a mess. s9indent has the same bug. To understand this, indent would probably need to understand C99 struct initializers, but indent doesn't even understand C90 prototypes yet. Once indent understands this, it could support a flag for fancy formatting of struct initializers independently of its formatting of other initializers and assignments. Bruce From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 11:28:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC390106564A; Sat, 13 Dec 2008 11:28:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id 32D3F8FC18; Sat, 13 Dec 2008 11:28:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-107-112-209.carlnfd1.nsw.optusnet.com.au [122.107.112.209]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mBDBSm2g004983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Dec 2008 22:28:49 +1100 Date: Sat, 13 Dec 2008 22:28:43 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Randall Stewart In-Reply-To: Message-ID: <20081213214209.L977@besplex.bde.org> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net , "Bruce M. Simpson" Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 13 Dec 2008 11:28:51 -0000 On Fri, 12 Dec 2008, Randall Stewart wrote: > 1) I went ahead and fixed the comments.. even added a ! instead of :-( > > 2) No problem using func_t.. changed to that.. seems nicer :-D > > 3) Removed an extra cr or two you pointed out.. hopefully got them all. OK. > 4) I disagree with you on the cast... its not ugly.. it prevents us > from having to have a per_pcb structure for UDP when all we need > is one pointer. As I said in my first post.. it seemed like to much > overhead, creating a zone for a single pointer... I am not adverse to > casts .. but of course I guess I am just an old fart who has been around > to many years writing code :-) This is actually more broken than I first thought. inp_ppcb is "void *" but is abused to hold a function pointer. This gives undefined behaviour with or without the cast. The actual behaviour is apparently to work on all supported machines, but to suppress printing of a diagnostic with the cast. On ia64, function pointers are very different from "void *", but they can still be represented as "void *" after a conversion. I think ia64 function pointers are implemented as something like an integer index into a table of the actual pointers. Since 2^32 function pointers should be enough for anyone, 64-bit "void *" is more than large enough to represent them. If inp_ppcb were a generic function pointer, then a conversion would still be needed, but it doesn't need to be a cast. Simple assignment without the cast must work. However, I think we have warning flags set to such a high level that there would be warnings for the type change done by assignment, and the cast would be needed anyway to suppress the warning. I don't like this. Casts normally do suppress warnings and this hides errors too. Of course, saving space is a valid reason for this hack. > > 5) I ran s9indent.. and of course it found a lot of other things you missed.. > but that > is the way of s9indent I have found :-D Not surprising that it has bugs :-). Apart from the types of errors mentioned in my previous mail, it does the following unformatting: [hard carriage returns removed from diff] % Index: netinet/udp_usrreq.c % =================================================================== % --- netinet/udp_usrreq.c (revision 185928) % +++ netinet/udp_usrreq.c (working copy) % @@ -97,7 +97,8 @@ % */ % % #ifdef VIMAGE_GLOBALS % -int udp_blackhole; % +int udp_blackhole; % + % #endif Hmm, it mangles #endif the same as indent(1), so it seems to be just a wrapper for indent(1), just with slightly worse directives than my knfometer. [% ...] I don't notice many more problems than mentioned in my previous mail. The slightly worse directives are -c33 instead of -c41 and whatever directive it is that breaks the tab indentation for udp_blackhole above. BTW, I used to use that directive in knfometer too. It was needed because most declarations are local, but old FreeBSD indent and gnu indent don't support different formatting for local declarations, so the directive that gave the least mangling was the one that preserved the formatting of local declarations. I eventually modified FreeBSD indent to support the different formatting. Not having this is one of the main problems that makes gnu indent not directly usable for formatting to KNF (gnu indent is generally better but has fewer features -- surprising for a gnu utility). % @@ -387,7 +395,8 @@ % uh->uh_dport = ntohs(next_hop->sin_port); % % /* % - * Remove the tag from the packet. We don't need it anymore. % + * Remove the tag from the packet. We don't need it % + * anymore. % */ % m_tag_delete(m, fwd_tag); % } No need to change this. Another bug in indent is that it has no flexibility for preserving formatting that is good enough. Normally you don't want large block comments reformatted. The line length parameter only works for reformatting comments, but minor changes in it normally lead to complete reformatting of block comments. knfometer uses directives to suppress reformatting of all block comments although this misses some necessary reformatting. % @@ -414,10 +423,11 @@ % inp->inp_faddr.s_addr != ip->ip_src.s_addr) % continue; % /* % - * XXX: Do not check source port of incoming datagram % - * unless inp_connect() has been called to bind the % - * fport part of the 4-tuple; the source could be % - * trying to talk to us with an ephemeral port. % + * XXX: Do not check source port of incoming % + * datagram unless inp_connect() has been called to % + * bind the fport part of the 4-tuple; the source % + * could be trying to talk to us with an ephemeral % + * port. % */ Again, the original formatting was good enough. The programmer may have done right near-justification manually or using a better utility than indent. [... most changes continue to be for correctly formatted block comments] % @@ -488,41 +500,72 @@ % struct mbuf *n; % % n = m_copy(m, 0, M_COPYALL); % - if (n != NULL) % - udp_append(last, ip, n, iphlen + % - sizeof(struct udphdr), &udp_in); % - INP_RUNLOCK(last); % + if (last->inp_ppcb == NULL) { % + if (n != NULL) % + udp_append(last, ip, n, iphlen + % + sizeof(struct udphdr), &udp_in); Still have several too-line lines. indent doesn't support reformatting long lines except in comments. % Index: netinet/udp_var.h % =================================================================== % --- netinet/udp_var.h (revision 185928) % +++ netinet/udp_var.h (working copy) % @@ -38,9 +38,10 @@ % * UDP kernel structures and variables. % */ % struct udpiphdr { % - struct ipovly ui_i; /* overlaid ip structure */ % - struct udphdr ui_u; /* udp header */ % + struct ipovly ui_i; /* overlaid ip structure */ % + struct udphdr ui_u; /* udp header */ % }; indent with suitable directives can avoid this mangling, but neither it nor style(9) know the core rule that the indentation may be excessive (to make struct member names line up despite verbose declaration-specifiers) provided at least 10% of the declaration-specifiers are verbose. % ... % -void udp_ctlinput(int, struct sockaddr *, void *); % -void udp_init(void); % -void udp_input(struct mbuf *, int); % -struct inpcb *udp_notify(struct inpcb *inp, int errno); % -int udp_shutdown(struct socket *so); % +void udp_ctlinput(int, struct sockaddr *, void *); % +void udp_init(void); % +void udp_input(struct mbuf *, int); % +struct inpcb *udp_notify(struct inpcb *inp, int errno); % +int udp_shutdown(struct socket *so); % + % + % +typedef void (*udp_tunnel_func_t) (struct mbuf *, int off); % +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f); % + % #endif % % #endif Now everything here is a mess. Another bug or two in indent causes it to put the bogus space after "(*udp_tunnel_func_t)" when starting with a perfectly formatted prototype. Bruce From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 11:49:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EB7F1065675 for ; Sat, 13 Dec 2008 11:49:56 +0000 (UTC) (envelope-from frank@harz.behrens.de) Received: from post.behrens.de (post.behrens.de [IPv6:2a01:170:1023::1:2]) by mx1.freebsd.org (Postfix) with ESMTP id 7547B8FC08 for ; Sat, 13 Dec 2008 11:49:55 +0000 (UTC) (envelope-from frank@harz.behrens.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=behrens.de; h=from:to:date:mime-version:subject:cc:in-reply-to:references:content-type:content-transfer-encoding:content-description; s=pinky1; t=1229168992; i=frank@harz.behrens.de; bh=/hu/RxgUWuXB7P4TYQswl/hQbnxnApTNBGu77H6FLFU=; b=m62YWoBM5pZIr94mN2cUyI9i23FYnlOTrVb5Mg10Xiz6za5wPRcnL2G55zXs6BMcyy/1hNymwHlrXg3BJRaRlg== Received: from sun.behrens ([IPv6:2a01:170:1023:0:1d9d:e7cf:365b:e76c]) by post.behrens.de (8.14.3/8.14.2) with ESMTP(MSA) id mBDBnfOa023545; Sat, 13 Dec 2008 12:49:41 +0100 (CET) (envelope-from frank@harz.behrens.de) Message-Id: <200812131149.mBDBnfOa023545@post.behrens.de> From: "Frank Behrens" To: "Bjoern A. Zeeb" Date: Sat, 13 Dec 2008 12:49:41 +0100 MIME-Version: 1.0 Priority: normal In-reply-to: <20081208205426.V80401@maildrop.int.zabbadoz.net> References: <200812031220.mB3CK204015947@post.behrens.de> X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Hashcash: 1:23:081213:freebsd-net@freebsd.org::XC703qJN9CkO1gxU:0000000000Hco8 X-Hashcash: 1:23:081213:bzeeb-lists@lists.zabbadoz.net::FrCj5jl7ip0wpZMN:000+oqA Cc: freebsd-net@freebsd.org Subject: Re: Problem with new source address selection 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, 13 Dec 2008 11:49:56 -0000 Bjoern A. Zeeb wrote on 8 Dec 2008 21:02: > Did you try the patch and did it work for you as expected? If so I'll > add it to my repo and the next jail patch. Meanwhile I can confirm that your patch works well for me on an up-to- date RELENG_7 kernel. Thanks! Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 19:30:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B5F01065673 for ; Sat, 13 Dec 2008 19:30:18 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id DBA3F8FC1C for ; Sat, 13 Dec 2008 19:30:17 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-024-089.pools.arcor-ip.net [88.66.24.89]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis) id 0MKwpI-1LBaBs12u4-0002DC; Sat, 13 Dec 2008 20:30:16 +0100 Received: (qmail 31165 invoked from network); 13 Dec 2008 19:30:15 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by laiers.local with SMTP; 13 Dec 2008 19:30:15 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sat, 13 Dec 2008 20:30:15 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> In-Reply-To: <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_H1ARJKf5YREingh" Message-Id: <200812132030.15665.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18hz1UdNocy86y97PC2ejc4XPHPDMxJQkWHl6R xmXu9FN6D/WeV898i/lxfM1bX2js2SJTNZs4nEgugA5rnnqwZB kF2riNNLTjPB02Gm18Dkw== Cc: "Bruce M. Simpson" , Randall Stewart Subject: Re: Heads up --- Thinking about UDP and tunneling 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, 13 Dec 2008 19:30:18 -0000 --Boundary-00=_H1ARJKf5YREingh Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 12 December 2008 14:46:30 Randall Stewart wrote: > Ok: > > Here is an updated patch it: > > 1) Fixes style9 issues > 2) move to _t typedef I won't get into this. > 3) Allow multicast/broadcast to also be tunneled. There seems to be an error with your patch. You RUNLOCK twice in some places - should be fixed in my version of the patch (see attached). > 4) Binding is now no longer a requirement to set tunneling mode, in > fact most protocols had better NOT have bound.. first set options, then > bind :-) Yep. > There was one thing I was a bit leary of for <3>. In the loop for > going through all the inp's of UDP that are listening to a m-cast/b-cast > I could not release the INP_INFO_LOCK() in other cases I make sure all > locks are released when we call into the tunneling protocol. I think > this will be ok as long as the tunnelee does not try to use the > INP_INFO_LOCK of the UDP world... I know for SCTP this is a non-issue.. but > it may be something we want to think about... not sure. I added a comment inline. Maybe we should add a flag to the tunnel function prototype, so that the called party can figure out if they need to defer work that is not allowed under the lock (e.g. malloc WAITOK). On top of that, I was wondering if it might make sense to pass in the inp as an argument - so that the tunnel consumer can figure out which tunnel the packet was received on (without relying on data off the wire). In that case I'd leave the inp RLOCK'ed and leave it up the the called party to release the lock if they so desire. > If there are no serious objections I will submit this into head.. and There are some open issues, see above - but in general okay with me. > followed behind it I will send in the changes so SCTP can be tunneled over > this new mechanism :-) -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-00=_H1ARJKf5YREingh Content-Type: text/plain; charset="iso-8859-15"; name="new_udp_diff.mlaier.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="new_udp_diff.mlaier.txt" Index: netinet/udp_var.h =================================================================== --- netinet/udp_var.h (revision 186046) +++ netinet/udp_var.h (working copy) @@ -110,6 +110,10 @@ void udp_input(struct mbuf *, int); struct inpcb *udp_notify(struct inpcb *inp, int errno); int udp_shutdown(struct socket *so); + + +typedef void(*udp_tunnel_function_t)(struct mbuf *, int off); +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f); #endif #endif Index: netinet/udp_usrreq.c =================================================================== --- netinet/udp_usrreq.c (revision 186046) +++ netinet/udp_usrreq.c (working copy) @@ -488,10 +488,29 @@ struct mbuf *n; n = m_copy(m, 0, M_COPYALL); - if (n != NULL) - udp_append(last, ip, n, iphlen + - sizeof(struct udphdr), &udp_in); - INP_RUNLOCK(last); + + if (last->inp_ppcb == NULL) { + if (n != NULL) + udp_append(last, ip, n, iphlen + + sizeof(struct udphdr), &udp_in); + INP_RUNLOCK(last); + } else { + /* Engage the tunneling protocol + * we will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't break :-( + * + * XXXML: Maybe add a flag to the + * prototype so that the tunneling + * can defer work that can't be done + * under the info lock? + */ + udp_tunnel_function_t tunnel_func; + + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, iphlen); + } } last = inp; /* @@ -516,10 +535,24 @@ V_udpstat.udps_noportbcast++; goto badheadlocked; } - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), - &udp_in); - INP_RUNLOCK(last); - INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb == NULL) { + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), + &udp_in); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } else { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + tunnel_func(m, iphlen); + } return; } @@ -563,6 +596,18 @@ INP_RUNLOCK(inp); goto badunlocked; } + if (inp->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; + INP_RUNLOCK(inp); + tunnel_func(m, iphlen); + return; + } udp_append(inp, ip, m, iphlen + sizeof(struct udphdr), &udp_in); INP_RUNLOCK(inp); return; @@ -1138,10 +1183,41 @@ INP_INFO_WUNLOCK(&V_udbinfo); inp->inp_vflag |= INP_IPV4; inp->inp_ip_ttl = V_ip_defttl; + /* + * UDP does not have a per-protocol + * pcb (inp->inp_ppcb). We use this + * pointer for kernel tunneling pointer. + * If we ever need to have a protocol + * block we will need to move this + * function pointer there. Null + * in this pointer means "do the normal + * thing". + */ + inp->inp_ppcb = NULL; INP_WUNLOCK(inp); return (0); } +int +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f) +{ + struct inpcb *inp; + inp = (struct inpcb *)so->so_pcb; + + if (so->so_type != SOCK_DGRAM) { + /* Not UDP socket... sorry */ + return (ENOTSUP); + } + if (inp == NULL) { + /* NULL INP? */ + return (EINVAL); + } + INP_WLOCK(inp); + inp->inp_ppcb = f; + INP_WUNLOCK(inp); + return (0); +} + static int udp_bind(struct socket *so, struct sockaddr *nam, struct thread *td) { Index: netinet6/udp6_usrreq.c =================================================================== --- netinet6/udp6_usrreq.c (revision 186046) +++ netinet6/udp6_usrreq.c (working copy) @@ -287,8 +287,20 @@ if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { INP_RLOCK(last); - udp6_append(last, n, off, &fromsa); - INP_RUNLOCK(last); + if (last->inp_ppcb) { + /* Engage the tunneling protocol + * we will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't break :-( + */ + udp_tunnel_function_t tunnel_func; + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, off); + } else { + udp6_append(last, n, off, &fromsa); + INP_RUNLOCK(last); + } } } last = inp; @@ -317,6 +329,19 @@ } INP_RLOCK(last); INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, off); + return (IPPROTO_DONE); + } udp6_append(last, m, off, &fromsa); INP_RUNLOCK(last); return (IPPROTO_DONE); @@ -354,6 +379,18 @@ } INP_RLOCK(inp); INP_INFO_RUNLOCK(&V_udbinfo); + if (inp->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; + INP_RUNLOCK(inp); + tunnel_func(m, off); + return (IPPROTO_DONE); + } udp6_append(inp, m, off, &fromsa); INP_RUNLOCK(inp); return (IPPROTO_DONE); --Boundary-00=_H1ARJKf5YREingh-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 19:45:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4173D1065676 for ; Sat, 13 Dec 2008 19:45:19 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id C585A8FC19 for ; Sat, 13 Dec 2008 19:45:18 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-024-089.pools.arcor-ip.net [88.66.24.89]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1LBaQP2mwI-000290; Sat, 13 Dec 2008 20:45:17 +0100 Received: (qmail 31355 invoked from network); 13 Dec 2008 19:45:17 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 13 Dec 2008 19:45:17 -0000 From: Max Laier Organization: FreeBSD To: FreeBSD virtualization mailing list Date: Sat, 13 Dec 2008 20:45:16 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> In-Reply-To: <20081213191345.M97918@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812132045.17207.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+27IOqh0kpb5k9lkeo0cpRVtzIiDsAHcZb2vO DWV2V/F0JRgyYSISL98JPhaRoUcr1hAs223+9ncH7M1jhT/JNL YMVGRKgYXnkNJ84kz4J2g== Cc: svn-src-head@freebsd.org, freebsd-net@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, FreeBSD current mailing list Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack 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, 13 Dec 2008 19:45:19 -0000 On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: ... > This state of having the variables in parallel, global and in the > container struct, will be maintained for another (short) time until > the entire virtualization framework is in. This is needed, so that > all three possible states can be benchmarked from exactly the same > code changeset. > > > For developers comitting new code or changing code it is important to > properly add virtualized variables in the way that: > 1) the globals and externs (if needed) are added/kept in sync as both > a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate > container struct + the V_ macro. > When used somewhere in code one has to use the V_foobarbaz version. Is there (an easy) way to have the tinderbox build every other run without VIMAGE_GLOBALS so that the most obvious error (global available, but not in the container struct - or the other way around) can be warned about? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 19:54:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABB4D1065670; Sat, 13 Dec 2008 19:54:12 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 37C9A8FC08; Sat, 13 Dec 2008 19:54:12 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id CBAC441C64A; Sat, 13 Dec 2008 20:35:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id LuSxzKuBSDNS; Sat, 13 Dec 2008 20:35:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 6AADA41C615; Sat, 13 Dec 2008 20:35:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 555864448D5; Sat, 13 Dec 2008 19:33:54 +0000 (UTC) Date: Sat, 13 Dec 2008 19:33:53 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, FreeBSD virtualization mailing list In-Reply-To: <200812131913.mBDJD38C037353@svn.freebsd.org> Message-ID: <20081213191345.M97918@maildrop.int.zabbadoz.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, FreeBSD current mailing list Subject: HEADS UP: vimage - virtualized global variables in the network stack X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD virtualization mailing list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 19:54:12 -0000 On Sat, 13 Dec 2008, Bjoern A. Zeeb wrote: Hi, > Author: bz > Date: Sat Dec 13 19:13:03 2008 > New Revision: 186048 > URL: http://svn.freebsd.org/changeset/base/186048 > > Log: > Second round of putting global variables, which were virtualized > but formerly missed under VIMAGE_GLOBAL. > > Put the extern declarations of the virtualized globals > under VIMAGE_GLOBAL as the globals themsevles are already. > This will help by the time when we are going to remove the globals > entirely. As some of you might have noticed that Marko's last commit for the first time in the series of vimage commits was an actual functional change. By default HEAD is no longer using the globals. With my commit the current set of virtualized variables is assumed to be "clean". This basically means three things: 1) The former globals and their externs are all under #ifdef VIMAGE_GLOBALS 2) The same variables are present in a 'container struct' 3) The initialization of those is done from 'constructor ("init") functions' This state of having the variables in parallel, global and in the container struct, will be maintained for another (short) time until the entire virtualization framework is in. This is needed, so that all three possible states can be benchmarked from exactly the same code changeset. For developers comitting new code or changing code it is important to properly add virtualized variables in the way that: 1) the globals and externs (if needed) are added/kept in sync as both a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate container struct + the V_ macro. When used somewhere in code one has to use the V_foobarbaz version. 2) Any new virtualized globals must not be directly initialized. They have to be initialized from a contructor function (which is usually there already). If you are confused about some of the terms etc. follow the links in the "Some documentation" section on the wiki: http://wiki.freebsd.org/Image The "Vimage Coding - beginners guide / FAQ" tries to answer the 101 questions. For the beaf you'll find the link to a document in perforce with the last question (that you may already know). We'll try to enhance this as we get questions or the integration goes on. In case of questions or suggestions ideally follow-up on freebsd-virtualization@ . /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 20:10:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7744410656A3; Sat, 13 Dec 2008 20:10:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id F28588FC17; Sat, 13 Dec 2008 20:10:06 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 2048F41C6A3; Sat, 13 Dec 2008 21:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id AL8qj7J-9cEK; Sat, 13 Dec 2008 21:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id BC8A041C6A1; Sat, 13 Dec 2008 21:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1A8434448D5; Sat, 13 Dec 2008 20:07:38 +0000 (UTC) Date: Sat, 13 Dec 2008 20:07:38 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Max Laier In-Reply-To: <200812132045.17207.max@love2party.net> Message-ID: <20081213195343.V97918@maildrop.int.zabbadoz.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> <200812132045.17207.max@love2party.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, FreeBSD current mailing list , FreeBSD virtualization mailing list , freebsd-net@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack 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, 13 Dec 2008 20:10:07 -0000 On Sat, 13 Dec 2008, Max Laier wrote: > On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: > ... >> This state of having the variables in parallel, global and in the >> container struct, will be maintained for another (short) time until >> the entire virtualization framework is in. This is needed, so that >> all three possible states can be benchmarked from exactly the same >> code changeset. >> >> >> For developers comitting new code or changing code it is important to >> properly add virtualized variables in the way that: >> 1) the globals and externs (if needed) are added/kept in sync as both >> a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate >> container struct + the V_ macro. >> When used somewhere in code one has to use the V_foobarbaz version. > > Is there (an easy) way to have the tinderbox build every other run without > VIMAGE_GLOBALS so that the most obvious error (global available, but not in > the container struct - or the other way around) can be warned about? Without VIMAGE_GLOBALS is the default; we have been building this for a few days already. The flip had been so smoothly that almost noone had really noticed. Marko has done a really great job! Thus my HEADS UP now after I am confident enough that (almost) all places were caught and clean. In case you want to check yourself you can simply put a file into one or multiple archs conf dir that looks like: ------------------------------------------------------------------------ > cat sys/amd64/conf/LINT-VIMAGE_GLOBALS include LINT ident LINT-VIMAGE_GLOBALS options VIMAGE_GLOBALS ------------------------------------------------------------------------ I am doing that build every other day from now to catch the possible error of a virtualized variable in the container struct w/o the global. But as this is the least problematic case I do not want to commit the kernel configuration as it'll make builds longer for everyone, etc. The more problematic cases that builds cannot catch are: - static initialization of a virtualized 'global'. - a newly added virtualized 'global' that is not under #ifdef VIMAGE_GLOBALS I have scripts to identify the latter already. The former will only be caught be either code inspection or "unexpected results" when running. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 20:27:17 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C195106570C; Sat, 13 Dec 2008 20:27:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 259428FC13; Sat, 13 Dec 2008 20:27:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mBDKOPGs092903; Sat, 13 Dec 2008 13:24:25 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 13 Dec 2008 13:24:25 -0700 (MST) Message-Id: <20081213.132425.41724046.imp@bsdimp.com> To: max@love2party.net From: Warner Losh In-Reply-To: <200812132045.17207.max@love2party.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> <200812132045.17207.max@love2party.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, current@FreeBSD.org, freebsd-virtualization@FreeBSD.org, freebsd-net@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack 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, 13 Dec 2008 20:27:17 -0000 From: Max Laier Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack Date: Sat, 13 Dec 2008 20:45:16 +0100 > On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: > ... > > This state of having the variables in parallel, global and in the > > container struct, will be maintained for another (short) time until > > the entire virtualization framework is in. This is needed, so that > > all three possible states can be benchmarked from exactly the same > > code changeset. > > > > > > For developers comitting new code or changing code it is important to > > properly add virtualized variables in the way that: > > 1) the globals and externs (if needed) are added/kept in sync as both > > a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate > > container struct + the V_ macro. > > When used somewhere in code one has to use the V_foobarbaz version. > > Is there (an easy) way to have the tinderbox build every other run without > VIMAGE_GLOBALS so that the most obvious error (global available, but not in > the container struct - or the other way around) can be warned about? This actually points out why the 'tinderbox' name is bogus for the universe plus failure: universe builds all the kernels. Tinderbox builds LINT only. Warner From owner-freebsd-net@FreeBSD.ORG Sat Dec 13 23:33:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95C711065673 for ; Sat, 13 Dec 2008 23:33:54 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 19C768FC16 for ; Sat, 13 Dec 2008 23:33:53 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 229719946; Sun, 14 Dec 2008 01:33:52 +0200 Message-ID: <4944465F.1030102@FreeBSD.org> Date: Sun, 14 Dec 2008 01:33:51 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: m_devget() and const buffer 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, 13 Dec 2008 23:33:54 -0000 Hi. Does anybody knows why m_devget() receives non-const char* as first argument? Is there any destructive copy routines used with it? I have searched all the kernel, but haven't found any. May be we could change that? -- Alexander Motin