From owner-freebsd-net@FreeBSD.ORG Sun Apr 8 09:39:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0354A16A404 for ; Sun, 8 Apr 2007 09:39:32 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from cmail.yandex.ru (cmail.yandex.ru [213.180.193.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7DAF113C45B for ; Sun, 8 Apr 2007 09:39:31 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from [87.250.227.254] (v3-227-254.yandex.net [87.250.227.254]) by cmail.yandex.ru (8.13.8/8.13.8) with ESMTP id l389dREX088343; Sun, 8 Apr 2007 13:39:28 +0400 (MSD) (envelope-from wawa@yandex-team.ru) Message-ID: <4618B84C.5010208@yandex-team.ru> Date: Sun, 08 Apr 2007 13:39:24 +0400 From: Vladimir Ivanov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060717 Debian/1.7.13-0.2ubuntu1 X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans References: <461549BD.1020800@yandex-team.ru> <20070406121505.T43678@delplex.bde.org> In-Reply-To: <20070406121505.T43678@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Ystatus: hits=-1015.0 SUBJ_RE __HAS_REFERENCES ALLTRUSTEDIP QUOTED_EMAIL_TEXT EMAIL_ATTRIBUTION CONTINUOUS_LETTERS_7 LV_YOU_CAN LV_FREE SP_HTTP_URI NEWBAYES_099 __MESS_NO_BODY SH_6_1111 WB_6_D_E SH_6_500 WB_6_B_E LINK_IN_TEXT __IMAGE__LINK SPF_PASS REPLY_WITH_QUOTES ORIGINAL_WITH_QUOTES DL_DLWC_15 REFERENCES IN_REP_TO DL_DLWC_IN_REP_TO X-Spam-Flag: NO X-Spam-Yversion: Spamooborona 1.7.0-nda Cc: freebsd-net@freebsd.org Subject: Re: Serious bug in most (?) ethernet drivers (bge, bce, ixgb etc.). X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Apr 2007 09:39:32 -0000 Bruce Evans wrote: > On Thu, 5 Apr 2007, Vladimir Ivanov wrote: > >> We have reported serious bug with em driver >> (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/87418) one year and >> half ago. >> It's very funny but most freebsd ethernet drivers cloned this bug I >> seem. >> You can see same bug in bce, bge, ixgb and so on. > > > I can only see it in bce and ixgb. bge is much simpler and better -- Yes, you're right. I was too pessimistic. Thank you a lot. I'll resend the bce patch to David. > bge_rxeof() doesn't depend on any state after the unlock/re-lock except > the rx indexes, and these are both reset to 0 by reinitialization. > > However, reinitialization often panics bge_rxeof() anyway. The only > reasons for the panics that I can think of is that nothing is declared > volatile but the producer index is extremely volatile, so the following > races are possible: > - compiler caching the indexes. bce implements this as foot-shooting. > I think aliasing problems prevent the compiler doing it, so declaring > things as volatile would make no difference. > - a race with the hardware in initialzation might result in the producer > index being nonzero and for old data despite it having been reset to 0 > and no new data arriving. Stopping the hardware for initialization > should prevent such races. > > Bruce From owner-freebsd-net@FreeBSD.ORG Sun Apr 8 09:49:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88C0016A400 for ; Sun, 8 Apr 2007 09:49:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 61E2013C44B for ; Sun, 8 Apr 2007 09:49:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id DFD73471F8; Sun, 8 Apr 2007 05:49:27 -0400 (EDT) Date: Sun, 8 Apr 2007 10:49:27 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kris Kennaway In-Reply-To: <20070407042322.GA72639@xor.obsecurity.org> Message-ID: <20070408104025.Y77212@fledge.watson.org> References: <20070407042322.GA72639@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Ivan Voras Subject: Re: A radical restructuring of IPsec... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 09:49:28 -0000 On Sat, 7 Apr 2007, Kris Kennaway wrote: > On Fri, Apr 06, 2007 at 04:49:01PM +0200, Ivan Voras wrote: >> gnn@freebsd.org wrote: >> >>> The patch removes Kame derived IPsec from the tree, and adds v6 support to >>> FAST_IPSEC. The IPSEC kernel option is removed, but the FAST_IPSEC option >>> remains. This is a test patch and has a known problem with routing packets >>> through a node. Nodes can operate in a host mode, that is they are the >>> endpoint of a tunnel. >> >> Just a quick question: Is the reason for this simplification, performance, >> cleanup (I see spl...() functions removed), or something else? > > KAME IPSEC is both giant-locked and lower performance than fast IPSEC (which > also integrates with crypto hardware devices). The missing piece from the > latter is what George has implemented, namely IPv6 support. Just to be specific here -- while most of the network stack is MPSAFE, there are a few straggling components that, when compiled into the kernel, require the entire network stack to run with the Giant lock. KAME IPSEC is one of those components, so if you compile KAME IPSEC into your kernel, you see a significant performance loss. The FAST_IPSEC implementation has been MPSAFE since inception, I believe. Eliminating the support infrastructure for non-MPSAFE protocols is a goal for 7.x, but may not be one we reach. Some of the other straggling components are: - i4b - netatm (Skip Ford is working on this) - IPX over IP tunneling (I have a patch, but no volunteers to test it) Of these, i4b is the most worrying since, to date, no one has expressed interest in eliminating its Giant dependency. This means that its future is not bright. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sun Apr 8 14:36:29 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F5A316A403 for ; Sun, 8 Apr 2007 14:36:29 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4A65913C44B for ; Sun, 8 Apr 2007 14:36:29 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1-b.corp.dcn.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id l38EQ2tX011005; Sun, 8 Apr 2007 07:26:03 -0700 (PDT) Date: Sun, 08 Apr 2007 23:25:37 +0900 Message-ID: From: gnn@FreeBSD.org To: Jeremie Le Hen In-Reply-To: <20070407101600.GF11297@obiwan.tataz.chchile.org> References: <46171DB2.6070705@FreeBSD.org> <20070407101600.GF11297@obiwan.tataz.chchile.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Bruce M. Simpson" , net@FreeBSD.org Subject: Re: A radical restructuring of IPsec... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 14:36:29 -0000 At Sat, 7 Apr 2007 12:16:00 +0200, Jeremie Le Hen wrote: > > Hi, Bruce, > > On Sat, Apr 07, 2007 at 05:27:30AM +0100, Bruce M. Simpson wrote: > > I'm all for this in principle. I believe that the case for FAST_IPSEC > > over KAME IPSEC is fairly clear for those of us who have read the USENIX > > paper. Qualitatively speaking I can say FAST_IPSEC has been more > > pleasant to work with when introducing the TCP-MD5 support. > > Would you point out the paper you're talking about please ? > http://www.usenix.org/events/bsdcon03/tech/leffler_ipsec.html You need a password (i.e. you need to be a USENIX member) to read it. > George, > > Thank you for your work! > Thank me when it's done ;-) > I'm a little sorrowful to see KAME's work going to be forgotten, but > well, this is Darwin's law :-). > > BTW, a couple of years ago, I've tried KAME's snapshot against my > RELENG_4's tree. There was a number of features that weren't in the > base system and I'm pretty sure this is still the case. I can't > remember them all but one: NAT-PT (RFC2766) (IPv4<->IPv6 > translation). Do you have any idea what those features will become > in later days ? I am working with another person who is interested in that and who has patches, Yvan VANHULLEBUS, who also posts here. Best, George From owner-freebsd-net@FreeBSD.ORG Sun Apr 8 16:08:04 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20E0316A402 for ; Sun, 8 Apr 2007 16:08:04 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from sr-6-int.cis.tamu.edu (smtp-relay.tamu.edu [165.91.22.120]) by mx1.freebsd.org (Postfix) with ESMTP id D4AAD13C459 for ; Sun, 8 Apr 2007 16:08:03 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from localhost (localhost.tamu.edu [127.0.0.1]) by sr-6-int.cis.tamu.edu (Postfix) with ESMTP id 2EDF82886C1; Sun, 8 Apr 2007 11:08:03 -0500 (CDT) Received: from [10.0.1.2] (pool-71-126-195-96.herntx.dsl-w.verizon.net [71.126.195.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sr-6-int.cis.tamu.edu (Postfix) with ESMTP id B6D8B288693; Sun, 8 Apr 2007 11:07:58 -0500 (CDT) In-Reply-To: References: <46171DB2.6070705@FreeBSD.org> <20070407101600.GF11297@obiwan.tataz.chchile.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-172781405; protocol="application/pkcs7-signature" Message-Id: <39074876-16C6-438B-A9D4-18C63E0C8E9C@tamu.edu> From: David Duchscher Date: Sun, 8 Apr 2007 11:07:56 -0500 To: gnn@freebsd.org X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: amavisd-new at tamu.edu X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Bruce M. Simpson" , Jeremie Le Hen , net@freebsd.org Subject: Re: A radical restructuring of IPsec... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 16:08:04 -0000 --Apple-Mail-1-172781405 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Apr 8, 2007, at 9:25 AM, gnn@freebsd.org wrote: > At Sat, 7 Apr 2007 12:16:00 +0200, > Jeremie Le Hen wrote: >> >> Hi, Bruce, >> >> On Sat, Apr 07, 2007 at 05:27:30AM +0100, Bruce M. Simpson wrote: >>> I'm all for this in principle. I believe that the case for >>> FAST_IPSEC >>> over KAME IPSEC is fairly clear for those of us who have read the >>> USENIX >>> paper. Qualitatively speaking I can say FAST_IPSEC has been more >>> pleasant to work with when introducing the TCP-MD5 support. >> >> Would you point out the paper you're talking about please ? >> > http://www.usenix.org/events/bsdcon03/tech/leffler_ipsec.html > > You need a password (i.e. you need to be a USENIX member) to read it. FYI, you only need an USENIX account to view papers that have been published in the last twelve months. Since this paper is from 2003, it is viewable by anyone. -- DaveD --Apple-Mail-1-172781405-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 8 21:19:04 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3789916A401 for ; Sun, 8 Apr 2007 21:19:04 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (206-223-169-85.beanfield.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0536D13C483 for ; Sun, 8 Apr 2007 21:19:03 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (206-223-169-82.beanfield.net [206.223.169.82]) by shrew.net (Postfix) with ESMTP id 3EDEA79E2D4; Sun, 8 Apr 2007 16:19:03 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 72786-03; Sun, 8 Apr 2007 21:19:02 +0000 (UTC) Received: from hole.shrew.net (24-155-108-213.dyn.grandenetworks.net [24.155.108.213]) by shrew.net (Postfix) with ESMTP id B6D5979E2D3; Sun, 8 Apr 2007 16:19:01 -0500 (CDT) Received: from [10.22.200.21] ([10.22.200.21]) by hole.shrew.net (8.13.6/8.13.6) with ESMTP id l38EKpvf063540; Sun, 8 Apr 2007 14:20:51 GMT (envelope-from mgrooms@shrew.net) Message-ID: <46195CAA.2050801@shrew.net> Date: Sun, 08 Apr 2007 16:20:42 -0500 From: Matthew Grooms User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------070209010107060903070601" Subject: Bug in FAST IPSEC pfkey interaction ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Apr 2007 21:19:04 -0000 This is a multi-part message in MIME format. --------------070209010107060903070601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, I have encountered a bug while doing some testing using the ike daemon that is bundled with the client software that I posted recently on this list. The daemon is multi threaded and tends to stress the pfkey interface a bit more than racoon by submitting batches of pfkey messages in rapid sequence when adding or removing client security policy. This triggers a page fault in netipsec/key.c key_spddelete2(). Offending code fragment ... /* Is there SP in SPD ? */ if ((sp = key_getspbyid(id)) == NULL) { ipseclog((LOG_DEBUG, "%s: no SP found id:%u.\n", __func__, id)); key_senderror(so, m, EINVAL); } sp->state = IPSEC_SPSTATE_DEAD; KEY_FREESP(&sp); ... where the function proceeds to set sp->state to IPSEC_SPSTATE_DEAD even if the sp pointer is NULL. My guess is that this was intended to read ... return key_senderror(so,m, EINVAL); ... or ... key_senderror(so, m, EINVAL); return 0; ... This could be a problem triggered by the daemon submitting multiple delete requests for a single SPD entry. I need to do a bit more digging to be certain. I just hope its not an SPD locking issue as the page fault only occurs about 1 out of every 10 attempts on my SMP system :/ I have attached some kdbg output and still have the core file lingering if anyone needs more info. Thanks, -Matthew --------------070209010107060903070601 Content-Type: text/plain; name="crash.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="crash.txt" Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xa0 fault code = supervisor write, page not present instruction pointer = 0x8:0xffffffff803ba56c stack pointer = 0x10:0xffffffffa8163740 frame pointer = 0x10:0x173 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 781 (iked) trap number = 12 panic: page fault cpuid = 0 Uptime: 4m24s Dumping 1014 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 1014MB (259472 pages) 998 982 966 950 934 918 902 886 870 854 838 822 806 790 774 758 742 7 26 710 694 678 662 646 630 614 598 582 566 550 534 518 502 486 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 #0 doadump () at pcpu.h:172 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) list *0xffffffff803ba56c 0xffffffff803ba56c is in key_spddelete2 (../../../netipsec/key.c:2160). 2155 if ((sp = key_getspbyid(id)) == NULL) { 2156 ipseclog((LOG_DEBUG, "%s: no SP found id:%u.\n", __func__, id)); 2157 key_senderror(so, m, EINVAL); 2158 } 2159 2160 sp->state = IPSEC_SPSTATE_DEAD; 2161 KEY_FREESP(&sp); 2162 2163 { 2164 struct mbuf *n, *nn; (kgdb) backtrace #0 doadump () at pcpu.h:172 #1 0x0000000000000004 in ?? () #2 0xffffffff802d9b07 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 #3 0xffffffff802da1a1 in panic (fmt=0xffffff002a1b4980 "") at ../../../kern/kern_shutdown.c:565 #4 0xffffffff804c16df in trap_fatal (frame=0xffffff002a1b4980, eva=18446742974936698880) at ../../../amd64/amd64/trap.c:660 #5 0xffffffff804c19ff in trap_pfault (frame=0xffffffffa8163690, usermode=0) at ../../../amd64/amd64/trap.c:573 #6 0xffffffff804c1cb3 in trap (frame= {tf_rdi = -1474939040, tf_rsi = -1098805196416, tf_rdx = 1, tf_rcx = 0, tf_r8 = 2816, tf_r9 = 1, tf_rax = 0, tf_rbx = -1474938976, tf_rbp = 371, tf_r10 = 1, tf_r11 = 8, tf_r12 = -1098494254848, tf_r 13 = -1098814477304, tf_r14 = -1474938976, tf_r15 = -1098814477304, tf_trapno = 12, tf_addr = 160, tf_ flags = -1474938976, tf_err = 2, tf_rip = -2143574676, tf_cs = 8, tf_rflags = 66182, tf_rsp = -1474939 056, tf_ss = 16}) at ../../../amd64/amd64/trap.c:352 #7 0xffffffff804ace9b in calltrap () at ../../../amd64/amd64/exception.S:168 #8 0xffffffff803ba56c in key_spddelete2 (so=0xffffff00298dac08, m=0xffffff003ca3e100, mhp=0xffffffffa81637a0) at ../../../netipsec/key.c:2161 #9 0xffffffff803c1f24 in key_parse (m=0xffffff003ca3e100, so=0xffffff00298dac08) at ../../../netipsec/key.c:7303 #10 0xffffffff803c31db in key_output (m=0xffffff003ca3e100, so=0xffffff00298dac08) at ../../../netipsec/keysock.c:121 #11 0xffffffff8036f72a in raw_usend (so=0xffffffffa8163760, flags=706431360, m=0x1, nam=0x0, control=0x0, td=0x1) at ../../../net/raw_usrreq.c:263 #12 0xffffffff803c3ada in key_send (so=0xffffffffa8163760, flags=706431360, m=0x1, nam=0x0, control=0xb00, td=0x1) at ../../../netipsec/keysock.c:520 #13 0xffffffff8032001e in sosend (so=0xffffff00298dac08, addr=0x0, uio=0xffffffffa8163a90, top=0xffffff003ca3e100, control=0x0, flags=0, td=0xffffff002a1b4980) at ../../../kern/uipc_socket.c:836 #14 0xffffffff80327aa9 in kern_sendit (td=0xffffff002a1b4980, s=11, mp=0xffffffffa8163b50, flags=0, control=0x0, segflg=72) at ../../../kern/uipc_syscalls.c:772 #15 0xffffffff80328eb7 in sendit (td=0xffffff002a1b4980, s=11, mp=0xffffffffa8163b50, flags=0) at ../../../kern/uipc_syscalls.c:712 #16 0xffffffff80329234 in sendto (td=0xffffffffa8163760, uap=0xffffff002a1b4980) at ../../../kern/uipc_syscalls.c:830 #17 0xffffffff804c2531 in syscall (frame= {tf_rdi = 11, tf_rsi = 5918592, tf_rdx = 72, tf_rcx = 0, tf_r8 = 0, tf_r9 = 0, tf_rax = 133, tf_ rbx = 34375701621, tf_rbp = 140737475749200, tf_r10 = 140737475744576, tf_r11 = 3, tf_r12 = 5957024, t f_r13 = 5738496, tf_r14 = 0, tf_r15 = 35, tf_trapno = 22, tf_addr = 0, tf_flags = 5859032, tf_err = 2, tf_rip = 34379888668, tf_cs = 43, tf_rflags = 582, tf_rsp = 140737475749160, tf_ss = 35}) at ../../../amd64/amd64/trap.c:792 #18 0xffffffff804ad038 in Xfast_syscall () at ../../../amd64/amd64/exception.S:270 #19 0x000000080133781c in ?? () Previous frame inner to this frame (corrupt stack?) --------------070209010107060903070601-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 08:51:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A63EE16A400 for ; Mon, 9 Apr 2007 08:51:19 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 4563D13C45B for ; Mon, 9 Apr 2007 08:51:19 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 3E2F11CC58; Mon, 9 Apr 2007 20:51:18 +1200 (NZST) Date: Mon, 9 Apr 2007 20:51:18 +1200 From: Andrew Thompson To: Niki Denev Message-ID: <20070409085118.GF64415@heff.fud.org.nz> References: <20070329235520.GD97061@heff.fud.org.nz> <460E6536.7060805@totalterror.net> <20070401095618.GA24408@heff.fud.org.nz> <4611F645.5000305@totalterror.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4611F645.5000305@totalterror.net> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org Subject: Re: CFT: new trunk(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: Mon, 09 Apr 2007 08:51:19 -0000 On Tue, Apr 03, 2007 at 09:37:57AM +0300, Niki Denev wrote: > >> Andrew Thompson wrote: > >>> Here is a patch to add OpenBSD's trunk(4) interface, and also includes > >>> LACP support which came from agr(4) on NetBSD. Im interested in anyone > >>> who wants to test this and in particular lacp mode if you have a switch > >>> that supports it. > >>> > > I tried today to do the wireless/wired roaming, almost as given > in the man page, with the exception that my wireless interface (ath), > uses WPA, and i'm trying to run dhclient on the trunk interface. > However it does not work as expected, and i'm not sure why... > The problem is that if ath0 is a member of the trunk0 interface > it always deassociates a few seconds after associating. > If i remove it from the trunk group it associates perfectly, and > keeps the link up. The updated patch here partially fixes the problem, the EAP packets will be passed now. http://people.freebsd.org/~thompsa/if_trunk-20070409.diff The remaining issue is that when the wireless interface is added to the trunk it will get a down/up as part of changing the MAC address. This causes wpa_supplicant to close and it doesnt get relaunched. Manually starting wpa_supplicant works but I need to find a way around this. cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 09:09:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8703516A401 for ; Mon, 9 Apr 2007 09:09:21 +0000 (UTC) (envelope-from ndenev@totalterror.net) Received: from sellinet.net (galileo.sellinet.net [82.199.192.2]) by mx1.freebsd.org (Postfix) with SMTP id D4BF713C48A for ; Mon, 9 Apr 2007 09:09:20 +0000 (UTC) (envelope-from ndenev@totalterror.net) Received: (qmail 29292 invoked by uid 1009); 9 Apr 2007 12:09:18 +0300 Received: from ndenev@totalterror.net by galileo by uid 1002 with qmail-scanner-1.22 (spamassassin: 3.0.3. Clear:RC:1(82.199.197.152):. Processed in 0.18037 secs); 09 Apr 2007 09:09:18 -0000 Received: from unknown (HELO ndenev.totalterror.net) (82.199.197.152) by galileo.sellinet.net with SMTP; 9 Apr 2007 12:09:18 +0300 Received: (qmail 6629 invoked from network); 9 Apr 2007 12:09:18 +0300 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by ndenev.totalterror.net with SMTP; 9 Apr 2007 12:09:18 +0300 Message-ID: <461A02BE.1010509@totalterror.net> Date: Mon, 09 Apr 2007 12:09:18 +0300 From: Niki Denev User-Agent: Thunderbird 1.5.0.10 (X11/20070326) MIME-Version: 1.0 To: Andrew Thompson References: <20070329235520.GD97061@heff.fud.org.nz> <460E6536.7060805@totalterror.net> <20070401095618.GA24408@heff.fud.org.nz> <4611F645.5000305@totalterror.net> <20070409085118.GF64415@heff.fud.org.nz> In-Reply-To: <20070409085118.GF64415@heff.fud.org.nz> X-Enigmail-Version: 0.94.3.0 OpenPGP: id=F2DB7EB9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: CFT: new trunk(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: Mon, 09 Apr 2007 09:09:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Thompson wrote: > On Tue, Apr 03, 2007 at 09:37:57AM +0300, Niki Denev wrote: >>>> Andrew Thompson wrote: >>>>> Here is a patch to add OpenBSD's trunk(4) interface, and also includes >>>>> LACP support which came from agr(4) on NetBSD. Im interested in anyone >>>>> who wants to test this and in particular lacp mode if you have a switch >>>>> that supports it. >>>>> >> I tried today to do the wireless/wired roaming, almost as given >> in the man page, with the exception that my wireless interface (ath), >> uses WPA, and i'm trying to run dhclient on the trunk interface. >> However it does not work as expected, and i'm not sure why... >> The problem is that if ath0 is a member of the trunk0 interface >> it always deassociates a few seconds after associating. >> If i remove it from the trunk group it associates perfectly, and >> keeps the link up. > > The updated patch here partially fixes the problem, the EAP packets will > be passed now. > > http://people.freebsd.org/~thompsa/if_trunk-20070409.diff > > The remaining issue is that when the wireless interface is added to the > trunk it will get a down/up as part of changing the MAC address. This > causes wpa_supplicant to close and it doesnt get relaunched. Manually > starting wpa_supplicant works but I need to find a way around this. > > > cheers, > Andrew Great, thanks! I'm recompiling now and will let you know shortly if everything works properly. Regards, Niki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGGgK9HNAJ/fLbfrkRAu33AKDDYaBmVk+yR/VTZzYyerx9NJgVggCeLXlQ CNwgN7oSGtJhpNprW/fKR7M= =LbkD -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 11:10:38 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8000D16A4CD for ; Mon, 9 Apr 2007 11:10:38 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6F43613C48A for ; Mon, 9 Apr 2007 11:10:38 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l39BAcQK059909 for ; Mon, 9 Apr 2007 11:10:38 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l39BAZXT059625 for freebsd-net@FreeBSD.org; Mon, 9 Apr 2007 11:10:35 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Apr 2007 11:10:35 GMT Message-Id: <200704091110.l39BAZXT059625@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon 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, 09 Apr 2007 11:10:38 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net Filtering incoming packets with enc0 does not work wit 7 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net bridge interface given in rc.conf not taking an (stati o kern/110720 net [net] [patch] support for interface descriptions 11 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 17:15:15 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62E5E16A409 for ; Mon, 9 Apr 2007 17:15:15 +0000 (UTC) (envelope-from ndenev@totalterror.net) Received: from sellinet.net (galileo.sellinet.net [82.199.192.2]) by mx1.freebsd.org (Postfix) with SMTP id AD0DE13C469 for ; Mon, 9 Apr 2007 17:15:14 +0000 (UTC) (envelope-from ndenev@totalterror.net) Received: (qmail 23066 invoked by uid 1009); 9 Apr 2007 20:15:13 +0300 Received: from ndenev@totalterror.net by galileo by uid 1002 with qmail-scanner-1.22 (spamassassin: 3.0.3. Clear:RC:1(82.199.197.152):. Processed in 0.317264 secs); 09 Apr 2007 17:15:13 -0000 Received: from unknown (HELO ndenev.totalterror.net) (82.199.197.152) by galileo.sellinet.net with SMTP; 9 Apr 2007 20:15:12 +0300 Received: (qmail 14940 invoked from network); 9 Apr 2007 20:15:12 +0300 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by ndenev.totalterror.net with SMTP; 9 Apr 2007 20:15:12 +0300 Message-ID: <461A74A0.4080201@totalterror.net> Date: Mon, 09 Apr 2007 20:15:12 +0300 From: Niki Denev User-Agent: Thunderbird 1.5.0.10 (X11/20070326) MIME-Version: 1.0 To: Andrew Thompson References: <20070329235520.GD97061@heff.fud.org.nz> <460E6536.7060805@totalterror.net> <20070401095618.GA24408@heff.fud.org.nz> <4611F645.5000305@totalterror.net> <20070409085118.GF64415@heff.fud.org.nz> In-Reply-To: <20070409085118.GF64415@heff.fud.org.nz> X-Enigmail-Version: 0.94.3.0 OpenPGP: id=F2DB7EB9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: CFT: new trunk(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: Mon, 09 Apr 2007 17:15:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Thompson wrote: > On Tue, Apr 03, 2007 at 09:37:57AM +0300, Niki Denev wrote: >>>> Andrew Thompson wrote: >>>>> Here is a patch to add OpenBSD's trunk(4) interface, and also includes >>>>> LACP support which came from agr(4) on NetBSD. Im interested in anyone >>>>> who wants to test this and in particular lacp mode if you have a switch >>>>> that supports it. >>>>> >> I tried today to do the wireless/wired roaming, almost as given >> in the man page, with the exception that my wireless interface (ath), >> uses WPA, and i'm trying to run dhclient on the trunk interface. >> However it does not work as expected, and i'm not sure why... >> The problem is that if ath0 is a member of the trunk0 interface >> it always deassociates a few seconds after associating. >> If i remove it from the trunk group it associates perfectly, and >> keeps the link up. > > The updated patch here partially fixes the problem, the EAP packets will > be passed now. > > http://people.freebsd.org/~thompsa/if_trunk-20070409.diff > > The remaining issue is that when the wireless interface is added to the > trunk it will get a down/up as part of changing the MAC address. This > causes wpa_supplicant to close and it doesnt get relaunched. Manually > starting wpa_supplicant works but I need to find a way around this. > > > cheers, > Andrew I'm not sure that i didn't mess something up with the cleaning up of the previous patch before applying the new one, but i had to add one line to the trunk_port_output() function, more specifically to initialize the variable "type" to zero, because gcc kept complaining that it could be used uninitialized and failed to compile the module. Other than that if_trunk(4) seems to work pretty well, minus the wpa_supplicant issue. P.S.: what is the correct way to determine the trunkport interface that is currently being used to route traffic in failover mode? I see that the first interface is marked as MASTER, and all interfaces with link are marked as ACTIVE. I guess that "the first active interface in the order that they were added to the trunk group is the one currently sending/receiving traffic" is the answer, but maybe i'm missing something more obvious, like another flag/status? Anyways, thanks for the great work! Regards, Niki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGGnSgHNAJ/fLbfrkRAtQbAJ4ku+niQ2f75xySkF+EdP5c1/vsAQCffb4T lCkkAhnk21x/C8MnfcW1Ghs= =oRWn -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 18:23:59 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54B8416A401 for ; Mon, 9 Apr 2007 18:23:59 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7CD13C489 for ; Mon, 9 Apr 2007 18:23:59 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id BDF7F216AF4 for ; Mon, 9 Apr 2007 14:24:10 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 09 Apr 2007 14:23:59 -0400 X-Sasl-enc: h+1/GZtJw4RDyLRJCtP8l4ZrUuGzl0z/sn9S6Gz7RdGM 1176143039 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id DB8751A023 for ; Mon, 9 Apr 2007 14:23:58 -0400 (EDT) Message-ID: <461A84BC.1040308@incunabulum.net> Date: Mon, 09 Apr 2007 19:23:56 +0100 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Call for testers: olsrd and IP_ONESBCAST X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Apr 2007 18:23:59 -0000 Hi, For a while now I have had a patch available to teach olsrd to use IP_ONESBCAST instead of using libnet/bpf just to send broadcast datagrams in FreeBSD, which has had IP_ONESBCAST for a few years now. If anyone is using olsrd on FreeBSD I would greatly appreciate testing and feedback for this patch: http://people.freebsd.org/~bms/dump/olsrd-onesbcast.diff Thanks! BMS From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 19:52:01 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84F3916A403 for ; Mon, 9 Apr 2007 19:52:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id 3027A13C480 for ; Mon, 9 Apr 2007 19:52:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so1155816nza for ; Mon, 09 Apr 2007 12:52:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IjclXNn8IOy8eOPwuPL0HFR+dbT3xTuNtSfOqo8C0XnfhfufVAWf15GW119vVqEh5O0Co2OGdZDQ3/yczOFvLWcVsFSZeCWonsNI2BWd7dKYaC6ZwLjvmkvFsdKK1PcYDFKqtnDVIEeezDJt4GaKp3JAvKq3VDVRAclMDviuxIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=m+Ii9kWW/IwJTYyDU2PEOcjs5oL9MQQT1PsjnJRCxm+QGipAIoDk8LMSrn5jJgrbIDWi6IibLHMg5pAtPMySY0GuwDqn9cS/oy7eIBfd0oAux8VTpAKfHgSFhVEJKbojl/B+cb74T+g5Umb8F6JOxC1OJrvxhBmGWYUNxJQRE7M= Received: by 10.115.78.1 with SMTP id f1mr2450740wal.1176148319618; Mon, 09 Apr 2007 12:51:59 -0700 (PDT) Received: by 10.114.103.15 with HTTP; Mon, 9 Apr 2007 12:51:53 -0700 (PDT) Message-ID: <2a41acea0704091251q38683a1byce7e1fe2deb6bbf2@mail.gmail.com> Date: Mon, 9 Apr 2007 12:51:53 -0700 From: "Jack Vogel" To: "Tai-hwa Liang" In-Reply-To: <0704071047341.19686@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0704051434p2b8c5902x868d0a5d6510aa01@mail.gmail.com> <0704071047341.19686@www.mmlab.cse.yzu.edu.tw> Cc: freebsd-net , freebsd-current , freebsd-stable@freebsd.org Subject: Re: Stack panic with em driver unload X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Apr 2007 19:52:01 -0000 On 4/6/07, Tai-hwa Liang wrote: > On Thu, 5 Apr 2007, Jack Vogel wrote: > > Our test group uses a script that does 100 iterations of > > a module load, then bring up all interfaces, and then > > unload driver. > > > > Depending on the system in anything from just a few > > iterations to 20 or more, the system will panic. > > Just a "me too" here. :p > > > Its doing an em_detach() which calls ether_ifdetach() > > which goes to if_detach, in_delmulti_ifp, in_delmulti_locked, > > and finally if_delmulti(). > > > > The panic is always happening on a cmpxchgq instruction > > so I assume its the LOCK macro, whats odd is that its > > not always the same reason, sometimes one register is > > 0 so its a page fault trap, but on other iterations its a > > general protection fault because the register is some > > big invalid number :) > > I run into this panic regularly. Apparently the result and condition > to trigger the panic are the same as yours: running "while true; do > ifconfig xxx up; kldunload if_xxx; done" and ending up with panicking > at the cmpxchgq instruction. > > > I am hardpressed to see this as a driver problem, but > > I'm willing to be proven wrong, does someone who > > knows the stack code better than me have any insights > > or ideas? > > > > It also appears system dependent, I have a couple > > machines I've tried to reproduce in on and have been > > unable. I also am told it happens on both amd64 and > > i386, but it seems easier to reproduce on the former. > > Dunno about amd64 since I only have i386 around; however, I'm sure > the panic I observed is reproducible on my -CURRENT driver development box. > > > Lastly, from evidence so far I think this doesnt happen > > on CURRENT, but the test group hasnt checked that > > only I have and I dont have as much hardware :) > > FWIW, I usually run into this panic after upgrading to a newer HEAD. > Sometimes I can make the aforementioned ifconfig/kldunload script to > survive longer by doing a clean rebuild on my driver. > I have learned what causes it, at least in our test group's setup... They have an entry in /etc/rc.conf for the device like: ifconfig_emX="addr netmask" And then the script they run assigns emX a DIFFERENT address, thats why you get into the multicast code and then hit the panic. I still would like to see the panic not happen, but to avoid it just dont go assigning different addresses :) Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 05:35:42 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0516416A400 for ; Tue, 10 Apr 2007 05:35:42 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id D440213C44C for ; Tue, 10 Apr 2007 05:35:41 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 4B5DD2168D2; Tue, 10 Apr 2007 01:35:56 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 10 Apr 2007 01:35:42 -0400 X-Sasl-enc: oj3HRuwR1Hi7hTy5DqmBR6hDsrBtxIAlVTzqthbrJoTF 1176183341 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 9A07211335; Tue, 10 Apr 2007 01:35:41 -0400 (EDT) Message-ID: <461B222B.5030602@incunabulum.net> Date: Tue, 10 Apr 2007 06:35:39 +0100 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: Yar Tikhiy References: <45FE9E24.8010201@incunabulum.net> <20070319152837.GA3984@svzserv.kemerovo.su> <20070321092605.GB41715@comp.chem.msu.su> In-Reply-To: <20070321092605.GB41715@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Eugene Grosbein , net@freebsd.org Subject: Re: Interface index hack in IP_ADD_MEMBERSHIP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Apr 2007 05:35:42 -0000 Yar Tikhiy wrote: > Quagga still uses it, too, if its configure script detects FreeBSD > or NetBSD. I'm afraid it was me who submitted the patch to the > Quagga folks when I'd found that Quagga's ospfd couldn't handle > unnumbered P2P interfaces in FreeBSD because their local IPs weren't > unique. Unfortunately, Quagga doesn't seem to use the protocol > independent part of the RFC 3678 API yet. > A preliminary patch for the Rhyolite.com routed is available at: http://people.freebsd.org/~bms/dump/routed.rfc3678.diff The upcoming rewrite of IPv4 multicast host-mdoe logic (currently in bms_netdev) adds support for the Linux-derived 'struct ip_mreqn' for specifying interface indexes to IP_MULTICAST_IF. The RFC 3678 API is implemented; IGMPv3 and MLDv2 may be hooked in later on subject to available resources. The RFC 1724 hack has been completely removed from the kernel in this spin. The new code passes the existing regression tests for any-source multicast. I hope to have source-specific multicast regression tests in the main tree ASAP, I am very close to a code drop. Whilst the radical approach of rewriting this stuff may break legacy applications, they should probably be updated to support the new APIs anyway, given that Linux 2.6 and Microsoft Windows "Longhorn" both support RFC 3678. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 08:08:50 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99EF816A404; Tue, 10 Apr 2007 08:08:50 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5B87E13C483; Tue, 10 Apr 2007 08:08:49 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id DEAF23F6D; Tue, 10 Apr 2007 09:42:13 +0200 (CEST) Date: Tue, 10 Apr 2007 09:42:13 +0200 From: VANHULLEBUS Yvan To: gnn@FreeBSD.org Message-ID: <20070410074213.GA29265@zen.inc> References: <46171DB2.6070705@FreeBSD.org> <20070407101600.GF11297@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Cc: "Bruce M. Simpson" , Jeremie Le Hen , net@FreeBSD.org Subject: Re: A radical restructuring of IPsec... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 08:08:50 -0000 On Sun, Apr 08, 2007 at 11:25:37PM +0900, gnn@FreeBSD.org wrote: > At Sat, 7 Apr 2007 12:16:00 +0200, > Jeremie Le Hen wrote: [....] > > I'm a little sorrowful to see KAME's work going to be forgotten, but > > well, this is Darwin's law :-). > > > > BTW, a couple of years ago, I've tried KAME's snapshot against my > > RELENG_4's tree. There was a number of features that weren't in the > > base system and I'm pretty sure this is still the case. I can't > > remember them all but one: NAT-PT (RFC2766) (IPv4<->IPv6 > > translation). Do you have any idea what those features will become > > in later days ? > > I am working with another person who is interested in that and who has > patches, Yvan VANHULLEBUS, who also posts here. I'm not sure my patch is directly related to what Jeremie is talking about, but my NAT-T patchset (RFCS 3947 - 3948) should be quite easy to port to the source code (with your patch), as the actual version works with both IPSEC FAST_IPSEC (with some thanks to Manu from NetBSD and to Larry Baird). I'll try to generate quicly a new version for FreeBSD-HEAD as soon as possible. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 11:37:30 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D75716A401; Tue, 10 Apr 2007 11:37:30 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4A0EF13C459; Tue, 10 Apr 2007 11:37:30 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 2974A216D70; Tue, 10 Apr 2007 07:37:46 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 10 Apr 2007 07:37:30 -0400 X-Sasl-enc: 2YRisFKDe7eFPFMBzwjuIc6SVBBaNDq/aYc09ynetqVb 1176205050 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id E97C51628E; Tue, 10 Apr 2007 07:37:29 -0400 (EDT) Message-ID: <461B76F8.3050003@incunabulum.net> Date: Tue, 10 Apr 2007 12:37:28 +0100 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kde@FreeBSD.org Subject: [CODE DROP] KDE support for Avahi service browsing on FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 11:37:30 -0000 Hi, As part of my ongoing work to support Zero-configuration networking in FreeBSD, please check out the following patches. I have been able to browse and connect to services from with the KDE environment using these. At the moment, the basic kernel support for Zeroconf/Bonjour is in place in FreeBSD. The next challenge there is to support address scope and preference for IPv4. http://people.freebsd.org/~bms/dump/nss_mdns.diff is a patch for the FreeBSD port of nss_mdns which I may commit shortly as it fixes a dynamic symbol issue found by Pat Lashley. nss_mdns must be installed and configured in FreeBSD's /etc/nsswitch.conf files before proceeding. http://people.freebsd.org/~bms/dump/avahi-qt3.diff is a patch for the FreeBSD avahi port to build and install the QT3 bindings for Avahi. After applying this patch and reinstalling the avahi port, please manually change the following file's 'prefix' line to point to ${X11BASE}, at ${LOCALBASE}libdata/pkgconfig/avahi-qt3.pc. e.g. "prefix=/usr/local" would become "prefix=/usr/X11R6". This is to allow kdnssd-avahi's configure script to find QT's Meta-object compiler (moc) which the FreeBSD ports system installs under ${X11BASE} by default. [Help from a ports committer to convert this patch into a 'slave port' would be very appreciated.] http://people.freebsd.org/~bms/dump/kdnssd_avahi.tar is a port for kdnssd-avahi. Installing this port will overwrite the default libkdnssd.so.1 library which is installed by the kdelibs port. After applying both of these changes to your system, you must completely restart KDE for them to take effect. Please read the pkg-message file in kdnssd_avahi.tar for step-by-step information on how to test the Avahi support for KDE in FreeBSD. I would greatly welcome your further testing and feedback. I apologise in advance for the unpolished nature of this work, however, integration of Avahi with KDE is an ongoing challenge for many other open source projects, and I would hope that the loose ends on FreeBSD become tied together in the near future. Thanks again, BMS From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 11:54:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE85916A409 for ; Tue, 10 Apr 2007 11:54:40 +0000 (UTC) (envelope-from volker@thalreit.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id BC82513C4C1 for ; Tue, 10 Apr 2007 11:54:38 +0000 (UTC) (envelope-from volker@thalreit.de) Received: from [89.48.107.64] (helo=thalreit.de) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1HbEvl2Ttx-0000Z6; Tue, 10 Apr 2007 13:54:37 +0200 Received: from localhost ([127.0.0.1] helo=thalreit.dyndns.org) by thalreit.de with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HbEvu-0000Wu-EK; Tue, 10 Apr 2007 13:54:46 +0200 Received: from 194.59.120.11 (SquirrelMail authenticated user volker) by thalreit.dyndns.org with HTTP; Tue, 10 Apr 2007 13:54:46 +0200 (CEST) Message-ID: <33741.194.59.120.11.1176206086.squirrel@thalreit.dyndns.org> In-Reply-To: <20070322212409.GA33837@ikarus.thalreit> References: <20070322212409.GA33837@ikarus.thalreit> Date: Tue, 10 Apr 2007 13:54:46 +0200 (CEST) From: "Volker Jahns" To: "Volker Jahns" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Provags-ID: V01U2FsdGVkX19yY2QCV1K4+Mp5PympF4zYoRmfxyZ0jcaoVZ6 PjaTzbVi8C0ly6rdvQHJ8A5TH8rfNjkUsN2bc2ZjJKbrR+Sso5 UWvzMjCcE9cxUgMl4EHjg== Cc: freebsd-net@freebsd.org Subject: Re: rpcinfo Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 11:54:40 -0000 The following configuration statements reproducibly crash FreeBSD 6.1 and 6.2 when calling "rpcinfo -p" or "rpcinfo -p localhost" ( see more details in the first posting) -- rpcbind_enable="YES" rpcbind_flags="-i -l" nisdomainname="tdom" nis_client_enable="YES" -- I would be tempted to identify this behaviour as a (serious) bug. Workaround If the nis_client_flags option is uncommented like #nis_client_flags="-S tdom,tdomserv.tdom.de,tdomserv -m" -- Volker Jahns, volker@thalreit.de > Running rpcbind on a FreeBSD 6.1 testsystem has horrible effects, when > > - rpcbind is started at system boottime by the rc.conf directive > rpcbind_enable="YES" > - rpcinfo -p localhost is run ( this command then hangs until the system > has died) > > > The top output shows high load and 'many' rpcbind processes which have > been started. > -- > last pid: 48637; load averages: 3.99, 3.24, 3.23 up 0+07:47:18 > 16:02:42 > 1832 processes:3 running, 195 sleeping, 1633 waiting, 1 lock > CPU states: 5.2% user, 0.0% nice, 26.8% system, 4.3% interrupt, 63.7% > idle > Mem: 121M Active, 20M Inact, 88M Wired, 4688K Cache, 34M Buf, 1004K Free > Swap: 470M Total, 244M Used, 226M Free, 51% Inuse, 22M In, 26M Out > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 317 root 1 128 0 1440K 424K RUN 44:17 7.37% rpcbind > 37057 root 1 96 0 6524K 3468K RUN 0:20 0.06% top > 296 root 1 96 0 1300K 0K WAIT 1:06 0.00% > 437 root 1 96 0 3408K 0K WAIT 0:00 0.00% > 538 root 1 96 0 6092K 0K WAIT 0:00 0.00% > 447 root 1 8 0 1312K 0K WAIT 0:00 0.00% > 441 smmsp 1 20 0 3300K 0K pause 0:00 0.00% > 383 root 1 96 0 1212K 0K WAIT 0:00 0.00% > 541 root 1 20 0 3996K 0K pause 0:00 0.00% > 99806 root 1 4 0 1468K 0K WAIT 0:00 0.00% > 38770 root 1 4 0 1464K 0K WAIT 0:00 0.00% > 20459 root 1 4 0 1468K 0K WAIT 0:00 0.00% > 21924 root 1 4 0 1440K 0K WAIT 0:00 0.00% > 426 root 1 96 0 3356K 0K select 0:00 0.00% > 49102 root 1 4 0 1468K 0K WAIT 0:00 0.00% > 10715 root 1 4 0 1468K 648K kqread 0:00 0.00% rpcbind > 49102 root 1 4 0 1468K 0K WAIT 0:00 0.00% > 45921 root 1 4 0 1464K 0K WAIT 0:00 0.00% > 45947 root 1 4 0 1464K 0K WAIT 0:00 0.00% > -- > > The output of some well-known commands w/ the system in this state is > puzzling me: > -- > orion# dmesg > No more processes. > -- > -- > ssh orion -l root > ssh_exchange_identification: Connection closed by remote host > -- > > Moreover, system log worries me: > -- > Mar 8 08:20:26 orion kernel: kern.maxfiles limit exceeded by uid 0, > please see > tuning(7). > Mar 8 08:20:26 orion kernel: kern.maxfiles limit exceeded by uid 0, > please see > tuning(7). > Mar 8 08:20:26 orion syslogd: /dev/console: Too many open files in > system: Too > many open files in system > Mar 8 07:20:25 orion rpcbind: warning: /etc/hosts.allow, line 23: cannot > open / > etc/hosts.allow: Too many open files in system > -- > > Running rpcinfo -p from a remote system can be used to > benchmark this FreeBSD system. sockstat shows the TCP connects to rpcbind > from the remote system and everything is fine. > > > If rpcbind is _not_ started at boottime, but from the commandline once the > system is up, rpcinfo -p localhost works as expected. > > I want to run NIS on the system, so rpcbind must run in reliable manner. > > Any help is much appreciated. > -- > Volker Jahns, volker@thalreit.de > From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 17:57:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E12916A403 for ; Tue, 10 Apr 2007 17:57:51 +0000 (UTC) (envelope-from lofi@freebsd.org) Received: from mail-in-13.arcor-online.net (mail-in-13.arcor-online.net [151.189.21.53]) by mx1.freebsd.org (Postfix) with ESMTP id D5B0113C4B0 for ; Tue, 10 Apr 2007 17:57:50 +0000 (UTC) (envelope-from lofi@freebsd.org) Received: from mail-in-01-z2.arcor-online.net (mail-in-01-z2.arcor-online.net [151.189.8.13]) by mail-in-13.arcor-online.net (Postfix) with ESMTP id 098321E5292; Tue, 10 Apr 2007 15:58:59 +0200 (CEST) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id E9ADD12BE9F; Tue, 10 Apr 2007 15:58:58 +0200 (CEST) Received: from lofi.dyndns.org (dslb-084-061-175-138.pools.arcor-ip.net [84.61.175.138]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 890F219B328; Tue, 10 Apr 2007 15:58:58 +0200 (CEST) Received: from kiste.my.domain (root@kiste.my.domain [192.168.8.2]) by lofi.dyndns.org (8.13.8/8.13.3) with ESMTP id l3ADwsNh090558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 15:58:54 +0200 (CEST) (envelope-from lofi@freebsd.org) Received: from kiste.my.domain (lofi@localhost [127.0.0.1]) by kiste.my.domain (8.13.6/8.13.4) with ESMTP id l3ADwrjl006165; Tue, 10 Apr 2007 15:58:53 +0200 (CEST) (envelope-from lofi@freebsd.org) Received: from localhost (localhost [[UNIX: localhost]]) by kiste.my.domain (8.13.6/8.13.4/Submit) id l3ADwrYE006164; Tue, 10 Apr 2007 15:58:53 +0200 (CEST) (envelope-from lofi@freebsd.org) X-Authentication-Warning: kiste.my.domain: lofi set sender to lofi@freebsd.org using -f From: Michael Nottebrock To: kde@freebsd.org Date: Tue, 10 Apr 2007 15:58:52 +0200 User-Agent: KMail/1.9.6 References: <461B76F8.3050003@incunabulum.net> In-Reply-To: <461B76F8.3050003@incunabulum.net> X-Face: g:jG2\O{-yqD1x?DG2lU1)(v%xffR"p8Nz(w/*)YEUO\Hn%mGi&-!+rq$&r64,=?utf-8?q?fuP=7E=3Bbw=5C=0A=09=5EQdX?=@v~HEAi?NaE8SU]}.oeYSjN84Fe{M(ahZ.(i+lxyP; pr)2[%mGbkY'RmM>=?utf-8?q?+mg3Y=24ip=0A=091?=@Z>[EUaE7tjJ=1DRs~:!uSd""d~:/Er3rpQA%ze|bp>S MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3485877.rpFlj3Fg5z"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704101558.53471.lofi@freebsd.org> X-Virus-Scanned: by amavisd-new Cc: freebsd-net@freebsd.org, Bruce M Simpson Subject: Re: [kde-freebsd] [CODE DROP] KDE support for Avahi service browsing on FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 17:57:51 -0000 --nextPart3485877.rpFlj3Fg5z Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday, 10. April 2007, Bruce M Simpson wrote: > http://people.freebsd.org/~bms/dump/avahi-qt3.diff > is a patch for the FreeBSD avahi port to build and install the QT3 > bindings for Avahi. After applying this patch and reinstalling the avahi > port, please manually change the following file's 'prefix' line to point > to ${X11BASE}, at ${LOCALBASE}libdata/pkgconfig/avahi-qt3.pc. e.g. > "prefix=3D/usr/local" would become "prefix=3D/usr/X11R6". > This is to allow kdnssd-avahi's configure script to find QT's > Meta-object compiler (moc) which the FreeBSD ports system installs under > ${X11BASE} by default. > > [Help from a ports committer to convert this patch into a 'slave port' > would be very appreciated.] Could you forward this part to the avahi maintainers (gnome@freebsd.org) as= =20 well? Thanks for your work on this! Cheers, =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart3485877.rpFlj3Fg5z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBGG5gdXhc68WspdLARAs4oAJ9ufs6MyhK7qmeq1S0tblXUHpS+YACfXGG8 vNGtuvo7ApIF+WgzArxSiEY= =LTcr -----END PGP SIGNATURE----- --nextPart3485877.rpFlj3Fg5z-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 13:59:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E57B416A404 for ; Wed, 11 Apr 2007 13:59:16 +0000 (UTC) (envelope-from joe.culler@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id A339A13C46E for ; Wed, 11 Apr 2007 13:59:16 +0000 (UTC) (envelope-from joe.culler@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so206188ana for ; Wed, 11 Apr 2007 06:59:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EmvsDSCwbM2WAAKokB0CZmkwu154N2yrLzKD7/Wfy4eXWsn69MxXvOIhzm+ARDXTbjNQ/NPx/CnoZIMPyLJovyclAGSGDxqgUA/vU7Zd8KMfzuXUTbAfS7tX+0Mowx1e105xVnWzfTj6RF6xQN/YzfZbsmbt7pG5vZ0RG30ex9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=BTUwXyHzrbvVRVtmhiHzWa4rKnfoy2Ye7LLSP1ROdv8hGn7RTOwB6HD4uQrV0puywMddY96EMgvplTqkgzpJ5AFYC7lgn3objzq3dZzRdeXcZWWRQIkiz32pfIJrbpArKhQIHyxNbYAlZ4aJM5U8TFBEftwjOeK6d3fUyCwDZcI= Received: by 10.115.76.1 with SMTP id d1mr267243wal.1176298259427; Wed, 11 Apr 2007 06:30:59 -0700 (PDT) Received: by 10.114.181.9 with HTTP; Wed, 11 Apr 2007 06:30:59 -0700 (PDT) Message-ID: <67a3f13e0704110630w799ea242va34d5b49f641b41c@mail.gmail.com> Date: Wed, 11 Apr 2007 21:30:59 +0800 From: "Joe Culler" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Questions about porting wireless network drivers to FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2007 13:59:17 -0000 Hello, I'm trying to port Zydas chipset to FreeBSD, but I encountered a problem. My driver can't get an IP from access point dhcp. Which part will cause that problem? Thank you. -joe From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 14:57:14 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B39F816A400 for ; Wed, 11 Apr 2007 14:57:14 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.166]) by mx1.freebsd.org (Postfix) with ESMTP id CF81913C459 for ; Wed, 11 Apr 2007 14:57:13 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.13.8/8.13.8) with ESMTP id l3BEhArA003528 for ; Wed, 11 Apr 2007 22:43:10 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.13.8/8.13.8/Submit) id l3BEh9TZ003527 for net@freebsd.org; Wed, 11 Apr 2007 22:43:09 +0800 (KRAST) (envelope-from eugen) Date: Wed, 11 Apr 2007 22:43:09 +0800 From: Eugene Grosbein To: net@freebsd.org Message-ID: <20070411144309.GA3456@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: ipfw tags & filtering incoming broadcasts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2007 14:57:14 -0000 Hi! I have a router based on FreeBSD 6 running quagga/RIPv2 and want to filter all incoming packets sent to it (not forwarded throught it) with a small set of exceptions. This router uses ipfw for packet filtering. There is no problem to filter unicasts. But I want also block all broadcasts except of incoming RIPv2, some of hardware routers send broadcasts instead of multicasts here. I've tried this way: ipfw add 30 allow tag 1 ip from any to any MAC ff:ff:ff:ff:ff:ff any ipfw add 40 allow ip from any to any layer2 ipfw add 50 count log ip from any to any tagged 1 I hoped that rule 30 would tag all broadcasts with tag 1 during layer2 filtering pass and it'd keep its tag during layer3 filtering but it seems it doesn't. If I send a broadcast with ping I see that rules 30 and 40 match this outgoing broadcast but rule 50 does not. Am I doing something wrong or is this behavour by design or is this a bug that deserve a PR? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 15:47:23 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F41416A400 for ; Wed, 11 Apr 2007 15:47:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outU.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 6530113C483 for ; Wed, 11 Apr 2007 15:47:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 11 Apr 2007 08:16:34 -0700 Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 5CF55125B78; Wed, 11 Apr 2007 08:47:22 -0700 (PDT) Message-ID: <461D0309.5080602@elischer.org> Date: Wed, 11 Apr 2007 08:47:21 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Eugene Grosbein References: <20070411144309.GA3456@grosbein.pp.ru> In-Reply-To: <20070411144309.GA3456@grosbein.pp.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: ipfw tags & filtering incoming broadcasts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2007 15:47:23 -0000 Eugene Grosbein wrote: > Hi! > > I have a router based on FreeBSD 6 running quagga/RIPv2 > and want to filter all incoming packets sent to it (not forwarded throught it) > with a small set of exceptions. This router uses ipfw for packet filtering. > > There is no problem to filter unicasts. But I want also block all > broadcasts except of incoming RIPv2, some of hardware > routers send broadcasts instead of multicasts here. > > I've tried this way: > > ipfw add 30 allow tag 1 ip from any to any MAC ff:ff:ff:ff:ff:ff any the MAC or layer2 commands are only useful if you are calling the firewall from the NIC layer.. have you turned on the layer 2 entrypoints? sysctl net.link.ether.{something} (I forget exactly) > ipfw add 40 allow ip from any to any layer2 > ipfw add 50 count log ip from any to any tagged 1 > > I hoped that rule 30 would tag all broadcasts with tag 1 during layer2 > filtering pass and it'd keep its tag during layer3 filtering but it seems > it doesn't. If I send a broadcast with ping > I see that rules 30 and 40 match this outgoing broadcast > but rule 50 does not. Am I doing something wrong or > is this behavour by design or is this a bug that deserve a PR? > > Eugene Grosbein > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 16:21:04 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91EEB16A403 for ; Wed, 11 Apr 2007 16:21:04 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id F23B513C484 for ; Wed, 11 Apr 2007 16:21:03 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l3BGKrLb094701; Thu, 12 Apr 2007 00:20:53 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l3BGKqOg094699; Thu, 12 Apr 2007 00:20:52 +0800 (KRAST) (envelope-from eugen) Date: Thu, 12 Apr 2007 00:20:52 +0800 From: Eugene Grosbein To: Julian Elischer Message-ID: <20070411162052.GA94437@svzserv.kemerovo.su> References: <20070411144309.GA3456@grosbein.pp.ru> <461D0309.5080602@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461D0309.5080602@elischer.org> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: ipfw tags & filtering incoming broadcasts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2007 16:21:04 -0000 On Wed, Apr 11, 2007 at 08:47:21AM -0700, Julian Elischer wrote: > the MAC or layer2 commands are only useful if you are calling the > firewall from the NIC layer.. > have you turned on the layer 2 entrypoints? > > sysctl net.link.ether.{something} (I forget exactly) It's net.link.ether.ipfw, and yes, I turned this on, or else rule 40 wouldn't match a packet but it does as I noted: > >ipfw add 40 allow ip from any to any layer2 > >ipfw add 50 count log ip from any to any tagged 1 > > > >I hoped that rule 30 would tag all broadcasts with tag 1 during layer2 > >filtering pass and it'd keep its tag during layer3 filtering but it seems > >it doesn't. If I send a broadcast with ping > >I see that rules 30 and 40 match this outgoing broadcast > >but rule 50 does not. Eugene From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 17:43:19 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A399C16A400 for ; Wed, 11 Apr 2007 17:43:19 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from webmail28.mail.yandex.net (webmail28.mail.yandex.net [213.180.200.117]) by mx1.freebsd.org (Postfix) with ESMTP id 3A09C13C4B0 for ; Wed, 11 Apr 2007 17:43:19 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (webmail28) by mail.yandex.ru id S5611793AbXDKR12 for ; Wed, 11 Apr 2007 21:27:28 +0400 Received: from [82.211.152.12] ([82.211.152.12]) by mail.yandex.ru with HTTP; Wed, 11 Apr 2007 21:27:27 +0400 From: "Andrey V. Elsukov" To: eugen@grosbein.pp.ru MIME-Version: 1.0 Message-Id: <74021176312447@webmail28.yandex.ru> Date: Wed, 11 Apr 2007 21:27:27 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: net@freebsd.org Subject: Re: ipfw tags & filtering incoming broadcasts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2007 17:43:19 -0000 > Hi! > I have a router based on FreeBSD 6 running quagga/RIPv2 > and want to filter all incoming packets sent to it (not forwarded throught it) > with a small set of exceptions. This router uses ipfw for packet filtering. You can use "in recv" keywords to determine incoming packets. > There is no problem to filter unicasts. But I want also block all > broadcasts except of incoming RIPv2, some of hardware > routers send broadcasts instead of multicasts here. > I've tried this way: > ipfw add 30 allow tag 1 ip from any to any MAC ff:ff:ff:ff:ff:ff any If you want use tags in the next rules, you should use `count' action instead of `allow'. > ipfw add 40 allow ip from any to any layer2 > ipfw add 50 count log ip from any to any tagged 1 > I hoped that rule 30 would tag all broadcasts with tag 1 during layer2 > filtering pass and it'd keep its tag during layer3 filtering but it seems > it doesn't. If I send a broadcast with ping > I see that rules 30 and 40 match this outgoing broadcast > but rule 50 does not. Am I doing something wrong or > is this behavour by design or is this a bug that deserve a PR? If you want filter a RIPv2 packets, may be it's a good idea to use src-port or dst-port 520 with udp protocol? -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 01:01:29 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B66A16A400 for ; Thu, 12 Apr 2007 01:01:29 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 93C1D13C44C for ; Thu, 12 Apr 2007 01:01:27 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l3C11Njq041986; Thu, 12 Apr 2007 09:01:23 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l3C11MVL041984; Thu, 12 Apr 2007 09:01:22 +0800 (KRAST) (envelope-from eugen) Date: Thu, 12 Apr 2007 09:01:22 +0800 From: Eugene Grosbein To: "Andrey V. Elsukov" Message-ID: <20070412010122.GA41509@svzserv.kemerovo.su> References: <74021176312447@webmail28.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74021176312447@webmail28.yandex.ru> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: ipfw tags & filtering incoming broadcasts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 01:01:29 -0000 On Wed, Apr 11, 2007 at 09:27:27PM +0400, Andrey V. Elsukov wrote: > > I have a router based on FreeBSD 6 running quagga/RIPv2 > > and want to filter all incoming packets sent to it (not forwarded throught it) > > with a small set of exceptions. This router uses ipfw for packet filtering. > > You can use "in recv" keywords to determine incoming packets. I know, thanks. Now I'm just trying to make it work somehow but without a success still. > > There is no problem to filter unicasts. But I want also block all > > broadcasts except of incoming RIPv2, some of hardware > > routers send broadcasts instead of multicasts here. > > I've tried this way: > > ipfw add 30 allow tag 1 ip from any to any MAC ff:ff:ff:ff:ff:ff any > > If you want use tags in the next rules, you should use `count' action > instead of `allow'. I've just tried, replaced "allow" with "count" in the rule 30 but nothing changed. And I think there should be no difference for this set of 3 rules, because a packet needs to be _allowed_ during layer2 pass to reach layer3 pass where tags are used. So it should not matter whether the rule 30 pass such packets or rule 40. > > ipfw add 40 allow ip from any to any layer2 > > ipfw add 50 count log ip from any to any tagged 1 > > I hoped that rule 30 would tag all broadcasts with tag 1 during layer2 > > filtering pass and it'd keep its tag during layer3 filtering but it seems > > it doesn't. If I send a broadcast with ping > > I see that rules 30 and 40 match this outgoing broadcast > > but rule 50 does not. Am I doing something wrong or > > is this behavour by design or is this a bug that deserve a PR? > > If you want filter a RIPv2 packets, may be it's a good idea > to use src-port or dst-port 520 with udp protocol? I want also to learn how to distinguish unicast UDP from broadcast UDP. Eugene From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 01:07:11 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C130B16A400 for ; Thu, 12 Apr 2007 01:07:11 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 5516713C43E for ; Thu, 12 Apr 2007 01:07:11 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id DD6531CC58; Thu, 12 Apr 2007 13:07:07 +1200 (NZST) Date: Thu, 12 Apr 2007 13:07:07 +1200 From: Andrew Thompson To: freebsd-net@freebsd.org Message-ID: <20070412010707.GC9390@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.13 (2006-08-11) Subject: ipv6 multicast refcnt panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 01:07:11 -0000 Hi, I have come across this panic which appears to be from incorrect refcounting on the inet6 multicast code. [root@dev7a]# ifconfig edsc0 create [root@dev7a]# ifconfig edsc0 inet6 f00f::01 [root@dev7a]# ifconfig edsc0 destroy Everything is ok... [root@dev7a]# ifconfig edsc0 create [root@dev7a]# ifconfig edsc0 inet6 f00f::01 [root@dev7a]# ifconfig edsc0 inet6 f00f::01 [root@dev7a]# ifconfig edsc0 destroy panic: if_freemulti: protospec not NULL cpuid = 0 KDB: enter: panic [thread pid 992 tid 100060 ] Stopped at breakpoint+0x4: leave db> tr Tracing pid 992 tid 100060 td 0xc25b6360 breakpoint(cd0faac4,c07689ae,c0a74962,0,0,...) at breakpoint+0x4 kdb_enter(c0a74962) at kdb_enter+0x30 panic(c0a84679,cd0faae4,c0800fc1,c2310e00,c25b6360,...) at panic+0x13e if_freemulti(c2310e00) at if_freemulti+0x2f if_delmulti_locked(c21fa400,c2310e00,1) at if_delmulti_locked+0x1e1 if_purgemaddrs(c21fa400) at if_purgemaddrs+0x4b if_detach(c21fa400) at if_detach+0x142 ether_ifdetach(c21fa400,8056670,bfbfee3b,cd0fab6c,c080261e,...) at ether_ifdetach+0x42 edsc_clone_destroy(c21fa400) at edsc_clone_destroy+0x10 ifc_simple_destroy(c26a5c20,c21fa400) at ifc_simple_destroy+0x36 if_clone_destroyif(c26a5c20,c21fa400) at if_clone_destroyif+0xf7 if_clone_destroy(c23b25c0) at if_clone_destroy+0xa4 ifioctl(c25b115c,80206979,c23b25c0,c25b6360) at ifioctl+0x111 soo_ioctl(c240f7e0,80206979,c23b25c0,c2697380,c25b6360) at soo_ioctl+0x3d5 fo_ioctl(c240f7e0,80206979,c23b25c0,c2697380,c25b6360) at fo_ioctl+0x1d kern_ioctl(c25b6360,3,80206979,c23b25c0) at kern_ioctl+0x22f ioctl(c25b6360,cd0facec) at ioctl+0x124 syscall(cd0fad38) at syscall+0x2b4 Xint0x80_syscall() at Xint0x80_syscall+0x20 (kgdb) frame 13 #13 0xc08007bb in if_freemulti (ifma=0xc2310e00) at /usr/src/sys/net/if.c:2256 2256 KASSERT(ifma->ifma_protospec == NULL, (kgdb) p *ifma $3 = {ifma_link = {tqe_next = 0xc23b2460, tqe_prev = 0xc21fa4bc}, ifma_addr = 0xc23b2200, ifma_lladdr = 0xc26d55c0, ifma_ifp = 0x0, ifma_refcount = 0, ifma_protospec = 0xc26d5580, ifma_llifma = 0xc23b2a20} (kgdb) p *(struct in6_multi *)ifma->ifma_protospec $4 = {in6m_entry = {le_next = 0xc26d5680, le_prev = 0xc0be44cc}, in6m_addr = { __u6_addr = {__u6_addr8 = "ÿ\001\000\a", '\0' , "\001", __u6_addr16 = {511, 1792, 0, 0, 0, 0, 0, 256}, __u6_addr32 = {117441023, 0, 0, 16777216}}}, in6m_ifp = 0xc21fa400, in6m_ifma = 0xc2310e00, in6m_refcount = 1, in6m_state = 0, in6m_timer = 0, in6m_timer_expire = { tv_sec = 0, tv_usec = 0}, in6m_timer_ch = 0xc23b2320} in6m_refcount is still 1 so the in6_multi is not freed. Andrew From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 01:37:48 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9088916A401 for ; Thu, 12 Apr 2007 01:37:48 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id EEAA113C468 for ; Thu, 12 Apr 2007 01:37:47 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l3C1bkJG044698 for ; Thu, 12 Apr 2007 09:37:46 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l3C1bkiC044697 for net@freebsd.org; Thu, 12 Apr 2007 09:37:46 +0800 (KRAST) (envelope-from eugen) Date: Thu, 12 Apr 2007 09:37:46 +0800 From: Eugene Grosbein To: net@freebsd.org Message-ID: <20070412013746.GA44307@svzserv.kemerovo.su> References: <20070411144309.GA3456@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070411144309.GA3456@grosbein.pp.ru> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: ipfw tags & filtering incoming broadcasts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 01:37:48 -0000 On Wed, Apr 11, 2007 at 10:43:09PM +0800, Eugene Grosbein wrote: > There is no problem to filter unicasts. But I want also block all > broadcasts except of incoming RIPv2, some of hardware > routers send broadcasts instead of multicasts here. > > I've tried this way: I've just added a copy of rule 50 with number 35: > ipfw add 30 allow tag 1 ip from any to any MAC ff:ff:ff:ff:ff:ff any ipfw add 35 count log ip from any to any tagged 1 > ipfw add 40 allow ip from any to any layer2 > ipfw add 50 count log ip from any to any tagged 1 And I see that tag is kept during layer2 filtering stage but seem to be lost somewhere in space in transition to layer3 stage. So that is the question: is it a bug or featue? Eugene From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 01:58:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE9F416A400; Thu, 12 Apr 2007 01:58:23 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 6EEFB13C480; Thu, 12 Apr 2007 01:58:23 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 081C2EB1E17; Thu, 12 Apr 2007 09:58:16 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id 44ZjdQu4fYct; Thu, 12 Apr 2007 09:58:02 +0800 (CST) Received: from [10.217.12.249] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id B080DEB1B21; Thu, 12 Apr 2007 09:58:02 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:x-enigmail-version:content-type; b=b43mA6f7j1Qt93oGv6bFQsWqoPaWeRDyNTn0AULP3mi204o6w7/9Mg3HZ2TVOTS2P WRiRmRZq54W1f16LYUxIw== Message-ID: <461D921E.5040206@delphij.net> Date: Thu, 12 Apr 2007 09:57:50 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig6ADB269EF08E8C356C438809" Subject: [PATCH] kern/681110 re-roll of RFC3522 (Eifel detection) patchset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 01:58:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6ADB269EF08E8C356C438809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I found this by accident on our wiki: Re-roll and bring in the Eifel detection originally submitted by Jeffrey Hsu. * PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/68110 * Eifel detection has the potential to improve network performance, in those cases where TCP has erroneously gone into slow-start to recover from apparent congestion. * Xin Li's patch So I have taken some time to do that. A new version of the patchset that is adapted to our latest -CURRENT code can be found at: http://research.delphij.net/freebsd/rfc3522.diff and http://people.freebsd.org/~delphij/for_review/rfc3522.diff Note that this version has not mixed with the Early Retransmission change as found in DragonFly. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig6ADB269EF08E8C356C438809 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHZIeOfuToMruuMARCuBKAJ9XCOtyEZNZjLQThoPR6FG/KbuNDwCeO1Wf bAPh1wptQ27bmduTYKv7LUY= =2ZDY -----END PGP SIGNATURE----- --------------enig6ADB269EF08E8C356C438809-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 03:37:13 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 308D716A402 for ; Thu, 12 Apr 2007 03:37:13 +0000 (UTC) (envelope-from yoitsmeremember@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.232]) by mx1.freebsd.org (Postfix) with ESMTP id E5CF313C459 for ; Thu, 12 Apr 2007 03:37:12 +0000 (UTC) (envelope-from yoitsmeremember@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so316638nza for ; Wed, 11 Apr 2007 20:37:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=l58bV8/KFUEVyFFcpYc4063XDt/JvnGcwOapTZ7jD6vJztmVKv29Eukt4NYz0M6ykiH6ftKH2w6nmQgH4aBe1NNQsKfhqwiJjXMGnjVJQKTDsx3bBUFNX8x/48rXOezYYaf8zubS5XZeNWTT2TB/eoE5e4Kx1uzD4qcfTu75K9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=sRmQvjMFdqOLcaQd8hEkln+yOA+WaGeSzz2WvfNSNSbpOIlenT+XQyJGcA7pPXaLhD5KIlZIpMqK+Za8HyN1AIzOlETj+0bu6BQ3q8iG7ixfWtZ1IUxNae3kzKiomsMHOrat78doTKJ6dthbPoZOg6SMMeqkuUdBNZwVdUtUg8E= Received: by 10.114.169.2 with SMTP id r2mr574090wae.1176347452695; Wed, 11 Apr 2007 20:10:52 -0700 (PDT) Received: by 10.114.72.5 with HTTP; Wed, 11 Apr 2007 20:10:52 -0700 (PDT) Message-ID: Date: Wed, 11 Apr 2007 22:10:52 -0500 From: Orum To: "FreeBSD-Net mailing list" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: altq unfortunately queuing vlan traffic. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yoitsmeremember@evil-geni.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 03:37:13 -0000 Hi, I just recently configured altq to run on my vge0 interface. The machine is running FreeBSD 6-STABLE (6.2-RELEASE doesn't have altq support in the vge driver). Before I go any further, let me show you a tiny diagram of my network: Private LAN ]----[vlan2, parent if = vge0] FreeBSD router [vge0 (doing nat via pf)]----[ Internet I'm using pf for nat on vge0, and would like to also like to use altq on that interface (no queuing is needed on the vlan2 interface). But, shortly after enabling it I noticed that my SSH session to that machine started to lag greatly. After going through and making a few sanity checks (cpu usage, disabling altq, etc.), I'm pretty sure I discovered that the problem is that altq is queuing packets destined for the vlan in vge0's queue because it is the parent interface. Ideally I would just add another interface, but unfortunately that's not possible. I also can't put the internet connection on a vlan for two reasons; 1) altq is not supported on vlan devices (I think I know why now too!), and 2) pf's nat does not work on vlan devices (probably for the same reason altq doesn't work on them). I guess this leaves me with two options. I can either make it so that altq will not queue packets on an interface for packets destined for a vlan that has that interface as a parent, or I can try and make altq work on the vlan interface, and modify pf's nat to work on vlan interfaces as well, thus eliminating the need to differentiate between those packets destined for a vlan and those for the untagged physical interface. The former seems like it would be the easier of the two, though neither option seems easy to me. Where would I go about making these modifications? In altq? Or does this have to do with the TCP/IP stack? Or something to do with the driver itself (to make matters more complicated, it uses VLAN_HWTAGGING)? I really have no idea where to begin. Or, if you can think of another easier solution to this problem, let me know! Thanks in advance, Ian From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 06:19:59 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6456016A400 for ; Thu, 12 Apr 2007 06:19:59 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id 0DF1013C469 for ; Thu, 12 Apr 2007 06:19:58 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 47399 invoked from network); 12 Apr 2007 05:53:17 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay00.pair.com with SMTP; 12 Apr 2007 05:53:17 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 12 Apr 2007 00:53:07 -0500 (CDT) From: Mike Silbersack To: LI Xin In-Reply-To: <461D921E.5040206@delphij.net> Message-ID: <20070412005137.A77693@odysseus.silby.com> References: <461D921E.5040206@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] kern/681110 re-roll of RFC3522 (Eifel detection) patchset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 06:19:59 -0000 On Thu, 12 Apr 2007, LI Xin wrote: > Hi, > > I found this by accident on our wiki: > > Re-roll and bring in the Eifel detection originally submitted by Jeffrey > Hsu. No. That is not going into FreeBSD if I can help it. http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL On top of that, we don't need yet another complication to the already too-complex retransmission code. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 08:41:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6592F16A500 for ; Thu, 12 Apr 2007 08:41:10 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3F29013C483 for ; Thu, 12 Apr 2007 08:41:10 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id DB70921321F; Thu, 12 Apr 2007 04:41:11 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 12 Apr 2007 04:41:10 -0400 X-Sasl-enc: 8PuEq2tKF4uG79Ukulsy+fX3x6N8CS9viSpHKQau4KAK 1176367270 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id E11ED16504; Thu, 12 Apr 2007 04:41:09 -0400 (EDT) Message-ID: <461DF0A2.5090304@FreeBSD.org> Date: Thu, 12 Apr 2007 09:41:06 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: Mike Silbersack References: <461D921E.5040206@delphij.net> <20070412005137.A77693@odysseus.silby.com> In-Reply-To: <20070412005137.A77693@odysseus.silby.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, LI Xin Subject: Re: [PATCH] kern/681110 re-roll of RFC3522 (Eifel detection) patchset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 08:41:10 -0000 First of all, Xin: Many thanks for your excellent work on bringing the code up to date. Mike Silbersack wrote: > > No. That is not going into FreeBSD if I can help it. > http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL > On top of that, we don't need yet another complication to the already > too-complex retransmission code. I wasn't aware of Ericsson's submission on this basis. Whilst FreeBSD's license is recognised by the OSI, the implications of having code in the kernel which are covered by an Ericsson patent are quite grim if anyone wishes to use FreeBSD for commercial purposes. I therefore agree with you that that this change should not go in, and have removed it from the Wiki. Kind regards, BMS From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 08:43:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF4C116A403; Thu, 12 Apr 2007 08:43:47 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 98BBB13C484; Thu, 12 Apr 2007 08:43:47 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 51603216C4C; Thu, 12 Apr 2007 04:43:49 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 12 Apr 2007 04:43:47 -0400 X-Sasl-enc: vf+74FBMSZMjknh0ZOGcMdiFd0yM47Iivo81U7cfQ/ik 1176367427 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 6B09422F49; Thu, 12 Apr 2007 04:43:47 -0400 (EDT) Message-ID: <461DF140.2020203@FreeBSD.org> Date: Thu, 12 Apr 2007 09:43:44 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: Andrew Thompson References: <20070412010707.GC9390@heff.fud.org.nz> In-Reply-To: <20070412010707.GC9390@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ipv6 multicast refcnt panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 08:43:47 -0000 Andrew Thompson wrote: > I have come across this panic which appears to be from incorrect > refcounting on the inet6 multicast code. > I'm assuming this is in -CURRENT, as the refcount code has not yet been MFCed. ... > in6m_refcount is still 1 so the in6_multi is not freed. I'll try to investigate further as time permits. Thanks for pointing this out, I suspect the same problem affects vlan and other nested cloners. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 08:47:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A829A16A405; Thu, 12 Apr 2007 08:47:28 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 4C03C13C4B9; Thu, 12 Apr 2007 08:47:28 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 262721CC5A; Thu, 12 Apr 2007 20:47:27 +1200 (NZST) Date: Thu, 12 Apr 2007 20:47:27 +1200 From: Andrew Thompson To: "Bruce M. Simpson" Message-ID: <20070412084727.GH9390@heff.fud.org.nz> References: <20070412010707.GC9390@heff.fud.org.nz> <461DF140.2020203@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461DF140.2020203@FreeBSD.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org Subject: Re: ipv6 multicast refcnt panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 08:47:28 -0000 On Thu, Apr 12, 2007 at 09:43:44AM +0100, Bruce M. Simpson wrote: > Andrew Thompson wrote: > >I have come across this panic which appears to be from incorrect > >refcounting on the inet6 multicast code. > > > I'm assuming this is in -CURRENT, as the refcount code has not yet been > MFCed. Yes sorry, a fresh current kernel. > >in6m_refcount is still 1 so the in6_multi is not freed. > > I'll try to investigate further as time permits. Thanks for pointing > this out, I suspect the same problem affects vlan and other nested cloners. Cool. Its 100% reproducible for me so hopefully you will be able to trigger the panic too. Andrew From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 09:26:29 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00E4A16A400 for ; Thu, 12 Apr 2007 09:26:29 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 633A913C44C for ; Thu, 12 Apr 2007 09:26:21 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 27C45EBA395; Thu, 12 Apr 2007 17:26:20 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id N3zJfwdHsuCV; Thu, 12 Apr 2007 17:26:12 +0800 (CST) Received: from [10.217.12.249] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id C3716EB2065; Thu, 12 Apr 2007 17:26:11 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=FTzq61yHg5hjYH9YrHQRFP6+CJM5BC8bTu9euG75N/xkaWaluAByEZmNEPP7fpS0b PtaQdPc4lTtEzqUz+RHyQ== Message-ID: <461DFB2B.10106@delphij.net> Date: Thu, 12 Apr 2007 17:26:03 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <461D921E.5040206@delphij.net> <20070412005137.A77693@odysseus.silby.com> <461DF0A2.5090304@FreeBSD.org> In-Reply-To: <461DF0A2.5090304@FreeBSD.org> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigAF4B91F449184C0F44FC22DA" Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] kern/681110 re-roll of RFC3522 (Eifel detection) patchset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 09:26:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAF4B91F449184C0F44FC22DA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bruce M. Simpson wrote: > First of all, >=20 > Xin: Many thanks for your excellent work on bringing the code up to dat= e. >=20 > Mike Silbersack wrote: >> >> No. That is not going into FreeBSD if I can help it. >> http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL >> On top of that, we don't need yet another complication to the already >> too-complex retransmission code. > I wasn't aware of Ericsson's submission on this basis. Whilst FreeBSD's= > license is recognised by the OSI, the implications of having code in th= e > kernel which are covered by an Ericsson patent are quite grim if anyone= > wishes to use FreeBSD for commercial purposes. >=20 > I therefore agree with you that that this change should not go in, and > have removed it from the Wiki. That's disappointing, but better safe than sorry. BTW. Is there any legal alternative, e.g. make this as an option like WANT_IDEA? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigAF4B91F449184C0F44FC22DA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHfsrOfuToMruuMARCp+0AJ0Rc+bsqljaVS/mz5gTd1a08FCD2QCginOz r5zJqrQMAoeAOm3QIAklO0o= =JCfg -----END PGP SIGNATURE----- --------------enigAF4B91F449184C0F44FC22DA-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 10:20:31 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD01C16A400 for ; Thu, 12 Apr 2007 10:20:31 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id B5DE613C457 for ; Thu, 12 Apr 2007 10:20:31 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id A9671215098; Thu, 12 Apr 2007 06:20:33 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 12 Apr 2007 06:20:31 -0400 X-Sasl-enc: pwmU/pWn2U1AvP8vE6IEZLaADfk3Kzvm0G0GKuzhn+Q/ 1176373231 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 5B8E26237; Thu, 12 Apr 2007 06:20:31 -0400 (EDT) Message-ID: <461E07ED.90201@FreeBSD.org> Date: Thu, 12 Apr 2007 11:20:29 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: yoitsmeremember@evil-geni.us References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Net mailing list Subject: Re: altq unfortunately queuing vlan traffic. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 10:20:31 -0000 I can't speak for ALTQ at the moment however I believe dummynet may work on vlan devices. I was careful not to break this when rewriting ether_input() in -CURRENT, as ip_dn_check_rule() is always called any time ether_demux() is entered (regardless if ether_input() has been re-entered due to the presence of M_PROMISC on a given mbuf chain). Regards, BMS From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 11:33:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1DA816A400; Thu, 12 Apr 2007 11:33:09 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 618D413C46C; Thu, 12 Apr 2007 11:33:09 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id AF653216CE9; Thu, 12 Apr 2007 07:33:11 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 12 Apr 2007 07:33:09 -0400 X-Sasl-enc: 0uy/bY5x0roxxlKthNKvLxZK+PimpqyDoBuOYPbpmhYl 1176377589 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id E76671B238; Thu, 12 Apr 2007 07:33:08 -0400 (EDT) Message-ID: <461E18F3.6000905@FreeBSD.org> Date: Thu, 12 Apr 2007 12:33:07 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: Andrew Thompson References: <20070412010707.GC9390@heff.fud.org.nz> In-Reply-To: <20070412010707.GC9390@heff.fud.org.nz> Content-Type: multipart/mixed; boundary="------------070108010701070003040309" Cc: freebsd-net@freebsd.org Subject: Re: ipv6 multicast refcnt panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 11:33:09 -0000 This is a multi-part message in MIME format. --------------070108010701070003040309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew Thompson wrote: > I have come across this panic which appears to be from incorrect > refcounting on the inet6 multicast code. > I can reproduce this panic, however I don't entirely understand what's going on. When the same IPv6 unicast address is configured twice on the edsc0 interface, the ifmcstat(8) utility reports that the refcnt for two IPv6 multicast addresses changed. I do not understand why the duplicate unicast address isn't rejected, or why groups are being joined twice for the same address. I strongly suspect this is a bug in KAME the kind of which existed in netinet (whereby the 224.0.0.1 address was being joined more than once per ifnet) which the refcounting change has exposed as a panic, a very brief look at the ifaddr code in netinet6 suggests this is the case. Before second address assignment: edsc0: inet6 f00f::1 group ff01::1%edsc0 refcnt 1 mcast-macaddr 33:33:00:00:00:01 refcnt 1 group ff02::2:f23c:3567%edsc0 refcnt 1 mcast-macaddr 33:33:f2:3c:35:67 refcnt 1 group ff02::1%edsc0 refcnt 1 mcast-macaddr 33:33:00:00:00:01 refcnt 1 group ff02::1:ff00:1%edsc0 refcnt 1 mcast-macaddr 33:33:ff:00:00:01 refcnt 1 After second address assignment: edsc0: inet6 f00f::1 group ff02::1:ff00:1%edsc0 refcnt 1 mcast-macaddr 33:33:ff:00:00:01 refcnt 1 group ff01::1%edsc0 refcnt 2 mcast-macaddr 33:33:00:00:00:01 refcnt 1 group ff02::2:f23c:3567%edsc0 refcnt 2 mcast-macaddr 33:33:f2:3c:35:67 refcnt 1 group ff02::1%edsc0 refcnt 2 mcast-macaddr 33:33:00:00:00:01 refcnt 1 The order of the addresses in the list has flipped around, which makes visual comparison that much more difficult. Flipping those around to the same order as the first sample yields: edsc0: inet6 f00f::1 group ff01::1%edsc0 refcnt 2 mcast-macaddr 33:33:00:00:00:01 refcnt 1 group ff02::2:f23c:3567%edsc0 refcnt 2 mcast-macaddr 33:33:f2:3c:35:67 refcnt 1 group ff02::1%edsc0 refcnt 2 mcast-macaddr 33:33:00:00:00:01 refcnt 1 group ff02::1:ff00:1%edsc0 refcnt 1 mcast-macaddr 33:33:ff:00:00:01 refcnt 1 So we can be sure the addresses themselves haven't changed, but the refcount on the IPv6 multicast entries has gone up by 1. The refcount is no longer proxied to the ifnet-level ifma object since the code was changed. I don't entirely understand the relationship between the protocol-level multicast addresses and the unicast address in netinet6, or why attempting to configure the same unicast address on the same interface more than once wasn't rejected with an error. As far as I can tell the code is correct for the single address case. I've attached a patch which makes the netinet6 detach path more like the netinet one, though this isn't going to make a great deal of difference apart from code style; the net code already calls in6_ifdetach() in the right order. We can weaken the error checking in if_delmulti() to get an operational kernel, but this kind of defeats the point of doing the error checking (which is there to expose such problems). When reporting problems with the networking code it is helpful to use ifmcstat, INVARIANTS, and the DIAGNOSTIC kernel option as I tend to add code to catch cases like this. Regards, BMS --------------070108010701070003040309 Content-Type: text/x-patch; name="in6detach.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="in6detach.diff" ==== //depot/user/bms/netdev/sys/netinet6/in6_ifattach.c#1 - /home/bms/p4/netdev/sys/netinet6/in6_ifattach.c ==== --- /tmp/tmp.3746.0 Thu Apr 12 12:32:23 2007 +++ /home/bms/p4/netdev/sys/netinet6/in6_ifattach.c Thu Apr 12 12:25:55 2007 @@ -76,6 +76,7 @@ static int get_ifid __P((struct ifnet *, struct ifnet *, struct in6_addr *)); static int in6_ifattach_linklocal __P((struct ifnet *, struct ifnet *)); static int in6_ifattach_loopback __P((struct ifnet *)); +static void in6_purgemaddrs __P((struct ifnet *)); #define EUI64_GBIT 0x01 #define EUI64_UBIT 0x02 @@ -731,8 +732,6 @@ struct rtentry *rt; short rtflags; struct sockaddr_in6 sin6; - struct in6_multi *in6m; - struct in6_multi *in6m_next; /* remove neighbor management table */ nd6_purge(ifp); @@ -790,18 +789,10 @@ IFAFREE(&oia->ia_ifa); } - /* leave from all multicast groups joined */ - in6_pcbpurgeif0(&udbinfo, ifp); in6_pcbpurgeif0(&ripcbinfo, ifp); - - for (in6m = LIST_FIRST(&in6_multihead); in6m; in6m = in6m_next) { - in6m_next = LIST_NEXT(in6m, in6m_entry); - if (in6m->in6m_ifp != ifp) - continue; - in6_delmulti(in6m); - in6m = NULL; - } + /* leave from all multicast groups joined */ + in6_purgemaddrs(ifp); /* * remove neighbor management table. we call it twice just to make @@ -889,4 +880,23 @@ } splx(s); +} + +static void +in6_purgemaddrs(ifp) + struct ifnet *ifp; +{ + struct in6_multi *in6m; + struct in6_multi *oin6m; + +#ifdef DIAGNOSTIC + printf("%s: purging ifp %p\n", __func__, ifp); +#endif + + IFF_LOCKGIANT(ifp); + LIST_FOREACH_SAFE(in6m, &in6_multihead, in6m_entry, oin6m) { + if (in6m->in6m_ifp == ifp) + in6_delmulti(in6m); + } + IFF_UNLOCKGIANT(ifp); } --------------070108010701070003040309-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 11:54:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F000816A402 for ; Thu, 12 Apr 2007 11:54:25 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 829CE13C448 for ; Thu, 12 Apr 2007 11:54:25 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l3CBsO6U001885; Thu, 12 Apr 2007 21:54:24 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l3CBsOMj001884; Thu, 12 Apr 2007 21:54:24 +1000 (EST) (envelope-from peter) Date: Thu, 12 Apr 2007 21:54:24 +1000 From: Peter Jeremy To: "Bruce M. Simpson" Message-ID: <20070412115424.GD834@turion.vk2pj.dyndns.org> References: <461E07ED.90201@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oTHb8nViIGeoXxdp" Content-Disposition: inline In-Reply-To: <461E07ED.90201@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.14 (2007-02-12) Cc: FreeBSD-Net mailing list Subject: Re: altq unfortunately queuing vlan traffic. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 11:54:26 -0000 --oTHb8nViIGeoXxdp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Apr-12 11:20:29 +0100, "Bruce M. Simpson" wrote: >I can't speak for ALTQ at the moment however I believe dummynet may work= =20 >on vlan devices. dummynet definitely does work on vlan devices. I use it extensively at wor= k. --=20 Peter Jeremy --oTHb8nViIGeoXxdp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGHh3w/opHv/APuIcRAjOKAJwNJiPFZv6WQJfc80GlhyvC/92NCgCgoMRB FuGTuUYzHHzrcHKDkztGPoI= =Rm6I -----END PGP SIGNATURE----- --oTHb8nViIGeoXxdp-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 14:28:02 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8FD116A400; Thu, 12 Apr 2007 14:28:02 +0000 (UTC) (envelope-from mallman@icir.org) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by mx1.freebsd.org (Postfix) with ESMTP id 953DD13C44C; Thu, 12 Apr 2007 14:28:02 +0000 (UTC) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l3CDScVG010048; Thu, 12 Apr 2007 06:28:39 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 6BF819CA538; Thu, 12 Apr 2007 09:28:33 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3196B1CF21E; Thu, 12 Apr 2007 09:28:21 -0400 (EDT) To: LI Xin From: Mark Allman In-Reply-To: <461DFB2B.10106@delphij.net> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Blue on Black MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 12 Apr 2007 09:28:21 -0400 Sender: mallman@icir.org Message-Id: <20070412132821.3196B1CF21E@lawyers.icir.org> Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: [PATCH] kern/681110 re-roll of RFC3522 (Eifel detection) patchset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 14:28:02 -0000 --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > BTW. Is there any legal alternative, e.g. make this as an option like > WANT_IDEA? I do not know what WANT_IDEA is. As far as alternatives, there is F-RTO (RFC 4138) and DSACK (RFCs 2883 & 3708). We have also worked on a response that is different (and unencumbered). It is just an internet-draft (and, in fact, needs rev-ed because we have a better idea in mind): Josh Blanton, Ethan Blanton, Mark Allman. Using Spurious Retransmissions to Adapt the Retransmission Timeout. December 2006. Internet-Draft draft-allman-rto-backoff-04.txt (work in progress). The problem is that these are not technically as good as Eifel, IMO. But, Ericsson has taken the obvious way to do things off the table, I am afraid. (Lots of the Eifel work would seem to me to not stand up to a challenge based on previous/simultaneous work and the obviousness of it. But, that is clearly pure conjecture and I am not putting up the funds to test the theory.) The good news is that in most environments if you use the standard RTO timer (RFC 2988) then the number of spurious timeouts experienced is vanishingly small. See: Mark Allman, Vern Paxson. On Estimating End-to-End Network Path Properties. Proceedings of the ACM SIGCOMM Technical Symposium, Cambridge, MA, September 1999. http://www.icir.org/mallman/papers/estimation.ps allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGHjP1WyrrWs4yIs4RAnKgAJwIlFn4NbC3Jucs7b2KT6QihT7jLQCfXUXA MBr3TUIE7VzCkm37tXUhf8o= =uCEJ -----END PGP SIGNATURE----- --=_bOundary-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 14:52:45 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DBD116A400 for ; Thu, 12 Apr 2007 14:52:45 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id B21CE13C459 for ; Thu, 12 Apr 2007 14:52:44 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 89059 invoked from network); 12 Apr 2007 14:52:43 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay01.pair.com with SMTP; 12 Apr 2007 14:52:43 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 12 Apr 2007 09:52:26 -0500 (CDT) From: Mike Silbersack To: LI Xin In-Reply-To: <461DFB2B.10106@delphij.net> Message-ID: <20070412095035.N77693@odysseus.silby.com> References: <461D921E.5040206@delphij.net> <20070412005137.A77693@odysseus.silby.com> <461DF0A2.5090304@FreeBSD.org> <461DFB2B.10106@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: [PATCH] kern/681110 re-roll of RFC3522 (Eifel detection) patchset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 14:52:45 -0000 On Thu, 12 Apr 2007, LI Xin wrote: > That's disappointing, but better safe than sorry. > > BTW. Is there any legal alternative, e.g. make this as an option like > WANT_IDEA? That sounds like an option... but is it worth it? Can you give us access to your testbench that shows eifel to be an important improvement over the current eifel-less stack we have right now? My guess is that SACK nullified most of eifel's importance. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 14:58:07 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C32016A406 for ; Thu, 12 Apr 2007 14:58:07 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id DF43013C4D1 for ; Thu, 12 Apr 2007 14:58:06 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.187.68] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1Hc0kM39Wy-00048A; Thu, 12 Apr 2007 16:58:05 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org, yoitsmeremember@evil-geni.us Date: Thu, 12 Apr 2007 16:57:50 +0200 User-Agent: KMail/1.9.5 References: In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4218025.m8SSxj5Hkn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704121658.00621.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+cpkJAMnKs2cct6ZRf4PVAzU3UN3j9HkGbrhm 3w5ccHrbShKvXqCMQfEOqBIyVd5rntR9WBCGMCNL8RFU9Unr+I O8Kks/n2qzCxAnEAIhoKQ== Cc: Subject: Re: altq unfortunately queuing vlan traffic. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 14:58:07 -0000 --nextPart4218025.m8SSxj5Hkn Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 12 April 2007 05:10, Orum wrote: > I just recently configured altq to run on my vge0 interface. The > machine is running FreeBSD 6-STABLE (6.2-RELEASE doesn't have altq > support in the vge driver). Before I go any further, let me show you a > tiny diagram of my network: > > Private LAN ]----[vlan2, parent if =3D vge0] FreeBSD router [vge0 (doing > nat via pf)]----[ Internet > > I'm using pf for nat on vge0, and would like to also like to use altq > on that interface (no queuing is needed on the vlan2 interface). But, > shortly after enabling it I noticed that my SSH session to that machine > started to lag greatly. After going through and making a few sanity > checks (cpu usage, disabling altq, etc.), I'm pretty sure I discovered > that the problem is that altq is queuing packets destined for the vlan > in vge0's queue because it is the parent interface. > > Ideally I would just add another interface, but unfortunately that's > not possible. I also can't put the internet connection on a vlan for > two reasons; 1) altq is not supported on vlan devices (I think I know > why now too!), and 2) pf's nat does not work on vlan devices (probably > for the same reason altq doesn't work on them). While queueing on vlan interfaces is not supported (as it doesn't make=20 sense in the ALTQ way of queueing) you can very well *classify* on vlan=20 interfaces and queue on the physical interface. The second point about=20 pf's NAT not working on vlan interfaces doesn't hold in my tests - can=20 you provide more details? What you'd do for your setup is the following: Define two (or more) queues on vge0 say q_lan and q_inet, then classify to= =20 direct the traffic to the queue it belongs to. Your setup is broken=20 without this anyway, as traffic in the vlan can suppress internet traffic=20 and vice versa. If you really have only one physical interface you have=20 to do queueing in any case. The setup in a nutshell looks like: altq on vge0 cbq bandwidth XXXMb queue { q_lan, q_wan } queue q_lan bandwidth YYYMb queue q_wan bandwidth ZZZMb cbq(default) pass on vlan0 .... keep state queue (q_lan) pass on vge0 ... to $next_hop keep state queue (q_wan) Of course you'd need to add child queues to the wan queue in order to=20 build you policy. Note that the classification ("queue (q_lan)") is done on the vlan=20 interface. The queueing happens later as the packet with the=20 classification tag hits the physical interface that defines the queue. > I guess this leaves me with two options. I can either make it so that > altq will not queue packets on an interface for packets destined for a > vlan that has that interface as a parent, or I can try and make altq > work on the vlan interface, and modify pf's nat to work on vlan > interfaces as well, thus eliminating the need to differentiate between > those packets destined for a vlan and those for the untagged physical > interface. The former seems like it would be the easier of the two, > though neither option seems easy to me. > > Where would I go about making these modifications? In altq? Or does > this have to do with the TCP/IP stack? Or something to do with the > driver itself (to make matters more complicated, it uses > VLAN_HWTAGGING)? I really have no idea where to begin. Or, if you can > think of another easier solution to this problem, let me know! =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart4218025.m8SSxj5Hkn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGHkj4XyyEoT62BG0RAj7wAJ0TxFXdZEYP/Lv+3TS4EQugWs2nhQCdHWxq NBglOFvsT5H3Nhhh80Jt2oc= =o3Y1 -----END PGP SIGNATURE----- --nextPart4218025.m8SSxj5Hkn-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 16:06:53 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A847116A400 for ; Thu, 12 Apr 2007 16:06:53 +0000 (UTC) (envelope-from yoitsmeremember@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by mx1.freebsd.org (Postfix) with ESMTP id 61EE113C457 for ; Thu, 12 Apr 2007 16:06:52 +0000 (UTC) (envelope-from yoitsmeremember@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so535854wra for ; Thu, 12 Apr 2007 09:06:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AFYNkvS3g0sdk5fd39H/KpB1ci8jzzv6Biliub8elB6ni6xTFYIss81NWQ//P7bmh5Te7VAA1BwHWTwYk3owv1VVCkPZ/haW4gGBTAheTWyar8nhoBqi6KWS+D7TVUoNQOd8CZ1ctLBxDDvSDhO270OeGflyRt/Irr/XFeRYTS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o2th8UOcN5FD+2PYAM9TbwX6ji2dFwhtPKLB/SaparM+01e/Vi3jIUrecIg89IJTCYK/e9o4Syuz2WLCjqZBd70YCR/n5GA8iMmBK5A6BsBKeULfC8rYR49RPu08J1T6hPM7o21UwFFDFtEJiLLAOS+vbmXELIRLBABPPSrtrKE= Received: by 10.115.58.1 with SMTP id l1mr802478wak.1176394011826; Thu, 12 Apr 2007 09:06:51 -0700 (PDT) Received: by 10.114.72.5 with HTTP; Thu, 12 Apr 2007 09:06:51 -0700 (PDT) Message-ID: Date: Thu, 12 Apr 2007 11:06:51 -0500 From: Orum To: "FreeBSD-Net mailing list" In-Reply-To: <200704121658.00621.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200704121658.00621.max@love2party.net> Subject: Re: altq unfortunately queuing vlan traffic. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yoitsmeremember@evil-geni.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 16:06:53 -0000 On 4/12/07, Peter Jeremy wrote: > On 2007-Apr-12 11:20:29 +0100, "Bruce M. Simpson" wrote: > >I can't speak for ALTQ at the moment however I believe dummynet may work > >on vlan devices. > > dummynet definitely does work on vlan devices. I use it extensively at work. > > -- > Peter Jeremy > Dummynet is unfortunately not an option as I will need to be able to run redundant stateful firewalls, unless there is something that allows you to do this with ipfw (I'm embarrased to say I don't know it that well). On 4/12/07, Max Laier wrote: > On Thursday 12 April 2007 05:10, Orum wrote: > > I just recently configured altq to run on my vge0 interface. The > > machine is running FreeBSD 6-STABLE (6.2-RELEASE doesn't have altq > > support in the vge driver). Before I go any further, let me show you a > > tiny diagram of my network: > > > > Private LAN ]----[vlan2, parent if = vge0] FreeBSD router [vge0 (doing > > nat via pf)]----[ Internet > > > > I'm using pf for nat on vge0, and would like to also like to use altq > > on that interface (no queuing is needed on the vlan2 interface). But, > > shortly after enabling it I noticed that my SSH session to that machine > > started to lag greatly. After going through and making a few sanity > > checks (cpu usage, disabling altq, etc.), I'm pretty sure I discovered > > that the problem is that altq is queuing packets destined for the vlan > > in vge0's queue because it is the parent interface. > > > > Ideally I would just add another interface, but unfortunately that's > > not possible. I also can't put the internet connection on a vlan for > > two reasons; 1) altq is not supported on vlan devices (I think I know > > why now too!), and 2) pf's nat does not work on vlan devices (probably > > for the same reason altq doesn't work on them). > > While queueing on vlan interfaces is not supported (as it doesn't make > sense in the ALTQ way of queueing) you can very well *classify* on vlan > interfaces and queue on the physical interface. The second point about > pf's NAT not working on vlan interfaces doesn't hold in my tests - can > you provide more details? I'll double check it, but when I tried it with 6.2-RELEASE the packets would leave the interface with the source address unchanged from the private network. > What you'd do for your setup is the following: > > Define two (or more) queues on vge0 say q_lan and q_inet, then classify to > direct the traffic to the queue it belongs to. Your setup is broken > without this anyway, as traffic in the vlan can suppress internet traffic > and vice versa. If you really have only one physical interface you have > to do queueing in any case. The setup in a nutshell looks like: > > altq on vge0 cbq bandwidth XXXMb queue { q_lan, q_wan } > queue q_lan bandwidth YYYMb > queue q_wan bandwidth ZZZMb cbq(default) > > pass on vlan0 .... keep state queue (q_lan) > pass on vge0 ... to $next_hop keep state queue (q_wan) > > Of course you'd need to add child queues to the wan queue in order to > build you policy. Sounds like a good idea, but in my case I'm using priority queuing and not class based queuing. I'm not sure how I would set the bandwidth on the priority queue, since it only has one bandwidth option, and it seems to be pretty critical to get it right when you're using altq to prioritize empty TCP ACKs. How would I do this with a priq? > Note that the classification ("queue (q_lan)") is done on the vlan > interface. The queueing happens later as the packet with the > classification tag hits the physical interface that defines the queue. > > > I guess this leaves me with two options. I can either make it so that > > altq will not queue packets on an interface for packets destined for a > > vlan that has that interface as a parent, or I can try and make altq > > work on the vlan interface, and modify pf's nat to work on vlan > > interfaces as well, thus eliminating the need to differentiate between > > those packets destined for a vlan and those for the untagged physical > > interface. The former seems like it would be the easier of the two, > > though neither option seems easy to me. > > > > Where would I go about making these modifications? In altq? Or does > > this have to do with the TCP/IP stack? Or something to do with the > > driver itself (to make matters more complicated, it uses > > VLAN_HWTAGGING)? I really have no idea where to begin. Or, if you can > > think of another easier solution to this problem, let me know! > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > Thanks, Ian From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 17:01:31 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84D6C16A407 for ; Thu, 12 Apr 2007 17:01:31 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 1289613C45B for ; Thu, 12 Apr 2007 17:01:30 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.187.68] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1Hc2fn3RYc-000668; Thu, 12 Apr 2007 19:01:28 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org, yoitsmeremember@evil-geni.us Date: Thu, 12 Apr 2007 19:00:35 +0200 User-Agent: KMail/1.9.5 References: <200704121658.00621.max@love2party.net> In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7792284.xIPRrjuzv8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704121901.26252.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18GIZtiTurPWKgNTSeD/TPvMZnPJHbfxg0NYjC H84xR2SGjDV8HAy/Szqrz7CIPayOioQj2HAqz+Hq8okvxy3SkZ emNl9S3E2ZAJQ5nHXG4Og== Cc: Subject: Re: altq unfortunately queuing vlan traffic. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 17:01:31 -0000 --nextPart7792284.xIPRrjuzv8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 12 April 2007 18:06, Orum wrote: > On 4/12/07, Max Laier wrote: > > On Thursday 12 April 2007 05:10, Orum wrote: > > > I just recently configured altq to run on my vge0 interface. The > > > machine is running FreeBSD 6-STABLE (6.2-RELEASE doesn't have altq > > > support in the vge driver). Before I go any further, let me show > > > you a tiny diagram of my network: > > > > > > Private LAN ]----[vlan2, parent if =3D vge0] FreeBSD router [vge0 > > > (doing nat via pf)]----[ Internet > > > > > > I'm using pf for nat on vge0, and would like to also like to use > > > altq on that interface (no queuing is needed on the vlan2 > > > interface). But, shortly after enabling it I noticed that my SSH > > > session to that machine started to lag greatly. After going > > > through and making a few sanity checks (cpu usage, disabling altq, > > > etc.), I'm pretty sure I discovered that the problem is that altq > > > is queuing packets destined for the vlan in vge0's queue because it > > > is the parent interface. > > > > > > Ideally I would just add another interface, but unfortunately > > > that's not possible. I also can't put the internet connection on a > > > vlan for two reasons; 1) altq is not supported on vlan devices (I > > > think I know why now too!), and 2) pf's nat does not work on vlan > > > devices (probably for the same reason altq doesn't work on them). > > > > While queueing on vlan interfaces is not supported (as it doesn't > > make sense in the ALTQ way of queueing) you can very well *classify* > > on vlan interfaces and queue on the physical interface. The second > > point about pf's NAT not working on vlan interfaces doesn't hold in > > my tests - can you provide more details? > > I'll double check it, but when I tried it with 6.2-RELEASE the packets > would leave the interface with the source address unchanged from the > private network. > > > What you'd do for your setup is the following: > > > > Define two (or more) queues on vge0 say q_lan and q_inet, then > > classify to direct the traffic to the queue it belongs to. Your > > setup is broken without this anyway, as traffic in the vlan can > > suppress internet traffic and vice versa. If you really have only > > one physical interface you have to do queueing in any case. The > > setup in a nutshell looks like: > > > > altq on vge0 cbq bandwidth XXXMb queue { q_lan, q_wan } > > queue q_lan bandwidth YYYMb > > queue q_wan bandwidth ZZZMb cbq(default) > > > > pass on vlan0 .... keep state queue (q_lan) > > pass on vge0 ... to $next_hop keep state queue (q_wan) > > > > Of course you'd need to add child queues to the wan queue in order to > > build you policy. > > Sounds like a good idea, but in my case I'm using priority queuing and > not class based queuing. I'm not sure how I would set the bandwidth > on the priority queue, since it only has one bandwidth option, and it > seems to be pretty critical to get it right when you're using altq to > prioritize empty TCP ACKs. How would I do this with a priq? You can combine cbq and priority scheduleing. Just look at the examples:=20 http://www.openbsd.org/faq/pf/queueing.html > > Note that the classification ("queue (q_lan)") is done on the vlan > > interface. The queueing happens later as the packet with the > > classification tag hits the physical interface that defines the > > queue. > > > > > I guess this leaves me with two options. I can either make it so > > > that altq will not queue packets on an interface for packets > > > destined for a vlan that has that interface as a parent, or I can > > > try and make altq work on the vlan interface, and modify pf's nat > > > to work on vlan interfaces as well, thus eliminating the need to > > > differentiate between those packets destined for a vlan and those > > > for the untagged physical interface. The former seems like it > > > would be the easier of the two, though neither option seems easy to > > > me. > > > > > > Where would I go about making these modifications? In altq? Or > > > does this have to do with the TCP/IP stack? Or something to do > > > with the driver itself (to make matters more complicated, it uses > > > VLAN_HWTAGGING)? I really have no idea where to begin. Or, if you > > > can think of another easier solution to this problem, let me know! > > > > -- > > /"\ Best regards, | mlaier@freebsd.org > > \ / Max Laier | ICQ #67774661 > > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > Thanks, > Ian > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart7792284.xIPRrjuzv8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGHmXmXyyEoT62BG0RAnPiAJ0XiW+z/2IOL5oGANC5W0+JKFBPLACeKNaf ZaLW51LN5AnHKaf+UtV/iQs= =EEJF -----END PGP SIGNATURE----- --nextPart7792284.xIPRrjuzv8-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 17:14:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D55A116A407 for ; Thu, 12 Apr 2007 17:14:18 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3F313C4B7 for ; Thu, 12 Apr 2007 17:14:18 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from jmb.local (t050096.ppp.asahi-net.or.jp [203.189.50.96]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 6E2D47301E; Fri, 13 Apr 2007 02:14:17 +0900 (JST) Date: Fri, 13 Apr 2007 02:14:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Andrew McDonald In-Reply-To: <20070405152547.GC6798@mcdonald.org.uk> References: <20070404211815.GA6798@mcdonald.org.uk> <20070405081639.GB6798@mcdonald.org.uk> <20070405152547.GC6798@mcdonald.org.uk> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: IPv6 Router Alert breaks forwarding X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Apr 2007 17:14:18 -0000 At Thu, 5 Apr 2007 16:25:47 +0100, Andrew McDonald wrote: > > The behavior looks reasonable, but I'd code it more explicitly with > > some comments so that the intent is clear and others can correctly > > modify it for future extensions. A possible patch to implement it is > > pasted below. One thing I'm not really sure is whether someone is > > using (or has used) other predefined alert values: > > > > 1 Datagram contains RSVP message. > > 2 Datagram contains an Active Networks message. > > > > (I guess you're now going to use values 3-35 per RFC3175). > > > > If there is a user, we need to be careful not to break compatibility. > > That patch looks good to me. > > I think RSVP is the only other potential current user (and most likely > without RFC3175 support). There appears to be some basic support for > IPv6 in the ISI RSVPd implementation (untouched since 1999), but from a > quick look at the code it is not clear whether they actually use the > IPv6 router alert anyway. It predates RFC3175. If you want to be very > conservative in changing behaviour you might want to include RSVP, but > it seems unlikely that anyone is using it. > > The only reference I know of for the Active Networks use is a published > paper (and the reference in RFC2711). I don't know of any running code. Okay, if no one else objects to it, I'll commit the change. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Fri Apr 13 08:48:20 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8EACD16A402 for ; Fri, 13 Apr 2007 08:48:20 +0000 (UTC) (envelope-from proks@logos.uptel.net) Received: from logos.uptel.net (logos.uptel.net [195.138.170.125]) by mx1.freebsd.org (Postfix) with ESMTP id 2821613C455 for ; Fri, 13 Apr 2007 08:48:17 +0000 (UTC) (envelope-from proks@logos.uptel.net) Received: from logos.uptel.net (logos.uptel.net [195.138.170.125]) by logos.uptel.net (Postfix) with ESMTP id 07FF933C1D; Fri, 13 Apr 2007 11:48:16 +0300 (EEST) Date: Fri, 13 Apr 2007 11:48:15 +0300 (EEST) From: "Prokofiev S.P." To: freebsd-net@freebsd.org Message-ID: <20070413104122.I17217@logos.uptel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@freebsd.org Subject: Hang up/down re0: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2007 08:48:20 -0000 I have a problem on FreeBSD 6.2-STABLE with NIC D-Link DGE-528(T). When I put interface into promiscuous mode or output by tcpdump or simply ifconfig xxx promisc/ifconfig xxx -promisc, the NIC hang down and then hang up. This is not normal behaviour... Sorry for my English. freebsd>[10:58:47]#>uname -a FreeBSD freebsd.xxxxx.xx 6.2-STABLE FreeBSD 6.2-STABLE #0: Tue Feb 13 16:19:02 EET 2007 proks@freebsd.xxxxx.xx:/usr/obj/usr/src/sys/FREEBSD i386 from src/sys/dev/re/if_re.c: __FBSDID("$FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.25 2007/02/02 00:48:55 yongari Exp $"); freebsd>[11:02:07]#>less /var/log/messages ....... Apr 13 10:54:52 freebsd kernel: net0: link state changed to DOWN Apr 13 10:54:52 freebsd kernel: vlan30: link state changed to DOWN Apr 13 10:54:52 freebsd kernel: vlan10: link state changed to DOWN Apr 13 10:54:56 freebsd kernel: net0: link state changed to UP Apr 13 10:54:56 freebsd kernel: vlan30: link state changed to UP Apr 13 10:54:56 freebsd kernel: vlan10: link state changed to UP from dmesg: re0: port 0xe800-0xe8ff mem 0xee020000-0xee0200ff irq 11 at device 14.0 on pci0 miibus0: on re0 rgephy0: on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: Ethernet address: 00:15:e9:ef:9b:6a re0: [FAST] from pciconf -lv: re0@pci0:14:0: class=0x020000 card=0x43001186 chip=0x43001186 rev=0x10 hdr=0x00 vendor = 'D-Link System Inc' class = network subclass = ethernet ifconfig: net0: flags=8843 mtu 1500 options=4b ether 00:15:e9:ef:9b:6a media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 vlan10: flags=8843 mtu 1500 inet xxx.xxx.xxx.x netmask 0xffffffc0 broadcast xxx.xxx.xxx.xx ether 00:15:e9:ef:9b:6a media: Ethernet autoselect (1000baseTX ) status: active vlan: 10 parent interface: net0 vlan30: flags=8843 mtu 1500 inet xxx.xxx.xxx.xxx netmask 0xffffffc0 broadcast xxx.xxx.xxx.xxx ether 00:15:e9:ef:9b:6a media: Ethernet autoselect (1000baseTX ) status: active vlan: 30 parent interface: net0 From owner-freebsd-net@FreeBSD.ORG Fri Apr 13 11:45:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8243316A402 for ; Fri, 13 Apr 2007 11:45:10 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 970ED13C48C for ; Fri, 13 Apr 2007 11:45:09 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 56046 invoked from network); 13 Apr 2007 15:50:29 +0400 Received: from unknown (HELO localhost) (88.212.205.2) by mail.sub.ru with SMTP; 13 Apr 2007 15:50:29 +0400 X-Virus-Scanned: by amavisd-new at mail.sub.ru Received: from unknown ([88.212.205.2]) by localhost (mail-new.sub.ru [88.212.205.2]) (amavisd-new, port 10024) with SMTP id U8NV-e3a42gK for ; Fri, 13 Apr 2007 15:50:23 +0400 (MSD) Received: from unknown (HELO ?192.168.139.47?) (tarkhil%sub.ru@192.168.139.47) by techno.sub.ru with SMTP; 13 Apr 2007 11:50:23 -0000 Message-ID: <461F6D39.2020407@webmail.sub.ru> Date: Fri, 13 Apr 2007 15:44:57 +0400 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: FreeBSD-Net mailing list Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: redirecting pf example X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Apr 2007 11:45:10 -0000 Hello! I'm trying to set up a box as round-robin TCP proxy. Of course, I'm trying to do everything on kernel-level. This simple setup rdr on sk0 proto tcp from any to any port = smtp -> port 25 round-robin should work. At least, I thought so. However, attempt to connect to port 25 yielded unexpected result. pfctl -s state shows self tcp 89.108.94.212:25 <- 89.108.94.91:25 <- 89.108.94.211:56975 CLOSED:SYN_SENT connection never established, and no IP packet ever sends out to 89.108.94.212:25 I don't understand this thing. Maybe someone can point me to my error? (firewall rules a quite permissive, in fact, they are pass in quick and pass out quick for all interfaces. attempt to telnet to port 25 outside works ok) Alex. From owner-freebsd-net@FreeBSD.ORG Fri Apr 13 16:18:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F69B16A400; Fri, 13 Apr 2007 16:18:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 30F9D13C469; Fri, 13 Apr 2007 16:18:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 239CC2176C7; Fri, 13 Apr 2007 12:18:26 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 13 Apr 2007 12:18:17 -0400 X-Sasl-enc: /LE+Egnj21I1h1RoZFgh3eFGYaERCuZLQudil9MzRqFT 1176481096 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 37E1FB997; Fri, 13 Apr 2007 12:18:16 -0400 (EDT) Message-ID: <461FAD46.20509@FreeBSD.org> Date: Fri, 13 Apr 2007 17:18:14 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <20070412010707.GC9390@heff.fud.org.nz> <461E18F3.6000905@FreeBSD.org> In-Reply-To: <461E18F3.6000905@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Andrew Thompson Subject: Re: ipv6 multicast refcnt panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Apr 2007 16:18:17 -0000 I speculate that the problem you are seeing in netinet6 is due to it not freeing referenced in6_multi objects when the interface address changes or the same address is re-added, as the same bug was present in netinet. Previous to the introduction of refcounting, FreeBSD would just leak memory. Further to this: The problem Yar was seeing with vlan and pfsync, which I pointed out, was an older bug which has been progressively shuffled around the stack due to code rewrites. I have a fix for the kernel panic caused by pfsync's member interface being detached which is now checked into bms_netdev, it should probably go straight into -CURRENT. The fix is cumulative -- pfsync's detach handler is called after netinet has torn down all inet state for an instance of ifnet, therefore it should not be trying to call in_delmulti(), however it should mark the ifp as no longer valid for pfsync's use. A suggested architectural fix going forward, is to change the semantics of objects owned by the netinet and netinet6 protocol domains, such as multicast group objects, to tear down hardware state when the ifnet instance goes away, yet allow consumers elsewhere in the kernel to retain handles for such objects. This is what the lower-level net code now does for ifmultiaddr objects. if_delmulti_locked() accepts an argument which specifies whether it is being called from if_detach(). If so, hardware state is torn down, and internal structures are freed, but the object *is not* freed if its reference count is not zero as someone still holds a pointer. In plainer language: netinet and netinet6 should probably be doing the same thing as net now does, insofaras this only apples to ifmultiaddr, the same should be done for in_multi and in6_multi. Of course, it would be easier to do this if per-protocol-domain state in ifnet were e.g. moved to the if_afdata[] array currently defined in ifnet for this purpose, this is guaranteed to break the ABI. The situation in ifnet as it stands just now strikes me as one of confusion. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Fri Apr 13 20:55:53 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B55216A406; Fri, 13 Apr 2007 20:55:53 +0000 (UTC) (envelope-from mallman@icir.org) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE9E13C484; Fri, 13 Apr 2007 20:55:53 +0000 (UTC) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l3DKtgSq004852; Fri, 13 Apr 2007 13:55:43 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 667B39DADCC; Fri, 13 Apr 2007 16:55:37 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 83AAC1D1E76; Fri, 13 Apr 2007 16:55:23 -0400 (EDT) To: Mike Silbersack From: Mark Allman In-Reply-To: <20070412095035.N77693@odysseus.silby.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Haircut MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 13 Apr 2007 16:55:23 -0400 Sender: mallman@icir.org Message-Id: <20070413205523.83AAC1D1E76@lawyers.icir.org> Cc: freebsd-net@freebsd.org, LI Xin , "Bruce M. Simpson" Subject: Re: [PATCH] kern/681110 re-roll of RFC3522 (Eifel detection) patchset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2007 20:55:53 -0000 --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > That sounds like an option... but is it worth it? Can you give us > access to your testbench that shows eifel to be an important > improvement over the current eifel-less stack we have right now? My > guess is that SACK nullified most of eifel's importance. SACK doesn't help in the domain where Eifel plays. The observation that led to Eifel is that sometimes the network sort of hicups and delays a stream of packets for a bit longer than usual. So, nothing is lost, but packets are delayed. So, since there is no loss there will be no SACK. If this delay lasts long enough then the RTO of the sender will expire and the sender will start retransmitting. And, in fact, will retransmit a whole window of stuff that doesn't really need retransmitted. Eifel tries to detect this case where the RTO expired and caused a spurious retransmission by looking at the timestamp on the first ACK to roll in after the RTO. F-RTO plays a different trick by carefully manipulating which data is transmitted after an RTO such that it can gain the same insight (i.e., whether the RTO was spurious). So, just because you have SACK doesn't mean you don't need Eifel. The work Vern Paxson and I did a lot of years back that I cited the other day shows that these hicups / delay spikes are pretty rare and if you use the RTO given in RFC 2988 then you won't fall prey to this effect much on the general Internet. Our measurements are now old. Things might have changed. I am aware of no more recent measurements that confirm or refute our's. Now, there is a claim that in mobile environments these sort of hicups happen quite often and so having something like Eifel is quite important. IMHO, this is not clear either way. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGH+47WyrrWs4yIs4RAlB2AJ49fvrqh45+XoXT+BotWMUvN2io1QCdEQqN CYbNh9NPOx7AWkqlQqil+GU= =zI0z -----END PGP SIGNATURE----- --=_bOundary-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 13 22:28:25 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA33016A4D5 for ; Fri, 13 Apr 2007 22:28:25 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 43E2213C484 for ; Fri, 13 Apr 2007 22:28:25 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id E722821558D for ; Fri, 13 Apr 2007 18:28:25 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 13 Apr 2007 18:28:25 -0400 X-Sasl-enc: muWjG7EgADT59At2z9VqgkwWyf8TJagdNxj6Ava33seL 1176503305 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 4BC27245AC for ; Fri, 13 Apr 2007 18:28:25 -0400 (EDT) Message-ID: <46200407.7020904@FreeBSD.org> Date: Fri, 13 Apr 2007 23:28:23 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: net@FreeBSD.org References: <45C14343.3020401@incunabulum.net> In-Reply-To: <45C14343.3020401@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: [PATCH] Zeroconf: avahi-autoipd support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2007 22:28:25 -0000 Bruce M Simpson wrote: > > Comments and feedback, particularly more in-depth testing by another > contributor, are very welcome. I have tested this on my local 802.11 > wireless segment with ath(4). > > Before this can be committed to ports or pushed upstream, it is > missing an rc script. > There has been feedback from the Avahi guys. I've updated the BSD-specific patch (which is against our present port), and the code has just been checked into Avahi SVN with some fixes. It would be great if someone could find time to look at integrating this. This way, we get a working autoipd until Fredrik (who will be working on Zeroconf for his Google SoC project) can make progress on a flavour of autoipd which is suitable for the base system. P.S. If anyone out there is working on wide-area DNS-SD, please make yourselves known to us... Regards, BMS From owner-freebsd-net@FreeBSD.ORG Sat Apr 14 02:17:39 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8620216A401 for ; Sat, 14 Apr 2007 02:17:39 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 61A7D13C469 for ; Sat, 14 Apr 2007 02:17:38 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id B7B56216AF1; Fri, 13 Apr 2007 22:17:39 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 13 Apr 2007 22:17:39 -0400 X-Sasl-enc: NwIaPxbVkdy80ISpoprDdZSdmsewudLg96sYL3ESpv2d 1176517058 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 9D3DF23637; Fri, 13 Apr 2007 22:17:38 -0400 (EDT) Message-ID: <462039C0.4070400@incunabulum.net> Date: Sat, 14 Apr 2007 03:17:36 +0100 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: FreeBSD-Net mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CODE DROP] Source-Specific Multicast for FreeBSD 7: Phase 1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2007 02:17:39 -0000 I am proud to announce the first code drop of SSM support for FreeBSD 7.0. From the README file: %%% Source-Specific Multicast for FreeBSD 7.0 -- Phase I This change brings FreeBSD closer to the standard of multicast API support offered by Linux 2.6 and Microsoft Windows "Longhorn". It is mostly of interest to organizations and individuals working with Internet multimedia applications, and IPv4/IPv6 routing, such as ISPs. It represents several weeks of work. The code is written to accomodate IPv6 and MLDv2 with only a little additional work. A regression test is included under src/tools/regression/netinet/ipmulticast in the code drop. The code is available in the bms_netdev branch on perforce.freebsd.org, or as a patch against -CURRENT extracted from this branch (with additional files, relative to src) available at: http://people.freebsd.org/~bms/ssm_phase1.tar The work is based on Wilbert de Graaf's IGMPv3 code drop for FreeBSD 4.6, which is available at: http://www.kloosterhof.com/wilbert/igmpv3.html %%% Regards, BMS From owner-freebsd-net@FreeBSD.ORG Sat Apr 14 03:06:06 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5ACC216A403 for ; Sat, 14 Apr 2007 03:06:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id 102E813C468 for ; Sat, 14 Apr 2007 03:06:05 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so912106nza for ; Fri, 13 Apr 2007 20:06:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=S8868JiJX+GF3kG+VMswaSFCt8iqsrNb8A5pu6IrsEr6EuF1p6aBp2O6Mj+SV279z5ALIxKvFHZbaT50rid3OYjyK8gH3L/pJoWThp0JRnFtCT+ADn17beGZSqYT7Fc8T2jeZWBCyHyjJNW9RhI6QQtr0HMYSHM1LFrJ09FKTEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=cFBghuIoyu0KhCjcrg6L/CeWhYIOS0rlAHFDIViyZZVDXOA7QIYnifpNlLAwJK0yeBNLoqnt7hnQ1U2Ar82WD+Y0G4T8JXGGNV952krFSYc8ZihgBNM9uQBUxvw0bYlqRAqb4HYStQYpW8P97B5avxxzPGL/D346P8P7/ptzb+g= Received: by 10.115.19.16 with SMTP id w16mr1201342wai.1176519965180; Fri, 13 Apr 2007 20:06:05 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id q20sm2186942pog.2007.04.13.20.06.01; Fri, 13 Apr 2007 20:06:03 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l3E35wxR013469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Apr 2007 12:05:58 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l3E35uUT013468; Sat, 14 Apr 2007 12:05:56 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 14 Apr 2007 12:05:56 +0900 From: Pyun YongHyeon To: "Prokofiev S.P." Message-ID: <20070414030556.GA12777@cdnetworks.co.kr> References: <20070413104122.I17217@logos.uptel.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <20070413104122.I17217@logos.uptel.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: Hang up/down re0: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2007 03:06:06 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 13, 2007 at 11:48:15AM +0300, Prokofiev S.P. wrote: > > I have a problem on FreeBSD 6.2-STABLE with NIC D-Link DGE-528(T). > When I put interface into promiscuous mode or output by tcpdump or simply > ifconfig xxx promisc/ifconfig xxx -promisc, the NIC hang down and then hang > up. > This is not normal behaviour... Please try attached patch and let me know the result. Thanks. -- Regards, Pyun YongHyeon --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.promisc.patch" Index: if_re.c =================================================================== RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v retrieving revision 1.88 diff -u -r1.88 if_re.c --- if_re.c 28 Mar 2007 18:07:12 -0000 1.88 +++ if_re.c 14 Apr 2007 03:03:34 -0000 @@ -2509,10 +2509,18 @@ break; case SIOCSIFFLAGS: RL_LOCK(sc); - if (ifp->if_flags & IFF_UP) - re_init_locked(sc); - else if (ifp->if_drv_flags & IFF_DRV_RUNNING) - re_stop(sc); + if ((ifp->if_flags & IFF_UP) != 0) { + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) { + if (((ifp->if_flags ^ sc->rl_if_flags) + & IFF_PROMISC) != 0) + re_setmulti(sc); + } else + re_init_locked(sc); + } else { + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) + re_stop(sc); + } + sc->rl_if_flags = ifp->if_flags; RL_UNLOCK(sc); break; case SIOCADDMULTI: Index: ../../pci/if_rlreg.h =================================================================== RCS file: /home/ncvs/src/sys/pci/if_rlreg.h,v retrieving revision 1.64 diff -u -r1.64 if_rlreg.h --- ../../pci/if_rlreg.h 16 Jan 2007 20:35:23 -0000 1.64 +++ ../../pci/if_rlreg.h 14 Apr 2007 03:03:35 -0000 @@ -728,6 +728,7 @@ uint32_t rl_hwrev; uint32_t rl_rxlenmask; int rl_testmode; + int rl_if_flags; int suspended; /* 0 = normal 1 = suspended */ #ifdef DEVICE_POLLING int rxcycles; --nFreZHaLTZJo0R7j-- From owner-freebsd-net@FreeBSD.ORG Sat Apr 14 05:40:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD49116A400 for ; Sat, 14 Apr 2007 05:40:32 +0000 (UTC) (envelope-from gore_jarold@yahoo.com) Received: from web63005.mail.re1.yahoo.com (web63005.mail.re1.yahoo.com [69.147.96.216]) by mx1.freebsd.org (Postfix) with SMTP id 8379E13C4AD for ; Sat, 14 Apr 2007 05:40:32 +0000 (UTC) (envelope-from gore_jarold@yahoo.com) Received: (qmail 27115 invoked by uid 60001); 14 Apr 2007 05:13:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=wR7JOtevlZMmH/6BRTR/5jRpzotF/LxMlF/ONzUKOmkCdWeIfvv+o9kTEFI7NUtG/fs5d4tG6btuauj/IQr55itXOr85/mPvIT7TDsBqJOg3ikmS4WlaW+yDdnWHOOuYL1fDxNRD6KiSvsAhp7hpM2jpyFHfWMqi/sl93Vgmt9k=; X-YMail-OSG: q328ZjgVM1mzZt57ZqkUGaJ8C3HIT0B4uc3dUa5.ESUMAUHRx.SU0kA7AAJ6b505SdHrUnxPrsfnrh7.SdAS7fW9NPfM_b6rrpgJ Received: from [75.72.230.91] by web63005.mail.re1.yahoo.com via HTTP; Fri, 13 Apr 2007 22:13:52 PDT Date: Fri, 13 Apr 2007 22:13:52 -0700 (PDT) From: Gore Jarold To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-ID: <100774.26745.qm@web63005.mail.re1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: WiFi channel bonding with netgraph - possible ? Back end needed ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Apr 2007 05:40:33 -0000 Let's say I live in a dorm room, or a large condo building. And let's say that everyone has the same ISP, and everyone is getting 3 mbps down and 512 kbps up, and there is no possibility of a better connection. And finally, let's say that everyone is running wide open wifi access points. Would it be possible to equip a computer with four (or more) wireless ethernet cards, jump on four open APs simultaneously, and bond them all together with netgraph to get a 12 mbps down and 2 mbps up connection ? The two main conceptual questions I have about this are: - do I need a back end somewhere (a collocated server) to tie all four connections back together into one again ? If I round-robin through the cards for each network request that would not _truly_ give me a bonded connection, and I wouldn't often get the full bonded bandwidth (unless I was doing lots of tiny, concurrent network transfers). It would seem that if I wanted to truly bond the connections into one, I would need them all to talk to some central server that would represent it to the world as a single IP ... - I have read that bonding wireless cards with netgraph is not as easy as bonding normal ethernet cards, because you need to arbitrarily assign and re-assign MAC addresses over and over on the fly, and the firmwares of many wireless cards do not allow one to do this ... I believe I saw a posting from a few years back that indicated Lucent cards (for instance) could not do this ... Comments ? The idea is to bond things into one, single, usable connection that could provide multiple connections worth of bandwidth for single-threaded network transactions (like downloading a single file from an ftp server). Perhaps there is a better tool to do this with than netgraph ? --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. From owner-freebsd-net@FreeBSD.ORG Sat Apr 14 09:53:55 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A296716A403 for ; Sat, 14 Apr 2007 09:53:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8299613C459 for ; Sat, 14 Apr 2007 09:53:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id F01332164F0; Sat, 14 Apr 2007 05:53:56 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 14 Apr 2007 05:53:55 -0400 X-Sasl-enc: 5Rc5LfYB/wOm1IebwF9R/p+240v3Q39R0uY3Z2xlrVrc 1176544435 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 18678261AC; Sat, 14 Apr 2007 05:53:55 -0400 (EDT) Message-ID: <4620A4B1.2060602@FreeBSD.org> Date: Sat, 14 Apr 2007 10:53:53 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: Gore Jarold References: <100774.26745.qm@web63005.mail.re1.yahoo.com> In-Reply-To: <100774.26745.qm@web63005.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: WiFi channel bonding with netgraph - possible ? Back end needed ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Apr 2007 09:53:55 -0000 Gore Jarold wrote: > Comments ? The idea is to bond things into one, single, usable connection that could provide multiple connections worth of bandwidth for single-threaded network transactions (like downloading a single file from an ftp server). Perhaps there is a better tool to do this with than netgraph ? > > You could try pf's load-balanced NAT feature to deal with the NAT. This of course assumes you can configure a FreeBSD router directly with line presentation i.e. not using an intermediate box between it and the link to the ISP. However, I can't say I like the idea much of trying to tie all those nodes together with tunnels transiting the ISP. Sounds like a clear cut case for 802.11s ESS Mesh... which isn't available yet. BMS