From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 00:00:16 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21512106566C for ; Sun, 7 Feb 2010 00:00:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 117638FC08 for ; Sun, 7 Feb 2010 00:00:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1700FNB024785 for ; Sun, 7 Feb 2010 00:00:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1700FGr024784; Sun, 7 Feb 2010 00:00:15 GMT (envelope-from gnats) Date: Sun, 7 Feb 2010 00:00:15 GMT Message-Id: <201002070000.o1700FGr024784@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Mars G Miro Cc: Subject: Re: kern/143573: [em] em(4) NIC crashes intermittently X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mars G Miro List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 00:00:16 -0000 The following reply was made to PR kern/143573; it has been noted by GNATS. From: Mars G Miro To: bug-followup@FreeBSD.org, earl.lapus@gmail.com, Jack Vogel , Ivan Voras Cc: Subject: Re: kern/143573: [em] em(4) NIC crashes intermittently Date: Sun, 7 Feb 2010 07:59:49 +0800 This looks like these: http://forums.freebsd.org/archive/index.php/t-10475.html http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054369.html How about this? http://www.mail-archive.com/commits@crater.dragonflybsd.org/msg03494.html -- cheers mars ----- Joan Crawford - "I, Joan Crawford, I believe in the dollar. Everything I earn, I spend." - http://www.brainyquote.com/quotes/authors/j/joan_crawford.html From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 01:20:03 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F8E0106566B for ; Sun, 7 Feb 2010 01:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 705B78FC13 for ; Sun, 7 Feb 2010 01:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o171K3f9096445 for ; Sun, 7 Feb 2010 01:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o171K3Q3096444; Sun, 7 Feb 2010 01:20:03 GMT (envelope-from gnats) Date: Sun, 7 Feb 2010 01:20:03 GMT Message-Id: <201002070120.o171K3Q3096444@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Ivan Voras Cc: Subject: Re: kern/143573: [em] em(4) NIC crashes intermittently X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ivan Voras List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 01:20:03 -0000 The following reply was made to PR kern/143573; it has been noted by GNATS. From: Ivan Voras To: Mars G Miro Cc: bug-followup@freebsd.org, earl.lapus@gmail.com, Jack Vogel Subject: Re: kern/143573: [em] em(4) NIC crashes intermittently Date: Sun, 7 Feb 2010 01:41:08 +0100 On 7 February 2010 00:59, Mars G Miro wrote: > This looks like these: > http://forums.freebsd.org/archive/index.php/t-10475.html > http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054369.html > > How about this? > http://www.mail-archive.com/commits@crater.dragonflybsd.org/msg03494.html > I don't know - from the looks of the traces it seems like all of these point to a different bug... From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 02:12:57 2010 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 029391065676 for ; Sun, 7 Feb 2010 02:12:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9F9C38FC08 for ; Sun, 7 Feb 2010 02:12:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o172AqFR052559 for ; Sat, 6 Feb 2010 19:10:52 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 06 Feb 2010 19:11:53 -0700 (MST) Message-Id: <20100206.191153.401093655925072575.imp@bsdimp.com> To: net@FreeBSD.org From: "M. Warner Losh" X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: How does rpc.lockd know where to send a request X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 02:12:57 -0000 I have a problem. All systems are running freebsd-current form sometime in the last month, although similar systems running 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS client is doing something that baffles my mind entirely, maybe you can help. Please bear with me, this is a little complicated, but I wanted to include all the details. I have a host, let's call it dune. dune is at 10.0.0.5. dune is also the master for the carp interface 10.0.0.99. It is running rpc.lockd and is an nfs server. I've told nfs, rpcbind, lockd and statd to only listen on address 10.0.0.99. I have a second host. maud-dib is 10.0.0.8. I do "mount 10.0.0.99:/dune /dune" on maud-dib. Wireshark shows all the traffic going to 10.0.0.99. All is happy in the world. When I start, there's no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. Until I do the following 'lockf /dune/imp/junk ls' (I have write perms to /dune/imp). At this point, rpc.lockd hangs. I get the message "10.0.0.99:/dune: lockd not responding" which seems odd. lockd is really there. However, wireshark shows the NLM traffic going to IP address 10.0.0.5. maud-dib has no carp interfaces. That's odd. So my question is 'how does lockd know where to go to talk the NLM protocol?' I did a packet capture from before I did the mount on maud-dib. I can see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to 10.0.0.5. This gets an ICMP port unreachable message, since I told nfs, et al, to bind only to 10.0.0.99. So, I thought, 'the answer is obvious, I'll just look for the packet that has the string 'dune' in it (which is the hostname of 10.0.0.5). No packets have that string in it, other than the mount packet which has /dune in it. Nor is there any DNS activity doing a lookup. Nor is there any static mapping in /etc/hosts on 10.0.0.8. Next thought: Oh, somebody like portmapper or the NFS protocol from 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do locking requests to 10.0.0.5. That's trivial to find, I think to myself. I'll look for the octets 0a 00 00 05 (hex). The only instances of that are in the ARP packet, the NLM request and the ICMP unreachable packets. No other packets includes these bytes. Nor do any include the reverse. Right after the mount, there's nothing in the connection table that points to 10.0.0.5, only 10.0.0.99. So I'm having a serious WTF moment. How the heck is this even possible. Any ideas on where to look for where this gets set and/or communicated? thanks a bunch for any insight that you can give... Warner From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 03:05:45 2010 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 006B01065694 for ; Sun, 7 Feb 2010 03:05:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-16.mx.aerioconnect.net [216.240.47.76]) by mx1.freebsd.org (Postfix) with ESMTP id D7D9D8FC15 for ; Sun, 7 Feb 2010 03:05:44 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o172rDbi017659; Sat, 6 Feb 2010 18:53:13 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 457DF2D6011; Sat, 6 Feb 2010 18:53:13 -0800 (PST) Message-ID: <4B6E2B40.1070405@elischer.org> Date: Sat, 06 Feb 2010 18:53:52 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "M. Warner Losh" References: <20100206.191153.401093655925072575.imp@bsdimp.com> In-Reply-To: <20100206.191153.401093655925072575.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: net@FreeBSD.org Subject: Re: How does rpc.lockd know where to send a request X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 03:05:45 -0000 M. Warner Losh wrote: > I have a problem. All systems are running freebsd-current form > sometime in the last month, although similar systems running > 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS > client is doing something that baffles my mind entirely, maybe you can > help. Please bear with me, this is a little complicated, but I wanted > to include all the details. > > I have a host, let's call it dune. dune is at 10.0.0.5. dune is also > the master for the carp interface 10.0.0.99. It is running rpc.lockd > and is an nfs server. I've told nfs, rpcbind, lockd and statd to only > listen on address 10.0.0.99. > > I have a second host. maud-dib is 10.0.0.8. I do "mount > 10.0.0.99:/dune /dune" on maud-dib. Wireshark shows all the traffic > going to 10.0.0.99. All is happy in the world. When I start, there's > no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. > > Until I do the following 'lockf /dune/imp/junk ls' (I have write perms > to /dune/imp). At this point, rpc.lockd hangs. I get the message > "10.0.0.99:/dune: lockd not responding" which seems odd. lockd is > really there. However, wireshark shows the NLM traffic going to IP > address 10.0.0.5. maud-dib has no carp interfaces. > > That's odd. So my question is 'how does lockd know where to go to > talk the NLM protocol?' > my recollection is that maud-dib will sent an initial packet to dune and dune will respond but that the response may come from 10.0.0.5, after which maud-dib will redirect all requests there, which will not work because dune is not listenning there. teh problem is that dune's daemon is setting a local address of IPADDR_ANY (0.0.0.0) which tells the packets to use a from address that is the address ofthe interface that they exit from. Since 10.0.0.5 is the primary address on that interface, that gets selected. you may try some trickery where you add the .5 address AFTER the .99 address so that the .99 is the primary address. > I did a packet capture from before I did the mount on maud-dib. I can > see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an > ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to > 10.0.0.5. This gets an ICMP port unreachable message, since I told > nfs, et al, to bind only to 10.0.0.99. > > So, I thought, 'the answer is obvious, I'll just look for the packet > that has the string 'dune' in it (which is the hostname of 10.0.0.5). > No packets have that string in it, other than the mount packet which > has /dune in it. Nor is there any DNS activity doing a lookup. Nor > is there any static mapping in /etc/hosts on 10.0.0.8. > > Next thought: Oh, somebody like portmapper or the NFS protocol from > 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do > locking requests to 10.0.0.5. That's trivial to find, I think to > myself. I'll look for the octets 0a 00 00 05 (hex). The only > instances of that are in the ARP packet, the NLM request and the ICMP > unreachable packets. No other packets includes these bytes. Nor do > any include the reverse. > > Right after the mount, there's nothing in the connection table that > points to 10.0.0.5, only 10.0.0.99. > > So I'm having a serious WTF moment. How the heck is this even > possible. Any ideas on where to look for where this gets set and/or > communicated? > > thanks a bunch for any insight that you can give... > > Warner > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 04:09:24 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C81B1065670 for ; Sun, 7 Feb 2010 04:09:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EC2928FC0A for ; Sun, 7 Feb 2010 04:09:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o1743sr7053288; Sat, 6 Feb 2010 21:03:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 06 Feb 2010 21:04:55 -0700 (MST) Message-Id: <20100206.210455.756168950357586371.imp@bsdimp.com> To: julian@elischer.org From: "M. Warner Losh" In-Reply-To: <4B6E2B40.1070405@elischer.org> References: <20100206.191153.401093655925072575.imp@bsdimp.com> <4B6E2B40.1070405@elischer.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: How does rpc.lockd know where to send a request X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 04:09:24 -0000 In message: <4B6E2B40.1070405@elischer.org> Julian Elischer writes: : M. Warner Losh wrote: : > I have a problem. All systems are running freebsd-current form : > sometime in the last month, although similar systems running : > 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS : > client is doing something that baffles my mind entirely, maybe you can : > help. Please bear with me, this is a little complicated, but I wanted : > to include all the details. : > I have a host, let's call it dune. dune is at 10.0.0.5. dune is also : > the master for the carp interface 10.0.0.99. It is running rpc.lockd : > and is an nfs server. I've told nfs, rpcbind, lockd and statd to only : > listen on address 10.0.0.99. : > I have a second host. maud-dib is 10.0.0.8. I do "mount : > 10.0.0.99:/dune /dune" on maud-dib. Wireshark shows all the traffic : > going to 10.0.0.99. All is happy in the world. When I start, there's : > no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. : > Until I do the following 'lockf /dune/imp/junk ls' (I have write perms : > to /dune/imp). At this point, rpc.lockd hangs. I get the message : > "10.0.0.99:/dune: lockd not responding" which seems odd. lockd is : > really there. However, wireshark shows the NLM traffic going to IP : > address 10.0.0.5. maud-dib has no carp interfaces. : > That's odd. So my question is 'how does lockd know where to go to : > talk the NLM protocol?' : > : : my recollection is that maud-dib will sent an initial packet to dune : and dune will respond but that the response may come from 10.0.0.5, : after which maud-dib will redirect all requests there, which will not : work because dune is not listenning there. But wouldn't the response from 10.0.0.5 mean I could search for the hex string and see 0a000005 in the packet header? : teh problem is that dune's daemon is setting a local address of : IPADDR_ANY (0.0.0.0) which tells the packets to use a from : address that is the address ofthe interface that they exit from. No, dune's daemon is sitting on 10.0.0.99. : Since 10.0.0.5 is the primary address on that interface, that gets : selected. : you may try some trickery where you add the .5 address AFTER the .99 : address so that the .99 is the primary address. Normally, I'd believe you. But since there's nothing listening on the * address, and also nothing listening on the 10.0.0.5 address, I'm less sure. After looking at the wireshark dump, I don't see any 10.0.0.5 packets until the ARP for it near the end of the trace. http://people.freebsd.org/~imp/wireshark.dat if you are interested. This is a good theory, and I'll have to look into it deeper. Warner : > I did a packet capture from before I did the mount on maud-dib. I can : > see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an : > ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to : > 10.0.0.5. This gets an ICMP port unreachable message, since I told : > nfs, et al, to bind only to 10.0.0.99. : > So, I thought, 'the answer is obvious, I'll just look for the packet : > that has the string 'dune' in it (which is the hostname of 10.0.0.5). : > No packets have that string in it, other than the mount packet which : > has /dune in it. Nor is there any DNS activity doing a lookup. Nor : > is there any static mapping in /etc/hosts on 10.0.0.8. : > Next thought: Oh, somebody like portmapper or the NFS protocol from : > 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do : > locking requests to 10.0.0.5. That's trivial to find, I think to : > myself. I'll look for the octets 0a 00 00 05 (hex). The only : > instances of that are in the ARP packet, the NLM request and the ICMP : > unreachable packets. No other packets includes these bytes. Nor do : > any include the reverse. : > Right after the mount, there's nothing in the connection table that : > points to 10.0.0.5, only 10.0.0.99. : > So I'm having a serious WTF moment. How the heck is this even : > possible. Any ideas on where to look for where this gets set and/or : > communicated? : > thanks a bunch for any insight that you can give... : > Warner : > _______________________________________________ : > freebsd-net@freebsd.org mailing list : > http://lists.freebsd.org/mailman/listinfo/freebsd-net : > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" : : From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 04:19:47 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B784106568B for ; Sun, 7 Feb 2010 04:19:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 49CD78FC08 for ; Sun, 7 Feb 2010 04:19:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o174Jfmu053343; Sat, 6 Feb 2010 21:19:41 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 06 Feb 2010 21:20:42 -0700 (MST) Message-Id: <20100206.212042.925196285631243946.imp@bsdimp.com> To: julian@elischer.org From: "M. Warner Losh" In-Reply-To: <4B6E2B40.1070405@elischer.org> References: <20100206.191153.401093655925072575.imp@bsdimp.com> <4B6E2B40.1070405@elischer.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.gSAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: How does rpc.lockd know where to send a request X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 04:19:47 -0000 In message: <4B6E2B40.1070405@elischer.org> Julian Elischer writes: : M. Warner Losh wrote: : > I have a problem. All systems are running freebsd-current form : > sometime in the last month, although similar systems running : > 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS : > client is doing something that baffles my mind entirely, maybe you can : > help. Please bear with me, this is a little complicated, but I wanted : > to include all the details. : > I have a host, let's call it dune. dune is at 10.0.0.5. dune is also : > the master for the carp interface 10.0.0.99. It is running rpc.lockd : > and is an nfs server. I've told nfs, rpcbind, lockd and statd to only : > listen on address 10.0.0.99. : > I have a second host. maud-dib is 10.0.0.8. I do "mount : > 10.0.0.99:/dune /dune" on maud-dib. Wireshark shows all the traffic : > going to 10.0.0.99. All is happy in the world. When I start, there's : > no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. : > Until I do the following 'lockf /dune/imp/junk ls' (I have write perms : > to /dune/imp). At this point, rpc.lockd hangs. I get the message : > "10.0.0.99:/dune: lockd not responding" which seems odd. lockd is : > really there. However, wireshark shows the NLM traffic going to IP : > address 10.0.0.5. maud-dib has no carp interfaces. : > That's odd. So my question is 'how does lockd know where to go to : > talk the NLM protocol?' : > : : my recollection is that maud-dib will sent an initial packet to dune : and dune will respond but that the response may come from 10.0.0.5, : after which maud-dib will redirect all requests there, which will not : work because dune is not listenning there. : : teh problem is that dune's daemon is setting a local address of : IPADDR_ANY (0.0.0.0) which tells the packets to use a from : address that is the address ofthe interface that they exit from. : : Since 10.0.0.5 is the primary address on that interface, that gets : selected. : you may try some trickery where you add the .5 address AFTER the .99 : address so that the .99 is the primary address. Actually, it looks like this is getting returned, as a ASCII string '10.0.0.5' in frame 68 in response to the GETADDR call. Since I've told it specifically '-h 10.0.0.99' I'd have thought it would respect that. Since it is supposed to be bound to 10.0.0.99, I'd proffer the argument this is a bug in rpcbind's implementation of GETADDR. I never would have thought it would have been returned as an ASCII string, but you live and learn, eh? Now, on to fixing the bug. Warner P.S. http://people.freebsd.org/~imp/wireshark.dat has the trace I'm referring to (and I've posted it in another message on this thread). : > I did a packet capture from before I did the mount on maud-dib. I can : > see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an : > ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to : > 10.0.0.5. This gets an ICMP port unreachable message, since I told : > nfs, et al, to bind only to 10.0.0.99. : > So, I thought, 'the answer is obvious, I'll just look for the packet : > that has the string 'dune' in it (which is the hostname of 10.0.0.5). : > No packets have that string in it, other than the mount packet which : > has /dune in it. Nor is there any DNS activity doing a lookup. Nor : > is there any static mapping in /etc/hosts on 10.0.0.8. : > Next thought: Oh, somebody like portmapper or the NFS protocol from : > 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do : > locking requests to 10.0.0.5. That's trivial to find, I think to : > myself. I'll look for the octets 0a 00 00 05 (hex). The only : > instances of that are in the ARP packet, the NLM request and the ICMP : > unreachable packets. No other packets includes these bytes. Nor do : > any include the reverse. : > Right after the mount, there's nothing in the connection table that : > points to 10.0.0.5, only 10.0.0.99. : > So I'm having a serious WTF moment. How the heck is this even : > possible. Any ideas on where to look for where this gets set and/or : > communicated? : > thanks a bunch for any insight that you can give... : > Warner : > _______________________________________________ : > freebsd-net@freebsd.org mailing list : > http://lists.freebsd.org/mailman/listinfo/freebsd-net : > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" : : From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 05:31:09 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF396106568D for ; Sun, 7 Feb 2010 05:31:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-21.mx.aerioconnect.net [216.240.47.81]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4118FC17 for ; Sun, 7 Feb 2010 05:31:09 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o175V678001705; Sat, 6 Feb 2010 21:31:06 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 3D98D2D6011; Sat, 6 Feb 2010 21:31:06 -0800 (PST) Message-ID: <4B6E5041.4050200@elischer.org> Date: Sat, 06 Feb 2010 21:31:45 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "M. Warner Losh" References: <20100206.191153.401093655925072575.imp@bsdimp.com> <4B6E2B40.1070405@elischer.org> <20100206.210455.756168950357586371.imp@bsdimp.com> In-Reply-To: <20100206.210455.756168950357586371.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: net@freebsd.org Subject: Re: How does rpc.lockd know where to send a request X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 05:31:09 -0000 M. Warner Losh wrote: > In message: <4B6E2B40.1070405@elischer.org> > Julian Elischer writes: > : M. Warner Losh wrote: > : > I have a problem. All systems are running freebsd-current form > : > sometime in the last month, although similar systems running > : > 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS > : > client is doing something that baffles my mind entirely, maybe you can > : > help. Please bear with me, this is a little complicated, but I wanted > : > to include all the details. > : > I have a host, let's call it dune. dune is at 10.0.0.5. dune is also > : > the master for the carp interface 10.0.0.99. It is running rpc.lockd > : > and is an nfs server. I've told nfs, rpcbind, lockd and statd to only > : > listen on address 10.0.0.99. > : > I have a second host. maud-dib is 10.0.0.8. I do "mount > : > 10.0.0.99:/dune /dune" on maud-dib. Wireshark shows all the traffic > : > going to 10.0.0.99. All is happy in the world. When I start, there's > : > no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. > : > Until I do the following 'lockf /dune/imp/junk ls' (I have write perms > : > to /dune/imp). At this point, rpc.lockd hangs. I get the message > : > "10.0.0.99:/dune: lockd not responding" which seems odd. lockd is > : > really there. However, wireshark shows the NLM traffic going to IP > : > address 10.0.0.5. maud-dib has no carp interfaces. > : > That's odd. So my question is 'how does lockd know where to go to > : > talk the NLM protocol?' > : > > : > : my recollection is that maud-dib will sent an initial packet to dune > : and dune will respond but that the response may come from 10.0.0.5, > : after which maud-dib will redirect all requests there, which will not > : work because dune is not listenning there. > > But wouldn't the response from 10.0.0.5 mean I could search for the > hex string and see 0a000005 in the packet header? probably, but it may also besoemwhere in the protocol, and not in the header.. It's quite common (I saw it at cisco) for protocols to have fields within them that say "who is responding" where a common address is used instead of where thepacket comes from, but that that address is selected by some mechanism that detirmines the address that would be used to send a packet to teh recipient. the usual mechanism to do this is to open a udp socket, bind to the destination and then do a getsocnname() which will return the primary address of the interface that would be used to send the packet, then that address is used in some "who I am" field within the protocol. anyhow, make sure the primary address on the interface is 99 and hte secondary is 5 before launching your next experiment. if it doesn't change things then that's one theory down the drain. > > : teh problem is that dune's daemon is setting a local address of > : IPADDR_ANY (0.0.0.0) which tells the packets to use a from > : address that is the address ofthe interface that they exit from. > > No, dune's daemon is sitting on 10.0.0.99. > > : Since 10.0.0.5 is the primary address on that interface, that gets > : selected. > : you may try some trickery where you add the .5 address AFTER the .99 > : address so that the .99 is the primary address. > > Normally, I'd believe you. But since there's nothing listening on the > * address, and also nothing listening on the 10.0.0.5 address, I'm > less sure. After looking at the wireshark dump, I don't see any > 10.0.0.5 packets until the ARP for it near the end of the trace. > > http://people.freebsd.org/~imp/wireshark.dat if you are interested. > > This is a good theory, and I'll have to look into it deeper. > > Warner > > > : > I did a packet capture from before I did the mount on maud-dib. I can > : > see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an > : > ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to > : > 10.0.0.5. This gets an ICMP port unreachable message, since I told > : > nfs, et al, to bind only to 10.0.0.99. > : > So, I thought, 'the answer is obvious, I'll just look for the packet > : > that has the string 'dune' in it (which is the hostname of 10.0.0.5). > : > No packets have that string in it, other than the mount packet which > : > has /dune in it. Nor is there any DNS activity doing a lookup. Nor > : > is there any static mapping in /etc/hosts on 10.0.0.8. > : > Next thought: Oh, somebody like portmapper or the NFS protocol from > : > 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do > : > locking requests to 10.0.0.5. That's trivial to find, I think to > : > myself. I'll look for the octets 0a 00 00 05 (hex). The only > : > instances of that are in the ARP packet, the NLM request and the ICMP > : > unreachable packets. No other packets includes these bytes. Nor do > : > any include the reverse. > : > Right after the mount, there's nothing in the connection table that > : > points to 10.0.0.5, only 10.0.0.99. > : > So I'm having a serious WTF moment. How the heck is this even > : > possible. Any ideas on where to look for where this gets set and/or > : > communicated? > : > thanks a bunch for any insight that you can give... > : > Warner > : > _______________________________________________ > : > freebsd-net@freebsd.org mailing list > : > http://lists.freebsd.org/mailman/listinfo/freebsd-net > : > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > : > : From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 05:32:47 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29DC5106566C for ; Sun, 7 Feb 2010 05:32:47 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-21.mx.aerioconnect.net [216.240.47.81]) by mx1.freebsd.org (Postfix) with ESMTP id 0A57D8FC16 for ; Sun, 7 Feb 2010 05:32:46 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o175WjOO001908; Sat, 6 Feb 2010 21:32:45 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 8ADD52D6017; Sat, 6 Feb 2010 21:32:44 -0800 (PST) Message-ID: <4B6E50A3.6080804@elischer.org> Date: Sat, 06 Feb 2010 21:33:23 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "M. Warner Losh" References: <20100206.191153.401093655925072575.imp@bsdimp.com> <4B6E2B40.1070405@elischer.org> <20100206.212042.925196285631243946.imp@bsdimp.com> In-Reply-To: <20100206.212042.925196285631243946.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: net@freebsd.org Subject: Re: How does rpc.lockd know where to send a request X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 05:32:47 -0000 M. Warner Losh wrote: > In message: <4B6E2B40.1070405@elischer.org> > Julian Elischer writes: > : M. Warner Losh wrote: > : > I have a problem. All systems are running freebsd-current form > : > sometime in the last month, although similar systems running > : > 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS > : > client is doing something that baffles my mind entirely, maybe you can > : > help. Please bear with me, this is a little complicated, but I wanted > : > to include all the details. > : > I have a host, let's call it dune. dune is at 10.0.0.5. dune is also > : > the master for the carp interface 10.0.0.99. It is running rpc.lockd > : > and is an nfs server. I've told nfs, rpcbind, lockd and statd to only > : > listen on address 10.0.0.99. > : > I have a second host. maud-dib is 10.0.0.8. I do "mount > : > 10.0.0.99:/dune /dune" on maud-dib. Wireshark shows all the traffic > : > going to 10.0.0.99. All is happy in the world. When I start, there's > : > no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. > : > Until I do the following 'lockf /dune/imp/junk ls' (I have write perms > : > to /dune/imp). At this point, rpc.lockd hangs. I get the message > : > "10.0.0.99:/dune: lockd not responding" which seems odd. lockd is > : > really there. However, wireshark shows the NLM traffic going to IP > : > address 10.0.0.5. maud-dib has no carp interfaces. > : > That's odd. So my question is 'how does lockd know where to go to > : > talk the NLM protocol?' > : > > : > : my recollection is that maud-dib will sent an initial packet to dune > : and dune will respond but that the response may come from 10.0.0.5, > : after which maud-dib will redirect all requests there, which will not > : work because dune is not listenning there. > : > : teh problem is that dune's daemon is setting a local address of > : IPADDR_ANY (0.0.0.0) which tells the packets to use a from > : address that is the address ofthe interface that they exit from. > : > : Since 10.0.0.5 is the primary address on that interface, that gets > : selected. > : you may try some trickery where you add the .5 address AFTER the .99 > : address so that the .99 is the primary address. > > Actually, it looks like this is getting returned, as a ASCII string > '10.0.0.5' in frame 68 in response to the GETADDR call. Since I've > told it specifically '-h 10.0.0.99' I'd have thought it would respect > that. Since it is supposed to be bound to 10.0.0.99, I'd proffer the > argument this is a bug in rpcbind's implementation of GETADDR. > > I never would have thought it would have been returned as an ASCII > string, but you live and learn, eh? > > Now, on to fixing the bug. > > Warner > > P.S. http://people.freebsd.org/~imp/wireshark.dat has the trace I'm > referring to (and I've posted it in another message on this thread). > > : > I did a packet capture from before I did the mount on maud-dib. I can > : > see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an > : > ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to > : > 10.0.0.5. This gets an ICMP port unreachable message, since I told > : > nfs, et al, to bind only to 10.0.0.99. > : > So, I thought, 'the answer is obvious, I'll just look for the packet > : > that has the string 'dune' in it (which is the hostname of 10.0.0.5). > : > No packets have that string in it, other than the mount packet which > : > has /dune in it. Nor is there any DNS activity doing a lookup. Nor > : > is there any static mapping in /etc/hosts on 10.0.0.8. > : > Next thought: Oh, somebody like portmapper or the NFS protocol from > : > 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do > : > locking requests to 10.0.0.5. That's trivial to find, I think to > : > myself. I'll look for the octets 0a 00 00 05 (hex). The only > : > instances of that are in the ARP packet, the NLM request and the ICMP > : > unreachable packets. No other packets includes these bytes. Nor do > : > any include the reverse. > : > Right after the mount, there's nothing in the connection table that > : > points to 10.0.0.5, only 10.0.0.99. > : > So I'm having a serious WTF moment. How the heck is this even > : > possible. Any ideas on where to look for where this gets set and/or > : > communicated? > : > thanks a bunch for any insight that you can give... > : > Warner > : > _______________________________________________ > : > freebsd-net@freebsd.org mailing list > : > http://lists.freebsd.org/mailman/listinfo/freebsd-net > : > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > : > : try swapping the addresses on the interface. From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 05:35:05 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 100661065676; Sun, 7 Feb 2010 05:35:05 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DA50B8FC0C; Sun, 7 Feb 2010 05:35:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o175Z4MT025972; Sun, 7 Feb 2010 05:35:04 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o175Z4Al025968; Sun, 7 Feb 2010 05:35:04 GMT (envelope-from linimon) Date: Sun, 7 Feb 2010 05:35:04 GMT Message-Id: <201002070535.o175Z4Al025968@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143622: [pfil] [patch] unlock pfil lock while calling firewall hooks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 05:35:05 -0000 Old Synopsis: [patch] unlock pfil lock while calling firewall hooks New Synopsis: [pfil] [patch] unlock pfil lock while calling firewall hooks Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 7 05:34:40 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143622 From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 08:41:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 584B61065670; Sun, 7 Feb 2010 08:41:21 +0000 (UTC) (envelope-from egorenar@googlemail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id B85288FC08; Sun, 7 Feb 2010 08:41:20 +0000 (UTC) Received: by ewy3 with SMTP id 3so2658747ewy.13 for ; Sun, 07 Feb 2010 00:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Iqm3EXr6qs+IkORQJOTX01OW6Kb+WLIl0TD4eRfIUpM=; b=Whadm/9FoDw1zJhpvIoeqsTKi7wpIPrtaQTmydqu1AcdbHLBgx1z6IPVO7Vospnhpc y/vgMTbXs/v9Q0hanojBIEJgsl4PT4a7aBYWZghy0WLaXDo4QVAWOie+FtQz6wcrWL+4 MMSl0Z/BR86Dh7vOcplSAPQLbnvVUDHQZkBjw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HBxhfXHNwlAYLKpLlZ9hDjNdNlE9Gl3mdM7Baq2lZkvSGr4cSBfXkeeKQJe7Fotefp ATcLHr5K7I3MxU45uczD2YeKFYy1aw1iTbKTTsA3ZEnp1y0OZIM3wzkQ7jvSaTjlM56G T3VktInfrncQOfDzZQcw+Dga6k9aF5wuNwWNc= MIME-Version: 1.0 Received: by 10.213.109.92 with SMTP id i28mr1431521ebp.63.1265532079604; Sun, 07 Feb 2010 00:41:19 -0800 (PST) In-Reply-To: <4B6DE491.8010901@errno.com> References: <2d3b7e441002060028i5b1fc665p92b10fa21d77284d@mail.gmail.com> <8F5F80D8-A262-49F4-B580-781A44D3190D@freebsd.org> <2d3b7e441002060658h49712201m464dac80208db369@mail.gmail.com> <4B6DE491.8010901@errno.com> Date: Sun, 7 Feb 2010 09:41:19 +0100 Message-ID: <2d3b7e441002070041waa8f968le66328ebeb7b163d@mail.gmail.com> From: Alexander Egorenkov To: Sam Leffler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Rui Paulo Subject: Re: HT rate set in net80211 not changeable for STA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 08:41:21 -0000 On Sat, Feb 6, 2010 at 10:52 PM, Sam Leffler wrote: > The advertised rate set should be initially set according to the > capabilities of the device. There were no devices > 2x2 when I wrote the > code so MCS15 is the max. To support such devices you need to do more than > just grow the rateset. > But my device is a 2T2R device and supports MCS32 (HT duplicate mode). From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 08:53:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96245106566B for ; Sun, 7 Feb 2010 08:53:38 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay2-bcrtfl2.verio.net (relay2-bcrtfl2.verio.net [131.103.218.177]) by mx1.freebsd.org (Postfix) with ESMTP id 6642B8FC0A for ; Sun, 7 Feb 2010 08:53:38 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (unknown [198.87.7.164]) by relay2-bcrtfl2.verio.net (Postfix) with ESMTP id 41ACA1FF0BA6 for ; Sun, 7 Feb 2010 03:53:37 -0500 (EST) thread-index: Acqn0wkIg2EnG+uiTxiaNVw4iBFSUw== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.0.33]) by iad-wprd-xchw01.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 7 Feb 2010 03:53:35 -0500 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Sun, 07 Feb 2010 02:53:31 +0000 Content-Transfer-Encoding: 7bit Date: Sun, 7 Feb 2010 02:53:31 -0600 From: "David DeSimone" Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 To: Message-ID: <20100207085330.GN5172@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20100206.191153.401093655925072575.imp@bsdimp.com> <4B6E2B40.1070405@elischer.org> <20100206.212042.925196285631243946.imp@bsdimp.com> <4B6E50A3.6080804@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4B6E50A3.6080804@elischer.org> Precedence: bulk User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 07 Feb 2010 08:53:35.0437 (UTC) FILETIME=[0866BFD0:01CAA7D3] Subject: Re: How does rpc.lockd know where to send a request X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 08:53:38 -0000 Julian Elischer wrote: > > try swapping the addresses on the interface. The original posting said that 10.0.0.99 is an address assigned to a CARP interface, not an alias assigned to an ethernet interface. As such, both are primary addresses on their respective interfaces, so there is nothing to swap. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 12:48:43 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E90B01065670 for ; Sun, 7 Feb 2010 12:48:43 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 733A58FC0A for ; Sun, 7 Feb 2010 12:48:43 +0000 (UTC) Received: by fxm24 with SMTP id 24so1646921fxm.3 for ; Sun, 07 Feb 2010 04:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=43hKZugr6h5ma7qnpbsPURBozxgKu0F4S+Dzye4mua8=; b=wg73fE1HRNMoHnMkDAMIU/UmDoeNK0XZED0ApMJxktHO4x2O/QEe9XAEH6xsONpseo yuAHs3wBvFHE+2esor4WBNzd9B2scHHrF+i/kdTG3LP7W6FlMNdWe9Hlegdj9k76RBcY 6TPEmNXmTMsukRzuu+zqILEccNvZLuuATteto= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Es4pby1o9HD9ruy1u32G8o2RWt+9u8sy4II/N1b7I9ZgPxxlTt+KgGK2a66QC5Ba9x 4CmBnX1YmS5wAoXdKQ8vGG5uKkBvhOdS3guRhM6M7urVvQ7xF464Cs+MRjaweEIeRcxC BmJgMJ+MWOj+W6HxrOa+2bs4xVWoK4aAyLiKo= Received: by 10.87.62.1 with SMTP id p1mr1344538fgk.42.1265546921580; Sun, 07 Feb 2010 04:48:41 -0800 (PST) Received: from ?10.0.10.4? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 13sm1439934fxm.13.2010.02.07.04.48.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 07 Feb 2010 04:48:40 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <2d3b7e441002070041waa8f968le66328ebeb7b163d@mail.gmail.com> Date: Sun, 7 Feb 2010 12:48:39 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7209E281-4B47-40BF-859C-B6583AD69921@freebsd.org> References: <2d3b7e441002060028i5b1fc665p92b10fa21d77284d@mail.gmail.com> <8F5F80D8-A262-49F4-B580-781A44D3190D@freebsd.org> <2d3b7e441002060658h49712201m464dac80208db369@mail.gmail.com> <4B6DE491.8010901@errno.com> <2d3b7e441002070041waa8f968le66328ebeb7b163d@mail.gmail.com> To: Alexander Egorenkov X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org Subject: Re: HT rate set in net80211 not changeable for STA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 12:48:44 -0000 On 7 Feb 2010, at 08:41, Alexander Egorenkov wrote: > But my device is a 2T2R device and supports MCS32 (HT duplicate = mode). I wouldn't worry about MCS 32 for now. If you can get your device to do = MCS 15, you're probably in a good shape already. MCS 32 would just come = as a bonus and I'm not sure it's worth doing it now since it's not that = common. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 13:05:23 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24E44106566C; Sun, 7 Feb 2010 13:05:23 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F0A8F8FC0A; Sun, 7 Feb 2010 13:05:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o17D5MEU016983; Sun, 7 Feb 2010 13:05:22 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o17D5MH2016979; Sun, 7 Feb 2010 13:05:22 GMT (envelope-from linimon) Date: Sun, 7 Feb 2010 13:05:22 GMT Message-Id: <201002071305.o17D5MH2016979@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143627: [ieee80211] [panic] A bug in ht_send_action_ba_addba causes net80211 to send malformed ADDBA response frames X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 13:05:23 -0000 Old Synopsis: [ieee80211] A bug in ht_send_action_ba_addba causes net80211 to send malformed ADDBA response frames New Synopsis: [ieee80211] [panic] A bug in ht_send_action_ba_addba causes net80211 to send malformed ADDBA response frames Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 7 13:04:54 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143627 From owner-freebsd-net@FreeBSD.ORG Sun Feb 7 21:02:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20EBE106568D; Sun, 7 Feb 2010 21:02:00 +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 7CD3C8FC12; Sun, 7 Feb 2010 21:01:59 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id o17L1uAx030918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2010 13:01:57 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4B6F2A44.3010205@errno.com> Date: Sun, 07 Feb 2010 13:01:56 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexander Egorenkov References: <2d3b7e441002060028i5b1fc665p92b10fa21d77284d@mail.gmail.com> <8F5F80D8-A262-49F4-B580-781A44D3190D@freebsd.org> <2d3b7e441002060658h49712201m464dac80208db369@mail.gmail.com> <4B6DE491.8010901@errno.com> <2d3b7e441002070041waa8f968le66328ebeb7b163d@mail.gmail.com> In-Reply-To: <2d3b7e441002070041waa8f968le66328ebeb7b163d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org, Rui Paulo Subject: Re: HT rate set in net80211 not changeable for STA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 21:02:00 -0000 Alexander Egorenkov wrote: > > > On Sat, Feb 6, 2010 at 10:52 PM, Sam Leffler > wrote: > > The advertised rate set should be initially set according to the > capabilities of the device. There were no devices > 2x2 when I > wrote the code so MCS15 is the max. To support such devices you > need to do more than just grow the rateset. > > > But my device is a 2T2R device and supports MCS32 (HT duplicate mode). > MCS32 is special; as you indicate it forces duplicate signal on the upper and lower channels in HT40. There is no support for MCS32 in net80211. Sam From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 02:10:04 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2229D106566B for ; Mon, 8 Feb 2010 02:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 120068FC13 for ; Mon, 8 Feb 2010 02:10:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o182A3Ca084371 for ; Mon, 8 Feb 2010 02:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o182A30H084370; Mon, 8 Feb 2010 02:10:03 GMT (envelope-from gnats) Date: Mon, 8 Feb 2010 02:10:03 GMT Message-Id: <201002080210.o182A30H084370@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Max Laier Cc: Subject: Re: kern/143622: [pfil] [patch] unlock pfil lock while calling firewall hooks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Max Laier List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 02:10:04 -0000 The following reply was made to PR kern/143622; it has been noted by GNATS. From: Max Laier To: bug-followup@freebsd.org, gleb.kurtsou@gmail.com Cc: Subject: Re: kern/143622: [pfil] [patch] unlock pfil lock while calling firewall hooks Date: Mon, 8 Feb 2010 02:55:41 +0100 Please no. The rmlock is extremely lightweight (PCPU) in contrast to taking and dropping the reference (atomic ops). In addition, the read lock does not mandate any locking model on the firewall and allows recursion, as well. Furthermore, there are many more locks that might be held from up/down the stack - pfil consumer must not sleep (regardless of the pfil lock) and should avoid recursion as much as possible. Changing the pfil lock will not change that ... nor does does changing any other locks in the stack ... it's just the way it is with a layered design. Regards, Max From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 11:07:01 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75C12106568D for ; Mon, 8 Feb 2010 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 644488FC20 for ; Mon, 8 Feb 2010 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o18B71ED087457 for ; Mon, 8 Feb 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o18B70C0087455 for freebsd-net@FreeBSD.org; Mon, 8 Feb 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Feb 2010 11:07:00 GMT Message-Id: <201002081107.o18B70C0087455@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 11:07:01 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/143627 net [ieee80211] [panic] A bug in ht_send_action_ba_addba c o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143573 net [em] em(4) NIC crashes intermittently o kern/143285 net [em] [regression] jumbo frames broken in 8.0 o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143046 net [mxge] [panic] panics since mxge(4) update o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142766 net [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 o bin/142547 net wpa_supplicant(8) drops connection on key renegotiatio o kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo o kern/141646 net [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged fr o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140970 net [bce] The two NetXtreme II BCM5709S NICs on our HP Bl4 o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140684 net [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc s kern/140597 net [request] implement Lost Retransmission Detection o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/139761 net [bce] bce driver on IBM HS22 [No PHY found on Child MI o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [em] FreeBSD 7 multicast routing problem f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o bin/82185 net [patch] ndp(8) can delete the incorrect entry s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 392 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 11:18:52 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E8531065670; Mon, 8 Feb 2010 11:18:52 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 959168FC14; Mon, 8 Feb 2010 11:18:51 +0000 (UTC) Received: by ewy3 with SMTP id 3so3343176ewy.13 for ; Mon, 08 Feb 2010 03:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=P5/IJcO1phr223/3IFRng2/vV7F/P4cft8Wsxadfkxs=; b=JXuXO8A6XyUf3qFaFEXBYtg3sUS5ZYrEaDE0mI8c6Gkfv1RLwW3ltqWVGO3oozneJn AXU99D8Z6u8VmuQyIoSG1+5xMj+EOC68atVjsO+7y5lL0fcofGYhbly5wOuGYiltxuuO XereLqYPxeorgbiVwZiLNjvz0zIHYIorygATY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=EtBFU8h33XsckVxUl2qSfHyszz1e3KE6KdH6TuHOvpS9p06R0lHsX99q4a8Il8Ui3B weutldrExF0zHllUWUaa3zdiuFEVdN7ia3covnIlP4JuEDarK4tX8td4+Bkp32AB+jpS TmAinbErc3wPFmNKpM6+DqUvU1cEXYHbYx2DA= MIME-Version: 1.0 Received: by 10.213.72.11 with SMTP id k11mr2572542ebj.38.1265627930562; Mon, 08 Feb 2010 03:18:50 -0800 (PST) Date: Mon, 8 Feb 2010 11:18:50 +0000 Message-ID: <3a142e751002080318g2e77999v73dd4d671c5a578@mail.gmail.com> From: Paul B Mahol To: fbsdlists@gmail.com, lothlorien@pvu.msk.ru Content-Type: text/plain; charset=ISO-8859-1 Cc: questions@freebsd.org, net@freebsd.org Subject: NDISulator bug on amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 11:18:52 -0000 On 1/16/10, Paul B Mahol wrote: > On 1/11/10, Paul B Mahol wrote: >> On 1/11/10, Bob Johnson wrote: >>> On 1/9/10, Paul B Mahol wrote: >>>> On 12/16/09, Bob Johnson wrote: >>>>> I'm using an ExpressCard for wireless networking because there seems >>>>> to be no driver for the internal card in my laptop (and NDIS panics >>>>> the system). The Expresscard shows up as a PCI device and works fine, >>>> >>>> How are you using NDIS and when system panic what is displayed? >>> >>> I tried to use ndisgen with the internal Dell 1397 card. I don't have >>> details available right now, although if you need them I can try it >>> again. When I did the kldload the system spit out error messages about >>> unknown symbols and then panic-ed. I did some searching of the >>> archives and found a message describing the same symptoms, and the >>> response posted was that it indicated that the Windows driver made API >>> calls that were not implemented in the NDIS wrapper. >>> >>> This was a 64-bit Windows driver and an amd64 FreeBSD system. Similar >>> results in both >>> FreeBSD 7.2 and 8.0. >>> >>> It appears that kern/132672 is describing the same or a very similar >>> issue. It also suggests that there is a more fundamental problem than >>> the unrecognized symbols. >>> >>> I can try to reproduce the problem tonight if you want me to. >>> >>> Thanks, >> >> If you have debug kernel, then make breakpoint for MSCALL2 (kldload >> ndis.ko before that): `break MSCALL2' > > Should be `break w86_64_call2' >> Then load ndisgen module. >> >> Then single step it with `s' it should panic after few steps. >> At least this is issue I'm experiencing on amd64, it fails in >> DriverEntry(). > > with the same virtual address as in kern/132672. I fixed bug that caused panic on amd64 in DriverEntry(). Code is available from here: www.gitorious.org/NDISulator From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 11:29:26 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 113DC106566B for ; Mon, 8 Feb 2010 11:29:26 +0000 (UTC) (envelope-from siquijorphilips@gmail.com) Received: from mail-pz0-f194.google.com (mail-pz0-f194.google.com [209.85.222.194]) by mx1.freebsd.org (Postfix) with ESMTP id E23FA8FC18 for ; Mon, 8 Feb 2010 11:29:25 +0000 (UTC) Received: by pzk32 with SMTP id 32so4208916pzk.27 for ; Mon, 08 Feb 2010 03:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=LtKC4NweRWYmx2GXNo5b6UQHphFfh23U5Ae82jVTJgg=; b=eDxGbE/m6zmPB54RB0d3481rl/ouZPLY/3CucpI/JUXHJAL1KzUZgX9LT+0mBQiGfF mQ8ZmWaEcZwbtFRRsS+8gISzMSggDm4CZRr3xh7xE7KuOKJ8Xv+7GOhta6bCdjriK2Ld Eo97VhmnUJHcdENEtO7kCjS48O/froZVJBIYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HSY9M2mwjO1qCtw4RgknxdLmVJj2VHvrxH3GQds5lhCxhh4B/1doaYV0XsY2ALJZY6 jo77uwq8N5B74D4UMcaQjb86n4o2fcA8CIyBUx78VrPMay6B7Js008pkyfrfN5vD61PQ zSe9Rp/FoR2g4yCVEtcfPVjOWmNm5x4Y9YTkA= MIME-Version: 1.0 Received: by 10.142.1.1 with SMTP id 1mr4178459wfa.108.1265628565469; Mon, 08 Feb 2010 03:29:25 -0800 (PST) Date: Mon, 8 Feb 2010 19:29:25 +0800 Message-ID: From: Siquijor Philips To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Intel GigE NIC Issue on IPv6 DAD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 11:29:26 -0000 Hi, I'm currently doing IPv6 conformance testing with FreeBSD-7.1 RELEASE however I've encountered DAD timing issue on Intel Gigabit NICs with em(4) driver. I configure several tweaks on net.inet6.ip6.dad_count such as 2 seconds, 3 seconds and 4 seconds just to get the specific DAD timing on each test item. There are 29 test items for a router category on RFC 4862 (IPv6 Stateless Address Autoconfiguration) and some items passed on 4 seconds, others passed on 1 second (default DAD configuration) while others are not consistent (sometimes passed on 4 seconds and if tested again, it will satisfy on 1 second). With FastE NICs such as Intel 10/100 with fxp(4) driver and Via Rhine 10/100 with vr(4) driver, these cards just works fine using the default net.inet6.ip6.dad_count=1 (1 second) without this DAD timing problem. So my concern is, why does Intel GigE NICs with em(4) driver behave this way? I have tested 2 Intel GigE NICs with different chipsets, 82541and 82574L and it does the same behavior? Is this a bug or something? Regards, Siquijor From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 15:39:50 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D90F1106568F; Mon, 8 Feb 2010 15:39:50 +0000 (UTC) (envelope-from balajig81@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 782F58FC1C; Mon, 8 Feb 2010 15:39:50 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so729442qwd.7 for ; Mon, 08 Feb 2010 07:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=0pyEJb2hcjTtqkFpxI4/2uqq0XnUXkhmkx84pCbLvaA=; b=CP0wQLO4tm+o2f/17N/8z9M6MehHKBnlB9F7Q7DHHR3lXM0v1P2Xrn7Dbf1KFPfYRv BppxpSZpysrQxhd/crETtn+WCte0y4JfNQMSZMEME1eiGMfL+Oa2ue9t9AeeP/A1TlYo 580AjFbum9zs8o9eWBxalMD/wPc+/TmSnfMkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=sMTWxBNhbOGtGXt6+W5S2nAzmlqKroKsw865nDFMXSSkVvjbP89wMTXNOhF2jSZ8We 7O4fexkPyE6YgsH2mrZ8cObuE4ZEuKYYseYrjE8tDmSySLQ1RQG3OfZYPuAQtwiurzJn eJM+kpYyH6AqxtSO9o7W00Nvu9wXzpkhCpO2I= MIME-Version: 1.0 Received: by 10.142.1.36 with SMTP id 36mr4366276wfa.7.1265643589129; Mon, 08 Feb 2010 07:39:49 -0800 (PST) Date: Mon, 8 Feb 2010 21:09:49 +0530 Message-ID: <6dd1343e1002080739m38f4deffr604c71e5036389a4@mail.gmail.com> From: Balaji G To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=00504502ad118ad7e3047f189c33 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Qing Li , "Li, Qing" Subject: [PATCH] net:: ECMP Phase 1 Fixes for FreeBSD 7.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: Mon, 08 Feb 2010 15:39:50 -0000 --00504502ad118ad7e3047f189c33 Content-Type: text/plain; charset=UTF-8 Hi Everybody Please find attached the patch files which contains the backported code for ECMP for FreeBSD 7.2. I have back ported the code from 8.0. I have done some basic testing with these patches rolled in. These are the phase 1 fixes and i would continue to work on this and back port few other stuff too. It would be great if someone could roll in this to 7.2, test it and give me their valuable feedback. This is my first Patch for FreeBSD community and i am really excited about this and look forward to it. Thanks for your time. Cheers, - Balaji --00504502ad118ad7e3047f189c33 Content-Type: text/x-patch; charset=US-ASCII; name="ecmp_patch1.patch" Content-Disposition: attachment; filename="ecmp_patch1.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g5ffexhn0 ZGlmZiAtdSAtciAvaG9tZS9iYWxhamkvQ29kZXMvRnJlZUJTRC83LjIuMC83LjIuMF91bm1vZGlm aWVkLzcuMi4wL3N5cy9uZXQvcmFkaXguYyBuZXQvcmFkaXguYwotLS0gL2hvbWUvYmFsYWppL0Nv ZGVzL0ZyZWVCU0QvNy4yLjAvNy4yLjBfdW5tb2RpZmllZC83LjIuMC9zeXMvbmV0L3JhZGl4LmMJ MjAxMC0wMi0wNCAyMjo0MDoyOS4wMDAwMDAwMDAgKzA1MzAKKysrIG5ldC9yYWRpeC5jCTIwMTAt MDItMDcgMTY6MDY6NTYuMDUzNjg3MzExICswNTMwCkBAIC00OCw2ICs0OCwxMCBAQAogI2luY2x1 ZGUgPG5ldC9yYWRpeC5oPgogI2VuZGlmCiAKKy8qIEVDTVAgQ2hhbmdlcyBCZWdpbiAqLworI2lu Y2x1ZGUgPG5ldC9yYWRpeF9tcGF0aC5oPgorLyogRUNNUCBDaGFuZ2VzIEVuZCAqLworCiBzdGF0 aWMgaW50CXJuX3dhbGt0cmVlX2Zyb20oc3RydWN0IHJhZGl4X25vZGVfaGVhZCAqaCwgdm9pZCAq YSwgdm9pZCAqbSwKIAkJICAgIHdhbGt0cmVlX2ZfdCAqZiwgdm9pZCAqdyk7CiBzdGF0aWMgaW50 IHJuX3dhbGt0cmVlKHN0cnVjdCByYWRpeF9ub2RlX2hlYWQgKiwgd2Fsa3RyZWVfZl90ICosIHZv aWQgKik7CkBAIC02MzAsNiArNjM0LDIyIEBACiAJc2F2ZWRfdHQgPSB0dCA9IHJuX2luc2VydCh2 LCBoZWFkLCAma2V5ZHVwbGljYXRlZCwgdHJlZW5vZGVzKTsKIAlpZiAoa2V5ZHVwbGljYXRlZCkg ewogCQlmb3IgKHQgPSB0dDsgdHQ7IHQgPSB0dCwgdHQgPSB0dC0+cm5fZHVwZWRrZXkpIHsKKwor LyogRUNNUCBDaGFuZ2VzIEJlZ2luICovCisJCQkvKiBwZXJtaXQgbXVsdGlwYXRoLCBpZiBlbmFi bGVkIGZvciB0aGUgZmFtaWx5ICovCisJCQlpZiAocm5fbXBhdGhfY2FwYWJsZShoZWFkKSAmJiBu ZXRtYXNrID09IHR0LT5ybl9tYXNrKSB7CisJCQkJLyoKKwkJCQkgKiBnbyBkb3duIHRvIHRoZSBl bmQgb2YgbXVsdGlwYXRocywgc28gdGhhdAorCQkJCSAqIG5ldyBlbnRyeSBnb2VzIGludG8gdGhl IGVuZCBvZiBybl9kdXBlZGtleQorCQkJCSAqIGNoYWluLgorCQkJCSAqLworCQkJCWRvIHsKKwkJ CQkJdCA9IHR0OworCQkJCQl0dCA9IHR0LT5ybl9kdXBlZGtleTsKKwkJCQl9IHdoaWxlICh0dCAm JiB0LT5ybl9tYXNrID09IHR0LT5ybl9tYXNrKTsKKwkJCQlicmVhazsKKwkJCX0KKy8qIEVDTVAg Q2hhbmdlcyBFbmQgKi8KIAkJCWlmICh0dC0+cm5fbWFzayA9PSBuZXRtYXNrKQogCQkJCXJldHVy biAoMCk7CiAJCQlpZiAobmV0bWFzayA9PSAwIHx8CmRpZmYgLXUgLXIgL2hvbWUvYmFsYWppL0Nv ZGVzL0ZyZWVCU0QvNy4yLjAvNy4yLjBfdW5tb2RpZmllZC83LjIuMC9zeXMvbmV0L3JhZGl4X21w YXRoLmMgbmV0L3JhZGl4X21wYXRoLmMKLS0tIC9ob21lL2JhbGFqaS9Db2Rlcy9GcmVlQlNELzcu Mi4wLzcuMi4wX3VubW9kaWZpZWQvNy4yLjAvc3lzL25ldC9yYWRpeF9tcGF0aC5jCTIwMTAtMDIt MDUgMDg6MzA6NTIuMDAwMDAwMDAwICswNTMwCisrKyBuZXQvcmFkaXhfbXBhdGguYwkyMDEwLTAy LTA2IDE4OjAyOjMxLjUwNzk0MzY3OSArMDUzMApAQCAtNTQsNyArNTQsNyBAQAogLyoKICAqIGdp dmUgc29tZSBqaXR0ZXIgdG8gaGFzaCwgdG8gYXZvaWQgc3luY2hyb25pemF0aW9uIGJldHdlZW4g cm91dGVycwogICovCi1zdGF0aWMgdWludDMyX3QgaGFzaGppdHRlcjsKKy8qIHN0YXRpYyB1aW50 MzJfdCBoYXNoaml0dGVyOyAqLwogCiBpbnQKIHJuX21wYXRoX2NhcGFibGUoc3RydWN0IHJhZGl4 X25vZGVfaGVhZCAqcm5oKQpAQCAtMzIwLDggKzMyMCw5IEBACiAjZW5kaWYKIAogZXh0ZXJuIGlu dAlpbjZfaW5pdGhlYWQodm9pZCAqKmhlYWQsIGludCBvZmYpOwotZXh0ZXJuIGludAlpbl9pbml0 aGVhZCh2b2lkICoqaGVhZCwgaW50IG9mZik7CitleHRlcm4gaW50CWluX2ludGhlYWQodm9pZCAq KmhlYWQsIGludCBvZmYpOwogCisjaWYgMAogI2lmZGVmIElORVQKIGludAogcm40X21wYXRoX2lu aXRoZWFkKHZvaWQgKipoZWFkLCBpbnQgb2ZmKQpAQCAtMzUyLDUgKzM1Myw2IEBACiAJfSBlbHNl CiAJCXJldHVybiAwOwogfQorI2VuZGlmCiAKICNlbmRpZgpPbmx5IGluIG5ldDogcmFkaXhfbXBh dGguaApkaWZmIC11IC1yIC9ob21lL2JhbGFqaS9Db2Rlcy9GcmVlQlNELzcuMi4wLzcuMi4wX3Vu bW9kaWZpZWQvNy4yLjAvc3lzL25ldC9yb3V0ZS5jIG5ldC9yb3V0ZS5jCi0tLSAvaG9tZS9iYWxh amkvQ29kZXMvRnJlZUJTRC83LjIuMC83LjIuMF91bm1vZGlmaWVkLzcuMi4wL3N5cy9uZXQvcm91 dGUuYwkyMDEwLTAyLTA0IDIyOjQwOjI5LjAwMDAwMDAwMCArMDUzMAorKysgbmV0L3JvdXRlLmMJ MjAxMC0wMi0wNyAxNjowNTo0NC40NDI5MzU1OTcgKzA1MzAKQEAgLTg4Niw2ICs4ODYsMTEzIEBA CiAJcmV0dXJuIChydHJlcXVlc3QxX2ZpYihyZXEsIGluZm8sIHJldF9ucnQsIDApKTsKIH0KIAor LyogRUNNUCBDaGFuZ2VzIEJlZ2luICovCitzdGF0aWMgaW50Citybl9tcGF0aF91cGRhdGUoaW50 IHJlcSwgc3RydWN0IHJ0X2FkZHJpbmZvICppbmZvLAorICAgIHN0cnVjdCByYWRpeF9ub2RlX2hl YWQgKnJuaCwgc3RydWN0IHJ0ZW50cnkgKipyZXRfbnJ0KQoreworCS8qCisJICogaWYgd2UgZ290 IG11bHRpcGF0aCByb3V0ZXMsIHdlIHJlcXVpcmUgdXNlcnMgdG8gc3BlY2lmeQorCSAqIGEgbWF0 Y2hpbmcgUlRBWF9HQVRFV0FZLgorCSAqLworCXN0cnVjdCBydGVudHJ5ICpydCwgKnJ0byA9IE5V TEw7CisJcmVnaXN0ZXIgc3RydWN0IHJhZGl4X25vZGUgKnJuOworCWludCBlcnJvciA9IDA7CisK KwlybiA9IHJuaC0+cm5oX21hdGNoYWRkcihkc3QsIHJuaCk7CisJaWYgKHJuID09IE5VTEwpCisJ CXJldHVybiAoRVNSQ0gpOworCXJ0byA9IHJ0ID0gUk5UT1JUKHJuKTsKKwlydCA9IHJ0X21wYXRo X21hdGNoZ2F0ZShydCwgZ2F0ZXdheSk7CisJaWYgKHJ0ID09IE5VTEwpCisJCXJldHVybiAoRVNS Q0gpOworCS8qCisJICogdGhpcyBpcyB0aGUgZmlyc3QgZW50cnkgaW4gdGhlIGNoYWluCisJICov CisJaWYgKHJ0byA9PSBydCkgeworCQlybiA9IHJuX21wYXRoX25leHQoKHN0cnVjdCByYWRpeF9u b2RlICopcnQpOworCQkvKgorCQkgKiB0aGVyZSBpcyBhbm90aGVyIGVudHJ5LCBub3cgaXQncyBh Y3RpdmUKKwkJICovCisJCWlmIChybikgeworCQkJcnRvID0gUk5UT1JUKHJuKTsKKwkJCVJUX0xP Q0socnRvKTsKKwkJCXJ0by0+cnRfZmxhZ3MgfD0gUlRGX1VQOworCQkJUlRfVU5MT0NLKHJ0byk7 CisJCX0gZWxzZSBpZiAocnQtPnJ0X2ZsYWdzICYgUlRGX0dBVEVXQVkpIHsKKwkJCS8qCisJCQkg KiBGb3IgZ2F0ZXdheSByb3V0ZXMsIHdlIG5lZWQgdG8gCisJCQkgKiBtYWtlIHN1cmUgdGhhdCB3 ZSB3ZSBhcmUgZGVsZXRpbmcKKwkJCSAqIHRoZSBjb3JyZWN0IGdhdGV3YXkuIAorCQkJICogcnRf bXBhdGhfbWF0Y2hnYXRlKCkgZG9lcyBub3QgCisJCQkgKiBjaGVjayB0aGUgY2FzZSB3aGVuIHRo ZXJlIGlzIG9ubHkKKwkJCSAqIG9uZSByb3V0ZSBpbiB0aGUgY2hhaW4uICAKKwkJCSAqLworCQkJ aWYgKGdhdGV3YXkgJiYKKwkJCSAgICAocnQtPnJ0X2dhdGV3YXktPnNhX2xlbiAhPSBnYXRld2F5 LT5zYV9sZW4gfHwKKwkJCQltZW1jbXAocnQtPnJ0X2dhdGV3YXksIGdhdGV3YXksIGdhdGV3YXkt PnNhX2xlbikpKQorCQkJCWVycm9yID0gRVNSQ0g7CisJCQllbHNlIHsKKwkJCQkvKgorCQkJCSAq IHJlbW92ZSBmcm9tIHRyZWUgYmVmb3JlIHJldHVybmluZyBpdAorCQkJCSAqIHRvIHRoZSBjYWxs ZXIKKwkJCQkgKi8KKwkJCQlybiA9IHJuaC0+cm5oX2RlbGFkZHIoZHN0LCBuZXRtYXNrLCBybmgp OworCQkJCUtBU1NFUlQocnQgPT0gUk5UT1JUKHJuKSwgKCJyYWRpeCBub2RlIGRpc2FwcGVhcmVk IikpOworCQkJCWdvdG8gZ3dkZWxldGU7CisJCQl9CisJCQkKKwkJfQorCQkvKgorCQkgKiB1c2Ug dGhlIG5vcm1hbCBkZWxldGUgY29kZSB0byByZW1vdmUKKwkJICogdGhlIGZpcnN0IGVudHJ5CisJ CSAqLworCQlpZiAocmVxICE9IFJUTV9ERUxFVEUpIAorCQkJZ290byBub25kZWxldGU7CisKKwkJ ZXJyb3IgPSBFTk9FTlQ7CisJCWdvdG8gZG9uZTsKKwl9CisJCQorCS8qCisJICogaWYgdGhlIGVu dHJ5IGlzIDJuZCBhbmQgb24gdXAKKwkgKi8KKwlpZiAoKHJlcSA9PSBSVE1fREVMRVRFKSAmJiAh cnRfbXBhdGhfZGVsZHVwKHJ0bywgcnQpKQorCQlwYW5pYyAoInJ0cmVxdWVzdDE6IHJ0X21wYXRo X2RlbGR1cCIpOworZ3dkZWxldGU6CisJUlRfTE9DSyhydCk7CisJUlRfQUREUkVGKHJ0KTsKKwlp ZiAocmVxID09IFJUTV9ERUxFVEUpIHsKKwkJcnQtPnJ0X2ZsYWdzICY9IH5SVEZfVVA7CisJCS8q CisJCSAqIE9uZSBtb3JlIHJ0ZW50cnkgZmxvYXRpbmcgYXJvdW5kIHRoYXQgaXMgbm90CisJCSAq IGxpbmtlZCB0byB0aGUgcm91dGluZyB0YWJsZS4gcnR0cmFzaCB3aWxsIGJlIGRlY3JlbWVudGVk CisJCSAqIHdoZW4gUlRGUkVFKHJ0KSBpcyBldmVudHVhbGx5IGNhbGxlZC4KKwkJICovCisJCXJ0 dHJhc2grKzsKKwl9CisJCitub25kZWxldGU6CisJaWYgKHJlcSAhPSBSVE1fREVMRVRFKQorCQlw YW5pYygidW5yZWNvZ25pemVkIHJlcXVlc3QgJWQiLCByZXEpOworCQorCisJLyoKKwkgKiBJZiB0 aGUgY2FsbGVyIHdhbnRzIGl0LCB0aGVuIGl0IGNhbiBoYXZlIGl0LAorCSAqIGJ1dCBpdCdzIHVw IHRvIGl0IHRvIGZyZWUgdGhlIHJ0ZW50cnkgYXMgd2Ugd29uJ3QgYmUKKwkgKiBkb2luZyBpdC4K KwkgKi8KKwlpZiAocmV0X25ydCkgeworCQkqcmV0X25ydCA9IHJ0OworCQlSVF9VTkxPQ0socnQp OworCX0gZWxzZQorCQlSVEZSRUVfTE9DS0VEKHJ0KTsKK2RvbmU6CisJcmV0dXJuIChlcnJvcik7 Cit9CisvKiBFQ01QIENoYW5nZXMgRW5kICovCisKKwogaW50CiBydHJlcXVlc3QxX2ZpYihpbnQg cmVxLCBzdHJ1Y3QgcnRfYWRkcmluZm8gKmluZm8sIHN0cnVjdCBydGVudHJ5ICoqcmV0X25ydCwK IAkJCQl1X2ludCBmaWJudW0pCkBAIC05MjMsNiArMTAzMCwxOSBAQAogCX0KIAlzd2l0Y2ggKHJl cSkgewogCWNhc2UgUlRNX0RFTEVURToKKworLyogRUNNUCBDaGFuZ2VzIEJlZ2luICovCisJCWlm IChybl9tcGF0aF9jYXBhYmxlKHJuaCkpIHsKKwkJCWVycm9yID0gcm5fbXBhdGhfdXBkYXRlKHJl cSwgaW5mbywgcm5oLCByZXRfbnJ0KTsKKwkJCS8qCisJCQkgKiAiYmFkIiBob2xkcyB0cnVlIGZv ciB0aGUgc3VjY2VzcyBjYXNlCisJCQkgKiBhcyB3ZWxsCisJCQkgKi8KKwkJCWlmIChlcnJvciAh PSBFTk9FTlQpCisJCQkJZ290byBiYWQ7CisJCX0KKy8qIEVDTVAgQ2hhbmdlcyBFbmQgKi8KKwog CQkvKgogCQkgKiBSZW1vdmUgdGhlIGl0ZW0gZnJvbSB0aGUgdHJlZSBhbmQgcmV0dXJuIGl0Lgog CQkgKiBDb21wbGFpbiBpZiBpdCBpcyBub3QgdGhlcmUgYW5kIGRvIG5vIG1vcmUgcHJvY2Vzc2lu Zy4KQEAgLTEwNDYsNiArMTE2NiwyMCBAQAogCQlydC0+cnRfaWZhID0gaWZhOwogCQlydC0+cnRf aWZwID0gaWZhLT5pZmFfaWZwOwogCisJLyogRUNNUCBDaGFuZ2VzIEJlZ2luICovCisJCS8qIGRv IG5vdCBwZXJtaXQgZXhhY3RseSB0aGUgc2FtZSBkc3QvbWFzay9ndyBwYWlyICovCisJCWlmIChy bl9tcGF0aF9jYXBhYmxlKHJuaCkgJiYKKwkJCXJ0X21wYXRoX2NvbmZsaWN0KHJuaCwgcnQsIG5l dG1hc2spKSB7CisJCQlpZiAocnQtPnJ0X2lmYSkgeworCQkJCUlGQUZSRUUocnQtPnJ0X2lmYSk7 CisJCQl9CisJCQlGcmVlKHJ0X2tleShydCkpOworCQkJUlRfTE9DS19ERVNUUk9ZKHJ0KTsKKwkJ CXVtYV96ZnJlZShydHpvbmUsIHJ0KTsKKwkJCXNlbmRlcnIoRUVYSVNUKTsKKwkJfQorCS8qIEVD TVAgQ2hhbmdlcyAgRW5kICovCisKIAkJLyogWFhYIG10dSBtYW5pcHVsYXRpb24gd2lsbCBiZSBk b25lIGluIHJuaF9hZGRhZGRyIC0tIGl0b2p1biAqLwogCQlybiA9IHJuaC0+cm5oX2FkZGFkZHIo bmRzdCwgbmV0bWFzaywgcm5oLCBydC0+cnRfbm9kZXMpOwogCQlpZiAocm4gPT0gTlVMTCkgewpA QCAtMTQ1Niw2ICsxNTkwLDI5IEBACiAJCQkJLyogdGhpcyB0YWJsZSBkb2Vzbid0IGV4aXN0IGJ1 dCBvdGhlcnMgbWlnaHQgKi8KIAkJCQljb250aW51ZTsKIAkJCVJBRElYX05PREVfSEVBRF9MT0NL KHJuaCk7CisvKiBFQ01QIENoYW5nZXMgQmVnaW4gKi8KKwkJCWlmIChybl9tcGF0aF9jYXBhYmxl KHJuaCkpIHsKKworCQkJCXJuID0gcm5oLT5ybmhfbWF0Y2hhZGRyKGRzdCwgcm5oKTsKKwkJCQlp ZiAocm4gPT0gTlVMTCkgCisJCQkJCWVycm9yID0gRVNSQ0g7CisJCQkJZWxzZSB7CisJCQkJCXJ0 ID0gUk5UT1JUKHJuKTsKKwkJCQkJLyoKKwkJCQkJICogZm9yIGludGVyZmFjZSByb3V0ZSB0aGUK KwkJCQkJICogcnQtPnJ0X2dhdGV3YXkgaXMgc29ja2FkZHJfaW50ZgorCQkJCQkgKiBmb3IgY2xv bmluZyBBUlAgZW50cmllcywgc28KKwkJCQkJICogcnRfbXBhdGhfbWF0Y2hnYXRlIG11c3QgdXNl IHRoZQorCQkJCQkgKiBpbnRlcmZhY2UgYWRkcmVzcworCQkJCQkgKi8KKwkJCQkJcnQgPSBydF9t cGF0aF9tYXRjaGdhdGUocnQsCisJCQkJCSAgICBpZmEtPmlmYV9hZGRyKTsKKwkJCQkJaWYgKCFy dCkgCisJCQkJCQllcnJvciA9IEVTUkNIOworCQkJCX0KKwkJCX0KKwkJCWVsc2UKKy8qIEVDTVAg Q2hhbmdlcyBFbmQgKi8KIAkJCXJuID0gcm5oLT5ybmhfbG9va3VwKGRzdCwgbmV0bWFzaywgcm5o KTsKIAkJCWVycm9yID0gKHJuID09IE5VTEwgfHwKIAkJCSAgICAocm4tPnJuX2ZsYWdzICYgUk5G X1JPT1QpIHx8CkBAIC0xNDgyLDYgKzE2MzksMjIgQEAKIAkJCSAqIG5vdGlmeSBhbnkgbGlzdGVu aW5nIHJvdXRpbmcgYWdlbnRzIG9mIHRoZSBjaGFuZ2UKIAkJCSAqLwogCQkJUlRfTE9DSyhydCk7 CisvKiBFQ01QIENoYW5nZXMgQmVnaW4gKi8KKwkJCS8qCisJCQkgKiBpbiBjYXNlIGFkZHJlc3Mg YWxpYXMgZmluZHMgdGhlIGZpcnN0IGFkZHJlc3MKKwkJCSAqIGUuZy4gaWZjb25maWcgYmdlMCAx OTIuMTAzLjU0LjI0Ni8yNAorCQkJICogZS5nLiBpZmNvbmZpZyBiZ2UwIDE5Mi4xMDMuNTQuMjQ3 LzI0CisJCQkgKiB0aGUgYWRkcmVzcyBzZXQgaW4gdGhlIHJvdXRlIGlzIDE5Mi4xMDMuNTQuMjQ2 CisJCQkgKiBzbyB3ZSBuZWVkIHRvIHJlcGxhY2UgaXQgd2l0aCAxOTIuMTAzLjU0LjI0NworCQkJ ICovCisJCQlpZiAobWVtY21wKHJ0LT5ydF9pZmEtPmlmYV9hZGRyLAorCQkJICAgIGlmYS0+aWZh X2FkZHIsIGlmYS0+aWZhX2FkZHItPnNhX2xlbikpIHsKKwkJCQlJRkFGUkVFKHJ0LT5ydF9pZmEp OworCQkJCUlGQVJFRihpZmEpOworCQkJCXJ0LT5ydF9pZnAgPSBpZmEtPmlmYV9pZnA7CisJCQkJ cnQtPnJ0X2lmYSA9IGlmYTsKKwkJCX0KKy8qIEVDTVAgQ2hhbmdlcyBFbmQgKi8KIAkJCXJ0X25l d2FkZHJtc2coY21kLCBpZmEsIGVycm9yLCBydCk7CiAJCQlpZiAoY21kID09IFJUTV9ERUxFVEUp IHsKIAkJCQkvKgpkaWZmIC11IC1yIC9ob21lL2JhbGFqaS9Db2Rlcy9GcmVlQlNELzcuMi4wLzcu Mi4wX3VubW9kaWZpZWQvNy4yLjAvc3lzL25ldC9yb3V0ZS5oIG5ldC9yb3V0ZS5oCi0tLSAvaG9t ZS9iYWxhamkvQ29kZXMvRnJlZUJTRC83LjIuMC83LjIuMF91bm1vZGlmaWVkLzcuMi4wL3N5cy9u ZXQvcm91dGUuaAkyMDEwLTAyLTA0IDIyOjQwOjI5LjAwMDAwMDAwMCArMDUzMAorKysgbmV0L3Jv dXRlLmgJMjAxMC0wMi0wNiAxNzoxOToxMC42NzI5NDYwMDQgKzA1MzAKQEAgLTU4LDYgKzU4LDkg QEAKIAl1X2xvbmcJcm14X210dTsJLyogTVRVIGZvciB0aGlzIHBhdGggKi8KIAl1X2xvbmcJcm14 X2V4cGlyZTsJLyogbGlmZXRpbWUgZm9yIHJvdXRlLCBlLmcuIHJlZGlyZWN0ICovCiAJdV9sb25n CXJteF9wa3NlbnQ7CS8qIHBhY2tldHMgc2VudCB1c2luZyB0aGlzIHJvdXRlICovCisvKiBFQ01Q IENoYW5nZXMgQmVnaW4gKi8KKwl1X2xvbmcgIHJteF93ZWlnaHQ7IAorLyogRUNNUCBDaGFuZ2Vz IEVuZCAgKi8KIH07CiAKIHN0cnVjdCBydF9tZXRyaWNzIHsKQEAgLTEwMSw2ICsxMDQsMTEgQEAK ICNpZm5kZWYgUk5GX05PUk1BTAogI2luY2x1ZGUgPG5ldC9yYWRpeC5oPgogI2VuZGlmCisKKy8q IEVDTVAgQ2hhbmdlcyBCZWdpbiAqLworI2luY2x1ZGUgPG5ldC9yYWRpeF9tcGF0aC5oPgorLyog RUNNUCBDaGFuZ2VzIEVuZCAgKi8KKwogc3RydWN0IHJ0ZW50cnkgewogCXN0cnVjdAlyYWRpeF9u b2RlIHJ0X25vZGVzWzJdOwkvKiB0cmVlIGdsdWUsIGFuZCBvdGhlciB2YWx1ZXMgKi8KIAkvKgpk aWZmIC11IC1yIC9ob21lL2JhbGFqaS9Db2Rlcy9GcmVlQlNELzcuMi4wLzcuMi4wX3VubW9kaWZp ZWQvNy4yLjAvc3lzL25ldC9ydHNvY2suYyBuZXQvcnRzb2NrLmMKLS0tIC9ob21lL2JhbGFqaS9D b2Rlcy9GcmVlQlNELzcuMi4wLzcuMi4wX3VubW9kaWZpZWQvNy4yLjAvc3lzL25ldC9ydHNvY2su YwkyMDEwLTAyLTA0IDIyOjQwOjI5LjAwMDAwMDAwMCArMDUzMAorKysgbmV0L3J0c29jay5jCTIw MTAtMDItMDYgMTY6MzQ6NDMuNzAwNzEzMTUyICswNTMwCkBAIC01MzYsNiArNTM2LDI3IEBACiAJ CQlSQURJWF9OT0RFX0hFQURfVU5MT0NLKHJuaCk7CiAJCQlzZW5kZXJyKEVTUkNIKTsKIAkJfQor CisvKiBFQ01QIENoYW5nZXMgQmVnaW4gKi8KKwkJLyoKKwkJICogZm9yIFJUTV9DSEFOR0UvTE9D SywgaWYgd2UgZ290IG11bHRpcGF0aCByb3V0ZXMsCisJCSAqIHdlIHJlcXVpcmUgdXNlcnMgdG8g c3BlY2lmeSBhIG1hdGNoaW5nIFJUQVhfR0FURVdBWS4KKwkJICoKKwkJICogZm9yIFJUTV9HRVQs IGdhdGUgaXMgb3B0aW9uYWwgZXZlbiB3aXRoIG11bHRpcGF0aC4KKwkJICogaWYgZ2F0ZSA9PSBO VUxMIHRoZSBmaXJzdCBtYXRjaCBpcyByZXR1cm5lZC4KKwkJICogKG5vIG5lZWQgdG8gY2FsbCBy dF9tcGF0aF9tYXRjaGdhdGUgaWYgZ2F0ZSA9PSBOVUxMKQorCQkgKi8KKwkJaWYgKHJuX21wYXRo X2NhcGFibGUocm5oKSAmJgorCQkgICAgKHJ0bS0+cnRtX3R5cGUgIT0gUlRNX0dFVCB8fCBpbmZv LnJ0aV9pbmZvW1JUQVhfR0FURVdBWV0pKSB7CisJCQlydCA9IHJ0X21wYXRoX21hdGNoZ2F0ZShy dCwgaW5mby5ydGlfaW5mb1tSVEFYX0dBVEVXQVldKTsKKwkJCWlmICghcnQpIHsKKwkJCQlSQURJ WF9OT0RFX0hFQURfVU5MT0NLKHJuaCk7CisJCQkJc2VuZGVycihFU1JDSCk7CisJCQl9CisJCX0K KworLyogRUNNUCBDaGFuZ2VzIEVuZCAqLworCiAJCVJUX0xPQ0socnQpOwogCQlSVF9BRERSRUYo cnQpOwogCQlSQURJWF9OT0RFX0hFQURfVU5MT0NLKHJuaCk7Cg== --00504502ad118ad7e3047f189c33 Content-Type: text/x-patch; charset=US-ASCII; name="ecmp_patch2.patch" Content-Disposition: attachment; filename="ecmp_patch2.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g5fffgku1 ZGlmZiAtdSAtciAvaG9tZS9iYWxhamkvQ29kZXMvRnJlZUJTRC83LjIuMC83LjIuMF91bm1vZGlm aWVkLzcuMi4wL3N5cy9uZXRpbmV0L2luX3JteC5jIG5ldGluZXQvaW5fcm14LmMKLS0tIC9ob21l L2JhbGFqaS9Db2Rlcy9GcmVlQlNELzcuMi4wLzcuMi4wX3VubW9kaWZpZWQvNy4yLjAvc3lzL25l dGluZXQvaW5fcm14LmMJMjAxMC0wMi0wNCAyMjozNTowNy4wMDAwMDAwMDAgKzA1MzAKKysrIG5l dGluZXQvaW5fcm14LmMJMjAxMC0wMi0wNyAxMjo1Njo1Ni45MzQ5NjgyNDQgKzA1MzAKQEAgLTM2 OSw2ICszNjksOSBAQAogCXJuaC0+cm5oX2FkZGFkZHIgPSBpbl9hZGRyb3V0ZTsKIAlybmgtPnJu aF9tYXRjaGFkZHIgPSBpbl9tYXRyb3V0ZTsKIAlybmgtPnJuaF9jbG9zZSA9IGluX2Nsc3JvdXRl OworCS8qIEVDTVAgQ2hhbmdlcyBCZWdpbiAqLworCXJuaC0+cm5oX211bHRpcGF0aCA9IDE7CisJ LyogRUNNUCBDaGFuZ2VzIEVuZCAqLwogCWlmIChfaW5fcnRfd2FzX2hlcmUgPT0gMCApIHsKIAkJ Y2FsbG91dF9pbml0KCZydHFfdGltZXIsIENBTExPVVRfTVBTQUZFKTsKIAkJaW5fcnRxdGltbyhy bmgpOwkvKiBraWNrIG9mZiB0aW1lb3V0IGZpcnN0IHRpbWUgKi8K --00504502ad118ad7e3047f189c33-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 16:09:16 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BFAB1065695; Mon, 8 Feb 2010 16:09:16 +0000 (UTC) (envelope-from jfb@mr-paradox.net) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id E4F888FC18; Mon, 8 Feb 2010 16:09:15 +0000 (UTC) Received: by vexbert.mr-paradox.net (Postfix, from userid 16139) id 8D009845B0; Mon, 8 Feb 2010 11:09:15 -0500 (EST) Date: Mon, 8 Feb 2010 11:09:13 -0500 From: Jeff Blank To: Ermal =?iso-8859-1?Q?Lu=E7i?= Message-ID: <20100208160913.GB13107@mr-happy.com> References: <201001291920.o0TJKAw9005498@freefall.freebsd.org> <2a41acea1001291447n5852f5b4h193d3ad6dff9faac@mail.gmail.com> <9a542da31002050626i14da8c81m94e5e46f87edfc6d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9a542da31002050626i14da8c81m94e5e46f87edfc6d@mail.gmail.com> X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e Cc: FreeBSD Net Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 16:09:16 -0000 On Fri, Feb 05, 2010 at 03:26:46PM +0100, Ermal Luçi wrote: > Anybody interested can please try the patch at this location > http://tinyurl.com/yk7qbtb. > It is against 8-STABLE though should apply even to 8-RELEASE. Ermal, This works great! I see it's been committed to HEAD as well. Thank you! Jeff From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 16:31:29 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E064D10656A7 for ; Mon, 8 Feb 2010 16:31:29 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from smtp201.iad.emailsrvr.com (smtp201.iad.emailsrvr.com [207.97.245.201]) by mx1.freebsd.org (Postfix) with ESMTP id BB6728FC1B for ; Mon, 8 Feb 2010 16:31:29 +0000 (UTC) Received: from relay10.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay10.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 9FB7D1ECEC2 for ; Mon, 8 Feb 2010 11:11:53 -0500 (EST) Received: by relay10.relay.iad.mlsrvr.com (Authenticated sender: kfodil-lemelin-AT-xiplink.com) with ESMTPSA id 87AF61EC61A for ; Mon, 8 Feb 2010 11:11:53 -0500 (EST) Message-ID: <4B7037C6.7000308@xiplink.com> Date: Mon, 08 Feb 2010 11:11:50 -0500 From: Karim Fodil-Lemelin User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Different SYN retransmit backoff between active and passive connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 16:31:30 -0000 Greetings, When doing an active connect and assuming that SYN packets are lost. The next retransmit timeout will trigger retransmissions of the SYN according to this code (in tcp_timer_rexmt): rexmt = TCP_REXMTVAL(tp) * tcp_syn_backoff[tp->t_rxtshift]; Now, when doing passive connections the syncache handles sending the SYN-ACK and assuming again the SYN-ACK is lost the next retransmit timeout will be calculated using this code: sc->sc_rxttime = ticks + TCPTV_RTOBASE * (tcp_backoff[sc->sc_rxmits]); Is there a reason why FreeBSD is not using the tcp_syn_backoff array in syncache_timeout? Regards, Karim. From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 21:01:52 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 160C410657A7; Mon, 8 Feb 2010 21:01:52 +0000 (UTC) (envelope-from eri@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E1FBC8FC1A; Mon, 8 Feb 2010 21:01:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o18L1ptZ008005; Mon, 8 Feb 2010 21:01:51 GMT (envelope-from eri@freefall.freebsd.org) Received: (from eri@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o18L1p41008001; Mon, 8 Feb 2010 21:01:51 GMT (envelope-from eri) Date: Mon, 8 Feb 2010 21:01:51 GMT Message-Id: <201002082101.o18L1p41008001@freefall.freebsd.org> To: jfb@mr-happy.com, eri@FreeBSD.org, freebsd-net@FreeBSD.org From: eri@FreeBSD.org Cc: Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 21:01:52 -0000 Synopsis: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames State-Changed-From-To: open->patched State-Changed-By: eri State-Changed-When: Mon Feb 8 21:00:22 UTC 2010 State-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=141646 From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 21:31:45 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0732106566B; Mon, 8 Feb 2010 21:31:45 +0000 (UTC) (envelope-from eri@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 788508FC1A; Mon, 8 Feb 2010 21:31:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o18LVjoq034922; Mon, 8 Feb 2010 21:31:45 GMT (envelope-from eri@freefall.freebsd.org) Received: (from eri@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o18LVjCo034918; Mon, 8 Feb 2010 21:31:45 GMT (envelope-from eri) Date: Mon, 8 Feb 2010 21:31:45 GMT Message-Id: <201002082131.o18LVjCo034918@freefall.freebsd.org> To: eri@FreeBSD.org, freebsd-net@FreeBSD.org, eri@FreeBSD.org From: eri@FreeBSD.org Cc: Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 21:31:45 -0000 Synopsis: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames Responsible-Changed-From-To: freebsd-net->eri Responsible-Changed-By: eri Responsible-Changed-When: Mon Feb 8 21:31:16 UTC 2010 Responsible-Changed-Why: Take ownership. http://www.freebsd.org/cgi/query-pr.cgi?pr=141646 From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 22:10:00 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87AE5106568D for ; Mon, 8 Feb 2010 22:10:00 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB688FC1C for ; Mon, 8 Feb 2010 22:09:59 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id PAA28420 for ; Mon, 8 Feb 2010 15:09:56 -0700 (MST) Message-Id: <201002082209.PAA28420@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Feb 2010 15:09:50 -0700 To: net@freebsd.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: IPFW firewall NAT, port address translation, and "active" FTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 22:10:00 -0000 Everyone: I've just attempted to build a router using FreeBSD 8.0 with IPFW's firewall NAT. I've included the following NAT parameters: ipfw nat 123 config if xl0 log redirect_port tcp 10.0.1.99:21 21 redirect_port tcp 10.0.1.99:20 20 Note that, among other things, incoming FTP is redirected to the host at 10.0.1.99 inside the firewall. The problem we're having is that users are having trouble reaching the FTP server with some clients -- in particular, Microsoft Internet Exploder. (I don't WANT them to be using IE, but I do not have control over this.) Does anyone know if I need to set anything special to make the firewall track FTP data ports? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 22:11:40 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7AA71065697; Mon, 8 Feb 2010 22:11:40 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 904768FC1F; Mon, 8 Feb 2010 22:11:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o18MBePg069132; Mon, 8 Feb 2010 22:11:40 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o18MBen0069128; Mon, 8 Feb 2010 22:11:40 GMT (envelope-from linimon) Date: Mon, 8 Feb 2010 22:11:40 GMT Message-Id: <201002082211.o18MBen0069128@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143666: [ip6] [request] PMTU black hole detection not implemented X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 22:11:40 -0000 Synopsis: [ip6] [request] PMTU black hole detection not implemented Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 8 22:11:24 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143666 From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 22:15:35 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 625EF1065698; Mon, 8 Feb 2010 22:15:35 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3A09A8FC1F; Mon, 8 Feb 2010 22:15:35 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o18MFZ0I070340; Mon, 8 Feb 2010 22:15:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o18MFZQS070336; Mon, 8 Feb 2010 22:15:35 GMT (envelope-from linimon) Date: Mon, 8 Feb 2010 22:15:35 GMT Message-Id: <201002082215.o18MFZQS070336@freefall.freebsd.org> To: lapo@lapo.it, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143673: [stf] the should be a way to support multiple 6to4 addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 22:15:35 -0000 Synopsis: [stf] the should be a way to support multiple 6to4 addresses State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Mon Feb 8 22:14:51 UTC 2010 State-Changed-Why: Mark suspended awaiting patches. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 8 22:14:51 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143673 From owner-freebsd-net@FreeBSD.ORG Mon Feb 8 22:48:11 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6D0D106566C for ; Mon, 8 Feb 2010 22:48:11 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 9FADC8FC0C for ; Mon, 8 Feb 2010 22:48:11 +0000 (UTC) Received: by iwn36 with SMTP id 36so1525001iwn.3 for ; Mon, 08 Feb 2010 14:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=OqKIlIsmJa9UqQ2pJaN5nKf81j8yZQoeb2mAQwK8Kus=; b=RKc/Bus9eN+CTpW9lvCOufvrw/g7g2PrxXLl6dya8UrsMISe9rhLYwoBh6WsdGBMHM +LHTgqBLJNiExPovjpwTgGp3LmZKt79Uxy6857iHXXd3RPkrroEjuLQcHH1lMf+E9tvh nQS2UBnQ8ScL7fE7N9Tt8KuI2KKNeLGeAekOE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=QoOKm9bazC/ORqpbjy3eM7AClEM7dHG2bcSMCIa5ahzTsiRms3FZglUQU6fEzkhn0A L9/t7i1FSnZ8G8NRwEoU16drLrdQtuPPhoKcNo3If3onsfyWWOeydvVNGKAYUOpFgt5X zn74/Xh7qkMoE/DNXMKabY0ksjA4gthw475gM= MIME-Version: 1.0 Received: by 10.231.143.148 with SMTP id v20mr655838ibu.14.1265667396736; Mon, 08 Feb 2010 14:16:36 -0800 (PST) In-Reply-To: <201002082209.PAA28420@lariat.net> References: <201002082209.PAA28420@lariat.net> Date: Mon, 8 Feb 2010 14:16:36 -0800 Message-ID: From: Freddie Cash To: net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: IPFW firewall NAT, port address translation, and "active" FTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 22:48:12 -0000 On Mon, Feb 8, 2010 at 2:09 PM, Brett Glass wrote: > Everyone: > > I've just attempted to build a router using FreeBSD 8.0 with IPFW's > firewall NAT. I've included the following NAT parameters: > > ipfw nat 123 config if xl0 log redirect_port tcp 10.0.1.99:21 21 > redirect_port tcp 10.0.1.99:20 20 > > Note that, among other things, incoming FTP is redirected to the host at > 10.0.1.99 inside the firewall. > > The problem we're having is that users are having trouble reaching the FTP > server with some clients -- in particular, Microsoft Internet Exploder. (I > don't WANT them to be using IE, but I do not have control over this.) Does > anyone know if I need to set anything special to make the firewall track FTP > data ports? > > Point them at "Use passive FTP" setting in IE. :) It's listed on the Advanced tab under Internet Options (IE 6 through 8). Or, use an FTP proxy. Not sure if IPFW has one built in, as I've never tried to use one ("either configure the client for PASV, or no connection" is our policy for FTP), but PF includes ftp-proxy. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Feb 9 16:10:09 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2E1A1065670 for ; Tue, 9 Feb 2010 16:10:09 +0000 (UTC) (envelope-from balajig81@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id AFDD08FC08 for ; Tue, 9 Feb 2010 16:10:09 +0000 (UTC) Received: by qyk4 with SMTP id 4so241758qyk.8 for ; Tue, 09 Feb 2010 08:10:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=zDqyvEIFMCi0crGJxAKQiEg0K+g8AbXLt6socPSmVa0=; b=s80NeonnbCJvsZR1UC64u04XrfPFyERU0vqwflj2XNyGkEGFLIM0e5Wy2WfBIAh/4w XboJR44dVPQ8guOV5Lqdrr4MSZqX0aGZx0mFdjHfrvXn3uh6b0zmhLC2sQEyFxIB3n5E GCCeCCZs5re8+IZHU65IgQUur9t7K1EjbidDc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XiegeAJVoHx3Ma7bWsf5VWWhO4ZFqtbfNBfErUhLcCPLckNg71819xElSNUxqcYuVt c4nDSKcSX4nmeyEhqJZ86YFu9cwKie3e2w4q6Kx7QrGldGGwcSypE0iilAlt123SyTLk EyIbfessoDPCXfXfO+fyDHlPjuberOO0eJx2k= MIME-Version: 1.0 Received: by 10.143.24.15 with SMTP id b15mr5454977wfj.41.1265731808277; Tue, 09 Feb 2010 08:10:08 -0800 (PST) Date: Tue, 9 Feb 2010 21:40:08 +0530 Message-ID: <6dd1343e1002090810k68255b8dw9a45046054ac35e@mail.gmail.com> From: Balaji G To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Interested in contributing towards the items in Wiki X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:10:10 -0000 Hi Everybody I am interested in contributing towards some of the items mentioned in the wiki link. Though I am quite new to FreeBSD and have been reading the kernel networking part and in fact working on back porting ECMP fixes to 7.2 from 8.0. I have sent a patch to the Mailing List too and also working on completing it . I am interested in contributing towards the following items 1. Low hanging Kernel fruit 2. IPv6 Cleanup Tasks mentioned in the wiki link http://wiki.freebsd.org/Networking It would be really great if people could reply to this mail and let me know how i could start and probably mentor me to being part of the team. Thanks for your time. Cheers, - Balaji From owner-freebsd-net@FreeBSD.ORG Tue Feb 9 17:44:19 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67E5A106566C for ; Tue, 9 Feb 2010 17:44:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2B63D8FC16 for ; Tue, 9 Feb 2010 17:44:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o19HYA33095029 for ; Tue, 9 Feb 2010 10:34:10 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 09 Feb 2010 10:34:11 -0700 (MST) Message-Id: <20100209.103411.506052712871889475.imp@bsdimp.com> To: net@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: struct sockaddr * and alignment X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 17:44:19 -0000 Greetings, I've found a few inconsistencies in the sockaddr stuff in the tree. I'm not sure where to go to get a definitive answer, so I thought I'd start here. I got here looking at the recent wake breakage on mips. It turns out that the warning was: src/usr.sbin/wake/wake.c: In function 'find_ether': src/usr.sbin/wake/wake.c:123: warning: cast increases required alignment of target type which comes from sdl = (struct sockaddr_dl *)ifa->ifa_addr; The problem is that on MIPS struct sockaddr * is byte aligned and sockaddr_dl * is word aligned, so the compiler is rightly telling us that there might be a problem here. However, further digging shows that there will never be a problem here with alignment. struct sockaddr_storage has a int64 in it to force it to be __aligned(8). So I thought to myself "why don't I just add __aligned(8) to the struct sockaddr definition?" After all, the kernel goes to great lengths to return data so aligned, and user code also keeps things aligned. Sure enough, that fixes this warning. Yea. But, sadly, it causes other problems. If you look at sbin/atm/atmconfig/natm.c you'll see code like: static void store_route(struct rt_msghdr *rtm) { ... char *cp struct sockaddr *sa; ... cp = (char *)(rtm + 1); ... sa = (struct sockaddr *)cp; cp += roundup(sa->sa_len, sizeof(long)); ... which breaks because we're now casting from an __aligned(1) char * to an __aligned(8) sockaddr *. And it is only rounding the size of the structure to long, rather than int64 like sockaddr_storage suggests is the proper alignment. But I haven't looked in the kernel to see if there's an issue there with routing sockets or not. The other extreme is to put __aligned(1) on all the sockaddr_foo structures. This would solve the compiler warning, but would have a negative effect on performance in accessing these elements (because the compiler would have to generate calls to bcopy or equivalent to access the scalar members that are larger than a byte). This cure would be worse than the disease. So the question here is "What is the right solution here?" It has me stumped. So I dropped WARNS level down from 6 to 3 for wake.c. Warner From owner-freebsd-net@FreeBSD.ORG Tue Feb 9 18:09:03 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49DC5106566B for ; Tue, 9 Feb 2010 18:09:03 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 347488FC0C for ; Tue, 9 Feb 2010 18:09:01 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o19I8ijP025933; Tue, 9 Feb 2010 10:08:44 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Feb 2010 10:05:10 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: struct sockaddr * and alignment Thread-Index: Acqpr4wkT9PnCl9mR4yZk0PbiugUKwAAt7/2 References: <20100209.103411.506052712871889475.imp@bsdimp.com> From: "Li, Qing" To: "M. Warner Losh" , Cc: Subject: RE: struct sockaddr * and alignment X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 18:09:03 -0000 > > Sure enough, that fixes this warning. Yea. But, sadly, it causes > other problems. If you look at sbin/atm/atmconfig/natm.c you'll see > code like: >=20 > static void > store_route(struct rt_msghdr *rtm) > { > ... > char *cp > struct sockaddr *sa; > ... >=20 > cp =3D (char *)(rtm + 1); > ... > sa =3D (struct sockaddr *)cp; > cp +=3D roundup(sa->sa_len, sizeof(long)); > ... >=20 > which breaks because we're now casting from an __aligned(1) char * to > an __aligned(8) sockaddr *. > And it is only rounding the size of the structure to long, rather than > int64 like sockaddr_storage suggests is the proper alignment. But I > haven't looked in the kernel to see if there's an issue there with > routing sockets or not. >=20 In the kernel route.h, the macro SA_SIZE is used by the routing socket code and may the root of the problem. -- Qing From owner-freebsd-net@FreeBSD.ORG Tue Feb 9 18:12:24 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9956E1065672 for ; Tue, 9 Feb 2010 18:12:24 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 605C48FC14 for ; Tue, 9 Feb 2010 18:12:24 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1F3357310A; Tue, 9 Feb 2010 19:21:14 +0100 (CET) Date: Tue, 9 Feb 2010 19:21:14 +0100 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20100209182114.GD89720@onelab2.iet.unipi.it> References: <20100209.103411.506052712871889475.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100209.103411.506052712871889475.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: struct sockaddr * and alignment X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 18:12:24 -0000 On Tue, Feb 09, 2010 at 10:34:11AM -0700, M. Warner Losh wrote: > Greetings, > > I've found a few inconsistencies in the sockaddr stuff in the tree. > I'm not sure where to go to get a definitive answer, so I thought I'd > start here. > > I got here looking at the recent wake breakage on mips. It turns out > that the warning was: > > src/usr.sbin/wake/wake.c: In function 'find_ether': > src/usr.sbin/wake/wake.c:123: warning: cast increases required alignment of target type > > which comes from > sdl = (struct sockaddr_dl *)ifa->ifa_addr; > > The problem is that on MIPS struct sockaddr * is byte aligned and > sockaddr_dl * is word aligned, so the compiler is rightly telling us > that there might be a problem here. > > However, further digging shows that there will never be a problem > here with alignment. struct sockaddr_storage has a int64 in it to > force it to be __aligned(8). So I thought to myself "why don't I just > add __aligned(8) to the struct sockaddr definition?" After all, the > kernel goes to great lengths to return data so aligned, and user code > also keeps things aligned. > > Sure enough, that fixes this warning. Yea. But, sadly, it causes > other problems. If you look at sbin/atm/atmconfig/natm.c you'll see > code like: > > static void > store_route(struct rt_msghdr *rtm) > { > ... > char *cp > struct sockaddr *sa; > ... > > cp = (char *)(rtm + 1); > ... > sa = (struct sockaddr *)cp; > cp += roundup(sa->sa_len, sizeof(long)); > ... > > which breaks because we're now casting from an __aligned(1) char * to > an __aligned(8) sockaddr *. > > And it is only rounding the size of the structure to long, rather than > int64 like sockaddr_storage suggests is the proper alignment. But I > haven't looked in the kernel to see if there's an issue there with > routing sockets or not. > > The other extreme is to put __aligned(1) on all the sockaddr_foo > structures. This would solve the compiler warning, but would have a > negative effect on performance in accessing these elements (because > the compiler would have to generate calls to bcopy or equivalent to > access the scalar members that are larger than a byte). This cure > would be worse than the disease. > > So the question here is "What is the right solution here?" It has me > stumped. So I dropped WARNS level down from 6 to 3 for wake.c. There does not seem to be a good fix for this type of problems (copying structures with >1 alignment requirements from/to linearized messages) that does not involve a bcopy. I think struct sockaddr (the generic versions) are normally not used in speed-critical paths, so having a bcopy inserted by the compiler (is this what really happens ?) should not harm too much. On the other hand, maybe the places where the misalignment occurs are not too many (and typically occur across ioctl/sockopt or similar system calls ?) so it might be preferable to expose the alignment requirements and manually fix the offending code. Many of those places might be already correct. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 06:41:29 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADE50106566B for ; Wed, 10 Feb 2010 06:41:29 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id F24798FC08 for ; Wed, 10 Feb 2010 06:41:28 +0000 (UTC) Received: by gxk10 with SMTP id 10so592507gxk.3 for ; Tue, 09 Feb 2010 22:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=ewnQvmd0RTWTy1GAq0BoKSonIgJXkJeey67pqnhxD1s=; b=K1dQpHvGZcGBmr+4dFD1P9KDHqdM6WHT1zbWpIP0A0zK2b96qgwZDphXZD58C5/WOm npHnVmfOLTezwP9Meh9p2U80Ace3E6mbUep6oo/vKfm9DhEmhVTnRu0vhcksO0dO/oQt EWucBymlbjbZ7D12PfrgVBYliPKeqhTdJ2z8E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=SWeIhxZzFVkB/ajGfLj+o3DHOS8W+R+JOTZPcqia6YtNUkBHpp+vHvl7yaf3An527w yToDxr8UsWkyxQFGn21F767xda/wh2yxdBSIbuRVKn9RFGYBFva9GwaCHUWMrrykiF7+ muJeFAnzpfpJ5+OYcep3XUfkNnNnkO2xsjxmg= Received: by 10.151.29.10 with SMTP id g10mr1664642ybj.129.1265784088100; Tue, 09 Feb 2010 22:41:28 -0800 (PST) Received: from centel.dataix.local (ppp-21.239.dialinfree.com [209.172.21.239]) by mx.google.com with ESMTPS id 4sm350305ywi.9.2010.02.09.22.41.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Feb 2010 22:41:27 -0800 (PST) Sender: "J. Hellenthal" Date: Wed, 10 Feb 2010 01:41:02 -0500 From: jhell To: Balaji G In-Reply-To: <6dd1343e1002080739m38f4deffr604c71e5036389a4@mail.gmail.com> Message-ID: References: <6dd1343e1002080739m38f4deffr604c71e5036389a4@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-net@freebsd.org, "Li, Qing" , Qing Li Subject: Re: [PATCH] net:: ECMP Phase 1 Fixes for FreeBSD 7.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, 10 Feb 2010 06:41:29 -0000 On Mon, 8 Feb 2010 10:39, balajig81@ wrote: > Hi Everybody > > Please find attached the patch files which contains the backported code for > ECMP for FreeBSD 7.2. I have back ported the code from 8.0. I have done some > basic testing with these patches rolled in. These are the phase 1 fixes and > i would continue to work on this and back port few other stuff too. It would > be great if someone could roll in this to 7.2, test it and give me their > valuable feedback. > > This is my first Patch for FreeBSD community and i am really excited about > this and look forward to it. > > Thanks for your time. > > Cheers, > - Balaji > In ecmp_patch1 you have, @@ -320,8 +320,9 @@ #endif extern int in6_inithead(void **head, int off); -extern int in_inithead(void **head, int off); +extern int in_inthead(void **head, int off); ?? Delete keys get in the way some times ;) -- jhell From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 06:53:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF50A106566B; Wed, 10 Feb 2010 06:53:38 +0000 (UTC) (envelope-from balajig81@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3128FC0C; Wed, 10 Feb 2010 06:53:38 +0000 (UTC) Received: by pzk40 with SMTP id 40so9536013pzk.7 for ; Tue, 09 Feb 2010 22:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=l3sBrqK36oxp5ZhjBz6grHozFDCc2exgBYRopPZAmyo=; b=Yf7Q52IA82iPGBVGwmc3kC6fI85fPSo4aubw0hO3u7FzUw+mwiBLm5Boruuvn500rN V6mJIvQ5QJPVuIvA2b1acSHdCCdMtjAQYTpUVUdj2qeDKlpgS/Z6QCDQ8TSqM3bmnp14 QWIAboJBc6UIl0vdHcH6FtRiZ+5vcl4LxakPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tlfyP4+AfFTW1unQEZmnxxqPMFM9NCCvV8y+gxLcs675zuoUQN8h2wDE3XuQZIkx+C VPxZDL6Y3JnUiHPq/e27Zn5m/CzmtKJ/oM48EzxtLyHsot8qEvB53uK0Uaxvnzu8N+ZX yMciImrFYBIHZOwUnNx8+ExdSOBoglp4S4OVs= MIME-Version: 1.0 Received: by 10.142.55.10 with SMTP id d10mr3396777wfa.244.1265784818164; Tue, 09 Feb 2010 22:53:38 -0800 (PST) In-Reply-To: References: <6dd1343e1002080739m38f4deffr604c71e5036389a4@mail.gmail.com> Date: Wed, 10 Feb 2010 12:23:38 +0530 Message-ID: <6dd1343e1002092253j5b111d42m7c354ca372241dde@mail.gmail.com> From: Balaji G To: jhell Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Li, Qing" , Qing Li Subject: Re: [PATCH] net:: ECMP Phase 1 Fixes for FreeBSD 7.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, 10 Feb 2010 06:53:38 -0000 Hi Jhell > Delete keys get in the way some times ;) I am sorry i didn't understand your comment. Is it wrong or should i change something, please let me know so that i could create an other patch . PS: I had also sent an email to the list to take up some items mentioned in the Wiki Page under the networking section. It would be nice if by any chance you know who's the contact person :). for those activities. Thanks for your feedback and time :) Thanks, Cheers, - Balaji On Wed, Feb 10, 2010 at 12:11 PM, jhell wrote: > > On Mon, 8 Feb 2010 10:39, balajig81@ wrote: > >> Hi Everybody >> >> Please find attached the patch files which contains the backported code >> for >> ECMP for FreeBSD 7.2. I have back ported the code from 8.0. I have done >> some >> basic testing with these patches rolled in. These are the phase 1 fixes >> and >> i would continue to work on this and back port few other stuff too. It >> would >> be great if someone could roll in this to 7.2, test it and give me their >> valuable feedback. >> >> This is my first Patch for FreeBSD community and i am really excited about >> this and look forward to it. >> >> Thanks for your time. >> >> Cheers, >> - Balaji >> >> > In ecmp_patch1 you have, > > @@ -320,8 +320,9 @@ > #endif > > extern int in6_inithead(void **head, int off); > -extern int in_inithead(void **head, int off); > +extern int in_inthead(void **head, int off); > > ?? > > Delete keys get in the way some times ;) > > -- > > jhell > > From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 07:19:47 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3265106566C for ; Wed, 10 Feb 2010 07:19:46 +0000 (UTC) (envelope-from kernmonk@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id C7F908FC1B for ; Wed, 10 Feb 2010 07:19:46 +0000 (UTC) Received: by pzk40 with SMTP id 40so9562334pzk.7 for ; Tue, 09 Feb 2010 23:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6e+siN/SDi8P7Kuq3e8tzj5v9fkzZYbrXeinqV+Gck4=; b=bEcsPLdIIW6JgILpUwLOyoBLE0s4KRyY6jz7xk6dOAHz1TiS4kPX9p+Ojh/mKjvQYP vw7zrBGDv8z2DHlOJ8fwA9DHRvXyayz8EhrN/x1lJ/eD4n+K8JP34j3Oj6gMjxiV70VP wkJfnP9vUGUk0doSSffnc/XkIZeF1DF0NXS6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YqF210rUrIeXrkaLQchY1ikY1vwQKECkb55wA7hs4urcezKMbdOKB8swVDDQIAb1AN enoeal0Oez/ZoJABGBiFU2KSpn4VNqMJupobTdJ7Koa55cs/7gAstwsSPoUHT68vx6bS dZqQMtjwuHZ7BBDmb4fLJ4hc9sxkiDIz9yXpE= MIME-Version: 1.0 Received: by 10.141.187.19 with SMTP id o19mr972982rvp.134.1265784925405; Tue, 09 Feb 2010 22:55:25 -0800 (PST) In-Reply-To: <6dd1343e1002090810k68255b8dw9a45046054ac35e@mail.gmail.com> References: <6dd1343e1002090810k68255b8dw9a45046054ac35e@mail.gmail.com> Date: Wed, 10 Feb 2010 12:25:25 +0530 Message-ID: From: "Leena M." To: Balaji G Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Interested in contributing towards the items in Wiki X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 07:19:47 -0000 Balaji , you can take topic of your interest & start working on it. for that first you need to have a test setup for testing your code. Regards, Onkar On Tue, Feb 9, 2010 at 9:40 PM, Balaji G wrote: > Hi Everybody > > I am interested in contributing towards some of the items mentioned in the > wiki link. Though I am quite new to FreeBSD and have been reading the > kernel > networking part and in fact working on back porting ECMP fixes to 7.2 from > 8.0. I have sent a patch to the Mailing List too and also working on > completing it . I am interested in contributing towards the following items > > 1. Low hanging Kernel fruit > 2. IPv6 Cleanup Tasks > > mentioned in the wiki link http://wiki.freebsd.org/Networking > > It would be really great if people could reply to this mail and let me know > how i could start and probably mentor me to being part of the team. > > Thanks for your time. > > Cheers, > - Balaji > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 08:11:18 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 922CA1065692 for ; Wed, 10 Feb 2010 08:11:18 +0000 (UTC) (envelope-from balajig81@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 6588D8FC14 for ; Wed, 10 Feb 2010 08:11:18 +0000 (UTC) Received: by pzk40 with SMTP id 40so20637pzk.7 for ; Wed, 10 Feb 2010 00:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KDw62/wlNqUSFB2WEkp7e7qMaC1yiDHe5KP0qSPQEVI=; b=Y/n7xVcZgd5T3eY0ZxV+sQrM/Dm6md+ZEq0IJ7+XDGxZroZo2rM4GGDGDzpU6UnDGx mUWhspaqicsRc7tuwfEwk5ORC9sQHAgNja6Khv83M7uKnm3MOpHbZ2jkzaC7dSYwzwM3 KmfMvYZce0EZQqDBMUyENjMxS7EI2GQ43gQCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jzJmjogHfZ5QxXhWE69dmvCka4eTeFT0FvxX6cEbRQCzQl0KFi7X5fC/hmZPX+ZY9d PTjV8lPT0ylC9ccXt3/scaPnQoi7ucsH9u+Z0PZwDUfVGz/y8SruK4VZmseY9e4OIcl7 GyaGQLGw1F+ARTYRrXkq7ebNOZzZF8hTQydvY= MIME-Version: 1.0 Received: by 10.142.56.11 with SMTP id e11mr607961wfa.272.1265789477896; Wed, 10 Feb 2010 00:11:17 -0800 (PST) In-Reply-To: References: <6dd1343e1002090810k68255b8dw9a45046054ac35e@mail.gmail.com> Date: Wed, 10 Feb 2010 13:41:17 +0530 Message-ID: <6dd1343e1002100011v7e92e0e1g2843d02baf82f577@mail.gmail.com> From: Balaji G To: "Leena M." Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Interested in contributing towards the items in Wiki X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 08:11:18 -0000 Hi Leena >Balaji , you can take topic of your interest & start working on it. Thanks for your reply. Yes for sure i could do it but i need some more information for the tasks and if i could get in touch with the maintainers it would be nice so that i could get more information on the tasks and i could start up with the work on what exactly needs to be done for that activity. I am relatively new to FreeBSD though i know some bit of L3 kernel code so could start with relatively smaller tasks and would get into the bigger things moving forward. > for that first you need to have a test setup for testing your code. I just have one system running Linux in the host and i have 2 VMs running FreeBSD 7.2 and FreeBSD 8.0 with custom kernel compiled which i have for testing some ECMP stuff. I am currently downloading FreeBSD 9.0 so that i could install that in an other VM so i would have 3 VMs running FreeBSD. I could do the work and do some basic testing with the VM and send the patch out and others could do some more testing and if there is something more to be done, i could do it based on the comments i get. Let me know your thoughts and inputs. Thanks, Cheers, - Balaji On Wed, Feb 10, 2010 at 12:25 PM, Leena M. wrote: > Balaji , you can take topic of your interest & start working on it. for > that > first you need to have a test setup for testing your code. > > Regards, > Onkar > > > On Tue, Feb 9, 2010 at 9:40 PM, Balaji G wrote: > >> Hi Everybody >> >> I am interested in contributing towards some of the items mentioned in the >> wiki link. Though I am quite new to FreeBSD and have been reading the >> kernel >> networking part and in fact working on back porting ECMP fixes to 7.2 from >> 8.0. I have sent a patch to the Mailing List too and also working on >> completing it . I am interested in contributing towards the following >> items >> >> 1. Low hanging Kernel fruit >> 2. IPv6 Cleanup Tasks >> >> mentioned in the wiki link http://wiki.freebsd.org/Networking >> >> It would be really great if people could reply to this mail and let me >> know >> how i could start and probably mentor me to being part of the team. >> >> Thanks for your time. >> >> Cheers, >> - Balaji >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 08:13:32 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BA351065679 for ; Wed, 10 Feb 2010 08:13:32 +0000 (UTC) (envelope-from aman.jassal@esigetel.fr) Received: from mail.esigetel.fr (venus.esigetel.fr [192.134.106.8]) by mx1.freebsd.org (Postfix) with ESMTP id B0DA58FC17 for ; Wed, 10 Feb 2010 08:13:31 +0000 (UTC) Received: by mail.esigetel.fr (Postfix, from userid 65534) id 29C1F1023C; Wed, 10 Feb 2010 09:13:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.esigetel.fr (Postfix) with ESMTP id 301B510198; Wed, 10 Feb 2010 09:09:57 +0100 (CET) X-Virus-Scanned: amavisd-new at esigetel.fr Received: from mail.esigetel.fr ([127.0.0.1]) by localhost (venus.esigetel.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E8X3NjnhNki; Wed, 10 Feb 2010 09:09:49 +0100 (CET) Received: from webmail.esigetel.fr (neo.ecampus.avon [192.168.106.14]) by mail.esigetel.fr (Postfix) with ESMTP id 6EA3110223; Wed, 10 Feb 2010 09:09:49 +0100 (CET) Received: from 83.206.131.26 (proxying for unknown) by webmail.esigetel.fr with HTTP; Wed, 10 Feb 2010 09:09:49 +0100 (CET) Message-ID: <26039.83.206.131.26.1265789389.squirrel@webmail.esigetel.fr> In-Reply-To: <6dd1343e1002092253j5b111d42m7c354ca372241dde@mail.gmail.com> References: <6dd1343e1002080739m38f4deffr604c71e5036389a4@mail.gmail.com> <6dd1343e1002092253j5b111d42m7c354ca372241dde@mail.gmail.com> Date: Wed, 10 Feb 2010 09:09:49 +0100 (CET) From: "JASSAL Aman" To: "Balaji G" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Qing Li Subject: Re: [PATCH] net:: ECMP Phase 1 Fixes for FreeBSD 7.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, 10 Feb 2010 08:13:32 -0000 Hi, Le Mer 10 février 2010 07:53, Balaji G a écrit : > Hi Jhell > > >> Delete keys get in the way some times ;) >> > > I am sorry i didn't understand your comment. Is it wrong or should i > change something, please let me know so that i could create an other patch > . > He's just saying that you've made a mistake in the spelling of the function : it's in_inithead() instead of in_inthead() > > PS: I had also sent an email to the list to take up some items mentioned > in the Wiki Page under the networking section. It would be nice if by any > chance you know who's the contact person :). for those activities. > > Thanks for your feedback and time :) > > > Thanks, > Cheers, > - Balaji > > > > On Wed, Feb 10, 2010 at 12:11 PM, jhell wrote: > > >> >> On Mon, 8 Feb 2010 10:39, balajig81@ wrote: >> >> >>> Hi Everybody >>> >>> >>> Please find attached the patch files which contains the backported >>> code for ECMP for FreeBSD 7.2. I have back ported the code from 8.0. I >>> have done some basic testing with these patches rolled in. These are >>> the phase 1 fixes and i would continue to work on this and back port >>> few other stuff too. It would be great if someone could roll in this to >>> 7.2, test it and give me their >>> valuable feedback. >>> >>> This is my first Patch for FreeBSD community and i am really excited >>> about this and look forward to it. >>> >>> Thanks for your time. >>> >>> >>> Cheers, >>> - Balaji >>> >>> >>> >> In ecmp_patch1 you have, >> >> >> @@ -320,8 +320,9 @@ >> #endif >> >> >> extern int in6_inithead(void **head, int off); -extern int >> in_inithead(void **head, int off); +extern int in_inthead(void >> **head, int off); >> >> >> ?? >> >> >> Delete keys get in the way some times ;) >> >> >> -- >> >> >> jhell >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > ------------ Aman Jassal Wisdom comes from experience. Experience comes from a lack of wisdom. From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 08:21:34 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ACE31065670; Wed, 10 Feb 2010 08:21:34 +0000 (UTC) (envelope-from balajig81@gmail.com) Received: from mail-px0-f203.google.com (mail-px0-f203.google.com [209.85.216.203]) by mx1.freebsd.org (Postfix) with ESMTP id E9C038FC1B; Wed, 10 Feb 2010 08:21:32 +0000 (UTC) Received: by pxi41 with SMTP id 41so8422268pxi.27 for ; Wed, 10 Feb 2010 00:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6cv9d4WmaBJsg1oZg9WUpQuLAOKOOQdQ3b6NIGTcFw4=; b=qwonv5ydpvjWUidjeJSo2MLajh5Cl10kGhFulqFv8MvbAH4Blgxvu3m1IH32TaQrea 064PyDdh/qYhw/QhhCCT0+JwVgr/2zqa0KTiKmtxG6Bm3HPnhSZl39nAHB+GlSbcUSqz e84fufxyvOXtOfXIWwgheIYoYTxo80jSVxWto= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MctSb/xTbAPGTEQ68jOssVqJMR6oERW6ve1TFq8y4ywnEj3eaJnr7DPZqCy2TVhPV0 LaJhJJHitwbbIHmESgXWK30EHODRpvfsjHCCNBw5RN7BxLUo274+0TBs6nVf1Cfz1CNL ateKv94JgSDrYJIDOwLYwUkRJLlMu3S7Ht9W4= MIME-Version: 1.0 Received: by 10.142.4.39 with SMTP id 39mr6190070wfd.76.1265790092474; Wed, 10 Feb 2010 00:21:32 -0800 (PST) In-Reply-To: <26039.83.206.131.26.1265789389.squirrel@webmail.esigetel.fr> References: <6dd1343e1002080739m38f4deffr604c71e5036389a4@mail.gmail.com> <6dd1343e1002092253j5b111d42m7c354ca372241dde@mail.gmail.com> <26039.83.206.131.26.1265789389.squirrel@webmail.esigetel.fr> Date: Wed, 10 Feb 2010 13:51:32 +0530 Message-ID: <6dd1343e1002100021o45af1ae5t2ee71346983b2693@mail.gmail.com> From: Balaji G To: JASSAL Aman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Qing Li Subject: Re: [PATCH] net:: ECMP Phase 1 Fixes for FreeBSD 7.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, 10 Feb 2010 08:21:34 -0000 Hi Jassal >He's just saying that you've made a mistake in the spelling of the >function : it's in_inithead() instead of in_inthead() I didn't see that. I ll correct that and when i send the next of patches will push this in too. JHell: Thanks for your comment and sorry didn't catch my eyes :) Thanks Cheers, - Balaji On Wed, Feb 10, 2010 at 1:39 PM, JASSAL Aman wrote= : > Hi, > > > Le Mer 10 f=C3=A9vrier 2010 07:53, Balaji G a =C3=A9crit : > > Hi Jhell > > > > > >> Delete keys get in the way some times ;) > >> > > > > I am sorry i didn't understand your comment. Is it wrong or should i > > change something, please let me know so that i could create an other > patch > > . > > > > He's just saying that you've made a mistake in the spelling of the > function : it's in_inithead() instead of in_inthead() > > > > > PS: I had also sent an email to the list to take up some items mentione= d > > in the Wiki Page under the networking section. It would be nice if by a= ny > > chance you know who's the contact person :). for those activities. > > > > Thanks for your feedback and time :) > > > > > > Thanks, > > Cheers, > > - Balaji > > > > > > > > On Wed, Feb 10, 2010 at 12:11 PM, jhell wrote: > > > > > >> > >> On Mon, 8 Feb 2010 10:39, balajig81@ wrote: > >> > >> > >>> Hi Everybody > >>> > >>> > >>> Please find attached the patch files which contains the backported > >>> code for ECMP for FreeBSD 7.2. I have back ported the code from 8.0. = I > >>> have done some basic testing with these patches rolled in. These are > >>> the phase 1 fixes and i would continue to work on this and back port > >>> few other stuff too. It would be great if someone could roll in this = to > >>> 7.2, test it and give me their > >>> valuable feedback. > >>> > >>> This is my first Patch for FreeBSD community and i am really excited > >>> about this and look forward to it. > >>> > >>> Thanks for your time. > >>> > >>> > >>> Cheers, > >>> - Balaji > >>> > >>> > >>> > >> In ecmp_patch1 you have, > >> > >> > >> @@ -320,8 +320,9 @@ > >> #endif > >> > >> > >> extern int in6_inithead(void **head, int off); -extern int > >> in_inithead(void **head, int off); +extern int in_inthead(void > >> **head, int off); > >> > >> > >> ?? > >> > >> > >> Delete keys get in the way some times ;) > >> > >> > >> -- > >> > >> > >> jhell > >> > >> > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > > > > ------------ > Aman Jassal > > Wisdom comes from experience. > Experience comes from a lack of wisdom. > > From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 10:13:04 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E56341065692 for ; Wed, 10 Feb 2010 10:13:03 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 896498FC25 for ; Wed, 10 Feb 2010 10:13:03 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 25so2595eya.9 for ; Wed, 10 Feb 2010 02:13:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.88.8 with SMTP id z8mr2759882wee.212.1265795339245; Wed, 10 Feb 2010 01:48:59 -0800 (PST) In-Reply-To: <20100209.103411.506052712871889475.imp@bsdimp.com> References: <20100209.103411.506052712871889475.imp@bsdimp.com> From: =?UTF-8?Q?Marius_N=C3=BCnnerich?= Date: Wed, 10 Feb 2010 10:48:09 +0100 Message-ID: To: "M. Warner Losh" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: struct sockaddr * and alignment X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 10:13:04 -0000 On Tue, Feb 9, 2010 at 18:34, M. Warner Losh wrote: > Greetings, > > I've found a few inconsistencies in the sockaddr stuff in the tree. > I'm not sure where to go to get a definitive answer, so I thought I'd > start here. > > I got here looking at the recent wake breakage on mips. =C2=A0It turns ou= t > that the warning was: > > src/usr.sbin/wake/wake.c: In function 'find_ether': > src/usr.sbin/wake/wake.c:123: warning: cast increases required alignment = of target type > > which comes from > =C2=A0 =C2=A0 =C2=A0 =C2=A0sdl =3D (struct sockaddr_dl *)ifa->ifa_addr; > > The problem is that on MIPS struct sockaddr * is byte aligned and > sockaddr_dl * is word aligned, so the compiler is rightly telling us > that there might be a problem here. > > However, further digging shows that there will never be a problem > here with alignment. =C2=A0struct sockaddr_storage has a int64 in it to > force it to be __aligned(8). =C2=A0So I thought to myself "why don't I ju= st > add __aligned(8) to the struct sockaddr definition?" =C2=A0After all, the > kernel goes to great lengths to return data so aligned, and user code > also keeps things aligned. > > Sure enough, that fixes this warning. =C2=A0Yea. =C2=A0But, sadly, it cau= ses > other problems. =C2=A0If you look at sbin/atm/atmconfig/natm.c you'll see > code like: > > static void > store_route(struct rt_msghdr *rtm) > { > ... > =C2=A0 =C2=A0 =C2=A0 =C2=A0char *cp > =C2=A0 =C2=A0 =C2=A0 =C2=A0struct sockaddr *sa; > =C2=A0 =C2=A0 =C2=A0 =C2=A0... > > =C2=A0 =C2=A0 =C2=A0 =C2=A0cp =3D (char *)(rtm + 1); > ... > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0sa =3D (struct sockaddr *)cp; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0cp +=3D roundup(sa->sa_len, sizeof(long)); > ... > > which breaks because we're now casting from an __aligned(1) char * to > an __aligned(8) sockaddr *. > > And it is only rounding the size of the structure to long, rather than > int64 like sockaddr_storage suggests is the proper alignment. =C2=A0But I > haven't looked in the kernel to see if there's an issue there with > routing sockets or not. > > The other extreme is to put __aligned(1) on all the sockaddr_foo > structures. =C2=A0This would solve the compiler warning, but would have a > negative effect on performance in accessing these elements (because > the compiler would have to generate calls to bcopy or equivalent to > access the scalar members that are larger than a byte). =C2=A0 This cure > would be worse than the disease. > > So the question here is "What is the right solution here?" =C2=A0It has m= e > stumped. =C2=A0So I dropped WARNS level down from 6 to 3 for wake.c. Hi Warner, I got into the same kind of trouble when I tried to raise the WARNS level above 3 for inetd and others. I guess everything which uses some sockaddr casting or (in the case of inetd) some of these macros: http://fxr.googlebit.com/source/sys/netinet6/in6.h?v=3D8-CURRENT#L233 It's a pity that only this keeps some programs from going to a WARNS level = of 6. From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 10:13:54 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C4CA1065694 for ; Wed, 10 Feb 2010 10:13:54 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id C3C7B8FC0C for ; Wed, 10 Feb 2010 10:13:53 +0000 (UTC) Received: by ewy3 with SMTP id 3so5448294ewy.13 for ; Wed, 10 Feb 2010 02:13:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.90.17 with SMTP id d17mr5160wef.175.1265795309213; Wed, 10 Feb 2010 01:48:29 -0800 (PST) In-Reply-To: <20100209.103411.506052712871889475.imp@bsdimp.com> References: <20100209.103411.506052712871889475.imp@bsdimp.com> From: =?UTF-8?Q?Marius_N=C3=BCnnerich?= Date: Wed, 10 Feb 2010 10:48:09 +0100 Message-ID: To: "M. Warner Losh" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: struct sockaddr * and alignment X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 10:13:54 -0000 On Tue, Feb 9, 2010 at 18:34, M. Warner Losh wrote: > Greetings, > > I've found a few inconsistencies in the sockaddr stuff in the tree. > I'm not sure where to go to get a definitive answer, so I thought I'd > start here. > > I got here looking at the recent wake breakage on mips. =C2=A0It turns ou= t > that the warning was: > > src/usr.sbin/wake/wake.c: In function 'find_ether': > src/usr.sbin/wake/wake.c:123: warning: cast increases required alignment = of target type > > which comes from > =C2=A0 =C2=A0 =C2=A0 =C2=A0sdl =3D (struct sockaddr_dl *)ifa->ifa_addr; > > The problem is that on MIPS struct sockaddr * is byte aligned and > sockaddr_dl * is word aligned, so the compiler is rightly telling us > that there might be a problem here. > > However, further digging shows that there will never be a problem > here with alignment. =C2=A0struct sockaddr_storage has a int64 in it to > force it to be __aligned(8). =C2=A0So I thought to myself "why don't I ju= st > add __aligned(8) to the struct sockaddr definition?" =C2=A0After all, the > kernel goes to great lengths to return data so aligned, and user code > also keeps things aligned. > > Sure enough, that fixes this warning. =C2=A0Yea. =C2=A0But, sadly, it cau= ses > other problems. =C2=A0If you look at sbin/atm/atmconfig/natm.c you'll see > code like: > > static void > store_route(struct rt_msghdr *rtm) > { > ... > =C2=A0 =C2=A0 =C2=A0 =C2=A0char *cp > =C2=A0 =C2=A0 =C2=A0 =C2=A0struct sockaddr *sa; > =C2=A0 =C2=A0 =C2=A0 =C2=A0... > > =C2=A0 =C2=A0 =C2=A0 =C2=A0cp =3D (char *)(rtm + 1); > ... > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0sa =3D (struct sockaddr *)cp; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0cp +=3D roundup(sa->sa_len, sizeof(long)); > ... > > which breaks because we're now casting from an __aligned(1) char * to > an __aligned(8) sockaddr *. > > And it is only rounding the size of the structure to long, rather than > int64 like sockaddr_storage suggests is the proper alignment. =C2=A0But I > haven't looked in the kernel to see if there's an issue there with > routing sockets or not. > > The other extreme is to put __aligned(1) on all the sockaddr_foo > structures. =C2=A0This would solve the compiler warning, but would have a > negative effect on performance in accessing these elements (because > the compiler would have to generate calls to bcopy or equivalent to > access the scalar members that are larger than a byte). =C2=A0 This cure > would be worse than the disease. > > So the question here is "What is the right solution here?" =C2=A0It has m= e > stumped. =C2=A0So I dropped WARNS level down from 6 to 3 for wake.c. Hi Warner, I got into the same kind of trouble when I tried to raise the WARNS level above 3 for inetd and others. I guess everything which uses some sockaddr casting or (in the case of inetd) some of these macros: http://fxr.googlebit.com/source/sys/netinet6/in6.h?v=3D8-CURRENT#L233 It's a pity that only this keeps some programs from going to a WARNS level = of 6. From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 12:46:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F27A1065693 for ; Wed, 10 Feb 2010 12:46:15 +0000 (UTC) (envelope-from egorenar@googlemail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 09D398FC1B for ; Wed, 10 Feb 2010 12:46:14 +0000 (UTC) Received: by ewy3 with SMTP id 3so5602911ewy.13 for ; Wed, 10 Feb 2010 04:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=t1vz08S9GL6JkR8olFOUArF+19g68jlOFWtnY+Ojdwo=; b=WQGI7xZkr5Y3BxkUE4o5VobkQQaIsGm9M2gux8P9vFZFXjqTbZzJmIECpnp9c9Z1f5 icmFZ0toyejf0zs/rT9Ir9kIbwdffmNkF77RXPPE1ohP+ix5gdu9rYP65FgM5ktfaeqb g9FxPVxGbqpkx5ySXNIqMHH4wqosOZMtICsnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YPsrIXVi+4BY77s5sUp7vcMaRjuTQG0aXDBFwdpD6kXICo17zqZPgkRj3Z2ag4EmTL vyVz79te7If5/HDCwqFoN48b84Qk10w/VEcGRhbukJG5Fl5aDdePgQBDMj6DsvKuzzlo XxXE7Qyin2vuqAdGa2t849oi1j1Da8YWU2jU4= MIME-Version: 1.0 Received: by 10.213.8.6 with SMTP id f6mr6430802ebf.93.1265805973836; Wed, 10 Feb 2010 04:46:13 -0800 (PST) Date: Wed, 10 Feb 2010 13:46:13 +0100 Message-ID: <2d3b7e441002100446k36493e24ldef6d4e335092b7f@mail.gmail.com> From: Alexander Egorenkov To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: net80211 and PPI header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 12:46:15 -0000 Is it possible to use PPI header instead of Radiotap header in net80211 ? If yes, how ? Radiotap header is not sufficient for 802.11n mode and PPI header supports 802.11n mode very good. From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 15:20:04 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A454106566B for ; Wed, 10 Feb 2010 15:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 69B018FC13 for ; Wed, 10 Feb 2010 15:20:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1AFK40j059383 for ; Wed, 10 Feb 2010 15:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1AFK4gx059382; Wed, 10 Feb 2010 15:20:04 GMT (envelope-from gnats) Date: Wed, 10 Feb 2010 15:20:04 GMT Message-Id: <201002101520.o1AFK4gx059382@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Dmitry Dorofeev Cc: Subject: Re: kern/143074: [wi]: wi driver triggers panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dmitry Dorofeev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 15:20:04 -0000 The following reply was made to PR kern/143074; it has been noted by GNATS. From: Dmitry Dorofeev To: bug-followup@FreeBSD.org, knowtree@aloha.com Cc: Subject: Re: kern/143074: [wi]: wi driver triggers panic Date: Wed, 10 Feb 2010 17:54:17 +0300 I have more info for this panic: Toshiba Portege 3500 Notebook with FreeBSD 8.0 i386 installed. #ifconfig wi0 up #ifconfig wi0 scan ifconfig: unable to get scan results And after couple of seconds it crashes: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x2c8 fault code = supervisor read, page not present instruction pointer = 0x20:0xc07fs1ff stack pointer = 0x28:0xd49eac18 frame pointer = 0x28:0xd49eac54 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq11: cbb0 cbb1++*) trap number = 12 panic: page fault cpuid = 0 $ dmesg Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #1: Tue Feb 9 16:12:10 MSK 2010 root@yota.home.lan:/usr/obj/usr/src/sys/GENERIC i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Mobile Intel(R) Pentium(R) III CPU - M 1333MHz (1298.74-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b4 Stepping = 4 Features=0x383f9ff real memory = 536870912 (512 MB) avail memory = 494129152 (471 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1eef0000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfc000000-0xfdffffff,0xfbc00000-0xfbffffff,0xf8000000-0xf9ffffff,0xf7ff8000-0xf7ffffff irq 11 at device 0.0 on pci1 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xeff0-0xefff at device 4.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 6.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 8.0 (no driver attached) fxp0: port 0xeb40-0xeb7f mem 0xf7efe000-0xf7efefff,0xf7ec0000-0xf7edffff irq 11 at device 10.0 on pci0 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:08:0d:ac:a6:13 fxp0: [ITHREAD] ohci0: mem 0xf7ebf000-0xf7ebffff irq 11 at device 12.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xf7ebe000-0xf7ebefff irq 11 at device 12.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xf7ebdf00-0xf7ebdfff irq 11 at device 12.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 0.95 usbus2: on ehci0 cbb0: at device 16.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] cbb1: at device 17.0 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [FILTER] cbb2: at device 17.1 on pci0 cardbus2: on cbb2 pccard2: <16-bit PCCard bus> on cbb2 cbb2: [FILTER] pci0: at device 18.0 (no driver attached) acpi_button0: on acpi0 acpi_lid0: on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 atrtc0: port 0x70-0x71 irq 8 on acpi0 uart2: <16550 or compatible> port 0x338-0x33f irq 4 on acpi0 uart2: [FILTER] cpu0: on acpi0 acpi_perf0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. Timecounter "TSC" frequency 1298744886 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ad0: 38154MB at ata0-master UDMA66 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 interrupt storm detected on "irq11:"; throttling interrupt source wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 wi0: [ITHREAD] uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 usbus0 uhub0: 3 ports with 3 removable, self powered Root mount waiting for: usbus2 uhub2: 5 ports with 5 removable, self powered Trying to mount root from ufs:/dev/ad0s1a $ vmstat -i interrupt total rate irq0: clk 125738 997 irq1: atkbd0 35 0 irq8: rtc 16096 127 irq9: acpi0 17 0 irq11: cbb0 cbb1++* 1139 9 irq14: ata0 7050 55 Total 150075 1191 ------------------- I can test bug-fixes and report back any info you would be interested in. Thanks, -Dmitry -- ó Õ×ÁÖÅÎÉÅÍ, äÍÉÔÒÉÊ äÏÒÏÆÅÅ×, ïïï "ñóð", çÅÎÅÒÁÌØÎÙÊ ÄÉÒÅËÔÏÒ +7 812 412 1076 From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 16:26:21 2010 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35E381065670 for ; Wed, 10 Feb 2010 16:26:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id DA2958FC1E for ; Wed, 10 Feb 2010 16:26:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o1AGJ0se011294; Wed, 10 Feb 2010 09:19:01 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 10 Feb 2010 09:19:03 -0700 (MST) Message-Id: <20100210.091903.177810546894923209.imp@bsdimp.com> To: marius@nuenneri.ch From: "M. Warner Losh" In-Reply-To: References: <20100209.103411.506052712871889475.imp@bsdimp.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@FreeBSD.org Subject: Re: struct sockaddr * and alignment X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 16:26:21 -0000 In message: Marius N=FCnnerich writes: : On Tue, Feb 9, 2010 at 18:34, M. Warner Losh wrote: : > Greetings, : > : > I've found a few inconsistencies in the sockaddr stuff in the tree.= : > I'm not sure where to go to get a definitive answer, so I thought I= 'd : > start here. : > : > I got here looking at the recent wake breakage on mips. =A0It turns= out : > that the warning was: : > : > src/usr.sbin/wake/wake.c: In function 'find_ether': : > src/usr.sbin/wake/wake.c:123: warning: cast increases required alig= nment of target type : > : > which comes from : > =A0 =A0 =A0 =A0sdl =3D (struct sockaddr_dl *)ifa->ifa_addr; : > : > The problem is that on MIPS struct sockaddr * is byte aligned and : > sockaddr_dl * is word aligned, so the compiler is rightly telling u= s : > that there might be a problem here. : > : > However, further digging shows that there will never be a problem : > here with alignment. =A0struct sockaddr_storage has a int64 in it t= o : > force it to be __aligned(8). =A0So I thought to myself "why don't I= just : > add __aligned(8) to the struct sockaddr definition?" =A0After all, = the : > kernel goes to great lengths to return data so aligned, and user co= de : > also keeps things aligned. : > : > Sure enough, that fixes this warning. =A0Yea. =A0But, sadly, it cau= ses : > other problems. =A0If you look at sbin/atm/atmconfig/natm.c you'll = see : > code like: : > : > static void : > store_route(struct rt_msghdr *rtm) : > { : > ... : > =A0 =A0 =A0 =A0char *cp : > =A0 =A0 =A0 =A0struct sockaddr *sa; : > =A0 =A0 =A0 =A0... : > : > =A0 =A0 =A0 =A0cp =3D (char *)(rtm + 1); : > ... : > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sa =3D (struct socka= ddr *)cp; : > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cp +=3D roundup(sa->= sa_len, sizeof(long)); : > ... : > : > which breaks because we're now casting from an __aligned(1) char * = to : > an __aligned(8) sockaddr *. : > : > And it is only rounding the size of the structure to long, rather t= han : > int64 like sockaddr_storage suggests is the proper alignment. =A0Bu= t I : > haven't looked in the kernel to see if there's an issue there with : > routing sockets or not. : > : > The other extreme is to put __aligned(1) on all the sockaddr_foo : > structures. =A0This would solve the compiler warning, but would hav= e a : > negative effect on performance in accessing these elements (because= : > the compiler would have to generate calls to bcopy or equivalent to= : > access the scalar members that are larger than a byte). =A0 This cu= re : > would be worse than the disease. : > : > So the question here is "What is the right solution here?" =A0It ha= s me : > stumped. =A0So I dropped WARNS level down from 6 to 3 for wake.c. : = : Hi Warner, : = : I got into the same kind of trouble when I tried to raise the WARNS : level above 3 for inetd and others. I guess everything which uses som= e : sockaddr casting or (in the case of inetd) some of these macros: : http://fxr.googlebit.com/source/sys/netinet6/in6.h?v=3D8-CURRENT#L233= : = : It's a pity that only this keeps some programs from going to a WARNS = level of 6. Well, if there were some way to tell the compiler "Yes, I know this is right" then we'd be set. But I've not found what that way might be. Warner From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 17:08:35 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FB661065693; Wed, 10 Feb 2010 17:08:35 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8108FC13; Wed, 10 Feb 2010 17:08:34 +0000 (UTC) Received: by gxk10 with SMTP id 10so241007gxk.3 for ; Wed, 10 Feb 2010 09:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=vf8tEWLyxYtXDUI8ow/8xP2wgu3zq49+MbKpFCrqcgs=; b=hYS0i4z1DJ2CGdm0zxD/AAwMHQAgVCjvJbjVgW9/EI0LdTszdhnQOrhFTjn+j8fP+A yzfZGH4Q/IiM0NQDVKZnfEDgqzVnAU/D5z//ULjXWO1hUj+ZFPuUmvEqEDbbDCxuR0/h 3JSi0v1TIEF2NhYZXWDZ5tc/b6wlGO4FQoJi0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=pFBzowke7ASbh1VJtXnj1EHpWGEWbeEwzGS3FaGx9+jaoH/PfXN2Q0uVJZzwbWvkEw aBYGNPKtG1yN1sV47CyuFqPKrsjlMZ50pwX0rMKHdjjERk08JLkQRmsCoOnMgicdCMs4 JXgJRUrf12FaOYP8xEnkwbJMkAan/+5FTZstY= Received: by 10.150.252.14 with SMTP id z14mr2829990ybh.72.1265821713579; Wed, 10 Feb 2010 09:08:33 -0800 (PST) Received: from centel.dataix.local (ppp-21.19.dialinfree.com [209.172.21.19]) by mx.google.com with ESMTPS id 6sm522328ywc.8.2010.02.10.09.08.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Feb 2010 09:08:31 -0800 (PST) Sender: "J. Hellenthal" Date: Wed, 10 Feb 2010 12:08:32 -0500 From: jhell To: Balaji G In-Reply-To: <6dd1343e1002092253j5b111d42m7c354ca372241dde@mail.gmail.com> Message-ID: References: <6dd1343e1002080739m38f4deffr604c71e5036389a4@mail.gmail.com> <6dd1343e1002092253j5b111d42m7c354ca372241dde@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, "Li, Qing" , Qing Li Subject: Re: [PATCH] net:: ECMP Phase 1 Fixes for FreeBSD 7.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, 10 Feb 2010 17:08:35 -0000 On Wed, 10 Feb 2010 01:53, balajig81@ wrote: > Hi Jhell > >> Delete keys get in the way some times ;) > > I am sorry i didn't understand your comment. Is it wrong or should i change > something, please let me know so that i could create an other patch . > Please see below. > PS: I had also sent an email to the list to take up some items mentioned in > the Wiki Page under the networking section. It would be nice if by any > chance you know who's the contact person :). for those activities. > I do not remember who the contact person is at the moment but it would be safe to say he/she is probably watching mailing list. > Thanks for your feedback and time :) > > Thanks, > Cheers, > - Balaji > > > On Wed, Feb 10, 2010 at 12:11 PM, jhell wrote: > >> >> On Mon, 8 Feb 2010 10:39, balajig81@ wrote: >> >>> Hi Everybody >>> >>> Please find attached the patch files which contains the backported code >>> for >>> ECMP for FreeBSD 7.2. I have back ported the code from 8.0. I have done >>> some >>> basic testing with these patches rolled in. These are the phase 1 fixes >>> and >>> i would continue to work on this and back port few other stuff too. It >>> would >>> be great if someone could roll in this to 7.2, test it and give me their >>> valuable feedback. >>> >>> This is my first Patch for FreeBSD community and i am really excited about >>> this and look forward to it. >>> >>> Thanks for your time. >>> >>> Cheers, >>> - Balaji >>> >>> >> In ecmp_patch1 you have, >> >> @@ -320,8 +320,9 @@ >> #endif >> >> extern int in6_inithead(void **head, int off); >> -extern int in_inithead(void **head, int off); >> +extern int in_inthead(void **head, int off); >> Problem is with the above two lines explicitly "in_inthead" should be "in_inithead" but it looked to me like it was a mistake and that you did not mean to delete the "i" which is why I said the following. >> ?? >> >> Delete keys get in the way some times ;) >> >> -- >> >> jhell >> >> > Best regards. -- jhell From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 17:26:36 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C9FB106566C; Wed, 10 Feb 2010 17:26:36 +0000 (UTC) (envelope-from balajig81@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id B1AB48FC14; Wed, 10 Feb 2010 17:26:34 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so72417qwd.7 for ; Wed, 10 Feb 2010 09:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0W5/HyFJXp2YIaPsTOpqORgpAPlh3kDmgEHmDhS4WH8=; b=RNR5I9thZRyd7kyhtdMLeaAl7Wh3KaRw7ge6/roxP6XK87p8KWGL1wq/x7f82k07Gp etRLNbDU0hMIlTfDhkLEEo9f1qoqx3f92KFDbFc7LLtZLCSbmJaZ+/SKz2PIZ5yERpfK D1R9djb/al6IixToswviRjKXF14BlrMFC8cWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nFr95wdRqSXBl9yWRTNVPZpgfOJTBruv7+MV2GMgm+owl6x2UYx49gcIfdcINRE7be TwOcTINeUlrnu/KryfzspWiwwwNORugIztPXYZoftDnyvJIAJEBvnm5w8nfEMJVyweDX 8Tz0/Z7a2BGb43ie7oc1+urctID1PKE54Qi+I= MIME-Version: 1.0 Received: by 10.142.56.6 with SMTP id e6mr327213wfa.191.1265822791876; Wed, 10 Feb 2010 09:26:31 -0800 (PST) In-Reply-To: References: <6dd1343e1002080739m38f4deffr604c71e5036389a4@mail.gmail.com> <6dd1343e1002092253j5b111d42m7c354ca372241dde@mail.gmail.com> Date: Wed, 10 Feb 2010 22:56:31 +0530 Message-ID: <6dd1343e1002100926mbbaf79epa8aeca5adb078d73@mail.gmail.com> From: Balaji G To: jhell Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Li, Qing" , Qing Li Subject: Re: [PATCH] net:: ECMP Phase 1 Fixes for FreeBSD 7.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, 10 Feb 2010 17:26:36 -0000 Hi Jhell Thanks yeah i got it. Jassal told me this :) sorry i didnt look at it. Will correct it when i generate the patches the next time as i am working on it Thanks for your feedback. I hope i get in touch with some on the task list soon :) Cheers, - Balaji On Wed, Feb 10, 2010 at 10:38 PM, jhell wrote: > > On Wed, 10 Feb 2010 01:53, balajig81@ wrote: > >> Hi Jhell >> >> Delete keys get in the way some times ;) >>> >> >> I am sorry i didn't understand your comment. Is it wrong or should i >> change >> something, please let me know so that i could create an other patch . >> >> > Please see below. > > > PS: I had also sent an email to the list to take up some items mentioned >> in >> the Wiki Page under the networking section. It would be nice if by any >> chance you know who's the contact person :). for those activities. >> >> > I do not remember who the contact person is at the moment but it would be > safe to say he/she is probably watching mailing list. > > > Thanks for your feedback and time :) >> >> Thanks, >> Cheers, >> - Balaji >> >> >> On Wed, Feb 10, 2010 at 12:11 PM, jhell wrote: >> >> >>> On Mon, 8 Feb 2010 10:39, balajig81@ wrote: >>> >>> Hi Everybody >>>> >>>> Please find attached the patch files which contains the backported code >>>> for >>>> ECMP for FreeBSD 7.2. I have back ported the code from 8.0. I have done >>>> some >>>> basic testing with these patches rolled in. These are the phase 1 fixes >>>> and >>>> i would continue to work on this and back port few other stuff too. It >>>> would >>>> be great if someone could roll in this to 7.2, test it and give me their >>>> valuable feedback. >>>> >>>> This is my first Patch for FreeBSD community and i am really excited >>>> about >>>> this and look forward to it. >>>> >>>> Thanks for your time. >>>> >>>> Cheers, >>>> - Balaji >>>> >>>> >>>> In ecmp_patch1 you have, >>> >>> @@ -320,8 +320,9 @@ >>> #endif >>> >>> extern int in6_inithead(void **head, int off); >>> -extern int in_inithead(void **head, int off); >>> +extern int in_inthead(void **head, int off); >>> >>> > Problem is with the above two lines explicitly "in_inthead" should be > "in_inithead" but it looked to me like it was a mistake and that you did not > mean to delete the "i" which is why I said the following. > > > ?? >>> >>> Delete keys get in the way some times ;) >>> >>> -- >>> >>> jhell >>> >>> >>> >> > > Best regards. > > -- > > jhell > > From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 21:38:26 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FBC0106566B for ; Wed, 10 Feb 2010 21:38:26 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id CD8BE8FC08 for ; Wed, 10 Feb 2010 21:38:25 +0000 (UTC) Received: by fxm24 with SMTP id 24so18354fxm.3 for ; Wed, 10 Feb 2010 13:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=LmDufyAxF80qStTrA41LKupkzBLBqXkF0rqHOUzFVYk=; b=mOMHQkQYx2x7rHMqk1Y6FcN7k3p4sJezokqUF4cm/7lqny19MFHklQAScHzHHE+MDT rge2gxrHfza+AEQmDMmxSX7v52hrA6940pj10qNAC5M4DlVfDje1y7pvmo60kFlXUVzm SbXPCTKo1zua11oUQW0AvZ/b9CjVmlyZDj2Wk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ihwgwZr0Afo17LeDgT5GfDlLZN0hBfIlCquAil5jTiqQg+1+TVs3tzA8U9IX+IeScZ 9KqVagBgDkrP8Gsg5dFSmVyEKtHCtzU0KLzrCnbyU+8460kgZ+LUtylW7RyNBKbzZ++e Ni7xfD2os6ILBN2MdNPlC00HZqIzkx326D57I= Received: by 10.223.164.78 with SMTP id d14mr1011563fay.85.1265837903757; Wed, 10 Feb 2010 13:38:23 -0800 (PST) Received: from mac-mini.local (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 14sm842132fxm.3.2010.02.10.13.38.22 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Feb 2010 13:38:22 -0800 (PST) Sender: Rui Paulo Message-ID: <4B73274E.1050902@freebsd.org> Date: Wed, 10 Feb 2010 21:38:22 +0000 From: Rui Paulo User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Alexander Egorenkov References: <2d3b7e441002100446k36493e24ldef6d4e335092b7f@mail.gmail.com> In-Reply-To: <2d3b7e441002100446k36493e24ldef6d4e335092b7f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: net80211 and PPI header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 21:38:26 -0000 On 10/02/2010 12:46, Alexander Egorenkov wrote: > Is it possible to use PPI header instead of Radiotap header in net80211 ? If > yes, how ? PPI is not implemented. > Radiotap header is not sufficient for 802.11n mode and PPI header supports > 802.11n mode very good. What exactly do you need? We should be able to extend radiotap. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 22:01:53 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB67A106566C; Wed, 10 Feb 2010 22:01:53 +0000 (UTC) (envelope-from egorenar@googlemail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 15E7E8FC0C; Wed, 10 Feb 2010 22:01:52 +0000 (UTC) Received: by ewy3 with SMTP id 3so554612ewy.13 for ; Wed, 10 Feb 2010 14:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Mm7SxO4DycPlqfOEQJN02K3o3fhMWSkbxL1bVLQlWfM=; b=eVPHIeRmXYLqJMugMwhCKE78Ar9Dz7ma64H1+8Nz6elVagX4AR7GruzL9gT/a3TKBg 7C2Vb0C8kDnCJFtHqSD7EK0XZgDplZh4NhYgGADdvkaFF9USXcoSiPYAc8wJkZQna/UL btrBcBTZVHx8D5aXE13OJ4nT4Z1GH3Qoo8IQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JOO/+objPDcVGevrKyKxGQwNtbfJ5cCcpbc4wstVMb1G7Y8XV8GQCdwblj7Ol7S5RT RUbxYl247LqJjV7NEDCL/U7HJdmwOLRDChpF6n6mE0tDG3AKbGSQtrWrPXgeNHyb8Xy/ lf0erc6zuSSblB7Ao6fOvY9uyCdSbR0DORrXg= MIME-Version: 1.0 Received: by 10.213.43.197 with SMTP id x5mr2765034ebe.91.1265839312074; Wed, 10 Feb 2010 14:01:52 -0800 (PST) In-Reply-To: <4B73274E.1050902@freebsd.org> References: <2d3b7e441002100446k36493e24ldef6d4e335092b7f@mail.gmail.com> <4B73274E.1050902@freebsd.org> Date: Wed, 10 Feb 2010 23:01:52 +0100 Message-ID: <2d3b7e441002101401x2f6f5f28i5ee3b63c18e6b1ed@mail.gmail.com> From: Alexander Egorenkov To: Rui Paulo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: net80211 and PPI header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 22:01:53 -0000 > What exactly do you need? We should be able to extend radiotap. > 1. Not only one RSSI but for every antenna (also in dBm) 2. HT greenfield/HT mixed indicator 4. Number of spatial streams (STBC) 3. A-MPDU support (MPDU density, A-MPDU reassembly) The most important one is A-MPDU support, i think. Wireshark supports PPI header and can handle A-MPDUs very nicely. That's it for now :-) Alex From owner-freebsd-net@FreeBSD.ORG Wed Feb 10 22:46:56 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9376E10656C5 for ; Wed, 10 Feb 2010 22:46:56 +0000 (UTC) (envelope-from batcilla@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 29AA98FC15 for ; Wed, 10 Feb 2010 22:46:55 +0000 (UTC) Received: by fxm24 with SMTP id 24so83573fxm.3 for ; Wed, 10 Feb 2010 14:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Aazix3+xmhccOFVgHn4DvjBVkMljjFgNkx7SUyFVKRA=; b=Ii4ao4EDZ9pNQv7i65irSyMLdHmiE/ExmnBdQNMZy0yemPGAin/mBywCLWwU1mvsdk qCVA54YJ6OVgwyRCSbWZ+j1chXVzV7j2cogQY3H/ChDAtAvE1FPraP7rj+9wIxHoYd5K hzeWSY/lwr7yaXWUpTxzvYmzGnFr4G/caggV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oEP6a03zxacatKAjiHhjisyup4RFU1xOIfqXb0Ct+2PodpOFSRYcKxkIA7QPhwiFX/ QE+iqS5F2D6Gev6M8+6qozIZtKkqfGjurRavkHfUt6lCdz31hW3fMSJlVHcZRnDC9Rx1 F56oM16nK2XbtAp9TZnynB8EiHVGmhzzZACpk= MIME-Version: 1.0 Received: by 10.239.154.204 with SMTP id f12mr95895hbc.153.1265840668185; Wed, 10 Feb 2010 14:24:28 -0800 (PST) Date: Thu, 11 Feb 2010 00:24:28 +0200 Message-ID: <6c36ec371002101424n28589b53l7d7a14660c04ce08@mail.gmail.com> From: batcilla itself To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: TDMA link cannot pass data X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 22:46:56 -0000 >>On 3 Jan 2010, at 12:23, Kim Culhan wrote: [skip...] >This is odd. What happens without the bridge? > >-- >Rui Paulo I guess without the bridge ping going w/o any problem. I also tried couple of configs with wlan in different wlanmode, hostap etc: it is precisely same as Kim wrote. In case of use routed connection it work just fine. In case of: [host1]----(eth===bridge0===gif)----wlan0=====wirelesslink=====wlan0---(gif===bridge0===eth)----[host2] it is works and host1 can ping host2. in case of [host1]----(eth===bridge0===wlan0)----====wirelesslink====-----(wlan0===bridge0===etc)---[host2] broadcast packets including arp can go through bridge, other packets miss after leaving wlan in direction of wirelesslink. I seen this on very recent 8-STABLE. (FreeBSD 8.0-STABLE #1: Thu Feb 4 23:03:37 EET 2010) Can it be somehow linked with experimental bridging support for a mesh? May be there is some sysctl need to be set in non-default value. I also repeat same test with 9-CURRENT ( FreeBSD 9.0-CURRENT #0: Thu Feb 4 16:16:02 UTC 2010 ). This is really odd... -- //batcilla From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 04:11:28 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A643A106566C; Thu, 11 Feb 2010 04:11:28 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5378FC19; Thu, 11 Feb 2010 04:11:28 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o1B4BSj4003304; Wed, 10 Feb 2010 20:11:28 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Feb 2010 20:11:22 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECMP enhancement Thread-Index: Acqq0EVTT28ES9OrQheQmTkpK9Aw7A== From: "Li, Qing" To: , Cc: qingli@freebsd.org Subject: ECMP enhancement X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 04:11:28 -0000 One of the advantages of enabling ECMP is to allow for connection load = balancing. Currently the address alias handling method is colliding with the ECMP = code. For example, when two interfaces are configured on the same prefix, only one prefix route is installed. So connection load balancing is not = possible. The other advantage of ECMP is for failover. The issue with the current = code, is=20 that the interface link-state is not reflected in the route entry. For = example,=20 if there are two interfaces on the same prefix, the cable on one = interface is=20 unplugged, new and existing connections should switch over to the other = interface.=20 This is not done today and packets go into a black hole. I discussed about these issues on the list about a month ago. Also, there is a small bug in the kernel where deleting ECMP routes in = the=20 userland will always return an error even though the command is = successfully executed. I have a patch that addresses the above issues. The patch is available = at: http://people.freebsd.org/~qingli/ecmp-linkstate-patch.diff This is not the final version. Your comments are welcome. -- Qing From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 08:50:17 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5FAD1065672; Thu, 11 Feb 2010 08:50:17 +0000 (UTC) (envelope-from balajig81@gmail.com) Received: from mail-pz0-f179.google.com (mail-pz0-f179.google.com [209.85.222.179]) by mx1.freebsd.org (Postfix) with ESMTP id B29D28FC1D; Thu, 11 Feb 2010 08:50:17 +0000 (UTC) Received: by pzk9 with SMTP id 9so1247690pzk.28 for ; Thu, 11 Feb 2010 00:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zvA4+DF4Ym16uv3jDvpGaLNBfxh7XTU2f7oOFPzQf50=; b=puT87PafZZMTl6jZ8+KeFcJ2Z43ACqjpFx756v1lNG+fQlOjPwq26S7RYGvtxHU7FO x4AB04qbuCns2HZQVJlM4K+KAqAh8dIppB94o6YKV4luslUR96GMDZd3s40gLkqZrGoQ sBmHyDiJNoYiAtk+N56vzSvTuldH/Dp8F8JPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pa1qc5NA5vCc+2DXyEz9yQNzT39y/Adht4FkV5/K92ZHuJ+a9dvQPkMeyLM8QawZmg Sz/z7Rp/YGYI2rO10OiXR6QTz/66Swl/2wuW+TlfzeuTXDwpB+SIV5ycN/b3lh6QCBIb znLWQoC1dpnlvrN0NqObkkLjnImoPhpvHF99I= MIME-Version: 1.0 Received: by 10.142.2.23 with SMTP id 23mr939024wfb.327.1265876509181; Thu, 11 Feb 2010 00:21:49 -0800 (PST) In-Reply-To: References: Date: Thu, 11 Feb 2010 13:51:49 +0530 Message-ID: <6dd1343e1002110021t544c09c9uec170c3671e364bb@mail.gmail.com> From: Balaji G To: "Li, Qing" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: qingli@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: ECMP enhancement X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 08:50:18 -0000 Hi Qing > I have a patch that addresses the above issues. The patch is available at: > http://people.freebsd.org/~qingli/ecmp-linkstate-patch.diff Thanks for the reply. I had sent you an email to you on load balancing couple of days back and thanks for the reply. I ll roll in the patch and give it a shot. Cheers, - Balaji On Thu, Feb 11, 2010 at 9:41 AM, Li, Qing wrote: > > One of the advantages of enabling ECMP is to allow for connection load > balancing. > Currently the address alias handling method is colliding with the ECMP > code. > For example, when two interfaces are configured on the same prefix, only > one prefix route is installed. So connection load balancing is not > possible. > > The other advantage of ECMP is for failover. The issue with the current > code, is > that the interface link-state is not reflected in the route entry. For > example, > if there are two interfaces on the same prefix, the cable on one interface > is > unplugged, new and existing connections should switch over to the other > interface. > This is not done today and packets go into a black hole. > > I discussed about these issues on the list about a month ago. > > Also, there is a small bug in the kernel where deleting ECMP routes in the > userland will always return an error even though the command is > successfully > executed. > > I have a patch that addresses the above issues. The patch is available at: > > http://people.freebsd.org/~qingli/ecmp-linkstate-patch.diff > > This is not the final version. Your comments are welcome. > > -- Qing > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 09:52:48 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC3C81065693; Thu, 11 Feb 2010 09:52:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B37758FC14; Thu, 11 Feb 2010 09:52:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1B9qmOD070175; Thu, 11 Feb 2010 09:52:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1B9qm5c070171; Thu, 11 Feb 2010 09:52:48 GMT (envelope-from linimon) Date: Thu, 11 Feb 2010 09:52:48 GMT Message-Id: <201002110952.o1B9qm5c070171@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143788: [iwi] wpa_supplicant(8) can't set privacy on iwi interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 09:52:49 -0000 Old Synopsis: wpa_supplicant can't set privacy on iwi interface New Synopsis: [iwi] wpa_supplicant(8) can't set privacy on iwi interface Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Feb 11 09:52:10 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143788 From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 11:25:17 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F9741065676 for ; Thu, 11 Feb 2010 11:25:17 +0000 (UTC) (envelope-from DAntrushin@mail.ru) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by mx1.freebsd.org (Postfix) with ESMTP id C74568FC12 for ; Thu, 11 Feb 2010 11:25:16 +0000 (UTC) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1BBPFWB029772 for ; Thu, 11 Feb 2010 11:25:15 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KXO00C00CVB8E00@fe-emea-09.sun.com> for freebsd-net@freebsd.org; Thu, 11 Feb 2010 11:25:05 +0000 (GMT) Received: from [129.159.126.126] ([unknown] [129.159.126.126]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KXO0018GD1NPSB0@fe-emea-09.sun.com> for freebsd-net@freebsd.org; Thu, 11 Feb 2010 11:25:00 +0000 (GMT) Date: Thu, 11 Feb 2010 14:24:50 +0300 From: Denis Antrushin Sender: Denis.Antrushin@Sun.COM To: freebsd-net@freebsd.org Message-id: <4B73E902.6050301@mail.ru> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.1.5) Gecko/20091202 Lightning/1.0pre Thunderbird/3.0 Subject: IPSec connection troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 11:25:17 -0000 Hello, I'm trying to establish IPSec connection between FreeBSD and Solaris boxes. I use FreeBSD 8-STABLE (don't recall exact checkout date, but it contains recent IPComp fixes for sure). Since I'm behind NAT, I compiled 0.8alpha snapshot of ipsec-tools from their site. racoon config looks like this: ------------------------------------------------------------ remote A.B.C.D { exchange_mode main; doi ipsec_doi; situation identity_only; certificate_type x509 "mycert.pem" "mykey.pem"; my_identifier asn1dn ; peers_identifier asn1dn ; peers_certfile x509 "server.crt"; send_cert off; verify_identifier off; lifetime time 7200 seconds; initial_contact on; passive off; proposal_check obey; generate_policy off; nonce_size 16; nat_traversal on; proposal { encryption_algorithm aes; hash_algorithm sha1; authentication_method rsasig; dh_group modp1536; } } sainfo address 192.168.1.33/32 tcp address A.B.C.D[2112] tcp { pfs_group modp1536; lifetime time 7200 seconds; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.1.33/32 udp address A.B.C.D[2112] udp { pfs_group modp1536; lifetime time 7200 seconds; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.1.33/32 icmp address A.B.C.D[any] icmp { pfs_group modp1536; lifetime time 7200 seconds; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } listen { isakmp 192.168.1.33 [500]; isakmp_natt 192.168.1.33 [4500]; } ------------------------------------------------------------------- security policy is as follows: spdadd 192.168.1.33/32 A.B.C.D/32[2112] tcp -P out ipsec esp/transport//unique; spdadd A.B.C.D/32[2112] 192.168.1.33/32 tcp -P in ipsec esp/transport//unique; spdadd 192.168.1.33/32 A.B.C.D/32[2112] udp -P out ipsec esp/transport//unique; spdadd A.B.C.D/32[2112] 192.168.1.33/32 udp -P in ipsec esp/transport//unique; spdadd 192.168.1.33/32 A.B.C.D/32 icmp -P out ipsec esp/transport//require; spdadd A.B.C.D/32 192.168.1.33/32 icmp -P in ipsec esp/transport//require; When I try to connect to TCP port 2112 of solaris box, racoon successfully negotiates with remote peer, I see SA installed in kernel, but then nothing happens. I see encapsulated TCP SYN packets sent on enc0, but nothing else. TCP connection is not established, nothing in racoon logs (except KA), nothing on PF_KEY socket. The very same setup works on Linux and Mac. How can I further debug this problem? Thanks, Denis From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 12:47:58 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEFF4106566B for ; Thu, 11 Feb 2010 12:47:58 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 796E88FC1C for ; Thu, 11 Feb 2010 12:47:58 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 174952798BC; Thu, 11 Feb 2010 13:47:57 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id F2C1D1702F; Thu, 11 Feb 2010 13:47:56 +0100 (CET) Date: Thu, 11 Feb 2010 13:47:56 +0100 From: VANHULLEBUS Yvan To: Denis Antrushin Message-ID: <20100211124756.GA9528@zeninc.net> References: <4B73E902.6050301@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B73E902.6050301@mail.ru> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: IPSec connection troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 12:47:58 -0000 On Thu, Feb 11, 2010 at 02:24:50PM +0300, Denis Antrushin wrote: > Hello, Hi. > I'm trying to establish IPSec connection between FreeBSD and > Solaris boxes. I use FreeBSD 8-STABLE (don't recall exact checkout > date, but it contains recent IPComp fixes for sure). > Since I'm behind NAT, I compiled 0.8alpha snapshot of ipsec-tools > from their site. [config] > When I try to connect to TCP port 2112 of solaris box, > racoon successfully negotiates with remote peer, I see > SA installed in kernel, >From developer's view, that's a good news :-) > but then nothing happens. > I see encapsulated TCP SYN packets sent on enc0, but > nothing else. TCP connection is not established, nothing > in racoon logs (except KA), nothing on PF_KEY socket. > The very same setup works on Linux and Mac. > > How can I further debug this problem? You can check on responder that you have lots of TCP checksums errors, which will confirm that you would need support for NAT-OA extension of NAT-T RFC, as you want to do some Transport IPsec of TCP flows using NAT-T. Unfortunately, actually, there is no support for NAT-OA extension, there are just specifications on PFKey interface to send them to kernel. Yvan. From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 13:00:07 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D83AD1065670; Thu, 11 Feb 2010 13:00:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5E89B8FC13; Thu, 11 Feb 2010 13:00:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 6418B41C7A4; Thu, 11 Feb 2010 14:00:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id LQChppK1URor; Thu, 11 Feb 2010 14:00:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 0387B41C796; Thu, 11 Feb 2010 14:00:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 4D33044496D; Thu, 11 Feb 2010 12:55:25 +0000 (UTC) Date: Thu, 11 Feb 2010 12:55:25 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: VANHULLEBUS Yvan In-Reply-To: <20100211124756.GA9528@zeninc.net> Message-ID: <20100211125420.G27327@maildrop.int.zabbadoz.net> References: <4B73E902.6050301@mail.ru> <20100211124756.GA9528@zeninc.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: IPSec connection troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 13:00:08 -0000 On Thu, 11 Feb 2010, VANHULLEBUS Yvan wrote: Hi, >> I'm trying to establish IPSec connection between FreeBSD and >> Solaris boxes. I use FreeBSD 8-STABLE (don't recall exact checkout >> date, but it contains recent IPComp fixes for sure). >> Since I'm behind NAT, I compiled 0.8alpha snapshot of ipsec-tools >> from their site. > [config] > >> When I try to connect to TCP port 2112 of solaris box, >> racoon successfully negotiates with remote peer, I see >> SA installed in kernel, > >> From developer's view, that's a good news :-) > > >> but then nothing happens. >> I see encapsulated TCP SYN packets sent on enc0, but >> nothing else. TCP connection is not established, nothing >> in racoon logs (except KA), nothing on PF_KEY socket. >> The very same setup works on Linux and Mac. >> >> How can I further debug this problem? > > You can check on responder that you have lots of TCP checksums errors, > which will confirm that you would need support for NAT-OA extension of > NAT-T RFC, as you want to do some Transport IPsec of TCP flows using > NAT-T. > > > Unfortunately, actually, there is no support for NAT-OA extension, > there are just specifications on PFKey interface to send them to > kernel. Him saying it works on linux - hsa ipsec-tools grown porpper OA support these days? If that would be the case the kernel would probably a minor task. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 13:18:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94E82106566B for ; Thu, 11 Feb 2010 13:18:15 +0000 (UTC) (envelope-from DAntrushin@mail.ru) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by mx1.freebsd.org (Postfix) with ESMTP id 270A08FC1A for ; Thu, 11 Feb 2010 13:18:14 +0000 (UTC) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1BDIDK9014679 for ; Thu, 11 Feb 2010 13:18:14 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KXO00A00I2Y0R00@fe-emea-10.sun.com> for freebsd-net@freebsd.org; Thu, 11 Feb 2010 13:17:58 +0000 (GMT) Received: from [129.159.126.126] ([unknown] [129.159.126.126]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KXO00K0JI9KLAC0@fe-emea-10.sun.com> for freebsd-net@freebsd.org; Thu, 11 Feb 2010 13:17:45 +0000 (GMT) Date: Thu, 11 Feb 2010 16:17:35 +0300 From: Denis Antrushin In-reply-to: <20100211125420.G27327@maildrop.int.zabbadoz.net> Sender: Denis.Antrushin@Sun.COM To: freebsd-net@freebsd.org Message-id: <4B74036F.6060803@mail.ru> References: <4B73E902.6050301@mail.ru> <20100211124756.GA9528@zeninc.net> <20100211125420.G27327@maildrop.int.zabbadoz.net> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.1.5) Gecko/20091202 Lightning/1.0pre Thunderbird/3.0 Subject: Re: IPSec connection troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 13:18:15 -0000 On 02/11/10 15:55, Bjoern A. Zeeb wrote: > On Thu, 11 Feb 2010, VANHULLEBUS Yvan wrote: > >>> How can I further debug this problem? >> >> You can check on responder that you have lots of TCP checksums errors, >> which will confirm that you would need support for NAT-OA extension of >> NAT-T RFC, as you want to do some Transport IPsec of TCP flows using >> NAT-T. >> >> >> Unfortunately, actually, there is no support for NAT-OA extension, >> there are just specifications on PFKey interface to send them to >> kernel. > > Him saying it works on linux - has ipsec-tools grown proper OA support > these days? If that would be the case the kernel would probably a > minor task. Yes, I see some NAT-OA debug messages in racoon logs. With ipsec-tools 0.7.3 they were missing and I could not even finish quick mode exchange... I'm sorry for ignorance, but can I workaround this problem using UDP instead? Or it requires that NAT_OA stuff as well? Thanks, Denis From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 14:52:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82DDA106566C for ; Thu, 11 Feb 2010 14:52:11 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9058FC14 for ; Thu, 11 Feb 2010 14:52:10 +0000 (UTC) Received: by fxm26 with SMTP id 26so1365179fxm.13 for ; Thu, 11 Feb 2010 06:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=gBRVnrxxZFvmjSiuDQpxDjyb11w33M00hIUSnaYqXFg=; b=NVcTG0s5b9VJDynv9S/3n/q2FR6Qgm/dE26czkoFIbElCEGljR5/F+VqdiJUQX0jk+ CJCPqcGLbDChIETXE7y3ak7ojQiqzfqJZ0KzcNUHwJ/RdUFYXT39SwWeaBF+PRET2pQL VxKNhx6BYounB0VGb2SZGTytorEeS94xXI0y0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=iTT/KsNS4pcifYG1JqwpCC0BvxqlXauc38jRadpDxVzUAbW4owYljD8/YYzwfT6+P4 2/OA+1yZ4I9FL6mSPlPWLyFaCIyRpBwtPfxHjCqclZ5OeKfGLEuKH/YQEkpCIQ6TDBgf XEy/bHSkM3zf2c9eTZkMafMran/R/cdT4Iyt0= Received: by 10.223.144.74 with SMTP id y10mr1260137fau.18.1265899929847; Thu, 11 Feb 2010 06:52:09 -0800 (PST) Received: from mac-mini.local (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 16sm1212328fxm.0.2010.02.11.06.52.07 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Feb 2010 06:52:08 -0800 (PST) Sender: Rui Paulo Message-ID: <4B741996.8030801@freebsd.org> Date: Thu, 11 Feb 2010 14:52:06 +0000 From: Rui Paulo User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: batcilla itself References: <6c36ec371002101424n28589b53l7d7a14660c04ce08@mail.gmail.com> In-Reply-To: <6c36ec371002101424n28589b53l7d7a14660c04ce08@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: TDMA link cannot pass data X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 14:52:11 -0000 On 10/02/2010 22:24, batcilla itself wrote: >>> On 3 Jan 2010, at 12:23, Kim Culhan wrote: > > [skip...] > >> This is odd. What happens without the bridge? >> >> -- >> Rui Paulo > > I guess without the bridge ping going w/o any problem. > > I also tried couple of configs with wlan in different wlanmode, hostap etc: > it is precisely same as Kim wrote. In case of use routed connection it > work just fine. > In case of: > [host1]----(eth===bridge0===gif)----wlan0=====wirelesslink=====wlan0---(gif===bridge0===eth)----[host2] > it is works and host1 can ping host2. > in case of > [host1]----(eth===bridge0===wlan0)----====wirelesslink====-----(wlan0===bridge0===etc)---[host2] > broadcast packets including arp can go through bridge, other packets > miss after leaving wlan in direction of wirelesslink. > > I seen this on very recent 8-STABLE. (FreeBSD 8.0-STABLE #1: Thu Feb > 4 23:03:37 EET 2010) > > Can it be somehow linked with experimental bridging support for a mesh? > May be there is some sysctl need to be set in non-default value. > > I also repeat same test with 9-CURRENT ( FreeBSD 9.0-CURRENT #0: Thu > Feb 4 16:16:02 UTC 2010 ). > > This is really odd... I think this is more likely related to ARP and routing table issues. I asked the submitter to use p5-SVN-Bisect in order to find the revision that broke. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 15:09:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA748106566B for ; Thu, 11 Feb 2010 15:09:45 +0000 (UTC) (envelope-from batcilla@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7DE308FC08 for ; Thu, 11 Feb 2010 15:09:44 +0000 (UTC) Received: by fxm26 with SMTP id 26so1384672fxm.13 for ; Thu, 11 Feb 2010 07:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u7OB5bqfQWZY54x6rC46BzR/ElBcmi7lT9d18iP/A4o=; b=cWMnTUbXQ8Tai5GYLCWghTSQnuq7kspOJ8cE4FKJQMJsKL9Dxi9Ecx+igz2u2ZRz+U ovozTzftN3oVBgv1gTBaAOXxoe06Q78ZBtAI5+kOUImGmTG9jzFf5nacSet0RnLrFVXf jdIj57Uhqux5uF1zoY2HAYchBvJ1QOzjCYm4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rAUmdmJio76K3OLna5eUNxChGufigQY2iwxMTJl/nCy4khOykMwPH24R/UdVM7eSQC yMREnoOBGaiQ3Xwg2mF2/0PyYq+xvhg82leeuaQIVP+gEnR3vkCyeuMarjaDiypA48Yz lzPcsih+3SJ9c0I79Sag15ZfHfiSG4nbE0O2E= MIME-Version: 1.0 Received: by 10.239.154.204 with SMTP id f12mr196924hbc.153.1265900983089; Thu, 11 Feb 2010 07:09:43 -0800 (PST) In-Reply-To: <4B741996.8030801@freebsd.org> References: <6c36ec371002101424n28589b53l7d7a14660c04ce08@mail.gmail.com> <4B741996.8030801@freebsd.org> Date: Thu, 11 Feb 2010 17:09:43 +0200 Message-ID: <6c36ec371002110709y4d2d316ahf0747a750c0e4e7d@mail.gmail.com> From: batcilla itself To: Rui Paulo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: TDMA link cannot pass data X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 15:09:46 -0000 2010/2/11 Rui Paulo : > On 10/02/2010 22:24, batcilla itself wrote: >>>> >>>> On 3 Jan 2010, at 12:23, Kim Culhan wrote: >> >> [skip...] >> >>> This is odd. What happens without the bridge? >>> >>> -- >>> Rui Paulo >> >> I guess without the bridge ping going w/o any problem. >> >> I also tried couple of configs with wlan in different wlanmode, hostap >> etc: >> it is precisely same as Kim wrote. In case of use routed connection it >> work just fine. >> In case of: >> >> [host1]----(eth=3D=3D=3Dbridge0=3D=3D=3Dgif)----wlan0=3D=3D=3D=3D=3Dwire= lesslink=3D=3D=3D=3D=3Dwlan0---(gif=3D=3D=3Dbridge0=3D=3D=3Deth)----[host2] >> it is works and host1 can ping host2. >> in case of >> >> [host1]----(eth=3D=3D=3Dbridge0=3D=3D=3Dwlan0)----=3D=3D=3D=3Dwirelessli= nk=3D=3D=3D=3D-----(wlan0=3D=3D=3Dbridge0=3D=3D=3Detc)---[host2] >> broadcast packets including arp can go through bridge, other packets >> miss after leaving wlan in direction of wirelesslink. >> >> I seen this on very recent 8-STABLE. (FreeBSD 8.0-STABLE #1: Thu Feb >> 4 23:03:37 EET 2010) >> >> Can it be somehow linked with experimental bridging support for a mesh? >> May be there is some sysctl need to be set in non-default value. >> >> I also repeat same test with 9-CURRENT ( FreeBSD 9.0-CURRENT #0: Thu >> Feb =A04 16:16:02 UTC 2010 ). >> >> This is really odd... > > I think this is more likely related to ARP and routing table issues. I as= ked > the submitter to use p5-SVN-Bisect in order to find the revision that bro= ke. I am not sure, because 1st additional test I did was to use static arp entries and put ping. In that case ping also not go, it transmitted, answered and answer lost in "radio" forwarding was off in that test. in other test, where it was on and hosts was routed anything working OK. > > > -- > Rui Paulo > -- //batcilla From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 16:57:26 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80A89106566C; Thu, 11 Feb 2010 16:57:26 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 676B38FC13; Thu, 11 Feb 2010 16:57:26 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o1BGvPAT027407; Thu, 11 Feb 2010 08:57:25 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Feb 2010 08:57:20 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECMP enhancement Thread-Index: AcqrFxfs+3AwRKypSj68ncVQESyHEwAI2lOW References: <6dd1343e1002110021t544c09c9uec170c3671e364bb@mail.gmail.com> From: "Li, Qing" To: "Balaji G" Cc: qingli@freebsd.org, current@freebsd.org, net@freebsd.org Subject: RE: ECMP enhancement X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 16:57:26 -0000 Balaji, =20 This patch came out of an offline discussion I had=20 with someone else about a month ago. That person was asking about the ECMP usage in general, and he reported a=20 couple of problems with ECMP operation to me privately. =20 This patch was created to address those reported issues. This patch has nothing to do with you and it's not a reply=20 to your email. =20 I have not had any time to review what you sent to me, which was why I asked you to send whatever you have to the mailing lists for anyone else who might be interested in looking at what you've done. =20 But I recommended to you privately to hold off on any back port because there are multiple pieces involved to make the ECMP code effective. For example, the=20 flow-table code needs to be there, too. Both Kip=20 and I are still evolving the implementation.=20 =20 Since you are new to both FreeBSD and the networking kernel, I told you the ECMP code is probably not the best=20 piece to start with, but you seem to ignore whatever I have=20 said completely ... =20 -- Qing =20 ________________________________ From: owner-freebsd-current@freebsd.org on behalf of Balaji G Sent: Thu 2/11/2010 12:21 AM To: Li, Qing Cc: qingli@freebsd.org; current@freebsd.org; net@freebsd.org Subject: Re: ECMP enhancement Hi Qing > I have a patch that addresses the above issues. The patch is available = at: > = http://people.freebsd.org/~qingli/ecmp-linkstate-patch.diff > Thanks for the reply. I had sent you an email to you on load balancing couple of days back and thanks for the reply. I ll roll in the patch and give it a shot. Cheers, - Balaji On Thu, Feb 11, 2010 at 9:41 AM, Li, Qing wrote: > > One of the advantages of enabling ECMP is to allow for connection load > balancing. > Currently the address alias handling method is colliding with the ECMP > code. > For example, when two interfaces are configured on the same prefix, = only > one prefix route is installed. So connection load balancing is not > possible. > > The other advantage of ECMP is for failover. The issue with the = current > code, is > that the interface link-state is not reflected in the route entry. For > example, > if there are two interfaces on the same prefix, the cable on one = interface > is > unplugged, new and existing connections should switch over to the = other > interface. > This is not done today and packets go into a black hole. > > I discussed about these issues on the list about a month ago. > > Also, there is a small bug in the kernel where deleting ECMP routes in = the > userland will always return an error even though the command is > successfully > executed. > > I have a patch that addresses the above issues. The patch is available = at: > > = http://people.freebsd.org/~qingli/ecmp-linkstate-patch.diff > > > This is not the final version. Your comments are welcome. > > -- Qing > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 17:50:41 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0EF4106566C; Thu, 11 Feb 2010 17:50:41 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id C4F1E8FC16; Thu, 11 Feb 2010 17:50:41 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o1BHofFS006418; Thu, 11 Feb 2010 09:50:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Feb 2010 09:47:42 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECMP for FreeBSD 7.2 Phase 1 Thread-Index: AcqrFxfs+3AwRKypSj68ncVQESyHEwAI2lOWAAHzlL0= References: <6dd1343e1002110021t544c09c9uec170c3671e364bb@mail.gmail.com> From: "Li, Qing" To: "Li, Qing" , "Balaji G" Cc: qingli@freebsd.org, current@freebsd.org, net@freebsd.org Subject: RE: ECMP for FreeBSD 7.2 Phase 1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 17:50:42 -0000 The ECMP (indirect) routes are installed into the FIB just fine, and=20 load balancing works fine with these routes. The problem is with interface prefix routes. See my other email for = details.=20 Because only a single prefix route was installed, obviously there is no=20 load balancing. -- Qing > > I would also like to know whether the Load balancing aspect works = perfectly > in FreeBSD 8.0 ?. Though i understand that the ECMP routes get = installed > fine in the FIB but would like to know whether the load balancing of = traffic > works in FreeBSD 8.0. =20 > > Thanks for your time > > Awaiting your reply . > > Cheers, > - Balaji > From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 18:03:12 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 456931065670; Thu, 11 Feb 2010 18:03:12 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1BB8FC15; Thu, 11 Feb 2010 18:03:11 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o1BI3B9C008640; Thu, 11 Feb 2010 10:03:11 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Feb 2010 10:03:08 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing problems on VPN servers running FreeBSD 8.0-RELEASE Thread-Index: AcqrRHdxOpu/kiPKQe6/6zwjaVPyyQ== From: "Li, Qing" To: Cc: qingli@freebsd.org, net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:03:12 -0000 Can you at least build one 8-stable system and see if the latest patches resolve your problems before we carry on with the=20 "merge into 8-release" or other alternatives discussion ? -- Qing Date: Thu, 04 Feb 2010 22:41:38 -0700 From: Brett Glass To: "Li, Qing" , Subject: RE: Routing problems on VPN servers running FreeBSD = 8.0-RELEASE=20 Message-ID: <201002050541.WAA04703@lariat.net> In-Reply-To: Qing: What about the possibility of going to 7.3-RELEASE? There is a lot=20 that is good about 8.x, but when I build a production system I=20 prefer to use a release that will have extended support. After all,=20 it's awkward to build a production server that will need to be=20 taken down for a major upgrade in only one year. I know that 7.2-RELEASE had problems with routing and PPP too, but=20 they were different ones. Have the 7-STABLE branch been patched=20 adequately since that time? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 20:27:52 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 081FE1065692 for ; Thu, 11 Feb 2010 20:27:52 +0000 (UTC) (envelope-from gumbo@bsdmail.org) Received: from imr-ma03.mx.aol.com (imr-ma03.mx.aol.com [64.12.206.41]) by mx1.freebsd.org (Postfix) with ESMTP id BA1FB8FC14 for ; Thu, 11 Feb 2010 20:27:51 +0000 (UTC) Received: from imo-ma01.mx.aol.com (imo-ma01.mx.aol.com [64.12.78.136]) by imr-ma03.mx.aol.com (8.14.1/8.14.1) with ESMTP id o1BKHg7j013946 for ; Thu, 11 Feb 2010 15:17:42 -0500 Received: from gumbo@bsdmail.org by imo-ma01.mx.aol.com (mail_out_v42.9.) id n.d51.67c191f9 (34905) for ; Thu, 11 Feb 2010 15:17:38 -0500 (EST) Received: from smtprly-dc01.mx.aol.com (smtprly-dc01.mx.aol.com [205.188.170.1]) by cia-da02.mx.aol.com (v127.7) with ESMTP id MAILCIADA022-d1c14b7465db14b; Thu, 11 Feb 2010 15:17:35 -0500 Received: from web-mmc-m03 (web-mmc-m03.sim.aol.com [64.12.224.136]) by smtprly-dc01.mx.aol.com (v127.7) with ESMTP id MAILSMTPRLYDC012-d1c14b7465db14b; Thu, 11 Feb 2010 15:17:31 -0500 To: freebsd-net@freebsd.org Date: Thu, 11 Feb 2010 15:17:31 -0500 X-MB-Message-Source: WebUI X-AOL-IP: 98.207.201.67 X-MB-Message-Type: User MIME-Version: 1.0 From: gumbo@bsdmail.org X-Mailer: Mail.com Webmail 30746-STANDARD Received: from 98.207.201.67 by web-mmc-m03.sysops.aol.com (64.12.224.136) with HTTP (WebMailUI); Thu, 11 Feb 2010 15:17:31 -0500 Message-Id: <8CC796E5FBF77EA-2B00-1FEE@web-mmc-m03.sysops.aol.com> X-Spam-Flag: NO X-AOL-SENDER: gumbo@bsdmail.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: problems using gif tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 20:27:52 -0000 I am running two nodes with freebsd 7.2 release on both. =20 node 1 has three gifs with tunnels configured on all. The first gif has a= tunnel to node 2.=20 Node two has one gif with a tunnel to node 1 configured. If I start a mul= ticast ping from=20 node 2 to the inner address of node 1 gif0, everything is fine. If I then= bring down gif2 on node 1, the ping receives no more responses. The down gif should have no= effect on the ping. Has anyone seen this problem ? What's going on ? Is this a known= bug ? Thanks, Rick From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 20:32:28 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB89B106566B for ; Thu, 11 Feb 2010 20:32:28 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 844BC8FC0C for ; Thu, 11 Feb 2010 20:32:28 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id NAA29928; Thu, 11 Feb 2010 13:32:22 -0700 (MST) Message-Id: <201002112032.NAA29928@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Feb 2010 13:32:12 -0700 To: "Li, Qing" From: Brett Glass In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 20:32:29 -0000 Qing: I will try to build a system late tonight. I was stuck in Washington, DC for four days due to snow and have just returned to a large backlog of work. Which snapshot would you recommend? --Brett Glass At 11:03 AM 2/11/2010, Li, Qing wrote: >Can you at least build one 8-stable system and see if the latest >patches resolve your problems before we carry on with the >"merge into 8-release" or other alternatives discussion ? > >-- Qing > > > >Date: Thu, 04 Feb 2010 22:41:38 -0700 >From: Brett Glass >To: "Li, Qing" , >Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE >Message-ID: <201002050541.WAA04703@lariat.net> >In-Reply-To: > > >Qing: > >What about the possibility of going to 7.3-RELEASE? There is a lot >that is good about 8.x, but when I build a production system I >prefer to use a release that will have extended support. After all, >it's awkward to build a production server that will need to be >taken down for a major upgrade in only one year. > >I know that 7.2-RELEASE had problems with routing and PPP too, but >they were different ones. Have the 7-STABLE branch been patched >adequately since that time? > >--Brett Glass From owner-freebsd-net@FreeBSD.ORG Thu Feb 11 20:45:27 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11301106566B for ; Thu, 11 Feb 2010 20:45:27 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8ABA08FC08 for ; Thu, 11 Feb 2010 20:45:26 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o1BKix4b002547; Fri, 12 Feb 2010 05:45:09 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id o1BKirQ9050949; Fri, 12 Feb 2010 05:44:58 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 12 Feb 2010 05:44:40 +0900 (JST) Message-Id: <20100212.054440.00550279.hrs@allbsd.org> To: gumbo@bsdmail.org From: Hiroki Sato In-Reply-To: <8CC796E5FBF77EA-2B00-1FEE@web-mmc-m03.sysops.aol.com> References: <8CC796E5FBF77EA-2B00-1FEE@web-mmc-m03.sysops.aol.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Feb_12_05_44_40_2010_403)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Fri, 12 Feb 2010 05:45:15 +0900 (JST) X-Spam-Status: No, score=-5.7 required=13.0 tests=AWL,BAYES_00, CONTENT_TYPE_PRESENT, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: problems using gif tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 20:45:27 -0000 ----Security_Multipart(Fri_Feb_12_05_44_40_2010_403)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit gumbo@bsdmail.org wrote in <8CC796E5FBF77EA-2B00-1FEE@web-mmc-m03.sysops.aol.com>: gu> I am running two nodes with freebsd 7.2 release on both. gu> node 1 has three gifs with tunnels configured on all. The first gif has a tunnel to node 2. gu> Node two has one gif with a tunnel to node 1 configured. If I start a multicast ping from gu> node 2 to the inner address of node 1 gif0, everything is fine. If I then bring down gif2 on gu> node 1, the ping receives no more responses. The down gif should have no effect on the gu> ping. Has anyone seen this problem ? What's going on ? Is this a known bug ? Can you show a way to reproduce your symptom by using command lines you entered, for example? -- Hiroki ----Security_Multipart(Fri_Feb_12_05_44_40_2010_403)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkt0bDgACgkQTyzT2CeTzy33CgCgpzNsmiaE5NIItLglIBCNvrL0 BNoAnizKCKnMcFQXxBa4L045Z5N388yS =K8Fy -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Feb_12_05_44_40_2010_403)---- From owner-freebsd-net@FreeBSD.ORG Fri Feb 12 07:50:02 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6731106566B for ; Fri, 12 Feb 2010 07:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D61BF8FC18 for ; Fri, 12 Feb 2010 07:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1C7o2OA055966 for ; Fri, 12 Feb 2010 07:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1C7o2vd055965; Fri, 12 Feb 2010 07:50:02 GMT (envelope-from gnats) Date: Fri, 12 Feb 2010 07:50:02 GMT Message-Id: <201002120750.o1C7o2vd055965@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: David Naylor Cc: Subject: Re: kern/126895: [patch] [ral] Add antenna selection (marked as TBD) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Naylor List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 07:50:03 -0000 The following reply was made to PR kern/126895; it has been noted by GNATS. From: David Naylor To: bug-followup@freebsd.org Cc: Subject: Re: kern/126895: [patch] [ral] Add antenna selection (marked as TBD) Date: Fri, 12 Feb 2010 09:41:10 +0200 --nextPart3113294.rVYeLKv7xS Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since this PR has not been dealt with (and it never did anything useful) I = am=20 happy for this PR to be closed. =20 --nextPart3113294.rVYeLKv7xS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEABECAAYFAkt1BhkACgkQUaaFgP9pFrIW8wCfZ5jkEhHw4y20cvPhEarxVIGT DYsAoIbgQmadhrdHTqUinHSfO9EP9bn8 =fxEa -----END PGP SIGNATURE----- --nextPart3113294.rVYeLKv7xS-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 12 15:28:35 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B51E21065676 for ; Fri, 12 Feb 2010 15:28:35 +0000 (UTC) (envelope-from www-data@astina.nine.ch) Received: from astina.nine.ch (astina.nine.ch [217.150.241.119]) by mx1.freebsd.org (Postfix) with ESMTP id 80F558FC0A for ; Fri, 12 Feb 2010 15:28:35 +0000 (UTC) Received: by astina.nine.ch (Postfix, from userid 33) id 0FAEAAB892; Fri, 12 Feb 2010 16:03:47 +0100 (CET) To: freebsd-net@freebsd.org From: Barry McManus MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20100212150347.0FAEAAB892@astina.nine.ch> Date: Fri, 12 Feb 2010 16:03:47 +0100 (CET) Subject: RFQ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barry.McManus@dove-eclectronic.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 15:28:35 -0000 Dear Sales Dept, We require a sale's quote and we would like to know if you carry any of the products below. If you do,email us a pricing,availability on; (1) InFocus IN3102 projector, DLP, XGA (1024 x 768) resolution, 3000 lumens (2) 160GB Ultra ATA 100 Barracuda 7200.10 Internal Hard Drive (3) Original HP 78 Tri-color Inkjet Print Cartridge (C6578DN) Terms: Net 30 days You will be contacted if your quote is acceptable.Please let me know if you have any questions. Best regards, Barry McManus Sales Manager Dove Electronic Components,Inc. 39 Research Way East Setauket, NY 11733 Tel: (888) 454-0312 Fax: (888) 779-1477 Barry.McManus@dove-eclectronic.com From owner-freebsd-net@FreeBSD.ORG Fri Feb 12 17:15:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 221AB106568B for ; Fri, 12 Feb 2010 17:15:08 +0000 (UTC) (envelope-from gumbo@bsdmail.org) Received: from imr-da03.mx.aol.com (imr-da03.mx.aol.com [205.188.105.145]) by mx1.freebsd.org (Postfix) with ESMTP id D08888FC12 for ; Fri, 12 Feb 2010 17:15:07 +0000 (UTC) Received: from imo-da04.mx.aol.com (imo-da04.mx.aol.com [205.188.169.202]) by imr-da03.mx.aol.com (8.14.1/8.14.1) with ESMTP id o1CHEofj002806 for ; Fri, 12 Feb 2010 12:14:50 -0500 Received: from gumbo@bsdmail.org by imo-da04.mx.aol.com (mail_out_v42.9.) id n.ceb.73cfcfcb (34929) for ; Fri, 12 Feb 2010 12:14:44 -0500 (EST) Received: from smtprly-db02.mx.aol.com (smtprly-db02.mx.aol.com [205.188.249.153]) by cia-da04.mx.aol.com (v127.7) with ESMTP id MAILCIADA042-5bca4b758c773ce; Fri, 12 Feb 2010 12:14:43 -0500 Received: from web-mmc-m03 (web-mmc-m03.sim.aol.com [64.12.224.136]) by smtprly-db02.mx.aol.com (v127.7) with ESMTP id MAILSMTPRLYDB021-5bca4b758c773ce; Fri, 12 Feb 2010 12:14:31 -0500 References: <8CC796E5FBF77EA-2B00-1FEE@web-mmc-m03.sysops.aol.com> <20100212.054440.00550279.hrs@allbsd.org> <8CC798334B50596-2B00-26B5@web-mmc-m03.sysops.aol.com> To: freebsd-net@freebsd.org Date: Fri, 12 Feb 2010 12:14:31 -0500 X-AOL-IP: 98.207.201.67 In-Reply-To: <8CC798334B50596-2B00-26B5@web-mmc-m03.sysops.aol.com> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: gumbo@bsdmail.org X-MB-Message-Type: User X-Mailer: Mail.com Webmail 30746-STANDARD Received: from 98.207.201.67 by web-mmc-m03.sysops.aol.com (64.12.224.136) with HTTP (WebMailUI); Fri, 12 Feb 2010 12:14:31 -0500 Message-Id: <8CC7A1DF9B06ECC-2B00-4C4D@web-mmc-m03.sysops.aol.com> X-Spam-Flag: NO X-AOL-SENDER: gumbo@bsdmail.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: re: problems using gif tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 17:15:08 -0000 The following configuration should reproduce the problem. node01 ifconfig em1 alias 10.66.0.1/24 ifconfig gif0 create ifconfig gif0 tunnel 10.66.0.1 10.66.0.2 ifconfig gif0 10.7.223.1 10.7.223.2 netmask 255.255.255.255 ifconfig gif1 create ifconfig gif1 tunnel 10.66.0.1 10.66.0.3 ifconfig gif1 10.7.224.1 10.7.224.3 netmask 255.255.255.255 ifconfig gif2 create ifconfig gif2 tunnel 10.66.0.1 10.66.0.4 ifconfig gif2 10.7.225.1 10.7.225.4 netmask 255.255.255.255 =20 node02 ifconfig em1 alias 10.66.0.2/24 ifconfig gif0 create ifconfig gif0 tunnel 10.66.0.2 10.66.0.1 ifconfig gif0 10.7.223.2 10.7.223.1 netmask 255.255.255.255 =20 Start a ping on node02 and see that it's woking.=20 ping -I 10.7.223.2 224.0.0.5 =20 Bring down gif2 on node01. ifconfig gif2 down =20 The ping on node02 no longer sees responses. This happens consistently. -----Original Message----- From: Hiroki Sato To: gumbo@bsdmail.org Cc: freebsd-net@FreeBSD.org Sent: Thu, Feb 11, 2010 12:44 pm Subject: Re: problems using gif tunnels gumbo@bsdmail.org wrote in <8CC796E5FBF77EA-2B00-1FEE@web-mmc-m03.sysops.aol.com>: gu> I am running two nodes with freebsd 7.2 release on both. u> node 1 has three gifs with tunnels configured on all. The first gif has= a=20 unnel to node 2. u> Node two has one gif with a tunnel to node 1 configured. If I start a= =20 ulticast ping from u> node 2 to the inner address of node 1 gif0, everything is fine. If I= then=20 ring down gif2 on u> node 1, the ping receives no more responses. The down gif should have= no=20 ffect on the u> ping. Has anyone seen this problem ? What's going on ? Is this a kno= wn=20 ug ? Can you show a way to reproduce your symptom by using command lines you entered, for example? -- Hiroki From owner-freebsd-net@FreeBSD.ORG Fri Feb 12 19:40:07 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FA001065707 for ; Fri, 12 Feb 2010 19:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AE17F8FC2C for ; Fri, 12 Feb 2010 19:40:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1CJe6Ea082886 for ; Fri, 12 Feb 2010 19:40:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1CJe6n3082885; Fri, 12 Feb 2010 19:40:06 GMT (envelope-from gnats) Date: Fri, 12 Feb 2010 19:40:06 GMT Message-Id: <201002121940.o1CJe6n3082885@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Eduardo Schoedler" Cc: Subject: Re: kern/141314: Network Performance has decreased by 30% [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eduardo Schoedler List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 19:40:07 -0000 The following reply was made to PR kern/141314; it has been noted by GNATS. From: "Eduardo Schoedler" To: , Cc: Subject: Re: kern/141314: Network Performance has decreased by 30% [regression] Date: Fri, 12 Feb 2010 17:14:54 -0200 Hello. First of all, sorry my bad english. I work in an small ISP in Brazil. This thread worried us a little bit, because we are going in production an Freebsd 8.0-RELEASE. We have stressed our brand new Dell servers (R210 and R410) with Freebsd 7.2-RELEASE and 8.0-RELEASE. None of them showed the problem. Here are the results of our tests (2-way tests): 7.2 i386 [R410] x 8.0 amd64 [R210]: Iperf = 931M | 98586,46K 8.0 amd64 [R210] x 7.2 i386 [R410]: Iperf = 931M | 114023,54K 8.0 amd64 [R410] x 8.0 amd64 [R210]: Iperf = 931M | 99752,64K 8.0 amd64 [R210] x 8.0 amd64 [R410]: Iperf = 931M | 114088,72K Best Regards, -- Eduardo Schoedler From owner-freebsd-net@FreeBSD.ORG Fri Feb 12 21:33:59 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AAFF106566B for ; Fri, 12 Feb 2010 21:33:59 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id AC3E38FC08 for ; Fri, 12 Feb 2010 21:33:58 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id OAA16835; Fri, 12 Feb 2010 14:33:51 -0700 (MST) Message-Id: <201002122133.OAA16835@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Feb 2010 14:32:55 -0700 To: "Li, Qing" From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 21:33:59 -0000 Qing: Last night, I updated an 8.0-RELEASE test machine to 8.0-RELENG using csup, and then rebuilt the world and the kernel. I then tested both ppp(8) (with PoPTop) and mpd 5.3 on the machine. (I did not recompile mpd, but ppp(8) was of course recompiled when I rebuilt the world.) Proxy ARP for users tunneling into the LAN via a PPTP VPN did not work. mpd produced no error message, but it did not create the proxy arp entry and the VPN connection was immediately broken. ppp(8) gave the error message Feb 12 14:16:02 tester ppp[1078]: tun0: Error: Add proxy arp entry
: File exists and then disconnected. Connections for which firewall NAT (rather than proxy arp) was used seemed to function properly. Unfortunately, this isn't an acceptable workaround for machines that need full access when tunneling through a firewall. I've been told that the ARP and routing changes are new to 8.0-RELEASE. Therefore, we may abandon 8-STABLE and try 7.3-RELEASE (assuming that we can find drivers for our hardware) if we can't get routing and ARP to work with the various PPP implementations soon. Please let me know if you can implement changes that will help us use 8-STABLE. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Fri Feb 12 22:37:49 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EAEA106566C for ; Fri, 12 Feb 2010 22:37:49 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 33FCF8FC12 for ; Fri, 12 Feb 2010 22:37:48 +0000 (UTC) Received: by fxm28 with SMTP id 28so1228889fxm.34 for ; Fri, 12 Feb 2010 14:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=YuySTatYWE2Xrh0B2RtHLyVKv5/cG1xBgtZqr0BON0E=; b=TUgxfTA7mql5QSINCzyYW9pRvbpwS5vPOR5LcJ4x2V4q4XXXxnQ7RU9vLWjQZtmMtt p/0OjmB2RNoP6XzgPUmFH55OMP1TDkqC+fLFoWQAMqORg+2RtdaH6ITNhLcD/0WMzKOx rIpx7kPHQ6qy7cuLuWk56S6msE7cSgSSxBj7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZB7ms7by4so+xeqA2/ATenY7u+Ev6VFUNeCmArOz0WTq3TUIcQsgeOPPc5i4FV3IMg r63Tf2eLjkchgLjpdAU5y//EencGArwgGGothWEiNE9k3cc86z5PpAiDPj1f/dajdsC0 uzubNV1xy29pHjX9cAx1oASMyyl4wVsqPFPa8= MIME-Version: 1.0 Received: by 10.239.185.6 with SMTP id a6mr231267hbh.31.1266012580368; Fri, 12 Feb 2010 14:09:40 -0800 (PST) In-Reply-To: <201002122133.OAA16835@lariat.net> References: <201002122133.OAA16835@lariat.net> Date: Fri, 12 Feb 2010 17:09:40 -0500 Message-ID: <25ff90d61002121409m6a9d7639qf254a754644a60ca@mail.gmail.com> From: David Horn To: Brett Glass Content-Type: text/plain; charset=ISO-8859-1 Cc: "Li, Qing" , net@freebsd.org Subject: Re: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 22:37:49 -0000 On Fri, Feb 12, 2010 at 4:32 PM, Brett Glass wrote: > Qing: > > Last night, I updated an 8.0-RELEASE test machine to 8.0-RELENG using csup, If you have not already, make certain you use the appropriate tag of "RELENG_8", and not "RELENG_8_0" as per: http://www.freebsd.org/doc/handbook/cvs-tags.html Since what you are needing for this particular test is 8-STABLE. You can use csup(1) to get the latest stable source as follows: csup -h /usr/share/examples/cvsup/stable-supfile You can get the list of csup/cvsup mirrors here: http://www.freebsd.org/doc/handbook/cvsup.html#CVSUP-MIRRORS > and then rebuilt the world and the kernel. I then tested both ppp(8) (with > PoPTop) and mpd 5.3 on the machine. (I did not recompile mpd, but ppp(8) was > of course recompiled when I rebuilt the world.) > > Proxy ARP for users tunneling into the LAN via a PPTP VPN did not work. mpd > produced no error message, but it did not create the proxy arp entry and the > VPN connection was immediately broken. > > ppp(8) gave the error message > > Feb 12 14:16:02 tester ppp[1078]: tun0: Error: Add proxy arp > entry
: File exists > > and then disconnected. Connections for which firewall NAT (rather than proxy > arp) was used seemed to function properly. Unfortunately, this isn't an > acceptable workaround for machines that need full access when tunneling > through a firewall. > > I've been told that the ARP and routing changes are new to 8.0-RELEASE. > Therefore, we may abandon 8-STABLE and try 7.3-RELEASE (assuming that we can > find drivers for our hardware) if we can't get routing and ARP to work with > the various PPP implementations soon. Please let me know if you can > implement changes that will help us use 8-STABLE. > > --Brett Glass > Good Luck. ---Dave From owner-freebsd-net@FreeBSD.ORG Fri Feb 12 22:40:12 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4054D106566C for ; Fri, 12 Feb 2010 22:40:12 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id C7F008FC15 for ; Fri, 12 Feb 2010 22:40:11 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id PAA17544; Fri, 12 Feb 2010 15:40:02 -0700 (MST) Message-Id: <201002122240.PAA17544@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Feb 2010 15:39:40 -0700 To: David Horn From: Brett Glass In-Reply-To: <25ff90d61002121409m6a9d7639qf254a754644a60ca@mail.gmail.co m> References: <201002122133.OAA16835@lariat.net> <25ff90d61002121409m6a9d7639qf254a754644a60ca@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Li, Qing" , net@freebsd.org Subject: Re: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 22:40:12 -0000 At 03:09 PM 2/12/2010, David Horn wrote: >If you have not already, make certain you use the appropriate tag of >"RELENG_8", and not "RELENG_8_0" Yup, that's what I did. I used /usr/share/examples/stable-supfile with only one mod: I explicitly inserted the name of the mirror into the file rather than using the -h command line option. I then did a "make buildworld", a "make buildkernel", a "make installkernel", a reboot, and a "make installworld" (followed by "make delete-old", "make cleandir", and "make clean" for good housekeeping). Didn't bother with mergemaster, because none of the config files was going to need changing. The routing and ARP mods that I brought in with the update didn't make PPTP work. This likely means that not only PPP-based VPN protocols but also some PPP dialup connections will not be fully functional on 8.0-RELEASE or 8-STABLE. I'd be glad to provide configuration files and firewall rules with which all of this can be reproduced. --Brett From owner-freebsd-net@FreeBSD.ORG Fri Feb 12 23:31:04 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2334106566C for ; Fri, 12 Feb 2010 23:31:04 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id A9A018FC08 for ; Fri, 12 Feb 2010 23:31:04 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o1CNV3va005564; Fri, 12 Feb 2010 15:31:04 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Feb 2010 15:26:44 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing problems on VPN servers running FreeBSD 8.0-RELEASE Thread-Index: AcqsNFXRqhddPCQ3SrObzlzAv0xxbgABoD4q References: <201002122133.OAA16835@lariat.net> <25ff90d61002121409m6a9d7639qf254a754644a60ca@mail.gmail.com> <201002122240.PAA17544@lariat.net> From: "Li, Qing" To: "Brett Glass" Cc: net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 23:31:04 -0000 My merges from /base/head are in /stable/8 =20 http://svn.freebsd.org/viewvc/base/stable/8/ =20 Let's be sure you do have the right set of files. Can you verify your = checked out version of "in.c" is similar to the version I last modified in = revision 203401 ?? =20 http://svn.freebsd.org/viewvc/base/stable/8/sys/netinet/in.c?view=3Dlog =20 Then please report back the result of your verification. =20 --Qing =20 ________________________________ From: Brett Glass [mailto:brett@lariat.net] Sent: Fri 2/12/2010 2:39 PM To: David Horn Cc: Li, Qing; net@freebsd.org Subject: Re: Routing problems on VPN servers running FreeBSD 8.0-RELEASE At 03:09 PM 2/12/2010, David Horn wrote: >If you have not already, make certain you use the appropriate tag of >"RELENG_8", and not "RELENG_8_0" Yup, that's what I did. I used /usr/share/examples/stable-supfile with only one mod: I explicitly inserted the name of the mirror into the file rather than using the -h command line option. I then did a "make buildworld", a "make buildkernel", a "make installkernel", a reboot, and a "make installworld" (followed by "make delete-old", "make cleandir", and "make clean" for good housekeeping). Didn't bother with mergemaster, because none of the config files was going to need changing. The routing and ARP mods that I brought in with the update didn't make PPTP work. This likely means that not only PPP-based VPN protocols but also some PPP dialup connections will not be fully functional on 8.0-RELEASE or 8-STABLE. I'd be glad to provide configuration files and firewall rules with which all of this can be reproduced. --Brett From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 00:04:56 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F321106566B for ; Sat, 13 Feb 2010 00:04:56 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3CE8FC13 for ; Sat, 13 Feb 2010 00:04:55 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id RAA18387; Fri, 12 Feb 2010 17:04:48 -0700 (MST) Message-Id: <201002130004.RAA18387@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Feb 2010 17:04:41 -0700 To: "Li, Qing" From: Brett Glass In-Reply-To: References: <201002122133.OAA16835@lariat.net> <25ff90d61002121409m6a9d7639qf254a754644a60ca@mail.gmail.com> <201002122240.PAA17544@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 00:04:56 -0000 Qing: On my test system, the file /usr/src/sys/netinet/in.c contains the following tag: __FBSDID("$FreeBSD: src/sys/netinet/in.c,v 1.143.2.13 2010/02/09 19:27:54 qingli Exp $"); The date above matches the date of revision 203718, which is 3 days old. --Brett At 04:26 PM 2/12/2010, Li, Qing wrote: >Let's be sure you do have the right set of files. Can you verify your checked >out version of "in.c" is similar to the version I last modified in >revision 203401 ?? From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 00:32:52 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DED19106566B for ; Sat, 13 Feb 2010 00:32:52 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id C6B378FC0A for ; Sat, 13 Feb 2010 00:32:52 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o1D0WpAK010362; Fri, 12 Feb 2010 16:32:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Feb 2010 16:28:08 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing problems on VPN servers running FreeBSD 8.0-RELEASE Thread-Index: AcqsQCxOrlm88Mp6StCmFplonW3gPAAAz5yl References: <201002122133.OAA16835@lariat.net> <25ff90d61002121409m6a9d7639qf254a754644a60ca@mail.gmail.com> <201002122240.PAA17544@lariat.net> <201002130004.RAA18387@lariat.net> From: "Li, Qing" To: "Brett Glass" Cc: net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 00:32:52 -0000 Okay. =20 I will be on a business trip for a week staring tomorrow. I'd be more = than happy=20 to work with you offline right after I get back, that's if you can wait = and no one=20 else has picked this issue up. =20 In the meantime, can you send me your PPP configuration information to qingli@freebsd.org , and whatever other pieces of information you are willing to share. =20 Thanks, =20 -- Qing =20 ________________________________ From: Brett Glass [mailto:brett@lariat.net] Sent: Fri 2/12/2010 4:04 PM To: Li, Qing Cc: net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE Qing: On my test system, the file /usr/src/sys/netinet/in.c contains the following tag: __FBSDID("$FreeBSD: src/sys/netinet/in.c,v 1.143.2.13 2010/02/09 19:27:54 qingli Exp $"); The date above matches the date of revision 203718, which is 3 days old. --Brett At 04:26 PM 2/12/2010, Li, Qing wrote: >Let's be sure you do have the right set of files. Can you verify your = checked >out version of "in.c" is similar to the version I last modified in >revision 203401 ?? From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 00:42:07 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AADD1065670 for ; Sat, 13 Feb 2010 00:42:07 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id C40B58FC1E for ; Sat, 13 Feb 2010 00:42:06 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id RAA18639; Fri, 12 Feb 2010 17:41:59 -0700 (MST) Message-Id: <201002130041.RAA18639@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Feb 2010 17:41:55 -0700 To: "Li, Qing" From: Brett Glass In-Reply-To: References: <201002122133.OAA16835@lariat.net> <25ff90d61002121409m6a9d7639qf254a754644a60ca@mail.gmail.com> <201002122240.PAA17544@lariat.net> <201002130004.RAA18387@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 00:42:07 -0000 At 05:28 PM 2/12/2010, Li, Qing wrote: >Okay. > >I will be on a business trip for a week staring tomorrow. I'd be >more than happy >to work with you offline right after I get back, that's if you can >wait and no one else has picked this issue up. It'd be good to resolve this as soon as possible, because I have two clients who need servers installed this weekend. (They wanted them last week, but I was trapped away from the office by a snowstorm.) I'll send configuration information offlist. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 02:03:35 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C907106566B for ; Sat, 13 Feb 2010 02:03:35 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 170708FC08 for ; Sat, 13 Feb 2010 02:03:35 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o1D23YIe016254; Fri, 12 Feb 2010 18:03:34 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Feb 2010 18:03:28 -0800 Message-ID: In-Reply-To: <201002130041.RAA18639@lariat.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing problems on VPN servers running FreeBSD 8.0-RELEASE Thread-Index: AcqsRV9VRICFDdfNRX+4PgAlMDac3QACSLvQ References: <201002122133.OAA16835@lariat.net> <25ff90d61002121409m6a9d7639qf254a754644a60ca@mail.gmail.com> <201002122240.PAA17544@lariat.net> <201002130004.RAA18387@lariat.net> <201002130041.RAA18639@lariat.net> From: "Li, Qing" To: "Brett Glass" Cc: "Li, Qing" , Luiz Otavio O Souza , net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 02:03:35 -0000 >=20 > It'd be good to resolve this as soon as possible, because I have > two clients who need servers installed this weekend. (They wanted > them last week, but I was trapped away from the office by a snowstorm.) >=20 Luiz Otavio and I have been discussing offline about an issue with the file /usr.sbin/ppp/arp.c in the past week or so. The ARP related=20 code in arp.c was missing a flag bit called "RTF_LLDATA".=20 Luiz Otavio and I just had a debug session on your issue. He was able to reproduce it, and due to the missing RTF_LLDATA bit, the proxy-arp entry made it into the routing table, which was not suppose to happen. Since there is already a PPP host entry for the remote end, you get the FILE EXIST error. I believe the reason was due to its confusing the kernel code as=20 if mpd is installing a routing entry as in=20 "route add x.x.x.x/y -iface em0". So you can wait for Luiz's patch, or you could do it yourself and try the following 1 line fix: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D -- usr.sbin/ppp/arp.c (revision 203430) +++ usr.sbin/ppp/arp.c (working copy) @@ -119,7 +119,7 @@ return 0; } arpmsg.hdr.rtm_type =3D add ? RTM_ADD : RTM_DELETE; - arpmsg.hdr.rtm_flags =3D RTF_ANNOUNCE | RTF_HOST | RTF_STATIC; + arpmsg.hdr.rtm_flags =3D RTF_ANNOUNCE | RTF_HOST | RTF_STATIC | RTF_LLDATA; arpmsg.hdr.rtm_version =3D RTM_VERSION; arpmsg.hdr.rtm_seq =3D ++bundle->routing_seq; arpmsg.hdr.rtm_addrs =3D RTA_DST | RTA_GATEWAY; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D I had to reintroduce the RTF_LLDATA flag for compatibility in r187094 back in Jan. 2009. This change appears to be missing from the ppp port. Please give the above fix a try and see if it resolves your issue. -- Qing From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 02:08:56 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 726C41065670 for ; Sat, 13 Feb 2010 02:08:56 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 00EAA8FC08 for ; Sat, 13 Feb 2010 02:08:55 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id TAA19278; Fri, 12 Feb 2010 19:08:48 -0700 (MST) Message-Id: <201002130208.TAA19278@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Feb 2010 19:08:45 -0700 To: "Li, Qing" From: Brett Glass In-Reply-To: References: <201002122133.OAA16835@lariat.net> <25ff90d61002121409m6a9d7639qf254a754644a60ca@mail.gmail.com> <201002122240.PAA17544@lariat.net> <201002130004.RAA18387@lariat.net> <201002130041.RAA18639@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Li, Qing" , Luiz Otavio O Souza , net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 02:08:56 -0000 At 07:03 PM 2/12/2010, Li, Qing wrote: >Luiz Otavio and I have been discussing offline about an issue with >the file /usr.sbin/ppp/arp.c in the past week or so. The ARP related >code in arp.c was missing a flag bit called "RTF_LLDATA". What about mpd? --Brett From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 02:23:06 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBA991065670 for ; Sat, 13 Feb 2010 02:23:06 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7D58FC0A for ; Sat, 13 Feb 2010 02:23:06 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id TAA19338; Fri, 12 Feb 2010 19:22:59 -0700 (MST) Message-Id: <201002130222.TAA19338@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Feb 2010 19:22:56 -0700 To: "Li, Qing" From: Brett Glass In-Reply-To: References: <201002122133.OAA16835@lariat.net> <25ff90d61002121409m6a9d7639qf254a754644a60ca@mail.gmail.com> <201002122240.PAA17544@lariat.net> <201002130004.RAA18387@lariat.net> <201002130041.RAA18639@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Li, Qing" , Luiz Otavio O Souza , net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 02:23:06 -0000 This patch seems to have had a positive effect on ppp(8)/PoPToP, though more testing is needed. However, It appears that mpd uses arp(8) rather than the socket interface to set up proxy ARP. Here's the code (from the file iface.c in mpd 5.3): if (Enabled(&iface->options, IFACE_CONF_PROXY)) { if (u_addrempty(&iface->peer_addr)) { Log(LG_IFACE, ("[%s] IFACE: Can't proxy arp for %s", b->name, u_addrtoa(&iface->peer_addr,hisaddr,sizeof(hisaddr)))); } else if (GetEther(&iface->peer_addr, &hwa) < 0) { Log(LG_IFACE, ("[%s] IFACE: No interface to proxy arp on for %s", b->name, u_addrtoa(&iface->peer_addr,hisaddr,sizeof(hisaddr)))); } else { ether = (u_char *) LLADDR(&hwa); if (ExecCmdNosh(LG_IFACE2, b->name, "%s -S %s %x:%x:%x:%x:%x:%x pub", PATH_ARP, u_addrtoa(&iface->peer_addr,hisaddr,sizeof(hisaddr)), ether[0], ether[1], ether[2], ether[3], ether[4], ether[5]) == 0) iface->proxy_addr = iface->peer_addr; } } When this executes, I do not get an error message but nothing actually happens. Must something be done to arp(8) or to mpd to make the code above work? --Brett At 07:03 PM 2/12/2010, Li, Qing wrote: > > > > It'd be good to resolve this as soon as possible, because I have > > two clients who need servers installed this weekend. (They wanted > > them last week, but I was trapped away from the office by a >snowstorm.) > > > >Luiz Otavio and I have been discussing offline about an issue with >the file /usr.sbin/ppp/arp.c in the past week or so. The ARP related >code in arp.c was missing a flag bit called "RTF_LLDATA". > >Luiz Otavio and I just had a debug session on your issue. He was >able to reproduce it, and due to the missing RTF_LLDATA bit, the >proxy-arp entry made it into the routing table, which was not >suppose to happen. Since there is already a PPP host entry >for the remote end, you get the FILE EXIST error. >I believe the reason was due to its confusing the kernel code as >if mpd is installing a routing entry as in >"route add x.x.x.x/y -iface em0". > >So you can wait for Luiz's patch, or you could do it yourself >and try the following 1 line fix: > >======================================================================== >======== >-- usr.sbin/ppp/arp.c (revision 203430) >+++ usr.sbin/ppp/arp.c (working copy) >@@ -119,7 +119,7 @@ > return 0; > } > arpmsg.hdr.rtm_type = add ? RTM_ADD : RTM_DELETE; >- arpmsg.hdr.rtm_flags = RTF_ANNOUNCE | RTF_HOST | RTF_STATIC; >+ arpmsg.hdr.rtm_flags = RTF_ANNOUNCE | RTF_HOST | RTF_STATIC | >RTF_LLDATA; > arpmsg.hdr.rtm_version = RTM_VERSION; > arpmsg.hdr.rtm_seq = ++bundle->routing_seq; > arpmsg.hdr.rtm_addrs = RTA_DST | RTA_GATEWAY; >======================================================================== >======== > >I had to reintroduce the RTF_LLDATA flag for compatibility in r187094 >back >in Jan. 2009. This change appears to be missing from the ppp port. > >Please give the above fix a try and see if it resolves your issue. > >-- Qing From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 02:30:58 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 989FF10657C0 for ; Sat, 13 Feb 2010 02:30:58 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 152D28FC14 for ; Sat, 13 Feb 2010 02:30:57 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id TAA19403; Fri, 12 Feb 2010 19:30:51 -0700 (MST) Message-Id: <201002130230.TAA19403@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Feb 2010 19:30:48 -0700 To: "Li, Qing" From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Li, Qing" , Luiz Otavio O Souza , net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 02:30:58 -0000 P.S. -- It occurs to me that perhaps adding the word "only" at the end of the command string used by mpd 5.3 might help. Should I try this? From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 02:38:38 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56A051065670 for ; Sat, 13 Feb 2010 02:38:38 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 411C58FC12 for ; Sat, 13 Feb 2010 02:38:38 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o1D2cbkU017999; Fri, 12 Feb 2010 18:38:37 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Feb 2010 18:37:56 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing problems on VPN servers running FreeBSD 8.0-RELEASE Thread-Index: AcqsVJNET6KAxSALRAeZUedzroGOowAAPltG References: <201002130230.TAA19403@lariat.net> From: "Li, Qing" To: "Brett Glass" Cc: Luiz Otavio O Souza , net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 02:38:38 -0000 Read the manpage. "only" just require a host route to be present. I don't think it will make a difference here. -- Qing -----Original Message----- From: Brett Glass [mailto:brett@lariat.net] Sent: Fri 2/12/2010 6:30 PM To: Li, Qing Cc: net@freebsd.org; Li, Qing; Luiz Otavio O Souza Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE =20 P.S. -- It occurs to me that perhaps adding the word "only" at the=20 end of the command string used by mpd 5.3 might help. Should I try this? From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 02:40:36 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F54C1065672 for ; Sat, 13 Feb 2010 02:40:36 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 0223A8FC08 for ; Sat, 13 Feb 2010 02:40:35 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o1D2eZpr018172; Fri, 12 Feb 2010 18:40:35 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Feb 2010 18:38:44 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing problems on VPN servers running FreeBSD 8.0-RELEASE Thread-Index: AcqsU3oYOecr5BRKQrS/K5ipNFfH0wAAi7eE References: <201002122133.OAA16835@lariat.net> <25ff90d61002121409m6a9d7639qf254a754644a60ca@mail.gmail.com> <201002122240.PAA17544@lariat.net> <201002130004.RAA18387@lariat.net> <201002130041.RAA18639@lariat.net> <201002130222.TAA19338@lariat.net> From: "Li, Qing" To: "Brett Glass" Cc: Luiz Otavio O Souza , net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 02:40:36 -0000 Okay, well, I need to pack. So will get back to it in a week. -- Qing -----Original Message----- From: Brett Glass [mailto:brett@lariat.net] Sent: Fri 2/12/2010 6:22 PM To: Li, Qing Cc: net@freebsd.org; Li, Qing; Luiz Otavio O Souza Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE =20 This patch seems to have had a positive effect on ppp(8)/PoPToP,=20 though more testing is needed. However, It appears that mpd uses=20 arp(8) rather than the socket interface to set up proxy ARP. Here's=20 the code (from the file iface.c in mpd 5.3): if (Enabled(&iface->options, IFACE_CONF_PROXY)) { if (u_addrempty(&iface->peer_addr)) { Log(LG_IFACE, ("[%s] IFACE: Can't proxy arp for %s", b->name,=20 u_addrtoa(&iface->peer_addr,hisaddr,sizeof(hisaddr)))); } else if (GetEther(&iface->peer_addr, &hwa) < 0) { Log(LG_IFACE, ("[%s] IFACE: No interface to proxy arp on for %s", b->name,=20 u_addrtoa(&iface->peer_addr,hisaddr,sizeof(hisaddr)))); } else { ether =3D (u_char *) LLADDR(&hwa); if (ExecCmdNosh(LG_IFACE2, b->name, "%s -S %s %x:%x:%x:%x:%x:%x pub", PATH_ARP,=20 u_addrtoa(&iface->peer_addr,hisaddr,sizeof(hisaddr)), ether[0], ether[1], ether[2], ether[3], ether[4], ether[5]) =3D=3D 0) iface->proxy_addr =3D iface->peer_addr; } } When this executes, I do not get an error message but nothing=20 actually happens. Must something be done to arp(8) or to mpd to=20 make the code above work? --Brett At 07:03 PM 2/12/2010, Li, Qing wrote: > > > > It'd be good to resolve this as soon as possible, because I have > > two clients who need servers installed this weekend. (They wanted > > them last week, but I was trapped away from the office by a >snowstorm.) > > > >Luiz Otavio and I have been discussing offline about an issue with >the file /usr.sbin/ppp/arp.c in the past week or so. The ARP related >code in arp.c was missing a flag bit called "RTF_LLDATA". > >Luiz Otavio and I just had a debug session on your issue. He was >able to reproduce it, and due to the missing RTF_LLDATA bit, the >proxy-arp entry made it into the routing table, which was not >suppose to happen. Since there is already a PPP host entry >for the remote end, you get the FILE EXIST error. >I believe the reason was due to its confusing the kernel code as >if mpd is installing a routing entry as in >"route add x.x.x.x/y -iface em0". > >So you can wait for Luiz's patch, or you could do it yourself >and try the following 1 line fix: > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D=3D=3D=3D=3D=3D >-- usr.sbin/ppp/arp.c (revision 203430) >+++ usr.sbin/ppp/arp.c (working copy) >@@ -119,7 +119,7 @@ > return 0; > } > arpmsg.hdr.rtm_type =3D add ? RTM_ADD : RTM_DELETE; >- arpmsg.hdr.rtm_flags =3D RTF_ANNOUNCE | RTF_HOST | RTF_STATIC; >+ arpmsg.hdr.rtm_flags =3D RTF_ANNOUNCE | RTF_HOST | RTF_STATIC | >RTF_LLDATA; > arpmsg.hdr.rtm_version =3D RTM_VERSION; > arpmsg.hdr.rtm_seq =3D ++bundle->routing_seq; > arpmsg.hdr.rtm_addrs =3D RTA_DST | RTA_GATEWAY; >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D=3D=3D=3D=3D=3D > >I had to reintroduce the RTF_LLDATA flag for compatibility in r187094 >back >in Jan. 2009. This change appears to be missing from the ppp port. > >Please give the above fix a try and see if it resolves your issue. > >-- Qing From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 03:05:25 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81E361065692 for ; Sat, 13 Feb 2010 03:05:25 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.211.181]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1D38FC0C for ; Sat, 13 Feb 2010 03:05:24 +0000 (UTC) Received: by ywh11 with SMTP id 11so4380239ywh.9 for ; Fri, 12 Feb 2010 19:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=8vxDq17dTC3OP1kkKEpXydETaAXYC/d3ob4aTyxaEXI=; b=SP4bdVS+RaXo5pNlXBXxYxItn9MoiDDfgUgKUcWvSWAz/xWf+5Z6IsErOTTm7NeAwH 9tNVzCEP18ChZUqFcrkNnCxI82i3Lvj6ZCwmW6VbEViVZFazeWOSdmU1bufy9D06jauZ U+wyEIgOyv8iMFVED2vGeJP6QuJ7rkvH7sbeA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=getWRGVXFfL0ylc+cckoMMYDiSI5J0ey/xl9fPbx7qzBmIPJmofL0QJe9XJostyX31 5W5st9vLCDGtDXQoWhxjvsJo2JF0qw2L3P/jb+ixQTeRPC9Xzm0geO7fpXZNV7uyDHaa 0+JI9w15olVglPTCuxmbClLlnxNxBYXW2arDc= Received: by 10.150.251.5 with SMTP id y5mr3632895ybh.48.1266028930688; Fri, 12 Feb 2010 18:42:10 -0800 (PST) Received: from ?192.168.0.86? ([189.35.249.167]) by mx.google.com with ESMTPS id 20sm1629787ywh.32.2010.02.12.18.42.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Feb 2010 18:42:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Luiz Otavio O Souza In-Reply-To: <201002130230.TAA19403@lariat.net> Date: Sat, 13 Feb 2010 00:42:06 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8192E832-3DD0-4D0A-9FAD-6A70CE59FD26@gmail.com> References: <201002130230.TAA19403@lariat.net> To: Brett Glass X-Mailer: Apple Mail (2.1077) Cc: "Li, Qing" , net@freebsd.org Subject: Re: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 03:05:25 -0000 Brett, Change the "-S" to "-s" in the following line: if (ExecCmdNosh(LG_IFACE2, b->name, "%s -S %s %x:%x:%x:%x:%x:%x pub", PATH_ARP, = u_addrtoa(&iface->peer_addr,hisaddr,sizeof(hisaddr)), The "-S" tries to remove the entry first, but it fails because it = doesn't exist. Luiz On Feb 13, 2010, at 12:30 AM, Brett Glass wrote: > P.S. -- It occurs to me that perhaps adding the word "only" at the end = of the command string used by mpd 5.3 might help. Should I try this? >=20 From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 05:04:29 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFCDB1065670; Sat, 13 Feb 2010 05:04:29 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0214A8FC18; Sat, 13 Feb 2010 05:04:28 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id WAA20359; Fri, 12 Feb 2010 22:04:18 -0700 (MST) Message-Id: <201002130504.WAA20359@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Feb 2010 22:04:13 -0700 To: Luiz Otavio O Souza From: Brett Glass In-Reply-To: <8192E832-3DD0-4D0A-9FAD-6A70CE59FD26@gmail.com> References: <201002130230.TAA19403@lariat.net> <8192E832-3DD0-4D0A-9FAD-6A70CE59FD26@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Li, Qing" , Alexander Motin , net@freebsd.org Subject: Re: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 05:04:29 -0000 At 07:42 PM 2/12/2010, Luiz Otavio O Souza wrote: >The "-S" tries to remove the entry first, but it fails because it >doesn't exist. As far as I can tell, the -S option doesn't cause the command to fail if no routing table entry already exists. It just deletes any route that does exist. Also, if you look at the code within mpd5 (the file iface.c), mpd first creates the proxy arp entry and then tries to add routes for the interface. So, using "-S" and also "only" in the arp(8) command would seem to be the right thing to do. This combination would remove any route that exists and not create a new one, ensuring that mpd itself could create new routes as needed. I have mpd working now with this change, and your patch seems to fix ppp(8). --Brett From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 05:08:16 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AA231065670; Sat, 13 Feb 2010 05:08:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D89A38FC16; Sat, 13 Feb 2010 05:08:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1D58Ftj077914; Sat, 13 Feb 2010 05:08:15 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1D58FP9077910; Sat, 13 Feb 2010 05:08:15 GMT (envelope-from linimon) Date: Sat, 13 Feb 2010 05:08:15 GMT Message-Id: <201002130508.o1D58FP9077910@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143855: [bpf] [patch] non-blocking BPF reads return -1/EWOULDBLOCK until the store buffer fills up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 05:08:16 -0000 Old Synopsis: non-blocking BPF reads return -1/EWOULDBLOCK until the store buffer fills up New Synopsis: [bpf] [patch] non-blocking BPF reads return -1/EWOULDBLOCK until the store buffer fills up Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Feb 13 05:07:35 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143855 From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 05:12:58 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8861106568D; Sat, 13 Feb 2010 05:12:58 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A2B5F8FC12; Sat, 13 Feb 2010 05:12:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1D5Cwih086153; Sat, 13 Feb 2010 05:12:58 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1D5CwCJ086149; Sat, 13 Feb 2010 05:12:58 GMT (envelope-from linimon) Date: Sat, 13 Feb 2010 05:12:58 GMT Message-Id: <201002130512.o1D5CwCJ086149@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143846: [gif] bringing gif3 tunnel down causes gif0 tunnel to stop working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 05:12:58 -0000 Old Synopsis: bringing gif3 tunnel down causes gif0 tunnel to stop working New Synopsis: [gif] bringing gif3 tunnel down causes gif0 tunnel to stop working Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Feb 13 05:12:39 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143846 From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 08:52:47 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90EE71065697; Sat, 13 Feb 2010 08:52:47 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 67DFB8FC16; Sat, 13 Feb 2010 08:52:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1D8qlYj008395; Sat, 13 Feb 2010 08:52:47 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1D8qlcs008391; Sat, 13 Feb 2010 08:52:47 GMT (envelope-from linimon) Date: Sat, 13 Feb 2010 08:52:47 GMT Message-Id: <201002130852.o1D8qlcs008391@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143868: [ath] [patch] allow Atheros watchdog timeout to be tunable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 08:52:47 -0000 Old Synopsis: allow Atheros watchdog timeout to be tunable New Synopsis: [ath] [patch] allow Atheros watchdog timeout to be tunable Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Feb 13 08:52:27 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143868 From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 18:04:56 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2AF01065670; Sat, 13 Feb 2010 18:04:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CC22D8FC14; Sat, 13 Feb 2010 18:04:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1DI4uwu025929; Sat, 13 Feb 2010 18:04:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1DI4ukW025925; Sat, 13 Feb 2010 18:04:56 GMT (envelope-from linimon) Date: Sat, 13 Feb 2010 18:04:56 GMT Message-Id: <201002131804.o1DI4ukW025925@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 18:04:57 -0000 Old Synopsis: Wireless 3945ABG error. wpi0 could not allocate memory resource New Synopsis: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Feb 13 18:04:30 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143874