From owner-freebsd-net@FreeBSD.ORG Sun Apr 1 02:46:58 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 D022416A401; Sun, 1 Apr 2007 02:46:58 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id A4B2713C44C; Sun, 1 Apr 2007 02:46:58 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l312aJuM095986; Sat, 31 Mar 2007 19:36:19 -0700 (PDT) Date: Sun, 01 Apr 2007 10:45:00 +0900 Message-ID: From: gnn@FreeBSD.org To: Mike Makonnen In-Reply-To: <20070329182906.GB38703@rogue.navcom.lan> References: <20070329182906.GB38703@rogue.navcom.lan> 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: freebsd-net@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Apr 2007 02:46:58 -0000 Hi, I'm going to take a look over these changes as well. Best, George From owner-freebsd-net@FreeBSD.ORG Sun Apr 1 09:56: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 6CA5F16A401 for ; Sun, 1 Apr 2007 09:56:23 +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 0C3DD13C465 for ; Sun, 1 Apr 2007 09:56:20 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 8DAE91CC58; Sun, 1 Apr 2007 21:56:18 +1200 (NZST) Date: Sun, 1 Apr 2007 21:56:18 +1200 From: Andrew Thompson To: Niki Denev Message-ID: <20070401095618.GA24408@heff.fud.org.nz> References: <20070329235520.GD97061@heff.fud.org.nz> <460E6536.7060805@totalterror.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <460E6536.7060805@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: Sun, 01 Apr 2007 09:56:23 -0000 On Sat, Mar 31, 2007 at 04:42:14PM +0300, Niki Denev wrote: > Andrew Thompson wrote: > > Hi, > > > > > > 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. > > > > This is great news! I was waiting for this for ages :) > > I had to apply the attached to compile it on my 2 hour old -CURRENT, > i'm not sure why single space before the tab confused Make... anyways > it seems to work perfectly when i tested it on my laptop with the built > in fxp0 interface and one cardbus xl0 adapter in failover mode. > I'll try to setup next a wireless network so i can test the cool > wired/wireless roaming example from the manual page. Great, thanks for testing. > --- if_trunk-20070330b.diff.orig Sat Mar 31 16:23:30 2007 > +++ if_trunk-20070330b.diff Sat Mar 31 16:24:02 2007 > @@ -440,7 +440,7 @@ > + > +.if ${MK_INET6_SUPPORT} != "no" > + opt_inet6.h: > -+ echo "#define INET6 1" > ${.TARGET} > ++ echo "#define INET6 1" > ${.TARGET} > +.endif > +.endif > + I have fixed this up, a couple of spaces slipped into the Makefile. cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Sun Apr 1 10:19: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 228D316A401 for ; Sun, 1 Apr 2007 10:19:06 +0000 (UTC) (envelope-from rock_on_the_web@hotmail.com) Received: from bay0-omc3-s24.bay0.hotmail.com (bay0-omc3-s24.bay0.hotmail.com [65.54.246.224]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3E113C45B for ; Sun, 1 Apr 2007 10:19:06 +0000 (UTC) (envelope-from rock_on_the_web@hotmail.com) Received: from hotmail.com ([65.55.154.109]) by bay0-omc3-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 1 Apr 2007 03:07:06 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 1 Apr 2007 03:07:06 -0700 Message-ID: Received: from 65.55.154.123 by by143fd.bay143.hotmail.msn.com with HTTP; Sun, 01 Apr 2007 10:07:01 GMT X-Originating-IP: [202.172.126.254] X-Originating-Email: [rock_on_the_web@hotmail.com] X-Sender: rock_on_the_web@hotmail.com From: "Da Rock" To: freebsd-net@freebsd.org Date: Sun, 01 Apr 2007 10:07:01 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 01 Apr 2007 10:07:06.0301 (UTC) FILETIME=[80A1EED0:01C77445] Subject: intel 802.11 2200BG routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Apr 2007 10:19:06 -0000 Call me dumb, but I'm having some strange issues trying to get my laptop to communicate properly with my network. First the iwi if works on boot, but then drops out. I have a wpa_supplicant working, but after a while it drops off and loses the connection on me. The only way for me to get it going again is to kill off wpa_supplicant and run it manually every time it drops. Next I can't get the if to talk to the network and access the net if the rl0 (ethernet) if has been plugged in- it won't switch back to wifi once its been cabled it has to be rebooted. I have been tried using routed but it doesn't like the situation any better. It still defaults to rl0. I've used netstat to check the route tables, and I've used ifconfig to set some metrics for the interfaces- making a rl0 a higher priority, but only if connected. Now I can't even get the iwi to see the dns or gateway. So I could use some guidance as to what I can do to rectifiy this problem. I have 2 goals: 1. setup iwi to start on boot, and attach to my ap whenever its in range. 2. make sure iwi stays connected without manually monitoring it. 3. prioritise my routes via the rl0 and iwi if's so that cable is used over wifi, but both can be used to access the network. To satisfy number 2- is there a script/daemon/whatever to monitor and restart services when required for instances like this? or do I need to make one up for my circumstances here? Cheers Da Rock _________________________________________________________________ Advertisement: Win tickets to see Muse at London’s Wembley Stadium. Go now! http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=761&referral=hotmailtagline&URL=http://music.ninemsn.com.au/muse From owner-freebsd-net@FreeBSD.ORG Sun Apr 1 10:49: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 BDF3616A404 for ; Sun, 1 Apr 2007 10:49:01 +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 835E913C484 for ; Sun, 1 Apr 2007 10:49:01 +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 819612110A1; Sun, 1 Apr 2007 06:49:02 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 01 Apr 2007 06:49:01 -0400 X-Sasl-enc: 5vywpw7WLsMfRGRbP4DqpztGzTCWKywERltOApTVZOdj 1175424541 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 2E5133777A; Sun, 1 Apr 2007 06:49:01 -0400 (EDT) Message-ID: <460F8E1B.80904@FreeBSD.org> Date: Sun, 01 Apr 2007 11:48:59 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Da Rock References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: intel 802.11 2200BG routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Apr 2007 10:49:01 -0000 Da Rock wrote: > > So I could use some guidance as to what I can do to rectifiy this > problem. I have 2 goals: > 1. setup iwi to start on boot, and attach to my ap whenever its in range. > 2. make sure iwi stays connected without manually monitoring it. > 3. prioritise my routes via the rl0 and iwi if's so that cable is used > over wifi, but both can be used to access the network. Umm, that's 3 goals. :^) The short answer is, you can't do what you're trying to do, yet. You can cut over without rebooting, you just need to remember to kill off all dhclient processes and manually remove the default route, as in FreeBSD all forwarding entries ('routes') reference an interface pointer, and the PRC_IFDOWN handler will not touch routes marked RTF_STATIC. No one as far as I know has rolled a 'cutover' script. What would be really useful is a port which can do this cutover in a more general way until the stack is changed. This isn't that different from say Microsoft Windows where a manual cutover is needed, although the OS having a multipath FIB ('routing table') helps. The long answer is, it's possible, and it requires some things in the network stack to be carefully reworked. I have looked at these issues in some depth; there are at least 3 items on the Network Stack Wiki which are directly relevant to making the kind of clean cut-over between wireless/wired interfaces possible. Notably looking at the PRC_IFDOWN handler in netinet, making forwarding entry lookup skip interfaces marked down, and introducing route preference into the routing trie. There are historical reasons why the code is the way it is. It will take a while to get these issues addressed going forward. Regards, BMS P.S. routed isn't going to help you at all in this situation, it's just an implementation of the RIPv2 routing protocol; it may have helped as the routes it introduces to the kernel are !RTF_STATIC. One thing I haven't tried is IPv4 Router Discovery (rdisc), that may help update the default route quickly. The problem with this of course is the additional network configuration in the infrastructure itself. From owner-freebsd-net@FreeBSD.ORG Sun Apr 1 11:32:26 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 34DE216A417; Sun, 1 Apr 2007 11:32:26 +0000 (UTC) (envelope-from ilya@po4ta.com) Received: from jerry.kiev.farlep.net (jerry.kiev.farlep.net [213.130.24.8]) by mx1.freebsd.org (Postfix) with ESMTP id BD86C13C43E; Sun, 1 Apr 2007 11:32:25 +0000 (UTC) (envelope-from ilya@po4ta.com) Received: from ilya.kiev.farlep.net ([62.221.47.37] helo=[10.0.0.3]) by jerry.kiev.farlep.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62 (FreeBSD)) (envelope-from ) id 1HXyIE-0008Q4-NJ; Sun, 01 Apr 2007 14:32:18 +0300 Message-ID: <460F9836.6010608@po4ta.com> Date: Sun, 01 Apr 2007 14:32:06 +0300 From: Ilya Bobir User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Julian Elischer References: <460D75CE.70804@elischer.org> <20070330145938.A88154@xorpc.icir.org> <460DA258.2030402@elischer.org> <460EDB97.8030906@po4ta.com> In-Reply-To: <460EDB97.8030906@po4ta.com> Content-Type: multipart/mixed; boundary="------------080601000200030409070503" Cc: Luigi Rizzo , ipfw@freebsd.org, FreeBSD Net Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Apr 2007 11:32:26 -0000 This is a multi-part message in MIME format. --------------080601000200030409070503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ilya Bobir wrote: > Julian Elischer wrote: >> This is pretty close.. I know I've mentioned this to people several >> times over >> the last year or so. the trick is to try do it in a way that the >> average packet >> doesn't need to do any locks to get in and the updater does more work. >> if you are willing to acquire a lock on both starting and ending >> the run through the firewall it is easy. >> (I already have code to do that..) >> (see http://www.freebsd.org/~julian/atomic_replace.c (untested but >> probably close.) >> doing it without requiring that each packet get those locks however >> is a whole new level of problem. > > Please, take a look at this variant. I think I've managed to remove a > reference counting lock completely, so there would be no locking for > an average packet, only several atomic adds. > > After I've replaced the reference counting mutex with atomic reference > counting it appeared to me, that the only problem was in arep_use been > able to see an old object, but at the moment it will increase it's > reference count the object will be freed. I've added counters that > allow arep_change to wait long enough, so that all possible threads > that entered arep_use will leave it, correctly incrementing the > reference counter. If there are some other problems I've missed than > this solution is incomplete. After thinking a bit more, I've found some situations where my previous solution would fail. Check this one, please. =) --------------080601000200030409070503 Content-Type: text/plain; name="atomic_replace.no_ref_mtx.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="atomic_replace.no_ref_mtx.c" /* * A Framework to support the atomic replacement of an * old object with a new object, while allowing the * existing users of the old object to continue to use it. * * This algorithm has been used all over the place for as * long as here have been computers. e.g. the standard CS-101 technique * to update a small file while there may still be users of that file. * (*) make new version of file. * (*) mv new old. * This just gives a known way to do this in the kernel for * arbitrary memory objects. * */ #include #include /* * !!!IMPORTANT!!! * Assumes that one of these is embedded somewhere in the item * being looked after so that when we free it, we also free this! */ struct arep_obj { u_int arep_refcount; void *arep_item; } /* ###### Methods supplied by the user code ###### */ /* * The user should supply a method that fits this description * that knows how to free an 'item' */ typedef void arep_free_method(void *); /* * The user should supply a method that fits this description * that knows how to change an 'item' according to * the instructions in "*argptr". */ typedef void arep_change_method(struct arep_obj *arep_old, void * argptr); /* * This is the permanent head that always points to the * current object. */ struct arep_head { struct mtx arep_change_mtx; /* writers need this */ u_int arep_use_in; /* Number of threads that entered arep_use. */ u_int arep_use_out; /* Number of threads that exited arep_use. */ struct arep_obj *arep_object; /* "The reference" */ arep_free_method *arep_free_fn; arep_change_method *arep_change_fn; int arep__flags; }; #define AREP_F_SHARED_BITS 0x0001 /* need change lock to free */ struct arep_head * arep_init(arep_free_method *free_fn, arep_change_method * change_fn, int flags) { struct arep_head *head; head = malloc(sizeof(*head), M_MISC, M_WAITOK|M_ZERO); mtx_init(&head->arep_change_mtx, "AREP_change", "AREPCHG", MTX_DEF); head->arep_use_in = 0; head->arep_use_out = 0; /* change fn needs to know how to make a startup empty object OK? */ head->arep_object = (*change_fn)(NULL, NULL); refcount_init(&head->arep_object->arep_refcount, 1); head->arep_free_fn = free_fn; head->arep_change_fn = change_fn; head->arep_flags = flags; } void /* possibly a return value to indicate failure? */ arep_change(struct arep_head *head, void *argptr) { struct arep_obj *obj, *old; u_int in_count, out_count; mtx_lock(&head->arep_change_mtx); old = head->arep_object; obj = (*head->arep_change)(old, argptr); if (obj == old) { mtx_unlock(&head->arep_change_mtx); return; } refcount_init(&obj->arep_refcount, 1); /* * It is possible, that at the moment we are be decreasing a * reference count for the old object some consumers in arep_use * already seen the old object but still did not increase the * reference counter for it. In order to let them do so we will * count the number of consumers who have left the arep_use at some * moment before the update and the number of consumers who have * entered the arep_use at some moment after the update. * * atomic_load_acq_int will make sure, that other threads will see * new object address before we will read the counter. */ out_count = atomic_load_acq_int(&head->arep_use_out); arep_head->arep_object = old; in_count = atomic_load_acq_int(&head->arep_use_in); /* * Wait for a moment when all threads that entered arep_use will * leave it. * * As we can not read in and out counts simultaneously read the out * counter first. * * Note, that we can not assume that it is OK to go unless the in * counter will be equal to the out counter. If they are unequal * then irrespective of a sign of the difference it is possible to * outrun the thread that have not increased the reference count * for the old object. */ while (in_count != out_count) { out_count = atomic_load_acq_int(&head->arep_use_out); in_count = atomic_load_acq_int(&head->arep_use_in); } if (refcount_release(&old->arep_refcount) == 1) { /* We are definitely the last holder. */ (*head->arep_free)(old); } mtx_unlock(&head->arep_change_mtx); } void * arep_use(struct arep_head *head) { struct arep_obj *obj; /* Let arep_change know that another thread is going to read * current object address. */ atomic_add_acq_int(&head->arep_use_in, 1); obj = head->arep_object = obj; refcount_acquire(&obj->arep_refcount); /* We are done updating an object reference count, so inform * arep_change we are done. */ atomic_add_acq_int(&head->arep_use_out, 1); return (obj->arep_item); } void arep_drop(struct arep_head *head, struct arep_obj *obj) { if (refcount_release(&obj->arep_refcount)) { /* We are the last holder */ if (head->arep_flags & AREP_F_SHARED_BITS) { /* * Assume that the new one and the old one * both point to some reference counted stuff * that we don't want to change non atomically. */ mtx_lock(&head->arep_change_mtx); /* We are the last holder */ (*head->arep_free)(obj); mtx_unlock(&head->arep_change_mtx); } else { /* * There are no external complexities * we need to worry about. */ (*head->arep_free)(obj); } } } --------------080601000200030409070503-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 1 12:19: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 F3D7F16A403 for ; Sun, 1 Apr 2007 12:19:18 +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 C011613C4C1 for ; Sun, 1 Apr 2007 12:19:18 +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 2A7B746FC2; Sun, 1 Apr 2007 08:19:18 -0400 (EDT) Date: Sun, 1 Apr 2007 13:19:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <460D75CE.70804@elischer.org> Message-ID: <20070401131715.H1185@fledge.watson.org> References: <460D75CE.70804@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Apr 2007 12:19:19 -0000 On Fri, 30 Mar 2007, Julian Elischer wrote: > I have been looking at the IPFW code recently, especially with respect to > locking. There are some things that could be done to improve IPFW's > behaviour when processing packets, but some of these take a toll (there is > always a toll) on the 'updating' side of things. > > For example. I can make IPFW lock-free during processing of packets (i.e. > not holding any locks while traversing the list) which would solve problems > we have with lock-order reversals when it needs to look at the socket layer > (which needs socket layer locks). Unfortunatly this would make it a lot more > expensive in the case where new rules are being added to the list. possibly > a LOT more expensive. Now, this would only matter if one was adding (or > deleting) hundreds of rules per second to the firewall, but as I've > discovered, there's always SOMEONE that is doing the very thing you imagine > that no-one would ever do. > > In my imagination, most of the people who did this sort of thing don't need > to do it any more as tables obviate the need for that sort of thing. > > Is there anyone out there who is adding hundreds (or even dozens) of rules > per second on a continuous basis, or who wants rule changing to be a really > efficient operation? (does it matter to you if it takes a few milliSecs to > add a rule?) Just to make sure this hits the public thread also, as I know we've talked about it privately: Stephan Upholf has an implementation of a mostly-read lock in the works, which avoids any atomic operations during acquisition of a read reference, at the cost of increasing the cost of write lock acquires. This might provide what we need without fundamentally restructuring ipfw. It would be useful, once that is available, to examine the costs and benefits of both approaches side-by-side. Historically, I've been quite interested in doing something like that you describe, but the complexity cost is high, so if we can make a simpler solution (mrlocks) work just as well, that would be preferable. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 11:08:14 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 0DB5116A47F for ; Mon, 2 Apr 2007 11:08:14 +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 F014613C4BB for ; Mon, 2 Apr 2007 11:08:13 +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 l32B8Dw7052205 for ; Mon, 2 Apr 2007 11:08:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l32B8C7k052201 for freebsd-net@FreeBSD.org; Mon, 2 Apr 2007 11:08:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Apr 2007 11:08:12 GMT Message-Id: <200704021108.l32B8C7k052201@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, 02 Apr 2007 11:08:14 -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 2 15:26: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 F2AC916A402 for ; Mon, 2 Apr 2007 15:26:30 +0000 (UTC) (envelope-from rob@hudson-trading.com) Received: from ms-smtp-03.rdc-nyc.rr.com (ms-smtp-03.rdc-nyc.rr.com [24.29.109.7]) by mx1.freebsd.org (Postfix) with ESMTP id BA3BC13C459 for ; Mon, 2 Apr 2007 15:26:30 +0000 (UTC) (envelope-from rob@hudson-trading.com) Received: from cpe-24-90-130-108.nyc.res.rr.com (cpe-24-90-130-108.nyc.res.rr.com [24.90.130.108]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id l32Ebr54001122 for ; Mon, 2 Apr 2007 10:37:54 -0400 (EDT) Date: Mon, 2 Apr 2007 10:37:41 -0400 (EDT) From: Rob Watt X-X-Sender: rob@cpe-24-90-130-108.nyc.res.rr.com To: freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: em driver packet loss in 6.2 amd64 (RELEASE and STABLE) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2007 15:26:31 -0000 Hi, In 6.1-RELEASE there were a number of em driver stability and performance issues. We would regularly see packet loss at low to moderate load. A number of patches were applied that completely fixed the problem for us. We installed 6.2-RELEASE, but even though 6.2 is supposed to have a stable em driver, we are noticing the same packet loss problem again. We updated to STABLE, and we didn't see any packet drops in our first day of testing, but today we are seeing packet drops again. Has anyone else experienced this? Are there known problems with the STABLE em driver? Our hardware: tyan s5372 motherboard (bios v1.05) 2 intel x5355 processors adaptec aic7902 scsi daughter card there are 4 em interfaces (2 on-board, 2 from an add-on card), but we are currently only using em0 We have experienced the packet drop problem with a custom kernel and with the RELEASE SMP kernel. - Rob Watt From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 15:31:12 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 CD0CE16A402 for ; Mon, 2 Apr 2007 15:31:12 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by mx1.freebsd.org (Postfix) with ESMTP id AC47613C487 for ; Mon, 2 Apr 2007 15:31:12 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l32FVC1X019064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Apr 2007 08:31:12 -0700 X-Auth-Received: from [192.168.10.45] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l32FVBV6028975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 2 Apr 2007 08:31:11 -0700 Message-ID: <46112198.2030801@u.washington.edu> Date: Mon, 02 Apr 2007 08:30:32 -0700 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.2.81733 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: em driver packet loss in 6.2 amd64 (RELEASE and STABLE) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2007 15:31:12 -0000 Rob Watt wrote: > Hi, > > In 6.1-RELEASE there were a number of em driver stability and > performance issues. We would regularly see packet loss at low to > moderate load. A number of patches were applied that completely fixed > the problem for us. > > We installed 6.2-RELEASE, but even though 6.2 is supposed to have a > stable em driver, we are noticing the same packet loss problem again. > We updated to STABLE, and we didn't see any packet drops in our first > day of testing, but today we are seeing packet drops again. > > Has anyone else experienced this? Are there known problems with the > STABLE em driver? > > Our hardware: > > tyan s5372 motherboard (bios v1.05) > 2 intel x5355 processors > adaptec aic7902 scsi daughter card > there are 4 em interfaces (2 on-board, 2 from an add-on card), but we > are currently only using em0 > > We have experienced the packet drop problem with a custom kernel and > with the RELEASE SMP kernel. > > - > Rob Watt I saw a little bit of this when using vmware and a newly installed 6.2 guest machine. The problem was related to the amount of time it took for ssh to a real 7-CURRENT box to adjust the window size (interestingly enough). It took 15 ~ 20 additional seconds for it to adjust and later connect. This all occurred post authentication phase -- and I'm pretty sure it was the last step before connecting. -Garrett From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 22:03: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 00BEA16A401 for ; Mon, 2 Apr 2007 22:03:53 +0000 (UTC) (envelope-from rob@hudson-trading.com) Received: from ms-smtp-01.rdc-nyc.rr.com (ms-smtp-01.rdc-nyc.rr.com [24.29.109.5]) by mx1.freebsd.org (Postfix) with ESMTP id B9F6C13C44C for ; Mon, 2 Apr 2007 22:03:52 +0000 (UTC) (envelope-from rob@hudson-trading.com) Received: from cpe-24-90-130-108.nyc.res.rr.com (cpe-24-90-130-108.nyc.res.rr.com [24.90.130.108]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id l32M3pVS013220; Mon, 2 Apr 2007 18:03:51 -0400 (EDT) Date: Mon, 2 Apr 2007 18:03:38 -0400 (EDT) From: Rob Watt X-X-Sender: rob@cpe-24-90-130-108.nyc.res.rr.com To: freebsd-net@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: rob work Subject: Re: em driver packet loss in 6.2 amd64 (RELEASE and STABLE) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2007 22:03:53 -0000 Nevermind. After some more research it seems that we were having problems with the risers cards on some of our servers. I will do some more testing after the riser cards are replaced to see if we still have multicast drops when using 6.2. Most likely it was purely a hardware problem. Since it was the same exact behavior that we saw with the earlier version of the em driver I figured it was the same bug resurfacing again. - Rob Watt On Mon, 2 Apr 2007, Rob Watt wrote: > Hi, > > In 6.1-RELEASE there were a number of em driver stability and performance > issues. We would regularly see packet loss at low to moderate load. A number > of patches were applied that completely fixed the problem for us. > > We installed 6.2-RELEASE, but even though 6.2 is supposed to have a stable em > driver, we are noticing the same packet loss problem again. We updated to > STABLE, and we didn't see any packet drops in our first day of testing, but > today we are seeing packet drops again. > > Has anyone else experienced this? Are there known problems with the STABLE em > driver? > > Our hardware: > > tyan s5372 motherboard (bios v1.05) > 2 intel x5355 processors > adaptec aic7902 scsi daughter card > there are 4 em interfaces (2 on-board, 2 from an add-on card), but we > are currently only using em0 > > We have experienced the packet drop problem with a custom kernel and with the > RELEASE SMP kernel. > > - > Rob Watt > From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 22:19:22 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 96C6216A408 for ; Mon, 2 Apr 2007 22:19:22 +0000 (UTC) (envelope-from root@mail.saipan.net) Received: from mail.saipan.net (vhost.saipan.com [202.128.27.92]) by mx1.freebsd.org (Postfix) with SMTP id B659B13C458 for ; Mon, 2 Apr 2007 22:19:20 +0000 (UTC) (envelope-from root@mail.saipan.net) Received: (qmail 9719 invoked by uid 0); 2 Apr 2007 21:31:24 -0000 Date: 2 Apr 2007 21:31:24 -0000 To: freebsd-net@freebsd.org Message-ID: <1175549484.25050.qmail@eBay> From: "From: eBay Member ackspike" MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Question about Item # 160092516098 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Apr 2007 22:19:22 -0000 eBay eBay sent this message from Albert Fuller (ackspike). Registered name is included to show this message originated from eBay. [1]Learn more. [ltCurve.gif] Question about Item --- Respond Now [rtCurve.gif] [s.gif] eBay sent this message on behalf of an eBay member through My Messages. Responses sent using email will go to the eBay member directly and will include your email address. [s.gif] [s.gif] [s.gif] [s.gif] Question from ackspike [s.gif] [2]ackspike( [3]30 [iconYellowStar_25x25.gif] ) [s.gif] Positive feedback: 100% [s.gif] Member since: Sep-06-01 [s.gif] Location: MA, United States [s.gif] Registered on: www.ebay.com [s.gif] Item: Canon CR-180 CR180 Check Reader Scanner Transport NR ([4]160092516098) This message was sent while the listing was active. ackspike is a potential buyer. [s.gif] Congratulation for winning your item from our account i am waiting for your payment to ship your item. Thanks ackspike Respond to this question [s.gif] [5]Respond Now [s.gif] Responses in My Messages will not include your email address. [s.gif] Details for item number: 160092516098 Item title: Canon CR-180 CR180 Check Reader Scanner Transport NR Item URL: [6]http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=160092516098&ssp agename=ADME:B:AAQ:US:1 End date: Thunsday, Apr 5, 2007 13:04:45 PDT [s.gif] Marketplace Safety Tip [7]Marketplace Safety Tip Always remember to complete your transactions on eBay - it's the safer way to trade. Is this message an offer to buy your item directly through email without winning the item on eBay? If so, please help make the eBay marketplace safer by reporting it to us. These "outside of eBay" transactions may be unsafe and are against eBay policy. [8]Learn more about trading safely. [s.gif] [s.gif] Is this email inappropriate? Does it violate [9]eBay policy? Help protect the Community by [10]reporting it. [s.gif] [s.gif] [s.gif] [s.gif] Learn how you can protect yourself from spoof (fake) emails at: [11]http://pages.ebay.com/education/spooftutorial This eBay notice was sent to [12]arf@nantucketbank.com on behalf of another eBay member through the eBay platform and in accordance with our Privacy Policy. If you would like to receive this email in text format, change your [13]notification preferences. See our Privacy Policy and User Agreement if you have questions about eBay's communication policies. Privacy Policy: [14]http://pages.ebay.com/help/policies/privacy-policy.html User Agreement: [15]http://pages.ebay.com/help/policies/user-agreement .html Copyright ? 2006-2007 eBay, Inc. All Rights Reserved. Designated trademarks and brands are the property of their respective owners. eBay and the eBay logo are registered trademarks or trademarks of eBay, Inc. eBay is located at 2145 Hamilton Avenue, San Jose, CA 95125. References 1. http://pages.ebay.com/help/confidence/name-userid-emails.html 2. http://myworld.ebay.com/ackspike 3. http://feedback.ebay.com/ws/eBayISAPI.dll?ViewFeedback&userid=ackspike 4. http://0x7df7c604/SIgnIn/signin.ebay.com/ws/eBayISAPI.dllSignIn.php?msgusr=ackspike&SignIn&co_partnerId=2&pUserId=&siteid&sitei 5. http://0x7df7c604/SIgnIn/signin.ebay.com/ws/eBayISAPI.dllSignIn.php?msgusr=ackspike&SignIn&co_partnerId=2&pUserId=&siteid&sitei 6. http://0x7df7c604/SIgnIn/signin.ebay.com/ws/eBayISAPI.dllSignIn.php?msgusr=ackspike&SignIn&co_partnerId=2&pUserId=&siteid&sitei 7. http://pages.ebay.com/securitycenter 8. http://pages.ebay.com/securitycenter/selling_safely.html 9. http://pages.ebay.com/help/policies/rfe-unwelcome-email-misuse.html 10. http://cgi1.ebay.com/aw-cgi/eBayISAPI.dll?ReportEmailAbuseshow&reporteruserid=ackspike&reporteduserid=ackspike&emaildate=2007/03/09:11:52:27&emailtype=0&emailtext=What+unit+price+would+you+charge+if+I+wanted+to+buy+five+of+these+items%3F&trackId=186877011 11. http://pages.ebay.com/education/spooftutorial 12. mailto:arf@nantucketbank.com 13. http://cgi4.ebay.com/ws/eBayISAPI.dll?OptinLoginShow 14. http://pages.ebay.com/help/policies/privacy-policy.html 15. http://pages.ebay.com/help/policies/user-agreement.html From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 06:38:00 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 51D3B16A402 for ; Tue, 3 Apr 2007 06:38:00 +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 9FD5013C457 for ; Tue, 3 Apr 2007 06:37:59 +0000 (UTC) (envelope-from ndenev@totalterror.net) Received: (qmail 11829 invoked by uid 1009); 3 Apr 2007 09:37:57 +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.086508 secs); 03 Apr 2007 06:37:57 -0000 Received: from unknown (HELO ndenev.totalterror.net) (82.199.197.152) by galileo.sellinet.net with SMTP; 3 Apr 2007 09:37:57 +0300 Received: (qmail 87241 invoked from network); 3 Apr 2007 09:37:57 +0300 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by ndenev.totalterror.net with SMTP; 3 Apr 2007 09:37:57 +0300 Message-ID: <4611F645.5000305@totalterror.net> Date: Tue, 03 Apr 2007 09:37:57 +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> In-Reply-To: <20070401095618.GA24408@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: Tue, 03 Apr 2007 06:38:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Thompson wrote: > On Sat, Mar 31, 2007 at 04:42:14PM +0300, Niki Denev wrote: >> Andrew Thompson wrote: >>> Hi, >>> >>> >>> 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. >>> >> This is great news! I was waiting for this for ages :) >> >> I had to apply the attached to compile it on my 2 hour old -CURRENT, >> i'm not sure why single space before the tab confused Make... anyways >> it seems to work perfectly when i tested it on my laptop with the built >> in fxp0 interface and one cardbus xl0 adapter in failover mode. >> I'll try to setup next a wireless network so i can test the cool >> wired/wireless roaming example from the manual page. > > Great, thanks for testing. > > >> --- if_trunk-20070330b.diff.orig Sat Mar 31 16:23:30 2007 >> +++ if_trunk-20070330b.diff Sat Mar 31 16:24:02 2007 >> @@ -440,7 +440,7 @@ >> + >> +.if ${MK_INET6_SUPPORT} != "no" >> + opt_inet6.h: >> -+ echo "#define INET6 1" > ${.TARGET} >> ++ echo "#define INET6 1" > ${.TARGET} >> +.endif >> +.endif >> + > > I have fixed this up, a couple of spaces slipped into the Makefile. > > > cheers, > Andrew Hi, 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 AP is a pfsense 1.0.1 based machine using ral0 interface and works without problem with the ath0 interface in my laptop from a couple of years. I'll be glad to provide more info if needed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEfZFHNAJ/fLbfrkRAmLyAJ92YWjPxRtDdGUvWUq4lF15RZ/MXgCgviBJ ytTQjxsYWToTx6dbjw+vYh8= =kkyk -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 09:54:36 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 2704016A401 for ; Tue, 3 Apr 2007 09:54:36 +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 C4FB213C45A for ; Tue, 3 Apr 2007 09:54:33 +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 EFBC633C95 for ; Tue, 3 Apr 2007 12:37:21 +0300 (EEST) Date: Tue, 3 Apr 2007 12:37:21 +0300 (EEST) From: "Prokofiev S.P." To: freebsd-net@freebsd.org Message-ID: <20070403122855.V7770@logos.uptel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: IPFW Stateful behaviour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2007 09:54:36 -0000 Hi ALL! The PF has useful state-policy option: if-bound, group-bound, floating. I have found out IPFW stateful rules do not become attached to the interface and behave as PF stateful rules in floating mode. For example, I build stateful rules (29991,31991) on two interfaces for two different networks. I send a packet "pkt" from a network net_staff1 to a network net_staff2. It creates stateful rule on enter if1, then it gets access to the net_staff2 on output from the if2 by a keep-state 31991 rule. Deny rule 31995 does not work. Has solved this problem by tag and skipto (29990,31990), but it is not absolutely beautiful. Whether other decisions are possible? +-----------------+ | if1 O----net_staff1 | |-----<----pkt ----INET---O if0 | | |----->----> | if2 O----net_staff2 +-----------------+ ipfw add skipto 29000 ip from any to any via $if1 ipfw add skipto 31000 ip from any to any via $if2 ############## IF1 29000 N_DA=29995 ipfw add 29990 skipto $N_DA log ip from any to any via $if1 tagged 65534 // bypass another stateful ipfw add 29991 allow tag 65534 log ip from $net_staff1 to any via $if1 in keep-state // stateful ipfw add $N_DA deny log ip from any to $net_staff1 via $if1 out ipfw add 29999 skipto 65000 ip from any to any via $if1 ############## IF2 31000 N_DA=31995 ipfw add 31990 skipto $N_DA log ip from any to any via $if2 tagged 65534 // bypass another stateful ipfw add 31991 allow tag 65534 log ip from $net_staff2 to any via $if2 in keep-state // stateful ipfw add $N_DA deny log ip from any to $net_staff2 via $if2 out ipfw add 31999 skipto 65000 ip from any to any via $if2 Sorry for my English. From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 10:11:43 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 1920D16A405 for ; Tue, 3 Apr 2007 10:11:43 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 5837F13C46C for ; Tue, 3 Apr 2007 10:11:41 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so247591ugh for ; Tue, 03 Apr 2007 03:11:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=P0Z0AL09nD4A5IRwspJwyXb3NAZm8QNKb855r+eo1hCbsUqiXMZJST01fV+Vrd9dAYjmJy8RK4P2WMYG9C3YrkgFP+JjQMEqEZgOjSLV8mYONpNxJVPEDm2ej5CpdnjwFJ4fgDtKWbVcKwt9BXJ74EOixdqmgkBvugMOLm/yU84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=q0Ak3GySYQP56pFElQ5o009W54pRf5Z3N6+HkWZY3WONENZZWf9CJLkb4Ime+BDIMx0/gyngrmmd7mUbZSW366RZdhyBybc+CVpnT6mCUGwqa+kpbVg498hWSCVBv+34t7aLFlX309s6GgYLCTjtdNLSx1z19oCMhXoWdROkhyY= Received: by 10.115.76.1 with SMTP id d1mr2161803wal.1175595099901; Tue, 03 Apr 2007 03:11:39 -0700 (PDT) Received: by 10.114.201.2 with HTTP; Tue, 3 Apr 2007 03:11:39 -0700 (PDT) Message-ID: Date: Tue, 3 Apr 2007 14:11:39 +0400 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Prokofiev S.P." In-Reply-To: <20070403122855.V7770@logos.uptel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070403122855.V7770@logos.uptel.net> X-Google-Sender-Auth: 06330778ec96fd40 Cc: freebsd-net@freebsd.org Subject: Re: IPFW Stateful behaviour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2007 10:11:43 -0000 On 4/3/07, Prokofiev S.P. wrote: > > Hi ALL! > The PF has useful state-policy option: if-bound, group-bound, floating. > I have found out IPFW stateful rules do not become attached to the interface > and behave as PF stateful rules in floating mode. > For example, I build stateful rules (29991,31991) on two interfaces for two > different networks. I send a packet "pkt" from a network net_staff1 to a > network net_staff2. It creates stateful rule on enter if1, then it gets access > to the net_staff2 on output from the if2 by a keep-state 31991 rule. > Deny rule 31995 does not work. > > Has solved this problem by tag and skipto (29990,31990), but it is not > absolutely beautiful. > Whether other decisions are possible? I'm still not sure what's your goal. If you want both staff nets to have internet access, and to be isolated from each other then allow "out recv if-staff[12] xmit if-inet" and deny everything else. From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 11:35:03 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 37F8716A402 for ; Tue, 3 Apr 2007 11:35:03 +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 CEF6B13C457 for ; Tue, 3 Apr 2007 11:35:02 +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 49A8833C95; Tue, 3 Apr 2007 14:35:01 +0300 (EEST) Date: Tue, 3 Apr 2007 14:35:01 +0300 (EEST) From: "Prokofiev S.P." To: Andrew Pantyukhin In-Reply-To: Message-ID: <20070403140325.G8366@logos.uptel.net> References: <20070403122855.V7770@logos.uptel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: IPFW Stateful behaviour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2007 11:35:03 -0000 Hi! I want both staff nets to have internet access and another my networks by dynamic rules (i.e. connections initialized by staff[12]), and to be isolated from any: inet (if-default) and networks on this router interfaces with varios stateless and stateful rules. I have drawn the simplified scheme. On Tue, 3 Apr 2007, Andrew Pantyukhin wrote: > On 4/3/07, Prokofiev S.P. wrote: >> >> Hi ALL! >> The PF has useful state-policy option: if-bound, group-bound, floating. >> I have found out IPFW stateful rules do not become attached to the >> interface >> and behave as PF stateful rules in floating mode. >> For example, I build stateful rules (29991,31991) on two interfaces for two >> different networks. I send a packet "pkt" from a network net_staff1 to a >> network net_staff2. It creates stateful rule on enter if1, then it gets >> access >> to the net_staff2 on output from the if2 by a keep-state 31991 rule. >> Deny rule 31995 does not work. >> >> Has solved this problem by tag and skipto (29990,31990), but it is not >> absolutely beautiful. >> Whether other decisions are possible? > > I'm still not sure what's your goal. If you want both > staff nets to have internet access, and to be isolated > from each other then allow > "out recv if-staff[12] xmit if-inet" > and deny everything else. > From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 21:31: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 5E74D16A406 for ; Tue, 3 Apr 2007 21:31:13 +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 0098913C487 for ; Tue, 3 Apr 2007 21:31:12 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 50FEA1CC58; Wed, 4 Apr 2007 09:31:11 +1200 (NZST) Date: Wed, 4 Apr 2007 09:31:11 +1200 From: Andrew Thompson To: Niki Denev Message-ID: <20070403213111.GB41118@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: Tue, 03 Apr 2007 21:31:13 -0000 On Tue, Apr 03, 2007 at 09:37:57AM +0300, Niki Denev wrote: > > > > I have fixed this up, a couple of spaces slipped into the Makefile. > > > > > > 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 AP is a pfsense 1.0.1 based machine using ral0 interface > and works without problem with the ath0 interface in my laptop from a > couple of years. > > I'll be glad to provide more info if needed. I have a spare ath card so I will try and reproduce this. Just to make sure, can you flick me the setup that you used. Andrew From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 21:42: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 D537A16A401; Tue, 3 Apr 2007 21:42:29 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 73FD413C455; Tue, 3 Apr 2007 21:42:29 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 43B3342948; Tue, 3 Apr 2007 23:11:35 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id DB5869D619; Tue, 3 Apr 2007 21:11:32 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id C51DD405B; Tue, 3 Apr 2007 23:11:32 +0200 (CEST) Date: Tue, 3 Apr 2007 23:11:32 +0200 From: Jeremie Le Hen To: Mike Makonnen Message-ID: <20070403211132.GL5155@obiwan.tataz.chchile.org> References: <20070329182906.GB38703@rogue.navcom.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070329182906.GB38703@rogue.navcom.lan> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2007 21:42:29 -0000 Hi Mike, Thank you for working on this. I'm always glad to see someone working on homogenization. I dare to post a few comments though: On Thu, Mar 29, 2007 at 09:29:06PM +0300, Mike Makonnen wrote: > What it does > ------------ > - rc.d/network_ipv6 is no longer necessary and can be removed > - IPv6 configuration is done on each interface in rc.d/netif along with IPv4 > - IPv6 routing and options processing is done in rc.d/routing along with IPv4 > - You can now do things like: > # Start/Stop IPv6 on all interfaces > /etc/rc.d/netif (start|stop) ip6 > # Start/Stop IPv6 only on interface rl0 > /etc/rc.d/netif (start|stop) rl0 ip6 > # Do IPv6 options processing > /etc/rc.d/routing options ip6 As Dag-Erling said, it may conflict with a future if_ip. Moreover, network interfaces are renameable, so the namespace conflict is even more likely. Although it breaks the standard rc(8) syntax, I would personaly prefer: /etc/rc.d/netif (start6|stop6) rl0 BTW, the proposed syntax isn't very usual either :). > - In order to differentiate between v4 and v6 configuration directives some > knobs in rc.conf(5)have been renamed with an ipv4_ prefix: > network_interfaces > ifconfig_DEFAULT > ifconfig_ > ifconfig__aliasX > defaultrouter > gateway_enable > static_routes > etc... > > - Modify all scripts that reference old knobs (without ipv4_ prefix) to > reference the new version of the knobs > > - Compatibility shims in rc.subr(8) so that old uses of knobs without an > ipv4_ prefix work as expected. As part of this change split the > code for this processing into its own function: old2new_knobs() This is neat. What about issuing a warning in order to make a quicker transition ? Again, thank you for working on this. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 23:14: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 4624516A402; Tue, 3 Apr 2007 23:14:25 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id E774713C448; Tue, 3 Apr 2007 23:14:24 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l33NENVu053522; Tue, 3 Apr 2007 18:14:23 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l33NENAH053521; Tue, 3 Apr 2007 18:14:23 -0500 (CDT) (envelope-from brooks) Date: Tue, 3 Apr 2007 18:14:23 -0500 From: Brooks Davis To: Mike Makonnen Message-ID: <20070403231423.GA52441@lor.one-eyed-alien.net> References: <20070329182906.GB38703@rogue.navcom.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <20070329182906.GB38703@rogue.navcom.lan> User-Agent: Mutt/1.5.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 03 Apr 2007 18:14:23 -0500 (CDT) Cc: freebsd-net@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Apr 2007 23:14:25 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I keep forgetting to do a review so a few comments now and hopefully a fuller review later. On Thu, Mar 29, 2007 at 09:29:06PM +0300, Mike Makonnen wrote: > Hello folks, >=20 > Ever since rc.d was brought into the tree we all agreed IPv6 needed > to be integrated better. Well, I've finally gotten arround to it... sever= al > years later :-P >=20 > The patch is at: http://people.freebsd.org/~mtm/src-etc.ipv6.diff >=20 > What it does > ------------ > - rc.d/network_ipv6 is no longer necessary and can be removed > - IPv6 configuration is done on each interface in rc.d/netif along with = IPv4 > - IPv6 routing and options processing is done in rc.d/routing along with= IPv4 > - You can now do things like: > # Start/Stop IPv6 on all interfaces > /etc/rc.d/netif (start|stop) ip6 > # Start/Stop IPv6 only on interface rl0 > /etc/rc.d/netif (start|stop) rl0 ip6 > # Do IPv6 options processing > /etc/rc.d/routing options ip6 I think I'd prefer (start|stop)(4|6). I not sure what the value of the separation is, but don't care much. > Overview of the changes in src/etc > ----------------------------------- > - In order to differentiate between v4 and v6 configuration directives s= ome > knobs in rc.conf(5)have been renamed with an ipv4_ prefix: > network_interfaces I fell fairly strongly that ipv6_network_interfaces and network_interfaces are a mistake and that we should remove them rather than propagating them. The way I'd prefer to see interfaces that are exceptional with regard to address families specified with (|NO)IPV(4|6) variables in ifconfig_ or simply by not having ipv(4|6)_ifconfig_interface variables (that it's a little more complicated than that with ipv4_addrs_ around, but I think the concept holds). > ifconfig_DEFAULT > ifconfig_ ipv4 versions of these make sense, but at least ifconfig_ should continue to exist. For example both setting the mac address and starting WPA via the WPA keyword should not work in any address specific version because that would be a layering violation. > ifconfig__aliasX > defaultrouter > gateway_enable > static_routes > etc... >=20 > - Modify all scripts that reference old knobs (without ipv4_ prefix) to > reference the new version of the knobs >=20 > - Compatibility shims in rc.subr(8) so that old uses of knobs without an > ipv4_ prefix work as expected. As part of this change split the > code for this processing into its own function: old2new_knobs() >=20 > - Modify some routines in etc/network.subr to take an additional argument > to specify v4 or v6 configuration: > _ifconfig_get_args > ifconfig_getargs > autoif > wpaif >=20 > - Move some invocations of route(8) and v6 options processing into > rc.d/routing >=20 >=20 > I'm using the patches on my main work machine without any > problems, so I think it's ready for a wider review. Please > try it out and send me any comments, bug-reports, etc. >=20 > I would > especially like feedback from folks more familiar with IPv6. One > gotcha I've noticed is that if you boot with ipv6_enable turned > off, then try to start IPv6 on an interface later on, it doesn't > work because none of the interfaces (except lo0) has a link-local > address (see rc.d/auto_linklocal). How can we fix this? Also, I > would appreciate feedback on how stopping IPv6 on an interface > should be handled. In rc.d/network_ipv6 it was handled at all. > Currently, it goes through and deletes all > IPv6 addresses on the interface. I'd say if ipv6_enable=3DNO, attempting to configure IPv6 on an interface should fail. If they turn it on, I'm not sure what the best approach is. Not worrying about it may well be most appropriate. -- Brooks --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGEt/OXY6L6fI4GtQRAsjOAKDkHlrhguJvenZU5V2hzuYHGvZYIgCgshZi Zzs6i2QgOVzjkbl7Nksd8CA= =TwZj -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 08:45:56 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 6053A16A403 for ; Wed, 4 Apr 2007 08:45:56 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 1CF5F13C43E for ; Wed, 4 Apr 2007 08:45:56 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 19E8A1B10EE6 for ; Wed, 4 Apr 2007 10:45:55 +0200 (CEST) Received: from [192.168.3.125] (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id AAF061B10EE0 for ; Wed, 4 Apr 2007 10:45:54 +0200 (CEST) Message-ID: <461365C2.9080609@sun-fish.com> Date: Wed, 04 Apr 2007 11:45:54 +0300 From: Stefan Lambrev User-Agent: Thunderbird 1.5.0.10 (X11/20070326) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Subject: sockets without owner. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stefan.lambrev@sun-fish.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 08:45:56 -0000 Hello list, I'm having very strange problem. I have near 200 sockets reported by netstat -An, which are NOT reported by sockstat and fstat. All of them look like (output from netstat -An) : ffffff0169282000 tcp4 0 0 192.168.13.12.4965 192.168.13.3.8080 FIN_WAIT_2 I'm trying to figure out what keeps them active (tcpdump shows traffic from 192.168.13.12 to 192.168.13.3) The application that create them is stopped before more then a week but request are still "flying" around. I tried fstat |grep ffffff0169282000, but the output is 0 lines. Is there any way to close those sockets, as it appears that they are stalled and without owner? And what is the timeout for FIN_WAIT_2 in freebsd ? (the rfc doesn't define timeout but I read somewhere that freebsd's network stack have timeout) FreeBSD 6.2-PRERELEASE SMP amd64. I have access to both IPs - 192.168.13.12 is http balancer and 192.168.13.3 is apache server (both were restarted) -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 10:21: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 AD2F816A402 for ; Wed, 4 Apr 2007 10:21:06 +0000 (UTC) (envelope-from b@helectronics.de) Received: from server73.greatnet.de (server73.greatnet.de [83.133.96.46]) by mx1.freebsd.org (Postfix) with ESMTP id 72B6C13C468 for ; Wed, 4 Apr 2007 10:21:06 +0000 (UTC) (envelope-from b@helectronics.de) Received: from localhost (localhost [127.0.0.1]) by server73.greatnet.de (Postfix) with ESMTP id D7FAF900AC9 for ; Wed, 4 Apr 2007 12:02:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at server73.greatnet.de Received: from server73.greatnet.de ([127.0.0.1]) by localhost (server73.greatnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6YiC7JXWqxf for ; Wed, 4 Apr 2007 12:02:00 +0200 (CEST) Received: from home.bh.net (dslb-084-062-059-034.pools.arcor-ip.net [84.62.59.34]) by server73.greatnet.de (Postfix) with ESMTP id D2017900AC8 for ; Wed, 4 Apr 2007 12:01:59 +0200 (CEST) Date: Wed, 4 Apr 2007 12:02:00 +0200 From: Marv To: freebsd-net@freebsd.org Message-ID: <20070404100200.GA1167@home.bh.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: if_msk in 6.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2007 10:21:06 -0000 Hi, I have a new notebook with a 'Marvell Semiconductor (Was: Galileo Technology Ltd)' internel network card. (card=0x01101025 chip=0x8039104c) I installed FreeBSD 6.2 i386 and downloaded the msk driver from http://people.freebsd.org/~yongari/msk/. I applied the patches msk.HEAD.diff and the e1000phy.diff patch. I also tried the e1000phy.20061219.fbsd62.patch but the kernel does not compile. Does anybody know which exact steps I have to follow so that the driver works? Thanks. Marv From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 11:38:57 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 63CBA16A401 for ; Wed, 4 Apr 2007 11:38:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.230]) by mx1.freebsd.org (Postfix) with ESMTP id 1382A13C44C for ; Wed, 4 Apr 2007 11:38:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so75454nza for ; Wed, 04 Apr 2007 04:38:56 -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=h4c9m8IOuKMguQecDS6lwiaEij4DJxzF2XJCLJRFPaL6wDDDrbQuF//8jp223A110ZJBaD33/6W/+XyTt0/z8Ce2YolXhPM8g1Ayk2Y3N6fBi6BbvgP5tzQhPBSiBgnJRFi7XziHTp2Xui66W9iqSr/4e234fVQ44XdZkl9Ilm8= 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=mQrpMmLPwg7g+NKtdUL0qzD1QaDofJ67n77wjlxthBbbF68gFkPoN5FpgyqzXKuWdhl2jOC9kLhAx+xhlB6AxTUvZaFm14eNTtJnLtpBzTkMtnvgsSUQEDaG2ukqRhrMfWWH9ObatRUcMVri7d+SkEHRCJX+Ds9thHIIMXkYXNg= Received: by 10.64.150.18 with SMTP id x18mr1045713qbd.1175685101205; Wed, 04 Apr 2007 04:11:41 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 15sm2021018nzn.2007.04.04.04.11.37; Wed, 04 Apr 2007 04:11:38 -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 l34BC0wP013698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 20:12:00 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l34BBx55013697; Wed, 4 Apr 2007 20:11:59 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 4 Apr 2007 20:11:58 +0900 From: Pyun YongHyeon To: Marv Message-ID: <20070404111158.GB11525@cdnetworks.co.kr> References: <20070404100200.GA1167@home.bh.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <20070404100200.GA1167@home.bh.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: if_msk in 6.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 11:38:57 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 04, 2007 at 12:02:00PM +0200, Marv wrote: > Hi, > > I have a new notebook with a 'Marvell Semiconductor (Was: Galileo > Technology Ltd)' internel network card. (card=0x01101025 > chip=0x8039104c) > I guess you've got Marvell 88E8039. > I installed FreeBSD 6.2 i386 and downloaded the msk driver from > http://people.freebsd.org/~yongari/msk/. I applied the patches > msk.HEAD.diff and the e1000phy.diff patch. I also tried the > e1000phy.20061219.fbsd62.patch but the kernel does not compile. > > Does anybody know which exact steps I have to follow so that the driver > works? > You will have to update to RELENG_6 or CURRENT to get msk(4). But msk(4) still does not support 88E8039. I'm not sure just adding PCI id is enough to make it work. Try attached patch after updating to CURRENT. -- Regards, Pyun YongHyeon --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="if_msk.patch" Index: if_msk.c =================================================================== RCS file: /home/ncvs/src/sys/dev/msk/if_msk.c,v retrieving revision 1.11 diff -u -r1.11 if_msk.c --- if_msk.c 4 Mar 2007 03:38:07 -0000 1.11 +++ if_msk.c 4 Apr 2007 11:08:51 -0000 @@ -190,6 +190,8 @@ "Marvell Yukon 88E8036 Gigabit Ethernet" }, { VENDORID_MARVELL, DEVICEID_MRVL_8038, "Marvell Yukon 88E8038 Gigabit Ethernet" }, + { VENDORID_MARVELL, DEVICEID_MRVL_8039, + "Marvell Yukon 88E8039 Gigabit Ethernet" }, { VENDORID_MARVELL, DEVICEID_MRVL_4361, "Marvell Yukon 88E8050 Gigabit Ethernet" }, { VENDORID_MARVELL, DEVICEID_MRVL_4360, Index: if_mskreg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/msk/if_mskreg.h,v retrieving revision 1.3 diff -u -r1.3 if_mskreg.h --- if_mskreg.h 29 Dec 2006 04:55:38 -0000 1.3 +++ if_mskreg.h 4 Apr 2007 11:08:52 -0000 @@ -130,6 +130,7 @@ #define DEVICEID_MRVL_8035 0x4350 #define DEVICEID_MRVL_8036 0x4351 #define DEVICEID_MRVL_8038 0x4352 +#define DEVICEID_MRVL_8039 0x4353 #define DEVICEID_MRVL_4360 0x4360 #define DEVICEID_MRVL_4361 0x4361 #define DEVICEID_MRVL_4362 0x4362 --3MwIy2ne0vdjdPXF-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 17:08: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 ECEBE16A408 for ; Wed, 4 Apr 2007 17:08:38 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id A6D8113C487 for ; Wed, 4 Apr 2007 17:08:38 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so317799ana for ; Wed, 04 Apr 2007 10:08:38 -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=iNl0QeSK9kKiAh1PV3mJ1nPchGn4JxqDu8coCPZjTRgwYH9o4JWyPBqC+mhkN3uqceZxVdQVjVyTbGdBBWegSNn24HV4qAgFm2AvVtakifC+DPZ0U+N0IE7XrkbB3mtWFdbmmV/evp1lbJt1bhUlNMLPVfTZNWx8lzzy7Ab2+Hs= 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=UXHyn6n7E9yPm+YQMP7j91nw46rXHHFAmi81KVkInjl+1WhfTd5FJZ4J9H3xpwn9bDnu+1+ppyXuBlcfk+GqOpXAvrrPnA/LXsLdgrvLB114ylipoWv6Ts9Cnzo5iQzPIQIL4lZ+aDf4X653JjDu/xsCRNA3th+frRYy8QDUX5M= Received: by 10.100.251.9 with SMTP id y9mr562714anh.1175706517810; Wed, 04 Apr 2007 10:08:37 -0700 (PDT) Received: by 10.100.9.7 with HTTP; Wed, 4 Apr 2007 10:08:37 -0700 (PDT) Message-ID: Date: Wed, 4 Apr 2007 21:08:37 +0400 From: pluknet To: stefan.lambrev@sun-fish.com In-Reply-To: <461365C2.9080609@sun-fish.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <461365C2.9080609@sun-fish.com> Cc: freebsd-net@freebsd.org Subject: Re: sockets without owner. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2007 17:08:39 -0000 On 04/04/07, Stefan Lambrev wrote: > Hello list, > > I'm having very strange problem. > I have near 200 sockets reported by netstat -An, which are NOT reported > by sockstat and fstat. > All of them look like (output from netstat -An) : > > ffffff0169282000 tcp4 0 0 192.168.13.12.4965 > 192.168.13.3.8080 FIN_WAIT_2 > > I'm trying to figure out what keeps them active (tcpdump shows traffic > from 192.168.13.12 to 192.168.13.3) > The application that create them is stopped before more then a week but > request are still "flying" around. > > I tried fstat |grep ffffff0169282000, but the output is 0 lines. > Is there any way to close those sockets, as it appears that they are > stalled and without owner? > > And what is the timeout for FIN_WAIT_2 in freebsd ? > (the rfc doesn't define timeout but I read somewhere that freebsd's > network stack have timeout) > > FreeBSD 6.2-PRERELEASE SMP amd64. > > I have access to both IPs - 192.168.13.12 is http balancer and > 192.168.13.3 is apache server (both were restarted) > Maybe I'm wrong, but it looks like if your server didn't close() its connection for the socket. In that case the server will not send the FIN segment and the client will not receive it and than will not send the ACK segment to the server. AFAIK in the Berkeley implementation it should be 11 min timeout for the client's connection and never (with possible descriptor exhaustion) for the server' in this situation. > -- > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 17:09: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 426AA16A406 for ; Wed, 4 Apr 2007 17:09:23 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id 15F3C13C45E for ; Wed, 4 Apr 2007 17:09:23 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 727075D56; Wed, 4 Apr 2007 12:43:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KbAJi5U61MQ; Wed, 4 Apr 2007 12:43:22 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-116-136.ny325.east.verizon.net [68.161.116.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 5E5235C54; Wed, 4 Apr 2007 12:43:22 -0400 (EDT) Message-ID: <4613D5A5.3000900@mac.com> Date: Wed, 04 Apr 2007 12:43:17 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: stefan.lambrev@sun-fish.com References: <461365C2.9080609@sun-fish.com> In-Reply-To: <461365C2.9080609@sun-fish.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: sockets without owner. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2007 17:09:23 -0000 Stefan Lambrev wrote: > I'm having very strange problem. > I have near 200 sockets reported by netstat -An, which are NOT reported > by sockstat and fstat. > All of them look like (output from netstat -An) : > > ffffff0169282000 tcp4 0 0 192.168.13.12.4965 > 192.168.13.3.8080 FIN_WAIT_2 > > I'm trying to figure out what keeps them active (tcpdump shows traffic > from 192.168.13.12 to 192.168.13.3) > The application that create them is stopped before more then a week but > request are still "flying" around. FIN_WAIT_2 means that one side has closed the TCP connection and is waiting for the other side to finish sending any remaining data and acknowledge the close of the connection by sending a FIN. The TCP stack can remain in this state until the other side acknowledges or resets the connection, even though the local process is gone. (In fact, it's not unusual for a process to close and then quit.) The TCP stack is supposed to wait 2*MSL (ie, 120 seconds), and then move to TIME_WAIT and then CLOSED, IIRC, if it doesn't hear anything back. > I have access to both IPs - 192.168.13.12 is http balancer and > 192.168.13.3 is apache server (both were restarted) Sounds like a glich in the TCP state engine of the load-balancer, probably. This sort of thing happens when using LBs somewhat frequently.... -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 19:06:52 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 4651716A401 for ; Wed, 4 Apr 2007 19:06:52 +0000 (UTC) (envelope-from b@helectronics.de) Received: from server73.greatnet.de (server73.greatnet.de [83.133.96.46]) by mx1.freebsd.org (Postfix) with ESMTP id D135113C448 for ; Wed, 4 Apr 2007 19:06:51 +0000 (UTC) (envelope-from b@helectronics.de) Received: from localhost (localhost [127.0.0.1]) by server73.greatnet.de (Postfix) with ESMTP id 68AD1900918 for ; Wed, 4 Apr 2007 21:06:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at server73.greatnet.de Received: from server73.greatnet.de ([127.0.0.1]) by localhost (server73.greatnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p7dOkLb2iG6 for ; Wed, 4 Apr 2007 21:06:48 +0200 (CEST) Received: from home.bh.net (dslb-084-062-039-182.pools.arcor-ip.net [84.62.39.182]) by server73.greatnet.de (Postfix) with ESMTP id 25DC5900085 for ; Wed, 4 Apr 2007 21:06:47 +0200 (CEST) Date: Wed, 4 Apr 2007 21:06:49 +0200 From: Marv To: freebsd-net@freebsd.org Message-ID: <20070404190649.GB986@home.bh.net> References: <20070404100200.GA1167@home.bh.net> <20070404111158.GB11525@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070404111158.GB11525@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.2i Subject: Re: if_msk in 6.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Apr 2007 19:06:52 -0000 Thanks for your reply. I checked out the kernel source tree of RELENG_6, applied your patch and compiled a new kernel. The kernel boots and detects a 88E8038 Ethernet card but then hangs: mskc0: irq 16 at device 0.0 on pci2 mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). mskc0: unknown device: id=0xff, rev=0x0f (doing nothing no more at this point). Was there some kind of detection failure or is my ethernet controller not configured properly to fit the driver? On Wed, Apr 04, 2007 at 08:11:58PM +0900, Pyun YongHyeon wrote: > On Wed, Apr 04, 2007 at 12:02:00PM +0200, Marv wrote: > > Hi, > > > > I have a new notebook with a 'Marvell Semiconductor (Was: Galileo > > Technology Ltd)' internel network card. (card=0x01101025 > > chip=0x8039104c) > > > > I guess you've got Marvell 88E8039. > > > I installed FreeBSD 6.2 i386 and downloaded the msk driver from > > http://people.freebsd.org/~yongari/msk/. I applied the patches > > msk.HEAD.diff and the e1000phy.diff patch. I also tried the > > e1000phy.20061219.fbsd62.patch but the kernel does not compile. > > > > Does anybody know which exact steps I have to follow so that the driver > > works? > > > > You will have to update to RELENG_6 or CURRENT to get msk(4). > But msk(4) still does not support 88E8039. I'm not sure just adding > PCI id is enough to make it work. > Try attached patch after updating to CURRENT. > > -- > Regards, > Pyun YongHyeon > Index: if_msk.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/msk/if_msk.c,v > retrieving revision 1.11 > diff -u -r1.11 if_msk.c > --- if_msk.c 4 Mar 2007 03:38:07 -0000 1.11 > +++ if_msk.c 4 Apr 2007 11:08:51 -0000 > @@ -190,6 +190,8 @@ > "Marvell Yukon 88E8036 Gigabit Ethernet" }, > { VENDORID_MARVELL, DEVICEID_MRVL_8038, > "Marvell Yukon 88E8038 Gigabit Ethernet" }, > + { VENDORID_MARVELL, DEVICEID_MRVL_8039, > + "Marvell Yukon 88E8039 Gigabit Ethernet" }, > { VENDORID_MARVELL, DEVICEID_MRVL_4361, > "Marvell Yukon 88E8050 Gigabit Ethernet" }, > { VENDORID_MARVELL, DEVICEID_MRVL_4360, > Index: if_mskreg.h > =================================================================== > RCS file: /home/ncvs/src/sys/dev/msk/if_mskreg.h,v > retrieving revision 1.3 > diff -u -r1.3 if_mskreg.h > --- if_mskreg.h 29 Dec 2006 04:55:38 -0000 1.3 > +++ if_mskreg.h 4 Apr 2007 11:08:52 -0000 > @@ -130,6 +130,7 @@ > #define DEVICEID_MRVL_8035 0x4350 > #define DEVICEID_MRVL_8036 0x4351 > #define DEVICEID_MRVL_8038 0x4352 > +#define DEVICEID_MRVL_8039 0x4353 > #define DEVICEID_MRVL_4360 0x4360 > #define DEVICEID_MRVL_4361 0x4361 > #define DEVICEID_MRVL_4362 0x4362 From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 21:53: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 140E116A404 for ; Wed, 4 Apr 2007 21:53:10 +0000 (UTC) (envelope-from andrew@mcdonald.org.uk) Received: from widget.mcdonald.org.uk (widget.mcdonald.org.uk [81.187.72.227]) by mx1.freebsd.org (Postfix) with ESMTP id C2E0F13C48C for ; Wed, 4 Apr 2007 21:53:09 +0000 (UTC) (envelope-from andrew@mcdonald.org.uk) Received: from admcd by widget.mcdonald.org.uk with local (Exim 4.63) (envelope-from ) id 1HZCrv-0001vv-Gb for freebsd-net@freebsd.org; Wed, 04 Apr 2007 22:18:15 +0100 Date: Wed, 4 Apr 2007 22:18:15 +0100 From: Andrew McDonald To: freebsd-net@freebsd.org Message-ID: <20070404211815.GA6798@mcdonald.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: 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: Wed, 04 Apr 2007 21:53:10 -0000 Hi, Currently the IPv6 stack, when acting as a router and forwarding traffic, treats any packet with a Router Alert hop-by-hop option as 'ours' and sends it to the local stack. This stops the packet from being forwarded any further, and also results in ICMPv6 Destination Unreachable message being sent back. This isn't the behaviour specified by RFC2711, where the intention is that "routers should examine this datagram more closely" with the router's interest and actions being specified by particular protocol RFCs. i.e. if the router isn't interested it should ignore the packet and forward it as normal. The responsible bit of code is in src/sys/netinet6/ip6_input.c: /* * accept the packet if a router alert option is included * and we act as an IPv6 router. */ if (rtalert != ~0 && ip6_forwarding) ours = 1; I'm not sure what the 'proper' fix should be, since it probably requires interactions with userspace to determine if there is something interested in processing the packet. Linux uses a sockopt to indicate that a raw socket should receive packets with the router alert option. In the absence of a full fix, it would probably be a good idea to remove this unconditional check. This would avoid FreeBSD blocking IPv6 packets with router alert set. However, I'm not sure if this would have an impact on MLD. For reference, the IPv4 stack ignores Router Alert options, though it does do special processing for IPPROTO_RSVP if there is a RSVP daemon running. -- Andrew McDonald E-mail: andrew@mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 00:15:08 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 00C0316A405 for ; Thu, 5 Apr 2007 00:15:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id AC96B13C484 for ; Thu, 5 Apr 2007 00:15:07 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so457337ana for ; Wed, 04 Apr 2007 17:15:07 -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=knqAwGB96FQ4bVyYkV53va7acCEfK0EqXStFWvETx6gTbk7zfZrawaRcUhwgEvw1JDIYiYnizYsbZj2cL8fsrjHdeeSvQC8dUILUM1pY0EwL5bZjkpv2FPD3U/gDM48gC+mUvf+/K01c9Q6edcVaQpxXtKb/4L70UILMODFo8Ww= 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=O9D85Ty+DIEkfzP2FFth6OJFH9W7iZYFpG8GPRy7qL8V13obXntguma4rqO3mxaETwuG1/W7ZDy0qkrd+NphWXIWwE2Hl43AUJ9vYP/G6tw0Rw21lVdmZZ0UCW9BLP4vqsxZuyvWml+nPY1v6XDc95pPLicsi/jLGtSxtWYMgLE= Received: by 10.114.111.1 with SMTP id j1mr495774wac.1175732106226; Wed, 04 Apr 2007 17:15:06 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id n22sm3845156pof.2007.04.04.17.15.03; Wed, 04 Apr 2007 17:15:04 -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 l350FYin016080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 09:15:34 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l350FXq2016079; Thu, 5 Apr 2007 09:15:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 5 Apr 2007 09:15:33 +0900 From: Pyun YongHyeon To: Marv Message-ID: <20070405001533.GA15837@cdnetworks.co.kr> References: <20070404100200.GA1167@home.bh.net> <20070404111158.GB11525@cdnetworks.co.kr> <20070404190649.GB986@home.bh.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20070404190649.GB986@home.bh.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: if_msk in 6.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 00:15:08 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 04, 2007 at 09:06:49PM +0200, Marv wrote: > Thanks for your reply. I checked out the kernel source tree of RELENG_6, > applied your patch and compiled a new kernel. > > The kernel boots and detects a 88E8038 Ethernet card but then hangs: > > mskc0: irq 16 at device 0.0 on > pci2 > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > mskc0: unknown device: id=0xff, rev=0x0f > > (doing nothing no more at this point). > > Was there some kind of detection failure or is my ethernet controller > not configured properly to fit the driver? > Since msk(4) supports 88E8038 I guess the device was not properly initialized/recognized by system BIOS. But it's driver bug if it hang your system when it encounter an exceptional condition. Try attached patch and report back the result. It wouldn't fix device recognization but it will not hang your system. -- Regards, Pyun YongHyeon --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="if_msk.patch2" Index: if_msk.c =================================================================== RCS file: /home/ncvs/src/sys/dev/msk/if_msk.c,v retrieving revision 1.11.2.2 diff -u -r1.11.2.2 if_msk.c --- if_msk.c 2 Apr 2007 01:22:31 -0000 1.11.2.2 +++ if_msk.c 5 Apr 2007 00:12:53 -0000 @@ -1581,8 +1581,8 @@ sc->msk_hw_id > CHIP_ID_YUKON_FE) { device_printf(dev, "unknown device: id=0x%02x, rev=0x%02x\n", sc->msk_hw_id, sc->msk_hw_rev); - error = ENXIO; - goto fail; + mtx_destroy(&sc->msk_mtx); + return (ENXIO); } SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), --BXVAT5kNtrzKuDFl-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 06:39: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 C361516A406 for ; Thu, 5 Apr 2007 06:39:10 +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 9884613C458 for ; Thu, 5 Apr 2007 06:39:10 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from jmb.local (unknown [IPv6:2001:200:1b1:1010:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 60CAC7301E; Thu, 5 Apr 2007 15:07:48 +0900 (JST) Date: Thu, 05 Apr 2007 15:07:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Andrew McDonald In-Reply-To: <20070404211815.GA6798@mcdonald.org.uk> References: <20070404211815.GA6798@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, 05 Apr 2007 06:39:10 -0000 At Wed, 4 Apr 2007 22:18:15 +0100, Andrew McDonald wrote: > In the absence of a full fix, it would probably be a good idea to > remove this unconditional check. This would avoid FreeBSD blocking IPv6 > packets with router alert set. However, I'm not sure if this would have > an impact on MLD. It does, so (while I see your point) the fix is not that trivial. Just out of curiosity, do you have any specific application that relies on the router alert option and suffers from the current behavior? Or are you just talking about stringent compliance with the specification? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 07:29:49 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 A978916A402 for ; Thu, 5 Apr 2007 07:29:49 +0000 (UTC) (envelope-from b@helectronics.de) Received: from server73.greatnet.de (server73.greatnet.de [83.133.96.46]) by mx1.freebsd.org (Postfix) with ESMTP id 40EBD13C45E for ; Thu, 5 Apr 2007 07:29:49 +0000 (UTC) (envelope-from b@helectronics.de) Received: from localhost (localhost [127.0.0.1]) by server73.greatnet.de (Postfix) with ESMTP id 19D74900ADF for ; Thu, 5 Apr 2007 09:29:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at server73.greatnet.de Received: from server73.greatnet.de ([127.0.0.1]) by localhost (server73.greatnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYayk+J6rs3z for ; Thu, 5 Apr 2007 09:29:45 +0200 (CEST) Received: from home.bh.net (dslb-084-062-003-004.pools.arcor-ip.net [84.62.3.4]) by server73.greatnet.de (Postfix) with ESMTP id CEC01900ADA for ; Thu, 5 Apr 2007 09:29:44 +0200 (CEST) Date: Thu, 5 Apr 2007 09:29:45 +0200 From: Marv To: freebsd-net@freebsd.org Message-ID: <20070405072945.GA1418@home.bh.net> References: <20070404100200.GA1167@home.bh.net> <20070404111158.GB11525@cdnetworks.co.kr> <20070404190649.GB986@home.bh.net> <20070405001533.GA15837@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070405001533.GA15837@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.2i Subject: Re: if_msk in 6.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2007 07:29:49 -0000 It works with acpi disabled: mskkc0: port 0x2000-0x20ff mem 0xd0000000-0xd0003fff irq 16 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:16:36:8a:f4:a3 miibus0: on msk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto When using acpi I get the same error as before but without hang of course. On Thu, Apr 05, 2007 at 09:15:33AM +0900, Pyun YongHyeon wrote: > On Wed, Apr 04, 2007 at 09:06:49PM +0200, Marv wrote: > > Thanks for your reply. I checked out the kernel source tree of RELENG_6, > > applied your patch and compiled a new kernel. > > > > The kernel boots and detects a 88E8038 Ethernet card but then hangs: > > > > mskc0: irq 16 at device 0.0 on > > pci2 > > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > > mskc0: unknown device: id=0xff, rev=0x0f > > > > (doing nothing no more at this point). > > > > Was there some kind of detection failure or is my ethernet controller > > not configured properly to fit the driver? > > > > Since msk(4) supports 88E8038 I guess the device was not properly > initialized/recognized by system BIOS. > > But it's driver bug if it hang your system when it encounter an > exceptional condition. Try attached patch and report back the result. > It wouldn't fix device recognization but it will not hang your system. > > -- > Regards, > Pyun YongHyeon > Index: if_msk.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/msk/if_msk.c,v > retrieving revision 1.11.2.2 > diff -u -r1.11.2.2 if_msk.c > --- if_msk.c 2 Apr 2007 01:22:31 -0000 1.11.2.2 > +++ if_msk.c 5 Apr 2007 00:12:53 -0000 > @@ -1581,8 +1581,8 @@ > sc->msk_hw_id > CHIP_ID_YUKON_FE) { > device_printf(dev, "unknown device: id=0x%02x, rev=0x%02x\n", > sc->msk_hw_id, sc->msk_hw_rev); > - error = ENXIO; > - goto fail; > + mtx_destroy(&sc->msk_mtx); > + return (ENXIO); > } > > SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 08:16:43 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 4ADDE16A402 for ; Thu, 5 Apr 2007 08:16:43 +0000 (UTC) (envelope-from andrew@mcdonald.org.uk) Received: from widget.mcdonald.org.uk (widget.mcdonald.org.uk [81.187.72.227]) by mx1.freebsd.org (Postfix) with ESMTP id 0283E13C457 for ; Thu, 5 Apr 2007 08:16:42 +0000 (UTC) (envelope-from andrew@mcdonald.org.uk) Received: from admcd by widget.mcdonald.org.uk with local (Exim 4.63) (envelope-from ) id 1HZN95-00036H-Di; Thu, 05 Apr 2007 09:16:39 +0100 Date: Thu, 5 Apr 2007 09:16:39 +0100 From: Andrew McDonald To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20070405081639.GB6798@mcdonald.org.uk> References: <20070404211815.GA6798@mcdonald.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) 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, 05 Apr 2007 08:16:43 -0000 On Thu, Apr 05, 2007 at 03:07:43PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > At Wed, 4 Apr 2007 22:18:15 +0100, > Andrew McDonald wrote: > > > In the absence of a full fix, it would probably be a good idea to > > remove this unconditional check. This would avoid FreeBSD blocking IPv6 > > packets with router alert set. However, I'm not sure if this would have > > an impact on MLD. > > It does, so (while I see your point) the fix is not that trivial. > > Just out of curiosity, do you have any specific application that > relies on the router alert option and suffers from the current > behavior? Or are you just talking about stringent compliance with the > specification? I'm primarily interested in the current IETF NSIS work, which uses router alert for path-coupled signalling. Although my systems aren't using FreeBSD, I'm seeing problems from KAME-derived IPv6 stacks in routers on the path. Thinking about it a bit, there is a simple fix that leaves MLD working (but currently doesn't provide a way for other applications to use router alert). The IPv6 Router Alert Option (RAO) has a 16-bit value field. For MLD this is zero. Other uses would contain different values (as per RFC2711). rtalert contains the contents of this value field, or (u_int32_t)~0 if there is no router alert option. So, if we change the check to: /* * accept the packet if a router alert option with value 0 * is included and we act as an IPv6 router. */ if (rtalert == 0 && ip6_forwarding) ours = 1; we'll only pick up packets containing ipv6 router alerts with value 0 (i.e. MLD router alerted packets). -- Andrew McDonald E-mail: andrew@mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 10:24:05 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 EC96E16A409 for ; Thu, 5 Apr 2007 10:24:05 +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 C237C13C45D for ; Thu, 5 Apr 2007 10:24:05 +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 6256A212654; Thu, 5 Apr 2007 06:24:11 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 05 Apr 2007 06:24:06 -0400 X-Sasl-enc: 4d4uDJwenqmk6SxRGw41h+QIPy5lQ/TOTiKphmFDKIlA 1175768645 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 65AF432885; Thu, 5 Apr 2007 06:24:05 -0400 (EDT) Message-ID: <4614CE43.2050601@FreeBSD.org> Date: Thu, 05 Apr 2007 11:24:03 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Andrew McDonald References: <20070404211815.GA6798@mcdonald.org.uk> <20070405081639.GB6798@mcdonald.org.uk> In-Reply-To: <20070405081639.GB6798@mcdonald.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "JINMEI Tatuya / ?$B?@L@C#:H" 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, 05 Apr 2007 10:24:06 -0000 I can only speak about IPv4 router alert in detail; we do nothing with IPv4 RA nor would it appear that it would make any real difference in performance given how the code is laid out. RSVP packets should be passed verbatim to userland from ip_input() via rip_input() there. I think your IPv6 fix is good for now but will wait to hear further from jinmei@. I am heading out the door so if someone could add an item for this to http://wiki.FreeBSD.org/Networking I should be most grateful. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 14:02:48 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 DF0DC16A401 for ; Thu, 5 Apr 2007 14:02:48 +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 B0E0013C448 for ; Thu, 5 Apr 2007 14:02:48 +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 95C337301F; Thu, 5 Apr 2007 23:02:47 +0900 (JST) Date: Thu, 05 Apr 2007 23:02:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Andrew McDonald In-Reply-To: <20070405081639.GB6798@mcdonald.org.uk> References: <20070404211815.GA6798@mcdonald.org.uk> <20070405081639.GB6798@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, 05 Apr 2007 14:02:49 -0000 At Thu, 5 Apr 2007 09:16:39 +0100, Andrew McDonald wrote: > Thinking about it a bit, there is a simple fix that leaves MLD working > (but currently doesn't provide a way for other applications to use > router alert). The IPv6 Router Alert Option (RAO) has a 16-bit value > field. For MLD this is zero. Other uses would contain different values > (as per RFC2711). > > rtalert contains the contents of this value field, or (u_int32_t)~0 if > there is no router alert option. So, if we change the check to: > /* > * accept the packet if a router alert option with value 0 > * is included and we act as an IPv6 router. > */ > if (rtalert == 0 && ip6_forwarding) > ours = 1; > we'll only pick up packets containing ipv6 router alerts with value 0 > (i.e. MLD router alerted packets). 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. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp Index: ip6_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ip6_input.c,v retrieving revision 1.90 diff -u -r1.90 ip6_input.c --- ip6_input.c 24 Feb 2007 11:38:47 -0000 1.90 +++ ip6_input.c 5 Apr 2007 13:57:21 -0000 @@ -657,11 +657,25 @@ nxt = hbh->ip6h_nxt; /* - * accept the packet if a router alert option is included - * and we act as an IPv6 router. + * If we are acting as a router and the packet contains a + * router alert option, see if we know the option value. + * Currently, we only support the option value for MLD, in which + * case we should pass the packet to the multicast routing + * daemon. */ - if (rtalert != ~0 && ip6_forwarding) - ours = 1; + if (rtalert != ~0 && ip6_forwarding) { + switch (rtalert) { + case IP6OPT_RTALERT_MLD: + ours = 1; + break; + default: + /* + * RFC2711 requires unrecognized values must be + * silently ignored. + */ + break; + } + } } else nxt = ip6->ip6_nxt; From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 15:21:27 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 ACCF616A401; Thu, 5 Apr 2007 15:21:27 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from mx1.ethionet.et (mx1.ethionet.et [213.55.64.53]) by mx1.freebsd.org (Postfix) with ESMTP id 223A713C459; Thu, 5 Apr 2007 15:21:27 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from mx1.ethionet.et (localhost [127.0.0.1]) by localhost.ethionet.et (Postfix) with ESMTP id 2B45B5245; Thu, 5 Apr 2007 18:17:43 +0300 (EAT) Received: from rogue.navcom.lan (unknown [213.55.64.98])by mx1.ethionet.et ( Postfix) with SMTP id 44F0A51C8;Thu, 5 Apr 2007 18:17:40 +0300 (EAT) Received: by rogue.navcom.lan (Postfix, from userid 1001)id C97A717045; Thu, 5 Apr 2007 18:24:06 +0300 (EAT) Date: Thu, 5 Apr 2007 18:24:06 +0300 From: Mike Makonnen To: Jeremie Le Hen Message-ID: <20070405152406.GA1844@rogue.navcom.lan> References: <20070329182906.GB38703@rogue.navcom.lan> <20070403211132.GL5155 @obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070403211132.GL5155@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD/7.0-CURRENT (i386) X-imss-version: 2.46 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:4 C:3 M:3 S:4 R:3 (1.0000 1.0000) Cc: freebsd-net@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2007 15:21:27 -0000 On Tue, Apr 03, 2007 at 11:11:32PM +0200, Jeremie Le Hen wrote: > > As Dag-Erling said, it may conflict with a future if_ip. Moreover, > network interfaces are renameable, so the namespace conflict is even > more likely. > > Although it breaks the standard rc(8) syntax, I would personaly prefer: > /etc/rc.d/netif (start6|stop6) rl0 > > BTW, the proposed syntax isn't very usual either :). I wasn't happy about the syntax either, but I was at a loss at how to handle it. Now that you've mentioned the obvious answer, I'm wondering how come it never occured to me :-P > > > - In order to differentiate between v4 and v6 configuration directives some > > knobs in rc.conf(5)have been renamed with an ipv4_ prefix: > > network_interfaces > > ifconfig_DEFAULT > > ifconfig_ > > ifconfig__aliasX > > defaultrouter > > gateway_enable > > static_routes > > etc... > > > > - Modify all scripts that reference old knobs (without ipv4_ prefix) to > > reference the new version of the knobs > > > > - Compatibility shims in rc.subr(8) so that old uses of knobs without an > > ipv4_ prefix work as expected. As part of this change split the > > code for this processing into its own function: old2new_knobs() > > This is neat. What about issuing a warning in order to make a > quicker transition ? > I think this is a matter of personal preference. If a lot of people think there should be a warning I can add it. Personally, I don't see the need, we can keep the shims as long as we want. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mmakonnen @ gmail.com | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm @ FreeBSD.Org | FreeBSD - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 15:25: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 EE63816A401 for ; Thu, 5 Apr 2007 15:25:51 +0000 (UTC) (envelope-from andrew@mcdonald.org.uk) Received: from widget.mcdonald.org.uk (widget.mcdonald.org.uk [81.187.72.227]) by mx1.freebsd.org (Postfix) with ESMTP id A738013C448 for ; Thu, 5 Apr 2007 15:25:51 +0000 (UTC) (envelope-from andrew@mcdonald.org.uk) Received: from admcd by widget.mcdonald.org.uk with local (Exim 4.63) (envelope-from ) id 1HZTqN-0003vj-Go; Thu, 05 Apr 2007 16:25:47 +0100 Date: Thu, 5 Apr 2007 16:25:47 +0100 From: Andrew McDonald To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20070405152547.GC6798@mcdonald.org.uk> References: <20070404211815.GA6798@mcdonald.org.uk> <20070405081639.GB6798@mcdonald.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) 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, 05 Apr 2007 15:25:52 -0000 On Thu, Apr 05, 2007 at 11:02:42PM +0900, JINMEI Tatuya / ?$B?@L@C#:H 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. I'm mainly interested in new allocations (i.e. values above 35). Thanks. -- Andrew McDonald E-mail: andrew@mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 15:44: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 6F23816A409; Thu, 5 Apr 2007 15:44:07 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from mx1.ethionet.et (mx1.ethionet.et [213.55.64.53]) by mx1.freebsd.org (Postfix) with ESMTP id 5228913C45E; Thu, 5 Apr 2007 15:44:01 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from mx1.ethionet.et (localhost [127.0.0.1]) by localhost.ethionet.et (Postfix) with ESMTP id C98CB5235; Thu, 5 Apr 2007 18:40:18 +0300 (EAT) Received: from rogue.navcom.lan (unknown [213.55.64.98])by mx1.ethionet.et ( Postfix) with SMTP id 2799551E6;Thu, 5 Apr 2007 18:40:18 +0300 (EAT) Received: by rogue.navcom.lan (Postfix, from userid 1001)id 8420417045; Thu, 5 Apr 2007 18:46:44 +0300 (EAT) Date: Thu, 5 Apr 2007 18:46:44 +0300 From: Mike Makonnen To: Brooks Davis Message-ID: <20070405154644.GB1844@rogue.navcom.lan> References: <20070329182906.GB38703@rogue.navcom.lan> <20070403231423.GA5244 1@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070403231423.GA52441@lor.one-eyed-alien.net> User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD/7.0-CURRENT (i386) X-imss-version: 2.46 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:4 C:3 M:3 S:4 R:3 (1.0000 1.0000) Cc: freebsd-net@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2007 15:44:07 -0000 On Tue, Apr 03, 2007 at 06:14:23PM -0500, Brooks Davis wrote: > > - You can now do things like: > > # Start/Stop IPv6 on all interfaces > > /etc/rc.d/netif (start|stop) ip6 > > # Start/Stop IPv6 only on interface rl0 > > /etc/rc.d/netif (start|stop) rl0 ip6 > > # Do IPv6 options processing > > /etc/rc.d/routing options ip6 > > I think I'd prefer (start|stop)(4|6). I not sure what the value of the > separation is, but don't care much. I'll post a new patch with this change. Now that its been mentioned I agree, it's a better thatn what I came up with. > > Overview of the changes in src/etc > > ----------------------------------- > > - In order to differentiate between v4 and v6 configuration directives some > > knobs in rc.conf(5)have been renamed with an ipv4_ prefix: > > network_interfaces > > I fell fairly strongly that ipv6_network_interfaces and > network_interfaces are a mistake and that we should remove them > rather than propagating them. The way I'd prefer to see interfaces > that are exceptional with regard to address families specified with > (|NO)IPV(4|6) variables in ifconfig_ or simply by not > having ipv(4|6)_ifconfig_interface variables (that it's a little more > complicated than that with ipv4_addrs_ around, but I think > the concept holds). I agree completely. However, when this hits the tree I don't want peoples configurations to break (especially since I would like to see this in 6-stable if we can aggree on it). Also, since this feature is already deprecated in the man page I think we can provide silent support for it without explicitly advertising it untill people have had a suffient transition period. > > > ifconfig_DEFAULT > > ifconfig_ > > ipv4 versions of these make sense, but at least ifconfig_ > should continue to exist. For example both setting the mac address and > starting WPA via the WPA keyword should not work in any address specific > version because that would be a layering violation. > Ok. That should be doable, but it's probably going to make configuration decisions more complicated. For example, do we ignore the WPA in the ipv(4|6)_* variables or does it's presence in any of the variables enable it? > > I would > > especially like feedback from folks more familiar with IPv6. One > > gotcha I've noticed is that if you boot with ipv6_enable turned > > off, then try to start IPv6 on an interface later on, it doesn't > > work because none of the interfaces (except lo0) has a link-local > > address (see rc.d/auto_linklocal). How can we fix this? Also, I > > would appreciate feedback on how stopping IPv6 on an interface > > should be handled. In rc.d/network_ipv6 it was handled at all. > > Currently, it goes through and deletes all > > IPv6 addresses on the interface. > > I'd say if ipv6_enable=NO, attempting to configure IPv6 on an interface > should fail. If they turn it on, I'm not sure what the best approach > is. Not worrying about it may well be most appropriate. I don't agree. I would expect that if I enable IPv6 in rc.conf I wouldn't have to reboot the machine to get my network interfaces configured properly. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mmakonnen @ gmail.com | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm @ FreeBSD.Org | FreeBSD - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 16:02: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 6187316A402; Thu, 5 Apr 2007 16:02:53 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id 039B313C45B; Thu, 5 Apr 2007 16:02:52 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l35G2pjt078120; Thu, 5 Apr 2007 11:02:51 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l35G2pH1078119; Thu, 5 Apr 2007 11:02:51 -0500 (CDT) (envelope-from brooks) Date: Thu, 5 Apr 2007 11:02:51 -0500 From: Brooks Davis To: Mike Makonnen Message-ID: <20070405160251.GA68077@lor.one-eyed-alien.net> References: <20070329182906.GB38703@rogue.navcom.lan> <20070403231423.GA52441@lor.one-eyed-alien.net> <20070405154644.GB1844@rogue.navcom.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: <20070405154644.GB1844@rogue.navcom.lan> User-Agent: Mutt/1.5.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 05 Apr 2007 11:02:51 -0500 (CDT) Cc: freebsd-net@freebsd.org, Brooks Davis , freebsd-rc@freebsd.org Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2007 16:02:53 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 05, 2007 at 06:46:44PM +0300, Mike Makonnen wrote: > On Tue, Apr 03, 2007 at 06:14:23PM -0500, Brooks Davis wrote: > > > - You can now do things like: > > > # Start/Stop IPv6 on all interfaces > > > /etc/rc.d/netif (start|stop) ip6 > > > # Start/Stop IPv6 only on interface rl0 > > > /etc/rc.d/netif (start|stop) rl0 ip6 > > > # Do IPv6 options processing > > > /etc/rc.d/routing options ip6 > >=20 > > I think I'd prefer (start|stop)(4|6). I not sure what the value of the > > separation is, but don't care much. >=20 > I'll post a new patch with this change. Now that its been mentioned > I agree, it's a better thatn what I came up with.=20 >=20 > > > Overview of the changes in src/etc > > > ----------------------------------- > > > - In order to differentiate between v4 and v6 configuration directiv= es some > > > knobs in rc.conf(5)have been renamed with an ipv4_ prefix: > > > network_interfaces > >=20 > > I fell fairly strongly that ipv6_network_interfaces and > > network_interfaces are a mistake and that we should remove them > > rather than propagating them. The way I'd prefer to see interfaces > > that are exceptional with regard to address families specified with > > (|NO)IPV(4|6) variables in ifconfig_ or simply by not > > having ipv(4|6)_ifconfig_interface variables (that it's a little more > > complicated than that with ipv4_addrs_ around, but I think > > the concept holds). >=20 > I agree completely. However, when this hits the tree I don't want peoples > configurations to break (especially since I would like to see this in > 6-stable if we can aggree on it). Also, since this feature is already > deprecated in the man page I think we can provide silent support for > it without explicitly advertising it untill people have had a suffient > transition period. OK, do you think it would be possible to kill off=20 > > > ifconfig_DEFAULT > > > ifconfig_ > >=20 > > ipv4 versions of these make sense, but at least ifconfig_ > > should continue to exist. For example both setting the mac address and > > starting WPA via the WPA keyword should not work in any address specific > > version because that would be a layering violation. > >=20 >=20 > Ok. That should be doable, but it's probably going to make > configuration decisions more complicated. For example, do we ignore > the WPA in the ipv(4|6)_* variables or does it's presence in any > of the variables enable it? I'd ignore WPA outside of ifconfig_. I think we'll want DHCP to work there and under ipv4_ifconfig_, but not IPv6. That will change if/when a dhcp6 client arrives, but who knows when that will happen. > > > I would > > > especially like feedback from folks more familiar with IPv6. One > > > gotcha I've noticed is that if you boot with ipv6_enable turned > > > off, then try to start IPv6 on an interface later on, it doesn't > > > work because none of the interfaces (except lo0) has a link-local > > > address (see rc.d/auto_linklocal). How can we fix this? Also, I > > > would appreciate feedback on how stopping IPv6 on an interface > > > should be handled. In rc.d/network_ipv6 it was handled at all. > > > Currently, it goes through and deletes all > > > IPv6 addresses on the interface. > >=20 > > I'd say if ipv6_enable=3DNO, attempting to configure IPv6 on an interfa= ce > > should fail. If they turn it on, I'm not sure what the best approach > > is. Not worrying about it may well be most appropriate. >=20 > I don't agree. I would expect that if I enable IPv6 in rc.conf I wouldn't > have to reboot the machine to get my network interfaces configured > properly. That would be nice if we can make it work. I'm just not sure how much effort it's worth to make all the edge cases work. -- Brooks --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGFR2qXY6L6fI4GtQRAhO3AKC4X5kWLjxlS8RPmNKPcu6DJ3ypJgCggJLC JCp4UmykOptHlgyDsNRqefo= =r511 -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 17:58: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 822A016A409 for ; Thu, 5 Apr 2007 17:58:53 +0000 (UTC) (envelope-from marga@rivero.com.ar) Received: from avas-mr13.fibertel.com.ar (avas-mr13.fibertel.com.ar [24.232.0.197]) by mx1.freebsd.org (Postfix) with ESMTP id 0887713C48C for ; Thu, 5 Apr 2007 17:58:53 +0000 (UTC) (envelope-from marga@rivero.com.ar) Received: from 29-185-89-200.fibertel.com.ar ([200.89.185.29]:44704 "EHLO smtp.rivero.com.ar" smtp-auth: "laboratoriosrivero@fibertel.com.ar") by avas-mr13.fibertel.com.ar with ESMTPA id S490565AbXDERlJ convert rfc822-to-8bit; Thu, 5 Apr 2007 14:41:09 -0300 Received: from localhost (fobos.rivero [192.168.200.241]) by smtp.rivero.com.ar (Postfix) with ESMTP id C9E4B409B for ; Thu, 5 Apr 2007 14:41:10 -0300 (ART) Received: from marga by localhost with local (Exim 3.36 #1 (Debian)) id 1HZVxL-0004as-00 for ; Thu, 05 Apr 2007 14:41:07 -0300 From: Margarita Manterola To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Date: Thu, 05 Apr 2007 14:41:07 -0300 Message-Id: <1175794867.2831.78.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Sender: Margarita Manterola X-Fib-Al-Info: Al X-Fib-Al-MRId: 5774b5799d3ef1868e03c87cdaaefa69 X-Fib-Al-SA: analyzed X-Fib-Al-From: marga@rivero.com.ar Subject: Problem with ipx X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Apr 2007 17:58:53 -0000 Hi! I'm having troubles with a Novell network, and found your message, which is strangely exactly two years old: http://lists.freebsd.org/pipermail/freebsd-net/2005-April/006907.html My problem looks a lot like yours. Did you ever find what was going on? Given the date coincidence, I'm inclined to think it's a virus of some sort. -- Margarita Manterola Área de Sistemas From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 19:53:49 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 B6BCB16A401 for ; Thu, 5 Apr 2007 19:53:49 +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 B383D13C46C for ; Thu, 5 Apr 2007 19:53:48 +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 l35JAu1n003995 for ; Thu, 5 Apr 2007 23:10:57 +0400 (MSD) (envelope-from wawa@yandex-team.ru) Message-ID: <461549BD.1020800@yandex-team.ru> Date: Thu, 05 Apr 2007 23:10:53 +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: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------040209070900020908020409" X-Spam-Ystatus: hits=-1000.6 ALLTRUSTEDIP LV_YOU_CAN SICKNESS LV_FREE SP_HTTP_URI FAKE_TEXT_CONTENT_TYPE STRANGE_DUPLETS ALEN_5000 NEWBAYES_099 __MESS_NO_BODY SH_9_100 SH_6_1111 WB_6_D_D SH_6_500 WB_6_B_E __IMAGE__LINK REAL_NAME_TO_ABSENT SPF_PASS DL_DLWC_15 X-Spam-Flag: NO X-Spam-Yversion: Spamooborona 1.7.0-nda Subject: 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: Thu, 05 Apr 2007 19:53:49 -0000 This is a multi-part message in MIME format. --------------040209070900020908020409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, 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've attached draft patch for bce driver to illustrate the problem. WBR, Vladimir Ivanov Yandex LLC --------------040209070900020908020409 Content-Type: text/x-patch; name="if_bce.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_bce.c.patch" --- if_bce.c.orig Fri Mar 16 00:58:25 2007 +++ if_bce.c Thu Apr 5 02:57:39 2007 @@ -3943,6 +3943,8 @@ bce_rx_intr(struct bce_softc *sc) unsigned int len; u32 status; + m = NULL; + /* Convert the producer/consumer indices to an actual rx_bd index. */ sw_chain_cons = RX_CHAIN_IDX(sw_cons); sw_chain_prod = RX_CHAIN_IDX(sw_prod); @@ -4131,16 +4133,30 @@ bce_rx_intr(struct bce_softc *sc) ifp->if_ipackets++; DBPRINT(sc, BCE_VERBOSE_RECV, "%s(): Passing received frame up.\n", __FUNCTION__); - BCE_UNLOCK(sc); - (*ifp->if_input)(ifp, m); - DBRUNIF(1, sc->rx_mbuf_alloc--); - BCE_LOCK(sc); bce_rx_int_next_rx: sw_prod = NEXT_RX_BD(sw_prod); } sw_cons = NEXT_RX_BD(sw_cons); + + if (m) { + sc->rx_cons = sw_cons; + sc->rx_prod = sw_prod; + sc->rx_prod_bseq = sw_prod_bseq; + + BCE_UNLOCK(sc); + (*ifp->if_input)(ifp, m); + BCE_LOCK(sc); + DBRUNIF(1, sc->rx_mbuf_alloc--); + + sw_cons = sc->rx_cons; + sw_prod = sc->rx_prod; + sw_prod_bseq = sc->rx_prod_bseq; + hw_cons = sc->hw_rx_cons = sblk->status_rx_quick_consumer_index0; + if ((hw_cons & USABLE_RX_BD_PER_PAGE) == USABLE_RX_BD_PER_PAGE) + hw_cons++; + } /* Refresh hw_cons to see if there's new work */ if (sw_cons == hw_cons) { --------------040209070900020908020409-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 20:38: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 7A60616A4CD; Thu, 5 Apr 2007 20:38:32 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by mx1.freebsd.org (Postfix) with ESMTP id AB63413C4F3; Thu, 5 Apr 2007 20:38:29 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 1HZW0I-00075D-4K; Thu, 05 Apr 2007 17:44:10 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp4.email.verio.net with esmtp id 1HZW0I-0000MI-0y; Thu, 05 Apr 2007 17:44:10 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 21B9F8E131; Thu, 5 Apr 2007 12:44:00 -0500 (CDT) Date: Thu, 5 Apr 2007 12:44:00 -0500 From: David DeSimone To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Message-ID: <20070405174359.GA23665@verio.net> Mail-Followup-To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: Status of sasyncd for 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: Thu, 05 Apr 2007 20:38:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Lists - Sorry for the cross-post, but I am not actually sure which list this question belongs on. I have been working on building HA firewall/VPN systems using PF and IPSEC and CARP. The systems work quite well, however there is a small gap in the desired feature set: HA VPN. I believe OpenBSD has a daemon called sasyncd(8) which utilizes pfsync(4) to synchronize the negotiated SA's between the cluster members. So, if one firewall fails, the other can pick up and continue not only firewall state but VPN activity without a hitch. So I am wondering, what is the status of a port of sasyncd to FreeBSD? Any pointers appreciated. I am also wondering about IKE synchronization. My understanding is that sasyncd keeps the IPSEC SA's sync'd between cluster members, but the IKE negotiations are not synchronized. I imagine that racoon(8) would have to take on that role, and I am curious if any work has been done to facilitate this. If there is any further work needed, I would like to look into completing it, but I don't want to start from scratch unless I have to. Please let me know what info is available. - -- David DeSimone == Network Admin == fox@verio.net "It took me fifteen years to discover that I had no talent for writing, but I couldn't give it up because by that time I was too famous. -- Robert Benchley -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGFTVfFSrKRjX5eCoRAuYoAKCiZqpY7dr1XdxaFr7oU2faK95qqgCdGrQb HreD59KGGG9G18Qbp/uflYk= =Cl2M -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 21:34: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 6172B16A401 for ; Thu, 5 Apr 2007 21:34:20 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by mx1.freebsd.org (Postfix) with ESMTP id 23B1E13C483 for ; Thu, 5 Apr 2007 21:34:19 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so397656nza for ; Thu, 05 Apr 2007 14:34:19 -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=h6xvsIaMSvIGBiz4Tc46yh49vJIne8HJogTduIN1tR4XPeBpEbsEDavjOhEGkDc29asZf3+bWA+Pc9P1vj2BEEP9sM/sT+w1PRF5NEceLBOQP1E3pzMSRzcuU1dOlBaYYxqvstWRm8sVvFmHIF6t/lQbR0juFqV8S/hvXcGTvUk= 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=PSh4igqcNLYTM5caGIY2fDSTaWesjXSkJtqy+cMPDZhdZpA9Wl8PWDkAzdWJAlx3GEOj4OzEmN33iHwlcg9GQG4YMTdibImoE/z2fyafxv74W5/bgPiFjk4kBuFPWvDR2Ac8KA0hgGDwJ5qHjrKCmUKjJ3wV3Z8wgrqEAvqaoSE= Received: by 10.115.32.1 with SMTP id k1mr906267waj.1175808858970; Thu, 05 Apr 2007 14:34:18 -0700 (PDT) Received: by 10.114.103.15 with HTTP; Thu, 5 Apr 2007 14:34:13 -0700 (PDT) Message-ID: <2a41acea0704051434p2b8c5902x868d0a5d6510aa01@mail.gmail.com> Date: Thu, 5 Apr 2007 14:34:13 -0700 From: "Jack Vogel" To: freebsd-stable@freebsd.org, freebsd-net , freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: 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: Thu, 05 Apr 2007 21:34:20 -0000 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. 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 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. 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 :) Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Fri Apr 6 02:05:56 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 3416316A401 for ; Fri, 6 Apr 2007 02:05:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id CD76513C4BC for ; Fri, 6 Apr 2007 02:05:55 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so348746pyh for ; Thu, 05 Apr 2007 19:05:55 -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=pTjZwvj+BP20e2U+UIyQpmAMXgY7vja1shM7q0dh6X55t5PxOkPlLoBoOFslfVKZ5lnbXwdbBjD4MItKtUIGmaFzwuHecT3YICona9A7JJ+fugFaZGAnwf5D/tHFgGRufmb8WuMIbCsjcRKaqd7aM7yViOgUNo0Wp3jTPVkvNDI= 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=libmarXE8Bj7wBuDm3LSAFVNwIaxEmLkKjWT0ZGUgcKB2MDu14dNz0205wYJ3a7CR0+pK9I+E7ToVzxea448WiQZoXkvrAAS0Cr5RuTs0IuGklE0KqICr5Tz+eW31Xv5r8uzAeoYGrOY4W4H5YhFjNAoC6nsFpb+mjfyjmz/wyI= Received: by 10.65.116.10 with SMTP id t10mr306340qbm.1175825155252; Thu, 05 Apr 2007 19:05:55 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 15sm10830774nzn.2007.04.05.19.05.52; Thu, 05 Apr 2007 19:05:53 -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 l3626bWC020758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 11:06:37 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l3626ZMS020757; Fri, 6 Apr 2007 11:06:35 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 6 Apr 2007 11:06:35 +0900 From: Pyun YongHyeon To: Marv Message-ID: <20070406020635.GB20103@cdnetworks.co.kr> References: <20070404100200.GA1167@home.bh.net> <20070404111158.GB11525@cdnetworks.co.kr> <20070404190649.GB986@home.bh.net> <20070405001533.GA15837@cdnetworks.co.kr> <20070405072945.GA1418@home.bh.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070405072945.GA1418@home.bh.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: if_msk in 6.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 02:05:56 -0000 On Thu, Apr 05, 2007 at 09:29:45AM +0200, Marv wrote: > It works with acpi disabled: > > mskkc0: port 0x2000-0x20ff mem > 0xd0000000-0xd0003fff irq 16 at device 0.0 on pci2 > msk0: on mskc0 > msk0: Ethernet address: 00:16:36:8a:f4:a3 > miibus0: on msk0 > e1000phy0: on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > When using acpi I get the same error as before but without hang of > course. > Thanks for the report. Patch committed to HEAD. > On Thu, Apr 05, 2007 at 09:15:33AM +0900, Pyun YongHyeon wrote: > > On Wed, Apr 04, 2007 at 09:06:49PM +0200, Marv wrote: > > > Thanks for your reply. I checked out the kernel source tree of RELENG_6, > > > applied your patch and compiled a new kernel. > > > > > > The kernel boots and detects a 88E8038 Ethernet card but then hangs: > > > > > > mskc0: irq 16 at device 0.0 on > > > pci2 > > > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > > > mskc0: unknown device: id=0xff, rev=0x0f > > > > > > (doing nothing no more at this point). > > > > > > Was there some kind of detection failure or is my ethernet controller > > > not configured properly to fit the driver? > > > > > > > Since msk(4) supports 88E8038 I guess the device was not properly > > initialized/recognized by system BIOS. > > > > But it's driver bug if it hang your system when it encounter an > > exceptional condition. Try attached patch and report back the result. > > It wouldn't fix device recognization but it will not hang your system. > > -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Fri Apr 6 02:31:35 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 114F416A401 for ; Fri, 6 Apr 2007 02:31:35 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id CE1B713C455 for ; Fri, 6 Apr 2007 02:31:34 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 5E5135DFD28; Fri, 6 Apr 2007 12:31:31 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 8549F8C0F; Fri, 6 Apr 2007 12:31:30 +1000 (EST) Date: Fri, 6 Apr 2007 12:31:28 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Vladimir Ivanov In-Reply-To: <461549BD.1020800@yandex-team.ru> Message-ID: <20070406121505.T43678@delplex.bde.org> References: <461549BD.1020800@yandex-team.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Fri, 06 Apr 2007 02:31:35 -0000 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 -- 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 Fri Apr 6 07:04: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 F3E4C16A401 for ; Fri, 6 Apr 2007 07:04:38 +0000 (UTC) (envelope-from rajkumars@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id B66F213C45D for ; Fri, 6 Apr 2007 07:04:38 +0000 (UTC) (envelope-from rajkumars@gmail.com) Received: by wr-out-0506.google.com with SMTP id 50so526011wra for ; Fri, 06 Apr 2007 00:04:38 -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=TR85kQZZtfquMT4oye8wHH3LN5hFInCaPCULTbEKQa5rIcFz/qrkTyOlvKZARvyKt3NuB5r5MwK3DUaKQWQjQe8uo7ZkE/2gKgAjkIifGJsk6vIvnF8qxh4NL3V6P8SQg254kyABTCC1KR51rsznpN7QqWSA6DR6E2JXS+S3PsI= 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=btBVfEh/u9GzdFi4idw6bmaR6OiMvcNaVQoHmNlQ6wDOlMipXJgmnV30EbdoSCou1wd1gyeQak5U/Ne2QcIRzbtC70SDV+WvydLceAT/xJmIRM7NlbI6djdjFOokfExxkjyGJqG2a4kveWEyeMR6bX2skoOtOJ1F2aYJT/4EBhs= Received: by 10.114.170.1 with SMTP id s1mr1124708wae.1175843077789; Fri, 06 Apr 2007 00:04:37 -0700 (PDT) Received: by 10.114.13.9 with HTTP; Fri, 6 Apr 2007 00:04:37 -0700 (PDT) Message-ID: <64de5c8b0704060004s5d2f4416if88f32cc45c77aba@mail.gmail.com> Date: Fri, 6 Apr 2007 12:34:37 +0530 From: "Rajkumar S" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline Subject: Spillover routing? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Apr 2007 07:04:39 -0000 SGksCgpJIGhhdmUgYSBsb3cgY29zdCAxMjhrYnBzIGFuZCBhIGhpZ2ggY29zdCA1MTIga2JwcyBs aW5rIHRvIGludGVybmV0LgpJcyBpdCBwb3NzaWJsZSB0byBkbyBhICJzcGlsbG92ZXIiIHJvdXRp bmcgc28gdGhhdCB0aGUgaGlnaCBjb3N0IGxpbmsKaXMgdXNlZCBvbmx5IHdoZW4gdGhlIGxvdyBj b3N0IGxpbmsgaXMsIHNheSwgdXNlZCBtb3JlIHRoYW4gODAlLgoKSSBoYXZlIHNlZW4gdGhpcyB3 b3JrIGluIFNvbmljd2FsbCwgZnJvbSBpdCdzIE1hbnVhbDoKClNwaWxsb3Zlci1CYXNlZCAtLSB3 aGVuIHNlbGVjdGVkLCB0aGUgdXNlciBjYW4gc3BlY2lmeSB3aGVuIHRoZQpTb25pY1dBTEwgc3Rh cnRzIHNlbmRpbmcgdHJhZmZpYyB0aHJvdWdoIHRoZSBTZWNvbmRhcnkgV0FOIGludGVyZmFjZS4K VGhpcyBtZXRob2QgYWxsb3dzIHRoZSBhZG1pbmlzdHJhdG9yIHRvIGNvbnRyb2wgd2hlbiBhbmQg aWYgdGhlClNlY29uZGFyeSBpbnRlcmZhY2UgaXMgZXZlbiB1c2VkLiBUaGlzIG1ldGhvZCB3aWxs IGJlIHVzZWQgd2hlbiB1c2VycwpkbyBub3QgcmVhbGx5IHdhbnQgb3V0Ym91bmQgdHJhZmZpYyBz ZW50IGFjcm9zcyB0aGUgU2Vjb25kYXJ5IFdBTgp1bmxlc3MgdGhlIFByaW1hcnkgV0FOIGlzIG92 ZXJsb2FkZWQuIFRoZSBTb25pY1dBTEwgaGFzIGEKb24tR1VJLWV4cG9zZWQgaG9sZCB0aW1lciBz ZXQgdG8gMjAgc2Vjb25kcyDigJMgaWYgdGhlIHN1c3RhaW5lZApvdXRib3VuZCB0cmFmZmljIGFj cm9zcyB0aGUgUHJpbWFyeSBXQU4gaW50ZXJmYWNlIGV4Y2VlZHMgdGhlCnVzZXItZGVmaW5lZCBL YnBzIGV4Y2VlZHMgdGhpcywgdGhlbiB0aGUgU29uaWNXQUxMIHdpbGwgc3BpbGwgb3V0Ym91bmQK dHJhZmZpYyB0byB0aGUgU2Vjb25kYXJ5IFdBTiBpbnRlcmZhY2UgKG9uIGEgcGVyLWRlc3RpbmF0 aW9uIGJhc2lzKS4KVGhlIHVzZXIgZW50cnkgYm94IHNob3VsZCBub3QgaGF2ZSBhIGRlZmF1bHQg ZW50cnkgYW5kIGJlIGxlZnQgZW1wdHkKZm9yIHRoZSB1c2VyLiBQbGVhc2Ugbm90ZSB0aGlzIGZl YXR1cmUgd2lsbCBiZSBvdmVycmlkZGVuIGJ5IHNwZWNpZmljCnN0YXRpYyByb3V0ZSBlbnRyaWVz LgoKcmFqCg== From owner-freebsd-net@FreeBSD.ORG Fri Apr 6 11:43: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 B70E616A402; Fri, 6 Apr 2007 11:43:02 +0000 (UTC) (envelope-from fujita@soum.co.jp) Received: from gate.soum.co.jp (gate.soum.co.jp [202.221.40.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5990F13C4AE; Fri, 6 Apr 2007 11:43:02 +0000 (UTC) (envelope-from fujita@soum.co.jp) Received: from mail.soum.co.jp (hoth.soum.co.jp [IPv6:2001:240:c4:1:203:baff:fea1:6471]) by gate.soum.co.jp (8.13.8/8.13.8) with ESMTP id l36B18CF090336; Fri, 6 Apr 2007 20:01:08 +0900 (JST) (envelope-from fujita@soum.co.jp) Received: from localhost (luke.soum.co.jp [IPv6:2001:240:c4:1:203:baff:fe80:54a5]) (authenticated bits=0) by mail.soum.co.jp (8.13.8/8.13.8) with ESMTP id l36B15BI007706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Apr 2007 20:01:07 +0900 (JST) Date: Fri, 06 Apr 2007 20:01:05 +0900 (JST) Message-Id: <20070406.200105.131603592.fujita@soum.co.jp> To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org From: FUJITA Kazutoshi X-Face: "; PnIN=f2{%Xj2PnI+zHd.39&Cn1)}br_7:N|2[CbS87Du6#6?|UeqX'&OfyZG-mX#'5T>k/~8X(F,2Mb_pNd8]3Cb1u[kSZjF}J+#`L5(g); List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 11:43:02 -0000 Hi, I have ASUS P5B, running FreeBSD 6.2-STABLE. It has on-board re(4) as follows, re0: port 0xa800-0xa8ff mem 0xfe9ff000-0xfe9fffff irq 19 at device 0.0 on pci3 miibus1: on re0 rgephy0: on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1a:92:6e:f2:a5 re0: [FAST] pciconf -lv re0@pci3:0:0: class=0x020000 card=0x81aa1043 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' class = network subclass = ethernet # ifconfig re0 re0: flags=8843 mtu 1500 options=1b inet6 fe80::21a:92ff:fe6e:f2a5%re0 prefixlen 64 scopeid 0x2 inet 172.19.3.78 netmask 0xffff0000 broadcast 172.19.255.255 ether 00:1a:92:6e:f2:a5 media: Ethernet autoselect (1000baseTX ) status: active # sysctl net.inet6.ip6.accept_rtadv net.inet6.ip6.accept_rtadv: 1 # rtsol -d re0 checking if re0 is ready... re0 is ready send RS on re0, whose state is 2 send RS on re0, whose state is 2 send RS on re0, whose state is 2 No answer after sending 3 RSs stop timer for re0 there is no timer It seems re0 can't receive IPv6 RA message. But in promisc mode(running tcpdump on another terminal), it receives RA. # ifconfig re0 re0: flags=8943 mtu 1500 options=1b inet6 fe80::21a:92ff:fe6e:f2a5%re0 prefixlen 64 scopeid 0x2 inet 172.19.3.78 netmask 0xffff0000 broadcast 172.19.255.255 ether 00:1a:92:6e:f2:a5 media: Ethernet autoselect (1000baseTX ) status: active # rtsol -d re0 checking if re0 is ready... re0 is ready send RS on re0, whose state is 2 received RA from fe80::230:48ff:fe81:e3fd on re0, state is 2 stop timer for re0 there is no timer # ifconfig re0 re0: flags=8943 mtu 1500 options=1b inet6 fe80::21a:92ff:fe6e:f2a5%re0 prefixlen 64 scopeid 0x2 inet 172.19.3.78 netmask 0xffff0000 broadcast 172.19.255.255 inet6 2001:240:c4:1:21a:92ff:fe6e:f2a5 prefixlen 64 autoconf ether 00:1a:92:6e:f2:a5 media: Ethernet autoselect (1000baseTX ) status: active Any suggestions? Regards, From owner-freebsd-net@FreeBSD.ORG Fri Apr 6 13:24:57 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 B51CA16A408; Fri, 6 Apr 2007 13:24:57 +0000 (UTC) (envelope-from fujita@soum.co.jp) Received: from gate.soum.co.jp (gate.soum.co.jp [202.221.40.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6103813C48A; Fri, 6 Apr 2007 13:24:56 +0000 (UTC) (envelope-from fujita@soum.co.jp) Received: from mail.soum.co.jp (hoth.soum.co.jp [IPv6:2001:240:c4:1:203:baff:fea1:6471]) by gate.soum.co.jp (8.13.8/8.13.8) with ESMTP id l36DOtns096110; Fri, 6 Apr 2007 22:24:55 +0900 (JST) (envelope-from fujita@soum.co.jp) Received: from localhost (luke.soum.co.jp [172.19.2.3]) (authenticated bits=0) by mail.soum.co.jp (8.13.8/8.13.8) with ESMTP id l36DOqmS002272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Apr 2007 22:24:55 +0900 (JST) Date: Fri, 06 Apr 2007 22:24:52 +0900 (JST) Message-Id: <20070406.222452.58377787.fujita@soum.co.jp> To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org From: FUJITA Kazutoshi In-Reply-To: <20070406.200105.131603592.fujita@soum.co.jp> References: <20070406.200105.131603592.fujita@soum.co.jp> X-Face: "; PnIN=f2{%Xj2PnI+zHd.39&Cn1)}br_7:N|2[CbS87Du6#6?|UeqX'&OfyZG-mX#'5T>k/~8X(F,2Mb_pNd8]3Cb1u[kSZjF}J+#`L5(g); List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 13:24:57 -0000 From: FUJITA Kazutoshi Subject: re(4) can't receive some multicast ? Date: Fri, 06 Apr 2007 20:01:05 +0900 (JST) > I have ASUS P5B, running FreeBSD 6.2-STABLE. > It has on-board re(4) as follows, > It seems re0 can't receive IPv6 RA message. > But in promisc mode(running tcpdump on another terminal), > it receives RA. Sorry, this is known problem. -CURRENT re(4) handles variant and it works fine for me. Regards, From owner-freebsd-net@FreeBSD.ORG Fri Apr 6 14:06:39 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 7C43216A404 for ; Fri, 6 Apr 2007 14:06:39 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id 2D71913C489 for ; Fri, 6 Apr 2007 14:06:39 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l36E6GX0035449 for ; Fri, 6 Apr 2007 07:06:16 -0700 (PDT) Date: Fri, 06 Apr 2007 23:05:57 +0900 Message-ID: From: gnn@freebsd.org To: net@freebsd.org User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.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: Subject: 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: Fri, 06 Apr 2007 14:06:39 -0000 Hi, There is now a patch here: http://people.freebsd.org/~gnn/fast_ipv6.20070406.diff which follows the current state of my radical_ipsec p4 branch. 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. When I applied the patch to a CURRENT tree (6 April 2007, 23:00 JST) it applied but did not automatically create the netinet6/ip6_ipsec.c and netinet6/ip6_sec.h file. I'm not sure why not. If those files are not created then you can create them by hand from the patch file. This is the direction that IPsec will be going in future so it would be good for people to start at least looking at these changes. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Apr 6 15:05:24 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 7DFF316A401 for ; Fri, 6 Apr 2007 15:05:24 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3B7E013C46C for ; Fri, 6 Apr 2007 15:05:24 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HZpke-0008Oz-GR for freebsd-net@freebsd.org; Fri, 06 Apr 2007 16:49:20 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Apr 2007 16:49:20 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Apr 2007 16:49:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 06 Apr 2007 16:49:01 +0200 Lines: 33 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig26795FA797AF72F334941D56" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: X-Enigmail-Version: 0.94.2.0 Sender: news 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: Fri, 06 Apr 2007 15:05:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig26795FA797AF72F334941D56 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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,=20 performance, cleanup (I see spl...() functions removed), or something els= e? --------------enig26795FA797AF72F334941D56 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.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGFl3dldnAQVacBcgRAl6JAJ9vV6Eqz+CKchgGd5kjgpop/63YrgCfYFa0 XtdbGFmHFVz1LZXtw5DrvFg= =2Stl -----END PGP SIGNATURE----- --------------enig26795FA797AF72F334941D56-- From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 03:25:03 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 EC65F16A401; Sat, 7 Apr 2007 03:25:03 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id B738313C468; Sat, 7 Apr 2007 03:25:03 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id DC5898C9B50; Sat, 7 Apr 2007 11:05:00 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id C41808C9B4E; Sat, 7 Apr 2007 11:05:00 +0800 (CST) Date: Sat, 7 Apr 2007 11:05:00 +0800 (CST) From: Tai-hwa Liang To: Jack Vogel In-Reply-To: <2a41acea0704051434p2b8c5902x868d0a5d6510aa01@mail.gmail.com> Message-ID: <0704071047341.19686@www.mmlab.cse.yzu.edu.tw> References: <2a41acea0704051434p2b8c5902x868d0a5d6510aa01@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Sat, 07 Apr 2007 03:25:04 -0000 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. -- Cheers, Tai-hwa Liang From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 04:20:43 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 4CAA016A401 for ; Sat, 7 Apr 2007 04:20:43 +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 27ABE13C465 for ; Sat, 7 Apr 2007 04:20: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 8EEFE212318 for ; Sat, 7 Apr 2007 00:20:41 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 07 Apr 2007 00:20:41 -0400 X-Sasl-enc: LE1zmICLq+ZF6i4AiPeic8kJJJooA8MULpUsPp2AZgr5 1175919641 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 F3D6423630 for ; Sat, 7 Apr 2007 00:20:40 -0400 (EDT) Message-ID: <46171C17.9080809@incunabulum.net> Date: Sat, 07 Apr 2007 05:20:39 +0100 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) 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: Source-specific multicast X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Apr 2007 04:20:43 -0000 I am very close to merging support for RFC 3678 to -CURRENT. I will make a patch available before I commit. The only userland consumer in the tree which is likely to be affected by the removal of ip_multicast_if() from the kernel is routed, which I will update to use the new setsourcefilter() API. The SSM code does change some of the coupling between sockets and IGMP, and changes some logic in udp_input; strict multicast membership becomes the default. For systems which deal with many multicast sockets and traffic, they may benefit from an additional hash table. I haven't finished touching the raw IP input path. Given current looming commitments I'm open to someone volunteering to finish the work of merging IGMPv3 and MLDv2, or possibly to fund the work. I wish to get at least the socket part of ASM/SSM merged before I come back to Yar's PR with vlan and pfsync, which I have not had reason to investigate thoroughly; I have had no further reports of problems with carp(4) in -CURRENT. regards, BMS From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 04:23: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 56B7E16A403 for ; Sat, 7 Apr 2007 04:23:23 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 44DB113C44B for ; Sat, 7 Apr 2007 04:23:23 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 5A23A1A3C1C; Fri, 6 Apr 2007 21:23:24 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6DED751482; Sat, 7 Apr 2007 00:23:22 -0400 (EDT) Date: Sat, 7 Apr 2007 00:23:22 -0400 From: Kris Kennaway To: Ivan Voras Message-ID: <20070407042322.GA72639@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-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: Sat, 07 Apr 2007 04:23:23 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 06, 2007 at 04:49:01PM +0200, Ivan Voras wrote: > gnn@freebsd.org wrote: >=20 > >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. >=20 > Just a quick question: Is the reason for this simplification,=20 > performance, cleanup (I see spl...() functions removed), or something els= e? 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. Kris --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFxy5Wry0BWjoQKURAnySAKCn7H/2T7AOsuoVfhXegEbrHOKkVgCfQIK6 NBR4qmXXX3YINNs52GcR+uA= =QThW -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 04:27:32 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 1B84716A401; Sat, 7 Apr 2007 04:27:32 +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 E9CFE13C45A; Sat, 7 Apr 2007 04:27: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 6C8FE212384; Sat, 7 Apr 2007 00:27:32 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 07 Apr 2007 00:27:32 -0400 X-Sasl-enc: 1vCVfAOksla+WfoXM2U03MkcPEthbu2SH4MDxHoNFQ+/ 1175920051 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 B9B2B18DD4; Sat, 7 Apr 2007 00:27:31 -0400 (EDT) Message-ID: <46171DB2.6070705@FreeBSD.org> Date: Sat, 07 Apr 2007 05:27:30 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: gnn@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Sat, 07 Apr 2007 04:27:32 -0000 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. I will try to look at the patch in more detail as time permits. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 10:35: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 517E816A402; Sat, 7 Apr 2007 10:35:29 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6C013C45E; Sat, 7 Apr 2007 10:35:28 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-g20.free.fr (Postfix) with ESMTP id AE4BED3E678; Sat, 7 Apr 2007 12:16:09 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 32B47432AB; Sat, 7 Apr 2007 12:16:07 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 3B3509C387; Sat, 7 Apr 2007 10:16:01 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 117C3405D; Sat, 7 Apr 2007 12:16:01 +0200 (CEST) Date: Sat, 7 Apr 2007 12:16:00 +0200 From: Jeremie Le Hen To: "Bruce M. Simpson" Message-ID: <20070407101600.GF11297@obiwan.tataz.chchile.org> References: <46171DB2.6070705@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46171DB2.6070705@FreeBSD.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: gnn@freebsd.org, 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: Sat, 07 Apr 2007 10:35:29 -0000 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 ? George, Thank you for your work! 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 ? Thank you. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 15:01: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 4930316A403 for ; Sat, 7 Apr 2007 15:01:21 +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 21C1E13C4B7 for ; Sat, 7 Apr 2007 15:01:20 +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 E1D502143A3; Sat, 7 Apr 2007 11:01:13 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 07 Apr 2007 11:01:20 -0400 X-Sasl-enc: Ao4mP6ktSrixDN1beguRGvnJQKD6/iQAd+QkXh6Sb48O 1175958080 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 D5678194F1; Sat, 7 Apr 2007 11:01:19 -0400 (EDT) Message-ID: <4617B23D.1090502@FreeBSD.org> Date: Sat, 07 Apr 2007 16:01:17 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Rajkumar S References: <64de5c8b0704060004s5d2f4416if88f32cc45c77aba@mail.gmail.com> In-Reply-To: <64de5c8b0704060004s5d2f4416if88f32cc45c77aba@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Spillover routing? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Apr 2007 15:01:21 -0000 Rajkumar S wrote: > Hi, > > I have a low cost 128kbps and a high cost 512 kbps link to internet. > Is it possible to do a "spillover" routing so that the high cost link > is used only when the low cost link is, say, used more than 80%. This feature is almost certainly not going to be present in the base system. What you would need to do to implement this is to configure a part of the kernel to perform bandwidth measurements and make an upcall to bring up the other link in a dial-on-demand style configuration. Add NAT into the mix and it gets even more interesting. I believe pf+altq may have the potential to do this however I could not help you with where to begin re configuring it to do so, so I wish you best of luck in your research. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 16:20:44 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 2DBF716A400 for ; Sat, 7 Apr 2007 16:20:44 +0000 (UTC) (envelope-from rajkumars@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.freebsd.org (Postfix) with ESMTP id E29CB13C4AD for ; Sat, 7 Apr 2007 16:20:43 +0000 (UTC) (envelope-from rajkumars@gmail.com) Received: by wr-out-0506.google.com with SMTP id 50so723110wra for ; Sat, 07 Apr 2007 09:20:43 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dk7TArGLiwQDtkuKoTGsWLeMgJIeKaSiQ5BvCGv3gqzIM8GYgKDHoVtGSfpwOcoiFiujNNFnJ8o8yDql1HmLqg04xxwX+x74R+nKiV8JQiR3z8NGB8Sp6g9sC39fr5PpYWMM2fElKoRJeUYclpD2M9SBMpmDZ3M1ZAVPyLWueHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oFHHXMVwKd7gZ1RgozhQE2A1kxMIPTszuyv5bYB0txWcBc0bb4SghEL14QLjBHQ45RbZT5eivHPi9P3s6SfYSC2rEGaVvBXeLrDg2+Huo6b6r+rRnwKD70xmKBIiwIeda5IJ/K7Pbj4KzUG8RQiOPVxEt1tINqSIS3FFtUPjO2g= Received: by 10.114.183.1 with SMTP id g1mr1652181waf.1175962842355; Sat, 07 Apr 2007 09:20:42 -0700 (PDT) Received: by 10.114.13.9 with HTTP; Sat, 7 Apr 2007 09:20:42 -0700 (PDT) Message-ID: <64de5c8b0704070920q986b5fat7523ac2b4e2b53d7@mail.gmail.com> Date: Sat, 7 Apr 2007 21:50:42 +0530 From: "Rajkumar S" To: freebsd-net@freebsd.org In-Reply-To: <4617B23D.1090502@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <64de5c8b0704060004s5d2f4416if88f32cc45c77aba@mail.gmail.com> <4617B23D.1090502@FreeBSD.org> Subject: Re: Spillover routing? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Apr 2007 16:20:44 -0000 On 4/7/07, Bruce M. Simpson wrote: > Rajkumar S wrote: > > I have a low cost 128kbps and a high cost 512 kbps link to internet. > > Is it possible to do a "spillover" routing > This feature is almost certainly not going to be present in the base > system. I was almost sure of this, but was just checking if I did miss some thing. To do spillover load balancing, I need to 1. Measure the current bandwidth. 2. If the current b/w is above certain limit, all new sessions should go via backup gateway, till the b/w in old gateway comes back to safe limit. I can measure the bandwidth using any userspace tools, and a simple approach would be to add the new gateway to the route-to rule when the b/w is above limit and remove it when the usage comes down. One problem with this approach is that when I add a new gateway, only round-robin [with sticky-address option] algorithm is available, though I would have liked to have all new sessions to be via new gateway and old sessions via old gateway. When it's strictly round robin, 50% of new sessions would have to go via existing gateway, causing some congestion. I prefer to have old sessions via old gateway because if some website expects all connections to be from same public ips they will not be disappointed. Another more ambitious and complex method would be to make use of tags support in pf, and use tags to select which gateway a session should use. Tagging can be done outside pf, and netgraph seems to be well suited for it. I can write a ng_tag, which can attach to upper and lower hook of lan interface, silently selecting which session should go to which gateway such that when a overload message is passed to it, all new sessions can be tagged to go via new gateway. This will also open up possibility of having ratios other than 1:1 when I have to use multiple gateways, some thing like 2:1 between two gateways. This is particularly useful when I have a 512 and 256 link, and want to use both of them together. ng_netflow already does most of the stuff, ie parsing the raw traffic flow into sessions good enough for load balancing, I am not sure if I want to take this route though. there is a big learning curve involved when I start coding. So before I plunge into it, I just want to check what other listers think about this. regards, raj From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 17:01: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 8FC8A16A402; Sat, 7 Apr 2007 17:01:19 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 653B113C44B; Sat, 7 Apr 2007 17:01:19 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.178] ([10.0.0.178]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l37GXU0w060449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 09:33:31 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4617C7DD.8050704@errno.com> Date: Sat, 07 Apr 2007 09:33:33 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Jeremie Le Hen References: <46171DB2.6070705@FreeBSD.org> <20070407101600.GF11297@obiwan.tataz.chchile.org> In-Reply-To: <20070407101600.GF11297@obiwan.tataz.chchile.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gnn@freebsd.org, "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: Sat, 07 Apr 2007 17:01:19 -0000 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 ? He's probably talking about my old Usenix BSDCon paper about fast ipsec. Look at the Usenix web site. > > > > George, > > Thank you for your work! > > 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 ? It's easier to add features when there's a single code base to add them too. Some stuff exists in netbsd's fast ipsec code base and can be brought over with minimal effort. Sam From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 20:16:53 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 CC82016A401 for ; Sat, 7 Apr 2007 20:16:53 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from sr-7-int.cis.tamu.edu (smtp-relay.tamu.edu [165.91.22.120]) by mx1.freebsd.org (Postfix) with ESMTP id 9FF1813C44B for ; Sat, 7 Apr 2007 20:16:51 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from localhost (localhost.tamu.edu [127.0.0.1]) by sr-7-int.cis.tamu.edu (Postfix) with ESMTP id 784B04F90E for ; Sat, 7 Apr 2007 15:01:11 -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-7-int.cis.tamu.edu (Postfix) with ESMTP id AC39D4F903 for ; Sat, 7 Apr 2007 15:01:10 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v752.2) To: net@freebsd.org Message-Id: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-100374143; protocol="application/pkcs7-signature" From: David Duchscher Date: Sat, 7 Apr 2007 15:01:09 -0500 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: Subject: pf + scrub fragment reassemble + if_bridge = bad? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Apr 2007 20:16:54 -0000 --Apple-Mail-1-100374143 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Ran into a problem the other day and wanted to drop a note and see if I should followup with a PR. Running a box as a bridging firewall and ran into problem with giant packets being reported by the router on one end and OSPF routing dropping. Seems that once a packet is reassembled by pf, it gets forward on through the bridge and out onto the wire. In this case, it was an OSPF packet that ended up being 1540 bytes long . Of course, turning off the scrub rules fix the problem but I was wondering if this is expected behavior, a bug, or has already been fix. The box is running 6.1-RELEASE i386. Network interfaces are em gigabit interfaces with MTU at 1500. Thanks, -- DaveD --Apple-Mail-1-100374143-- From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 21:04:53 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 2305616A400 for ; Sat, 7 Apr 2007 21:04:53 +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 BDCC013C46C for ; Sat, 7 Apr 2007 21:04:52 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id E6B301CC58; Sun, 8 Apr 2007 08:51:39 +1200 (NZST) Date: Sun, 8 Apr 2007 08:51:39 +1200 From: Andrew Thompson To: David Duchscher Message-ID: <20070407205139.GD64415@heff.fud.org.nz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: net@freebsd.org Subject: Re: pf + scrub fragment reassemble + if_bridge = bad? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Apr 2007 21:04:53 -0000 On Sat, Apr 07, 2007 at 03:01:09PM -0500, David Duchscher wrote: > Ran into a problem the other day and wanted to drop a note and see > if I should followup with a PR. Running a box as a bridging firewall > and ran into problem with giant packets being reported by the router > on one end and OSPF routing dropping. Seems that once a packet is > reassembled by pf, it gets forward on through the bridge and out > onto the wire. In this case, it was an OSPF packet that ended up > being 1540 bytes long . Of course, turning off the scrub rules fix > the problem but I was wondering if this is expected behavior, a > bug, or has already been fix. > > The box is running 6.1-RELEASE i386. Network interfaces are em > gigabit interfaces with MTU at 1500. You are quite right and this has been fixed from 6.2. You will either need to upgrade to that or manually apply r1.11.2.31 cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 21:20: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 9D72416A402 for ; Sat, 7 Apr 2007 21:20:42 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from sr-2-int.cis.tamu.edu (smtp-relay.tamu.edu [165.91.22.120]) by mx1.freebsd.org (Postfix) with ESMTP id 66C9C13C44B for ; Sat, 7 Apr 2007 21:20:42 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from localhost (localhost.tamu.edu [127.0.0.1]) by sr-2-int.cis.tamu.edu (Postfix) with ESMTP id D85801AE10; Sat, 7 Apr 2007 16:20:41 -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-2-int.cis.tamu.edu (Postfix) with ESMTP id 37F531AE0B; Sat, 7 Apr 2007 16:20:41 -0500 (CDT) In-Reply-To: <20070407205139.GD64415@heff.fud.org.nz> References: <20070407205139.GD64415@heff.fud.org.nz> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-105144997; protocol="application/pkcs7-signature" Message-Id: From: David Duchscher Date: Sat, 7 Apr 2007 16:20:40 -0500 To: Andrew Thompson 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: net@freebsd.org Subject: Re: pf + scrub fragment reassemble + if_bridge = bad? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Apr 2007 21:20:42 -0000 --Apple-Mail-2-105144997 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Apr 7, 2007, at 3:51 PM, Andrew Thompson wrote: > On Sat, Apr 07, 2007 at 03:01:09PM -0500, David Duchscher wrote: >> Ran into a problem the other day and wanted to drop a note and see >> if I should followup with a PR. Running a box as a bridging firewall >> and ran into problem with giant packets being reported by the router >> on one end and OSPF routing dropping. Seems that once a packet is >> reassembled by pf, it gets forward on through the bridge and out >> onto the wire. In this case, it was an OSPF packet that ended up >> being 1540 bytes long . Of course, turning off the scrub rules fix >> the problem but I was wondering if this is expected behavior, a >> bug, or has already been fix. >> >> The box is running 6.1-RELEASE i386. Network interfaces are em >> gigabit interfaces with MTU at 1500. > > You are quite right and this has been fixed from 6.2. You will either > need to upgrade to that or manually apply r1.11.2.31 Sweet and thanks. I swear I looked for a fix had already been committed but obviously I missed it. -- DaveD --Apple-Mail-2-105144997--