From owner-freebsd-net@FreeBSD.ORG Sun Aug 7 00:02:12 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A85216A41F for ; Sun, 7 Aug 2005 00:02:12 +0000 (GMT) (envelope-from tilman@arved.at) Received: from 21322530218.direct.eti.at (21322530218.direct.eti.at [213.225.30.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82EDF443A3 for ; Sun, 7 Aug 2005 00:02:11 +0000 (GMT) (envelope-from tilman@arved.at) Received: from jim.arved.de (localhost [127.0.0.1]) by 21322530218.direct.eti.at (8.13.3/8.13.1) with ESMTP id j77029wO047998; Sun, 7 Aug 2005 02:02:09 +0200 (CEST) (envelope-from tilman@arved.at) Received: (from arved@localhost) by jim.arved.de (8.13.3/8.13.1/Submit) id j77029Tv047997; Sun, 7 Aug 2005 02:02:09 +0200 (CEST) (envelope-from tilman@arved.at) X-Authentication-Warning: jim.arved.de: arved set sender to tilman@arved.at using -f Date: Sun, 7 Aug 2005 02:02:09 +0200 From: Tilman Linneweh To: "Bjoern A. Zeeb" Message-ID: <20050807000209.GA31999@arved.at> References: <38bcd230a8da978cf1901ede6ce4eb95@arved.at> 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: IPv6 LOR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2005 00:02:12 -0000 * Bjoern A. Zeeb [2005-08-07 00:20]: > > Today i tried to configure IPv6 on a RELENG_6 box with an axe(4) USB > > NIC. > > > > I got these two traces in my log: > > would you be able to send this w/o lines wrapped and perhaps > also without the syslog line starting. Would be easier to read;) I am sorry, Sleeping on "usbsyn" with the following non-sleepable locks held: exclusive sleep mutex inp (raw6inp) r = 0 (0xc133a9b4) locked @ /usr/RELENG_6/sr c/sys/netinet6/raw_ip6.c:624 exclusive sleep mutex rip r = 0 (0xc079628c) locked @ /usr/RELENG_6/src/sys/neti net6/raw_ip6.c:611 KDB: stack backtrace: kdb_backtrace(2,c15fdc48,c1194780,2,d350b970) at kdb_backtrace+0x29 witness_warn(5,0,c06d85fe,c06cfc71) at witness_warn+0x18e msleep(c23f0600,0,4c,c06cfc71,0) at msleep+0x42 usbd_transfer(c23f0600,d350b9d0,c04d0825,c23f0600,246) at usbd_transfer+0x121 usbd_sync_transfer(c23f0600,246,c074c360,d350b9cc,0) at usbd_sync_transfer+0x11 usbd_do_request_flags_pipe(c1574400,c23e5a80,d350ba28,d350ba5e,0) at usbd_do_req uest_flags_pipe+0x5d usbd_do_request_flags(c1574400,d350ba28,d350ba5e,0,0) at usbd_do_request_flags+0 x20 usbd_do_request(c1574400,d350ba28,d350ba5e) at usbd_do_request+0x1a axe_cmd(c23d4500,200f,0,0,d350ba5e) at axe_cmd+0x74 axe_setmulti(c23d4500,c23b4080,c23b4080,c1564680,c11c9400) at axe_setmulti+0x2f axe_ioctl(c11c9400,80206932,0) at axe_ioctl+0x13e if_delmulti(c11c9400,c23ea640) at if_delmulti+0x199 in6_delmulti(c1fe3bc0) at in6_delmulti+0x4f ip6_freemoptions(c11cb9c0,0) at ip6_freemoptions+0x37 in6_pcbdetach(c133a924,c133a9b4,0,c06ec94e,270) at in6_pcbdetach+0x184 rip6_detach(c14a342c) at rip6_detach+0x96 soclose(c14a342c,c126b5e8,0,d350bb5c,c05045b8) at soclose+0x1e0 soo_close(c126b5e8,c1194780) at soo_close+0x4b fdrop_locked(c126b5e8,c1194780,c1070784,0,c06d4c2e) at fdrop_locked+0x88 fdrop(c126b5e8,c1194780,d350bba8,c053ff84,c06d4c2e) at fdrop+0x24 closef(c126b5e8,c1194780) at closef+0x35f fdfree(c1194780,c15fdd94,0,c06db654,6ac) at fdfree+0x473 exit1(c1194780,100,d350bd30,c0696c87,c1194780) at exit1+0x3f6 exit1(c1194780,d350bd04,1,2,296) at exit1 syscall(3b,3b,3b,0,8057300) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280bd383, esp = 0xbfbfe17c, eb p = 0xbfbfe198 --- lock order reversal 1st 0xc133a9b4 inp (raw6inp) @ /usr/RELENG_6/src/sys/netinet6/raw_ip6.c:624 2nd 0xc0747060 Giant (Giant) @ /usr/RELENG_6/src/sys/kern/kern_synch.c:236 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c07543c0,c0756328,c071d1c4) at kdb_backtrace+0x29 witness_checkorder(c0747060,9,c06d8637,ec) at witness_checkorder+0x564 _mtx_lock_flags(c0747060,0,c06d8637,ec) at _mtx_lock_flags+0x5b msleep(c23f0600,0,4c,c06cfc71,0) at msleep+0x386 usbd_transfer(c23f0600,d350b9d0,c04d0825,c23f0600,246) at usbd_transfer+0x121 usbd_sync_transfer(c23f0600,246,c074c360,d350b9cc,0) at usbd_sync_transfer+0x11 usbd_do_request_flags_pipe(c1574400,c23e5a80,d350ba28,d350ba5e,0) at usbd_do_req uest_flags_pipe+0x5d usbd_do_request_flags(c1574400,d350ba28,d350ba5e,0,0) at usbd_do_request_flags+0 x20 usbd_do_request(c1574400,d350ba28,d350ba5e) at usbd_do_request+0x1a axe_cmd(c23d4500,200f,0,0,d350ba5e) at axe_cmd+0x74 axe_setmulti(c23d4500,c23b4080,c23b4080,c1564680,c11c9400) at axe_setmulti+0x2f axe_ioctl(c11c9400,80206932,0) at axe_ioctl+0x13e if_delmulti(c11c9400,c23ea640) at if_delmulti+0x199 in6_delmulti(c1fe3bc0) at in6_delmulti+0x4f ip6_freemoptions(c11cb9c0,0) at ip6_freemoptions+0x37 in6_pcbdetach(c133a924,c133a9b4,0,c06ec94e,270) at in6_pcbdetach+0x184 rip6_detach(c14a342c) at rip6_detach+0x96 soclose(c14a342c,c126b5e8,0,d350bb5c,c05045b8) at soclose+0x1e0 soo_close(c126b5e8,c1194780) at soo_close+0x4b fdrop_locked(c126b5e8,c1194780,c1070784,0,c06d4c2e) at fdrop_locked+0x88 fdrop(c126b5e8,c1194780,d350bba8,c053ff84,c06d4c2e) at fdrop+0x24 closef(c126b5e8,c1194780) at closef+0x35f fdfree(c1194780,c15fdd94,0,c06db654,6ac) at fdfree+0x473 exit1(c1194780,100,d350bd30,c0696c87,c1194780) at exit1+0x3f6 exit1(c1194780,d350bd04,1,2,296) at exit1 syscall(3b,3b,3b,0,8057300) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f > > From what I had seen this isn't only a LOR but more problems... Well, ping and traceroute and basic http seem to work. From owner-freebsd-net@FreeBSD.ORG Sun Aug 7 00:46:11 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 896FC16A41F for ; Sun, 7 Aug 2005 00:46:11 +0000 (GMT) (envelope-from janm@transactionware.com) Received: from mail.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.FreeBSD.org (Postfix) with SMTP id 9D3B443D48 for ; Sun, 7 Aug 2005 00:46:09 +0000 (GMT) (envelope-from janm@transactionware.com) Received: (qmail 31483 invoked from network); 7 Aug 2005 00:49:58 -0000 Received: from new.transactionware.com (192.168.1.55) by dm.transactionware.com with SMTP; 7 Aug 2005 00:49:58 -0000 Received: (qmail 59631 invoked by uid 1026); 7 Aug 2005 00:46:28 -0000 Received: from 127.0.0.1 by new.transactionware.com (envelope-from , uid 1003) with qmail-scanner-1.25 (spamassassin: 3.0.2. Clear:RC:1(127.0.0.1):. Processed in 2.432876 secs); 07 Aug 2005 00:46:28 -0000 Received: from unknown (HELO JMLAPTOP) (unknown) by unknown with SMTP; 7 Aug 2005 00:46:25 -0000 From: "Jan Mikkelsen" To: Date: Sun, 7 Aug 2005 10:46:22 +1000 Organization: Transactionware Message-ID: <002c01c59ae9$6f3c7de0$0204a8c0@transactionware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Subject: WAN cards: Sangoma vs. Tahoe group X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2005 00:46:11 -0000 Hi, I'm looking using either Sangoma cards or the Tahoe Group cards for connections to a frame relay network (Telstra in Australia, for what it's worth). I'm comparing the Sangoma A101-U to the Tahoe 971 and the Sangoma S5141 to the Tahoe 931. >From looking at the archives, people seem generally happy with Sangoma, but I can't find much on the Tahoe cards and FreeBSD. The software for the Tahoe cards is significantly simpler than the Sangoma Wanpipe stuff. What are the general experiences of these cards? Is anyone actually using the Tahoe cards? Thanks, Jan Mikkelsen janm@transactionware.com From owner-freebsd-net@FreeBSD.ORG Sun Aug 7 03:45:23 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D506716A42A for ; Sun, 7 Aug 2005 03:45:23 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A154B4435A for ; Sun, 7 Aug 2005 03:15:28 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 9192E20067E; Sat, 6 Aug 2005 20:15:28 -0700 (PDT) Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j773FRZQ058997; Sat, 6 Aug 2005 20:15:28 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <42F57CCE.2060804@elischer.org> Date: Sat, 06 Aug 2005 20:15:26 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050424 X-Accept-Language: en, hu MIME-Version: 1.0 To: Jan Mikkelsen References: <002c01c59ae9$6f3c7de0$0204a8c0@transactionware.com> In-Reply-To: <002c01c59ae9$6f3c7de0$0204a8c0@transactionware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: WAN cards: Sangoma vs. Tahoe group X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2005 03:45:24 -0000 Jan Mikkelsen wrote: > Hi, > > I'm looking using either Sangoma cards or the Tahoe Group cards for > connections to a frame relay network (Telstra in Australia, for what it's > worth). > > I'm comparing the Sangoma A101-U to the Tahoe 971 and the Sangoma S5141 to > the Tahoe 931. > >>From looking at the archives, people seem generally happy with Sangoma, but > I can't find much on the Tahoe cards and FreeBSD. The software for the > Tahoe cards is significantly simpler than the Sangoma Wanpipe stuff. > > What are the general experiences of these cards? Is anyone actually using > the Tahoe cards? If you can get a dumb sync card that runs with the sr or ar drivers then FreeBSD has built in frame relay code. > > Thanks, > > Jan Mikkelsen > janm@transactionware.com > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Aug 7 09:01:29 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69FA116A462 for ; Sun, 7 Aug 2005 09:01:29 +0000 (GMT) (envelope-from janm@transactionware.com) Received: from mail.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.FreeBSD.org (Postfix) with SMTP id 59B9C44217 for ; Sun, 7 Aug 2005 08:39:08 +0000 (GMT) (envelope-from janm@transactionware.com) Received: (qmail 41622 invoked from network); 7 Aug 2005 08:42:57 -0000 Received: from new.transactionware.com (192.168.1.55) by dm.transactionware.com with SMTP; 7 Aug 2005 08:42:57 -0000 Received: (qmail 62957 invoked by uid 1026); 7 Aug 2005 08:39:28 -0000 Received: from 127.0.0.1 by new.transactionware.com (envelope-from , uid 1003) with qmail-scanner-1.25 (spamassassin: 3.0.2. Clear:RC:1(127.0.0.1):. Processed in 2.464882 secs); 07 Aug 2005 08:39:28 -0000 Received: from unknown (HELO JMLAPTOP) (unknown) by unknown with SMTP; 7 Aug 2005 08:39:25 -0000 From: "Jan Mikkelsen" To: "'Julian Elischer'" Date: Sun, 7 Aug 2005 18:39:22 +1000 Organization: Transactionware Message-ID: <003701c59b2b$82ff5e00$0204a8c0@transactionware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <42F57CCE.2060804@elischer.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Cc: freebsd-net@freebsd.org Subject: RE: WAN cards: Sangoma vs. Tahoe group X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2005 09:01:29 -0000 Julian Elischer wrote: > Jan Mikkelsen wrote: > > Hi, > > > > I'm looking using either Sangoma cards or the Tahoe Group cards for > > connections to a frame relay network (Telstra in Australia, > for what it's > > worth). > > > > I'm comparing the Sangoma A101-U to the Tahoe 971 and the > Sangoma S5141 to > > the Tahoe 931. > > > >>From looking at the archives, people seem generally happy > with Sangoma, but > > I can't find much on the Tahoe cards and FreeBSD. The > software for the > > Tahoe cards is significantly simpler than the Sangoma Wanpipe stuff. > > > > What are the general experiences of these cards? Is anyone > actually using > > the Tahoe cards? > > If you can get a dumb sync card that runs with the sr or ar drivers > then FreeBSD has built in frame relay code. Yes, I'd like to use the netgraph frame relay code. The Tahoe 931 sync card seems to be about half the price of the other dumb sync cards I could find (eg. Digi, don't have any pricing on the WANic card). I'll take a closer look at what hardware is around. Regards, Jan Mikkelsen janm@transactionware.com From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 10:32:50 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83D3816A41F for ; Mon, 8 Aug 2005 10:32:50 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C354F43D46 for ; Mon, 8 Aug 2005 10:32:49 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 95142 invoked from network); 8 Aug 2005 10:14:50 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Aug 2005 10:14:50 -0000 Message-ID: <42F734D0.6F7387E0@freebsd.org> Date: Mon, 08 Aug 2005 12:32:48 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave+Seddon References: <1123040973.95445.TMDA@seddon.ca> <20050802225518.G53516@odysseus.silby.com> <1123055951.16791.TMDA@seddon.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: running out of mbufs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 10:32:50 -0000 Dave+Seddon wrote: > > Also thanks for the info on the VLAN searching. I think the adjustment you > suggested sounds good, but at bit out of my league. It seems there are > plent of things to tweak in the kernel still. Yes, there are some rough edges. I'm starting to work on them right now. :) > BTW, I'd be interested to know people's thoughts on multiple IP stacks on > FreeBSD. It would be really cool to be able to give a jail it's own IP > stack bound to a VLAN interface. It could then be like a VRF on Cisco. There is a patch doing that for FreeBSD 4.x. However while interesting it is not the way to go. You don't want to have multiple parallel stacks but just multiple routing tables and interface groups one per jail. This gives you the same functionality as Cisco VRF but is far less intrusive to the kernel. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 11:01:59 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 141CB16A41F for ; Mon, 8 Aug 2005 11:01:59 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E3C043D49 for ; Mon, 8 Aug 2005 11:01:58 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j78B1wZj006872 for ; Mon, 8 Aug 2005 11:01:58 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j78B1vbG006866 for freebsd-net@freebsd.org; Mon, 8 Aug 2005 11:01:57 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 8 Aug 2005 11:01:57 GMT Message-Id: <200508081101.j78B1vbG006866@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2005 11:01:59 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 03:37:57 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41C3216A41F for ; Mon, 8 Aug 2005 03:37:57 +0000 (GMT) (envelope-from nhuquang.tran@scavi.com.vn) Received: from mr.vnn.vn (mr.vnn.vn [203.162.4.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5197243D46 for ; Mon, 8 Aug 2005 03:37:52 +0000 (GMT) (envelope-from nhuquang.tran@scavi.com.vn) Received: (qmail 16449 invoked by uid 0); 8 Aug 2005 03:58:49 -0000 Received: from unknown (HELO scavimail.scavi.com.vn) (scavi@[203.113.146.194]) (envelope-sender ) by mr.vnn.vn (qmail-ldap-1.03) with SMTP for ; 8 Aug 2005 03:58:49 -0000 Received: from tnq ([192.168.0.11]) by scavimail.scavi.com.vn with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Aug 2005 10:36:44 +0700 Message-ID: <000c01c59bca$aa163b90$0900000a@SCAVIVN.COM> From: "Tran Nhu Quang" To: Date: Mon, 8 Aug 2005 10:38:38 +0700 MIME-Version: 1.0 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 X-OriginalArrivalTime: 08 Aug 2005 03:36:44.0640 (UTC) FILETIME=[65F85600:01C59BCA] X-Mailman-Approved-At: Mon, 08 Aug 2005 12:24:09 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Serial Console X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 03:37:57 -0000 Hi all, Needing of a console for managing the system, I want to make a serial = console on freebsd. Everything works well except boot message. I cannot = see the whole boot message from serial console until the login prompt = appears. Any experienced-man in freebsd can tell me why and how? Thanks in advanced From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 12:36:31 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FEB816A41F for ; Mon, 8 Aug 2005 12:36:31 +0000 (GMT) (envelope-from gpt@tirloni.org) Received: from srv-03.bs2.com.br (srv-03.bs2.com.br [200.203.183.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id C93B343D45 for ; Mon, 8 Aug 2005 12:36:30 +0000 (GMT) (envelope-from gpt@tirloni.org) Received: from localhost (localhost.bs2.com.br [127.0.0.1]) by srv-03.bs2.com.br (Postfix) with ESMTP id CABA14B1E3; Mon, 8 Aug 2005 09:37:05 -0300 (BRT) Received: from [172.16.12.100] (unknown [201.14.1.190]) by srv-03.bs2.com.br (Postfix) with ESMTP id 2139A4B1BF; Mon, 8 Aug 2005 09:37:05 -0300 (BRT) Message-ID: <42F751C9.6030501@tirloni.org> Date: Mon, 08 Aug 2005 09:36:25 -0300 From: "Giovanni P. Tirloni" User-Agent: Mozilla Thunderbird 1.0.6-1.4.1.centos4 (X11/20050721) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tran Nhu Quang References: <000c01c59bca$aa163b90$0900000a@SCAVIVN.COM> In-Reply-To: <000c01c59bca$aa163b90$0900000a@SCAVIVN.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Serial Console X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 12:36:31 -0000 Tran Nhu Quang wrote: > Hi all, > Needing of a console for managing the system, I want to make a serial console on freebsd. Everything works well except boot message. I cannot see the whole boot message from serial console until the login prompt appears. Any experienced-man in freebsd can tell me why and how? > Thanks in advanced [Should probably be in questions@freebsd.org] You can try: echo "-h" > /boot.config and reboot. If keyboard is attached it'll use it. If not, it'll use serial. Take a look at the boot(8) man page. -- Giovanni P. Tirloni / gpt@tirloni.org From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 12:56:59 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D3E516A41F; Mon, 8 Aug 2005 12:56:59 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id D969243D45; Mon, 8 Aug 2005 12:56:58 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id B1559C0C8; Mon, 8 Aug 2005 14:56:57 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 0984F405B; Mon, 8 Aug 2005 14:57:13 +0200 (CEST) Date: Mon, 8 Aug 2005 14:57:12 +0200 From: Jeremie Le Hen To: Andre Oppermann Message-ID: <20050808125712.GI45385@obiwan.tataz.chchile.org> References: <1123040973.95445.TMDA@seddon.ca> <20050802225518.G53516@odysseus.silby.com> <1123055951.16791.TMDA@seddon.ca> <42F734D0.6F7387E0@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42F734D0.6F7387E0@freebsd.org> User-Agent: Mutt/1.5.9i Cc: Dave+Seddon , freebsd-net@freebsd.org Subject: Re: running out of mbufs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 12:56:59 -0000 Andre, > There is a patch doing that for FreeBSD 4.x. However while interesting > it is not the way to go. You don't want to have multiple parallel stacks > but just multiple routing tables and interface groups one per jail. This > gives you the same functionality as Cisco VRF but is far less intrusive > to the kernel. By "interface groups", do you mean the same ones as OpenBSD ? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 13:20:55 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1B3916A41F for ; Mon, 8 Aug 2005 13:20:55 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1769543D48 for ; Mon, 8 Aug 2005 13:20:54 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 96246 invoked from network); 8 Aug 2005 13:02:54 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Aug 2005 13:02:54 -0000 Message-ID: <42F75C34.48F433E6@freebsd.org> Date: Mon, 08 Aug 2005 15:20:52 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeremie Le Hen References: <1123040973.95445.TMDA@seddon.ca> <20050802225518.G53516@odysseus.silby.com> <1123055951.16791.TMDA@seddon.ca> <42F734D0.6F7387E0@freebsd.org> <20050808125712.GI45385@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: running out of mbufs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 13:20:55 -0000 Jeremie Le Hen wrote: > > Andre, > > > There is a patch doing that for FreeBSD 4.x. However while interesting > > it is not the way to go. You don't want to have multiple parallel stacks > > but just multiple routing tables and interface groups one per jail. This > > gives you the same functionality as Cisco VRF but is far less intrusive > > to the kernel. > > By "interface groups", do you mean the same ones as OpenBSD ? I don't know. What is the definition of an OpenBSD interface group? -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 15:46:02 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEBA316A41F; Mon, 8 Aug 2005 15:46:02 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 170F543D49; Mon, 8 Aug 2005 15:46:02 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-1.free.fr (Postfix) with ESMTP id 2EC3F319EAA; Mon, 8 Aug 2005 17:46:01 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 43C64405B; Mon, 8 Aug 2005 17:46:14 +0200 (CEST) Date: Mon, 8 Aug 2005 17:46:14 +0200 From: Jeremie Le Hen To: Andre Oppermann Message-ID: <20050808154614.GJ45385@obiwan.tataz.chchile.org> References: <1123040973.95445.TMDA@seddon.ca> <20050802225518.G53516@odysseus.silby.com> <1123055951.16791.TMDA@seddon.ca> <42F734D0.6F7387E0@freebsd.org> <20050808125712.GI45385@obiwan.tataz.chchile.org> <42F75C34.48F433E6@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42F75C34.48F433E6@freebsd.org> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org, Jeremie Le Hen Subject: Re: running out of mbufs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 15:46:02 -0000 Hi Andre, > > By "interface groups", do you mean the same ones as OpenBSD ? > > I don't know. What is the definition of an OpenBSD interface group? >From ifconfig(8) manual page : %%% group group-name Assign the interface to a ``group''. Any interface can be in multiple groups. Cloned interfaces are members of their interface family group by default. For example, a PPP interface such as ppp0 is a member of the PPP interface family group, ppp. The interface(s) the default route(s) point to are mem- bers of the egress interface group. %%% This article [1] explains better what interface groups are, see the "Interface group" section (according to w3m: line 182/422 (43%)) [1] http://kerneltrap.org/node/5190 Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 15:58:58 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF39D16A41F; Mon, 8 Aug 2005 15:58:58 +0000 (GMT) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4908F43D48; Mon, 8 Aug 2005 15:58:58 +0000 (GMT) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id E7C669B6C4; Mon, 8 Aug 2005 18:00:44 +0200 (CEST) Received: from [127.0.0.1] (imunes.tel.fer.hr [161.53.19.8]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 54EB39B762; Mon, 8 Aug 2005 18:00:35 +0200 (CEST) From: Marko Zec To: freebsd-net@freebsd.org Date: Mon, 8 Aug 2005 17:57:47 +0200 User-Agent: KMail/1.7.2 References: <1123040973.95445.TMDA@seddon.ca> <1123055951.16791.TMDA@seddon.ca> <42F734D0.6F7387E0@freebsd.org> In-Reply-To: <42F734D0.6F7387E0@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508081757.47499.zec@icir.org> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.0.2 Cc: Dave+Seddon , Andre Oppermann Subject: Re: running out of mbufs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 15:58:58 -0000 On Monday 08 August 2005 12:32, Andre Oppermann wrote: > Dave+Seddon wrote: > > BTW, I'd be interested to know people's thoughts on multiple IP > > stacks on FreeBSD. It would be really cool to be able to give a > > jail it's own IP stack bound to a VLAN interface. It could then be > > like a VRF on Cisco. > > There is a patch doing that for FreeBSD 4.x. However while > interesting it is not the way to go. You don't want to have multiple > parallel stacks but just multiple routing tables and interface groups > one per jail. This gives you the same functionality as Cisco VRF but > is far less intrusive to the kernel. Andre, the stack virtualization framework for 4.x is based precisely on introducing multiple routing tables and interface groups. In order to cleanly implement support for multiple independent interface groups, one has to touch both the link and network layers, not forgetting the ARP stuff... and in no time you have ended up with a huge and intrusive diff against the original network stack code. So I see no point in pretending we could get such a functionality for free, i.e. with only a negligible intrusiveness to the kernel code. A more appropriate question would be whether the potential benefits of having multiple stack state instances could outweight the trouble and damage associated with the scope of required modifications to the kernel code tree. Only if we could get an affirmative answer to that question it would make sense to start thinking / debating on the most appropriate methodology to (re)implement the multiple stacks framework. Cheers, Marko From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 16:12:19 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB39616A423 for ; Mon, 8 Aug 2005 16:12:19 +0000 (GMT) (envelope-from net@dino.sk) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C7A543D5D for ; Mon, 8 Aug 2005 16:12:18 +0000 (GMT) (envelope-from net@dino.sk) Received: from home.dino.sk ([213.215.74.194]) (AUTH: LOGIN milan) by bsd.dino.sk with esmtp; Mon, 08 Aug 2005 18:12:08 +0200 id 00000133.42F78458.000003CE From: Milan Obuch To: freebsd-net@freebsd.org Date: Mon, 8 Aug 2005 18:11:44 +0200 User-Agent: KMail/1.8 References: <1123040973.95445.TMDA@seddon.ca> <42F734D0.6F7387E0@freebsd.org> <200508081757.47499.zec@icir.org> In-Reply-To: <200508081757.47499.zec@icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508081811.45126.net@dino.sk> Subject: Re: running out of mbufs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 16:12:20 -0000 On Monday 08 August 2005 17:57, Marko Zec wrote: > On Monday 08 August 2005 12:32, Andre Oppermann wrote: > > Dave+Seddon wrote: > > > BTW, I'd be interested to know people's thoughts on multiple IP > > > stacks on FreeBSD. It would be really cool to be able to give a > > > jail it's own IP stack bound to a VLAN interface. It could then be > > > like a VRF on Cisco. > > > > There is a patch doing that for FreeBSD 4.x. However while > > interesting it is not the way to go. You don't want to have multiple > > parallel stacks but just multiple routing tables and interface groups > > one per jail. This gives you the same functionality as Cisco VRF but > > is far less intrusive to the kernel. > > Andre, > > the stack virtualization framework for 4.x is based precisely on > introducing multiple routing tables and interface groups. In order to > cleanly implement support for multiple independent interface groups, > one has to touch both the link and network layers, not forgetting the > ARP stuff... and in no time you have ended up with a huge and intrusive > diff against the original network stack code. > > So I see no point in pretending we could get such a functionality for > free, i.e. with only a negligible intrusiveness to the kernel code. A > more appropriate question would be whether the potential benefits of > having multiple stack state instances could outweight the trouble and > damage associated with the scope of required modifications to the > kernel code tree. Only if we could get an affirmative answer to that > question it would make sense to start thinking / debating on the most > appropriate methodology to (re)implement the multiple stacks framework. > > Cheers, > > Marko I did use Marko's patch for some time with great success. I feel it would be really great to be able to use something similar in new releases. It is really like cisco's vrf. I used it for multi-VPN monitoring/management. There is nothing comparable currently - user mode linux is too resource consuming, other methods are not so easy to use... If anyone knows the way to put virtual stacks into newer FreeBSD, I am eager to test it. For my current task (multi-VPN monitoring/management, again) I will use this, again. Regards, Milan From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 16:47:07 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 216D516A41F for ; Mon, 8 Aug 2005 16:47:07 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAD4143D49 for ; Mon, 8 Aug 2005 16:47:05 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 97755 invoked from network); 8 Aug 2005 16:29:04 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Aug 2005 16:29:04 -0000 Message-ID: <42F78C87.5EB79CBC@freebsd.org> Date: Mon, 08 Aug 2005 18:47:03 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Marko Zec References: <1123040973.95445.TMDA@seddon.ca> <1123055951.16791.TMDA@seddon.ca> <42F734D0.6F7387E0@freebsd.org> <200508081757.47499.zec@icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Dave+Seddon , freebsd-net@freebsd.org Subject: Re: running out of mbufs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 16:47:07 -0000 Marko Zec wrote: > > On Monday 08 August 2005 12:32, Andre Oppermann wrote: > > Dave+Seddon wrote: > > > BTW, I'd be interested to know people's thoughts on multiple IP > > > stacks on FreeBSD. It would be really cool to be able to give a > > > jail it's own IP stack bound to a VLAN interface. It could then be > > > like a VRF on Cisco. > > > > There is a patch doing that for FreeBSD 4.x. However while > > interesting it is not the way to go. You don't want to have multiple > > parallel stacks but just multiple routing tables and interface groups > > one per jail. This gives you the same functionality as Cisco VRF but > > is far less intrusive to the kernel. > > Andre, > > the stack virtualization framework for 4.x is based precisely on > introducing multiple routing tables and interface groups. In order to > cleanly implement support for multiple independent interface groups, > one has to touch both the link and network layers, not forgetting the > ARP stuff... and in no time you have ended up with a huge and intrusive > diff against the original network stack code. While your stack indexing approach is interesting I don't think it is the way we should take for the generic FreeBSD. There are better ways to implement a less limiting superset of the desired functionality. And the ARP is almost done, I have to review the code and then it goes into -current. > So I see no point in pretending we could get such a functionality for > free, i.e. with only a negligible intrusiveness to the kernel code. A > more appropriate question would be whether the potential benefits of > having multiple stack state instances could outweight the trouble and > damage associated with the scope of required modifications to the > kernel code tree. Only if we could get an affirmative answer to that > question it would make sense to start thinking / debating on the most > appropriate methodology to (re)implement the multiple stacks framework. Having multiple stacks duplicates a lot of structures for each stack which don't have to be duplicated. With your approach you need a new jail for every new stack. In each jail you have to run a new instance of a routing daemon (if you do routing). And it precludes having one routing daemon managing multiple routing tables. While removing one limitation you create some new ones in addition to the complexity. What I have in mind is a redesign of some parts of the stack as such. I have got funding to work on this through my fundraise of two weeks ago. Work is about to start later this week. I will provide a more detailed design document for discussion and review by the FreeBSD community in a few days. It will include features such as multiple hierarchical routing tables (bound to jails or not), interface groups, virtual interfaces belonging to one or more interface groups, policy routing (based on source address/interface), multi-path routing, a reworked routing-socket and some more stuff. I recommend waiting for the design document for further discussions and jumping to any conclusions. :) -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 18:39:47 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B547116A41F for ; Mon, 8 Aug 2005 18:39:47 +0000 (GMT) (envelope-from steve@nomad.lets.net) Received: from hornet.wiznet.ca (hornet.wiznet.ca [216.138.223.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A3BC43D48 for ; Mon, 8 Aug 2005 18:39:47 +0000 (GMT) (envelope-from steve@nomad.lets.net) Received: from nomad.lets.net (toronto-hs-216-138-220-74.s-ip.magma.ca [216.138.220.74]) by hornet.wiznet.ca (Postfix) with SMTP id 2976C1015D7 for ; Mon, 8 Aug 2005 14:39:46 -0400 (EDT) Received: (qmail 14322 invoked by uid 1008); 8 Aug 2005 19:52:14 -0000 Date: Mon, 8 Aug 2005 15:52:14 -0400 From: Steve Shorter To: freebsd-net@freebsd.org Message-ID: <20050808195214.GA14241@nomad.lets.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: 1000BaseSX 1000BaseLX confusion? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 18:39:47 -0000 Howdy! I was wondering how come the listed media types supported by sk(4) and em(4) is only 1000BaseSX. Even for single mode 1000BaseLX NICs such as sk 9841 and Intel PWLA8490LX, ifconfig show the media type as 1000BaseSX. Though the NIC appears to operate in single mode connected to a LX switch port ok. From what I can understand SX supports only multimode fibre and LX supports both. How come there isn't 1000BaseLX for a displayed media type, and is it really single mode? thanx - steve From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 19:00:26 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97C2416A41F for ; Mon, 8 Aug 2005 19:00:26 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F86A43D46 for ; Mon, 8 Aug 2005 19:00:25 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Aug 2005 15:00:24 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id D837B13633; Mon, 8 Aug 2005 15:00:24 -0400 (EDT) Date: Mon, 8 Aug 2005 15:00:24 -0400 From: Ed Maste To: freebsd-net@freebsd.org Message-ID: <20050808190024.GA4843@sandvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 08 Aug 2005 19:00:25.0008 (UTC) FILETIME=[6F156300:01C59C4B] Subject: Multicast locking LOR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 19:00:26 -0000 I built a vanilla (i.e. without local patches) kernel with the recent multicast locking changes, and got the following LOR: Lock order reversal 1st 0xa26ffaec inp (udpinp) @ /d2/emaste/cvs_mcast/src/sys/netinet/udp_usrreq.c:762 2nd 0xa07ebf60 in_multi_mtx (in_multi_mtx) @ d2/emaste/cvs_mcast/src/sys/netinet/ip_output.c:294 KDB: stack backtrace: kdb_backtrace(0,ffffffff,a07ab3b8,a07ab480,a075e1e0) at 0xa0586a95 = kdb_backtrace+0x29 witness_checkorder(a07ebf60,9,a0729936,126) at 0xa0590c60 = witness_checkorder+0x564 _mtx_lock_flags(a07ebf60,0,a0729936,126,0) at 0xa0566610 = _mtx_lock_flags+0x60 ip_output(a2706a00,0,c8463b08,20,a26a9500) at 0xa05f7d8a = ip_output+0x3fe udp_output(a26ffa5c,a2706a00,0,0,a29b9900) at 0xa060754f = udp_output+0x4a7 udp_send(a29b2ca0,0,a2911900,0,0) at 0xa0607abe = udp_send+0x1a sosend(a29b2ca0,0,c8463cbc,a2911900,0) at 0xa05a8287 = sosend+0x5e3 soo_write(a26d79d8,c8463cbc,a2605800,0,a29b9900) at 0xa059810a = soo_write+0x46 dofilewrite(a29b9900,c,a26d79d8,c8463cbc,ffffffff) at 0xa0592903 = dofilewrite+0x77 kern_writev(a29b9900,c,c8463cbc,842b12a,0) at 0xa05927a7 = kern_writev+0x3b write(a29b9900,c8463d04,3,0,282) at 0xa05926cd = write+0x45 syscall(685a003b,804003b,9fbf003b,821c400,f6) at 0xa06c75b3 = syscall+0x25b Xint0x80_syscall() at 0xa06b4ccf = Xint0x80_syscall+0x1f --- syscall (4, FreeBSD ELF32, write), eip = 0x681e31af, esp = 0x9f9ff9fc, ebp = 0x9f9ffa18 --- -- Ed Maste, Sandvine Incorporated From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 19:13:43 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9A7C16A41F for ; Mon, 8 Aug 2005 19:13:43 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from rms06.rommon.net (rms06.rommon.net [212.54.5.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 926E643D46 for ; Mon, 8 Aug 2005 19:13:42 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.234] (dyn234.helenius.fi [193.64.42.234]) by rms06.rommon.net (Postfix) with ESMTP id 43A1733C1B; Mon, 8 Aug 2005 22:13:31 +0300 (EEST) Message-ID: <42F7AEDC.2000002@he.iki.fi> Date: Mon, 08 Aug 2005 22:13:32 +0300 From: Petri Helenius User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Shorter References: <20050808195214.GA14241@nomad.lets.net> In-Reply-To: <20050808195214.GA14241@nomad.lets.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 1000BaseSX 1000BaseLX confusion? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 19:13:44 -0000 Steve Shorter wrote: >Howdy! > > I was wondering how come the listed media types supported >by sk(4) and em(4) is only 1000BaseSX. Even for single mode >1000BaseLX NICs such as sk 9841 and Intel PWLA8490LX, ifconfig >show the media type as 1000BaseSX. Though the NIC appears to operate in >single mode connected to a LX switch port ok. > > From what I can understand SX supports only multimode fibre >and LX supports both. > > How come there isn't 1000BaseLX for a displayed media type, and >is it really single mode? > > The driver does not make a difference between the optics installed on the card. Maybe it should? Pete From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 19:14:25 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D71316A41F for ; Mon, 8 Aug 2005 19:14:25 +0000 (GMT) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (e-gerbil.net [69.31.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC7C843D48 for ; Mon, 8 Aug 2005 19:14:24 +0000 (GMT) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@localhost.e-gerbil.net [127.0.0.1]) by overlord.e-gerbil.net (8.13.3/8.13.3) with ESMTP id j78JELpN062167; Mon, 8 Aug 2005 15:14:21 -0400 (EDT) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.13.3/8.13.3/Submit) id j78JELFL062165; Mon, 8 Aug 2005 15:14:21 -0400 (EDT) (envelope-from ras) Date: Mon, 8 Aug 2005 15:14:20 -0400 From: Richard A Steenbergen To: Steve Shorter Message-ID: <20050808191420.GZ8847@overlord.e-gerbil.net> References: <20050808195214.GA14241@nomad.lets.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050808195214.GA14241@nomad.lets.net> User-Agent: Mutt/1.5.6i Cc: freebsd-net@freebsd.org Subject: Re: 1000BaseSX 1000BaseLX confusion? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 19:14:25 -0000 On Mon, Aug 08, 2005 at 03:52:14PM -0400, Steve Shorter wrote: > Howdy! > > I was wondering how come the listed media types supported > by sk(4) and em(4) is only 1000BaseSX. Even for single mode > 1000BaseLX NICs such as sk 9841 and Intel PWLA8490LX, ifconfig > show the media type as 1000BaseSX. Though the NIC appears to operate in > single mode connected to a LX switch port ok. > > From what I can understand SX supports only multimode fibre > and LX supports both. > > How come there isn't 1000BaseLX for a displayed media type, and > is it really single mode? Probably because no one ever bothered writing in support for it. :) As far as the fbsd driver is concerned, it is all the same thing. You can't switch the optics in software, it is what it is based on the optical component that was physically installed on the card (ignoring pluggables for the moment :P). That makes it purely a cosmetic issue. But that said: # find . | xargs grep IFM_1000_LX ./net/if_media.h:#define IFM_1000_LX 14 /* 1000baseLX - single-mode fiber */ ./net/if_media.h: { IFM_1000_LX, "1000baseLX" }, \ ./net/if_media.h: { IFM_1000_LX, "1000LX" }, \ ./pci/if_sk.c: sc->sk_pmd = IFM_1000_LX; ./pci/if_sk.c: case IFM_1000_LX: For shame. :) There are a lot of optics out there besides SX and LX, or besides SR and LR in 10GE. I know nothing about fbsd's level of support for SFP based cards, but I would imagine it isn't going to be good based on the above. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 19:46:50 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42C3B16A41F for ; Mon, 8 Aug 2005 19:46:50 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61CCC43D46 for ; Mon, 8 Aug 2005 19:46:49 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Aug 2005 15:46:48 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 5724813633; Mon, 8 Aug 2005 15:46:48 -0400 (EDT) Date: Mon, 8 Aug 2005 15:46:48 -0400 From: Ed Maste To: freebsd-net@freebsd.org Message-ID: <20050808194648.GB4843@sandvine.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="s/l3CgOIzMHHjg/5" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 08 Aug 2005 19:46:48.0510 (UTC) FILETIME=[EA2E15E0:01C59C51] Subject: [PATCH] Minor cleanup of inline declaration for netgraph.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 19:46:50 -0000 --s/l3CgOIzMHHjg/5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline We build one of our netgraph modules with -W, which causes GCC to emit "warning: `inline' is not at beginning of declaration" for netgraph.h. It's pretty trivial, but the attached patch cleans this up so it's consistent across all of the functions in netgraph.h. -- Ed Maste, Sandvine Incorporated --s/l3CgOIzMHHjg/5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netgraph.h.patch" Index: sys/netgraph/netgraph.h =================================================================== RCS file: /usr/cvs/src/sys/netgraph/netgraph.h,v retrieving revision 1.58 diff -u -3 -r1.58 netgraph.h --- sys/netgraph/netgraph.h 2 Aug 2005 20:06:48 -0000 1.58 +++ sys/netgraph/netgraph.h 8 Aug 2005 19:31:07 -0000 @@ -175,7 +175,7 @@ int line); static __inline void _ng_hook_force_queue(hook_p hook, char * file, int line); -static void __inline +static __inline void _chkhook(hook_p hook, char *file, int line) { if (hook->hk_magic != HK_MAGIC) { @@ -407,7 +407,7 @@ #ifdef NETGRAPH_DEBUG /*----------------------------------------------*/ void dumpnode(node_p node, char *file, int line); -static void __inline _chknode(node_p node, char *file, int line); +static __inline void _chknode(node_p node, char *file, int line); static __inline char * _ng_node_name(node_p node, char *file, int line); static __inline int _ng_node_has_name(node_p node, char *file, int line); static __inline ng_ID_t _ng_node_id(node_p node, char *file, int line); @@ -425,7 +425,7 @@ ng_fn_eachhook *fn, void *arg, char *file, int line); static __inline void _ng_node_revive(node_p node, char *file, int line); -static void __inline +static __inline void _chknode(node_p node, char *file, int line) { if (node->nd_magic != ND_MAGIC) { --s/l3CgOIzMHHjg/5-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 20:09:39 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18BC316A41F for ; Mon, 8 Aug 2005 20:09:39 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEB5B43D48 for ; Mon, 8 Aug 2005 20:09:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id A7DF01F49D4; Mon, 8 Aug 2005 13:09:38 -0700 (PDT) Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j78K9cxD084313; Mon, 8 Aug 2005 13:09:38 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <42F7BC01.80102@elischer.org> Date: Mon, 08 Aug 2005 13:09:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050424 X-Accept-Language: en, hu MIME-Version: 1.0 To: Ed Maste References: <20050808194648.GB4843@sandvine.com> In-Reply-To: <20050808194648.GB4843@sandvine.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] Minor cleanup of inline declaration for netgraph.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 20:09:39 -0000 Ed Maste wrote: > We build one of our netgraph modules with -W, which causes GCC > to emit "warning: `inline' is not at beginning of declaration" for > netgraph.h. It's pretty trivial, but the attached patch cleans this > up so it's consistent across all of the functions in netgraph.h. committed to -current. Will MFC to other branches in 1 week if possible > > -- > Ed Maste, Sandvine Incorporated > > > ------------------------------------------------------------------------ > > Index: sys/netgraph/netgraph.h > =================================================================== > RCS file: /usr/cvs/src/sys/netgraph/netgraph.h,v > retrieving revision 1.58 > diff -u -3 -r1.58 netgraph.h > --- sys/netgraph/netgraph.h 2 Aug 2005 20:06:48 -0000 1.58 > +++ sys/netgraph/netgraph.h 8 Aug 2005 19:31:07 -0000 > @@ -175,7 +175,7 @@ > int line); > static __inline void _ng_hook_force_queue(hook_p hook, char * file, int line); > > -static void __inline > +static __inline void > _chkhook(hook_p hook, char *file, int line) > { > if (hook->hk_magic != HK_MAGIC) { > @@ -407,7 +407,7 @@ > > #ifdef NETGRAPH_DEBUG /*----------------------------------------------*/ > void dumpnode(node_p node, char *file, int line); > -static void __inline _chknode(node_p node, char *file, int line); > +static __inline void _chknode(node_p node, char *file, int line); > static __inline char * _ng_node_name(node_p node, char *file, int line); > static __inline int _ng_node_has_name(node_p node, char *file, int line); > static __inline ng_ID_t _ng_node_id(node_p node, char *file, int line); > @@ -425,7 +425,7 @@ > ng_fn_eachhook *fn, void *arg, char *file, int line); > static __inline void _ng_node_revive(node_p node, char *file, int line); > > -static void __inline > +static __inline void > _chknode(node_p node, char *file, int line) > { > if (node->nd_magic != ND_MAGIC) { > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Aug 8 21:31:46 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADA9016A41F for ; Mon, 8 Aug 2005 21:31:46 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B6F843D46 for ; Mon, 8 Aug 2005 21:31:46 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 908F446B13; Mon, 8 Aug 2005 17:31:45 -0400 (EDT) Date: Mon, 8 Aug 2005 22:34:53 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ed Maste In-Reply-To: <20050808190024.GA4843@sandvine.com> Message-ID: <20050808223106.P67598@fledge.watson.org> References: <20050808190024.GA4843@sandvine.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Multicast locking LOR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 21:31:46 -0000 On Mon, 8 Aug 2005, Ed Maste wrote: > I built a vanilla (i.e. without local patches) kernel with > the recent multicast locking changes, and got the following > LOR: Ed, Could you add a hard-coded entry to WITNESS to place the udpinp lock before the in_multi_mtx in the lock order, and let me know which path resulted in the opposite order from this one? In theory, pcb locks should appear before the inet multicast address lock. The only case I'm aware of right now that might cause problems is IGMP's call into ip_output() to send an IGMP message, and ip_output() could hit ipfw/ pf/etc acquiring an inpcb lock. There might also be recursion back into ip_input() due to multicast, which is the case I'm curious about. I had been wondering if we need to defer the ip_output() call for IGMP to a separate worker context, and assuming you're hitting a case related to that, I think that we'll need to. There was already a warning about potential recursion there in the IGMP source. Thanks, Robert N M Watson > > Lock order reversal > 1st 0xa26ffaec inp (udpinp) @ /d2/emaste/cvs_mcast/src/sys/netinet/udp_usrreq.c:762 > 2nd 0xa07ebf60 in_multi_mtx (in_multi_mtx) @ d2/emaste/cvs_mcast/src/sys/netinet/ip_output.c:294 > KDB: stack backtrace: > kdb_backtrace(0,ffffffff,a07ab3b8,a07ab480,a075e1e0) at 0xa0586a95 = kdb_backtrace+0x29 > witness_checkorder(a07ebf60,9,a0729936,126) at 0xa0590c60 = witness_checkorder+0x564 > _mtx_lock_flags(a07ebf60,0,a0729936,126,0) at 0xa0566610 = _mtx_lock_flags+0x60 > ip_output(a2706a00,0,c8463b08,20,a26a9500) at 0xa05f7d8a = ip_output+0x3fe > udp_output(a26ffa5c,a2706a00,0,0,a29b9900) at 0xa060754f = udp_output+0x4a7 > udp_send(a29b2ca0,0,a2911900,0,0) at 0xa0607abe = udp_send+0x1a > sosend(a29b2ca0,0,c8463cbc,a2911900,0) at 0xa05a8287 = sosend+0x5e3 > soo_write(a26d79d8,c8463cbc,a2605800,0,a29b9900) at 0xa059810a = soo_write+0x46 > dofilewrite(a29b9900,c,a26d79d8,c8463cbc,ffffffff) at 0xa0592903 = dofilewrite+0x77 > kern_writev(a29b9900,c,c8463cbc,842b12a,0) at 0xa05927a7 = kern_writev+0x3b > write(a29b9900,c8463d04,3,0,282) at 0xa05926cd = write+0x45 > syscall(685a003b,804003b,9fbf003b,821c400,f6) at 0xa06c75b3 = syscall+0x25b > Xint0x80_syscall() at 0xa06b4ccf = Xint0x80_syscall+0x1f > --- syscall (4, FreeBSD ELF32, write), eip = 0x681e31af, esp = 0x9f9ff9fc, ebp = 0x9f9ffa18 --- > > -- > Ed Maste, Sandvine Incorporated > _______________________________________________ > 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 Aug 8 21:31:47 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A57616A41F for ; Mon, 8 Aug 2005 21:31:47 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44AB443D45 for ; Mon, 8 Aug 2005 21:31:46 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 99828 invoked from network); 8 Aug 2005 21:13:42 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Aug 2005 21:13:42 -0000 Message-ID: <42F7CF40.FC36E5D3@freebsd.org> Date: Mon, 08 Aug 2005 23:31:44 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeremie Le Hen References: <1123040973.95445.TMDA@seddon.ca> <20050802225518.G53516@odysseus.silby.com> <1123055951.16791.TMDA@seddon.ca> <42F734D0.6F7387E0@freebsd.org> <20050808125712.GI45385@obiwan.tataz.chchile.org> <42F75C34.48F433E6@freebsd.org> <20050808154614.GJ45385@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: running out of mbufs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 21:31:47 -0000 Jeremie Le Hen wrote: > > Hi Andre, > > > > By "interface groups", do you mean the same ones as OpenBSD ? > > > > I don't know. What is the definition of an OpenBSD interface group? > > >From ifconfig(8) manual page : > %%% > group group-name > Assign the interface to a ``group''. Any interface can > be in multiple groups. > > Cloned interfaces are members of their interface family > group by default. For example, a PPP interface such as > ppp0 is a member of the PPP interface family group, ppp. > The interface(s) the default route(s) point to are mem- > bers of the egress interface group. > %%% > > This article [1] explains better what interface groups are, see the > "Interface group" section (according to w3m: line 182/422 (43%)) > > [1] http://kerneltrap.org/node/5190 Yea, I guess we're going to support that. If just to make the pf porters happy. For routing tables work and such I'd rather compare a pointer or int than a string but I'm sure we manage to find a clean way to get both. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 23:56:02 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E36D16A41F for ; Mon, 8 Aug 2005 23:56:02 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: from seddon.ca (seddon.ca [203.209.212.18]) by mx1.FreeBSD.org (Postfix) with SMTP id A875F43D49 for ; Mon, 8 Aug 2005 23:56:01 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: (qmail 93703 invoked by uid 89); 8 Aug 2005 23:55:58 -0000 Received: by seddon.ca (tmda-sendmail, from uid 89); Tue, 09 Aug 2005 09:55:56 +1000 (EST) References: <1123040973.95445.TMDA@seddon.ca> <1123055951.16791.TMDA@seddon.ca> <42F734D0.6F7387E0@freebsd.org> <200508081757.47499.zec@icir.org> <42F78C87.5EB79CBC@freebsd.org> In-Reply-To: <42F78C87.5EB79CBC@freebsd.org> To: Andre Oppermann Date: Tue, 09 Aug 2005 09:55:55 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: <1123545356.93682.TMDA@seddon.ca> X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Dave+Seddon Cc: freebsd-net@freebsd.org Subject: Re: running out of mbufs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave+Seddon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2005 23:56:02 -0000 Greetings, It=E2=80=99s very cool to hear you guys are interested in separate routin= g. > Having multiple stacks duplicates a lot of structures for each stack > which don't have to be duplicated. With your approach you need a new > jail for every new stack. In each jail you have to run a new instance > of a routing daemon (if you do routing). And it precludes having one > routing daemon managing multiple routing tables. While removing one > limitation you create some new ones in addition to the complexity. Running multiple routing daemons isn=E2=80=99t too much of a problem thou= gh. The memory size isn=E2=80=99t usually very high, and it is more likely to be = secure if the daemons are separate. If somebody was going to run a large instance = of routing they should probably use a router, not a unix box. Regards, Dave Seddon From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 09:05:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4ECD916A41F; Tue, 9 Aug 2005 09:05:18 +0000 (GMT) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id E99C143D46; Tue, 9 Aug 2005 09:05:16 +0000 (GMT) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 01CBA9B762; Tue, 9 Aug 2005 11:07:22 +0200 (CEST) Received: from [127.0.0.1] (imunes.tel.fer.hr [161.53.19.8]) by xaqua.tel.fer.hr (Postfix) with ESMTP id EDC659B6C4; Tue, 9 Aug 2005 11:07:13 +0200 (CEST) From: Marko Zec To: freebsd-net@freebsd.org Date: Tue, 9 Aug 2005 11:04:06 +0200 User-Agent: KMail/1.7.2 References: <1123040973.95445.TMDA@seddon.ca> <200508081757.47499.zec@icir.org> <42F78C87.5EB79CBC@freebsd.org> In-Reply-To: <42F78C87.5EB79CBC@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508091104.06572.zec@icir.org> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.0.2 Cc: Dave+Seddon , Andre Oppermann Subject: Re: running out of mbufs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 09:05:18 -0000 On Monday 08 August 2005 18:47, Andre Oppermann wrote: > Marko Zec wrote: > > On Monday 08 August 2005 12:32, Andre Oppermann wrote: > > > Dave+Seddon wrote: > > > > BTW, I'd be interested to know people's thoughts on multiple IP > > > > stacks on FreeBSD. It would be really cool to be able to give > > > > a jail it's own IP stack bound to a VLAN interface. It could > > > > then be like a VRF on Cisco. > > > > > > There is a patch doing that for FreeBSD 4.x. However while > > > interesting it is not the way to go. You don't want to have > > > multiple parallel stacks but just multiple routing tables and > > > interface groups one per jail. This gives you the same > > > functionality as Cisco VRF but is far less intrusive to the > > > kernel. > > > > Andre, > > > > the stack virtualization framework for 4.x is based precisely on > > introducing multiple routing tables and interface groups. In order > > to cleanly implement support for multiple independent interface > > groups, one has to touch both the link and network layers, not > > forgetting the ARP stuff... and in no time you have ended up with a > > huge and intrusive diff against the original network stack code. > > While your stack indexing approach is interesting I don't think it is > the way we should take for the generic FreeBSD. There are better > ways to implement a less limiting superset of the desired > functionality. Andre, there's no doubt almost any idea or particularly software can be improved. Could you provide a more elaborate argumentation to your claim the network stack cloning concept is so severely limited that it has no place to search for in the future of FreeBSD? And what exactly did you mean by a "stack indexing approach"? > And the ARP is almost done, I have to review the code > and then it goes into -current. While having a per-interface ARP logic is certainly a nice feature, this alone will not solve much with regards to introducing multiple independent interface groups. You will still most probably have to revisit the ARP code once you start introducing non-global interface lists in the kernel. > > So I see no point in pretending we could get such a functionality > > for free, i.e. with only a negligible intrusiveness to the kernel > > code. A more appropriate question would be whether the potential > > benefits of having multiple stack state instances could outweight > > the trouble and damage associated with the scope of required > > modifications to the kernel code tree. Only if we could get an > > affirmative answer to that question it would make sense to start > > thinking / debating on the most appropriate methodology to > > (re)implement the multiple stacks framework. > > Having multiple stacks duplicates a lot of structures for each stack > which don't have to be duplicated. With your approach you need a new > jail for every new stack. In each jail you have to run a new > instance of a routing daemon (if you do routing). And it precludes > having one routing daemon managing multiple routing tables. While > removing one limitation you create some new ones in addition to the > complexity. Bemusingly, none of the above claims are true. A new jail for each network stack instance is NOT required. Inside the kernel what could be considered "per-jail" and per-network stack structures are cleanly separated and independent. In fact, one can run multiple jails bound to a single network stack instance, if desired. Furthermore, a single process can simultaneously attach to multiple network stacks, thus potentially allowing a single routing daemon to manage multiple separated routing tables and interface groups. The entity that gets permanently bound to a network stack instance is a socket and not a process. This translates to the capability of a single process to open multiple sockets in multiple independent stacks. IMO, one particular strength of such an approach is that it requires absolutely no extensions or modifications to the existing routing socket API. And finally, I'm wondering what structures exactly are you referring to when you say that this approach "duplicates a lot of structures for each stack which don't have to be duplicated"? I absolutely agree that the virtualization of the network stack should be done as simple and non-intrusive as possible, but my point is that it just cannot be done cleanly / properly without taking some sacrifices in terms of the scope of minimum required modifications. Cheers, Marko > What I have in mind is a redesign of some parts of the stack as such. > I have got funding to work on this through my fundraise of two weeks > ago. Work is about to start later this week. I will provide a more > detailed design document for discussion and review by the FreeBSD > community in a few days. It will include features such as multiple > hierarchical routing tables (bound to jails or not), interface > groups, virtual interfaces belonging to one or more interface groups, > policy routing (based on source address/interface), multi-path > routing, a reworked routing-socket and some more stuff. > > I recommend waiting for the design document for further discussions > and jumping to any conclusions. :) From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 10:33:23 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 859E216A41F for ; Tue, 9 Aug 2005 10:33:23 +0000 (GMT) (envelope-from net@dino.sk) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC03B43D49 for ; Tue, 9 Aug 2005 10:33:20 +0000 (GMT) (envelope-from net@dino.sk) Received: from home.dino.sk ([213.215.74.194]) (AUTH: LOGIN milan) by bsd.dino.sk with esmtp; Tue, 09 Aug 2005 12:33:14 +0200 id 00000133.42F8866B.00002926 From: Milan Obuch To: freebsd-net@freebsd.org Date: Tue, 9 Aug 2005 12:32:50 +0200 User-Agent: KMail/1.8 References: <1123040973.95445.TMDA@seddon.ca> <42F78C87.5EB79CBC@freebsd.org> <200508091104.06572.zec@icir.org> In-Reply-To: <200508091104.06572.zec@icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508091232.52095.net@dino.sk> Subject: Stack virtualization (was Re: running out of mbufs?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 10:33:23 -0000 On Tuesday 09 August 2005 11:04, Marko Zec wrote: > On Monday 08 August 2005 18:47, Andre Oppermann wrote: ... > Andre, > > there's no doubt almost any idea or particularly software can be > improved. Could you provide a more elaborate argumentation to your > claim the network stack cloning concept is so severely limited that it > has no place to search for in the future of FreeBSD? ... > I am coming to this talk having used Marko's patch once and planning to use it again for similar task if nothing better will be available (which almost surely will not be the case in not too distant future). The only one problem with it is not being -current or 5/6 release based, so the whole thing needs to be implemented anew in new kernel environment. ... > > Having multiple stacks duplicates a lot of structures for each stack > > which don't have to be duplicated. With your approach you need a new > > jail for every new stack. In each jail you have to run a new > > instance of a routing daemon (if you do routing). And it precludes > > having one routing daemon managing multiple routing tables. While > > removing one limitation you create some new ones in addition to the > > complexity. > > Bemusingly, none of the above claims are true. > > A new jail for each network stack instance is NOT required. Inside the > kernel what could be considered "per-jail" and per-network stack > structures are cleanly separated and independent. In fact, one can run > multiple jails bound to a single network stack instance, if desired. > > Furthermore, a single process can simultaneously attach to multiple > network stacks, thus potentially allowing a single routing daemon to > manage multiple separated routing tables and interface groups. The > entity that gets permanently bound to a network stack instance is a > socket and not a process. This translates to the capability of a single > process to open multiple sockets in multiple independent stacks. IMO, > one particular strength of such an approach is that it requires > absolutely no extensions or modifications to the existing routing > socket API. > > And finally, I'm wondering what structures exactly are you referring to > when you say that this approach "duplicates a lot of structures for > each stack which don't have to be duplicated"? I absolutely agree that > the virtualization of the network stack should be done as simple and > non-intrusive as possible, but my point is that it just cannot be done > cleanly / properly without taking some sacrifices in terms of the scope > of minimum required modifications. > As I am no network code guru, I can only tell from reading presentation papers and some material on this issue virtualisation as done by Marko meets most of above mentioned criteria already. I would like to stress its easiness of use - no application modification is necessary, but one could surely make new application (or modify old one, for that matter) aware of stack virtualization - routing daemon could benefit here. Only argument against Marko's work could be it's monolithic, which does interfere with current movement towards modular network infrastructure, so new protocol could be kldload'ed. To me this would be great start - it does work well, it is usable in many various scenarios already and it *is* well structured, even easy to understand (at least at conceptual level, code itself is somewhat more complicated). Milan From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 11:46:00 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C84E16A41F for ; Tue, 9 Aug 2005 11:46:00 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA03D43D45 for ; Tue, 9 Aug 2005 11:45:59 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 5302 invoked from network); 9 Aug 2005 11:27:49 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Aug 2005 11:27:49 -0000 Message-ID: <42F89777.6E1181F1@freebsd.org> Date: Tue, 09 Aug 2005 13:45:59 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave+Seddon References: <1123040973.95445.TMDA@seddon.ca> <1123055951.16791.TMDA@seddon.ca> <42F734D0.6F7387E0@freebsd.org> <200508081757.47499.zec@icir.org> <42F78C87.5EB79CBC@freebsd.org> <1123545356.93682.TMDA@seddon.ca> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: running out of mbufs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 11:46:00 -0000 Dave+Seddon wrote: > > Greetings, > > It’s very cool to hear you guys are interested in separate routing. > > > Having multiple stacks duplicates a lot of structures for each stack > > which don't have to be duplicated. With your approach you need a new > > jail for every new stack. In each jail you have to run a new instance > > of a routing daemon (if you do routing). And it precludes having one > > routing daemon managing multiple routing tables. While removing one > > limitation you create some new ones in addition to the complexity. > > Running multiple routing daemons isn’t too much of a problem though. The > memory size isn’t usually very high, and it is more likely to be secure if It depends on your goals. If you have full BGP feeds then running multiple routing daemons is a big problem. Especially with Quagga's RIB+protocolRIB design. Five times 130MB of RAM ain't nice. > the daemons are separate. If somebody was going to run a large instance of > routing they should probably use a router, not a unix box. Bzzt, wrong answer. There is no difference between a FreeBSD box and a "router" per you definition, see Juniper. The only thing they've got is a hardware FIB and forwarding plane. I don't want to run Cisco et al. because I can't change anything other than what the IOS cli gives me. I'm not satisfied. I can't run my own experimental routing protocols on it. I can't fix any of their (plenty) bugs. Nono, you want to use FreeBSD as router instead of Cisco, Juniper or all the others. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 12:41:44 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0F1E16A41F for ; Tue, 9 Aug 2005 12:41:44 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 277EC43D49 for ; Tue, 9 Aug 2005 12:41:43 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 5740 invoked from network); 9 Aug 2005 12:23:33 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Aug 2005 12:23:33 -0000 Message-ID: <42F8A487.67183CA6@freebsd.org> Date: Tue, 09 Aug 2005 14:41:43 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Marko Zec References: <1123040973.95445.TMDA@seddon.ca> <200508081757.47499.zec@icir.org> <42F78C87.5EB79CBC@freebsd.org> <200508091104.06572.zec@icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: running out of mbufs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 12:41:45 -0000 Marko Zec wrote: > > On Monday 08 August 2005 18:47, Andre Oppermann wrote: > > Marko Zec wrote: > > > On Monday 08 August 2005 12:32, Andre Oppermann wrote: > > > > Dave+Seddon wrote: > > > > > BTW, I'd be interested to know people's thoughts on multiple IP > > > > > stacks on FreeBSD. It would be really cool to be able to give > > > > > a jail it's own IP stack bound to a VLAN interface. It could > > > > > then be like a VRF on Cisco. > > > > > > > > There is a patch doing that for FreeBSD 4.x. However while > > > > interesting it is not the way to go. You don't want to have > > > > multiple parallel stacks but just multiple routing tables and > > > > interface groups one per jail. This gives you the same > > > > functionality as Cisco VRF but is far less intrusive to the > > > > kernel. > > > > > > Andre, > > > > > > the stack virtualization framework for 4.x is based precisely on > > > introducing multiple routing tables and interface groups. In order > > > to cleanly implement support for multiple independent interface > > > groups, one has to touch both the link and network layers, not > > > forgetting the ARP stuff... and in no time you have ended up with a > > > huge and intrusive diff against the original network stack code. > > > > While your stack indexing approach is interesting I don't think it is > > the way we should take for the generic FreeBSD. There are better > > ways to implement a less limiting superset of the desired > > functionality. > > Andre, > > there's no doubt almost any idea or particularly software can be > improved. Could you provide a more elaborate argumentation to your > claim the network stack cloning concept is so severely limited that it > has no place to search for in the future of FreeBSD? And what exactly > did you mean by a "stack indexing approach"? I'm not saying your concept is wrong or doesn't have its place. However there are other approaches doing 98% of what people want to do with less intrusive code changes. > > And the ARP is almost done, I have to review the code > > and then it goes into -current. > > While having a per-interface ARP logic is certainly a nice feature, this > alone will not solve much with regards to introducing multiple > independent interface groups. You will still most probably have to > revisit the ARP code once you start introducing non-global interface > lists in the kernel. I don't want to have non-global interface lists in the kernel. What I want to provide is not exactly what your stack virtualizations does. In fact my work does not preclude virtualization like yours on top of it. It's solving a somewhat different problem set in a different, architectual clean way. That's way I said we should wait for my paper before going to too deep into discussions yet. ;) > > > So I see no point in pretending we could get such a functionality > > > for free, i.e. with only a negligible intrusiveness to the kernel > > > code. A more appropriate question would be whether the potential > > > benefits of having multiple stack state instances could outweight > > > the trouble and damage associated with the scope of required > > > modifications to the kernel code tree. Only if we could get an > > > affirmative answer to that question it would make sense to start > > > thinking / debating on the most appropriate methodology to > > > (re)implement the multiple stacks framework. > > > > Having multiple stacks duplicates a lot of structures for each stack > > which don't have to be duplicated. With your approach you need a new > > jail for every new stack. In each jail you have to run a new > > instance of a routing daemon (if you do routing). And it precludes > > having one routing daemon managing multiple routing tables. While > > removing one limitation you create some new ones in addition to the > > complexity. > > Bemusingly, none of the above claims are true. > > A new jail for each network stack instance is NOT required. Inside the > kernel what could be considered "per-jail" and per-network stack > structures are cleanly separated and independent. In fact, one can run > multiple jails bound to a single network stack instance, if desired. Ok. > Furthermore, a single process can simultaneously attach to multiple > network stacks, thus potentially allowing a single routing daemon to > manage multiple separated routing tables and interface groups. The > entity that gets permanently bound to a network stack instance is a > socket and not a process. This translates to the capability of a single > process to open multiple sockets in multiple independent stacks. IMO, > one particular strength of such an approach is that it requires > absolutely no extensions or modifications to the existing routing > socket API. The existing API should be modified, it is pretty out of date. > And finally, I'm wondering what structures exactly are you referring to > when you say that this approach "duplicates a lot of structures for > each stack which don't have to be duplicated"? I absolutely agree that > the virtualization of the network stack should be done as simple and > non-intrusive as possible, but my point is that it just cannot be done > cleanly / properly without taking some sacrifices in terms of the scope > of minimum required modifications. Multiple interface lists, vm zones, etc. as your FAQ spells out. Again, I think we are talking past each other right now and we have different solutions to different problem sets in mind (or already coded). When I have my paper finished my vision and intentions should be more clear and then we can have the discussion on the merits of each approach and whether parts of each are complementary or converse. -- Andre > Cheers, > > Marko > > > What I have in mind is a redesign of some parts of the stack as such. > > I have got funding to work on this through my fundraise of two weeks > > ago. Work is about to start later this week. I will provide a more > > detailed design document for discussion and review by the FreeBSD > > community in a few days. It will include features such as multiple > > hierarchical routing tables (bound to jails or not), interface > > groups, virtual interfaces belonging to one or more interface groups, > > policy routing (based on source address/interface), multi-path > > routing, a reworked routing-socket and some more stuff. > > > > I recommend waiting for the design document for further discussions > > and jumping to any conclusions. :) From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 12:24:39 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5865116A41F; Tue, 9 Aug 2005 12:24:39 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0401643D48; Tue, 9 Aug 2005 12:24:38 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 333CE46B55; Tue, 9 Aug 2005 08:24:38 -0400 (EDT) Date: Tue, 9 Aug 2005 13:27:51 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: net@FreeBSD.org Message-ID: <20050809131102.H84992@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 09 Aug 2005 15:09:40 +0000 Cc: sobomax@FreeBSD.org, jhb@FreeBSD.org, onoe@FreeBSD.org, joerg@FreeBSD.org, marius@FreeBSD.org, mdodd@FreeBSD.org, nyan@FreeBSD.org, imp@FreeBSD.org, yongari@FreeBSD.org Subject: Drivers that modify ifp->if_flags's IFF_ALLMULTI field X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 12:24:39 -0000 (maintainers or effective maintainers of the affected device drivers CC'd -- see below for the details, sorry about dups) I've recently been reviewing the use of if_flags with respect to network stack and driver locking. Part of that work has been to break the field out into two separate fields: one maintained and locked by the device driver (if_drv_flags), and the other maintained and locked by the network stack (if_flags). So far, I've moved IFF_OACTIVE and IFF_RUNNING from if_flags to if_drv_flags. This change was recently committed to 7.x, and will be merged to 6.x prior to 6.0. I'm now reviewing the remainder of the flags, and hit upon IFF_ALLMULTI, which seems generally to be an administrative flag specificying that all multicast packets should be accepted at the device driver layer. This flag is generally set in one of three ways: (1) if_allmulti() is invoked by network protocols wanting to specify that they want to see all multicast packets, such as for multicast routing. (2) IFF_ALLMULTI is sometimes set directly by cross-driver common link layer code, specifically if IN6_IS_ADDR_UNSPECIFIED(&sin6->sin6_addr) is matched in if_resolvemulti(). (3) Some device drivers set IFF_ALLMULTI when their multicast address filters overflow to indicate that all multicast traffic should and is being accepted, to be handled at the link or network layer. IFF_ALLMULTI is then generally read by network device drivers in order to special case their multicast handling if all multicast is desired. My feeling is that (2) and (3) are in fact bugs in device drivers and the IPv6 code. Specifically: - IFF_ALLMULTI should be set using if_allmulti(), which maintains a counter of consumers, which (2) bypasses. Also, once (2) has happened, IFF_ALLMULTI is not disabled by the consumer. And, it may be disabled by another consumer, breaking the consumer that wanted it on. This should be corrected to use if_allmulti(), and ideally a symetric "now turn it off" should be identified. - (3) is also a bug, as it reflects internal driver state, and will interfere with the administrative setting of IFF_ALLMULTI by turning it off even though there are consumers that want it on. Drivers should maintain their forcing of the flag on or off internally. If it is necesary to also expose IFF_ALLMULTI as a status flag for the device driver, a new flag should be introduced that is distinguished from the administrative state. (3) is fairly uncommon -- most device drivers already maintain the forcing of the all multicast state internally in a separate flag. The following device drivers do not, however: src/sys/dev/awi/awi.c src/sys/dev/gem/if_gem.c src/sys/dev/hme/if_hme.c src/sys/dev/ie/if_ie.c src/sys/dev/lnc/if_lnc.c src/sys/dev/pdq/pdq_ifsubr.c src/sys/dev/ray/if_ray.c src/sys/dev/snc/dp83932.c src/sys/dev/usb/if_udav.c src/sys/pci/if_de.c The fix is generally pretty straight forward, and depending on the device driver, may or may not require adding new state to softc. Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 15:29:13 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 160E016A41F; Tue, 9 Aug 2005 15:29:13 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id A210D43D46; Tue, 9 Aug 2005 15:29:12 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Aug 2005 11:29:11 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id C915513621; Tue, 9 Aug 2005 11:29:11 -0400 (EDT) Date: Tue, 9 Aug 2005 11:29:11 -0400 From: Ed Maste To: Robert Watson Message-ID: <20050809152911.GA72933@sandvine.com> References: <20050808190024.GA4843@sandvine.com> <20050808223106.P67598@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050808223106.P67598@fledge.watson.org> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 09 Aug 2005 15:29:11.0989 (UTC) FILETIME=[17C9E650:01C59CF7] Cc: freebsd-net@freebsd.org Subject: Re: Multicast locking LOR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 15:29:13 -0000 On Mon, Aug 08, 2005 at 10:34:53PM +0100, Robert Watson wrote: > Could you add a hard-coded entry to WITNESS to place the udpinp lock > before the in_multi_mtx in the lock order, and let me know which path > resulted in the opposite order from this one? I hard-coded the correct order, but am now unable to reproduce the problem. I guess Murphy's Law at work. I suspect you're right about IGMP's packet getting back into ip_input. I'll post another message if I can get it to happen again. -ed From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 15:53:17 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F386016A41F; Tue, 9 Aug 2005 15:53:16 +0000 (GMT) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4267543D45; Tue, 9 Aug 2005 15:53:16 +0000 (GMT) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id B82849B6C4; Tue, 9 Aug 2005 17:55:29 +0200 (CEST) Received: from [127.0.0.1] (imunes.tel.fer.hr [161.53.19.8]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 8FE6A9B763; Tue, 9 Aug 2005 17:55:20 +0200 (CEST) From: Marko Zec To: freebsd-net@freebsd.org Date: Tue, 9 Aug 2005 17:37:32 +0200 User-Agent: KMail/1.7.2 References: <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> In-Reply-To: <42F8A487.67183CA6@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200508091737.32391.zec@icir.org> Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.0.2 Cc: Andre Oppermann Subject: Stack virtualization (was: running out of mbufs?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 15:53:17 -0000 On Tuesday 09 August 2005 14:41, Andre Oppermann wrote: > Marko Zec wrote: > > On Monday 08 August 2005 18:47, Andre Oppermann wrote: > > > Marko Zec wrote: > > > > On Monday 08 August 2005 12:32, Andre Oppermann wrote: ... > > > > > There is a patch doing that for FreeBSD 4.x. However while > > > > > interesting it is not the way to go. You don't want to have > > > > > multiple parallel stacks but just multiple routing tables and > > > > > interface groups one per jail. This gives you the same ^^^^^^^^^^^^^^^^ > > > > > functionality as Cisco VRF but is far less intrusive to the > > > > > kernel. ... > I don't want to have non-global interface lists in the kernel. But sooner or later you _will_ end up with some sort of non-global interface lists after all, just as you stated yourself at the beginning of this tread. Of course one can still maintain all interfaces linked in one list and introduce another set of separated lists on per-stack basis which will be used to logically group interfaces into smaller sets, but that's really just a question of coding / design style. ... > > > Having multiple stacks duplicates a lot of structures for each > > > stack which don't have to be duplicated. With your approach you > > > need a new jail for every new stack. In each jail you have to > > > run a new instance of a routing daemon (if you do routing). And > > > it precludes having one routing daemon managing multiple routing > > > tables. While removing one limitation you create some new ones > > > in addition to the complexity. > > > > Bemusingly, none of the above claims are true. > > > > A new jail for each network stack instance is NOT required. Inside > > the kernel what could be considered "per-jail" and per-network > > stack structures are cleanly separated and independent. In fact, > > one can run multiple jails bound to a single network stack > > instance, if desired. > > Ok. > > > Furthermore, a single process can simultaneously attach to multiple > > network stacks, thus potentially allowing a single routing daemon > > to manage multiple separated routing tables and interface groups. > > The entity that gets permanently bound to a network stack instance > > is a socket and not a process. This translates to the capability of > > a single process to open multiple sockets in multiple independent > > stacks. IMO, one particular strength of such an approach is that > > it requires absolutely no extensions or modifications to the > > existing routing socket API. > > The existing API should be modified, it is pretty out of date. > > > And finally, I'm wondering what structures exactly are you > > referring to when you say that this approach "duplicates a lot of > > structures for each stack which don't have to be duplicated"? I > > absolutely agree that the virtualization of the network stack > > should be done as simple and non-intrusive as possible, but my > > point is that it just cannot be done cleanly / properly without > > taking some sacrifices in terms of the scope of minimum required > > modifications. > > Multiple interface lists, vm zones, etc. as your FAQ spells out. Multiple interface lists are a must, whether as a replacement (the way I did it) or as a supplement to a global interface list. They cost nothing in terms of memory use, and greatly simplify the code and prevent potential performance and cross-stack-boundary-leaking pitfails. For a long time my framework does _not_ use separate VM zones per network stack instance for storing PCBs. True, the FAQ should probably be updated, but it already clearly stated my doubts whether separate VM zones were really needed, and the later experiments and working code proved they indeed weren't. What still uses multiple VM zones is the TCP syncache code, and I agree it could most likely be reworked to use only a single global zone. Any other offending structures? :-) It looks like we might be converging in terms of what it takes to virtualize a network stack :-) > Again, I think we are talking past each other right now and we have > different solutions to different problem sets in mind (or already > coded). When I have my paper finished my vision and intentions > should be more clear and then we can have the discussion on the > merits of each approach and whether parts of each are complementary > or converse. OK, looking forward to it... Cheers, Marko From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 15:53:48 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 038F916A41F for ; Tue, 9 Aug 2005 15:53:48 +0000 (GMT) (envelope-from darcy@wavefire.com) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id 9ECE243D46 for ; Tue, 9 Aug 2005 15:53:47 +0000 (GMT) (envelope-from darcy@wavefire.com) Received: (qmail 15003 invoked from network); 9 Aug 2005 17:57:25 -0000 Received: from dbitech.internal.wavefire.ca (64.141.15.12) by radius.wavefire.com with SMTP; 9 Aug 2005 17:57:25 -0000 From: Darcy Buskermolen Organization: Wavefire Technologies Corp To: freebsd-net@freebsd.org Date: Tue, 9 Aug 2005 08:54:21 -0700 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508090854.21278.darcy@wavefire.com> Subject: panic: if_attach called without if_alloc'd input() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 15:53:48 -0000 I'm getting the following panic on my RELENG_6 test box: xl1f0: BUG: if_attach called without if_alloc'd input() Where should I be looking to track this down? I suspect it has to do with a custom kernel, it wasn't doing it when i was running GENERIC -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759 From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 16:25:19 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF76D16A41F for ; Tue, 9 Aug 2005 16:25:19 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCD7543D45 for ; Tue, 9 Aug 2005 16:25:18 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 7558 invoked from network); 9 Aug 2005 16:07:06 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Aug 2005 16:07:06 -0000 Message-ID: <42F8D8ED.11A196FC@freebsd.org> Date: Tue, 09 Aug 2005 18:25:17 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Marko Zec References: <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> <200508091737.32391.zec@icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Stack virtualization (was: running out of mbufs?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 16:25:19 -0000 Marko Zec wrote: > > On Tuesday 09 August 2005 14:41, Andre Oppermann wrote: > ... > > I don't want to have non-global interface lists in the kernel. > > But sooner or later you _will_ end up with some sort of non-global > interface lists after all, just as you stated yourself at the beginning > of this tread. Of course one can still maintain all interfaces linked > in one list and introduce another set of separated lists on per-stack > basis which will be used to logically group interfaces into smaller > sets, but that's really just a question of coding / design style. I thinking more along the lines of OpenBSD's interface groups. There you just add another attribute called group to an interface. Claudio (@openbsd.org, working at next desk to me) explained it quickly to me after it was raised here on the list. The group name is a string but in the ifnet structure only an int is stored. This group name then is used primarily for pf firewall to create rules for interface groups. It handles newly arriving interfaces too. I haven't fully explored all applications and possible tie-ins with jails, virtual stacks etc. but it looks very interesting. For example I want to have multiple routing tables within the same stack. These routing tables can be opaque or fall-through and match on the source and destination address (not at the same time though). This way we get ultimate routing flexibility in using FreeBSD as router. An incoming packet on interface em0 with group priority would first match into routing table X, and if no match fall-through to the default routing table. Or you could create a source matching routing table Y sending matching packets further to table Z for low priority routing. It's hard to describe this textually to its full extent. That's why my upcoming paper will have mostly graphics depicting the packet flow and the processing options. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 18:16:02 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B960D16A41F for ; Tue, 9 Aug 2005 18:16:02 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68DA843D45 for ; Tue, 9 Aug 2005 18:16:02 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j79IG1Gh028865; Tue, 9 Aug 2005 11:16:01 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j79IG1Iv028864; Tue, 9 Aug 2005 11:16:01 -0700 Date: Tue, 9 Aug 2005 11:16:01 -0700 From: Brooks Davis To: Darcy Buskermolen Message-ID: <20050809181601.GB20908@odin.ac.hmc.edu> References: <200508090854.21278.darcy@wavefire.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0" Content-Disposition: inline In-Reply-To: <200508090854.21278.darcy@wavefire.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-net@freebsd.org Subject: Re: panic: if_attach called without if_alloc'd input() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 18:16:02 -0000 --LyciRD1jyfeSSjG0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 09, 2005 at 08:54:21AM -0700, Darcy Buskermolen wrote: > I'm getting the following panic on my RELENG_6 test box: >=20 > xl1f0: BUG: if_attach called without if_alloc'd input() >=20 > Where should I be looking to track this down? I suspect it has to do with= a=20 > custom kernel, it wasn't doing it when i was running GENERIC The ef(4) device is currently broken. I haven't had time to look at it much though it seems mostly correct by inspection so I'm not sure what's going on. If you could compile with debugging and get be a stack trace from the panic, that might help be track this down. I'm assuming there's a path through the code that I'm missing that results in using a bogus cast to get an ifnet pointer and thus causes a panic. You might also try the following patch which fixes a couple bugs I think are unrelated, but may not be. -- Brooks Index: if_ef.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/net/if_ef.c,v retrieving revision 1.34 diff -u -p -r1.34 if_ef.c --- if_ef.c 10 Jun 2005 16:49:18 -0000 1.34 +++ if_ef.c 26 Jul 2005 23:56:39 -0000 @@ -477,7 +477,7 @@ ef_clone(struct ef_link *efl, int ft) efp->ef_pifp =3D ifp; efp->ef_frametype =3D ft; eifp =3D efp->ef_ifp =3D if_alloc(IFT_ETHER); - if (ifp =3D=3D NULL) + if (eifp =3D=3D NULL) return (ENOSPC); snprintf(eifp->if_xname, IFNAMSIZ, "%sf%d", ifp->if_xname, efp->ef_frametype); @@ -536,8 +536,8 @@ ef_load(void) SLIST_FOREACH(efl, &efdev, el_next) { for (d =3D 0; d < EF_NFT; d++) if (efl->el_units[d]) { - if (efl->el_units[d]->ef_pifp !=3D NULL) - if_free(efl->el_units[d]->ef_pifp); + if (efl->el_units[d]->ef_ifp !=3D NULL) + if_free(efl->el_units[d]->ef_ifp); free(efl->el_units[d], M_IFADDR); } free(efl, M_IFADDR); --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --LyciRD1jyfeSSjG0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFC+PLhXY6L6fI4GtQRAta7AKCe/TGJoaouw/4aijvbCACn78SJ3gCePMuB 17xpkruirwfZsEHOwi6aQTw= =dVFL -----END PGP SIGNATURE----- --LyciRD1jyfeSSjG0-- From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 19:49:34 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E97716A41F for ; Tue, 9 Aug 2005 19:49:34 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 899DE43D5E for ; Tue, 9 Aug 2005 19:49:33 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: (qmail 4030 invoked from network); 9 Aug 2005 19:49:32 -0000 Received: from aldan.algebra.com ([216.254.65.224]) (envelope-sender ) by mail23.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 9 Aug 2005 19:49:32 -0000 Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.1/8.13.1) with ESMTP id j79JnTeQ082493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Aug 2005 15:49:30 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11]) by corbulon.video-collage.com (8.13.4/8.13.1) with ESMTP id j79JnNtT022425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Aug 2005 15:49:23 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id j79JnHRh001222; Tue, 9 Aug 2005 15:49:17 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id j79JnFDs001221; Tue, 9 Aug 2005 15:49:15 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: mteterin.us.murex.com: mteterin set sender to mi+mx@aldan.algebra.com using -f From: Mikhail Teterin Organization: Virtual Estates, Inc. To: net@freebsd.org, questions@freebsd.org Date: Tue, 9 Aug 2005 15:49:15 -0400 User-Agent: KMail/1.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508091549.15676.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV devel-20050525/1011/Tue Aug 9 05:20:28 2005 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: Subject: very busy ftpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 19:49:34 -0000 Hi! I just noticed, that uploading a file over a LANG (at around 5.7Mb/s) resulted in around 25% CPU consumption by the ftpd. I think, that's unusual for a Pentium4 -- what is the process doing? The machine is running 5.2.1-RELEASE and has TrustedBSD extensions. -mi From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 20:47:31 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C9BA16A41F for ; Tue, 9 Aug 2005 20:47:31 +0000 (GMT) (envelope-from darcy@wavefire.com) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id 2257A43D48 for ; Tue, 9 Aug 2005 20:47:30 +0000 (GMT) (envelope-from darcy@wavefire.com) Received: (qmail 7781 invoked from network); 9 Aug 2005 22:51:11 -0000 Received: from dbitech.internal.wavefire.ca (64.141.15.12) by radius.wavefire.com with SMTP; 9 Aug 2005 22:51:11 -0000 From: Darcy Buskermolen Organization: Wavefire Technologies Corp To: Brooks Davis Date: Tue, 9 Aug 2005 13:48:04 -0700 User-Agent: KMail/1.8.2 References: <200508090854.21278.darcy@wavefire.com> <20050809181601.GB20908@odin.ac.hmc.edu> In-Reply-To: <20050809181601.GB20908@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508091348.05099.darcy@wavefire.com> Cc: freebsd-net@freebsd.org Subject: Re: panic: if_attach called without if_alloc'd input() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 20:47:31 -0000 On Tuesday 09 August 2005 11:16, Brooks Davis wrote: > On Tue, Aug 09, 2005 at 08:54:21AM -0700, Darcy Buskermolen wrote: > > I'm getting the following panic on my RELENG_6 test box: > > > > xl1f0: BUG: if_attach called without if_alloc'd input() > > > > Where should I be looking to track this down? I suspect it has to do with > > a custom kernel, it wasn't doing it when i was running GENERIC > > The ef(4) device is currently broken. I haven't had time to look at it > much though it seems mostly correct by inspection so I'm not sure what's > going on. > > If you could compile with debugging and get be a stack trace from the > panic, that might help be track this down. Here is a trace without your patch KDB: enter: panic [thread pid 0 tid 0 ] Stoped at kdb_enter+0x2b: nop db> trace Tracing pid 0 tid 0 td 0xc0824dc0 kdb_enter(c07b7c59) at kdb_enter+0xb2 panic(c07bd294,c13b5c10,c0c20cfc,c059605d,c13b8c10) at panic+0xbb if_attach(c13b5c00,c13b5c00,c1380a00,c0c20d28,c05e93ed) at if_attach+0x33 ether_ifattach(c13b5c00,c12ba2ab,0,c0c20d40,c05e9c86) at ether_ifattach+0x19 ef_attach(c13b04d0) at ef_attach+0x5d ef_load(c0c20d74,c0572383,c12b6600,0,0) at ef_load+0x1ae if_ef_modevent(c16b6600,0,0,c08259c0,0) at if_ef_modeevent+0x19 module_redgister)init(c07fe220,c1ec00,c1e000,0,c0444065) at module_register_init+0x4b mi_startup() at mi_startup+0x96 begin() at begin+0x2c db> This was transcribed for the monitor behind me so I may have typoed an address along the way, but hopefully it's enough to point you down the right path, if you need more detail just let me know. I'm compiling with your patch now, but it may take a bit before i get back to you with answers on how it does, darn slow hardware.. > I'm assuming there's a path > through the code that I'm missing that results in using a bogus cast to > get an ifnet pointer and thus causes a panic. You might also try the > following patch which fixes a couple bugs I think are unrelated, but may > not be. > > -- Brooks > > Index: if_ef.c > =================================================================== > RCS file: /home/ncvs/src/sys/net/if_ef.c,v > retrieving revision 1.34 > diff -u -p -r1.34 if_ef.c > --- if_ef.c 10 Jun 2005 16:49:18 -0000 1.34 > +++ if_ef.c 26 Jul 2005 23:56:39 -0000 > @@ -477,7 +477,7 @@ ef_clone(struct ef_link *efl, int ft) > efp->ef_pifp = ifp; > efp->ef_frametype = ft; > eifp = efp->ef_ifp = if_alloc(IFT_ETHER); > - if (ifp == NULL) > + if (eifp == NULL) > return (ENOSPC); > snprintf(eifp->if_xname, IFNAMSIZ, > "%sf%d", ifp->if_xname, efp->ef_frametype); > @@ -536,8 +536,8 @@ ef_load(void) > SLIST_FOREACH(efl, &efdev, el_next) { > for (d = 0; d < EF_NFT; d++) > if (efl->el_units[d]) { > - if (efl->el_units[d]->ef_pifp != NULL) > - if_free(efl->el_units[d]->ef_pifp); > + if (efl->el_units[d]->ef_ifp != NULL) > + if_free(efl->el_units[d]->ef_ifp); > free(efl->el_units[d], M_IFADDR); > } > free(efl, M_IFADDR); -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759 From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 21:35:55 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1036616A468; Tue, 9 Aug 2005 21:35:55 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A06B44451; Tue, 9 Aug 2005 21:15:26 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id 78269C101; Tue, 9 Aug 2005 23:15:24 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id ACBCB405B; Tue, 9 Aug 2005 23:15:37 +0200 (CEST) Date: Tue, 9 Aug 2005 23:15:37 +0200 From: Jeremie Le Hen To: Andre Oppermann Message-ID: <20050809211537.GX45385@obiwan.tataz.chchile.org> References: <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> <200508091737.32391.zec@icir.org> <42F8D8ED.11A196FC@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42F8D8ED.11A196FC@freebsd.org> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org, Marko Zec Subject: Re: Stack virtualization (was: running out of mbufs?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 21:35:55 -0000 > I haven't fully explored all applications and possible tie-ins with > jails, virtual stacks etc. but it looks very interesting. > > For example I want to have multiple routing tables within the same > stack. These routing tables can be opaque or fall-through and match > on the source and destination address (not at the same time though). > This way we get ultimate routing flexibility in using FreeBSD as > router. An incoming packet on interface em0 with group priority > would first match into routing table X, and if no match fall-through > to the default routing table. Or you could create a source matching > routing table Y sending matching packets further to table Z for > low priority routing. What you are saying clearly reminds me the way Linux does it. Basically they have about 256 routing tables available, one of them being the default one (254 IIRC). Once you have filled the those you want to use, you can assign a routing table to each packet with what they simply call "rules". The routing criteria are classical, such as "from", "to", "tos", "iif" (incoming interface)... (See the manpage [1] for more informations, the IPRoute2 framework is quite powerful.) One of the most powerful criteria it provides is "fwmark" which allows to match against a mark stamped on the skbuff (their mbuf) by the firewall. This leads to the ability to route packets based on the whole capabilities of the firewall framework (NetFilter in this case) : TCP/UDP ports, ICMP types, and so on... This might appear a little bit hackish to networking guys, especially those ones that are working on backbone routers, but this flexibility is almost nothing to add (pf already has the ability to tag packets, IIRC) and it doesn't constrain the design at all, IMHO. FYI, this has already been discussed in this subthread [2]. I have to say that I was quite impressed by Linux networking capabilities (this was in the 2.4 days), and that's why I would really like to see FreeBSD to be able to do this. > It's hard to describe this textually to its full extent. That's why > my upcoming paper will have mostly graphics depicting the packet flow > and the processing options. I'm in haste to read your paper. [1] http://www.manpage.org/cgi-bin/man/man2html?8+ip [2] http://lists.freebsd.org/pipermail/freebsd-net/2005-June/007743.html Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 23:06:48 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B55ED16A420 for ; Tue, 9 Aug 2005 23:06:45 +0000 (GMT) (envelope-from darcy@wavefire.com) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id 4955044807 for ; Tue, 9 Aug 2005 23:06:26 +0000 (GMT) (envelope-from darcy@wavefire.com) Received: (qmail 19916 invoked from network); 10 Aug 2005 01:10:07 -0000 Received: from dbitech.internal.wavefire.ca (64.141.15.12) by radius.wavefire.com with SMTP; 10 Aug 2005 01:10:06 -0000 From: Darcy Buskermolen Organization: Wavefire Technologies Corp To: freebsd-net@freebsd.org Date: Tue, 9 Aug 2005 16:06:59 -0700 User-Agent: KMail/1.8.2 References: <200508090854.21278.darcy@wavefire.com> <20050809181601.GB20908@odin.ac.hmc.edu> <200508091348.05099.darcy@wavefire.com> In-Reply-To: <200508091348.05099.darcy@wavefire.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508091606.59685.darcy@wavefire.com> Cc: Subject: Re: panic: if_attach called without if_alloc'd input() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 23:06:49 -0000 On Tuesday 09 August 2005 13:48, Darcy Buskermolen wrote: > On Tuesday 09 August 2005 11:16, Brooks Davis wrote: > > On Tue, Aug 09, 2005 at 08:54:21AM -0700, Darcy Buskermolen wrote: > > > I'm getting the following panic on my RELENG_6 test box: > > > > > > xl1f0: BUG: if_attach called without if_alloc'd input() > > > > > > Where should I be looking to track this down? I suspect it has to do > > > with a custom kernel, it wasn't doing it when i was running GENERIC > > > > The ef(4) device is currently broken. I haven't had time to look at it > > much though it seems mostly correct by inspection so I'm not sure what's > > going on. > > > > If you could compile with debugging and get be a stack trace from the > > panic, that might help be track this down. > > Here is a trace without your patch > > KDB: enter: panic > [thread pid 0 tid 0 ] > Stoped at kdb_enter+0x2b: nop > db> trace > Tracing pid 0 tid 0 td 0xc0824dc0 > kdb_enter(c07b7c59) at kdb_enter+0xb2 > panic(c07bd294,c13b5c10,c0c20cfc,c059605d,c13b8c10) at panic+0xbb > if_attach(c13b5c00,c13b5c00,c1380a00,c0c20d28,c05e93ed) at if_attach+0x33 > ether_ifattach(c13b5c00,c12ba2ab,0,c0c20d40,c05e9c86) at > ether_ifattach+0x19 ef_attach(c13b04d0) at ef_attach+0x5d > ef_load(c0c20d74,c0572383,c12b6600,0,0) at ef_load+0x1ae > if_ef_modevent(c16b6600,0,0,c08259c0,0) at if_ef_modeevent+0x19 > module_redgister)init(c07fe220,c1ec00,c1e000,0,c0444065) at > module_register_init+0x4b > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > db> > > This was transcribed for the monitor behind me so I may have typoed an > address along the way, but hopefully it's enough to point you down the > right path, if you need more detail just let me know. > > I'm compiling with your patch now, but it may take a bit before i get back > to you with answers on how it does, darn slow hardware.. > And with the patch no difference, same looking trace > > I'm assuming there's a path > > through the code that I'm missing that results in using a bogus cast to > > get an ifnet pointer and thus causes a panic. You might also try the > > following patch which fixes a couple bugs I think are unrelated, but may > > not be. > > > > -- Brooks > > > > Index: if_ef.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/net/if_ef.c,v > > retrieving revision 1.34 > > diff -u -p -r1.34 if_ef.c > > --- if_ef.c 10 Jun 2005 16:49:18 -0000 1.34 > > +++ if_ef.c 26 Jul 2005 23:56:39 -0000 > > @@ -477,7 +477,7 @@ ef_clone(struct ef_link *efl, int ft) > > efp->ef_pifp = ifp; > > efp->ef_frametype = ft; > > eifp = efp->ef_ifp = if_alloc(IFT_ETHER); > > - if (ifp == NULL) > > + if (eifp == NULL) > > return (ENOSPC); > > snprintf(eifp->if_xname, IFNAMSIZ, > > "%sf%d", ifp->if_xname, efp->ef_frametype); > > @@ -536,8 +536,8 @@ ef_load(void) > > SLIST_FOREACH(efl, &efdev, el_next) { > > for (d = 0; d < EF_NFT; d++) > > if (efl->el_units[d]) { > > - if (efl->el_units[d]->ef_pifp != NULL) > > - if_free(efl->el_units[d]->ef_pifp); > > + if (efl->el_units[d]->ef_ifp != NULL) > > + if_free(efl->el_units[d]->ef_ifp); > > free(efl->el_units[d], M_IFADDR); > > } > > free(efl, M_IFADDR); -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759 From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 03:39:59 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B85016A422 for ; Wed, 10 Aug 2005 03:39:59 +0000 (GMT) (envelope-from cataract@pepe.pl) Received: from adsl-64-170-236-50.dsl.lsan03.pacbell.net (adsl-64-170-236-50.dsl.lsan03.pacbell.net [64.170.236.50]) by mx1.FreeBSD.org (Postfix) with SMTP id D550D45BB9 for ; Wed, 10 Aug 2005 03:39:51 +0000 (GMT) (envelope-from cataract@pepe.pl) Received: from [80.236.222.58] (port=8521 helo=[transformable]) by adsl-64-170-236-50.dsl.lsan03.pacbell.net with esmtp id 11075421672catalogs33118 for freebsd-net@freebsd.org; Tue, 9 Aug 2005 20:38:16 -0700 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Message-Id: <12909248708.11646071295@adsl-64-170-236-50.dsl.lsan03.pacbell.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-net@freebsd.org From: Sal Date: Tue, 9 Aug 2005 20:38:15 -0700 X-Mailer: attaining Subject: 36 hours of freedom. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 03:39:59 -0000 Cialis - the next to the Guiness' book?!.. http://scantly.terramefolk.info/?statementxtvuyjeopardyzctrationalizes The enemy came. He was beaten. I am tired. Goodnight. The wicked at heart probably know something. I never think of the future - it comes soon enough. I wasn't kissing her, I was whispering in her mouth. From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 04:49:20 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7DA016A423 for ; Wed, 10 Aug 2005 04:49:20 +0000 (GMT) (envelope-from redchin@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A25E4604B for ; Wed, 10 Aug 2005 04:49:20 +0000 (GMT) (envelope-from redchin@gmail.com) Received: by wproxy.gmail.com with SMTP id i5so57300wra for ; Tue, 09 Aug 2005 21:49:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=QzLVndvFVmMakG5+f7tW2ccIlS9UlVsaiByPcvbpGUN4zUzn8SMPT7ZzLAa9DWniUcsnHcClstDwK5X0yt1ffmvtLR5BGqYQkVsDcw02oqeQck2ybvYtf4QMJby2ksTUlKpkTBfh994OWisVHVWOBEKwY+/N+PXP7MZpnLsaZSg= Received: by 10.54.8.51 with SMTP id 51mr230140wrh; Tue, 09 Aug 2005 21:49:19 -0700 (PDT) Received: by 10.54.160.3 with HTTP; Tue, 9 Aug 2005 21:49:19 -0700 (PDT) Message-ID: <1d3ed48c05080921492e2c4988@mail.gmail.com> Date: Tue, 9 Aug 2005 21:49:19 -0700 From: Kevin Downey To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1133_20141831.1123649359885" Subject: Atheros 5212 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 04:49:21 -0000 ------=_Part_1133_20141831.1123649359885 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I am running a generic kernel with all the debugging knobs. if I use BitTorrent or Gnutella in X the computer reboots after a few minut= es. >From the console it drops into the debugger deal. But will not give me a crash dump. Under the assumption that something was wrong with the ath driver I tried to get the atheros card working with project evil and if_ndis.ko built fine, but after I loaded it nothing happened (ndis0 did not show up in ifconfig). Rebuilding world from old sources (7/20/05) to try and go back to before this showed up. This did not help. Here are some juicy bits from dmesg, the whole dmesg is attached. FreeBSD zifnab 6.0-BETA1 FreeBSD 6.0-BETA1 #4: Tue Aug 9 15:16:43 PDT 2005 root@zifnab:/usr/obj/usr/src/sys/GENERIC i386 Aug 9 03:32:16 zifnab kernel: ath0: mem 0xec410000-0xec41ffff irq 11 at device 10.0 on pci0 Aug 9 03:32:16 zifnab kernel: ath0: Ethernet address: 00:0f:3d:ae:ad:b8 Aug 9 03:32:16 zifnab kernel: ath0: mac 5.9 phy 4.3 radio 4.6 ............................. Aug 9 03:32:16 zifnab kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Aug 9 03:32:16 zifnab kernel: exclusive sleep mutex ath0 (network driver) r =3D 0 (0xc1a73d0c) locked @ /usr/src/sys/modules/ath/../../dev/ath/if_ath .c:4677 Aug 9 03:32:16 zifnab kernel: KDB: stack backtrace: Aug 9 03:32:16 zifnab kernel: kdb_backtrace(c0a2b0dc,cec5aabc,1,c1a9cda0,c1461b40) at kdb_backtrace+0x2e Aug 9 03:32:16 zifnab kernel: witness_warn(5,0,c092e935,c08f67d4,c1a73bcc) at witness_warn+0x1a3 Aug 9 03:32:16 zifnab kernel: uma_zalloc_arg(c1461b40,0,2,c146c960,c1a9cda0) at uma_zalloc_arg+0x5b Aug 9 03:32:16 zifnab kernel: malloc(0,c09772c0,2,c1a9cda0,c1a4008c) at malloc+0xc9 Aug 9 03:32:16 zifnab kernel: ieee80211_ioctl_setoptie(c1a731ac,c1a9cda0,cec5ab40,c068d33d,c09e4a40) at ieee80211_ioctl_setoptie+0x50 Aug 9 03:32:16 zifnab kernel: ieee80211_ioctl_set80211(c1a731ac,801c69ea,c1a9cda0,1245,0) at ieee80211_ioctl_set80211+0x71c Aug 9 03:32:16 zifnab kernel: ieee80211_ioctl(c1a731ac,801c69ea,c1a9cda0,1245,c0917cc2) at ieee80211_ioctl+0x137 Aug 9 03:32:16 zifnab kernel: ath_ioctl(c1a66000,801c69ea,c1a9cda0,c0a2be20,1) at ath_ioctl+0xdc Aug 9 03:32:16 zifnab kernel: in_control(c1be8de8,801c69ea,c1a9cda0,c1a66000,c1a8b600) at in_control+0xcbe Aug 9 03:32:16 zifnab kernel: ifioctl(c1be8de8,801c69ea,c1a9cda0,c1a8b600,1) at ifioctl+0x1e9 Aug 9 03:32:16 zifnab kernel: soo_ioctl(c1b450d8,801c69ea,c1a9cda0,c1941a80,c1a8b600) at soo_ioctl+0x3bf Aug 9 03:32:16 zifnab kernel: ioctl(c1a8b600,cec5ad04,c,422,3) at ioctl+0x= 45d Aug 9 03:32:16 zifnab kernel: syscall(3b,3b,3b,bfbfe13c,80672c0) at syscall+0x2a2 Aug 9 03:32:16 zifnab kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Aug 9 03:32:16 zifnab kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x280fd92f, esp =3D 0xbfbfe0ec, ebp =3D 0xbfbfe158 --- --=20 The best prophet of the future is the past. ------=_Part_1133_20141831.1123649359885 Content-Type: application/octet-stream; name="dmesg.today" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.today" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDYuMC1CRVRBMiAjMjogTW9uIEF1ZyAgOCAwNzoxNToyNCBQ RFQgMjAwNQogICAgcm9vdEB6aWZuYWI6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQwpXQVJO SU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4K VGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ1BVOiBB TUQgRHVyb24odG0pIHByb2Nlc3NvciAoNzk5LjQ0LU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdp biA9ICJBdXRoZW50aWNBTUQiICBJZCA9IDB4NjMxICBTdGVwcGluZyA9IDEKICBGZWF0dXJlcz0w eDE4M2Y5ZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxTRVAsTVRSUixQR0Us TUNBLENNT1YsUEFULFBTRTM2LE1NWCxGWFNSPgogIEFNRCBGZWF0dXJlcz0weGMwNDQwODAwPFNZ U0NBTEwsPGIxOD4sTU1YKywzRE5vdyssM0ROb3c+CnJlYWwgbWVtb3J5ICA9IDI1OTk4MTMxMiAo MjQ3IE1CKQphdmFpbCBtZW1vcnkgPSAyNDA1Mzc2MDAgKDIyOSBNQikKYXRoX2hhbDogMC45LjE0 LjkgKEFSNTIxMCwgQVI1MjExLCBBUjUyMTIsIFJGNTExMSwgUkY1MTEyLCBSRjI0MTMpCm5weDA6 IFtGQVNUXQpucHgwOiA8bWF0aCBwcm9jZXNzb3I+IG9uIG1vdGhlcmJvYXJkCm5weDA6IElOVCAx NiBpbnRlcmZhY2UKYWNwaTA6IDxWSUE2OTQgQVdSREFDUEk+IG9uIG1vdGhlcmJvYXJkCmFjcGkw OiBQb3dlciBCdXR0b24gKGZpeGVkKQpwY2lfbGluazA6IDxBQ1BJIFBDSSBMaW5rIExOS0E+IGly cSAxMCBvbiBhY3BpMApwY2lfbGluazE6IDxBQ1BJIFBDSSBMaW5rIExOS0I+IGlycSAxMiBvbiBh Y3BpMApwY2lfbGluazI6IDxBQ1BJIFBDSSBMaW5rIExOS0M+IGlycSAxMSBvbiBhY3BpMApwY2lf bGluazM6IDxBQ1BJIFBDSSBMaW5rIExOS0Q+IGlycSA1IG9uIGFjcGkwClRpbWVjb3VudGVyICJB Q1BJLXNhZmUiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDog PDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwMDgtMHg0MDBiIG9uIGFjcGkw CmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKYWNwaV90aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJv dHRsaW5nPiBvbiBjcHUwCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKcGNp YjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiwweDQwMDAtMHg0MDdm LDB4NDA4MC0weDQwZmYsMHg1MDAwLTB4NTAwZiwweDYwMDAtMHg2MDdmIG9uIGFjcGkwCnBjaTA6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCmFncDA6IDxWSUEgODM2MSAoS0xFMTMzKSBob3N0IHRv IFBDSSBicmlkZ2U+IG1lbSAweGVjMDAwMDAwLTB4ZWMzZmZmZmYgYXQgZGV2aWNlIDAuMCBvbiBw Y2kwCnBjaWIxOiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8 UENJIGJ1cz4gb24gcGNpYjEKcGNpMTogPGRpc3BsYXksIFZHQT4gYXQgZGV2aWNlIDAuMCAobm8g ZHJpdmVyIGF0dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9u IHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxWSUEgODJDNjg2QiBVRE1B MTAwIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYs MHhkMDAwLTB4ZDAwZiBhdCBkZXZpY2UgNy4xIG9uIHBjaTAKYXRhcGNpMDogQ29ycmVjdGluZyBW SUEgY29uZmlnIGZvciBzb3V0aGJyaWRnZSBkYXRhIGNvcnJ1cHRpb24gYnVnCmF0YTA6IDxBVEEg Y2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCnVo Y2kwOiA8VklBIDgzQzU3MiBVU0IgY29udHJvbGxlcj4gcG9ydCAweGQ0MDAtMHhkNDFmIGlycSA1 IGF0IGRldmljZSA3LjIgb24gcGNpMAp1aGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMDogPFZJQSA4 M0M1NzIgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kwCnVzYjA6IFVTQiByZXZpc2lvbiAxLjAKdWh1 YjA6IFZJQSBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQp1 aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWhjaTE6IDxWSUEg ODNDNTcyIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4ZDgwMC0weGQ4MWYgaXJxIDUgYXQgZGV2aWNl IDcuMyBvbiBwY2kwCnVoY2kxOiBbR0lBTlQtTE9DS0VEXQp1c2IxOiA8VklBIDgzQzU3MiBVU0Ig Y29udHJvbGxlcj4gb24gdWhjaTEKdXNiMTogVVNCIHJldmlzaW9uIDEuMAp1aHViMTogVklBIFVI Q0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIxOiAyIHBv cnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApwY2kwOiA8YnJpZGdlPiBhdCBkZXZp Y2UgNy40IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmlj ZSA4LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNtMDogPEVTUyBUZWNobm9sb2d5IEFsbGVncm8t MT4gcG9ydCAweGU0MDAtMHhlNGZmIGlycSAxMiBhdCBkZXZpY2UgOS4wIG9uIHBjaTAKcGNtMDog ZmFpbGVkIHRvIGVuYWJsZSBtZW1vcnkgbWFwcGluZyEKcGNtMDogPEVTUyBUZWNobm9sb2d5IEVT MTk4OCBBQzk3IENvZGVjPgphdGgwOiA8QXRoZXJvcyA1MjEyPiBtZW0gMHhlYzQxMDAwMC0weGVj NDFmZmZmIGlycSAxMSBhdCBkZXZpY2UgMTAuMCBvbiBwY2kwCmF0aDA6IEV0aGVybmV0IGFkZHJl c3M6IDAwOjBmOjNkOmFlOmFkOmI4CmF0aDA6IG1hYyA1LjkgcGh5IDQuMyByYWRpbyA0LjYKZmRj MDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyPiBwb3J0IDB4M2YwLTB4M2Y1LDB4M2Y3IGlycSA2 IGRycSAyIG9uIGFjcGkwCmZkYzA6IFtGQVNUXQpzaW8wOiBjb25maWd1cmVkIGlycSA0IG5vdCBp biBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMApzaW8wOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApz aW8wOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQg ZmxhZ3MgMHgxMCBvbiBhY3BpMApzaW8wOiB0eXBlIDE2NTUwQQpzaW8xOiBjb25maWd1cmVkIGly cSAzIG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMApzaW8xOiBwb3J0IG1heSBub3QgYmUg ZW5hYmxlZApzaW8xOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgyZjgtMHgy ZmYgaXJxIDMgb24gYWNwaTAKc2lvMTogdHlwZSAxNjU1MEEKcHBjMDogPFN0YW5kYXJkIHBhcmFs bGVsIHByaW50ZXIgcG9ydD4gcG9ydCAweDM3OC0weDM3ZiBpcnEgNyBvbiBhY3BpMApwcGMwOiBH ZW5lcmljIGNoaXBzZXQgKEVQUC9OSUJCTEUpIGluIENPTVBBVElCTEUgbW9kZQpwcGJ1czA6IDxQ YXJhbGxlbCBwb3J0IGJ1cz4gb24gcHBjMApwcGkwOiA8UGFyYWxsZWwgSS9PPiBvbiBwcGJ1czAK cGxpcDA6IDxQTElQIG5ldHdvcmsgaW50ZXJmYWNlPiBvbiBwcGJ1czAKbHB0MDogPFByaW50ZXI+ IG9uIHBwYnVzMApscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQKcG10aW1lcjAgb24gaXNhMApv cm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4Y2JmZmYsMHhjYzAwMC0w eGNmZmZmIG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQg cG9ydCAweDYwLDB4NjQgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgx MDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnZn YTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0w eGJmZmZmIG9uIGlzYTAKdW1zMDogTG9naXRlY2ggVVNCLVBTLzIgT3B0aWNhbCBNb3VzZSwgcmV2 IDIuMDAvMTEuMTAsIGFkZHIgMiwgaWNsYXNzIDMvMQp1bXMwOiAzIGJ1dHRvbnMgYW5kIFogZGly Lgp1a2JkMDogU0VKSU4gU0VKSU4gVVNCIE1pbmkgS2V5Ym9hcmQsIHJldiAxLjEwLzIuMjAsIGFk ZHIgMywgaWNsYXNzIDMvMQprYmQwIGF0IHVrYmQwClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5j eSA3OTk0MzU4NDggSHogcXVhbGl0eSA4MDAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAg bXNlYwpwY20wOiBVbmtub3duIEhXVk9MIGV2ZW50CmFkMDogMTE3MjQ2TUIgPE1heHRvciA2TDEy MFAwIEJBSDQxRTAwPiBhdCBhdGEwLW1hc3RlciBVRE1BMTAwCmFjZDA6IERWRFIgPEdFTkVSSUMg RFZEIFJXIDEyWE1heC8xMTBJPiBhdCBhdGExLW1hc3RlciBVRE1BMzMKVHJ5aW5nIHRvIG1vdW50 IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDBzMWEKV0FSTklORzogIHdhcyBub3QgcHJvcGVybHkgZGlz bW91bnRlZApXQVJOSU5HOiAgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkCldBUk5JTkc6ICB3 YXMgbm90IHByb3Blcmx5IGRpc21vdW50ZWQKV0FSTklORzogIHdhcyBub3QgcHJvcGVybHkgZGlz bW91bnRlZAptYWxsb2MoTV9XQUlUT0spIG9mICIxNiIsIGZvcmNpbmcgTV9OT1dBSVQgd2l0aCB0 aGUgZm9sbG93aW5nIG5vbi1zbGVlcGFibGUgbG9ja3MgaGVsZDoKZXhjbHVzaXZlIHNsZWVwIG11 dGV4IGF0aDAgKG5ldHdvcmsgZHJpdmVyKSByID0gMCAoMHhjMWE3M2QwYykgbG9ja2VkIEAgL3Vz ci9zcmMvc3lzL21vZHVsZXMvYXRoLy4uLy4uL2Rldi9hdGgvaWZfYXRoLmM6NDY3NwpLREI6IHN0 YWNrIGJhY2t0cmFjZToKa2RiX2JhY2t0cmFjZShjMGEyYzJjNCxjZWM1NGFiYywxLGMxYTljY2Uw LGMxNDYxYjQwKSBhdCBrZGJfYmFja3RyYWNlKzB4MmUKd2l0bmVzc193YXJuKDUsMCxjMDkyZjg0 ZixjMDhmNzZlZSxjMWE3M2JjYykgYXQgd2l0bmVzc193YXJuKzB4MWEzCnVtYV96YWxsb2NfYXJn KGMxNDYxYjQwLDAsMixjMTQ2Yzk2MCxjMWE5Y2NlMCkgYXQgdW1hX3phbGxvY19hcmcrMHg1Ygpt YWxsb2MoMCxjMDk3ODM0MCwyLGMxYTljY2UwLGMxYTQwMDhjKSBhdCBtYWxsb2MrMHhjOQppZWVl ODAyMTFfaW9jdGxfc2V0b3B0aWUoYzFhNzMxYWMsYzFhOWNjZTAsY2VjNTRiNDAsYzA2OGQzNGQs YzA5ZTVjNjApIGF0IGllZWU4MDIxMV9pb2N0bF9zZXRvcHRpZSsweDUwCmllZWU4MDIxMV9pb2N0 bF9zZXQ4MDIxMShjMWE3MzFhYyw4MDFjNjllYSxjMWE5Y2NlMCwxMjQ1LDApIGF0IGllZWU4MDIx MV9pb2N0bF9zZXQ4MDIxMSsweDcxYwppZWVlODAyMTFfaW9jdGwoYzFhNzMxYWMsODAxYzY5ZWEs YzFhOWNjZTAsMTI0NSxjMDkxOGJkYykgYXQgaWVlZTgwMjExX2lvY3RsKzB4MTM3CmF0aF9pb2N0 bChjMWE2NjAwMCw4MDFjNjllYSxjMWE5Y2NlMCxjMGEyZDA0MCwxKSBhdCBhdGhfaW9jdGwrMHhk Ywppbl9jb250cm9sKGMxYmU4ZGU4LDgwMWM2OWVhLGMxYTljY2UwLGMxYTY2MDAwLGMxYThiMzAw KSBhdCBpbl9jb250cm9sKzB4Y2JlCmlmaW9jdGwoYzFiZThkZTgsODAxYzY5ZWEsYzFhOWNjZTAs YzFhOGIzMDAsMSkgYXQgaWZpb2N0bCsweDFlOQpzb29faW9jdGwoYzFiNDU0ODAsODAxYzY5ZWEs YzFhOWNjZTAsYzE5NDFhODAsYzFhOGIzMDApIGF0IHNvb19pb2N0bCsweDNiZgppb2N0bChjMWE4 YjMwMCxjZWM1NGQwNCxjLDQyMiwzKSBhdCBpb2N0bCsweDQ1ZApzeXNjYWxsKDNiLDNiLDNiLGJm YmZlMTNjLDgwNjcyYzApIGF0IHN5c2NhbGwrMHgyYTIKWGludDB4ODBfc3lzY2FsbCgpIGF0IFhp bnQweDgwX3N5c2NhbGwrMHgxZgotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxGMzIsIGlvY3Rs KSwgZWlwID0gMHgyODBmZDkyZiwgZXNwID0gMHhiZmJmZTBlYywgZWJwID0gMHhiZmJmZTE1OCAt LS0KZHJtMDogPEFUSSBSYWRlb24gUVkgUlYxMDAgNzAwMC9WRT4gcG9ydCAweGUwMDAtMHhlMGZm IG1lbSAweGUwMDAwMDAwLTB4ZTdmZmZmZmYsMHhlYzQwMDAwMC0weGVjNDBmZmZmIGlycSAxMCBh dCBkZXZpY2UgOC4wIG9uIHBjaTAKaW5mbzogW2RybV0gSW5pdGlhbGl6ZWQgcmFkZW9uIDEuMTYu MCAyMDA1MDMxMSBvbiBtaW5vciAwCmxvY2sgb3JkZXIgcmV2ZXJzYWwKIDFzdCAweGMwYTNhNTIw IFVNQSBsb2NrIChVTUEgbG9jaykgQCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoxNDk0CiAy bmQgMHhjMTQ2MDE0NCBzeXN0ZW0gbWFwIChzeXN0ZW0gbWFwKSBAIC91c3Ivc3JjL3N5cy92bS92 bV9tYXAuYzoyMzE3CktEQjogc3RhY2sgYmFja3RyYWNlOgprZGJfYmFja3RyYWNlKGMwOTE4ZjY4 LGMxNDYwMTQ0LGMwOTJmZjY4LGMwOTJmZjY4LGMwOTMwNGIwKSBhdCBrZGJfYmFja3RyYWNlKzB4 MmUKd2l0bmVzc19jaGVja29yZGVyKGMxNDYwMTQ0LDksYzA5MzA0YjAsOTBkLDI0NikgYXQgd2l0 bmVzc19jaGVja29yZGVyKzB4NmMzCl9tdHhfbG9ja19mbGFncyhjMTQ2MDE0NCwwLGMwOTMwNGIw LDkwZCxjMWE4MTAwMCkgYXQgX210eF9sb2NrX2ZsYWdzKzB4OGEKX3ZtX21hcF9sb2NrKGMxNDYw MGMwLGMwOTMwNGIwLDkwZCwxLGMxYTNhOWMwKSBhdCBfdm1fbWFwX2xvY2srMHgzNwp2bV9tYXBf cmVtb3ZlKGMxNDYwMGMwLGMxYTgxMDAwLGMxYTgyMDAwLGNjNzc0YmRjLGMwODI3ODdiKSBhdCB2 bV9tYXBfcmVtb3ZlKzB4MzAKa21lbV9mcmVlKGMxNDYwMGMwLGMxYTgxMDAwLDEwMDAsY2M3NzRj MTQsYzA4MjcwYmYpIGF0IGttZW1fZnJlZSsweDMyCnBhZ2VfZnJlZShjMWE4MTAwMCwxMDAwLDIs MCwyKSBhdCBwYWdlX2ZyZWUrMHgzYgp6b25lX2RyYWluKGMxNDRhNzgwLDAsYzA5MmY1YzEsNWQ2 LDApIGF0IHpvbmVfZHJhaW4rMHgyYWYKem9uZV9mb3JlYWNoKGMwODI2ZTEwLGNjNzc0Y2U0LGMw ODNkOGRhLGMxOTQxYTBjLDApIGF0IHpvbmVfZm9yZWFjaCsweDRjCnVtYV9yZWNsYWltKGMxOTQx YTBjLDAsYzA5MzE5OWQsMjllLGMwNjhkMzRkKSBhdCB1bWFfcmVjbGFpbSsweDE3CnZtX3BhZ2Vv dXRfc2NhbigwLDAsYzA5MzE5OWQsNWMzLDEzODgpIGF0IHZtX3BhZ2VvdXRfc2NhbisweDE0YQp2 bV9wYWdlb3V0KDAsY2M3NzRkMzgsYzA5MTI5NmEsMzBkLDApIGF0IHZtX3BhZ2VvdXQrMHgzMWIK Zm9ya19leGl0KGMwODNlOTcwLDAsY2M3NzRkMzgpIGF0IGZvcmtfZXhpdCsweGMxCmZvcmtfdHJh bXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBl c3AgPSAweGNjNzc0ZDZjLCBlYnAgPSAwIC0tLQo= ------=_Part_1133_20141831.1123649359885-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 05:05:41 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A8F016A441 for ; Wed, 10 Aug 2005 05:05:36 +0000 (GMT) (envelope-from mi@corbulon.video-collage.com) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD10145F40 for ; Wed, 10 Aug 2005 04:41:00 +0000 (GMT) (envelope-from mi@corbulon.video-collage.com) Received: (qmail 23382 invoked from network); 10 Aug 2005 04:41:00 -0000 Received: from aldan.algebra.com ([216.254.65.224]) (envelope-sender ) by mail25.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Aug 2005 04:41:00 -0000 Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.1/8.13.1) with ESMTP id j7A4erEw083559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2005 00:40:57 -0400 (EDT) (envelope-from mi@corbulon.video-collage.com) Received: from corbulon.video-collage.com (smmsp@localhost.video-collage.com [127.0.0.1]) by corbulon.video-collage.com (8.13.4/8.13.1) with ESMTP id j7A4ek35025585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Aug 2005 00:40:47 -0400 (EDT) (envelope-from mi@corbulon.video-collage.com) Received: (from root@localhost) by corbulon.video-collage.com (8.13.4/8.13.4/Submit) id j7A4ekqp025584; Wed, 10 Aug 2005 00:40:46 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin Message-Id: <200508100440.j7A4ekqp025584@corbulon.video-collage.com> To: maxim@macomnet.ru (Maxim Konovalov) Date: Wed, 10 Aug 2005 00:40:46 -0400 (EDT) In-Reply-To: <20050810064601.N91726@mp2.macomnet.net> X-Mailer: ELM [version 2.5 PL7] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV devel-20050525/1011/Tue Aug 9 05:20:28 2005 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: questions@freebsd.org, net@freebsd.org Subject: Re: very busy ftpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 05:05:41 -0000 > > I just noticed, that uploading a file over a LANG (at around > > 5.7Mb/s) resulted in around 25% CPU consumption by the ftpd. > > > > I think, that's unusual for a Pentium4 -- what is the process doing? > > Check the client does not use ascii mode when uploading (getc() vs > read()). That's quite possible, indeed. I wouldn't put it past some users -- some still use the ancient ftp-clients, which default to text-mode transfers. Is there any way to disable this mode on the server, perhaps? Even if it violates the protocol :-/ Thanks! -mi From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 05:35:40 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 699A916A41F for ; Wed, 10 Aug 2005 05:35:40 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 137F7461EB for ; Wed, 10 Aug 2005 05:35:40 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.93] ([66.127.85.93]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j7A5Zcms057499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Aug 2005 22:35:39 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42F99256.9080003@errno.com> Date: Tue, 09 Aug 2005 22:36:22 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Downey References: <1d3ed48c05080921492e2c4988@mail.gmail.com> In-Reply-To: <1d3ed48c05080921492e2c4988@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Atheros 5212 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 05:35:40 -0000 Kevin Downey wrote: > I am running a generic kernel with all the debugging knobs. > if I use BitTorrent or Gnutella in X the computer reboots after a few minutes. >>From the console it drops into the debugger deal. But will not give me > a crash dump. The stack trace below isn't a crash, it's just witness warning about a malloc w/ WAITOK while holding a lock. Try updating to BETA2 and getting a trace from the crash. Then also provide basic info like what you're trying to do at the time. It appears you're trying to use wpa_supplicant w/ WPA based on the stack trace. > > Under the assumption that something was wrong with the ath driver I > tried to get the atheros card working with project evil and if_ndis.ko > built fine, but after I loaded it nothing happened (ndis0 did not show > up in ifconfig). > > Rebuilding world from old sources (7/20/05) to try and go back to > before this showed up. This did not help. > > Here are some juicy bits from dmesg, the whole dmesg is attached. > > FreeBSD zifnab 6.0-BETA1 FreeBSD 6.0-BETA1 #4: Tue Aug 9 15:16:43 PDT > 2005 root@zifnab:/usr/obj/usr/src/sys/GENERIC i386 > > > Aug 9 03:32:16 zifnab kernel: ath0: mem > 0xec410000-0xec41ffff irq 11 at device 10.0 on pci0 > Aug 9 03:32:16 zifnab kernel: ath0: Ethernet address: 00:0f:3d:ae:ad:b8 > Aug 9 03:32:16 zifnab kernel: ath0: mac 5.9 phy 4.3 radio 4.6 > > ............................. > > > Aug 9 03:32:16 zifnab kernel: malloc(M_WAITOK) of "16", forcing > M_NOWAIT with the following non-sleepable locks held: > Aug 9 03:32:16 zifnab kernel: exclusive sleep mutex ath0 (network > driver) r = 0 (0xc1a73d0c) locked @ > /usr/src/sys/modules/ath/../../dev/ath/if_ath > .c:4677 > Aug 9 03:32:16 zifnab kernel: KDB: stack backtrace: > Aug 9 03:32:16 zifnab kernel: > kdb_backtrace(c0a2b0dc,cec5aabc,1,c1a9cda0,c1461b40) at > kdb_backtrace+0x2e > Aug 9 03:32:16 zifnab kernel: > witness_warn(5,0,c092e935,c08f67d4,c1a73bcc) at witness_warn+0x1a3 > Aug 9 03:32:16 zifnab kernel: > uma_zalloc_arg(c1461b40,0,2,c146c960,c1a9cda0) at uma_zalloc_arg+0x5b > Aug 9 03:32:16 zifnab kernel: malloc(0,c09772c0,2,c1a9cda0,c1a4008c) > at malloc+0xc9 > Aug 9 03:32:16 zifnab kernel: > ieee80211_ioctl_setoptie(c1a731ac,c1a9cda0,cec5ab40,c068d33d,c09e4a40) > at ieee80211_ioctl_setoptie+0x50 > Aug 9 03:32:16 zifnab kernel: > ieee80211_ioctl_set80211(c1a731ac,801c69ea,c1a9cda0,1245,0) at > ieee80211_ioctl_set80211+0x71c > Aug 9 03:32:16 zifnab kernel: > ieee80211_ioctl(c1a731ac,801c69ea,c1a9cda0,1245,c0917cc2) at > ieee80211_ioctl+0x137 > Aug 9 03:32:16 zifnab kernel: > ath_ioctl(c1a66000,801c69ea,c1a9cda0,c0a2be20,1) at ath_ioctl+0xdc > Aug 9 03:32:16 zifnab kernel: > in_control(c1be8de8,801c69ea,c1a9cda0,c1a66000,c1a8b600) at > in_control+0xcbe > Aug 9 03:32:16 zifnab kernel: > ifioctl(c1be8de8,801c69ea,c1a9cda0,c1a8b600,1) at ifioctl+0x1e9 > Aug 9 03:32:16 zifnab kernel: > soo_ioctl(c1b450d8,801c69ea,c1a9cda0,c1941a80,c1a8b600) at > soo_ioctl+0x3bf > Aug 9 03:32:16 zifnab kernel: ioctl(c1a8b600,cec5ad04,c,422,3) at ioctl+0x45d > Aug 9 03:32:16 zifnab kernel: syscall(3b,3b,3b,bfbfe13c,80672c0) at > syscall+0x2a2 > Aug 9 03:32:16 zifnab kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f > Aug 9 03:32:16 zifnab kernel: --- syscall (54, FreeBSD ELF32, ioctl), > eip = 0x280fd92f, esp = 0xbfbfe0ec, ebp = 0xbfbfe158 --- > > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 05:54:25 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 548FD16A6FA; Wed, 10 Aug 2005 05:53:59 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57CCF45616; Wed, 10 Aug 2005 02:47:23 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.3/8.13.3) with ESMTP id j7A2lEqg091752; Wed, 10 Aug 2005 06:47:15 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Wed, 10 Aug 2005 06:47:14 +0400 (MSD) From: Maxim Konovalov To: Mikhail Teterin In-Reply-To: <200508091549.15676.mi+mx@aldan.algebra.com> Message-ID: <20050810064601.N91726@mp2.macomnet.net> References: <200508091549.15676.mi+mx@aldan.algebra.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: questions@freebsd.org, net@freebsd.org Subject: Re: very busy ftpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 05:54:26 -0000 On Tue, 9 Aug 2005, 15:49-0400, Mikhail Teterin wrote: > Hi! > > I just noticed, that uploading a file over a LANG (at around > 5.7Mb/s) resulted in around 25% CPU consumption by the ftpd. > > I think, that's unusual for a Pentium4 -- what is the process doing? Check the client does not use ascii mode when uploading (getc() vs read()). -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 08:29:31 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C884216A41F; Wed, 10 Aug 2005 08:29:31 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3821143D48; Wed, 10 Aug 2005 08:29:30 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.3/8.13.3) with ESMTP id j7A8TJMH098733; Wed, 10 Aug 2005 12:29:19 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Wed, 10 Aug 2005 12:29:19 +0400 (MSD) From: Maxim Konovalov To: Mikhail Teterin In-Reply-To: <200508100440.j7A4ekqp025584@corbulon.video-collage.com> Message-ID: <20050810122339.F97163@mp2.macomnet.net> References: <200508100440.j7A4ekqp025584@corbulon.video-collage.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: questions@freebsd.org, net@freebsd.org Subject: Re: very busy ftpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 08:29:31 -0000 On Wed, 10 Aug 2005, 00:40-0400, Mikhail Teterin wrote: > > > I just noticed, that uploading a file over a LANG (at around > > > 5.7Mb/s) resulted in around 25% CPU consumption by the ftpd. > > > > > > I think, that's unusual for a Pentium4 -- what is the process doing? > > > > Check the client does not use ascii mode when uploading (getc() vs > > read()). > > That's quite possible, indeed. I wouldn't put it past some users -- > some still use the ancient ftp-clients, which default to text-mode > transfers. > > Is there any way to disable this mode on the server, perhaps? Even > if it violates the protocol :-/ A dirty hack: Index: ftpcmd.y =================================================================== RCS file: /home/ncvs/src/libexec/ftpd/ftpcmd.y,v retrieving revision 1.64 diff -u -r1.64 ftpcmd.y --- ftpcmd.y 18 Nov 2004 13:46:29 -0000 1.64 +++ ftpcmd.y 10 Aug 2005 08:23:09 -0000 @@ -379,6 +379,9 @@ switch (cmd_type) { case TYPE_A: + reply(504, "Type A not implemented."); + break; +#if 0 if (cmd_form == FORM_N) { reply(200, "Type set to A."); type = cmd_type; @@ -386,7 +389,7 @@ } else reply(504, "Form must be N."); break; - +#endif case TYPE_E: reply(504, "Type E not implemented."); break; %%% -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 11:16:14 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9146F16A41F for ; Wed, 10 Aug 2005 11:16:14 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3D9643D48 for ; Wed, 10 Aug 2005 11:16:13 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 14644 invoked from network); 10 Aug 2005 10:57:53 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Aug 2005 10:57:53 -0000 Message-ID: <42F9E1FB.3ECF023E@freebsd.org> Date: Wed, 10 Aug 2005 13:16:11 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeremie Le Hen References: <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> <200508091737.32391.zec@icir.org> <42F8D8ED.11A196FC@freebsd.org> <20050809211537.GX45385@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Marko Zec Subject: Re: Stack virtualization (was: running out of mbufs?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 11:16:14 -0000 Jeremie Le Hen wrote: > > > I haven't fully explored all applications and possible tie-ins with > > jails, virtual stacks etc. but it looks very interesting. > > > > For example I want to have multiple routing tables within the same > > stack. These routing tables can be opaque or fall-through and match > > on the source and destination address (not at the same time though). > > This way we get ultimate routing flexibility in using FreeBSD as > > router. An incoming packet on interface em0 with group priority > > would first match into routing table X, and if no match fall-through > > to the default routing table. Or you could create a source matching > > routing table Y sending matching packets further to table Z for > > low priority routing. > > What you are saying clearly reminds me the way Linux does it. > Basically they have about 256 routing tables available, one of them > being the default one (254 IIRC). Once you have filled the those you > want to use, you can assign a routing table to each packet with what > they simply call "rules". The routing criteria are classical, such as > "from", "to", "tos", "iif" (incoming interface)... > (See the manpage [1] for more informations, the IPRoute2 framework is > quite powerful.) > > One of the most powerful criteria it provides is "fwmark" which allows > to match against a mark stamped on the skbuff (their mbuf) by the > firewall. This leads to the ability to route packets based on the > whole capabilities of the firewall framework (NetFilter in this case) : > TCP/UDP ports, ICMP types, and so on... This is mostly the direction I'll go. However any packet classification other than on IP addresses is to be done by a packet filter (ipfw, pf, ipfilter). > This might appear a little bit hackish to networking guys, especially > those ones that are working on backbone routers, but this flexibility > is almost nothing to add (pf already has the ability to tag packets, > IIRC) and it doesn't constrain the design at all, IMHO. FYI, this has > already been discussed in this subthread [2]. The biggest problem for more complex IP routing setups is wrapping ones head around the endless possibilities. The very concept of longest- prefix match on a hop by hop basis is difficult to graps for too many people unfortunatly. I have things in (very large) enterprise environments you wouldn't believe... -- Andre > I have to say that I was quite impressed by Linux networking > capabilities (this was in the 2.4 days), and that's why I would really > like to see FreeBSD to be able to do this. > > > It's hard to describe this textually to its full extent. That's why > > my upcoming paper will have mostly graphics depicting the packet flow > > and the processing options. > > I'm in haste to read your paper. > > [1] http://www.manpage.org/cgi-bin/man/man2html?8+ip > [2] http://lists.freebsd.org/pipermail/freebsd-net/2005-June/007743.html > > Regards, > -- > Jeremie Le Hen > < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 12:49:58 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A33BA16A41F; Wed, 10 Aug 2005 12:49:58 +0000 (GMT) (envelope-from ck-lists@cksoft.de) Received: from mx11.cksoft.de (mx11.cksoft.de [62.111.66.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53B5C43D53; Wed, 10 Aug 2005 12:49:57 +0000 (GMT) (envelope-from ck-lists@cksoft.de) Received: from vesihiisi.cksoft.de (unknown [192.168.64.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mx12.cksoft.de (Postfix) with ESMTP id D021BB97B; Wed, 10 Aug 2005 14:49:54 +0200 (CEST) Received: from vesihiisi.cksoft.de (localhost [127.0.0.1]) by vesihiisi.cksoft.de (Postfix) with ESMTP id D00B11EB5; Wed, 10 Aug 2005 14:49:52 +0200 (CEST) Received: by vesihiisi.cksoft.de (Postfix, from userid 1000) id BB1C61EAC; Wed, 10 Aug 2005 14:49:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by vesihiisi.cksoft.de (Postfix) with ESMTP id B95081EAB; Wed, 10 Aug 2005 14:49:49 +0200 (CEST) Date: Wed, 10 Aug 2005 14:49:49 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@vesihiisi.cksoft.de To: Andre Oppermann In-Reply-To: <42F9E1FB.3ECF023E@freebsd.org> Message-ID: <20050810144407.F97974@vesihiisi.cksoft.de> References: <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> <200508091737.32391.zec@icir.org> <42F8D8ED.11A196FC@freebsd.org> <20050809211537.GX45385@obiwan.tataz.chchile.org> <42F9E1FB.3ECF023E@freebsd.org> X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on vesihiisi.cksoft.de Cc: freebsd-net@freebsd.org, Marko Zec , Jeremie Le Hen Subject: Re: Stack virtualization (was: running out of mbufs?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Kratzer List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2005 12:49:58 -0000 Hi, On Wed, 10 Aug 2005, Andre Oppermann wrote: > Jeremie Le Hen wrote: >> One of the most powerful criteria it provides is "fwmark" which allows >> to match against a mark stamped on the skbuff (their mbuf) by the >> firewall. This leads to the ability to route packets based on the >> whole capabilities of the firewall framework (NetFilter in this case) : >> TCP/UDP ports, ICMP types, and so on... > > This is mostly the direction I'll go. However any packet classification > other than on IP addresses is to be done by a packet filter (ipfw, pf, > ipfilter). please consider that routing is not everything. Marcos patch as I understand it, also addresses the application of having clean and separate ip stacks in each jail. The current jail implementation has to use ugly hacks to give correct semantics to things like INADDR_ANY. We also currently do not have a clean way of associating multiple ipv4 addresses to jail and having correct sematics for INADDR_ANY. And of course IPv6 for jails is something that could propably be solved in a very clean way using virtual ip stacks as in Marcos patch. For above reasons I would prefer a clean implementation of full network stack virtualisation to something that justs adds names to interfaces. Greetings Christian -- Christian Kratzer ck@cksoft.de CK Software GmbH http://www.cksoft.de/ Phone: +49 7452 889 135 Fax: +49 7452 889 136 From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 12:57:39 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DBCF16A41F for ; Wed, 10 Aug 2005 12:57:39 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5568C43D48 for ; Wed, 10 Aug 2005 12:57:38 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 15454 invoked from network); 10 Aug 2005 12:39:16 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Aug 2005 12:39:16 -0000 Message-ID: <42F9F9BF.879994D2@freebsd.org> Date: Wed, 10 Aug 2005 14:57:35 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Kratzer References: <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> <200508091737.32391.zec@icir.org> <42F8D8ED.11A196FC@freebsd.org> <20050809211537.GX45385@obiwan.tataz.chchile.org> <42F9E1FB.3ECF023E@freebsd.org> <20050810144407.F97974@vesihiisi.cksoft.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Marko Zec , Jeremie Le Hen Subject: Re: Stack virtualization (was: running out of mbufs?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 12:57:39 -0000 Christian Kratzer wrote: > > Hi, > > On Wed, 10 Aug 2005, Andre Oppermann wrote: > > > Jeremie Le Hen wrote: > >> One of the most powerful criteria it provides is "fwmark" which allows > >> to match against a mark stamped on the skbuff (their mbuf) by the > >> firewall. This leads to the ability to route packets based on the > >> whole capabilities of the firewall framework (NetFilter in this case) : > >> TCP/UDP ports, ICMP types, and so on... > > > > This is mostly the direction I'll go. However any packet classification > > other than on IP addresses is to be done by a packet filter (ipfw, pf, > > ipfilter). > > please consider that routing is not everything. Routing is the primary scope of my IP work. It doesn't preclude Marko's approach from being implemented and working as it does for 4.11. > Marcos patch as I understand it, also addresses the application of having > clean and separate ip stacks in each jail. The current jail implementation > has to use ugly hacks to give correct semantics to things like INADDR_ANY. > > We also currently do not have a clean way of associating multiple ipv4 > addresses to jail and having correct sematics for INADDR_ANY. The problem with jails is that they are based on an IP address instead of a (virtual) interface. I think interface groups and virtual interfaces can help here a lot. > And of course IPv6 for jails is something that could propably be solved > in a very clean way using virtual ip stacks as in Marcos patch. I'll cook something up that uses interface groups and then you can judge whether it meets you needs or not. It would be more lightwigth than having a full network stack per jail. > For above reasons I would prefer a clean implementation of full network > stack virtualisation to something that justs adds names to interfaces. Be my guest. For my funded work this is out of scope. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 13:07:28 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAEBC16A41F; Wed, 10 Aug 2005 13:07:28 +0000 (GMT) (envelope-from steve.langdon@mail.ru) Received: from f24.mail.ru (f24.mail.ru [194.67.57.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D50C43D58; Wed, 10 Aug 2005 13:07:28 +0000 (GMT) (envelope-from steve.langdon@mail.ru) Received: from mail by f24.mail.ru with local id 1E2qIp-000NEB-00; Wed, 10 Aug 2005 17:07:27 +0400 Received: from [195.14.57.50] by win.mail.ru with HTTP; Wed, 10 Aug 2005 17:07:27 +0400 From: Steve Langdon To: freebsd-questions@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [195.14.57.50] Date: Wed, 10 Aug 2005 17:07:27 +0400 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Cc: freebsd-net@freebsd.org Subject: Stranges with ARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Steve Langdon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2005 13:07:28 -0000 Hello all. Help me to solve a strange conduct. I want to have permanent bundle with IP->MAC for users in our network to have some security. So, once my user's MAC doesn't appear in my ARP table, I have to block by ``arp -S ..' his IP with MAC generated by my script with prefix d1:fa:28. One day I have a phone talk with my user, he make complaints against slow speed in Internet. When I have checked his IP I feel a terrible :) tcpdump: listening on rl0 18:48:11.339543 213.238.62.65.80 > 192.168.57.90.1072: . 2091947455:2091948915(1460) ack 140637902 win 7441 (DF) [tos 0x60] ^C 561 packets received by filter 0 packets dropped by kernel Traffic comes to that user! root@router:~ % arp -a | grep -w 192.168.57.90 ? (192.168.57.90) at d1:fa:28:ec:87:98 on rl0 permanent [ethernet] root@router:~ % While user is blocked by _our_ generated MAC! Btw, could anyone advice me how to block user IP block without touching ipfw (I think to use route + ``-blackhole' to that user that have no his MAC in my ARP table), any ideas? root@router:~ % arping 192.168.57.90 ARPING 192.168.57.90 60 bytes from 00:00:f0:87:4b:ca (192.168.57.90): index=0 time=2.724 msec 60 bytes from 00:00:f0:87:4b:ca (192.168.57.90): index=1 time=9.966 msec ^C --- 192.168.57.90 statistics --- 2 packets transmitted, 2 packets received, 0% unanswered root@router:~ % His real MAC is 00:00:f0:87:4b:ca. I can't belave this could be. Whats wrong? As I think all traffic must transmit to d1:fa:28:ec:87:98, NOT to 00:00:f0:87:4b:ca and user's NIC must ignore that packet unless his interface in PROMISC mode. Or I'm wrong? root@router:~ % ifconfig rl0 | grep flags rl0: flags=8843 mtu 1500 root@router:~ % -- Best regards, Steve From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 13:30:39 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46C3016A420; Wed, 10 Aug 2005 13:30:39 +0000 (GMT) (envelope-from ck-lists@cksoft.de) Received: from mx11.cksoft.de (mx11.cksoft.de [62.111.66.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAB5443D46; Wed, 10 Aug 2005 13:30:37 +0000 (GMT) (envelope-from ck-lists@cksoft.de) Received: from vesihiisi.cksoft.de (unknown [192.168.64.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mx12.cksoft.de (Postfix) with ESMTP id 407E0B85B; Wed, 10 Aug 2005 15:30:38 +0200 (CEST) Received: from vesihiisi.cksoft.de (localhost [127.0.0.1]) by vesihiisi.cksoft.de (Postfix) with ESMTP id 36A0E1EB5; Wed, 10 Aug 2005 15:30:36 +0200 (CEST) Received: by vesihiisi.cksoft.de (Postfix, from userid 1000) id 0EDB21EAC; Wed, 10 Aug 2005 15:30:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by vesihiisi.cksoft.de (Postfix) with ESMTP id 0CFDB1EAB; Wed, 10 Aug 2005 15:30:33 +0200 (CEST) Date: Wed, 10 Aug 2005 15:30:32 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@vesihiisi.cksoft.de To: Andre Oppermann In-Reply-To: <42F9F9BF.879994D2@freebsd.org> Message-ID: <20050810151547.X97974@vesihiisi.cksoft.de> References: <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> <200508091737.32391.zec@icir.org> <42F8D8ED.11A196FC@freebsd.org> <20050809211537.GX45385@obiwan.tataz.chchile.org> <42F9E1FB.3ECF023E@freebsd.org> <20050810144407.F97974@vesihiisi.cksoft.de> <42F9F9BF.879994D2@freebsd.org> X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on vesihiisi.cksoft.de Cc: freebsd-net@freebsd.org, Marko Zec , Jeremie Le Hen Subject: Re: Stack virtualization (was: running out of mbufs?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Kratzer List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2005 13:30:39 -0000 Hi, On Wed, 10 Aug 2005, Andre Oppermann wrote: > Christian Kratzer wrote: >> please consider that routing is not everything. > > Routing is the primary scope of my IP work. It doesn't preclude Marko's > approach from being implemented and working as it does for 4.11. I fully understand that you mostly focus on your primary goals especially now that you have specific funding for that. >> Marcos patch as I understand it, also addresses the application of having >> clean and separate ip stacks in each jail. The current jail implementation >> has to use ugly hacks to give correct semantics to things like INADDR_ANY. >> >> We also currently do not have a clean way of associating multiple ipv4 >> addresses to jail and having correct sematics for INADDR_ANY. > > The problem with jails is that they are based on an IP address instead > of a (virtual) interface. I think interface groups and virtual interfaces > can help here a lot. Yes the current implementation is like that which is quite hackish. As I read Marcos comments and his FAQ his patch only bind sockets to ip stacks and sockets to processes and thus jails. >> And of course IPv6 for jails is something that could propably be solved >> in a very clean way using virtual ip stacks as in Marcos patch. > > I'll cook something up that uses interface groups and then you can judge > whether it meets you needs or not. It would be more lightwigth than having > a full network stack per jail. Yes I can imagine Interface groups coming in handy in firewall setups. You will propably not be able to provide clean semantics for INADDR_ANY with anything but a dedicated virtual stack. A full network stack per jail provides the same semantics as in an environment without jails and all the security of clean separation. A little overhead for security is something I am very willing to pay ;) >> For above reasons I would prefer a clean implementation of full network >> stack virtualisation to something that justs adds names to interfaces. > > Be my guest. For my funded work this is out of scope. I understand that. My only concern is that we will somehow close the door on full network stack virtualisation coming to freebsd. Looking forward to your paper. Greetings Christian -- Christian Kratzer ck@cksoft.de CK Software GmbH http://www.cksoft.de/ Phone: +49 7452 889 135 Fax: +49 7452 889 136 From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 13:45:14 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B378616A41F; Wed, 10 Aug 2005 13:45:14 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id E96E243D45; Wed, 10 Aug 2005 13:45:13 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-1.free.fr (Postfix) with ESMTP id 5A6412DDA9B; Wed, 10 Aug 2005 15:45:11 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id B1CE8405B; Wed, 10 Aug 2005 15:45:23 +0200 (CEST) Date: Wed, 10 Aug 2005 15:45:23 +0200 From: Jeremie Le Hen To: Christian Kratzer Message-ID: <20050810134523.GK45385@obiwan.tataz.chchile.org> References: <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> <200508091737.32391.zec@icir.org> <42F8D8ED.11A196FC@freebsd.org> <20050809211537.GX45385@obiwan.tataz.chchile.org> <42F9E1FB.3ECF023E@freebsd.org> <20050810144407.F97974@vesihiisi.cksoft.de> <42F9F9BF.879994D2@freebsd.org> <20050810151547.X97974@vesihiisi.cksoft.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050810151547.X97974@vesihiisi.cksoft.de> User-Agent: Mutt/1.5.9i Cc: Jeremie Le Hen , freebsd-net@freebsd.org, Marko Zec , Andre Oppermann Subject: Re: Stack virtualization (was: running out of mbufs?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 13:45:14 -0000 On Wed, Aug 10, 2005 at 03:30:32PM +0200, Christian Kratzer wrote: > >>And of course IPv6 for jails is something that could propably be solved > >>in a very clean way using virtual ip stacks as in Marcos patch. > > > >I'll cook something up that uses interface groups and then you can judge > >whether it meets you needs or not. It would be more lightwigth than having > >a full network stack per jail. > > Yes I can imagine Interface groups coming in handy in firewall setups. > You will propably not be able to provide clean semantics for INADDR_ANY > with anything but a dedicated virtual stack. > > A full network stack per jail provides the same semantics as in an > environment without jails and all the security of clean separation. > A little overhead for security is something I am very willing to pay ;) Both approach will require the ability to prevent jailed processes to do certain actions on their virtual interface/stack, such as adding a new IP address, because it has a noticable impact on the real network. I think this could be the job of the MAC framework (although I must admit that I never played with this), but I'm a little bit scared about the administrative overhead this would introduce for managing jails. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 13:48:59 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF89A16A41F; Wed, 10 Aug 2005 13:48:59 +0000 (GMT) (envelope-from steve.langdon@mail.ru) Received: from f31.mail.ru (f31.mail.ru [194.67.57.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6467F43D46; Wed, 10 Aug 2005 13:48:59 +0000 (GMT) (envelope-from steve.langdon@mail.ru) Received: from mail by f31.mail.ru with local id 1E2qwz-0005um-00; Wed, 10 Aug 2005 17:48:57 +0400 Received: from [195.14.57.50] by win.mail.ru with HTTP; Wed, 10 Aug 2005 17:48:57 +0400 From: Steve Langdon To: Sten Daniel S=?koi8-r?Q?=F8?=rsdal Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [195.14.57.50] Date: Wed, 10 Aug 2005 17:48:57 +0400 In-Reply-To: <42FA0295.1030503@wm-access.no> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re[2]: Stranges with ARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Steve Langdon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2005 13:48:59 -0000 Sten, thanks for helping me. Another question: ``route -blackhole' is the same thing like ``arp -S [IP] 00:00:00:00:00'? So packet will ignore on router. Or not? -----Original Message----- From: Sten Daniel Sørsdal To: Steve Langdon Date: Wed, 10 Aug 2005 15:35:17 +0200 Subject: Re: Stranges with ARP [snip] > Using static arp is a very VERY bad idea. > Consider an flood attack against this IP. All packets will be sent to > ALL clients and you would have a hard time tracking down the problem. > > Just use -blackhole or firewall instead. From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 13:57:15 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8CF916A41F; Wed, 10 Aug 2005 13:57:15 +0000 (GMT) (envelope-from ck-lists@cksoft.de) Received: from mx11.cksoft.de (mx11.cksoft.de [62.111.66.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1A7143D45; Wed, 10 Aug 2005 13:57:14 +0000 (GMT) (envelope-from ck-lists@cksoft.de) Received: from vesihiisi.cksoft.de (unknown [192.168.64.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mx12.cksoft.de (Postfix) with ESMTP id 52333B85B; Wed, 10 Aug 2005 15:57:14 +0200 (CEST) Received: from vesihiisi.cksoft.de (localhost [127.0.0.1]) by vesihiisi.cksoft.de (Postfix) with ESMTP id 26E301EB5; Wed, 10 Aug 2005 15:57:12 +0200 (CEST) Received: by vesihiisi.cksoft.de (Postfix, from userid 1000) id EF1411EAC; Wed, 10 Aug 2005 15:57:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by vesihiisi.cksoft.de (Postfix) with ESMTP id E754D1EAB; Wed, 10 Aug 2005 15:57:08 +0200 (CEST) Date: Wed, 10 Aug 2005 15:57:08 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@vesihiisi.cksoft.de To: Jeremie Le Hen In-Reply-To: <20050810134523.GK45385@obiwan.tataz.chchile.org> Message-ID: <20050810154817.A97974@vesihiisi.cksoft.de> References: <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> <200508091737.32391.zec@icir.org> <42F8D8ED.11A196FC@freebsd.org> <20050809211537.GX45385@obiwan.tataz.chchile.org> <42F9E1FB.3ECF023E@freebsd.org> <20050810144407.F97974@vesihiisi.cksoft.de> <42F9F9BF.879994D2@freebsd.org> <20050810151547.X97974@vesihiisi.cksoft.de> <20050810134523.GK45385@obiwan.tataz.chchile.org> X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on vesihiisi.cksoft.de Cc: freebsd-net@freebsd.org, Marko Zec , Andre Oppermann Subject: Re: Stack virtualization (was: running out of mbufs?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Kratzer List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2005 13:57:16 -0000 Hi, On Wed, 10 Aug 2005, Jeremie Le Hen wrote: > On Wed, Aug 10, 2005 at 03:30:32PM +0200, Christian Kratzer wrote: >>>> And of course IPv6 for jails is something that could propably be solved >>>> in a very clean way using virtual ip stacks as in Marcos patch. >>> >>> I'll cook something up that uses interface groups and then you can judge >>> whether it meets you needs or not. It would be more lightwigth than having >>> a full network stack per jail. >> >> Yes I can imagine Interface groups coming in handy in firewall setups. >> You will propably not be able to provide clean semantics for INADDR_ANY >> with anything but a dedicated virtual stack. >> >> A full network stack per jail provides the same semantics as in an >> environment without jails and all the security of clean separation. >> A little overhead for security is something I am very willing to pay ;) > > Both approach will require the ability to prevent jailed processes to > do certain actions on their virtual interface/stack, such as adding a > new IP address, because it has a noticable impact on the real network. > > I think this could be the job of the MAC framework (although I must > admit that I never played with this), but I'm a little bit scared about > the administrative overhead this would introduce for managing jails. yes a jail with its own ip stack could mess up a network as much as a separate machine on the same network could today. Virtual network stacks would primarily bring clean separation and consistent semantics to jails for cases where we require multiple IPv4, IPv6 ips and other protocols. This would be a good thing. One reason multiple IPv4 and especially IPv6 have been missing from jails is propably because the current very simple concept (converting all binds to inaddr_any to the jails ip) does not scale. Interface groups would not help in this area. As to inhibiting a jail from changing its stack so as not to disturb the network. This would indeed need to be addressed perhaps through a mac framework of some kind. Greetings Christian -- Christian Kratzer ck@cksoft.de CK Software GmbH http://www.cksoft.de/ Phone: +49 7452 889 135 Fax: +49 7452 889 136 From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 14:19:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEC4616A41F for ; Wed, 10 Aug 2005 14:19:18 +0000 (GMT) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3273D43D48 for ; Wed, 10 Aug 2005 14:19:18 +0000 (GMT) (envelope-from cjeker@diehard.n-r-g.com) Received: (qmail 29738 invoked by uid 1001); 10 Aug 2005 14:19:38 -0000 Date: Wed, 10 Aug 2005 16:19:16 +0200 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20050810141938.GF31018@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i Subject: Re: Stranges with ARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 14:19:19 -0000 On Wed, Aug 10, 2005 at 05:07:27PM +0400, Steve Langdon wrote: > Hello all. > > Help me to solve a strange conduct. > I want to have permanent bundle with IP->MAC for users in our network to > have some security. So, once my user's MAC doesn't appear in my ARP > table, I have to block by ``arp -S ..' his IP with MAC generated by my > script with prefix d1:fa:28. > > One day I have a phone talk with my user, he make complaints against slow speed in Internet. When I have checked his IP I feel a terrible :) > > tcpdump: listening on rl0 > 18:48:11.339543 213.238.62.65.80 > 192.168.57.90.1072: . 2091947455:2091948915(1460) ack 140637902 win 7441 (DF) [tos 0x60] > ^C > 561 packets received by filter > 0 packets dropped by kernel > > Traffic comes to that user! > > root@router:~ % arp -a | grep -w 192.168.57.90 > ? (192.168.57.90) at d1:fa:28:ec:87:98 on rl0 permanent [ethernet] > root@router:~ % > > While user is blocked by _our_ generated MAC! Btw, could anyone advice > me how to block user IP block without touching ipfw (I think to use > route + ``-blackhole' to that user that have no his MAC in my ARP > table), any ideas? > > > root@router:~ % arping 192.168.57.90 > ARPING 192.168.57.90 > 60 bytes from 00:00:f0:87:4b:ca (192.168.57.90): index=0 time=2.724 msec > 60 bytes from 00:00:f0:87:4b:ca (192.168.57.90): index=1 time=9.966 msec > ^C > --- 192.168.57.90 statistics --- > 2 packets transmitted, 2 packets received, 0% unanswered > root@router:~ % > > His real MAC is 00:00:f0:87:4b:ca. I can't belave this could be. Whats > wrong? > As I think all traffic must transmit to d1:fa:28:ec:87:98, NOT to > 00:00:f0:87:4b:ca and user's NIC must ignore that packet unless his > interface in PROMISC mode. Or I'm wrong? Come on have a look at the MAC address. d1:fa:28:ec:87:98. Ja ja ja d1. Remember the multicast bit of 802.11? No, its the LSB of the first octet. So your outgoing pings are actually multicasts. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 16:34:23 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D55FC16A41F for ; Wed, 10 Aug 2005 16:34:23 +0000 (GMT) (envelope-from vanvorst@ieee.org) Received: from mail.stupendousness.org (67-41-211-151.brbn.qwest.net [67.41.211.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E9FC43D48 for ; Wed, 10 Aug 2005 16:34:22 +0000 (GMT) (envelope-from vanvorst@ieee.org) Received: from brussels.luv.shack (localhost.localdomain [127.0.0.1]) by mail.stupendousness.org (8.13.1/8.13.1) with ESMTP id j7AGYMxv024332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Aug 2005 10:34:22 -0600 Received: (from apache@localhost) by brussels.luv.shack (8.13.1/8.13.1/Submit) id j7AGYL6l024331; Wed, 10 Aug 2005 10:34:21 -0600 X-Authentication-Warning: brussels.luv.shack: apache set sender to vanvorst@ieee.org using -f Received: from 157.127.124.134 (proxying for unknown) (SquirrelMail authenticated user vanvorst) by www.stupendousness.org with HTTP; Wed, 10 Aug 2005 10:34:21 -0600 (MDT) Message-ID: <59841.157.127.124.134.1123691661.squirrel@www.stupendousness.org> Date: Wed, 10 Aug 2005 10:34:21 -0600 (MDT) From: "Nathanael M Van Vorst" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.4-1.FC3 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20050810103421_56376" X-Priority: 3 (Normal) Importance: Normal X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Netgraph question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vanvorst@ieee.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2005 16:34:24 -0000 ------=_20050810103421_56376 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit I sent this is Julian a bit ago. I guess he has been too busy to look into it, so I hope someone else in the community can help! Somehow I lost the screen shot I refer to in the message below (but its trival to reproduce). In brief, the code below is supposed to create a KLD/psuedo-device that I can pass netgraph items to, then later on have a netgraph node get them back. Thanks! --Nate ---------------------------- Original Message ---------------------------- Subject: Re: netgraph question From: "Nathanael M Van Vorst" Date: Wed, July 27, 2005 11:55 am To: "Julian Elischer" -------------------------------------------------------------------------- Sorry my reply has taken so long. I just got back from vacation. Thank you for taking the time to help! I am attaching a bit of code I put together. Its attached as a tar (test.tar). Please note, this is just a hack I have put together to see if I can get this concept working before I integrate this into my larger, rather complicated, project. The tar should extract into a directory named "test". "test" will have the folling structure: test |-echodev.c |-Makefile |-wireMe |-nateNode |-nate.h |-nate.c |-Makefile |-registerNode |-reg.c |-reg.h |-Makfile The tar consits of three things: 1) a node to receive packets, print a message to the long then drop the message, 2) a node that calls system module functions and passes all its items to the system module, 3) a system module or more acturatly a psuedo-device that takes items from a node and puts them on a queue. "wireMe" just loads the correctly KLDs for me and wires up a very simple netgraph graph (which follows). is my ethernet device, is a registerNode and is a nateNode. --> --> When receives the first message, it calls "setMyHook" with the destination hook to . "setMyHook" is in the echoDev and simple stores the pointer if its current pointer is NULL. After calls "setMyHook" is calls "addItem". "addItem" is also in echoDev and simply places the item at the end of the queue. Also in I have tried alot of stuff trying to see what is wrong. All the other crap is just that, crap. First, I cat echo dev. Them I cause packets to be sent to and in turn handed over to the echoDev. After I see echoDev print the syslog that it has 5 or more items, I "cat /dev/echo". cat'ing /dev/echo should case echoDev to call NG_FWD with hook that was passed in and first item that was passed in. This is where it dies. Below are the set of commands I type in the 'test' as root cd test make clean make cd nateNode make clean make cd ../registerNode make clean make cd .. ./wireme cat /dev/echo cat /dev/echo --then the kernel panics. The kernel core is trash so it doesn’t help. I am attaching a screen shot of the panic. Thank you for all your efforts (and for netgraph)! --Nate --------------------------------------- Nathanael Van Vorst Home: vanvorst@ieee.org 303-274-6396 “It is intuitively obvious to even the most casual of observers!” ------=_20050810103421_56376-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 19:27:28 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48E9016A41F for ; Wed, 10 Aug 2005 19:27:28 +0000 (GMT) (envelope-from gpt@tirloni.org) Received: from srv-03.bs2.com.br (srv-03.bs2.com.br [200.203.183.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id D69B743D46 for ; Wed, 10 Aug 2005 19:27:27 +0000 (GMT) (envelope-from gpt@tirloni.org) Received: from localhost (localhost.bs2.com.br [127.0.0.1]) by srv-03.bs2.com.br (Postfix) with ESMTP id 66C144AFAD for ; Wed, 10 Aug 2005 16:28:04 -0300 (BRT) Received: from [172.16.12.100] (unknown [201.14.1.190]) by srv-03.bs2.com.br (Postfix) with ESMTP id 96B7F4ADBE for ; Wed, 10 Aug 2005 16:28:03 -0300 (BRT) Message-ID: <42FA551C.3080903@tirloni.org> Date: Wed, 10 Aug 2005 16:27:24 -0300 From: "Giovanni P. Tirloni" User-Agent: Mozilla Thunderbird 1.0.6-1.4.1.centos4 (X11/20050721) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1d3ed48c05080921492e2c4988@mail.gmail.com> <42F99256.9080003@errno.com> In-Reply-To: <42F99256.9080003@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Atheros 5212 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 19:27:28 -0000 Sam Leffler wrote: > Kevin Downey wrote: > >> I am running a generic kernel with all the debugging knobs. >> if I use BitTorrent or Gnutella in X the computer reboots after a few >> minutes. >> >>> From the console it drops into the debugger deal. But will not give me >> >> a crash dump. > > > The stack trace below isn't a crash, it's just witness warning about a > malloc w/ WAITOK while holding a lock. > > Try updating to BETA2 and getting a trace from the crash. Then also > provide basic info like what you're trying to do at the time. It > appears you're trying to use wpa_supplicant w/ WPA based on the stack > trace. I've an Atheros 5212 on my laptop and it's working with 6.0-BETA2. I'm using just WEP. What I've witnessed is that unloading the module livelocks the machine so I decided to compile it in the kernel. It's been working just fine. -- Giovanni P. Tirloni / gpt@tirloni.org From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 21:54:22 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4010616A41F for ; Wed, 10 Aug 2005 21:54:22 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC6AA43D49 for ; Wed, 10 Aug 2005 21:54:21 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j7ALsJms062104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Aug 2005 14:54:20 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42FA78D4.3080402@errno.com> Date: Wed, 10 Aug 2005 14:59:48 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Giovanni P. Tirloni" References: <1d3ed48c05080921492e2c4988@mail.gmail.com> <42F99256.9080003@errno.com> <42FA551C.3080903@tirloni.org> In-Reply-To: <42FA551C.3080903@tirloni.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Atheros 5212 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 21:54:22 -0000 Giovanni P. Tirloni wrote: > Sam Leffler wrote: > >> Kevin Downey wrote: >> >>> I am running a generic kernel with all the debugging knobs. >>> if I use BitTorrent or Gnutella in X the computer reboots after a few >>> minutes. >>> >>>> From the console it drops into the debugger deal. But will not give me >>> >>> >>> a crash dump. >> >> >> >> The stack trace below isn't a crash, it's just witness warning about a >> malloc w/ WAITOK while holding a lock. >> >> Try updating to BETA2 and getting a trace from the crash. Then also >> provide basic info like what you're trying to do at the time. It >> appears you're trying to use wpa_supplicant w/ WPA based on the stack >> trace. > > > I've an Atheros 5212 on my laptop and it's working with 6.0-BETA2. I'm > using just WEP. > > What I've witnessed is that unloading the module livelocks the machine > so I decided to compile it in the kernel. It's been working just fine. > I don't know what livelock means in this case. I believe current is missing a lock when clearing the node table and I haven't committed code to the crypto modules to track dynamic references and disallow unloads but any of these will cause a panic not a lockup. Sam From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 23:24:39 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DAB416A41F; Wed, 10 Aug 2005 23:24:39 +0000 (GMT) (envelope-from dmehler26@woh.rr.com) Received: from ms-smtp-02-eri0.ohiordc.rr.com (ms-smtp-02-smtplb.ohiordc.rr.com [65.24.5.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA89543D45; Wed, 10 Aug 2005 23:24:38 +0000 (GMT) (envelope-from dmehler26@woh.rr.com) Received: from satellite (cpe-65-31-44-187.woh.res.rr.com [65.31.44.187]) by ms-smtp-02-eri0.ohiordc.rr.com (8.12.10/8.12.7) with SMTP id j7ANOZXV015310; Wed, 10 Aug 2005 19:24:35 -0400 (EDT) Message-ID: <000501c59e02$6ceece00$0200a8c0@satellite> From: "dave" To: Date: Wed, 10 Aug 2005 19:22:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: freebsd-net@freebsd.org Subject: two dc cards on 5.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dave List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2005 23:24:39 -0000 Hello, I'm trying to get a pair of netgear cards to work on a 5.4-RELEASE-p6 box. My rc.conf looks as follows: ifconfig_dc0="DHCP" ifconfig_dc1="inet 192.168.0.200 netmask 255.255.255.255" When i only have one dc card in the box dc0 everything works, the box gets a dhcp ip. Put the second one in regardless whether or not the ifconfig dc1 line is uncommented and two things happen, first i get continuous watchdog timeouts from dc0, second dc0 does not get an IP. As i said the second card doesn't have to be configured, just in the box and it happens, i've checked i/o and irq's neither conflict between the two cards. One thing, with a single dc card the media is set to ethernet autoselect <100base-TX full-duplex and it's listed as active. Put the second card in and dc0 shows media ethernet autoselect but for media type i have none and status is listed as no carrier, i believe this is the reason for the lack of a dhcp ip, my question is i don't understand why. I've tried: ifconfig_dc0_mediaopt="100base-TX, full-duplex" but the system didn't like that. I'd like to tell fbsd specifically what mode these cards are to be probed to in, but nothing seems to work, and this only occurs when the second card is in the box. I've tried three separate cards, all give the same behavior. Some urgency! Any help greatly appreciated. Dave. From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 00:18:07 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84E1016A41F for ; Thu, 11 Aug 2005 00:18:07 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: from seddon.ca (seddon.ca [203.209.212.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 5F48543D48 for ; Thu, 11 Aug 2005 00:18:06 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: (qmail 53636 invoked by uid 89); 11 Aug 2005 00:18:02 -0000 Received: by seddon.ca (tmda-sendmail, from uid 89); Thu, 11 Aug 2005 10:18:00 +1000 (EST) References: <000501c59e02$6ceece00$0200a8c0@satellite> In-Reply-To: <000501c59e02$6ceece00$0200a8c0@satellite> To: dave Date: Thu, 11 Aug 2005 10:17:59 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <1123719480.53612.TMDA@seddon.ca> X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Dave+Seddon Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: two dc cards on 5.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave+Seddon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2005 00:18:07 -0000 google = "freebsd media rc.conf" -> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/config-network-set up.html Section shows: ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0" ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP" So you want: ifconfig_dc0="100baseTX mediaopt full-duplex" ifconfig_dc1="100baseTX mediaopt full-duplex" Regards, Dave Seddon dave writes: > Hello, > I'm trying to get a pair of netgear cards to work on a 5.4-RELEASE-p6 > box. My rc.conf looks as follows: > > ifconfig_dc0="DHCP" > ifconfig_dc1="inet 192.168.0.200 netmask 255.255.255.255" > > When i only have one dc card in the box dc0 everything works, the box gets a > dhcp ip. Put the second one in regardless whether or not the ifconfig dc1 > line is uncommented and two things happen, first i get continuous watchdog > timeouts from dc0, second dc0 does not get an IP. As i said the second card > doesn't have to be configured, just in the box and it happens, i've checked > i/o and irq's neither conflict between the two cards. One thing, with a > single dc card the media is set to ethernet autoselect <100base-TX > full-duplex and it's listed as active. Put the second card in and dc0 shows > media ethernet autoselect but for media type i have none and status is > listed as no carrier, i believe this is the reason for the lack of a dhcp > ip, my question is i don't understand why. I've tried: > ifconfig_dc0_mediaopt="100base-TX, full-duplex" > but the system didn't like that. I'd like to tell fbsd specifically what > mode these cards are to be probed to in, but nothing seems to work, and this > only occurs when the second card is in the box. I've tried three separate > cards, all give the same behavior. > Some urgency! Any help greatly appreciated. > Dave. > > _______________________________________________ > 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 Aug 11 00:25:24 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E52E16A41F for ; Thu, 11 Aug 2005 00:25:24 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE82143D49 for ; Thu, 11 Aug 2005 00:25:21 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.5.8] (host-81-191-3-170.bluecom.no [81.191.3.170]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j7B0PJdm031658; Thu, 11 Aug 2005 02:25:19 +0200 Message-ID: <42FA9AD9.1070901@wm-access.no> Date: Thu, 11 Aug 2005 02:24:57 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Langdon References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 OpenPGP: id=AE7F1636 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Stranges with ARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 00:25:24 -0000 Steve Langdon wrote: > Sten, thanks for helping me. > > Another question: ``route -blackhole' is the same thing like ``arp -S [IP] 00:00:00:00:00'? So packet will ignore on router. Or not? > > -blackhole would drop any packets matching that route. That is, it drops packets coming from say the internet going to the user in question. It will not block packets coming from the user and going to the internet. This would open up for the possibility of flooding attacks from the user. Perhaps a better solution would be to use address lists in ipfw or pf and drop all traffic to and from a particular ip address. ipfw can also filter on mac addresses, which could help a potential ip stealing issue without the hazards of using static arp. Just a thought. -- Sten Daniel Sørsdal From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 02:14:44 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DB0C16A420 for ; Thu, 11 Aug 2005 02:14:44 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from dmzraw5.extranet.tce.com (dmzraw5.extranet.tce.com [157.254.234.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CFBB43D55 for ; Thu, 11 Aug 2005 02:14:41 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from indyvss2.am.thmulti.com (unknown [157.254.92.61]) by dmzraw5.extranet.tce.com (Postfix) with ESMTP id 11E6F919 for ; Thu, 11 Aug 2005 02:14:41 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by indyvss2.am.thmulti.com (Postfix) with ESMTP id F27A33442 for ; Thu, 11 Aug 2005 02:14:40 +0000 (GMT) Received: from indyvss2.am.thmulti.com ([127.0.0.1]) by localhost (indyvss2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13468-01-23 for ; Thu, 11 Aug 2005 02:14:37 +0000 (GMT) Received: from smtprelay2.indy.tce.com (smtprelay2.indy.tce.com [157.254.96.95]) by indyvss2.am.thmulti.com (Postfix) with ESMTP id 0D0E23469 for ; Thu, 11 Aug 2005 02:14:37 +0000 (GMT) Received: from boulsmailbh02.eu.thmulti.com (localhost [127.0.0.1]) by smtprelay2.indy.tce.com (8.12.9/8.12.8) with ESMTP id j7B2EChD001100 for ; Thu, 11 Aug 2005 02:14:36 GMT Received: from tahkexch2k.ap.thmulti.com ([141.11.13.12]) by boulsmailbh02.eu.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Aug 2005 04:14:34 +0200 Received: from tahksmail01.ap.thmulti.com ([141.11.13.38]) by tahkexch2k.ap.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Aug 2005 10:13:41 +0800 Received: from bjngsmail01.ap.thmulti.com ([10.11.70.35]) by tahksmail01.ap.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Aug 2005 10:13:41 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Aug 2005 10:13:38 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why Ierrs is so high? Thread-Index: AcWeGkZPoF6NBTzDTQuM4e7uxLUcRw== From: "Mao Shou Yan" To: X-OriginalArrivalTime: 11 Aug 2005 02:13:41.0396 (UTC) FILETIME=[4AF6E540:01C59E1A] X-Virus-Scanned: amavisd-new at thomson.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Why Ierrs is so high? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 02:14:44 -0000 Hi, all, I have a machine with 3 Intel pro1000 cards. em0 is in promisc mode, whose MAC controller is 82543 using fiber line connected. em1, em2 is not connected with cable. Driver configuration is the default, RXD is 256, TXD is 256. =20 Result of "netstat -i": =20 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll=20 em0 1500 00:03:47:de:72:36 1701943600 369823630 1 0 0=20 em1 1500 00:10:dc:56:8b:b5 5561 0 4608 0 0=20 em2 1500 00:03:47:42:6d:17 0 0 0 0 0 =20 Pps of em0 is about 20k/pps, and bandwidth is no more than 150Mbps. When I use "sysctl hw.em0.stats=3D1", I found the number of "missed packets" is very high, which is about equal Ierrs. And I also found the number of"receive with no buffers"is raising with about 10 per second. =20 The machine is no extra load, only a raw system with em0 in promisc mode! =20 I'm looking forward your help! From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 02:26:06 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CF1F16A41F for ; Thu, 11 Aug 2005 02:26:06 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: from seddon.ca (seddon.ca [203.209.212.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 53EA343D49 for ; Thu, 11 Aug 2005 02:26:05 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: (qmail 64696 invoked by uid 89); 11 Aug 2005 02:26:01 -0000 Received: by seddon.ca (tmda-sendmail, from uid 89); Thu, 11 Aug 2005 12:26:00 +1000 (EST) References: In-Reply-To: To: freebsd-net@freebsd.org Date: Thu, 11 Aug 2005 12:25:59 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit From: Dave+Seddon Message-ID: <1123727160.64678.TMDA@seddon.ca> X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) Subject: Re: Why Ierrs is so high? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave+Seddon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2005 02:26:06 -0000 Greetings, Yeah I'd say there is something funny also. I've stuffed around with HZ and polling settings heaps and could only manage about 120MB/s-ish of HTTP traffic. I'm as running 5.4-stable from about 2-3 weeks ago. /etc/sysctl.conf kern.polling.enable=1 kern.polling.each_burst=50 #need to edit /usr/src/sys/kern/kern_poll.c for set this kern.polling.burst_max=1500 #DO NOT SET THIS HIGHER THAN 65536 * 2 (FREEBSD BUG) net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 kern.ipc.somaxconn=1024 I still get lots of kern.polling.lost_polls and kern.polling.suspect. How do you edit the RXD is 256, TXD is 256? How do you view the errors when you set "sysctl hw.em0.stats=1"? Regards, Dave Mao Shou Yan writes: > Hi, all, > > I have a machine with 3 Intel pro1000 cards. > > em0 is in promisc mode, whose MAC controller is 82543 using fiber line > connected. > > em1, em2 is not connected with cable. > > Driver configuration is the default, RXD is 256, TXD is 256. > > > > Result of "netstat -i": > > > > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > em0 1500 00:03:47:de:72:36 1701943600 369823630 1 0 0 > em1 1500 00:10:dc:56:8b:b5 5561 0 4608 0 0 > em2 1500 00:03:47:42:6d:17 0 0 0 0 0 > > > > Pps of em0 is about 20k/pps, and bandwidth is no more than 150Mbps. > > When I use "sysctl hw.em0.stats=1", I found the number of "missed > packets" is very high, which is about equal Ierrs. > > And I also found the number of"receive with no buffers"is raising with > about 10 per second. > > > > The machine is no extra load, only a raw system with em0 in promisc > mode! > > > > I'm looking forward your help! > > _______________________________________________ > 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 Aug 11 02:42:30 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9E5716A41F for ; Thu, 11 Aug 2005 02:42:30 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from dmzraw5.extranet.tce.com (dmzraw5.extranet.tce.com [157.254.234.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A7A343D45 for ; Thu, 11 Aug 2005 02:42:30 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from indyvss2.am.thmulti.com (unknown [157.254.92.61]) by dmzraw5.extranet.tce.com (Postfix) with ESMTP id A5BD5B2C for ; Thu, 11 Aug 2005 02:42:29 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by indyvss2.am.thmulti.com (Postfix) with ESMTP id 990388C03 for ; Thu, 11 Aug 2005 02:42:29 +0000 (GMT) Received: from indyvss2.am.thmulti.com ([127.0.0.1]) by localhost (indyvss2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17699-01-50 for ; Thu, 11 Aug 2005 02:42:27 +0000 (GMT) Received: from indysmailcs01.am.thmulti.com (indysmailcs01.am.thmulti.com [157.254.96.5]) by indyvss2.am.thmulti.com (Postfix) with ESMTP id A5C7D8C0A for ; Thu, 11 Aug 2005 02:42:27 +0000 (GMT) Received: from indysmailbh01.am.thmulti.com ([157.254.96.4]) by indysmailcs01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Aug 2005 21:42:27 -0500 Received: from tahkexch2k.ap.thmulti.com ([141.11.13.12]) by indysmailbh01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Aug 2005 21:42:27 -0500 Received: from tahksmail01.ap.thmulti.com ([141.11.13.38]) by tahkexch2k.ap.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Aug 2005 10:40:45 +0800 Received: from bjngsmail01.ap.thmulti.com ([10.11.70.35]) by tahksmail01.ap.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Aug 2005 10:40:44 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Aug 2005 10:40:36 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why Ierrs is so high? Thread-Index: AcWeHGtO6EMUAyg8S1yNRq1vj9A6pQAAB/DwAABcx1A= From: "Mao Shou Yan" To: X-OriginalArrivalTime: 11 Aug 2005 02:40:44.0395 (UTC) FILETIME=[1258E3B0:01C59E1E] X-Virus-Scanned: amavisd-new at thomson.net Subject: FW: Why Ierrs is so high? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 02:42:31 -0000 -----Original Message----- From: Mao Shou Yan=20 Sent: 2005=C4=EA8=D4=C211=C8=D5 10:34 To: 'Dave+Seddon' Subject: RE: Why Ierrs is so high? I'm also using polling enable and set HZ to 10000, the CPU is p4 3.0G. The system is 5.4 too. My conf: kern.polling.enable=3D1 kern.polling.burst_max=3D600 kern.polling.each_burst=3D10 And also gots lots of kern.polling.lost_polls and kern.polling.suspect. -----Original Message----- From: owner-freebsd-net@freebsd.org = [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Dave+Seddon Sent: 2005=C4=EA8=D4=C211=C8=D5 10:26 To: freebsd-net@freebsd.org Subject: Re: Why Ierrs is so high? Greetings,=20 Yeah I'd say there is something funny also. I've stuffed around with HZ = and=20 polling settings heaps and could only manage about 120MB/s-ish of HTTP=20 traffic. I'm as running 5.4-stable from about 2-3 weeks ago.=20 /etc/sysctl.conf kern.polling.enable=3D1 kern.polling.each_burst=3D50 #need to edit /usr/src/sys/kern/kern_poll.c for set this kern.polling.burst_max=3D1500 #DO NOT SET THIS HIGHER THAN 65536 * 2 (FREEBSD BUG) net.inet.tcp.sendspace=3D131072 net.inet.tcp.recvspace=3D131072 kern.random.sys.harvest.ethernet=3D0 kern.random.sys.harvest.interrupt=3D0 kern.ipc.somaxconn=3D1024=20 I still get lots of kern.polling.lost_polls and kern.polling.suspect.=20 How do you edit the RXD is 256, TXD is 256? ---> in /usr/src/sys/dev/em/if_em.h, the default is 256/256. How do you view the errors when you set "sysctl hw.em0.stats=3D1"?=20 ----> sysctl hw.em0.stats=3D1, then see it using dmesg. Regards, Dave=20 Mao Shou Yan writes:=20 > Hi, all,=20 >=20 > I have a machine with 3 Intel pro1000 cards.=20 >=20 > em0 is in promisc mode, whose MAC controller is 82543 using fiber line > connected.=20 >=20 > em1, em2 is not connected with cable.=20 >=20 > Driver configuration is the default, RXD is 256, TXD is 256.=20 >=20 > =20 >=20 > Result of "netstat -i":=20 >=20 > =20 >=20 > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll=20 > em0 1500 00:03:47:de:72:36 1701943600 369823630 1 0 0=20 > em1 1500 00:10:dc:56:8b:b5 5561 0 4608 0 0=20 > em2 1500 00:03:47:42:6d:17 0 0 0 0 0=20 >=20 > =20 >=20 > Pps of em0 is about 20k/pps, and bandwidth is no more than 150Mbps.=20 >=20 > When I use "sysctl hw.em0.stats=3D1", I found the number of "missed > packets" is very high, which is about equal Ierrs.=20 >=20 > And I also found the number of"receive with no buffers"is raising with > about 10 per second.=20 >=20 > =20 >=20 > The machine is no extra load, only a raw system with em0 in promisc > mode!=20 >=20 > =20 >=20 > I'm looking forward your help!=20 >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" =20 _______________________________________________ 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 Aug 11 04:03:23 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60E0A16A41F for ; Thu, 11 Aug 2005 04:03:23 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: from seddon.ca (seddon.ca [203.209.212.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 8CC1C43D45 for ; Thu, 11 Aug 2005 04:03:22 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: (qmail 72482 invoked by uid 89); 11 Aug 2005 04:03:19 -0000 Received: by seddon.ca (tmda-sendmail, from uid 89); Thu, 11 Aug 2005 14:03:18 +1000 (EST) References: In-Reply-To: To: "Mao Shou Yan" Date: Thu, 11 Aug 2005 14:03:17 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <1123732998.72461.TMDA@seddon.ca> X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Dave+Seddon Cc: freebsd-net@freebsd.org Subject: Re: Why Ierrs is so high? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave+Seddon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2005 04:03:23 -0000 Greetings, Also, how were you measuring the packet and data rate? What were you using to generate the traffic? I used /usr/ports/benchmark/siege and /usr/ports/www/thttpd. Regards, Dave Mao Shou Yan writes: > Hi, all, > > I have a machine with 3 Intel pro1000 cards. > > em0 is in promisc mode, whose MAC controller is 82543 using fiber line > connected. > > em1, em2 is not connected with cable. > > Driver configuration is the default, RXD is 256, TXD is 256. > > > > Result of "netstat -i": > > > > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > em0 1500 00:03:47:de:72:36 1701943600 369823630 1 0 0 > em1 1500 00:10:dc:56:8b:b5 5561 0 4608 0 0 > em2 1500 00:03:47:42:6d:17 0 0 0 0 0 > > > > Pps of em0 is about 20k/pps, and bandwidth is no more than 150Mbps. > > When I use "sysctl hw.em0.stats=1", I found the number of "missed > packets" is very high, which is about equal Ierrs. > > And I also found the number of"receive with no buffers"is raising with > about 10 per second. > > > > The machine is no extra load, only a raw system with em0 in promisc > mode! > > > > I'm looking forward your help! > > _______________________________________________ > 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 Aug 11 04:17:32 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9023F16A41F for ; Thu, 11 Aug 2005 04:17:32 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EC5443D55 for ; Thu, 11 Aug 2005 04:17:31 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-2.free.fr (Postfix) with ESMTP id 960712BBAA9; Thu, 11 Aug 2005 06:17:30 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 365D9405C; Thu, 11 Aug 2005 06:17:39 +0200 (CEST) Date: Thu, 11 Aug 2005 06:17:38 +0200 From: Jeremie Le Hen To: Mao Shou Yan Message-ID: <20050811041738.GP45385@obiwan.tataz.chchile.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: Why Ierrs is so high? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 04:17:32 -0000 Hi, > I have a machine with 3 Intel pro1000 cards. > > em0 is in promisc mode, whose MAC controller is 82543 using fiber line > connected. > > em1, em2 is not connected with cable. > > Driver configuration is the default, RXD is 256, TXD is 256. > > > > Result of "netstat -i": > > > > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > em0 1500 00:03:47:de:72:36 1701943600 369823630 1 0 0 > em1 1500 00:10:dc:56:8b:b5 5561 0 4608 0 0 > em2 1500 00:03:47:42:6d:17 0 0 0 0 0 > > > > Pps of em0 is about 20k/pps, and bandwidth is no more than 150Mbps. > > When I use "sysctl hw.em0.stats=1", I found the number of "missed > packets" is very high, which is about equal Ierrs. > > And I also found the number of"receive with no buffers"is raising with > about 10 per second. > > > > The machine is no extra load, only a raw system with em0 in promisc > mode! Did you try another em(4) interface ? Do you have the same behaviour in this case ? It seems that em1 has a weird Opkts too. What is em1 being used for ? If you're still having error after switching interfaces, maybe it's time to check your cable. Finally, what are you running ? [ ] RELENG_4 [ ] RELENG_5 [ ] RELENG_6 [ ] CURRENT Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 13:44:24 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A837D16A41F for ; Thu, 11 Aug 2005 13:44:24 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: from mail.lrtc.lt (pegasus.lrtc.lt [217.9.240.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8A7C43D45 for ; Thu, 11 Aug 2005 13:44:23 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: (qmail 21174 invoked from network); 11 Aug 2005 13:43:58 -0000 Received: from p2p-241-242-ird.vln0.lrtc.net (HELO donatas) (d.gendvilas@[217.9.241.242]) (envelope-sender ) by mail.lrtc.lt (qmail-ldap-1.03) with SMTP for ; 11 Aug 2005 13:43:58 -0000 Message-ID: <026001c59e7a$c6ca69c0$9f90a8c0@donatas> From: "Donatas" To: Date: Thu, 11 Aug 2005 16:44:20 +0300 Organization: AB Lietuvos Radijo ir Televizijos Centras MIME-Version: 1.0 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 Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: routing problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Donatas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2005 13:44:24 -0000 please see the scheme below: user1---[usa]-------->machine1 machine2 vlan1(default gw) = vlan1---------------->em0(USA) ?<--------------- = -=3D-=3D-=3D-=3D--> (zebra,ospf) = =20 user2=3D=3D[europe]=3D=3D=3D>vlan2(ospf,zebra) = vlan2=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>em1(EUROPE) = ?<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I've encountered a serious problem. I must differentiate USA and EUROPE = subnets into two different vlans between two different machies. First = machine gets USA traffic to em0 and EUROPE traffic to em1. When user1 = tries to reach USA IP, he does not gets any routes via ospf, so he = passes through machine's1default gw via vlan1. When user2 tries to reach = EUROPE IP he get's ospf routes from vlan2 and goes out via that vlan2. = The problem is with inbound traffic. How can machine2 divert inbound USA = traffic to vlan1, and inbound EUROPE traffic to vlan2?The problem should = be solved in IP level only. Zebra(ospf) is unable to do that and I = cannot change vlan or interface structure because of certain reasons:( Thanks for any ideas. bsd5.4 From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 14:38:32 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4297216A41F; Thu, 11 Aug 2005 14:38:32 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from rms06.rommon.net (rms06.rommon.net [212.54.5.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E774F43D49; Thu, 11 Aug 2005 14:38:31 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.234] (dyn234.helenius.fi [193.64.42.234]) by rms06.rommon.net (Postfix) with ESMTP id 2CD9833C1B; Thu, 11 Aug 2005 17:38:27 +0300 (EEST) Message-ID: <42FB62E3.4050908@he.iki.fi> Date: Thu, 11 Aug 2005 17:38:27 +0300 From: Petri Helenius User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD - net , freebsd-amd64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: libthr and 64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 14:38:32 -0000 Does libthr work on amd64 in RELENG_6? Pete From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 16:13:40 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BDED16A41F for ; Thu, 11 Aug 2005 16:13:40 +0000 (GMT) (envelope-from redchin@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3DA343D48 for ; Thu, 11 Aug 2005 16:13:39 +0000 (GMT) (envelope-from redchin@gmail.com) Received: by wproxy.gmail.com with SMTP id i5so401954wra for ; Thu, 11 Aug 2005 09:13:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WXdF0uvaAUHhzpapkp59ilDgDs8Yo3ILYD6gk4KRLmivCKQeh2UmCt9ihGtSKH8h7fSY8APJxWM2NIqY/sprKzoow7JQ3oORTgUxPHyiCrtKy+AVELlhmeYIx/hjnkRpwetbONLu/yA1Bp900SWpqqxgpTzt4OXAuic47ezL6V8= Received: by 10.54.49.72 with SMTP id w72mr1306401wrw; Thu, 11 Aug 2005 09:13:38 -0700 (PDT) Received: by 10.54.160.3 with HTTP; Thu, 11 Aug 2005 09:13:38 -0700 (PDT) Message-ID: <1d3ed48c050811091354d28d54@mail.gmail.com> Date: Thu, 11 Aug 2005 09:13:38 -0700 From: Kevin Downey To: freebsd-net@freebsd.org In-Reply-To: <42FA78D4.3080402@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1d3ed48c05080921492e2c4988@mail.gmail.com> <42F99256.9080003@errno.com> <42FA551C.3080903@tirloni.org> <42FA78D4.3080402@errno.com> Subject: Re: Atheros 5212 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 16:13:40 -0000 On 8/10/05, Sam Leffler wrote: > Giovanni P. Tirloni wrote: > > Sam Leffler wrote: > > > >> Kevin Downey wrote: > >> > >>> I am running a generic kernel with all the debugging knobs. > >>> if I use BitTorrent or Gnutella in X the computer reboots after a few > >>> minutes. > >>> > >>>> From the console it drops into the debugger deal. But will not give = me > >>> > >>> > >>> a crash dump. > >> > >> > >> This seems to be fixed. I cvsupped to 6.0beta2 and still had problems. Then because I did not know what else to do I recompiled the kernel wit h PREEMPTION. Everything seems fine and dandy now... -- "These words are razors to my wounded heart" From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 18:47:35 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF37916A421 for ; Thu, 11 Aug 2005 18:47:35 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4651243D49 for ; Thu, 11 Aug 2005 18:47:35 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.10.10.238] (mail.atheros.com [12.36.123.2]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j7BIlYBd067225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Aug 2005 11:47:34 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42FB9D41.50004@errno.com> Date: Thu, 11 Aug 2005 11:47:29 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Downey References: <1d3ed48c05080921492e2c4988@mail.gmail.com> <42F99256.9080003@errno.com> <42FA551C.3080903@tirloni.org> <42FA78D4.3080402@errno.com> <1d3ed48c050811091354d28d54@mail.gmail.com> In-Reply-To: <1d3ed48c050811091354d28d54@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-dcc.uncw.edu-Metrics: ebb.errno.com 1201; Body=2 Fuz1=2 Fuz2=2 Cc: freebsd-net@freebsd.org Subject: Re: Atheros 5212 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 18:47:36 -0000 Kevin Downey wrote: > On 8/10/05, Sam Leffler wrote: > >>Giovanni P. Tirloni wrote: >> >>>Sam Leffler wrote: >>> >>> >>>>Kevin Downey wrote: >>>> >>>> >>>>>I am running a generic kernel with all the debugging knobs. >>>>>if I use BitTorrent or Gnutella in X the computer reboots after a few >>>>>minutes. >>>>> >>>>> >>>>>>From the console it drops into the debugger deal. But will not give me >>>>> >>>>> >>>>>a crash dump. >>>> >>>> >>>> > > This seems to be fixed. I cvsupped to 6.0beta2 and still had problems. > Then because I did not know what else to do I recompiled the kernel > wit h PREEMPTION. Everything seems fine and dandy now... You should not need to rebuild w/ PREEMPTION. If there's a problem with ath I'd like to know so if you can tell me the steps you used to trigger the problem it'd be appreciated. As I said I'm aware of some issues with unloading if_ath and wlan & co as modules--there is a locking assertion that is not satisfied and dynamic references to the cipher modules (and also wlan_acl) are not tracked so it's possible to unload one module when another still has references to code+data. I've got fixes for all these things but haven't committed them yet. Sam From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 19:45:32 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 700C216A41F; Thu, 11 Aug 2005 19:45:32 +0000 (GMT) (envelope-from pingali@ISI.EDU) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB37643D45; Thu, 11 Aug 2005 19:45:31 +0000 (GMT) (envelope-from pingali@ISI.EDU) Received: from [127.0.0.1] (boreas.isi.edu [128.9.160.161]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BJi6f12908; Thu, 11 Aug 2005 12:44:06 -0700 (PDT) Message-ID: <42FBAA86.5090002@isi.edu> Date: Thu, 11 Aug 2005 12:44:06 -0700 From: Venkata Pingali User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Kratzer References: <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> <200508091737.32391.zec@icir.org> <42F8D8ED.11A196FC@freebsd.org> <20050809211537.GX45385@obiwan.tataz.chchile.org> <42F9E1FB.3ECF023E@freebsd.org> <20050810144407.F97974@vesihiisi.cksoft.de> <42F9F9BF.879994D2@freebsd.org> <20050810151547.X97974@vesihiisi.cksoft.de> <20050810134523.GK45385@obiwan.tataz.chchile.org> <20050810154817.A97974@vesihiisi.cksoft.de> In-Reply-To: <20050810154817.A97974@vesihiisi.cksoft.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: pingali@isi.edu Cc: freebsd-net@freebsd.org, Andre Oppermann , Marko Zec , Jeremie Le Hen Subject: Re: Stack virtualization X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 19:45:32 -0000 Christian Kratzer wrote: > Hi, > > On Wed, 10 Aug 2005, Jeremie Le Hen wrote: > >> On Wed, Aug 10, 2005 at 03:30:32PM +0200, Christian Kratzer wrote: >> >>>>> And of course IPv6 for jails is something that could propably be >>>>> solved >>>>> in a very clean way using virtual ip stacks as in Marcos patch. >>>> >>>> >>>> I'll cook something up that uses interface groups and then you can >>>> judge >>>> whether it meets you needs or not. It would be more lightwigth >>>> than having >>>> a full network stack per jail. >>> >>> >>> Yes I can imagine Interface groups coming in handy in firewall setups. >>> You will propably not be able to provide clean semantics for INADDR_ANY >>> with anything but a dedicated virtual stack. >>> >>> A full network stack per jail provides the same semantics as in an >>> environment without jails and all the security of clean separation. >>> A little overhead for security is something I am very willing to pay ;) >> >> >> Both approach will require the ability to prevent jailed processes to >> do certain actions on their virtual interface/stack, such as adding a >> new IP address, because it has a noticable impact on the real network. >> >> I think this could be the job of the MAC framework (although I must >> admit that I never played with this), but I'm a little bit scared about >> the administrative overhead this would introduce for managing jails. > > > yes a jail with its own ip stack could mess up a network as much as a > separate machine on the same network could today. > > Virtual network stacks would primarily bring clean separation and > consistent semantics to jails for cases where we require multiple > IPv4, IPv6 ips and other protocols. This would be a good thing. We have a demonstration of that. We have been using the stacks to create complete and multiple virtual networks over the same set of hosts. We could do this with minimal effort. Standard applications including ping and traceroute work unmodified just like how they would do in the regular network. This could not be possible without support for appropriate host and router RFCs i.e., without each stack emulating a complete internet host. Stacks have to do more with isolation and abstraction. They provide the context for other network operations including binding, forwarding, lookup, firewalling etc. The question then becomes whether one feels that it is necessary to support complete virtual hosts or not. > > One reason multiple IPv4 and especially IPv6 have been missing from > jails is propably because the current very simple concept (converting > all binds to inaddr_any to the jails ip) does not scale. Interface > groups would not help in this area. > > As to inhibiting a jail from changing its stack so as not to disturb > the network. This would indeed need to be addressed perhaps through > a mac framework of some kind. > > Greetings > Christian > From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 02:08:14 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF90F16A41F for ; Fri, 12 Aug 2005 02:08:14 +0000 (GMT) (envelope-from jha0147@yahoo.com) Received: from web34105.mail.mud.yahoo.com (web34105.mail.mud.yahoo.com [66.163.178.103]) by mx1.FreeBSD.org (Postfix) with SMTP id 74A2443D45 for ; Fri, 12 Aug 2005 02:08:14 +0000 (GMT) (envelope-from jha0147@yahoo.com) Received: (qmail 30075 invoked by uid 60001); 12 Aug 2005 02:08:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tzObLGwLWNpAJi+DNYRxKQoQNh7CRk3144678+srKPjgtPfVC7x96Xcemhp7/0aj2mdXcHyQXwXYub7qJscQMy1/wtVJPZrs6hBwKXX4nfsnq02Eg4dMzYlqlmn3HcozFjL4Eu5qP3e5Aq/jFUQSsvbaEWbbGKDtGBFDkXzkRvc= ; Message-ID: <20050812020814.30073.qmail@web34105.mail.mud.yahoo.com> Received: from [69.236.90.193] by web34105.mail.mud.yahoo.com via HTTP; Thu, 11 Aug 2005 19:08:13 PDT Date: Thu, 11 Aug 2005 19:08:13 -0700 (PDT) From: jha miku To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Question regd timestamp option X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 02:08:15 -0000 In case of active open, the SYN segments always have timestamp enabled, since the RFC flg is set. But, Currently, I am seeing some SYN segments without timestamp option. The only condition that I am aware of when timestamp is disabled, is on sending the 3rd SYN in retransmit code when the timestamp gets disabled. looking at the tcpdump, it is unclear why the SYNs are sent during active open without timestamp option. Are there other situations when timestamp gets disabled? Please let me know. Thanks. ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 05:34:47 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 857D616A41F for ; Fri, 12 Aug 2005 05:34:47 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CB1843D49 for ; Fri, 12 Aug 2005 05:34:46 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (h192.p058.iij4u.or.jp [210.130.58.192]) by r-dd.iij4u.or.jp (4U-MR/r-dd) id j7C5YXKC025012; Fri, 12 Aug 2005 14:34:43 +0900 (JST) Date: Fri, 12 Aug 2005 14:34:30 +0900 (JST) Message-Id: <20050812.143430.37456105.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: jha miku In-Reply-To: <20050812020814.30073.qmail@web34105.mail.mud.yahoo.com> References: <20050812020814.30073.qmail@web34105.mail.mud.yahoo.com> X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Question regd timestamp option X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 05:34:47 -0000 > Are there other situations when timestamp gets disabled? In case of active open and net.inet.tcp.rfc1323 is set to non-zero, one possibility is TCP_NOOPT is turned on by setsockopt(). But I do not know which applications use TCP_NOOPT. Regards, Noritoshi Demizu > From: jha miku > To: freebsd-net@freebsd.org > Subject: Question regd timestamp option > Date: Thu, 11 Aug 2005 19:08:13 -0700 (PDT) > > In case of active open, the SYN segments always have > timestamp enabled, since the RFC flg is set. But, > Currently, I am seeing some SYN segments without > timestamp option. > > The only condition that I am aware of when timestamp is > disabled, is on sending the 3rd SYN in retransmit code > when the timestamp gets disabled. > looking at the tcpdump, it is unclear why the SYNs are > sent during active open without timestamp option. > > Are there other situations when timestamp gets > disabled? > Please let me know. > Thanks. > > ____________________________________________________ > Start your day with Yahoo! - make it your home page > http://www.yahoo.com/r/hs > > _______________________________________________ > 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 Aug 12 05:52:29 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ABC816A41F for ; Fri, 12 Aug 2005 05:52:29 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from dmzraw5.extranet.tce.com (dmzraw5.extranet.tce.com [157.254.234.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83CAD43D45 for ; Fri, 12 Aug 2005 05:52:28 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from indyvss4.am.thmulti.com (unknown [157.254.92.63]) by dmzraw5.extranet.tce.com (Postfix) with ESMTP id 668ACB3C for ; Fri, 12 Aug 2005 05:52:27 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by indyvss4.am.thmulti.com (Postfix) with ESMTP id 30385210A0 for ; Fri, 12 Aug 2005 05:50:24 +0000 (GMT) Received: from indyvss4.am.thmulti.com ([127.0.0.1]) by localhost (indyvss4 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13178-01-37 for ; Fri, 12 Aug 2005 05:50:22 +0000 (GMT) Received: from indysmailcs01.am.thmulti.com (indysmailcs01.am.thmulti.com [157.254.96.5]) by indyvss4.am.thmulti.com (Postfix) with ESMTP id CE581210A5 for ; Fri, 12 Aug 2005 05:50:22 +0000 (GMT) Received: from indysmailbh01.am.thmulti.com ([157.254.96.4]) by indysmailcs01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Aug 2005 00:52:26 -0500 Received: from tahkexch2k.ap.thmulti.com ([141.11.13.12]) by indysmailbh01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Aug 2005 00:52:25 -0500 Received: from bjngsmail01.ap.thmulti.com ([10.11.70.35]) by tahkexch2k.ap.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Aug 2005 13:50:38 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Aug 2005 13:48:59 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: problems with em(4) Thread-Index: AcWfAYXhYy8f7NOvRF6hsbrSgr+HxA== From: "Mao Shou Yan" To: X-OriginalArrivalTime: 12 Aug 2005 05:50:38.0688 (UTC) FILETIME=[C449C600:01C59F01] X-Virus-Scanned: amavisd-new at thomson.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: problems with em(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: Fri, 12 Aug 2005 05:52:29 -0000 I have a machine running 5.4 stable, with 3 em cards: (1) Two 82543GC with fiber=20 (2) One 82544 All of them are shared irq 11( from vmstat -i) =20 The problem is: After the system run about 3 hours, there will be large "Ierrs" with the em0(BTW, em0 is in promisc mode). I use "sysctl hw.em0.stats=3D1", found there are a lot of = "missed packets" and some "Receive with no buffers". Em0 is in polling mode, and hz is 2000, burst_max and each_burst is the default value. The system is not heavy loaded, incoming rates of em0 is less than 150Mbits/s. em1 and em2 are not connected. And pps is less than 30k. After 3 hours, the ierrs raise quickly every 1 minutes! From pciconf, I found the driver version is "1.7.35". =20 I think is a problem with em(4) driver. Anyone meet such condition? =20 =20 From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 05:52:46 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5742E16A41F for ; Fri, 12 Aug 2005 05:52:46 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: from mail.lrtc.lt (pegasus.lrtc.lt [217.9.240.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id B312243D45 for ; Fri, 12 Aug 2005 05:52:45 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: (qmail 2293 invoked from network); 12 Aug 2005 05:52:17 -0000 Received: from p2p-241-242-ird.vln0.lrtc.net (HELO donatas) (d.gendvilas@[217.9.241.242]) (envelope-sender ) by mail.lrtc.lt (qmail-ldap-1.03) with SMTP for ; 12 Aug 2005 05:52:17 -0000 Message-ID: <027701c59f02$0eb808a0$9f90a8c0@donatas> From: "Donatas" To: "Julian Elischer" References: <026001c59e7a$c6ca69c0$9f90a8c0@donatas> <42FBC0AE.8020803@elischer.org> Date: Fri, 12 Aug 2005 08:52:43 +0300 Organization: AB Lietuvos Radijo ir Televizijos Centras MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 Cc: freebsd-net@freebsd.org Subject: routing problem (with corrected scheme) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Donatas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2005 05:52:46 -0000 hello, I am sorry for a previous diagram that got wrapped . If someone could take a look at the picture explaining the problem, I = would be thankfull. ftp://temp:temp@217.9.241.242/routing_problem.jpg - 136Kbytes. Short description of a problem: I can't find a way to divert or route = inbound traffic to specifiend ip(vlan) in IP level. From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 08:52:43 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E73B16A41F for ; Fri, 12 Aug 2005 08:52:43 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0263343D45 for ; Fri, 12 Aug 2005 08:52:42 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-1.free.fr (Postfix) with ESMTP id 1F6B917349E; Fri, 12 Aug 2005 10:52:41 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 86268405B; Fri, 12 Aug 2005 10:52:52 +0200 (CEST) Date: Fri, 12 Aug 2005 10:52:51 +0200 From: Jeremie Le Hen To: Claudio Jeker , freebsd-net@freebsd.org, Steve Langdon Message-ID: <20050812085251.GB45385@obiwan.tataz.chchile.org> References: <20050810141938.GF31018@diehard.n-r-g.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050810141938.GF31018@diehard.n-r-g.com> User-Agent: Mutt/1.5.9i Cc: Subject: Re: Stranges with ARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 08:52:43 -0000 Hi Claudio, Steve, > > While user is blocked by _our_ generated MAC! Btw, could anyone advice > > me how to block user IP block without touching ipfw (I think to use > > route + ``-blackhole' to that user that have no his MAC in my ARP > > table), any ideas? I'm just wondering why you don't want to use ipfw ? If it is for performance reasons, you have to know that ipfw is really fast and is intended to be run on routers. Have a look at this post [1]. > Come on have a look at the MAC address. d1:fa:28:ec:87:98. Ja ja ja d1. > Remember the multicast bit of 802.11? No, its the LSB of the first octet. > So your outgoing pings are actually multicasts. Good catch ! :-) [1] http://lists.freebsd.org/pipermail/freebsd-ipfw/2005-July/001934.html Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 18:58:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2903716A42B for ; Fri, 12 Aug 2005 18:58:18 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1F6E43D45 for ; Fri, 12 Aug 2005 18:58:17 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id B3118208FC9; Fri, 12 Aug 2005 11:58:17 -0700 (PDT) Received: from [192.168.2.2] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j7CIwGwL025146; Fri, 12 Aug 2005 11:58:17 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <42FCF148.5010400@elischer.org> Date: Fri, 12 Aug 2005 11:58:16 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050424 X-Accept-Language: en, hu MIME-Version: 1.0 To: Donatas References: <026001c59e7a$c6ca69c0$9f90a8c0@donatas> <42FBC0AE.8020803@elischer.org> <027701c59f02$0eb808a0$9f90a8c0@donatas> In-Reply-To: <027701c59f02$0eb808a0$9f90a8c0@donatas> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: routing problem (with corrected scheme) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 18:58:18 -0000 Donatas wrote: > hello, > I am sorry for a previous diagram that got wrapped . > If someone could take a look at the picture explaining the problem, I would be thankfull. > ftp://temp:temp@217.9.241.242/routing_problem.jpg - 136Kbytes. > Short description of a problem: I can't find a way to divert or route inbound traffic to specifiend ip(vlan) in IP level. > Do the users have to have real IP addresses or can they have NAT'd addresses? In other words, do they have INCOMING sessions or just outgoing sessions? If the latter then you could put a NATD on each of the vlan interfaces on the user router, so that the return packets will automatically go back to the vlan from which they came. Why do you need DIFFERENT VLANS between the two routers for data that will eventually go to different places? Why can't that decision be made on the core router? Is it just so you can shape traffic between the two routers? why not do the shaping on the core router? actually you should be able to do it with ipfw's 'fwd' rule without NAT. ipfw add 1000 fwd ip4 ip from any to ${USER_NETWORK} in recv em0 ipfw add 1001 fwd ip3 ip from any to ${USER_NETWORK} in recv em1 From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 19:18:46 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE64D16A41F for ; Fri, 12 Aug 2005 19:18:46 +0000 (GMT) (envelope-from darcy@wavefire.com) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id 3790643D48 for ; Fri, 12 Aug 2005 19:18:45 +0000 (GMT) (envelope-from darcy@wavefire.com) Received: (qmail 7743 invoked from network); 12 Aug 2005 21:23:05 -0000 Received: from dbitech.internal.wavefire.ca (64.141.15.12) by radius.wavefire.com with SMTP; 12 Aug 2005 21:23:05 -0000 From: Darcy Buskermolen Organization: Wavefire Technologies Corp To: freebsd-net@freebsd.org Date: Fri, 12 Aug 2005 12:18:49 -0700 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508121218.49898.darcy@wavefire.com> Subject: CARP without address on the physical interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 19:18:46 -0000 Does anybody have a patch for FreeBSD which provides the same functionality as obsd does as in the following? (Basicly I'm looking at carping a bridge0 interface) http://www.monkey.org/openbsd/archive2/tech/200412/msg00004.html This patch has been merged into obsd's -HEAD best I can see. -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759 From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 19:52:26 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A871116A43D for ; Fri, 12 Aug 2005 19:52:26 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DE1343D45 for ; Fri, 12 Aug 2005 19:52:26 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id BFA3A5F26; Fri, 12 Aug 2005 15:52:25 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39071-07; Fri, 12 Aug 2005 15:52:24 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-79-217.ny325.east.verizon.net [68.161.79.217]) by pi.codefab.com (Postfix) with ESMTP id 445B95CBE; Fri, 12 Aug 2005 15:52:24 -0400 (EDT) Message-ID: <42FCFDFC.2020903@mac.com> Date: Fri, 12 Aug 2005 15:52:28 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jha miku References: <20050812020814.30073.qmail@web34105.mail.mud.yahoo.com> In-Reply-To: <20050812020814.30073.qmail@web34105.mail.mud.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-net@freebsd.org Subject: Re: Question regd timestamp option X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 19:52:26 -0000 jha miku wrote: > In case of active open, the SYN segments always have > timestamp enabled, since the RFC flg is set. But, > Currently, I am seeing some SYN segments without > timestamp option. FreeBSD (and OS X, and other things using a BSD network stack) will generate initial TCP SYN packets containing the "MNWNNT" TCP options, at least by default in the absense of other information or settings. > The only condition that I am aware of when timestamp > is disabled, is on sending the 3rd SYN in retransmit code > when the timestamp gets disabled. > looking at the tcpdump, it is unclear why the SYNs are > sent during active open without timestamp option. The TCP stack seems to remember some information about which TCP options a remote host is willing to accept. If the remote system didn't accept a timestamp the first time (perhaps it's talking to an old windows box which does "MNNS"), there is no point in sending that option out the next time you open a new connection to the same system. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 20:57:37 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F106A16A41F for ; Fri, 12 Aug 2005 20:57:37 +0000 (GMT) (envelope-from jha_miku@yahoo.com) Received: from web50201.mail.yahoo.com (web50201.mail.yahoo.com [206.190.38.42]) by mx1.FreeBSD.org (Postfix) with SMTP id 774D643D49 for ; Fri, 12 Aug 2005 20:57:37 +0000 (GMT) (envelope-from jha_miku@yahoo.com) Received: (qmail 26237 invoked by uid 60001); 12 Aug 2005 20:57:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lfxbFlvEz2NjegaZ0LLqnBuRhxWdcg6E4qqE91emEXt2dejd2Hp8NXTtQ6N5zF+xDKBvbknOZbKS6Z6Oj9Ha8I6zF9hvoNxfgHK7TZ6fN0Pqv6AFl86BMu6PTKhGx9/2Oo/X7nE9BdJBhkMCg5CWaQOxHrr5hMDHwqhYv2x8aWM= ; Message-ID: <20050812205736.26235.qmail@web50201.mail.yahoo.com> Received: from [65.113.40.130] by web50201.mail.yahoo.com via HTTP; Fri, 12 Aug 2005 13:57:36 PDT Date: Fri, 12 Aug 2005 13:57:36 -0700 (PDT) From: Miku Jha To: Chuck Swiger , jha miku In-Reply-To: <42FCFDFC.2020903@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Question regd timestamp option X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 20:57:38 -0000 --- Chuck Swiger wrote: > jha miku wrote: > > In case of active open, the SYN segments always > have > > timestamp enabled, since the RFC flg is set. But, > > Currently, I am seeing some SYN segments without > > timestamp option. > > FreeBSD (and OS X, and other things using a BSD > network stack) will generate > initial TCP SYN packets containing the "MNWNNT" TCP > options, at least by > default in the absense of other information or > settings. > > > The only condition that I am aware of when > timestamp > > is disabled, is on sending the 3rd SYN in > retransmit code > > when the timestamp gets disabled. > > looking at the tcpdump, it is unclear why the SYNs > are > > sent during active open without timestamp option. > > The TCP stack seems to remember some information > about which TCP options a > remote host is willing to accept. If the remote > system didn't accept a > timestamp the first time (perhaps it's talking to an > old windows box which does > "MNNS"), there is no point in sending that option > out the next time you open a > new connection to the same system. > The first time both ends negotiate and accept timestamp option. The situation is that if the client crashes , the server eventually sends a RST (10.39.53) Following this RST, the client comes back in lets say around 2-3 minutes. Now when the client sends a SYN(10.42.23), there is no timestamp option. Is there some requirement that RST needs to be ACKED or RST flag will remain set for some time window within which if SYN is send, timestamp option will not be set. Thanks in advance for your help. > -Chuck > > _______________________________________________ > 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" > mailto:jha_miku@yahoo.com contact : 408 9211697. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 21:14:57 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC37216A41F for ; Fri, 12 Aug 2005 21:14:57 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5185143D48 for ; Fri, 12 Aug 2005 21:14:57 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id B28165D1B; Fri, 12 Aug 2005 17:14:56 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39369-05; Fri, 12 Aug 2005 17:14:55 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-79-217.ny325.east.verizon.net [68.161.79.217]) by pi.codefab.com (Postfix) with ESMTP id 202CC5C53; Fri, 12 Aug 2005 17:14:55 -0400 (EDT) Message-ID: <42FD1153.50202@mac.com> Date: Fri, 12 Aug 2005 17:14:59 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miku Jha References: <20050812205736.26235.qmail@web50201.mail.yahoo.com> In-Reply-To: <20050812205736.26235.qmail@web50201.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: jha miku , freebsd-net@freebsd.org Subject: Re: Question regd timestamp option X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 21:14:57 -0000 Miku Jha wrote: [ ... ] > The situation is that if the client crashes, the server eventually sends a > RST (10.39.53) Following this RST, the client comes back in lets say around > 2-3 minutes. Now when the client sends a SYN(10.42.23), there is no > timestamp option. If the client opens a connection and both sides exchange packets with timestamps, you'll probably end up seeing "NNT" in all packets during the first session. This right? Now if you open a second connection, while things are still OK, do you see the SYN packet contain all options as normal? I assume the client is opening connections to the server? And it is a FreeBSD box...? Showing tcpdump data (or putting on a website somewhere) would help understand the issue... > Is there some requirement that RST needs to be ACKED > or RST flag will remain set for some time window > within which if SYN is send, timestamp option will not > be set. A RST to a closed or listening socket will be ignored (dropped), a RST which matches an established connection will flush and close that connection but will not be ACKed itself. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sat Aug 13 20:35:48 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5641216A41F; Sat, 13 Aug 2005 20:35:48 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11F0543D45; Sat, 13 Aug 2005 20:35:47 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id B75EA1F9EC8; Sat, 13 Aug 2005 13:35:47 -0700 (PDT) Received: from [192.168.2.2] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j7DKZi82052024; Sat, 13 Aug 2005 13:35:45 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <42FE59A0.5080602@elischer.org> Date: Sat, 13 Aug 2005 13:35:44 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050424 X-Accept-Language: en, hu MIME-Version: 1.0 To: "Dan Mahoney, System Admin" References: <20050812042749.H87994@prime.gushi.org> <20050812063359.A14229@xorpc.icir.org> <20050812224956.GG45385@obiwan.tataz.chchile.org> <20050812170348.A20828@xorpc.icir.org> <20050813044147.B61674@prime.gushi.org> In-Reply-To: <20050813044147.B61674@prime.gushi.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , Jeremie Le Hen , net@freebsd.org Subject: Re: 5.4 -- bridging, ipfw, dot1q X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Aug 2005 20:35:48 -0000 Dan Mahoney, System Admin wrote: should be in -net not -hackers cc's changed accordingly.. > > After all, the demuxing is nothing more than ignoring a few extra bits > at the beginning of the packet. Which all my BPF stuff is doing nicely. > Snort, trafshow, etc all work fine and don't seem to choke on the extra > frames. > > I'd personally just be happy if ipfw was smart enough to know that if I > was using ip-type rules on something that's not ip...that it would > handle the demuxing automagically. > > i.e. ipfw add 100 deny ip from any to 192.168.1.1 mac-type vlan via em1 > > or maybe > > i.e. ipfw add 100 deny ip from any to 192.168.1.1 mac-type vlan-as-inet > via em1 > > Hi Dan. What it comes down to is just that no-one who has worked in ipfw has had your particular problem to solve. O/S gets done when people have a particular problem to solve. As for demultiplexing, well, you COULD pass it out to a netgraph node that strips off the header and stores the info in a tag, and then passes it back to ipfw, but I don't know how the details would work. (I haven't been in ifpw since it was rewritten). Alternatively you could use netgraph bridging and tehnetgraph vlan node type to achieve some sort of stripping.. (Once again, I'm just pointing you in this direction, not providing a full answer.) In 6.x netgraph has more options for this sort of thing with a direct interface between ipfw and netgraph. So, if you want to fix it, you could either do some work on ipfw or do some work on netgraph, but either way you'll probably need to do some work. Julian