From owner-freebsd-net@FreeBSD.ORG Sun Jun 30 05:15:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 38BFF29A; Sun, 30 Jun 2013 05:15:58 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 03511123D; Sun, 30 Jun 2013 05:15:57 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id kq13so3806260pab.39 for ; Sat, 29 Jun 2013 22:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GkH9ErJ5UsPKoHUWuk+qRzf8cJlfo8wtNiKOMg8hkOY=; b=lN9axW5rtz7GLC0L4+iVVgaEemtetXHrIb9CaEmswRJ836t72lll5lkGfLdGTVo54z F+mi0RdcDDeKf2rlrm8qNELZWbG7iVe29maymX8hSwP04kGm2rMOCFXmQFNEZOP2jzDT 5etaQJpXpBgItlXtYOSeNThkxaD3llV0rPZj7vcje97DJgmG10nyz3T4FZN6ONdxD3TG LZZMUgVSc+mUIx8vqDLJ4mq6X6RnVkwE6iHncHXWI9hKwJZvxF4lExUEK1ytaxxGGwqG DqYwDw4y+BGeSLc95nbhNbbm2/KXmR497V5UHBCzbPTXZYc5MBr2koAZdAYrNESAYe3M +N7Q== MIME-Version: 1.0 X-Received: by 10.68.196.167 with SMTP id in7mr18266433pbc.170.1372569357658; Sat, 29 Jun 2013 22:15:57 -0700 (PDT) Received: by 10.70.96.139 with HTTP; Sat, 29 Jun 2013 22:15:57 -0700 (PDT) Received: by 10.70.96.139 with HTTP; Sat, 29 Jun 2013 22:15:57 -0700 (PDT) In-Reply-To: References: <20130629002959.GB20376@nat.myhome> Date: Sun, 30 Jun 2013 08:15:57 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: "Paul A. Procacci" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-ipfw , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Jun 2013 05:15:58 -0000 Any buyers? :) I need your kindly help on this... Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 29 =D7=91=D7=99=D7=95=D7=A0 2013 09:50= , =D7=9E=D7=90=D7=AA "Sami Halabi" : > I think I was misunderstood... > Here is the situation i want to handle: > My box is a router that handles several /24 behind. > One of my links (em0) is connected to a private network 192.168.0.1 is me= , > my neighbour is 192.168.0.2. > I want to make that any connection comes to 192.168.0.1 to go to ip > 193.xxx.yyy.2 using specific public ip 84.xx.yy.1 > And packets comming to my public 84.xx.yy.1 ip to be trsnslated as came > from 192.168.0.1 and sent to 192.168.0.2/or ant other ips > behind(192.168.1.xx/24). > > Hope that makes it clearer, and I appreciate any help. > > Sami > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 29 =D7=91=D7=99=D7=95=D7=A0 2013 03:= 30, =D7=9E=D7=90=D7=AA "Paul A. Procacci" >: > >> > Hi, (sorry for sending again, the last email was with wrong subject) >> > I would like to perform a full dnat/snat as in iptbles in: >> > linux-ip.net/html/nat-dnat.html >> > How it can be done in fbsd, I use ipfw. >> > >> > I seeked natd man page but its translation, and thr proxy_rule is for >> > specefic port, not a whole transparancy. >> > >> >> Using in-kernel nat is probably a better choice IMHO. >> >> read `man ipfw(8)` >> >> The section labeled EXAMPLES has exactly what you need. >> Here is a snippet from the manpage to get you started: >> >> ------------------------------- >> >> >> Then to configure nat instance 123 to alias all the outgoing traffic wit= h >> ip 192.168.0.123, blocking all incoming connections, trying to keep same >> ports on both sides, clearing aliasing table on address change and keep- >> ing a log of traffic/link statistics: >> >> ipfw nat 123 config ip 192.168.0.123 log deny_in reset same_ports >> >> >> >> ipfw nat 123 config redirect_addr 10.0.0.1 10.0.0.66 >> redirect_port tcp 192.168.0.1:80 500 >> redirect_proto udp 192.168.1.43 192.168.1.1 >> redirect_addr 192.168.0.10,192.168.0.11 >> 10.0.0.100 # LSNAT >> redirect_port tcp 192.168.0.1:80, >> 192.168.0.10:22 >> 500 # LSNAT >> >> >> ------------------------------- >> >> >> ~Paul >> >> ________________________________ >> >> This message may contain confidential or privileged information. If you >> are not the intended recipient, please advise us immediately and delete >> this message. See http://www.datapipe.com/legal/email_disclaimer/ for >> further information on confidentiality and the risks of non-secure >> electronic communication. If you cannot access these links, please notif= y >> us by reply message and we will send the contents to you. >> > From owner-freebsd-net@FreeBSD.ORG Sun Jun 30 07:30:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4985F78 for ; Sun, 30 Jun 2013 07:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 23157160E for ; Sun, 30 Jun 2013 07:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5U7U1Zo075186 for ; Sun, 30 Jun 2013 07:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5U7U0fW075185; Sun, 30 Jun 2013 07:30:00 GMT (envelope-from gnats) Date: Sun, 30 Jun 2013 07:30:00 GMT Message-Id: <201306300730.r5U7U0fW075185@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Mikolaj Golub Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mikolaj Golub List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 07:30:01 -0000 The following reply was made to PR kern/179901; it has been noted by GNATS. From: Mikolaj Golub To: bug-followup@FreeBSD.org Cc: Michael Gmelin Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Date: Sun, 30 Jun 2013 10:17:05 +0300 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jun 27, 2013 at 11:00:16PM +0300, Mikolaj Golub wrote: > I don't insist on maintaining the old behaviour. But as actually we > have 2 issues here (regression introduced by me in FreeBSD9 and > historical behavior that looks wrong), with different priority, I > would like to fix the issues separately. This way it will be easier to > track the changes, e.g. when after a year it turns out that the second > change has broken some other case. Here is a patch for the second issue. -- Mikolaj Golub --EeQfGwPcQSOJBaQU Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="pr179901.2.1.patch" commit 7cf3a6a95d74ae91c80350fc1ae8e96fe59c3c65 Author: Mikolaj Golub Date: Sun Jun 30 00:09:20 2013 +0300 A complete duplication of binding should be allowed if on both new and duplicated sockets a multicast address is bound and either SO_REUSEPORT or SO_REUSEADDR is set. But actually it works for the following combinations: * SO_REUSEPORT is set for the fist socket and SO_REUSEPORT for the new; * SO_REUSEADDR is set for the fist socket and SO_REUSEADDR for the new; * SO_REUSEPORT is set for the fist socket and SO_REUSEADDR for the new; and fails for this: * SO_REUSEADDR is set for the fist socket and SO_REUSEPORT for the new. Fix the last case. PR: 179901 diff --git a/sys/netinet/in_pcb.c b/sys/netinet/in_pcb.c index 3506b74..eb15a38 100644 --- a/sys/netinet/in_pcb.c +++ b/sys/netinet/in_pcb.c @@ -554,7 +554,7 @@ in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, in_addr_t *laddrp, * and a multicast address is bound on both * new and duplicated sockets. */ - if (so->so_options & SO_REUSEADDR) + if ((so->so_options & (SO_REUSEADDR|SO_REUSEPORT)) != 0) reuseport = SO_REUSEADDR|SO_REUSEPORT; } else if (sin->sin_addr.s_addr != INADDR_ANY) { sin->sin_port = 0; /* yech... */ diff --git a/sys/netinet6/in6_pcb.c b/sys/netinet6/in6_pcb.c index a0a6874..fb84279 100644 --- a/sys/netinet6/in6_pcb.c +++ b/sys/netinet6/in6_pcb.c @@ -156,7 +156,7 @@ in6_pcbbind(register struct inpcb *inp, struct sockaddr *nam, * and a multicast address is bound on both * new and duplicated sockets. */ - if (so->so_options & SO_REUSEADDR) + if ((so->so_options & (SO_REUSEADDR|SO_REUSEPORT)) != 0) reuseport = SO_REUSEADDR|SO_REUSEPORT; } else if (!IN6_IS_ADDR_UNSPECIFIED(&sin6->sin6_addr)) { struct ifaddr *ifa; --EeQfGwPcQSOJBaQU-- From owner-freebsd-net@FreeBSD.ORG Sun Jun 30 09:16:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C88C05CA; Sun, 30 Jun 2013 09:16:02 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ04.datapipe-corp.net (exfesmq04.datapipe.com [64.27.120.68]) by mx1.freebsd.org (Postfix) with ESMTP id 77A7A189E; Sun, 30 Jun 2013 09:16:01 +0000 (UTC) Received: from nat.myhome (192.168.128.103) by EXFESMQ04.datapipe-corp.net (192.168.128.29) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 30 Jun 2013 05:14:50 -0400 Date: Sun, 30 Jun 2013 04:15:11 -0500 From: "Paul A. Procacci" To: Sami Halabi Subject: Re: DNAT in freebsd Message-ID: <20130630091511.GC20376@nat.myhome> References: <20130629002959.GB20376@nat.myhome> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.103] Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Jun 2013 09:16:02 -0000 On Sat, Jun 29, 2013 at 09:50:15AM +0300, Sami Halabi wrote: > I think I was misunderstood... > Here is the situation i want to handle: > My box is a router that handles several /24 behind. > One of my links (em0) is connected to a private network 192.168.0.1 is me= , > my neighbour is 192.168.0.2. > I want to make that any connection comes to 192.168.0.1 to go to ip > 193.xxx.yyy.2 using specific public ip 84.xx.yy.1 > And packets comming to my public 84.xx.yy.1 ip to be trsnslated as came > from 192.168.0.1 and sent to 192.168.0.2/or ant other ips > behind(192.168.1.xx/24). > > Hope that makes it clearer, and I appreciate any help. > > Sami > ???????????? 29 ???????? 2013 03:30, ?????? "Paul A. Procacci" : The answer I provided you does exactly what you want it to do. Not to ment= ion the man page goes over other things as well if the answer I provided you wasn't accurate. Here is my config that I use for my home setup. The config: - binds a nat instance on the primary interface - denies all inbound syn's among other things - Forward packets originating on the internal network interface through nat - and returns packets (ack's) back to the original sender. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! #!/bin/sh ###################### Start of IPFW Configuration #################### # Set rules command prefix :: Rule numbering cannot exceed 900 cmd=3D"/sbin/ipfw -q" pif=3D"de0" # Public NIC iif=3D"bridge0" # Internal NIC ############################################## # Flush current rules and do config. $cmd -f flush $cmd enable one_pass ############################################## ${cmd} add 00001 allow all from any to any via lo0 ${cmd} add 00002 deny all from any to 127.0.0.0/8 ${cmd} add 00003 deny ip from 127.0.0.0/8 to any ${cmd} nat 1 config if ${pif} log deny_in reset unreg_only same_ports ${cmd} add 00020 nat 1 all from any to any via ${pif} ${cmd} add 00050 allow all from any to any via ${iif} ${cmd} add 65534 deny log all from any to any !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Again, this information is found in `man ipfw(8)` and does what you are asking. ~Paul ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/legal/email_disclaimer/ for further inf= ormation on confidentiality and the risks of non-secure electronic communic= ation. If you cannot access these links, please notify us by reply message = and we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Sun Jun 30 10:23:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 128D3BD2; Sun, 30 Jun 2013 10:23:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 74D2519FB; Sun, 30 Jun 2013 10:23:04 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id r5UAMpt1034873; Sun, 30 Jun 2013 17:22:51 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <51D006F6.6060809@grosbein.net> Date: Sun, 30 Jun 2013 17:22:46 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Sami Halabi Subject: Re: DNAT in freebsd References: <20130629002959.GB20376@nat.myhome> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Paul A. Procacci" , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Jun 2013 10:23:06 -0000 On 29.06.2013 13:50, Sami Halabi wrote: > I think I was misunderstood... > Here is the situation i want to handle: > My box is a router that handles several /24 behind. > One of my links (em0) is connected to a private network 192.168.0.1 is me, > my neighbour is 192.168.0.2. > I want to make that any connection comes to 192.168.0.1 to go to ip > 193.xxx.yyy.2 using specific public ip 84.xx.yy.1 > And packets comming to my public 84.xx.yy.1 ip to be trsnslated as came > from 192.168.0.1 and sent to 192.168.0.2/or ant other ips > behind(192.168.1.xx/24). > > Hope that makes it clearer, and I appreciate any help. You need to setup 2 ipfw nat instanses, one to translate source IPs, another to translate destination IPs (this one needs "reverse" mode). From owner-freebsd-net@FreeBSD.ORG Sun Jun 30 11:46:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B432AAC6; Sun, 30 Jun 2013 11:46:46 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 8B8581C48; Sun, 30 Jun 2013 11:46:46 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kx10so4030379pab.41 for ; Sun, 30 Jun 2013 04:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3+Q2jqoAPE/gsorsYHFd720AqEFldXQd4kD8wuo0k54=; b=omqnpoAxNVwdpjRsr2i8SjeokfYdn16iF8MjeAiPf7D3GsPQzgwFYKMW7ZQwUpfsLX kg1DlZbY2Z0tNpottHu/QNzwHNKjqmFv1018qfAP9wODL5VF/J3LdQapHaOzojmNbBcc g5YHoE7LkZ+C7cIHgY+E0oF7zmg1OqP7+gbMKNh6gCFueFH5BfLZO2mmbpbe+6JTIvTa lEkbW2iOe+oDXDLxNgl2eLrRlKfMEBn1472fi6MyKpwd8oC+JCpxK81hXopR3gNXFpFN DZUQz9ALpooQthwRqZ8/SXBilJ8aVla2z9Fh2ZG/gVFjFau+zCa3HVLuitCm8z46HCdj q7SA== MIME-Version: 1.0 X-Received: by 10.67.3.99 with SMTP id bv3mr19245949pad.140.1372592806166; Sun, 30 Jun 2013 04:46:46 -0700 (PDT) Received: by 10.70.96.139 with HTTP; Sun, 30 Jun 2013 04:46:46 -0700 (PDT) In-Reply-To: <20130630091511.GC20376@nat.myhome> References: <20130629002959.GB20376@nat.myhome> <20130630091511.GC20376@nat.myhome> Date: Sun, 30 Jun 2013 14:46:46 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: "Paul A. Procacci" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Jun 2013 11:46:46 -0000 Hi, Thanks for your time. What this configuration does is normal NAT configuration (SNAT). what I'm seeking is combination of SNAT & DNAT to act as a transparent proxy as: 192.168.0.2 connects to me (192.168.0.1) it'll talk actually with 193.xx.yy.1 whithout knowing it using my special public ip 194.xx.yy.1, and when 193.xx.yy.1 wants to open connection with 192.168.0.2 it will connect to 194.xx.yy.1 and 192.168.0.2 will think 192.168.0.1 is talking with it... Any ideas??? Sami On Sun, Jun 30, 2013 at 12:15 PM, Paul A. Procacci wrote: > > On Sat, Jun 29, 2013 at 09:50:15AM +0300, Sami Halabi wrote: > > I think I was misunderstood... > > Here is the situation i want to handle: > > My box is a router that handles several /24 behind. > > One of my links (em0) is connected to a private network 192.168.0.1 is > me, > > my neighbour is 192.168.0.2. > > I want to make that any connection comes to 192.168.0.1 to go to ip > > 193.xxx.yyy.2 using specific public ip 84.xx.yy.1 > > And packets comming to my public 84.xx.yy.1 ip to be trsnslated as came > > from 192.168.0.1 and sent to 192.168.0.2/or ant other ips > > behind(192.168.1.xx/24). > > > > Hope that makes it clearer, and I appreciate any help. > > > > Sami > > ???????????? 29 ???????? 2013 03:30, ?????? "Paul A. Procacci" < > pprocacci@datapipe.com>: > > The answer I provided you does exactly what you want it to do. Not to > mention > the man page goes over other things as well if the answer I provided you > wasn't accurate. Here is my config that I use for my home setup. > > The config: > > - binds a nat instance on the primary interface > - denies all inbound syn's among other things > - Forward packets originating on the internal network interface through nat > - and returns packets (ack's) back to the original sender. > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > #!/bin/sh > ###################### Start of IPFW Configuration #################### > # Set rules command prefix :: Rule numbering cannot exceed 900 > > cmd="/sbin/ipfw -q" > pif="de0" # Public NIC > iif="bridge0" # Internal NIC > > ############################################## > # Flush current rules and do config. > $cmd -f flush > $cmd enable one_pass > ############################################## > > ${cmd} add 00001 allow all from any to any via lo0 > ${cmd} add 00002 deny all from any to 127.0.0.0/8 > ${cmd} add 00003 deny ip from 127.0.0.0/8 to any > > ${cmd} nat 1 config if ${pif} log deny_in reset unreg_only same_ports > ${cmd} add 00020 nat 1 all from any to any via ${pif} > > ${cmd} add 00050 allow all from any to any via ${iif} > > ${cmd} add 65534 deny log all from any to any > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > Again, this information is found in `man ipfw(8)` and does what you are > asking. > > ~Paul > > ________________________________ > > This message may contain confidential or privileged information. If you > are not the intended recipient, please advise us immediately and delete > this message. See http://www.datapipe.com/legal/email_disclaimer/ for > further information on confidentiality and the risks of non-secure > electronic communication. If you cannot access these links, please notify > us by reply message and we will send the contents to you. > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Sun Jun 30 11:48:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8DC1AB9E; Sun, 30 Jun 2013 11:48:34 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id 666A91C5E; Sun, 30 Jun 2013 11:48:34 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id y10so1933791pdj.14 for ; Sun, 30 Jun 2013 04:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VnHWADKg64yNnvTVWEdGGb5hS2iAcVtiqsojmlhdSi8=; b=vzfxykxM/hTf7wzLAtm+ur+6qS6pmJArkaTsw/o1lAiaElwUruGhRH8NkVeiBT9iAC eLZKGMvMhYLmp4I4lMV89s2GTMGFiWJXz3am2TATVvFtNd3RP20PMOBM67rNzZTZi0Of eDWkvtmgOSH84z3DlTIoSsWjnGBtPQQ9iUic1myvcWsXAWNF4q0R6L1qsjYP1jc4UIp7 04dh6vEr+4aGjdt+jUT8wSiRZi6NRDD8UEHZAzB7V8ZUwz1w0JDfVvO/1tVWr/lMjWe9 bdXe7c64gXFyz5PzhNkV/DYaR1AW1iPfYAnDKag2G8lIwXKRKtpo8K2eIL5EVc6f21aE 2YwQ== MIME-Version: 1.0 X-Received: by 10.68.50.69 with SMTP id a5mr19343086pbo.122.1372592914141; Sun, 30 Jun 2013 04:48:34 -0700 (PDT) Received: by 10.70.96.139 with HTTP; Sun, 30 Jun 2013 04:48:34 -0700 (PDT) In-Reply-To: <51D006F6.6060809@grosbein.net> References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> Date: Sun, 30 Jun 2013 14:48:34 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: Eugene Grosbein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , "Paul A. Procacci" , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Jun 2013 11:48:34 -0000 Hi, I don't understand how reverse mode works exactly, and didn't find a good example. can you try and help on the configuration? Thanks in advance, Sami On Sun, Jun 30, 2013 at 1:22 PM, Eugene Grosbein wrote: > On 29.06.2013 13:50, Sami Halabi wrote: > > I think I was misunderstood... > > Here is the situation i want to handle: > > My box is a router that handles several /24 behind. > > One of my links (em0) is connected to a private network 192.168.0.1 is > me, > > my neighbour is 192.168.0.2. > > I want to make that any connection comes to 192.168.0.1 to go to ip > > 193.xxx.yyy.2 using specific public ip 84.xx.yy.1 > > And packets comming to my public 84.xx.yy.1 ip to be trsnslated as came > > from 192.168.0.1 and sent to 192.168.0.2/or ant other ips > > behind(192.168.1.xx/24). > > > > Hope that makes it clearer, and I appreciate any help. > > You need to setup 2 ipfw nat instanses, one to translate source IPs, > another to translate destination IPs (this one needs "reverse" mode). > > > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Sun Jun 30 14:27:25 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 074425B9; Sun, 30 Jun 2013 14:27:25 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id A4ABB1025; Sun, 30 Jun 2013 14:27:24 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=dhcp170-36-red.yandex.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1UtIeG-0000lQ-Vk; Sun, 30 Jun 2013 18:30:41 +0400 Message-ID: <51D03FCE.1060102@FreeBSD.org> Date: Sun, 30 Jun 2013 18:25:18 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130418 Thunderbird/17.0.5 MIME-Version: 1.0 To: net@freebsd.org Subject: cxgbetool & hw filtering issues Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Navdeep Parhar X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Jun 2013 14:27:25 -0000 Hello list! While experimenting with Chelsio T440-CR (cxgbe) internal firewall, I'm getting some kind of unexpected results: filtering 'type ipv4 action drop' permits IPv4 TCP traffic with bad checksum. filtering 'type IPv6 action drop' permits IPv6 traffic to multicast addresses (MLDv2, etc..) filtering 'ethtype 34525 action drop' (drop all IPv6) results in 'CHELSIO_T4_SET_FILTER: Argument list too long' despite to what is said in budget table from cxgbetool.8 filtering 'matchtype 4 action drop' or similar (4,5,4:0,4:4, 5:0, 5:5) does not match anything despite some traffic definitely falls into that conditions. filtering 'action drop' and 'iport X action drop' filters IPv4 traffic only. filter 'type ipv6 ...' can be set on (0,4,8,12,...) filter numbers yelling 'CHELSIO_T4_SET_FILTER: Invalid argument' on other numbers. What can I do to debug further/fix this behavior? Some more questions: Does anybody known how I can get/set total number of HW firewall records? There is such tunable in Linux version. Is there any way to retrieve _host_ interface statistic (e.g. how much traffic in packets/bytes are thrown to NIC driver)? Setup description: [packet generator replaying small PCAP with 280kpps rate] -> cxgbe3 [[FreeBSD 10-CURRENT r248721]]. PCAP is captured on my host machine so 1) Outgoing TCP checksums are almost all wrong 2) DST macs are not modified (so they are all unknown to NIC). cxgbe3: flags=28943 metric 0 mtu 1500 options=6c00bb ether 00:07:43:11:88:d8 inet6 fe80::207:43ff:fe11:88d8%cxgbe3 prefixlen 64 scopeid 0x9 inet6 2a02:6b8:0:401:207:43ff:fe11:88d8 prefixlen 64 detached deprecated autoconf nd6 options=23 media: Ethernet 10Gbase-Twinax status: active dev.t4nex.0.%desc: Chelsio T440-CR NIC (rev 2), S/N:PT42110574, E/C:01234567890123 dev.t4nex.0.%driver: t4nex dev.t4nex.0.%location: slot=0 function=4 dev.t4nex.0.%pnpinfo: vendor=0x1425 device=0x4403 subvendor=0x1425 subdevice=0x0000 class=0x020000 dev.t4nex.0.%parent: pci8 dev.t4nex.0.nports: 4 dev.t4nex.0.hw_revision: 2 dev.t4nex.0.firmware_version: 1.8.4.0 dev.t4nex.0.cf: default dev.t4nex.0.cfcsum: 4260083439 dev.t4nex.0.linkcaps: 0 dev.t4nex.0.niccaps: 1 dev.t4nex.0.toecaps: 0 dev.t4nex.0.rdmacaps: 0 dev.t4nex.0.iscsicaps: 0 dev.t4nex.0.fcoecaps: 0 dev.t4nex.0.core_clock: 228125 dev.t4nex.0.holdoff_timers: 1 5 10 50 100 200 dev.t4nex.0.holdoff_pkt_counts: 1 8 16 32 dev.t4nex.0.fwq.abs_id: 0 dev.t4nex.0.fwq.cntxt_id: 0 dev.t4nex.0.fwq.cidx: 121 dev.t4nex.0.mgmtq.cntxt_id: 0 dev.t4nex.0.mgmtq.cidx: 95 dev.t4nex.0.mgmtq.pidx: 111 dev.t4nex.0.mgmtq.tx_wrs: 119 dev.t4nex.0.mgmtq.no_desc: 0 dev.t4nex.0.mgmtq.unstalled: 0 # kenv | grep cxgbe hw.cxgbe.fcoecaps_allowed="0" hw.cxgbe.iscsicaps_allowed="0" hw.cxgbe.nrxq10g="4" hw.cxgbe.ntxq10g="4" hw.cxgbe.qsize_rxq="4096" hw.cxgbe.qsize_txq="4096" hw.cxgbe.rdmacaps_allowed="0" hw.cxgbe.toecaps_allowed="0" TRAFFIC PART: input (cxgbe3) output packets errs idrops bytes packets errs bytes colls 284368 0 0 85436494 0 0 0 0 284340 0 0 85442168 0 0 0 0 284205 0 0 85464055 0 0 0 0 ... (not changing, nearly constant rate, is not affected by filters) # ipfw show 200 00200 16860 2685762 deny ip from any to any via cxgbe3 # Running counter to see how much is actually dropped/passed # while true; do sleep 1; ipfw show 200 ; ipfw -q zero 200 ;done [[ empty filters ]] 00200 281769 80351685 deny ip from any to any via cxgbe3 .. [[ ### (1) IPv4 EXPERIMENT ]] [[ # ./cxgbetool t4nex0 filter 0 type ipv4 action drop ]] 00200 115263 15431259 deny ip from any to any via cxgbe3 00200 116523 15584332 deny ip from any to any via cxgbe3 [[# time tcpdump -i cxgbe3 -lnps0 -c 100 ip 18:18:42.621728 IP 95.108.170.36.39215 > 93.158.158.93.80: Flags [.], ack 4252241156, win 995, options [nop,nop,TS val 538195932 ecr 1194270183], length 0 .. tcpdump -i cxgbe3 -lnps0 -c 100 ip 0,00s user 0,01s system 15% cpu 0,059 total #]] [[ ### (2) IPv6 EXPERIMENT ]] [[ # ./cxgbetool t4nex0 filter 4 type ipv6 action drop ]] 00200 64962 10332022 deny ip from any to any via cxgbe3 00200 64878 10327694 deny ip from any to any via cxgbe3 ... [[# time tcpdump -i cxgbe3 -lnps0 -c 100 ip6 18:21:34.553596 IP6 fe80::884:a1e8:86ae:57f7 > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 .. tcpdump -i cxgbe3 -lnps0 -c 100 ip6 0,00s user 0,00s system 0% cpu 0,483 total #]] Address in (1) is my host machine address, viewing resulting .pcap file in wireshark shows incorrect TCP checksums for IPv4 packets. Other pcaps not containing "bad" traffic are properly filtered by rules above. From owner-freebsd-net@FreeBSD.ORG Sun Jun 30 15:33:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AA520193; Sun, 30 Jun 2013 15:33:19 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 0B236119C; Sun, 30 Jun 2013 15:33:18 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id r5UFX1ri036097; Sun, 30 Jun 2013 22:33:01 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <51D04FA8.8080900@grosbein.net> Date: Sun, 30 Jun 2013 22:32:56 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Sami Halabi Subject: Re: DNAT in freebsd References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "Paul A. Procacci" , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Jun 2013 15:33:19 -0000 On 30.06.2013 18:48, Sami Halabi wrote: > Hi, > I don't understand how reverse mode works exactly, and didn't find a good example. > > > can you try and help on the configuration? Well, that's pretty simple. Generally, NAT translates source IP address of the packet keeping destination IP intact. You need both of source and destination addresses get translated. Reverse NAT translates does, well, reverse thing: it translates destination IP keeping source IP intact. So, you just need setup two ipfw nat instances, one "general" and one "reverse" and pass your packets through both instances. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Jun 30 16:05:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 530228ED for ; Sun, 30 Jun 2013 16:05:05 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm15-vm6.bullet.mail.ne1.yahoo.com (nm15-vm6.bullet.mail.ne1.yahoo.com [98.138.91.108]) by mx1.freebsd.org (Postfix) with ESMTP id DF719128E for ; Sun, 30 Jun 2013 16:05:04 +0000 (UTC) Received: from [98.138.90.56] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jun 2013 16:04:58 -0000 Received: from [98.138.89.168] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jun 2013 16:04:58 -0000 Received: from [127.0.0.1] by omp1024.mail.ne1.yahoo.com with NNFMP; 30 Jun 2013 16:04:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 742790.15695.bm@omp1024.mail.ne1.yahoo.com Received: (qmail 87672 invoked by uid 60001); 30 Jun 2013 16:04:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372608298; bh=gg1c787/2M8+f1k94aN9rePcgQ15G7nqR7eNHSgzXjM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=f0KZk2r6wcoLkLvaNkFl9Fo2O/8m+RugRBiYqxc2CpqXEyM9Yb+SwHYhm6rpdR9XMVHPw6L0rSKYlcBEH3XtelgyxtAqJ9T7HfIq+VdB/kdBLC9yeSDN/6tUKLJAcREniuhQAc8ZouyvEy8zJQwPfiHF5re03TiCT3S6vH0Tw8c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=B6FKJ5XLAy9qzsGq82c/lO3s0JDWctJPdEq5EUexovmCwHKg5Y77GezXLAZEkhPSZyX7UFr4AgMdPrM9PnMLhzDfzdw2kAbf6fC9qJxuGZ3pfIlkqNDVBKk4CsADefBzU36ga+nfLbKC45Fvv45XOpavT/RhEROBifhx2FIEn34=; X-YMail-OSG: 6v.H7q0VM1nS7b_XQQk0OpKsU4n.acDdrlATBV8doQ7J7Ye o7Q3lU67lNfJBCSiIu7DhI08SNf4O5lVdSMjJJyKkjxtpWprZR.wDzmpHZfV QSDec6M2t3xKC9zaM4eVwMCiA8mxWAkrEFB49VbRPAh9.0U2RFIySXTrra49 0.pBfQ_8VqCZoc8gBYbjsgaKCtqNM2FFGIQH1aEWD3idVTAjXPufIT_TdyR6 E_b52Ce8Kw2rLe4nq8N.3aQptJCGXGjLTvVs5MmbfPt_0J1o9yZyyfyNRo12 q0WPmS4KAoXm_gSqNwNd7r9uA93gl.RmMnIdfR3YE_yml95e26boObUUUlrm ndR0G6ztUZ36WTeCoNzbOwo8.p.Xc5e2Mqr9gytrs4GHhb.2n0ZoGCtaiKeR 81hWIFv9nGf4VMLtaBVbmpLLBA38aa1E7z5XOhJrdV2_qSlE1TZRddyUWGQq JAEsaqddKSfEceg_c.DdWI4dQ_vRScMesPxrtXFN0sui_lnBv.LY2WfEpObS m89E6TnX2uFgEfouHHpYvy0Qa8VNPJGboDnmrdKDHj7rtug2V79MFSQNe8Xc kspvUf5Psfl2rIf.Pmqd6gtGgjKl..w-- Received: from [98.203.118.124] by web121601.mail.ne1.yahoo.com via HTTP; Sun, 30 Jun 2013 09:04:58 PDT X-Rocket-MIMEInfo: 002.001, T25lIHBhcnRpY3VsYXIgYW5ub3lhbmNlIHdpdGggRnJlZWJzZCBpcyB0aGF0IGRpZmZlcmVudCBOSUNzIGhhdmUgZGlmZmVyZW50IGRvcm1hbnQgYmVoYXZpb3IuDQoNCkZvciBleGFtcGxlIGVtIGFuZCBpZ2IgYm90aCB3aWxsIHNob3cgdGhlIGxpbmsgYmVpbmcgYWN0aXZlIG9yIG5vdCBvbiBib290IHdoZXRoZXIgdGhlIGludGVyZmFjZQ0KaGFzIGJlZW4gVVBlZCBvciBub3QsIHdoaWxlIGl4Z2JlIGFuZCBiY2UgZG8gbm90LiANCg0KSSB0aGluayBpdCdzIGEgd29ydGh5IGdvYWwgdG8gaGF2ZSBOSUNzIHcBMAEBAQE- X-Mailer: YahooMailClassic/223 YahooMailWebService/0.8.148.557 Message-ID: <1372608298.77405.YahooMailBasic@web121601.mail.ne1.yahoo.com> Date: Sun, 30 Jun 2013 09:04:58 -0700 (PDT) From: Barney Cordoba Subject: Inconsistent NIC behavior To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Jun 2013 16:05:05 -0000 One particular annoyance with Freebsd is that different NICs have different dormant behavior. For example em and igb both will show the link being active or not on boot whether the interface has been UPed or not, while ixgbe and bce do not. I think it's a worthy goal to have NICs work the same in this manner. It's very valuable to know that a nic is connected without having to UP it. And an annoyance when you fire up a new box with a new nic that shows No Carrier when the link light is on. It's really too much of a project for one person to have enough knowledge of multiple drivers to make the changes, so it would be best if the maintainers would do it. BC From owner-freebsd-net@FreeBSD.ORG Sun Jun 30 19:41:17 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3E4FCFBA; Sun, 30 Jun 2013 19:41:17 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id 1648F1991; Sun, 30 Jun 2013 19:41:17 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id wz7so4054274pbc.9 for ; Sun, 30 Jun 2013 12:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NQfzf95BFZbIkJ1WhFqFhLtMXraSUcisEhHbj3vje2U=; b=Ge56S0IeVtg6XZHkW1idOKTG9D83dnDItMWeVOyGXGprAFz4N6jZqwgvByL9L2Ttw1 chxym8mMfa1U6ULglZupYEInifKZYqsWphXQPclSNxy2ezuZXqC0gaoFDsUFFuq+gzkA d3F3zGU0ZITu2nWy2tTQHI5Vc3zIVBrNf+TwzwJdhcAP4GSj1BnzBs27RDCbMHe0QBlk 2I2NzvFOU/FOaYgxOlAJU2CcZSyAU2uUK19KyMomkiR2xBtbkc1DR1Intle5b0eSor8P H96EcVBkJzqrN3Jf2jXc4EYs+iLYPK7dOYUQ1Rm/3UuAMJw0HDdUxqlSOi2EKS42aBVP PwGg== X-Received: by 10.68.14.6 with SMTP id l6mr20751193pbc.202.1372621276770; Sun, 30 Jun 2013 12:41:16 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id tq8sm18494277pbc.30.2013.06.30.12.41.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Jun 2013 12:41:15 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <51D089D9.6080901@FreeBSD.org> Date: Sun, 30 Jun 2013 12:41:13 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130627 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: cxgbetool & hw filtering issues References: <51D03FCE.1060102@FreeBSD.org> In-Reply-To: <51D03FCE.1060102@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Jun 2013 19:41:17 -0000 On 06/30/13 07:25, Alexander V. Chernikov wrote: > Hello list! > > While experimenting with Chelsio T440-CR (cxgbe) internal firewall, I'm > getting some kind of unexpected results: One bit of general advice to begin with: add "hitcnts 1" to all your filter rules and then you can see how many incoming packets hit that filter in the output of "cxgbetool t4nex0 filter list". I really should make hitcnts=1 the default in the driver. > filtering 'type ipv4 action drop' permits IPv4 TCP traffic with bad > checksum. It may be that a bad checksum makes it an invalid IPv4 packet to the chip and so it doesn't hit the "type ipv4" rule. There is an entirely separate knob available to have the chip drop bad packets if you don't want to see them. The default is to let them through so that users can examine them with tcpdump etc. > filtering 'type IPv6 action drop' permits IPv6 traffic to multicast > addresses (MLDv2, etc..) The DMAC is an L2 multicast address? Try "proto 58 hitcnts 1 action drop" to get these ICMP6 packets. > filtering 'ethtype 34525 action drop' (drop all IPv6) results in > 'CHELSIO_T4_SET_FILTER: Argument list too long' despite to what is said > in budget table from cxgbetool.8 This _would_ have gotten everything with ethertype ipv6 but the default filter mode doesn't have ethtype enabled, which is why it's complaining: # cxgbetool t4nex0 filter mode ipv4 ipv6 sip dip sport dport matchtype proto ivlan iport fcoe > filtering 'matchtype 4 action drop' or similar (4,5,4:0,4:4, 5:0, 5:5) > does not match anything despite some traffic definitely falls into that > conditions. > filtering 'action drop' and 'iport X action drop' filters IPv4 traffic > only. Strange. I use "iport X action drop hitcnts 1" as a packet black hole all the time. Were these the only filters when you tried them? Are you sure your packets didn't hit some other rule and were delivered as a result of that? Check the order in "cxgbetool t4nex0 filter list" Also, are you going by the ifnet rx stats as displayed by netstat etc.? Right now the driver fills the ifnet stats directly from hardware registers rather than counting the packets that it actually received from the chip. The hardware registers include packets that would have been delivered to the driver if no filters were present but are dropped due to a filter. > filter 'type ipv6 ...' can be set on (0,4,8,12,...) filter numbers > yelling 'CHELSIO_T4_SET_FILTER: Invalid argument' on other numbers. Yes, IPv6 filters take 4 tid's (non-IPv6 take 1) and these tid's have to start at a naturally aligned boundary. No way around this. > What can I do to debug further/fix this behavior? > > Some more questions: > Does anybody known how I can get/set total number of HW firewall > records? There is such tunable in Linux version. I will add a simple sysctl for this. For now you can indirectly figure this out from the output of "sysctl -n dev.t4nex.0.misc.tids" -- the FTIDs are the filter tids. For example I see 1456 filters on this card: trantor:~# sysctl -n dev.t4nex.0.misc.tids ATID range: 0-8191, in use: 0 TID range: 2048-18431, in use: 0 STID range: 0-511, in use: 0 FTID range: 512-1967 HW TID usage: 0 IP users, 0 IPv6 users trantor:~# echo $((1967 - 512 + 1)) 1456 > Is there any way to retrieve _host_ interface statistic (e.g. how much > traffic in packets/bytes are thrown to NIC driver)? cxgbe(4) doesn't count this stuff itself. Currently it just reads the hardware registers once per second and it's done. Software stats would have to be per queue (and then aggregated from time to time). I'll wait to see where the PCPU counter work in the kernel goes before reworking this part of the driver. Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Sun Jun 30 20:27:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 98A81BC1; Sun, 30 Jun 2013 20:27:02 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by mx1.freebsd.org (Postfix) with ESMTP id 704C11AB1; Sun, 30 Jun 2013 20:27:02 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id p10so2089017pdj.22 for ; Sun, 30 Jun 2013 13:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TfDgrVxJL97/2ej+sxQZasnhfjjOL9gNarzZM+NA4n8=; b=jW/dN86WSgISpahtrkT8TKVqJSQcTVj+vnK7BMKE3rkUqCA6X0zXFaFVYaAWeH5+zY lN73zJlGVji1Ai4vygaolf3lNkzD/3vR9/vFzvW1OM7oArTTYXt+wQnZmTaaYDspz/7u c2dPbE8jXqwP/dvqoGGPEGeh6tCNir4HuSzceyWgXHpvfInVAtMtnxsOX6nkE2gU7640 6Eo/xFhpJHD9f5dtAbCipoaGhVh0PSP0/PVLpGS97LONQ5nOYo5pfnLGQtIgZpMBiGEN q5J7mCgpLDow606GkiYjcHRlAiSXQIh9+J7ZD4fBhAu6jTuLHxJsHwFlP2YkAeQrVaZL 7ycw== MIME-Version: 1.0 X-Received: by 10.66.179.78 with SMTP id de14mr20399981pac.18.1372624022285; Sun, 30 Jun 2013 13:27:02 -0700 (PDT) Received: by 10.70.71.7 with HTTP; Sun, 30 Jun 2013 13:27:02 -0700 (PDT) In-Reply-To: <51D04FA8.8080900@grosbein.net> References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> Date: Sun, 30 Jun 2013 23:27:02 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: Eugene Grosbein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , "Paul A. Procacci" , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Jun 2013 20:27:02 -0000 Hi Eugene, It simply doesn't work for me, the reverse option doesn't work properly for me.... it keeps translating the source instead of the destination... On Sun, Jun 30, 2013 at 6:32 PM, Eugene Grosbein wrote: > On 30.06.2013 18:48, Sami Halabi wrote: > > Hi, > > I don't understand how reverse mode works exactly, and didn't find a > good example. > > > > > > can you try and help on the configuration? > > Well, that's pretty simple. Generally, NAT translates source IP address of > the packet > keeping destination IP intact. You need both of source and > destination addresses get translated. Reverse NAT translates does, > well, reverse thing: it translates destination IP keeping source IP intact. > So, you just need setup two ipfw nat instances, one "general" and one > "reverse" > and pass your packets through both instances. > > Eugene Grosbein > > > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Sun Jun 30 23:48:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA889713 for ; Sun, 30 Jun 2013 23:48:54 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id 8086B1022 for ; Sun, 30 Jun 2013 23:48:54 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id m1so3288768ves.28 for ; Sun, 30 Jun 2013 16:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+8vpWdIg5kdkXZT5skyRFYfibdmdoqKHyhMyazWkGEQ=; b=MLW6dFBSz6gn+3adWzTkMlqJTjNH7+kH5MZ/btlCy7walLXcaTV/l8XqVnX4ZO56LA EyJGjQCicAXr06AS53um+/GwxSgfnBY8SQjNd9bHaCakRpfwK1lf6MGFusqMSlg/WfRO 6lQUSNFmuM2fdxRe9GquQ8nhow5jjHsl3CB62OVHZKt1bKy1G5RhyVwHUnBNxz8EHX3k TpnJ4AbBh9P20OaQqGbM2d7NV9NwN/NOeFT5zFV3TGAOxJ38PTcbcpNTndaRFb/Z+9WB 7xEzBtey/fxVg2T31e8v/LjXBuOrN+lmfHGxhUaT+RhED+3JN5K6dLoCXNmCtir/gOLt SFGg== MIME-Version: 1.0 X-Received: by 10.52.92.171 with SMTP id cn11mr7208227vdb.10.1372636132698; Sun, 30 Jun 2013 16:48:52 -0700 (PDT) Received: by 10.220.194.133 with HTTP; Sun, 30 Jun 2013 16:48:52 -0700 (PDT) Date: Sun, 30 Jun 2013 19:48:52 -0400 Message-ID: Subject: Duplicate Address Detection misfire? From: Zaphod Beeblebrox To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Jun 2013 23:48:54 -0000 I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the "bridged" type of networking with VMWare. It gets it's IPv4 address from DHCP (successfully) and then fails to initialize IPv6. The relevant rc.conf is: ipv6_activate_all_interfaces="YES" ifconfig_em0_ipv6="inet6 accept_rtadv" ip6addrctl_verbose="YES" The console output says: em0: DAD detected duplicate IPv6 address fe80:2::20c:29ff:fe0a:3989: NS in/out=2/1, NA in=0 em0: DAD complete for fe80:2::20c:29ff:fe0a:3989 - duplicate found em0: manual intervention required em0: possible hardware address duplication deteted, disable IPv6 And subsequently, em0's nd6 has "IFDISABLED" in it. With wireshark, I see two ICMPv6 neighbor solicitations that are identical --- is this the problem? How do I fix this? From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 00:19:14 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 309E7C46 for ; Mon, 1 Jul 2013 00:19:14 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0901136 for ; Mon, 1 Jul 2013 00:19:13 +0000 (UTC) Received: from alph.d.allbsd.org (p3086-ipbf906funabasi.chiba.ocn.ne.jp [122.26.46.86]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r610Isjx071962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 09:19:05 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r610IqUE043060; Mon, 1 Jul 2013 09:18:54 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 01 Jul 2013 09:18:00 +0900 (JST) Message-Id: <20130701.091800.431052507291100682.hrs@allbsd.org> To: zbeeble@gmail.com Subject: Re: Duplicate Address Detection misfire? From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Jul__1_09_18_00_2013_865)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Mon, 01 Jul 2013 09:19:05 +0900 (JST) X-Spam-Status: No, score=-89.3 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,ONLY1HOPDIRECT,QENCPTR1,RCVD_IN_PBL,SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 00:19:14 -0000 ----Security_Multipart(Mon_Jul__1_09_18_00_2013_865)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zaphod Beeblebrox wrote in : zb> I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the zb> "bridged" type of networking with VMWare. It gets it's IPv4 address from zb> DHCP (successfully) and then fails to initialize IPv6. The relevant zb> rc.conf is: zb> zb> ipv6_activate_all_interfaces="YES" zb> ifconfig_em0_ipv6="inet6 accept_rtadv" zb> ip6addrctl_verbose="YES" zb> zb> The console output says: zb> zb> em0: DAD detected duplicate IPv6 address fe80:2::20c:29ff:fe0a:3989: NS zb> in/out=2/1, NA in=0 zb> em0: DAD complete for fe80:2::20c:29ff:fe0a:3989 - duplicate found zb> em0: manual intervention required zb> em0: possible hardware address duplication deteted, disable IPv6 zb> zb> And subsequently, em0's nd6 has "IFDISABLED" in it. zb> zb> With wireshark, I see two ICMPv6 neighbor solicitations that are identical zb> --- is this the problem? zb> zb> How do I fix this? Does your host environment have the same address on the bridged interface? -- Hiroki ----Security_Multipart(Mon_Jul__1_09_18_00_2013_865)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHQyrgACgkQTyzT2CeTzy1E3gCg30hIUA69yv4x+/tY5ScVO3EB 3cgAoKenc6fQfiwICnhR6oVkzJrZNZZ/ =624S -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Jul__1_09_18_00_2013_865)---- From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 02:39:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 220AC40E for ; Mon, 1 Jul 2013 02:39:09 +0000 (UTC) (envelope-from kevin@your.org) Received: from mail.your.org (mail.your.org [IPv6:2001:4978:1:2::cc09:3717]) by mx1.freebsd.org (Postfix) with ESMTP id CA88916DE for ; Mon, 1 Jul 2013 02:39:08 +0000 (UTC) Received: from mail.your.org (chi02.mail.your.org [204.9.55.23]) by mail.your.org (Postfix) with ESMTP id 5412CF06C22; Mon, 1 Jul 2013 02:39:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=your.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=pC3Zv2wsrMwDqaQBzR4/vNhtNDU=; b= bD80e4TM0j8KTle00A7xl3HOlgy45CbMRfrhEcnZDqk/+6CZ9qeYP0npFppRSNPF cjTL3qztRyWaBHawdXs1txxUzrwt+G4/gix/nb73wC05Hk9v/gIYcWegvQ8S6Ki3 YbdgI6OKrSvwu6RlM4C2HPptFrowdMhNbmojLDwv1vg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=your.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=XN2cMXjjAE5t2UgjnvT9I3hbx9 DcKWWSZXKTEjGmiF0HbZt5go93Q6TExDmpc2EIfo7jw3dgCYexWKMaxbwqywZsfz 9DqqcwLUcfsnHOss/guzAvarJsITKllSTDP5slokDWqj591m036EqNcEBscLMMFh VgvJwWjLIROFn4EZc= Received: from unassigned.v6.your.org (unknown [IPv6:2001:4978:1:45:f505:2b6c:dff2:f5a9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTPSA id D6CA6F06C1F; Mon, 1 Jul 2013 02:39:07 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_43288E98-F252-4279-A13E-3BEBA8FDC34B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Duplicate Address Detection misfire? From: Kevin Day In-Reply-To: Date: Sun, 30 Jun 2013 21:39:05 -0500 Message-Id: <06BA4BD5-BE4E-4184-AFBB-D7FD4B2597D9@your.org> References: To: Zaphod Beeblebrox X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 02:39:09 -0000 --Apple-Mail=_43288E98-F252-4279-A13E-3BEBA8FDC34B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 30, 2013, at 6:48 PM, Zaphod Beeblebrox = wrote: > I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the > "bridged" type of networking with VMWare. It gets it's IPv4 address = from > DHCP (successfully) and then fails to initialize IPv6. The relevant > rc.conf is: >=20 > ipv6_activate_all_interfaces=3D"YES" > ifconfig_em0_ipv6=3D"inet6 accept_rtadv" > ip6addrctl_verbose=3D"YES" >=20 > The console output says: >=20 > em0: DAD detected duplicate IPv6 address fe80:2::20c:29ff:fe0a:3989: = NS > in/out=3D2/1, NA in=3D0 > em0: DAD complete for fe80:2::20c:29ff:fe0a:3989 - duplicate found > em0: manual intervention required > em0: possible hardware address duplication deteted, disable IPv6 >=20 > And subsequently, em0's nd6 has "IFDISABLED" in it. >=20 > With wireshark, I see two ICMPv6 neighbor solicitations that are = identical > --- is this the problem? >=20 > How do I fix this? Did you copy this VM and have both copies running at once? If so, it = assigned the same MAC address to each VM.=20 VMware is suppose to detect this and ask if you "copied" or "moved" the = VM, and if you say "copied" it will randomly assign a new MAC to the VM. = If this didn't happen or if you said "moved" when you actually copied = it, just go in and delete/re-create the network interface in the VM's = settings to create a new MAC for it. If that's not the issue, we'd probably need more details about your = configuration. --Apple-Mail=_43288E98-F252-4279-A13E-3BEBA8FDC34B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPITCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBR4wggQGoAMC AQICEQDX7payXlJleRO8EofThBYfMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMDYxNjAwMDAwMFoXDTE0MDYxNjIzNTk1OVowHzEdMBsGCSqG SIb3DQEJARYOa2V2aW5AeW91ci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ +8pMP5JQB9JNtJMBToSs0n8raC/nLnXvgLO1W2ab2h5z/9tmUhIaYF5GXsPTcstp3rWGY85yMgC6 fFVzgo8eiCz0jbiuwH5VKry7WSdUh3ZLGkVfMYaSOh1BjAN7AUEC/k4F5XAmPr8OfEUi1sEY/7Ot wWMankm0N2QdKyffrcFkiRlxHb4uoNcY+a0R8RSv0ILDH5xlRDx67XpuJ1hg6YCz4Xv/NdEe4H/Y Ek/ulaFICLTOxf4KvOI6Tq4ZaV+j/rzkBkmjRAtI522Uml4uwYaXvKzxj+l6Ezm5wLvf1zaQL/8l e7JgwK2eV3wuDqO7gNDpx9lpSDACioolMy55AgMBAAGjggHeMIIB2jAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUv94xWfNBA4IaXtCd/3dmO3GpZoowDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWls Q0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2Eu Y29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAZBgNVHREEEjAQgQ5rZXZpbkB5b3VyLm9y ZzANBgkqhkiG9w0BAQUFAAOCAQEAFs2L7FssxGKC4+3j40bFG0FIp1LIZwczT4b16Y3zprZZ09/T ojYAsVQfNCbvSNcGAoiYRpr5/lrbRq+OYHwb4CYlt6k0XFhlRccDqYadmzVSEgiGUpGn9GDtjwRL QvmAVYFj/up2uythSNmIM3J/2kS5U9MX+lbzHhX7GVhtWB8Y8q6F4L3rr4CW3RE4vE+hUY1LXW0t sQkWpM8XCyrAiTeb3O5IqdqrfHG77iEfbPWM8VF3XMbjEp/iitripx7xci44BXaUEYk0M6bN80rf s+INL5Fo5DzEAbOuST4rgLM1ZkzljpCESGOm5A3JxMTcXEdjWCuAUlTZEp3QmcIqxjGCA64wggOq AgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RP IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA1+6Wsl5SZXkTvBKH 04QWHzAJBgUrDgMCGgUAoIIB2TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMzA3MDEwMjM5MDVaMCMGCSqGSIb3DQEJBDEWBBRhX3BuMHZJ0CNJy/vZ3qko6fqiWTCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcG A1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA 1+6Wsl5SZXkTvBKH04QWHzCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJBgNVBAYTAkdCMRsw GQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFu ZCBTZWN1cmUgRW1haWwgQ0ECEQDX7payXlJleRO8EofThBYfMA0GCSqGSIb3DQEBAQUABIIBAIIm GS80vUTcxyArQoLieIrfdUyqedtJQDwKskmLLjsbuMJ95kkEnxev4FFdGB6PxNO4hC6DqDiqw77y MNsi1u9Br+SFgWHoxuK8I2Sbj3Y6MvalPk13kAalKhMgY6OJvxLxjMSS125UiuxBx556srZJMQ/D 4ZlNAzqZ/FJb/Hs7UKMv+0bapqvAp+EBehRZfob1bAeexelFcguvzixr2ukexYtrv1B01wlMCnOa dZRUh+mk6h681AMQuXQWVv9Q7pk97ZtWLyMYel0/fjV6o05oAgb0fJrD6fee4B3zOK1/CzrW1QHE MWDCL0gwFzcqUbgUnP0RkaOAm8LiVvSDceIAAAAAAAA= --Apple-Mail=_43288E98-F252-4279-A13E-3BEBA8FDC34B-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 07:30:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6240BE68; Mon, 1 Jul 2013 07:30:19 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id 396BE12AB; Mon, 1 Jul 2013 07:30:19 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id ma3so4478470pbc.21 for ; Mon, 01 Jul 2013 00:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cLigPQSbNHcbGbeLgUFZmy/FWIiMryDw8Rb0O29PLc8=; b=Ypa1Ffj5L3AoL51y/BKMDv0o6hZpHigRVZanxcUW2CGFyOBwO54NzWYGggJsT/JGSg LpVnAng/okt9FwIa7cRofyZJS4UWFdrJD7U6zAsBPQO8UjodFM7PJ2yDPpXJiu7RXzem tmD34Qmb5SsfDH+tcPFVdueGEE15L1yh0wpZDXzZYr/+KaE3MShoTtEPMOptXK6haTpJ qF24xkKKQ0EgA2Y96sD/2M5zuKNX3SxhVuPPuys24HX1GLo2d0sqmsJswjh0A0c6WVZY v9zqPkatFK9F6gpsuSx7KhsN13E30TSolcIx7VLlQOWzX+8nbyDGEtzvYuAYJJ64quxw OuZw== MIME-Version: 1.0 X-Received: by 10.68.35.131 with SMTP id h3mr22567607pbj.140.1372663818975; Mon, 01 Jul 2013 00:30:18 -0700 (PDT) Received: by 10.70.71.7 with HTTP; Mon, 1 Jul 2013 00:30:18 -0700 (PDT) In-Reply-To: References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> Date: Mon, 1 Jul 2013 10:30:18 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: Eugene Grosbein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , "Paul A. Procacci" , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 07:30:19 -0000 Hi, I've tried the following: em1 - ip 10.0.1.1/24 em2 - ip 11.0.3.1/24 route add 11.0.4.0/24 11.0.3.2 ipfw flush ipfw add 1000 nat 1 all from 10.0.1.2 to 10.0.1.1 ipfw add 2000 nat 2 all from 11.0.3.1 to 10.0.1.1 ipfw add 3000 nat 2 all from 11.0.4.2 to 11.0.3.1 ipfw add 4000 nat 1 all from 10.0.1.1 to 11.0.3.1 ipfw nat 1 config same_ports ureg_only ip 11.0.3.1 ipfw nat 1 config reverse same_ports ureg_only ip 11.0.4.2 what i see in tcpdump and logs is that the rule 1000 converts the ip correctly 10.0.1.2->10.0.1.1 ==> 11.0.3.1->10.0.1.1 while the 2000 rule does nothing... Thanks in advance, Sami On Sun, Jun 30, 2013 at 11:27 PM, Sami Halabi wrote: > Hi Eugene, > > It simply doesn't work for me, the reverse option doesn't work properly > for me.... it keeps translating the source instead of the destination... > > > On Sun, Jun 30, 2013 at 6:32 PM, Eugene Grosbein wrote: > >> On 30.06.2013 18:48, Sami Halabi wrote: >> > Hi, >> > I don't understand how reverse mode works exactly, and didn't find a >> good example. >> > >> > >> > can you try and help on the configuration? >> >> Well, that's pretty simple. Generally, NAT translates source IP address >> of the packet >> keeping destination IP intact. You need both of source and >> destination addresses get translated. Reverse NAT translates does, >> well, reverse thing: it translates destination IP keeping source IP >> intact. >> So, you just need setup two ipfw nat instances, one "general" and one >> "reverse" >> and pass your packets through both instances. >> >> Eugene Grosbein >> >> >> > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 08:29:34 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4F1D6687; Mon, 1 Jul 2013 08:29:34 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id F00C91716; Mon, 1 Jul 2013 08:29:33 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=dhcp170-36-red.yandex.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1UtZXW-000APL-0F; Mon, 01 Jul 2013 12:32:50 +0400 Message-ID: <51D13D6D.7030603@FreeBSD.org> Date: Mon, 01 Jul 2013 12:27:25 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130418 Thunderbird/17.0.5 MIME-Version: 1.0 To: Navdeep Parhar Subject: Re: cxgbetool & hw filtering issues References: <51D03FCE.1060102@FreeBSD.org> <51D089D9.6080901@FreeBSD.org> In-Reply-To: <51D089D9.6080901@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 08:29:34 -0000 On 30.06.2013 23:41, Navdeep Parhar wrote: > On 06/30/13 07:25, Alexander V. Chernikov wrote: >> Hello list! >> >> While experimenting with Chelsio T440-CR (cxgbe) internal firewall, I'm >> getting some kind of unexpected results: > One bit of general advice to begin with: add "hitcnts 1" to all your > filter rules and then you can see how many incoming packets hit that > filter in the output of "cxgbetool t4nex0 filter list". I really should > make hitcnts=1 the default in the driver. Thanks for the hint. > >> filtering 'type ipv4 action drop' permits IPv4 TCP traffic with bad >> checksum. > It may be that a bad checksum makes it an invalid IPv4 packet to the > chip and so it doesn't hit the "type ipv4" rule. There is an entirely > separate knob available to have the chip drop bad packets if you don't > want to see them. The default is to let them through so that users can > examine them with tcpdump etc. That's OK, Intel also has such tunable (IXGBE_FCTRL_SBP flag). How can I tune this? > >> filtering 'type IPv6 action drop' permits IPv6 traffic to multicast >> addresses (MLDv2, etc..) > The DMAC is an L2 multicast address? Try "proto 58 hitcnts 1 action > drop" to get these ICMP6 packets. > >> filtering 'ethtype 34525 action drop' (drop all IPv6) results in >> 'CHELSIO_T4_SET_FILTER: Argument list too long' despite to what is said >> in budget table from cxgbetool.8 > This _would_ have gotten everything with ethertype ipv6 but the default > filter mode doesn't have ethtype enabled, which is why it's complaining: > # cxgbetool t4nex0 filter mode > ipv4 ipv6 sip dip sport dport matchtype proto ivlan iport fcoe Well, ./cxgbetool t4nex0 filter mode ipv4 ipv6 sip dip sport dport matchtype proto vlan iport cxgbetool: CHELSIO_T4_SET_FILTER_MODE: Operation not supported (Probably because -t4_set_filter_mode() is still under "#ifdef notyet" in t4_main.c) :) > >> filtering 'matchtype 4 action drop' or similar (4,5,4:0,4:4, 5:0, 5:5) >> does not match anything despite some traffic definitely falls into that >> conditions. >> filtering 'action drop' and 'iport X action drop' filters IPv4 traffic >> only. > Strange. I use "iport X action drop hitcnts 1" as a packet black hole > all the time. Were these the only filters when you tried them? Are you > sure your packets didn't hit some other rule and were delivered as a > result of that? Check the order in "cxgbetool t4nex0 filter list" TESTING COUNTER: # ipfw show 200 00200 432677 57910898 deny ip from any to any via cxgbe3 # while true; do sleep 1; ipfw show 200 ; ipfw -q zero 200 ;done [## EMPTY # ./cxgbetool t4nex0 filter list ##] 00200 281878 80450397 deny ip from any to any via cxgbe3 00200 281451 80296577 deny ip from any to any via cxgbe3 00200 299594 85351560 deny ip from any to any via cxgbe3 [## # ./cxgbetool t4nex0 filter 0 iport 3 hitcnts 1 action drop # ./cxgbetool t4nex0 filter list Idx Hits FCoE Port vld:VLAN Prot MPS Frag DIP SIP DPORT SPORT Action 0 1841792 0/0 3/7 0:0000/0:0000 00/00 0/0 0/0 00000000/00000000 00000000/00000000 0000/0000 0000/0000 Drop ##] 00200 115487 15451587 deny ip from any to any via cxgbe3 00200 115148 15414229 deny ip from any to any via cxgbe3 00200 116008 15526682 deny ip from any to any via cxgbe3 [ ## the same, IPv4 TCP with bad csum packets, and IPv6 traffic with L2 multicast macs: # tcpdump -i cxgbe3 -lns0 -c1 ip tcpdump: WARNING: cxgbe3: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on cxgbe3, link-type EN10MB (Ethernet), capture size 65535 bytes 12:09:42.249299 IP 95.108.170.36.39215 > 93.158.158.93.80: Flags [P.], seq 2064108148:2064108546, ack 4252238260, win 1040, options [nop,nop,TS val 538195909 ecr 1194268184], length 398 12:12 [0] test25# tcpdump -i cxgbe3 -lnes0 -c10 ip6 tcpdump: WARNING: cxgbe3: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on cxgbe3, link-type EN10MB (Ethernet), capture size 65535 bytes 12:12:16.728912 80:49:71:11:8d:a2 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 324: fe80::8249:71ff:fe11:8da2.5353 > ff02::fb.5353: 0*- [0q] 2/0/7 PTR zivot-osx._smb._tcp.local., TXT "model=MacBookAir4,2" (262) 12:12:16.728923 00:25:90:0e:00:b8 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 134: fe80::225:90ff:fe0e:b8 > ff02::1: ICMP6, router advertisement, length 80 12:12:16.728942 5c:26:0a:6e:b4:76 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 130: fe80::884:a1e8:86ae:57f7 > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 12:12:16.728968 5c:26:0a:6e:b4:76 > 33:33:ff:0e:00:b8, ethertype IPv6 (0x86dd), length 86: fe80::884:a1e8:86ae:57f7 > ff02::1:ff0e:b8: ICMP6, neighbor solicitation, who has fe80::225:90ff:fe0e:b8, length 32 12:12:16.728971 5c:26:0a:6e:b4:76 > 33:33:ff:0e:00:b8, ethertype IPv6 (0x86dd), length 86: fe80::884:a1e8:86ae:57f7 > ff02::1:ff0e:b8: ICMP6, neighbor solicitation, who has fe80::225:90ff:fe0e:b8, length 32 12:12:16.729011 5c:26:0a:6e:b4:76 > 33:33:ff:0e:00:b8, ethertype IPv6 (0x86dd), length 86: fe80::884:a1e8:86ae:57f7 > ff02::1:ff0e:b8: ICMP6, neighbor solicitation, who has fe80::225:90ff:fe0e:b8, length 32 12:12:16.729011 20:c9:d0:2b:b7:28 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 321: fe80::22c9:d0ff:fe2b:b728.5353 > ff02::fb.5353: 0*- [0q] 2/0/7 PTR octo-osx._smb._tcp.local., TXT "model=MacBookAir5,2" (259) 12:12:16.729012 20:c9:d0:7c:cb:1d > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 95: fe80::22c9:d0ff:fe7c:cb1d.5353 > ff02::fb.5353: 0 PTR (QM)? _smb._tcp.local. (33) 12:12:16.729021 5c:26:0a:6e:b4:76 > 33:33:ff:4f:dc:69, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff4f:dc69: ICMP6, neighbor solicitation, who has 2a02:6b8:0:401:c599:50e2:184f:dc69, length 24 12:12:16.729022 5c:26:0a:6e:b4:76 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::884:a1e8:86ae:57f7 > ff02::2: ICMP6, router solicitation, length 16 ## ] > > Also, are you going by the ifnet rx stats as displayed by netstat etc.? > Right now the driver fills the ifnet stats directly from hardware > registers rather than counting the packets that it actually received > from the chip. The hardware registers include packets that would have > been delivered to the driver if no filters were present but are dropped > due to a filter. I'm counting packets by "deny ip from any to any via cxgbe3" ipfw counter, as I specified in the setup scenario :) > >> filter 'type ipv6 ...' can be set on (0,4,8,12,...) filter numbers >> yelling 'CHELSIO_T4_SET_FILTER: Invalid argument' on other numbers. > Yes, IPv6 filters take 4 tid's (non-IPv6 take 1) and these tid's have to > start at a naturally aligned boundary. No way around this. No problem :) > >> What can I do to debug further/fix this behavior? >> >> Some more questions: >> Does anybody known how I can get/set total number of HW firewall >> records? There is such tunable in Linux version. > I will add a simple sysctl for this. For now you can indirectly figure > this out from the output of "sysctl -n dev.t4nex.0.misc.tids" -- the > FTIDs are the filter tids. For example I see 1456 filters on this card: > trantor:~# sysctl -n dev.t4nex.0.misc.tids > ATID range: 0-8191, in use: 0 > TID range: 2048-18431, in use: 0 > STID range: 0-511, in use: 0 > FTID range: 512-1967 > HW TID usage: 0 IP users, 0 IPv6 users > trantor:~# echo $((1967 - 512 + 1)) > 1456 Thanks! > >> Is there any way to retrieve _host_ interface statistic (e.g. how much >> traffic in packets/bytes are thrown to NIC driver)? > cxgbe(4) doesn't count this stuff itself. Currently it just reads the Understood. I'll use hitcnts counters, then. > hardware registers once per second and it's done. Software stats would > have to be per queue (and then aggregated from time to time). I'll wait counter(9) framework handles this automatically for sysctls > to see where the PCPU counter work in the kernel goes before reworking > this part of the driver. Well, it's actually working, and working great :) We're using PCPU counters for if_vlan, ipfw and IP stack statistics > > Regards, > Navdeep > From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 08:50:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7A38A435; Mon, 1 Jul 2013 08:50:34 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id E1CF219CA; Mon, 1 Jul 2013 08:50:33 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id y10so3361829wgg.2 for ; Mon, 01 Jul 2013 01:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=8g8zeKoFY5XJ+v5FqR3EnLUs65zvcBUp24hsjXwRf2U=; b=xfFK0WWc3Wkd6UY1dxbSYzFmWu4czRBr/yH2Gn3TwK3GfeWY7Br0ztlARfk+1muiKV NG722uHhVvp4zDSV7jXMfV53KF4RIywz3+5J0PTuBDrfIvv/frOHDbQVhTQL3kOL9c07 msLy1a34eyW2DA9bJakNoNUlsvIXjdmQCS6pLiTLBoZEXyH2Y1y0XBphYKpriLtErn1o es/EM/euXNcE5CXXvx5l6/DL+KupYliPKxLIfs4vAU8AndwizkzL7FwJg8Kd4ditrnhp IN2KRF7KItaAIA2qOSdHkQfXKVg8asoyt6yrDkcg5BAYxnubc80Tf5NqDF9yY7vesqoU KDXw== X-Received: by 10.194.8.163 with SMTP id s3mr19414079wja.41.1372668632385; Mon, 01 Jul 2013 01:50:32 -0700 (PDT) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.22.195 with HTTP; Mon, 1 Jul 2013 01:50:12 -0700 (PDT) In-Reply-To: References: From: h bagade Date: Mon, 1 Jul 2013 13:20:12 +0430 X-Google-Sender-Auth: p1vIyLxxYevqHpPSgrw3aZnN9Is Message-ID: Subject: Re: probable side effects of deleting interfaces ip addresses(loopback ones) from routing table ! To: Alan Somers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 08:50:34 -0000 Thanks Alan for your helpful reply. As in my test cable was always connected, I didn't have any problem pinging my own interface ip. I think it's better to keep interface loopback ip rather than deleting them to avoid the problem you mentioned besides performance reduction. On Thu, Jun 27, 2013 at 7:35 PM, Alan Somers wrote: > The network route uses your real interface, eg igb0. But the > interface IP's route is bound to lo0. So if you delete your interface > route, any packets sent to the interface IP will actually go out the > real interface. In an experiment, my ping times suggest that those > packets are actually going out to the switch and coming back. So if > you delete your interface route, you will have reduced performance > when talking to your interface address, and you'll also be unable to > talk to your own interface address if your ethernet cable gets pulled > out. I wouldn't do it if I were you. > > On Wed, Jun 26, 2013 at 10:35 PM, h bagade wrote: > > On Sat, Jun 22, 2013 at 12:25 PM, h bagade wrote: > > > >> Hi all, > >> > >> I've deleted the interface ip address from routing table and only keep > the > >> network address. Nothing is behaving unusual afterwards. I think this > >> loopback ip address is added for better performance. My question is > would I > >> get in to trouble by deleting these ip addresses from routing table or > >> it's, as I think, just a matter of performance? > >> > >> Thanks in advance > >> > > > > I've done further tests after deleting loopback ip addresses and my > system > > works correctly without any side effects! Is that really OK with deleting > > these ip addresses? > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 09:17:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A3436A86; Mon, 1 Jul 2013 09:17:52 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id EE4E91BC2; Mon, 1 Jul 2013 09:17:51 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id r619HfGT044150; Mon, 1 Jul 2013 16:17:41 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <51D14930.1060502@grosbein.net> Date: Mon, 01 Jul 2013 16:17:36 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Sami Halabi Subject: Re: DNAT in freebsd References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "Paul A. Procacci" , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 09:17:52 -0000 On 01.07.2013 14:30, Sami Halabi wrote: > Hi, > > I've tried the following: > > em1 - ip 10.0.1.1/24 > em2 - ip 11.0.3.1/24 > route add 11.0.4.0/24 11.0.3.2 > > ipfw flush > ipfw add 1000 nat 1 all from 10.0.1.2 to 10.0.1.1 > ipfw add 2000 nat 2 all from 11.0.3.1 to 10.0.1.1 > > ipfw add 3000 nat 2 all from 11.0.4.2 to 11.0.3.1 > ipfw add 4000 nat 1 all from 10.0.1.1 to 11.0.3.1 > > > ipfw nat 1 config same_ports ureg_only ip 11.0.3.1 > ipfw nat 1 config reverse same_ports ureg_only ip 11.0.4.2 > > what i see in tcpdump and logs is that the rule 1000 converts the ip correctly > 10.0.1.2->10.0.1.1 ==> 11.0.3.1->10.0.1.1 > while the 2000 rule does nothing... man ipfw says: To let the packet continue after being (de)aliased, set the sysctl vari- able net.inet.ip.fw.one_pass to 0. By default, rule 1000 "consumes" aliased packets and they do not hit rule 2000 at all. So, you need to set sysctl net.inet.ip.fw.one_pass=0 From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 10:05:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 51A7CAB8; Mon, 1 Jul 2013 10:05:26 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 27A8E1E2F; Mon, 1 Jul 2013 10:05:26 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id bj3so4856496pad.14 for ; Mon, 01 Jul 2013 03:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gUFcWIn+6Egf9Ma3ts4dElHxIs62/t4Ou0SvBAhgtXs=; b=A9nsDXcTk3SIvwpT7yqCQNdlvbqbyAnR0ZjHQ+nmklX5m2rjC9Ec4wL7MIozka1ut/ vZUuIMPE7WyC31vr5LojVTT+t0l05W3FTOK7WzLJdaKwVe8fXSTY4VioqEexh/fmFd22 +puuWRBHX35BjGu7ifwIlg2UNu9vbPgHCIpiRtRItUHQK628WcbUtwhbLZTp82KmQuAv gVSs+0gqmlKlaOA5teERr/ArRdwJzcdoBbzMI9zOW40XN8uoYi9rtYqGaNVGD/+8iibS Gtr7rXEKsoFSoKU0gefQi2YmECOXNx53dRRr0UMa6OQFcvrSQPDh/4WpUzOrnYxaykr+ GgCw== MIME-Version: 1.0 X-Received: by 10.68.252.36 with SMTP id zp4mr23153576pbc.51.1372673125951; Mon, 01 Jul 2013 03:05:25 -0700 (PDT) Received: by 10.70.71.7 with HTTP; Mon, 1 Jul 2013 03:05:25 -0700 (PDT) In-Reply-To: <51D14930.1060502@grosbein.net> References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> Date: Mon, 1 Jul 2013 13:05:25 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: Eugene Grosbein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , "Paul A. Procacci" , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 10:05:26 -0000 Hi, forgot to mention that but this sysctl is already set to 0. i see in the logs packets pass 1000 rule. Sami On Mon, Jul 1, 2013 at 12:17 PM, Eugene Grosbein wrote: > On 01.07.2013 14:30, Sami Halabi wrote: > > Hi, > > > > I've tried the following: > > > > em1 - ip 10.0.1.1/24 > > em2 - ip 11.0.3.1/24 > > route add 11.0.4.0/24 11.0.3.2 > > > > ipfw flush > > ipfw add 1000 nat 1 all from 10.0.1.2 to 10.0.1.1 > > ipfw add 2000 nat 2 all from 11.0.3.1 to 10.0.1.1 > > > > ipfw add 3000 nat 2 all from 11.0.4.2 to 11.0.3.1 > > ipfw add 4000 nat 1 all from 10.0.1.1 to 11.0.3.1 > > > > > > ipfw nat 1 config same_ports ureg_only ip 11.0.3.1 > > ipfw nat 1 config reverse same_ports ureg_only ip 11.0.4.2 > > > > what i see in tcpdump and logs is that the rule 1000 converts the ip > correctly > > 10.0.1.2->10.0.1.1 ==> 11.0.3.1->10.0.1.1 > > while the 2000 rule does nothing... > > man ipfw says: > > To let the packet continue after being (de)aliased, set the sysctl > vari- > able net.inet.ip.fw.one_pass to 0. > > By default, rule 1000 "consumes" aliased packets and they do not hit rule > 2000 at all. > So, you need to set sysctl net.inet.ip.fw.one_pass=0 > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 10:42:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6DE68225; Mon, 1 Jul 2013 10:42:23 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id C4A701F9E; Mon, 1 Jul 2013 10:42:22 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id r61AgJiP045731; Mon, 1 Jul 2013 17:42:19 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <51D15D06.9030300@grosbein.net> Date: Mon, 01 Jul 2013 17:42:14 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Sami Halabi Subject: Re: DNAT in freebsd References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 10:42:23 -0000 On 01.07.2013 17:05, Sami Halabi wrote: > Hi, > forgot to mention that but this sysctl is already set to 0. > i see in the logs packets pass 1000 rule. Use rules like 'ipfw add 1500 count log ip from any to any' to check intermediate results of translation. From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 11:06:51 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3D54663C for ; Mon, 1 Jul 2013 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2CA3410E2 for ; Mon, 1 Jul 2013 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r61B6pL6085854 for ; Mon, 1 Jul 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r61B6oCQ085852 for freebsd-net@FreeBSD.org; Mon, 1 Jul 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Jul 2013 11:06:50 GMT Message-Id: <201307011106.r61B6oCQ085852@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 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 11:06:51 -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/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179999 net [ofed] [patch] Bug assigning HCA from IB to ETH p kern/179975 net [igb] igb(4) fails to do polling(4) o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179901 net [netinet] [patch] Multicast SO_REUSEADDR handled incor o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178116 net [ipfilter] [panic] Kernel panic: general protection fa o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] [ipfilter] drops UDP packets with zero checksu o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipfilter] ipfilter/nat NULL pointer deference p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall 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/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] 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/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg 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 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f 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 o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti 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/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 p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) 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/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/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 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i 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/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i 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/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... 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/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c 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/132554 net [ipfilter] There is no ippool start script/ipfilter ma o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f 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 kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131365 net route(8): route add changes interpretation of network 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 [ipfilter] [rc.d] [patch] No good way to set ipfilter 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 f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat 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 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 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/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) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() 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/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection 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/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. 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 [ipfilter] FreeBSD 6.1+VPN+ipnat+ipf: port mapping doe o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one 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 conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c 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 f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge 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/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work 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 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net 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/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption 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 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 kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands 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/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 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/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets 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/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/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) 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 [ipfilter] [panic] Kernel Panic Trap No 12 Page Fault 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 [ipfilter] [patch] ipfilter drops OOW packets under 6. 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 o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack 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 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 s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipfilter] [patch] wrong behaviour with skip rule insi o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipfilter] [panic] using ipfilter "auth" keyword leads o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipfilter] 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 bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipfilter] [patch] ipfilter ioctl SIOCGNATL does not m 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 a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipfilter] ipfilter ipnat problem with h323 proxy supp o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipfilter] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps 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 [ipfilter] [ppp] Interactive use of user PPP and ipfil f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 472 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 11:16:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7850C1F8; Mon, 1 Jul 2013 11:16:01 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6651301; Mon, 1 Jul 2013 11:16:01 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md12so4683061pbc.2 for ; Mon, 01 Jul 2013 04:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eE8qwYEdLDvMe4xO9nO4WyjcS4FfxcjdscMIXDFR5D8=; b=P2UYW+XXynEbvgDSKSe9wCi5Yk4FN8ZXMuYWW0IP94PGPI5AYNKGZQIeMAmH1QYHEP axVn0NE5npIsTajNS6IfOWpG+j4zZSjg1fgGj6WUgKu9H/XksT97WAbs5e+y7dxY1QA/ HR123HI2VLRr6aR0T/i+LXwedz3PHj9Zr4KybUXabeq3mYQ0Mmb5pzVMq6vS5pvGOlaJ zsLTYdCIADY+5yI8ta9uszg+1O+a5AOj5OnOqJMV08CpjG3WCnfp9wPqhPIJ+AKKIiJw fBXQCxpSJZf6EfPEbm1yWbTabdBSc94kqDzNxYmNCSoDKQFjGMQWfHS33pvu2sHW6UIz xxYw== MIME-Version: 1.0 X-Received: by 10.68.171.99 with SMTP id at3mr2318015pbc.64.1372677360659; Mon, 01 Jul 2013 04:16:00 -0700 (PDT) Received: by 10.70.71.7 with HTTP; Mon, 1 Jul 2013 04:16:00 -0700 (PDT) In-Reply-To: <51D15D06.9030300@grosbein.net> References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> <51D15D06.9030300@grosbein.net> Date: Mon, 1 Jul 2013 14:16:00 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: Eugene Grosbein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 11:16:01 -0000 Hi, I did ping 10.0.1.1 from 10.0.1.2, so packet is 10.0.1.2 ->10.0.1.1 > ipfw add 1000 nat 1 all from 10.0.1.2 to 10.0.1.1 if I have 10.0.1.1 in em1 no translation is done! if I delete it (and add a static arp entry in 10.0.1.2 for mac of 10.0.1.1) rule 1000 translates well and I get packet from 11.0.3.1->10.0.1.1 > ipfw add 2000 nat 2 all from 11.0.3.1 to 10.0.1.1 no translation is done at all! Sami > ipfw add 3000 nat 2 all from 11.0.4.2 to 11.0.3.1 > ipfw add 4000 nat 1 all from 10.0.1.1 to 11.0.3.1 > > > ipfw nat 1 config same_ports ureg_only ip 11.0.3.1 > ipfw nat 1 config reverse same_ports ureg_only ip 11.0.4.2 On Mon, Jul 1, 2013 at 1:42 PM, Eugene Grosbein wrote: > On 01.07.2013 17:05, Sami Halabi wrote: > > Hi, > > forgot to mention that but this sysctl is already set to 0. > > i see in the logs packets pass 1000 rule. > > Use rules like 'ipfw add 1500 count log ip from any to any' to check > intermediate results of translation. > > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 11:22:35 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C7BD3418 for ; Mon, 1 Jul 2013 11:22:35 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward18.mail.yandex.net (forward18.mail.yandex.net [IPv6:2a02:6b8:0:1402::3]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF251374 for ; Mon, 1 Jul 2013 11:22:35 +0000 (UTC) Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward18.mail.yandex.net (Yandex) with ESMTP id 078451780E38 for ; Mon, 1 Jul 2013 15:22:33 +0400 (MSK) Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id D612618A04A8 for ; Mon, 1 Jul 2013 15:22:33 +0400 (MSK) Received: from v10-164-205.yandex.net (v10-164-205.yandex.net [84.201.164.205]) by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTP id E7gXCMys9J-MXbmtBdU; Mon, 1 Jul 2013 15:22:33 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1372677753; bh=NR0NfC5eeLaBm0YfjhwTMd3Xl08OuP+8jcfHLt+ALZY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; b=LkMW7quHcm4yBQLUUDsMTXWdVj+jLQ3CciSgvYimM/uuIRQgFs/e6pQuWZsAorO/H jPRpjUzYC5XuY9YSA6wBy0vRf45DZa7P1pgppHe+mkHw8c5taKU8qhH4iiFPwmhcrk AM2+UUo4mmUdScEhT569hQixm+RrV0L+t3jZN5ag= Authentication-Results: smtp18.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <51D165CD.7070508@yandex.ru> Date: Mon, 01 Jul 2013 15:19:41 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Problem with fwip(4) and limited size ll_addr in the struct llentry X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 11:22:35 -0000 Hi, In the kern/176596 described the easy repeatable panic. I found that it occurs, because struct llentry by default has only 8 bytes to store hardware address, but fwip(4) has 16-bytes hw address. And it overwrites next field of struct llentry. Since fwip(4) can be loaded in runtime, we can't use #ifdefs with increased size here. So, what the best way to fix this? -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 12:02:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D994D425 for ; Mon, 1 Jul 2013 12:02:21 +0000 (UTC) (envelope-from syuu@dokukino.com) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id B4C82179A for ; Mon, 1 Jul 2013 12:02:21 +0000 (UTC) Received: by mail-pb0-f52.google.com with SMTP id xa12so4692974pbc.39 for ; Mon, 01 Jul 2013 05:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dokukino.com; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=skOb+qm7fUcZhlY8tCz+dzyBArmBVD9a86aWttQzThY=; b=NOyqOLFva+HoUzXx9sMHpd23g92SYOrKMMAWIoLFv3R09FXP9XOlutxXYwevkZwczJ qEKogI1ACZbTz7JAJEsLr/4V2vmD6lvV9VPythk/9N7ODDjnmyR+eOtadvSpUpKhtC/I 0R9OHR5uC+YdSoDJnhUKguLkjmKorL4Mqk91w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=skOb+qm7fUcZhlY8tCz+dzyBArmBVD9a86aWttQzThY=; b=jtYfiAfvCJfe7mfaEFk2CqS0GavycmqTs3AOo4prH3VUjaLuagLZg5hOw//Ir59Kba 7/nv+ZU1v6Yn2Dtu1Jg/q/U/e1m5FLw7S5SZ6ElnfZGeuar3dIRFgUfeoKoDJdkZiOe9 m3wv+lD6I3rYf1V6Mkh7hmitc5HMjHpEn8fMu68vewR2HORtLnJw46M8aIugEFLX5awU aJ/twjU+oNnrtdSwijPn7ZdhMPs/Tkf3c9HsCxGBq4KjKDs/crON8eT0bUXxZvojM6A+ svdKTnVFj+vFZDrGxyOpp910YGSyK4BHdsgKhh/xuKJ+yAQZssvBHq/j5gEDh6m9OjIQ hoxQ== X-Received: by 10.68.160.99 with SMTP id xj3mr13892110pbb.189.1372680141462; Mon, 01 Jul 2013 05:02:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.222.34 with HTTP; Mon, 1 Jul 2013 05:01:41 -0700 (PDT) From: Takuya ASADA Date: Mon, 1 Jul 2013 21:01:41 +0900 Message-ID: Subject: Multiqueue support for bpf To: FreeBSD Net X-Gm-Message-State: ALoCoQkq++TgVmBMEIPt86v/R6XuAjVsjirdczD/hBp+lqQz8dIbP0vAqSFphdWYJ8//yGhpr6Hc Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 12:02:21 -0000 Hi all, I'd like to propose multiqueue support for bpf. It's result of GSoC'11, and proposed on freebsd-net at Aug.2011 but not yet merged: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/syuu1228/1 http://lists.freebsd.org/pipermail/freebsd-net/2011-August/029585.html The objectives of the patch is to support multiqueue NICs on BPF, and provide interfaces for multithreaded packet processing using BPF. To get optimal performance and to reduce lock contention, multiqueue BPF provides a feature to specify hardware queues. Following is basic usage of multiqueue BPF: void *bpf_thread(void *arg) { cpu = (int)arg; CPU_ZERO(&cpuset); CPU_SET(cpu, &cpuset); cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_TID, -1, sizeof(cpuset), &cpuset); fd = open("/dev/bpf0", O_RDWR); ioctl(fd, BIOCSTRXQMASK, &cpu); ioctl(fd, BIOCSTTXQMASK, &cpu); /* actual works */ } int main(void) { for (i = 0; i < maxcpus; i++) pthread_create(&threads[i], NULL, bpf_thread, (void *)i); for (i = 0; i < maxcpus; i++) pthread_join(&threads[i], NULL); } In this example, threads[n] bind to CPUn, receives packets from rxqueue n and txqueue n. To implement it, the patch modifies bpf_*tap*() and extends struct ifnet, struct mbuf to notify hardware queue information. The changes are in this branch: http://svnweb.freebsd.org/base/user/syuu/mq_bpf/ API descriptions and benchmark results are on previous post: http://lists.freebsd.org/pipermail/freebsd-net/2011-August/029585.html Benchmark program is on this repository: https://github.com/syuu1228/mq_bpf_test From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 12:21:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F236903 for ; Mon, 1 Jul 2013 12:21:55 +0000 (UTC) (envelope-from rhezcool@yahoo.com) Received: from nm7-vm8.bullet.mail.sg3.yahoo.com (nm7-vm8.bullet.mail.sg3.yahoo.com [106.10.148.183]) by mx1.freebsd.org (Postfix) with ESMTP id 36C0618AB for ; Mon, 1 Jul 2013 12:21:53 +0000 (UTC) Received: from [106.10.166.112] by nm7.bullet.mail.sg3.yahoo.com with NNFMP; 01 Jul 2013 12:21:47 -0000 Received: from [106.10.151.234] by tm1.bullet.mail.sg3.yahoo.com with NNFMP; 01 Jul 2013 12:21:47 -0000 Received: from [127.0.0.1] by omp1018.mail.sg3.yahoo.com with NNFMP; 01 Jul 2013 12:21:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 164278.17528.bm@omp1018.mail.sg3.yahoo.com Received: (qmail 15317 invoked by uid 60001); 1 Jul 2013 12:21:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372681306; bh=I6IIaeJUwrXJOtX4CMG2mdXLkYq0boRs846xlR6JnkY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=ig2w5ffJ3cukqOvTSpiIBFM8/5BqH1+S2ol77tcvDSeCXSU6wVC1tNj6o+071a15WArwAK13TEemwpfp0j5kqZ1AnPIvNP3RuyiQL7xFW0ClL2PYsB7YWt/UBF1DGteN7wIGwQUQo/JN5QhdO1Xo6PpHD4Dxv3eK9JEBv7XtMbI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=QXfPoS69HrVhhGRss4wkp1yoi4C9yOvVmbbsre7D6MiwJZLJHx8uQRzZyqxfpY5ewNcMNUpgfULoqS13JrXDUq4hx3fezFRp3n3Kr4nnYnj98VBrjZk784BG3GHRZvhLlU1wwHWiypeyN3VOGkRDB9zPFifD0rMUPVQv2803YBw=; X-YMail-OSG: oitN0dIVM1n_bAEJX_1ZmAIuioLUE_pWpsWQ8nim_ZLGZ6h Sp_a921k.KT23Dw1UwN9HHbE7Jfd26rEkqV7Kbg.ZVxdUL2oTiyhnlLLA78V FqxoKf.JEk6xGfm8WQ5_hXDVNdYve_W3zMOWXeUPrrqVhKO42K_sBTstzZo1 3xp3kh2t6FpTJfsBfi5dNUSVyE1fjZKLS7wSoclvGNcuNN.c6b7.hl.UXXuR Xso5S9EiGaYg6pdB22jm30PfD.TqGRo4u.gVV6Tkm9MkE1J5WvI5vqAgYWC8 _slPK9_58GQRbJqajRmujAGRb2pqB1Mk48bwt5du7gzSYTM6Z9fZMkaX4LZh hX_VTZxHoDuNrweI1_OFV4nvgsuaUsWpWPVgnTk.wRbQ3pv91ZJW4lsu3toy 0On1iREfy60B9pbNuA2ZIDh_vOzGDwjgC0BPfeANuA5ilXFv6eTa3KtEo0Pc 99UD6VUmQFstLcP104n0QrLqf8kC66KajPATrxE_Ie7KkJ34zNcg3xSfVK6z gOeZTQHnAzX8cX9jheSS3gMKBQUhzTPg- Received: from [110.136.185.9] by web190806.mail.sg3.yahoo.com via HTTP; Mon, 01 Jul 2013 20:21:46 SGT X-Rocket-MIMEInfo: 002.001, SGkhCgpJIG5lZWQgc29tZSBoZWxwLCBJIGhhZCB3b3JraW5nIG11bHRpY2FzdCBJUHY2IHJvdXRpbmcgdXNpbmcgZnJlZWJzZCA4LjMgwqBidXQgd2hlbiBpIHRyeSB0byB0ZXN0IGl0IEkgZmFpbGVkLiBteSB0b3BvbG9neSBpcyBsaWtlIHRoaXMgd2l0aCBmcmVlYnNkIGFzIHJvdXRlciBhbmQgeHAgYXMgc2VydmVyIGFuZCBjbGllbnQgOgoKWFAxPC0tLTIwMDE6YWJjZDoxMDo6LzY0LS0tPkZCU0QxPC0tLTIwMDE6YWJjZDoyMDo6LzY0LS0tPkZCU0QyPC0tLTIwMDE6YWJjZDozMDo6LzY0LS0tPlhQMgoKdGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.557 Message-ID: <1372681306.6628.YahooMailNeo@web190806.mail.sg3.yahoo.com> Date: Mon, 1 Jul 2013 20:21:46 +0800 (SGT) From: Reza Abraham Subject: IPv6 Multicast Routing problem To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Reza Abraham List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 12:21:55 -0000 Hi!=0A=0AI need some help, I had working multicast IPv6 routing using freeb= sd 8.3 =A0but when i try to test it I failed. my topology is like this with= freebsd as router and xp as server and client :=0A=0AXP1<---2001:abcd:10::= /64--->FBSD1<---2001:abcd:20::/64--->FBSD2<---2001:abcd:30::/64--->XP2=0A= =0Athis is my step to make the multicast routing:=0A=0A=091. i had re-compi= le my kernel with optionsMROUTING.=0A=092. i install the mcast-toolpackage.= =0A=093. i configure IPv6 static routing in rc.conf=0A=094. i also configur= e this in rc.conf=0A=09* mroute6d_enable=3D"YES"=0A=09* mroute6d_program=3D= "/usr/local/sbin/pim6sd=0Ai confused=A0where can i find pim6sd.conf, so i j= ust copied pim6sd.conf.example and rename it then i edit it, do i right?=0A= this my pim6sd.conf configuration on FBSD1:=0A=0Aphyint em0:=0Aphyint em1;= =0Aphyint em2;=0Astatic rp ff0e::123/128 2001:abcd:20::1;=0A=0Aaddress 2001= :abcd:20::1 is interface em0 on FBSD1 and its linked with interface em0 on = FBSD2.=0Athe configuration for FBSD2 is similiar to FBSD1.=0Ai do streaming= with vlc to test the connection but failed.=0Ai also set ttl >1 but still = failed. From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 12:26:57 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0E394B63 for ; Mon, 1 Jul 2013 12:26:57 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3E718EA for ; Mon, 1 Jul 2013 12:26:56 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id o10so2009210eaj.19 for ; Mon, 01 Jul 2013 05:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EzI4Q7oTp23SAdftaKrbDdHnzd/Sx+sK0O64Ztoe5sw=; b=Ww1w4s3wD9tNNgt0vupgjHgEBubLDdA1puOW9N8dJs6UCcPb+moT1TFsHskQO1PUA6 MSBv9yjN3JDHg0N2qsbR1erBKGUlsOhZheKMHpzq5iCnmv2TxmzLqdDtQl4CG/cu/3YR LBQC2icAfNfJA09sxz+QXr/+7fVX+yPiG1VesTD7+ajTfg51OPr2AOdZ5sNYYJ9tMn2U nrKjyTA7EO0ZHZ0RaH846QJRPRB27Q6l+uXjxzUcNocf6OYec4PvIqS5/fWdqhqlTZ7s DkyXmbFti4ot3XzqY2vwfD8fXbgtka9hU7eiuG5+8ppzpwKZm7fuPxDyU0jZa3vTd6pf tFbQ== MIME-Version: 1.0 X-Received: by 10.15.45.5 with SMTP id a5mr21223406eew.7.1372681615693; Mon, 01 Jul 2013 05:26:55 -0700 (PDT) Received: by 10.223.57.198 with HTTP; Mon, 1 Jul 2013 05:26:55 -0700 (PDT) In-Reply-To: <51D165CD.7070508@yandex.ru> References: <51D165CD.7070508@yandex.ru> Date: Mon, 1 Jul 2013 17:56:55 +0530 Message-ID: Subject: Re: Problem with fwip(4) and limited size ll_addr in the struct llentry From: Vijay Singh To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 12:26:57 -0000 If you enable OFED, then the llentry size is expanded to store IB addresses as well. Code should be in 9.x. -vijay On Mon, Jul 1, 2013 at 4:49 PM, Andrey V. Elsukov wrote: > Hi, > > In the kern/176596 described the easy repeatable panic. > I found that it occurs, because struct llentry by default has only 8 > bytes to store hardware address, but fwip(4) has 16-bytes hw address. > And it overwrites next field of struct llentry. > > Since fwip(4) can be loaded in runtime, we can't use #ifdefs with > increased size here. So, what the best way to fix this? > > -- > WBR, Andrey V. Elsukov > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 12:33:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) by hub.freebsd.org (Postfix) with ESMTP id 4071ED95 for ; Mon, 1 Jul 2013 12:33:53 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 8B0B95FC6; Mon, 1 Jul 2013 12:33:52 +0000 (UTC) Message-ID: <51D17684.1050201@FreeBSD.org> Date: Mon, 01 Jul 2013 16:31:00 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vijay Singh Subject: Re: Problem with fwip(4) and limited size ll_addr in the struct llentry References: <51D165CD.7070508@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 12:33:53 -0000 On 01.07.2013 16:26, Vijay Singh wrote: > If you enable OFED, then the llentry size is expanded to store IB addresses > as well. Code should be in 9.x. Yes, but this isn't solution. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 19:58:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E9226B2D; Mon, 1 Jul 2013 19:58:25 +0000 (UTC) (envelope-from logan@elandsys.com) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A441C1E7F; Mon, 1 Jul 2013 19:58:25 +0000 (UTC) Received: from mx.elandsys.com (IDENT:logan@localhost [127.0.0.1]) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r61JwN3a009073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 12:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372708704; bh=bd0eUocE6P8GCVDka2AvtZ9dV8zsqgGy0qUDMzoMzzk=; h=Date:From:To:Cc:Subject; b=SBiO1sd0uYmAXz/nzqpj5BMv/niJEsPSXzyGSQeqFugVxWsQRsKZHyCcvjwisBBz4 C7hF7VDqe3YtyLqC6qy2rC4ohWfoSN0iDVX+rlyKW9E59gpf76I9juXcqJIIJTzL8/ p+5MB9sDpE41HF6ltuyQYyM2KjRtk+L07jsmgQk8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1372708704; i=@elandsys.com; bh=bd0eUocE6P8GCVDka2AvtZ9dV8zsqgGy0qUDMzoMzzk=; h=Date:From:To:Cc:Subject; b=MQc3JcgFUSvars2OsRVMISMBwg/cStSHqaSOZyaCcNirJcJerxDoJK8ZtdixHp7Zc 049DQuRUQSglBJ4tg9B/qGSjNx/+V56aPznJQQNZTXSz++tI19A7iXL3eeI1I+26y7 /7kIz/a64wuy7qResu/FcmZ8SEEZi7HvFdqjz1TU= Received: (from logan@localhost) by mx.elandsys.com (8.14.5/8.14.5/Submit) id r61JwNqh009909; Mon, 1 Jul 2013 12:58:23 -0700 (PDT) X-Authentication-Warning: mx.elandsys.com: logan set sender to logan@elandsys.com using -f Date: Mon, 1 Jul 2013 12:58:23 -0700 From: Loganaden Velvindron To: freebsd-net@freebsd.org Subject: kern/157410: [ip6] IPv6 Router Advertisements Cause Excessive CPU Use Message-ID: <20130701195823.GA207@mx.elandsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bz@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 19:58:26 -0000 Hi I came across this old PR. It appears that it's not fixed in -current. I attempted to port the diff to our FreeBSD 9.1 release machines which have IPv6 connectivity and are affected by RA flooding. I can report that it mitigates RA_flooding. Feedback welcomed. I'd be happy to polish it so that it can make it to 9.2 and 10.0 :-) I broke down the diffs into separate ones. --- in6.c.orig 2013-06-30 23:07:46.000000000 +0400 +++ in6.c 2013-07-01 19:20:15.000000000 +0400 @@ -2694,6 +2694,8 @@ in6_domifattach(struct ifnet *ifp) ext->nd_ifinfo = nd6_ifattach(ifp); ext->scope6_id = scope6_ifattach(ifp); ext->lltable = lltable_init(ifp, AF_INET6); + ext->nprefixes = 0; + ext->ndefrouters = 0; if (ext->lltable != NULL) { ext->lltable->llt_free = in6_lltable_free; ext->lltable->llt_prefix_free = in6_lltable_prefix_free; --- in6_proto.c.orig 2013-06-30 23:07:58.000000000 +0400 +++ in6_proto.c 2013-07-01 21:05:08.000000000 +0400 @@ -413,7 +413,8 @@ VNET_DEFINE(int, ip6_rr_prune) = 5; /* r * walk list every 5 sec. */ VNET_DEFINE(int, ip6_mcast_pmtu) = 0; /* enable pMTU discovery for multicast? */ VNET_DEFINE(int, ip6_v6only) = 1; - +VNET_DEFINE(int, ip6_maxifprefixes) = 16; +VNET_DEFINE(int, ip6_maxifdefrouters) = 16; VNET_DEFINE(int, ip6_keepfaith) = 0; VNET_DEFINE(time_t, ip6_log_time) = (time_t)0L; #ifdef IPSTEALTH @@ -524,6 +525,10 @@ SYSCTL_VNET_STRUCT(_net_inet6_ip6, IPV6C &VNET_NAME(ip6stat), ip6stat, ""); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXFRAGPACKETS, maxfragpackets, CTLFLAG_RW, &VNET_NAME(ip6_maxfragpackets), 0, ""); +SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXIFPREFIXES, maxifprefixes, + CTLFLAG_RW, &VNET_NAME(ip6_maxifprefixes), 0, ""); +SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXIFDEFROUTERS, maxifdefrouters, + CTLFLAG_RW, &VNET_NAME(ip6_maxifdefrouters), 0, ""); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_ACCEPT_RTADV, accept_rtadv, CTLFLAG_RW, &VNET_NAME(ip6_accept_rtadv), 0, "Default value of per-interface flag for accepting ICMPv6 Router" --- in6_var.h.orig 2013-06-30 23:08:28.000000000 +0400 +++ in6_var.h 2013-07-01 22:38:03.000000000 +0400 @@ -104,6 +104,8 @@ struct in6_ifextra { struct scope6_id *scope6_id; struct lltable *lltable; struct mld_ifinfo *mld_ifinfo; + int nprefixes; + int ndefrouters; }; #define LLTABLE6(ifp) (((struct in6_ifextra *)(ifp)->if_afdata[AF_INET6])->lltable) --- ip6_var.h.orig 2013-06-30 23:09:22.000000000 +0400 +++ ip6_var.h 2013-07-01 20:28:30.000000000 +0400 @@ -315,6 +315,8 @@ VNET_DECLARE(int, ip6_maxfragpackets); / * queue */ VNET_DECLARE(int, ip6_maxfrags); /* Maximum fragments in reassembly * queue */ +VNET_DECLARE(int, ip6_maxifprefixes); +VNET_DECLARE(int, ip6_maxifdefrouters); VNET_DECLARE(int, ip6_accept_rtadv); /* Acts as a host not a router */ VNET_DECLARE(int, ip6_no_radr); /* No defroute from RA */ VNET_DECLARE(int, ip6_norbit_raif); /* Disable R-bit in NA on RA --- nd6.h.orig 2013-06-30 23:09:42.000000000 +0400 +++ nd6.h 2013-07-01 22:16:09.000000000 +0400 @@ -277,6 +277,7 @@ struct nd_prefix { u_char ndpr_plen; int ndpr_refcnt; /* reference couter from addresses */ }; +#define ndpr_next ndpr_entry.le_next #define ndpr_raf ndpr_flags #define ndpr_raf_onlink ndpr_flags.onlink --- nd6_rtr.c.orig 2013-06-30 23:10:24.000000000 +0400 +++ nd6_rtr.c 2013-07-01 22:40:29.000000000 +0400 @@ -83,6 +83,7 @@ static void nd6_rtmsg(int, struct rtentr static int in6_init_prefix_ltimes(struct nd_prefix *); static void in6_init_address_ltimes __P((struct nd_prefix *, struct in6_addrlifetime *)); +static void purge_detached(struct ifnet *); static int nd6_prefix_onlink(struct nd_prefix *); static int nd6_prefix_offlink(struct nd_prefix *); @@ -565,6 +566,7 @@ defrtrlist_del(struct nd_defrouter *dr) { struct nd_defrouter *deldr = NULL; struct nd_prefix *pr; + struct in6_ifextra *ext = dr->ifp->if_afdata[AF_INET6]; /* * Flush all the routing table entries that use the router @@ -597,6 +599,12 @@ defrtrlist_del(struct nd_defrouter *dr) if (deldr) defrouter_select(); + ext->ndefrouters--; + if (ext->ndefrouters < 0) { + log(LOG_WARNING, "defrtrlist_del: negative count on %s\n", + dr->ifp->if_xname); + } + free(dr, M_IP6NDP); } @@ -734,6 +742,7 @@ static struct nd_defrouter * defrtrlist_update(struct nd_defrouter *new) { struct nd_defrouter *dr, *n; + struct in6_ifextra *ext = new->ifp->if_afdata[AF_INET6]; int s = splnet(); if ((dr = defrouter_lookup(&new->rtaddr, new->ifp)) != NULL) { @@ -775,6 +784,12 @@ defrtrlist_update(struct nd_defrouter *n splx(s); return (dr); } + /*struct in6_ifextra *ext = new->ifp->if_afdata[AF_INET6];*/ + if (ip6_maxifdefrouters >= 0 && + ext->ndefrouters >= ip6_maxifdefrouters) { + splx(s); + return (NULL); + } /* entry does not exist */ if (new->rtlifetime == 0) { @@ -810,6 +825,8 @@ insert: defrouter_select(); From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 20:30:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 01CD6654; Mon, 1 Jul 2013 20:30:45 +0000 (UTC) (envelope-from logan@elandsys.com) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id C38541035; Mon, 1 Jul 2013 20:30:44 +0000 (UTC) Received: from mx.elandsys.com (IDENT:logan@localhost [127.0.0.1]) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r61KUgLL016313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 13:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372710644; bh=hGxM7V4TPwonJMwk5aXwylMUSAzT7jwREtqDGz/bI6I=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=La5E41ZQ60lvu9krZXPT4BDBJhM9PTVFeRhPsHoiLONfGsHYujU1n1Bg2dsOrb9nR jmU0Eu3s/+CRVPKwqaVWhxCepPTRMGcG4p3aaUeMdvMLx6VgxCM4zejR7NQsKcEK1B qeXM1jf/yYh3xDVJ3mL5bXKyX+igpQ7zGOw5Ami4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1372710644; i=@elandsys.com; bh=hGxM7V4TPwonJMwk5aXwylMUSAzT7jwREtqDGz/bI6I=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=HlGA2Baxaoqnx3qhomYr3r3saEjzfyEG7TBLYzUPDSt1a4gC6VP6QI51o/BrSaBwA MSUxUtHgE+DKf8X+OENqdjGSVLLWnkXx7T0E/ReWMXg/WyB9MGIC+fp+BuSvmziwSe NIioY5o19LXA1SqdJsBpNZQs3AeYkpp8SykuJLlM= Received: (from logan@localhost) by mx.elandsys.com (8.14.5/8.14.5/Submit) id r61KUgkh005435; Mon, 1 Jul 2013 13:30:42 -0700 (PDT) X-Authentication-Warning: mx.elandsys.com: logan set sender to logan@elandsys.com using -f Date: Mon, 1 Jul 2013 13:30:42 -0700 From: Loganaden Velvindron To: freebsd-net@freebsd.org Subject: Re: kern/157410: [ip6] IPv6 Router Advertisements Cause Excessive CPU Use Message-ID: <20130701203042.GA13730@mx.elandsys.com> References: <20130701195823.GA207@mx.elandsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130701195823.GA207@mx.elandsys.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bz@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 20:30:45 -0000 On Mon, Jul 01, 2013 at 12:58:23PM -0700, Loganaden Velvindron wrote: > Hi I came across this old PR. It appears that it's not fixed in -current. > > I attempted to port the diff to our FreeBSD 9.1 release machines which > have IPv6 connectivity and are affected by RA flooding. > > I can report that it mitigates RA_flooding. > > Feedback welcomed. I'd be happy to polish it so that it can > make it to 9.2 and 10.0 :-) > > I broke down the diffs into separate ones. > > The last diff (nd6_rtr.diff) was garbled and another diff was missing. I'm resending the whole patchset. --- in6.c.orig 2013-06-30 23:07:46.000000000 +0400 +++ in6.c 2013-07-01 19:20:15.000000000 +0400 @@ -2694,6 +2694,8 @@ in6_domifattach(struct ifnet *ifp) ext->nd_ifinfo = nd6_ifattach(ifp); ext->scope6_id = scope6_ifattach(ifp); ext->lltable = lltable_init(ifp, AF_INET6); + ext->nprefixes = 0; + ext->ndefrouters = 0; if (ext->lltable != NULL) { ext->lltable->llt_free = in6_lltable_free; ext->lltable->llt_prefix_free = in6_lltable_prefix_free; --- in6_proto.c.orig 2013-06-30 23:07:58.000000000 +0400 +++ in6_proto.c 2013-07-01 21:05:08.000000000 +0400 @@ -413,7 +413,8 @@ VNET_DEFINE(int, ip6_rr_prune) = 5; /* r * walk list every 5 sec. */ VNET_DEFINE(int, ip6_mcast_pmtu) = 0; /* enable pMTU discovery for multicast? */ VNET_DEFINE(int, ip6_v6only) = 1; - +VNET_DEFINE(int, ip6_maxifprefixes) = 16; +VNET_DEFINE(int, ip6_maxifdefrouters) = 16; VNET_DEFINE(int, ip6_keepfaith) = 0; VNET_DEFINE(time_t, ip6_log_time) = (time_t)0L; #ifdef IPSTEALTH @@ -524,6 +525,10 @@ SYSCTL_VNET_STRUCT(_net_inet6_ip6, IPV6C &VNET_NAME(ip6stat), ip6stat, ""); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXFRAGPACKETS, maxfragpackets, CTLFLAG_RW, &VNET_NAME(ip6_maxfragpackets), 0, ""); +SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXIFPREFIXES, maxifprefixes, + CTLFLAG_RW, &VNET_NAME(ip6_maxifprefixes), 0, ""); +SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXIFDEFROUTERS, maxifdefrouters, + CTLFLAG_RW, &VNET_NAME(ip6_maxifdefrouters), 0, ""); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_ACCEPT_RTADV, accept_rtadv, CTLFLAG_RW, &VNET_NAME(ip6_accept_rtadv), 0, "Default value of per-interface flag for accepting ICMPv6 Router" --- in6_var.h.orig 2013-06-30 23:08:28.000000000 +0400 +++ in6_var.h 2013-07-01 22:38:03.000000000 +0400 @@ -104,6 +104,8 @@ struct in6_ifextra { struct scope6_id *scope6_id; struct lltable *lltable; struct mld_ifinfo *mld_ifinfo; + int nprefixes; + int ndefrouters; }; #define LLTABLE6(ifp) (((struct in6_ifextra *)(ifp)->if_afdata[AF_INET6])->lltable) --- ip6_var.h.orig 2013-06-30 23:09:22.000000000 +0400 +++ ip6_var.h 2013-07-01 20:28:30.000000000 +0400 @@ -315,6 +315,8 @@ VNET_DECLARE(int, ip6_maxfragpackets); / * queue */ VNET_DECLARE(int, ip6_maxfrags); /* Maximum fragments in reassembly * queue */ +VNET_DECLARE(int, ip6_maxifprefixes); +VNET_DECLARE(int, ip6_maxifdefrouters); VNET_DECLARE(int, ip6_accept_rtadv); /* Acts as a host not a router */ VNET_DECLARE(int, ip6_no_radr); /* No defroute from RA */ VNET_DECLARE(int, ip6_norbit_raif); /* Disable R-bit in NA on RA --- nd6.h.orig 2013-06-30 23:09:42.000000000 +0400 +++ nd6.h 2013-07-01 22:16:09.000000000 +0400 @@ -277,6 +277,7 @@ struct nd_prefix { u_char ndpr_plen; int ndpr_refcnt; /* reference couter from addresses */ }; +#define ndpr_next ndpr_entry.le_next #define ndpr_raf ndpr_flags #define ndpr_raf_onlink ndpr_flags.onlink --- in6.h.orig 2013-07-02 00:24:36.000000000 +0400 +++ in6.h 2013-07-01 21:58:04.000000000 +0400 @@ -607,7 +607,6 @@ struct ip6_mtuinfo { #define IPV6CTL_ISATAPRTR 43 /* isatap router */ #endif #define IPV6CTL_MCAST_PMTU 44 /* enable pMTU discovery for multicast? */ - /* New entries should be added here from current IPV6CTL_MAXID value. */ /* to define items, should talk with KAME guys first, for *BSD compatibility */ #define IPV6CTL_STEALTH 45 @@ -619,6 +618,9 @@ struct ip6_mtuinfo { #define IPV6CTL_RFC6204W3 50 /* Accept defroute even when forwarding enabled */ #define IPV6CTL_MAXID 51 +#define IPV6CTL_MAXIFPREFIXES 52 +#define IPV6CTL_MAXIFDEFROUTERS 53 + #endif /* __BSD_VISIBLE */ /* --- nd6_rtr.c.orig 2013-06-30 23:10:24.000000000 +0400 +++ nd6_rtr.c 2013-07-01 22:40:29.000000000 +0400 @@ -83,6 +83,7 @@ static void nd6_rtmsg(int, struct rtentr static int in6_init_prefix_ltimes(struct nd_prefix *); static void in6_init_address_ltimes __P((struct nd_prefix *, struct in6_addrlifetime *)); +static void purge_detached(struct ifnet *); static int nd6_prefix_onlink(struct nd_prefix *); static int nd6_prefix_offlink(struct nd_prefix *); @@ -565,6 +566,7 @@ defrtrlist_del(struct nd_defrouter *dr) { struct nd_defrouter *deldr = NULL; struct nd_prefix *pr; + struct in6_ifextra *ext = dr->ifp->if_afdata[AF_INET6]; /* * Flush all the routing table entries that use the router @@ -597,6 +599,12 @@ defrtrlist_del(struct nd_defrouter *dr) if (deldr) defrouter_select(); + ext->ndefrouters--; + if (ext->ndefrouters < 0) { + log(LOG_WARNING, "defrtrlist_del: negative count on %s\n", + dr->ifp->if_xname); + } + free(dr, M_IP6NDP); } @@ -734,6 +742,7 @@ static struct nd_defrouter * defrtrlist_update(struct nd_defrouter *new) { struct nd_defrouter *dr, *n; + struct in6_ifextra *ext = new->ifp->if_afdata[AF_INET6]; int s = splnet(); if ((dr = defrouter_lookup(&new->rtaddr, new->ifp)) != NULL) { @@ -775,6 +784,12 @@ defrtrlist_update(struct nd_defrouter *n splx(s); return (dr); } + /*struct in6_ifextra *ext = new->ifp->if_afdata[AF_INET6];*/ + if (ip6_maxifdefrouters >= 0 && + ext->ndefrouters >= ip6_maxifdefrouters) { + splx(s); + return (NULL); + } /* entry does not exist */ if (new->rtlifetime == 0) { @@ -810,6 +825,8 @@ insert: defrouter_select(); + ext->ndefrouters++; + splx(s); return (n); @@ -868,6 +885,44 @@ nd6_prefix_lookup(struct nd_prefixctl *k return (search); } +static void +purge_detached(struct ifnet *ifp) +{ + struct nd_prefix *pr, *pr_next; + struct in6_ifaddr *ia; + struct ifaddr *ifa, *ifa_next; + + for (pr = nd_prefix.lh_first; pr; pr = pr_next) { + pr_next = pr->ndpr_next; + + /* + * This function is called when we need to make more room for + * new prefixes rather than keeping old, possibly stale ones. + * Detached prefixes would be a good candidate; if all routers + * that advertised the prefix expired, the prefix is also + * probably stale. + */ + if (pr->ndpr_ifp != ifp || + IN6_IS_ADDR_LINKLOCAL(&pr->ndpr_prefix.sin6_addr) || + ((pr->ndpr_stateflags & NDPRF_DETACHED) == 0 && + !LIST_EMPTY(&pr->ndpr_advrtrs))) + continue; + + for (ifa = ifp->if_addrlist.tqh_first; ifa; ifa = ifa_next) { + ifa_next = ifa->ifa_list.tqe_next; + if (ifa->ifa_addr->sa_family != AF_INET6) + continue; + ia = (struct in6_ifaddr *)ifa; + if ((ia->ia6_flags & IN6_IFF_AUTOCONF) == + IN6_IFF_AUTOCONF && ia->ia6_ndpr == pr) { + in6_purgeaddr(ifa); + } + } + if (pr->ndpr_refcnt == 0) + prelist_remove(pr); + } +} + int nd6_prelist_add(struct nd_prefixctl *pr, struct nd_defrouter *dr, struct nd_prefix **newp) @@ -876,6 +931,14 @@ nd6_prelist_add(struct nd_prefixctl *pr, int error = 0; int i, s; char ip6buf[INET6_ADDRSTRLEN]; + struct in6_ifextra *ext = pr->ndpr_ifp->if_afdata[AF_INET6]; + + if (ip6_maxifprefixes >= 0) { + if (ext->nprefixes >= ip6_maxifprefixes / 2) + purge_detached(pr->ndpr_ifp); + if (ext->nprefixes >= ip6_maxifprefixes) + return ENOMEM; + } new = (struct nd_prefix *)malloc(sizeof(*new), M_IP6NDP, M_NOWAIT); if (new == NULL) @@ -923,7 +986,7 @@ nd6_prelist_add(struct nd_prefixctl *pr, if (dr) pfxrtr_add(new, dr); - + ext->nprefixes++; return 0; } @@ -933,6 +996,7 @@ prelist_remove(struct nd_prefix *pr) struct nd_pfxrouter *pfr, *next; int e, s; char ip6buf[INET6_ADDRSTRLEN]; + struct in6_ifextra *ext = pr->ndpr_ifp->if_afdata[AF_INET6]; /* make sure to invalidate the prefix until it is really freed. */ pr->ndpr_vltime = 0; @@ -965,6 +1029,12 @@ prelist_remove(struct nd_prefix *pr) LIST_FOREACH_SAFE(pfr, &pr->ndpr_advrtrs, pfr_entry, next) { free(pfr, M_IP6NDP); } + + ext->nprefixes--; + if (ext->nprefixes < 0) { + log(LOG_WARNING, "prelist_remove: negative count on %s\n", + pr->ndpr_ifp->if_xname); + } splx(s); free(pr, M_IP6NDP); From owner-freebsd-net@FreeBSD.ORG Mon Jul 1 22:35:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 06F832B7; Mon, 1 Jul 2013 22:35:33 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by mx1.freebsd.org (Postfix) with ESMTP id B04C81719; Mon, 1 Jul 2013 22:35:32 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id l18so2426963qak.16 for ; Mon, 01 Jul 2013 15:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=K+di5bxvTL1f9BNAXYHBK33kRsTGp+INfyPwv/5mWZE=; b=JvlHXo4jmO8dv5FIs2lCVT1G+XJlxpMItEGrvZRYpG7X/O4E4NuwDSTewXj5MlOOXq 5Dnflgq01BHL1ZeNkQcZ3yi5zm2wsIOQkqeAv6TLNL6vnUSilCaopRnOSc0IuNGwfXEx c3pibPwrQXu9IYvtLDE/aGVvd+6DgNLDqwgwu0z/70K/T/ZzwQMyDeb5ahJAJfNdUDIS gJvf7ei7L/qSFvqsUItAxhWEyQ+/mSBKl2w0bGL9WncAPFUane1nen9hpBaXpYKa0irY Fi2F44v+PPQqoXF+F5GpCgZLIvPr2RvfUtTD7PiXkQ8SMBeeqeQX5UEdoZELz4+YgSfp ybqw== MIME-Version: 1.0 X-Received: by 10.224.166.6 with SMTP id k6mr34931908qay.39.1372718132317; Mon, 01 Jul 2013 15:35:32 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Mon, 1 Jul 2013 15:35:32 -0700 (PDT) Date: Tue, 2 Jul 2013 00:35:32 +0200 X-Google-Sender-Auth: m8Wv04mx5eLexfg9T5FW-YDRuV8 Message-ID: Subject: Removing support for FreeBSD 2.x in PPP From: Robert Millan To: freebsd-net@freebsd.org, brian@freebsd.org Content-Type: multipart/mixed; boundary=001a11c24784a7562004e07ad8fd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Jul 2013 22:35:33 -0000 --001a11c24784a7562004e07ad8fd Content-Type: text/plain; charset=UTF-8 Hi, Is there any concern if the arcane FreeBSD 2.x build logic is removed from PPP? These ifdefs are currently being hit when building on GNU/kFreeBSD (because of __FreeBSD__ value being undefined, i.e. 0). I guess one could add even more ifdef logic could be added to handle that, but it seems a bit pointless since 2.x is such an old release series. If there is no objection I will check in the attached patch. -- Robert Millan --001a11c24784a7562004e07ad8fd Content-Type: application/octet-stream; name="ppp.diff" Content-Disposition: attachment; filename="ppp.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_him8w5mo0 SW5kZXg6IHVzci5zYmluL3BwcC9kZWZzLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4vcHBwL2Rl ZnMuYwkocmV2aXNpb24gMjUyNDkwKQorKysgdXNyLnNiaW4vcHBwL2RlZnMuYwkod29ya2luZyBj b3B5KQpAQCAtNDMsNyArNDMsNyBAQAogI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KICNlbmRpZgog I2luY2x1ZGUgPHRlcm1pb3MuaD4KLSNpZiAhZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgX19GcmVl QlNEX18gPCAzCisjaWZuZGVmIF9fRnJlZUJTRF9fCiAjaW5jbHVkZSA8dGltZS5oPgogI2VuZGlm CiAjaW5jbHVkZSA8dW5pc3RkLmg+CkBAIC01NiwyMCArNTYsMTEgQEAKIAogI2RlZmluZQlpc3Nl cChjKQkoKGMpID09ICdcdCcgfHwgKGMpID09ICcgJykKIAotI2lmIGRlZmluZWQoX19OZXRCU0Rf XykgfHwgX19GcmVlQlNEX18gPCAzCisjaWZkZWYgX19OZXRCU0RfXwogdm9pZAogcmFuZGluaXQo KQogewotI2lmIGRlZmluZWQoX19GcmVlQlNEX18pCi0gIHN0YXRpYyBpbnQgaW5pdGRvbmU7CQkv KiBzcmFuZG9tZGV2KCkgY2FsbCBpcyBvbmx5IHJlcXVpcmVkIG9uY2UgKi8KLQotICBpZiAoIWlu aXRkb25lKSB7Ci0gICAgaW5pdGRvbmUgPSAxOwotICAgIHNyYW5kb21kZXYoKTsKLSAgfQotI2Vs c2UKICAgc3JhbmRvbSgodGltZShOVUxMKV5nZXRwaWQoKSkrcmFuZG9tKCkpOwotI2VuZGlmCiB9 CiAjZW5kaWYKIApJbmRleDogdXNyLnNiaW4vcHBwL2RlZnMuaAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iu c2Jpbi9wcHAvZGVmcy5oCShyZXZpc2lvbiAyNTI0OTApCisrKyB1c3Iuc2Jpbi9wcHAvZGVmcy5o CSh3b3JraW5nIGNvcHkpCkBAIC0xMTcsNyArMTE3LDcgQEAKIAogI2RlZmluZSBST1VORFVQKHgp ICgoeCkgPyAoMSArICgoKHgpIC0gMSkgfCAoc2l6ZW9mKGxvbmcpIC0gMSkpKSA6IHNpemVvZihs b25nKSkKIAotI2lmIGRlZmluZWQoX19OZXRCU0RfXykgfHwgX19GcmVlQlNEX18gPCAzCisjaWZk ZWYgX19OZXRCU0RfXwogZXh0ZXJuIHZvaWQgcmFuZGluaXQodm9pZCk7CiAjZWxzZQogI2RlZmlu ZSByYW5kb20gYXJjNHJhbmRvbQo= --001a11c24784a7562004e07ad8fd-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 2 03:39:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1FAB5FD1; Tue, 2 Jul 2013 03:39:37 +0000 (UTC) (envelope-from brian@freebsd.org) Received: from smtp-out-01.shaw.ca (smtp-out-01.shaw.ca [64.59.136.137]) by mx1.freebsd.org (Postfix) with ESMTP id D7BED1247; Tue, 2 Jul 2013 03:39:36 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=SNukfclIDc7GjKe+LHtSoPUBJt/gHPuqMk7EpfoOdzs= c=1 sm=1 a=5nrBDZ_FnQAA:10 a=dBRESv0yCI8A:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=Jvqgub9IZPV2TmRqH1mFPg==:17 a=6I5d2MoRAAAA:8 a=MMwg4So0AAAA:8 a=lJWLfxBmVappjzjelGEA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=WJ3hkfHDukgA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO gw.Awfulhak.org) ([174.7.169.46]) by smtp-out-01.shaw.ca with ESMTP; 01 Jul 2013 21:39:30 -0600 Received: from [67.215.89.21] ([67.215.89.21]) (authenticated bits=0) by gw.Awfulhak.org (8.14.7/8.14.7) with ESMTP id r623dRtP061804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Jul 2013 20:39:28 -0700 (PDT) (envelope-from brian@freebsd.org) Subject: Re: Removing support for FreeBSD 2.x in PPP Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Brian Somers In-Reply-To: Date: Mon, 1 Jul 2013 20:39:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0BC5BCAE-8B7E-4F38-985A-C2E58A01DB9A@freebsd.org> References: To: Robert Millan X-Mailer: Apple Mail (2.1508) X-Spam-Status: No, score=2.2 required=5.0 tests=RDNS_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gw.lan.Awfulhak.org Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Jul 2013 03:39:37 -0000 There are certainly no objections from me. On Jul 1, 2013, at 3:35 PM, Robert Millan wrote: > Hi, >=20 > Is there any concern if the arcane FreeBSD 2.x build logic is removed = from PPP? >=20 > These ifdefs are currently being hit when building on GNU/kFreeBSD > (because of __FreeBSD__ value being undefined, i.e. 0). >=20 > I guess one could add even more ifdef logic could be added to handle > that, but it seems a bit pointless since 2.x is such an old release > series. >=20 > If there is no objection I will check in the attached patch. >=20 > -- > Robert Millan > -- Brian Somers = Don't _EVER_ lose your sense of humour ! = From owner-freebsd-net@FreeBSD.ORG Tue Jul 2 12:33:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DC4FFDFB; Tue, 2 Jul 2013 12:33:33 +0000 (UTC) (envelope-from logan@elandsys.com) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B12671A39; Tue, 2 Jul 2013 12:33:33 +0000 (UTC) Received: from mx.elandsys.com (IDENT:logan@localhost [127.0.0.1]) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r62CXT7M015250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 05:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372768410; bh=buPHQMlvrgRM0PVXb3XD3VxmaR6BDjLqKeOeNxNl22M=; h=Date:From:To:Cc:Subject; b=AliVLmlCm1b2H/KESTL4mXOIde+TsqtqstaDxhDhq8ueSqhQz4eYjfMgggLdfxPcJ 8iLjs491p3BfEI6SiLK98GmppEwHjc61ImFIX8h7mzcQQj8l7c3FETbENjE72pcBNd oY3Wy2/0uowxg/uDM0bgOQSgl8BojgZIVQTYhYNo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1372768410; i=@elandsys.com; bh=buPHQMlvrgRM0PVXb3XD3VxmaR6BDjLqKeOeNxNl22M=; h=Date:From:To:Cc:Subject; b=3uYaZl3KdZi8zFUYeMGlJWzKFJnhetyXml+I05j1v9TZqMnZREGI4tbCoQk0cbchN HEXepwimFsH7r5Xvs6OhZEmibu9yNR+o1m2YQM12Q8MGBI+JXYumdsjqikG5RBxGps yL9FizMEl/KOzUUdbfSj4pxz+wZzt1Xv1DiajSqE= Received: (from logan@localhost) by mx.elandsys.com (8.14.5/8.14.5/Submit) id r62CXSJG027628; Tue, 2 Jul 2013 05:33:28 -0700 (PDT) X-Authentication-Warning: mx.elandsys.com: logan set sender to logan@elandsys.com using -f Date: Tue, 2 Jul 2013 05:33:28 -0700 From: Loganaden Velvindron To: freebsd-net@freebsd.org Subject: FreeBSD equivalent of rt_timer_count() Message-ID: <20130702123328.GA12871@mx.elandsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bz@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Jul 2013 12:33:33 -0000 Hi, I'm interested in implementing something like rt_timer_count() See: http://fxr.watson.org/fxr/source/net/route.c?v=NETBSD;im=bigexcerpts#L1121 Maybe freebsd has something similar ? //logan C-x-C-c From owner-freebsd-net@FreeBSD.ORG Tue Jul 2 13:38:29 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 317491D2 for ; Tue, 2 Jul 2013 13:38:29 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by mx1.freebsd.org (Postfix) with ESMTP id AFB781E22 for ; Tue, 2 Jul 2013 13:38:28 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id d10so3389572lbj.0 for ; Tue, 02 Jul 2013 06:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5EIiI5qx0Yy8oxhHcM2LzWrOZvJ+/RJWkcr0lGlKeSU=; b=i1fMkIN777Y9KTj+Sti11gZgayyyfHqJt/Le+8l3GnpPMDm90pRbv5Zn7ZXkgW2CSM TEVkN1XKbw15Nkg8h+MQgNOaJuuYmP24Ljumu0YszoiODLRhJ1O+RG+RvFAUWdS6GAH7 vdqrE0GKVYaht6H42fs0LEGzTstCGuHKCiKPyvqzEXiKi3G3WQYDaxkq0rZq2wBEG+1w nL+uIlaKCFZa0XtMq9v77LJI87UH24wwrnUJynqrfvpc1PTmDQDg8X+8cMQRiHPsWeNK n3K2NMxbbe4B7DrQ76oOf5pe36IncrH+hFthc7KXLRTqf/NGnQOC1MwizlIP66KhsreM xbJA== MIME-Version: 1.0 X-Received: by 10.112.5.199 with SMTP id u7mr13995356lbu.67.1372772307636; Tue, 02 Jul 2013 06:38:27 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.15 with HTTP; Tue, 2 Jul 2013 06:38:27 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Jul 2013 15:38:27 +0200 X-Google-Sender-Auth: cK4N2xZ3u5qM4QnifWhdIf3mO4I Message-ID: Subject: Re: Multiqueue support for bpf From: Luigi Rizzo To: Takuya ASADA Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Jul 2013 13:38:29 -0000 On Mon, Jul 1, 2013 at 2:01 PM, Takuya ASADA wrote: > Hi all, > > I'd like to propose multiqueue support for bpf. > It's result of GSoC'11, and proposed on freebsd-net at Aug.2011 but not yet > merged: > > http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/syuu1228/1 > http://lists.freebsd.org/pipermail/freebsd-net/2011-August/029585.html Do you have an updated URL for the diffs ? The link below from your original message seems not working now (NXDOMAIN) http://www.dokukino.com/mq_bpf_20110813.diff Specifically, I am curious about the type of mbuf changes, because there are many pending changes to the mbufs we'd like to have (such as some local room/leading space to store metadata instead of using expensive mtags), and in the interest of API stability we should try and make those changes at once. ifnet changes are also a concern but less important (they are only a compile time issue, whereas mbuf changes potentially have an impact on runtime) cheers luigi > > The objectives of the patch is to support multiqueue NICs on BPF, and > provide interfaces for multithreaded packet processing using BPF. > To get optimal performance and to reduce lock contention, multiqueue BPF > provides a feature to specify hardware queues. > Following is basic usage of multiqueue BPF: > > void *bpf_thread(void *arg) { > cpu = (int)arg; > CPU_ZERO(&cpuset); > CPU_SET(cpu, &cpuset); > cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_TID, -1, sizeof(cpuset), > &cpuset); > fd = open("/dev/bpf0", O_RDWR); > ioctl(fd, BIOCSTRXQMASK, &cpu); > ioctl(fd, BIOCSTTXQMASK, &cpu); > /* actual works */ > } > > int main(void) > { > for (i = 0; i < maxcpus; i++) > pthread_create(&threads[i], NULL, bpf_thread, (void *)i); > for (i = 0; i < maxcpus; i++) > pthread_join(&threads[i], NULL); > } > > In this example, threads[n] bind to CPUn, receives packets from rxqueue n > and txqueue n. > > To implement it, the patch modifies bpf_*tap*() and extends struct ifnet, > struct mbuf to notify hardware queue information. > > The changes are in this branch: > http://svnweb.freebsd.org/base/user/syuu/mq_bpf/ > > API descriptions and benchmark results are on previous post: > http://lists.freebsd.org/pipermail/freebsd-net/2011-August/029585.html > > Benchmark program is on this repository: > https://github.com/syuu1228/mq_bpf_test > _______________________________________________ > 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" > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Tue Jul 2 14:21:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A9339192; Tue, 2 Jul 2013 14:21:31 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id 79DB71088; Tue, 2 Jul 2013 14:21:31 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id q10so3641836pdj.24 for ; Tue, 02 Jul 2013 07:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v5sflUrLA93oBHu2bhJeXdy2nzU7cAxAowhdHU6CSf4=; b=Ghb4SdwsLleetJB7pnaZAbwIp9uzQ2lUFYLK7EOo25oeT76dE9rl+VTGb0IQDAL2TR jhRlyEf1SAwf7+BIxwh6HzfLEpo6Glj6VARfWHE9T+0p4p2ZpOTpNiNGUo49K17yuffa cacFCCUBAPPp1wAAwA2WCAYoxleKw3KgoI/57iNKYKCXd9CJqtxVuXCQ6SAWaYWpEfon fUKt8gJF0P2y+BJkQqz7eSjJX13qIpn3gwPX99yaNQ/rbDXBG7O8kIpGqaV1u9xZf5On oDHOpbUU8+cWv3GctMGrDjPA4CR8EFAGTTNNvKR+d9tJaBxCil1WoXSN2FxRuhNppdg0 eO4Q== MIME-Version: 1.0 X-Received: by 10.68.235.103 with SMTP id ul7mr29405855pbc.14.1372774891213; Tue, 02 Jul 2013 07:21:31 -0700 (PDT) Received: by 10.70.71.7 with HTTP; Tue, 2 Jul 2013 07:21:30 -0700 (PDT) Received: by 10.70.71.7 with HTTP; Tue, 2 Jul 2013 07:21:30 -0700 (PDT) In-Reply-To: References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> <51D15D06.9030300@grosbein.net> Date: Tue, 2 Jul 2013 17:21:30 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: Eugene Grosbein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-ipfw , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Jul 2013 14:21:31 -0000 Hi again, So far no solution.... Is there really no alternative in FreeBSD? Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 1 =D7=91=D7=99=D7=95=D7=9C 2013 14:16,= =D7=9E=D7=90=D7=AA "Sami Halabi" : > Hi, > I did ping 10.0.1.1 from 10.0.1.2, so packet is 10.0.1.2 ->10.0.1.1 > > ipfw add 1000 nat 1 all from 10.0.1.2 to 10.0.1.1 > if I have 10.0.1.1 in em1 no translation is done! > if I delete it (and add a static arp entry in 10.0.1.2 for mac of > 10.0.1.1) > rule 1000 translates well and I get packet from 11.0.3.1->10.0.1.1 > > > ipfw add 2000 nat 2 all from 11.0.3.1 to 10.0.1.1 > no translation is done at all! > > Sami > > > ipfw add 3000 nat 2 all from 11.0.4.2 to 11.0.3.1 > > ipfw add 4000 nat 1 all from 10.0.1.1 to 11.0.3.1 > > > > > > ipfw nat 1 config same_ports ureg_only ip 11.0.3.1 > > ipfw nat 1 config reverse same_ports ureg_only ip 11.0.4.2 > > > > On Mon, Jul 1, 2013 at 1:42 PM, Eugene Grosbein wrote= : > >> On 01.07.2013 17:05, Sami Halabi wrote: >> > Hi, >> > forgot to mention that but this sysctl is already set to 0. >> > i see in the logs packets pass 1000 rule. >> >> Use rules like 'ipfw add 1500 count log ip from any to any' to check >> intermediate results of translation. >> >> > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert > From owner-freebsd-net@FreeBSD.ORG Tue Jul 2 15:56:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 324E5D24 for ; Tue, 2 Jul 2013 15:56:51 +0000 (UTC) (envelope-from syuu@dokukino.com) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 0926A1702 for ; Tue, 2 Jul 2013 15:56:50 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id 4so3731697pdd.34 for ; Tue, 02 Jul 2013 08:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dokukino.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Jk9Nor0FTRvjBCYtUAkkvzmjmLL7RR2gLC0T44Nn4aw=; b=GTAncEtu2MUwn0BqpS2aWK660l9fHSdSyICFyvfNjYgUi1wSusBr3w5FbP1HABMYpJ S3rp4972PhcBRuwDqKbHSbNxAZLT8jJcfhE6JBOX2pzed/koyB7P/crqii90zBTA+SKl deRml/+GguJ8B1NElZ/ANd2FqnDxr/GPA2B4Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Jk9Nor0FTRvjBCYtUAkkvzmjmLL7RR2gLC0T44Nn4aw=; b=mrf88mhJ31Id1UdxWElXbfPD+sUa4OmmnWEo+d4UTsMkNTA3bkdBs4RtQjrDX9xDXr 1uK6bad6XTZV7vmS8rPninCsMeQ/IGGK3E0u2wZNGkFZyI+zzKATWU7zA4w2eYuwej1l nMUAvHAyqRrI2r1aH0uc8uNBj0tcNX+kaZwIgJVk1OYcXRn2bozi7sHRHp8lL1JvERFG hfh4ZFdLA8PkHYP5+e2w13wfjdLmE0eyXmaDr+BjQ15dJnRlgnGsg8QyYo2OCdHYeTDf 8nscui9lwvSoeKBvpnldKgwKz9w8gg1lPQ9U4HNh9AEX9bU32ivmDO0qaZEmPw2CEjkj WOtQ== X-Received: by 10.66.2.101 with SMTP id 5mr20341863pat.82.1372780610563; Tue, 02 Jul 2013 08:56:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.222.34 with HTTP; Tue, 2 Jul 2013 08:56:10 -0700 (PDT) In-Reply-To: References: From: Takuya ASADA Date: Wed, 3 Jul 2013 00:56:10 +0900 Message-ID: Subject: Re: Multiqueue support for bpf To: Luigi Rizzo Content-Type: multipart/mixed; boundary=bcaec518248ea5c9a804e089646d X-Gm-Message-State: ALoCoQlPyI5JWg3UveZC9jhNhvdYC4QPTloV52qsy9rRzTDW1JTIya2uA6vxcx2H7SN899hK75Kw X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Jul 2013 15:56:51 -0000 --bcaec518248ea5c9a804e089646d Content-Type: text/plain; charset=UTF-8 Hi, Do you have an updated URL for the diffs ? The link below from your > original message > seems not working now (NXDOMAIN) > > http://www.dokukino.com/mq_bpf_20110813.diff > Changes with recent head is on my repository: http://svnweb.freebsd.org/base/user/syuu/mq_bpf/ And I attached a diff file on this mail. --bcaec518248ea5c9a804e089646d Content-Type: application/octet-stream; name="mq_bpf_20130703.diff" Content-Disposition: attachment; filename="mq_bpf_20130703.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hin9onwa0 SW5kZXg6IGlmbmV0LjkKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaWZuZXQuOQkoLi4uL2hlYWQvc2hhcmUvbWFu L21hbjkvaWZuZXQuOSkJKHJldmlzaW9uIDI1MjUwOSkKKysrIGlmbmV0LjkJKC4uLi91c2VyL3N5 dXUvbXFfYnBmL3NoYXJlL21hbi9tYW45L2lmbmV0LjkpCShyZXZpc2lvbiAyNTI1MDkpCkBAIC0x MTksNiArMTE5LDE0IEBACiAuRm8gXCoobHAqaWZfcmVzb2x2ZW11bHRpXCoocnAKIC5GYSAic3Ry dWN0IGlmbmV0ICppZnAiICJzdHJ1Y3Qgc29ja2FkZHIgKipyZXRzYSIgInN0cnVjdCBzb2NrYWRk ciAqYWRkciIKIC5GYworLkZ0IGludAorLkZuIFwqKGxwKmlmX2dldF9yeHF1ZXVlX2xlblwqKHJw ICJzdHJ1Y3QgaWZuZXQgKmlmcCIKKy5GdCBpbnQKKy5GbiBcKihscCppZl9nZXRfdHhxdWV1ZV9s ZW5cKihycCAic3RydWN0IGlmbmV0ICppZnAiCisuRnQgaW50CisuRm4gXCoobHAqaWZfZ2V0X3J4 cXVldWVfYWZmaW5pdHlcKihycCAic3RydWN0IGlmbmV0ICppZnAiICJpbnQgcXVlaWQiCisuRnQg aW50CisuRm4gXCoobHAqaWZfZ2V0X3R4cXVldWVfYWZmaW5pdHlcKihycCAic3RydWN0IGlmbmV0 ICppZnAiICJpbnQgcXVlaWQiCiAuU3MgInN0cnVjdCBpZmFkZHIgbWVtYmVyIGZ1bmN0aW9uIgog LkZ0IHZvaWQKIC5GbyBcKihscCppZmFfcnRyZXF1ZXN0XCoocnAKQEAgLTUzNyw2ICs1NDUsMTQg QEAKIGNvcnJlc3BvbmRzIHRvIHRoYXQgYWRkcmVzcyB3aGljaCBpcyByZXR1cm5lZCBpbgogLkZh ICpyZXRzYSAuCiBSZXR1cm5zIHplcm8gb24gc3VjY2Vzcywgb3IgYW4gZXJyb3IgY29kZSBvbiBm YWlsdXJlLgorLkl0IEZuIGlmX2dldF9yeHF1ZXVlX2xlbgorR2V0IFJYIHF1ZXVlIGxlbmd0aCwg b25seSByZXF1aXJlZCBmb3IgbXVsdGlxdWV1ZSBzdXBwb3J0ZWQgaW50ZXJmYWNlcy4KKy5JdCBG biBpZl9nZXRfdHhxdWV1ZV9sZW4KK0dldCBUWCBxdWV1ZSBsZW5ndGgsIG9ubHkgcmVxdWlyZWQg Zm9yIG11bHRpcXVldWUgc3VwcG9ydGVkIGludGVyZmFjZXMuCisuSXQgRm4gaWZfZ2V0X3J4cXVl dWVfYWZmaW5pdHkKK0dldCBSWCBxdWV1ZSBhZmZpbml0eSwgb25seSByZXF1aXJlZCBmb3IgbXVs dGlxdWV1ZSBzdXBwb3J0ZWQgaW50ZXJmYWNlcy4KKy5JdCBGbiBpZl9nZXRfdHhxdWV1ZV9hZmZp bml0eQorR2V0IFRYIHF1ZXVlIGFmZmluaXR5LCBvbmx5IHJlcXVpcmVkIGZvciBtdWx0aXF1ZXVl IHN1cHBvcnRlZCBpbnRlcmZhY2VzLgogLkVsCiAuU3MgIkludGVyZmFjZSBGbGFncyIKIEludGVy ZmFjZSBmbGFncyBhcmUgdXNlZCBmb3IgYSBudW1iZXIgb2YgZGlmZmVyZW50IHB1cnBvc2VzLgpJ bmRleDogYnBmLjQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQotLS0gYnBmLjQJKC4uLi9oZWFkL3NoYXJlL21hbi9tYW40 L2JwZi40KQkocmV2aXNpb24gMjUyNTA5KQorKysgYnBmLjQJKC4uLi91c2VyL3N5dXUvbXFfYnBm L3NoYXJlL21hbi9tYW40L2JwZi40KQkocmV2aXNpb24gMjUyNTA5KQpAQCAtNjMxLDYgKzYzMSw0 NiBAQAogLlZ0IGJ6aF9rZXJuZWxfZ2VuCiBhZ2FpbnN0CiAuVnQgYnpoX3VzZXJfZ2VuIC4KKy5J dCBEdiBCSU9DRU5BUU1BU0sKK0VuYWJsZXMgbXVsdGlxdWV1ZSBmaWx0ZXIgb24gdGhlIGRlc2Ny aXB0b3IuCisKKy5JdCBEdiBCSU9DRElTUU1BU0sKK0Rpc2FibGVzIG11bHRpcXVldWUgZmlsdGVy IG9uIHRoZSBkZXNjcmlwdG9yLgorCisuSXQgRHYgQklPQ1NUUlhRTUFTSworLlBxIExpIHVpbnQz Ml90CitTZXQgbWFzayBiaXQgb24gc3BlY2lmaWVkIFJYIHF1ZXVlLgorCisuSXQgRHYgQklPQ0NS UlhRTUFTSworLlBxIExpIHVpbnQzMl90CitDbGVhciBtYXNrIGJpdCBvbiBzcGVjaWZpZWQgUlgg cXVldWUuCisKKy5JdCBEdiBCSU9DR1RSWFFNQVNLCisuUHEgTGkgdWludDMyX3QKK0dldCBtYXNr IGJpdCBvbiBzcGVjaWZpZWQgUlggcXVldWUuCisKKy5JdCBEdiBCSU9DU1RUWFFNQVNLCisuUHEg TGkgdWludDMyX3QKK1NldCBtYXNrIGJpdCBvbiBzcGVjaWZpZWQgVFggcXVldWUuCisKKy5JdCBE diBCSU9DQ1JUWFFNQVNLCisuUHEgTGkgdWludDMyX3QKK0NsZWFyIG1hc2sgYml0IG9uIHNwZWNp ZmllZCBUWCBxdWV1ZS4KKworLkl0IER2IEJJT0NHVFRYUU1BU0sKKy5QcSBMaSB1aW50MzJfdAor R2V0IG1hc2sgYml0IG9uIHNwZWNpZmllZCBUWCBxdWV1ZS4KKworLkl0IER2IEJJT0NTVE9USEVS TUFTSworU2V0IG1hc2sgYml0IGZvciB0aGUgcGFja2V0cyB3aGljaCBub3QgdGllZCB3aXRoIGFu eSBxdWV1ZXMuCisKKy5JdCBEdiBCSU9DQ1JPVEhFUk1BU0sKK0NsZWFyIG1hc2sgYml0IGZvciB0 aGUgcGFja2V0cyB3aGljaCBub3QgdGllZCB3aXRoIGFueSBxdWV1ZXMuCisKKy5JdCBEdiBCSU9D R1RPVEhFUk1BU0sKKy5QcSBMaSB1aW50MzJfdAorR2V0IG1hc2sgYml0IGZvciB0aGUgcGFja2V0 cyB3aGljaCBub3QgdGllZCB3aXRoIGFueSBxdWV1ZXMuCisKIC5FbAogLlNoIEJQRiBIRUFERVIK IE9uZSBvZiB0aGUgZm9sbG93aW5nIHN0cnVjdHVyZXMgaXMgcHJlcGVuZGVkIHRvIGVhY2ggcGFj a2V0IHJldHVybmVkIGJ5CkBAIC0xMDM3LDYgKzEwNzcsMjQgQEAKIAlCUEZfU1RNVChCUEZfUkVU K0JQRl9LLCAwKSwKIH07CiAuRWQKKy5TaCBNVUxUSVFVRVVFIFNVUFBPUlQKK011bHRpcXVldWUg bmV0d29yayBpbnRlcmZhY2Ugc3VwcG9ydCBmdW5jdGlvbiBwcm92aWRlcyBpbnRlcmZhY2VzIGZv ciAKK211bHRpdGhyZWFkZWQgcGFja2V0IHByb2Nlc3NpbmcgdXNpbmcgYnBmLgorCitOb3JtYWwg YnBmIGNhbiByZWNlaXZlIHBhY2tldHMgZnJvbSBzcGVjaWZpZWQgaW50ZXJmYWNlLCBtdWx0aXF1 ZXVlIHN1cHBvcnQgCitmdW5jdGlvbiBjYW4gcmVjZWl2ZSBwYWNrZXRzIGZyb20gc3BlY2lmaWVk IGhhcmR3YXJlIHF1ZXVlLgorCitUaGlzIGRpc3RyaWJ1dGVzIGJwZiB3b3JrbG9hZCBvbiBtdWx0 aXBsZSB0aHJlYWRzLCBhbHNvIHJlZHVjZXMgbG9jayAKK2NvbnRlbnRpb24gb24gYnBmLgorCitU byBtYWtlIHlvdXIgcHJvZ3JhbSBtdWx0aXRocmVhZGVkLCB5b3UnbGwgbmVlZCB0byBvcGVuIGJw ZiBkZXNjcmlwdG9yIG9uIGVhY2ggCit0aHJlYWQsIGVuYWJsZSBtdWx0aXF1ZXVlIHN1cHBvcnQg YnkgQklPQ0VOQVFNQVNLIGlvY3RsLCBhbmQgc2V0IHF1ZXVlIG1hc2sgYnkgCitCSU9DU1RSWFFN QVNLIC8gQklPQ1NUVFhRTUFTSyAvIEJJT0NTVE9USEVSTUFTSyBpb2N0bHMuCisKK1F1ZXVlIGxl bmd0aCBhbmQgcXVldWUgYWZmaW5pdHkgaW5mb3JtYXRpb24gbWF5IHVzZWZ1bCB0byBvcHRpbWl6 ZSBzZXR0aW5nIAorcXVldWUgbWFzayBvbiBicGYgZGVzY3JpcHRvciwgc2VlCisuWHIgbmV0aW50 cm8gNCAuCisKIC5TaCBTRUUgQUxTTwogLlhyIHRjcGR1bXAgMSAsCiAuWHIgaW9jdGwgMiAsCklu ZGV4OiBpZmNvbmZpZy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGlmY29uZmlnLmMJKC4uLi9oZWFkL3NiaW4v aWZjb25maWcvaWZjb25maWcuYykJKHJldmlzaW9uIDI1MjUwOSkKKysrIGlmY29uZmlnLmMJKC4u Li91c2VyL3N5dXUvbXFfYnBmL3NiaW4vaWZjb25maWcvaWZjb25maWcuYykJKHJldmlzaW9uIDI1 MjUwOSkKQEAgLTkxNyw3ICs5MTcsNyBAQAogIlwwMjBcMVJYQ1NVTVwyVFhDU1VNXDNORVRDT05T XDRWTEFOX01UVVw1VkxBTl9IV1RBR0dJTkdcNkpVTUJPX01UVVw3UE9MTElORyIgXAogIlwxMFZM QU5fSFdDU1VNXDExVFNPNFwxMlRTTzZcMTNMUk9cMTRXT0xfVUNBU1RcMTVXT0xfTUNBU1RcMTZX T0xfTUFHSUMiIFwKICJcMTdUT0U0XDIwVE9FNlwyMVZMQU5fSFdGSUxURVJcMjNWTEFOX0hXVFNP XDI0TElOS1NUQVRFXDI1TkVUTUFQIiBcCi0iXDI2UlhDU1VNX0lQVjZcMjdUWENTVU1fSVBWNiIK KyJcMjZSWENTVU1fSVBWNlwyN1RYQ1NVTV9JUFY2XDMwTVVMVElRVUVVRSIKIAogLyoKICAqIFBy aW50IHRoZSBzdGF0dXMgb2YgdGhlIGludGVyZmFjZS4gIElmIGFuIGFkZHJlc3MgZmFtaWx5IHdh cwpAQCAtOTg0LDYgKzk4NCwzOCBAQAogCQl9CiAJfQogCisJaWYgKChpZnIuaWZyX3JlcWNhcCAm IElGQ0FQX01VTFRJUVVFVUUpKSB7CisJCWludCBpLCByeHFsZW4gPSAwLCB0eHFsZW4gPSAwOwor CisJCWlmIChpb2N0bChzLCBTSU9DR0lGUUxFTiwgJmlmcikgPT0gMCkgeworCQkJcnhxbGVuID0g aWZyLmlmcl9yeHF1ZXVlX2xlbjsKKwkJCXR4cWxlbiA9IGlmci5pZnJfdHhxdWV1ZV9sZW47CisJ CX1lbHNlCisJCQlwZXJyb3IoImlvY3RsIik7CisKKwkJcHJpbnRmKCJcdHJ4cXVldWUgbGVuPSVk IGFmZmluaXR5PVsiLCByeHFsZW4pOworCQlmb3IgKGkgPSAwOyBpIDwgcnhxbGVuOyBpKyspIHsK KwkJCWlmci5pZnJfcXVldWVfYWZmaW5pdHlfaW5kZXggPSBpOworCQkJaWYgKGlvY3RsKHMsIFNJ T0NHSUZSWFFBRkZJTklUWSwgJmlmcikgPT0gMCkKKwkJCQlwcmludGYoIiAlZDolZCIsIGlmci5p ZnJfcXVldWVfYWZmaW5pdHlfaW5kZXgsCisJCQkJCWlmci5pZnJfcXVldWVfYWZmaW5pdHlfY3B1 KTsKKwkJCWVsc2UKKwkJCQlwZXJyb3IoImlvY3RsIik7CisJCX0KKwkJcHJpbnRmKCIgXVxuIik7 CisKKwkJcHJpbnRmKCJcdHR4cXVldWUgbGVuPSVkIGFmZmluaXR5PVsiLCB0eHFsZW4pOworCQlm b3IgKGkgPSAwOyBpIDwgdHhxbGVuOyBpKyspIHsKKwkJCWlmci5pZnJfcXVldWVfYWZmaW5pdHlf aW5kZXggPSBpOworCQkJaWYgKGlvY3RsKHMsIFNJT0NHSUZUWFFBRkZJTklUWSwgJmlmcikgPT0g MCkKKwkJCQlwcmludGYoIiAlZDolZCIsIGlmci5pZnJfcXVldWVfYWZmaW5pdHlfaW5kZXgsCisJ CQkJCWlmci5pZnJfcXVldWVfYWZmaW5pdHlfY3B1KTsKKwkJCWVsc2UKKwkJCQlwZXJyb3IoImlv Y3RsIik7CisJCX0KKwkJcHJpbnRmKCIgXVxuIik7CisJfQorCiAJdHVubmVsX3N0YXR1cyhzKTsK IAogCWZvciAoaWZ0ID0gaWZhOyBpZnQgIT0gTlVMTDsgaWZ0ID0gaWZ0LT5pZmFfbmV4dCkgewpJ bmRleDogdGNwZHVtcC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRjcGR1bXAuYwkoLi4uL2hlYWQvY29udHJp Yi90Y3BkdW1wL3RjcGR1bXAuYykJKHJldmlzaW9uIDI1MjUwOSkKKysrIHRjcGR1bXAuYwkoLi4u L3VzZXIvc3l1dS9tcV9icGYvY29udHJpYi90Y3BkdW1wL3RjcGR1bXAuYykJKHJldmlzaW9uIDI1 MjUwOSkKQEAgLTcwMiw2ICs3MDIsNyBAQAogI2VuZGlmCiAJaW50IHN0YXR1czsKIAlGSUxFICpW RmlsZTsKKwl1aW50MzJfdCByeHEgPSAodWludDMyX3QpLTEsIHR4cSA9ICh1aW50MzJfdCktMSwg b3RoZXIgPSAodWludDMyX3QpLTE7CiAjaWZkZWYgV0lOMzIKIAlpZih3c29ja2luaXQoKSAhPSAw KSByZXR1cm4gMTsKICNlbmRpZiAvKiBXSU4zMiAqLwpAQCAtNzM3LDcgKzczOCw3IEBACiAjZW5k aWYKIAogCXdoaWxlICgKLQkgICAgKG9wID0gZ2V0b3B0KGFyZ2MsIGFyZ3YsICJhQWIiIEJfRkxB RyAiYzpDOmQiIERfRkxBRyAiZUU6ZkY6RzpoSGk6IiBJX0ZMQUcgal9GTEFHIEpfRkxBRyAiS2xM bTpNOm5OT3BxcjpSczpTdFQ6dSIgVV9GTEFHICJWOnZ3Olc6eFh5Oll6Olo6IikpICE9IC0xKQor CSAgICAob3AgPSBnZXRvcHQoYXJnYywgYXJndiwgImFBYiIgQl9GTEFHICJjOkM6ZCIgRF9GTEFH ICJlRTpmRjpHOmhIaToiIElfRkxBRyBqX0ZMQUcgSl9GTEFHICJLbExtOk06bk5PcHFyOlJzOlN0 VDp1IiBVX0ZMQUcgIlY6dnc6Vzp4WHk6WXo6WjpROmc6ayIpKSAhPSAtMSkKIAkJc3dpdGNoIChv cCkgewogCiAJCWNhc2UgJ2EnOgpAQCAtODE1LDYgKzgxNiwxMCBAQAogCQkJaW5maWxlID0gb3B0 YXJnOwogCQkJYnJlYWs7CiAKKwkJY2FzZSAnZyc6CisJCQl0eHEgPSBhdG9pKG9wdGFyZyk7CisJ CQlicmVhazsKKwogCQljYXNlICdHJzoKIAkJCUdmbGFnID0gYXRvaShvcHRhcmcpOwogCQkJaWYg KEdmbGFnIDwgMCkKQEAgLTkxOSw2ICs5MjQsMTIgQEAKICNlbmRpZiAvKiBXSU4zMiAqLwogCQkJ YnJlYWs7CiAKKwkJY2FzZSAnayc6CisJCQlvdGhlciA9IGF0b2kob3B0YXJnKTsKKwkJCWlmIChv dGhlciAhPSAwIHx8IG90aGVyICE9IDEpCisJCQkJdXNhZ2UoKTsKKwkJCWJyZWFrOworCiAJCWNh c2UgJ0snOgogCQkJKytLZmxhZzsKIAkJCWJyZWFrOwpAQCAtOTY1LDYgKzk3NiwxMCBAQAogCQkJ KytzdXBwcmVzc19kZWZhdWx0X3ByaW50OwogCQkJYnJlYWs7CiAKKwkJY2FzZSAnUSc6CisJCQly eHEgPSBhdG9pKG9wdGFyZyk7CisJCQlicmVhazsKKwogCQljYXNlICdyJzoKIAkJCVJGaWxlTmFt ZSA9IG9wdGFyZzsKIAkJCWJyZWFrOwpAQCAtMTI3NCw2ICsxMjg5LDEzIEBACiAJCQkgICAgCSAg ICBkZXZpY2UsIHBjYXBfc3RhdHVzdG9zdHIoc3RhdHVzKSk7CiAJCX0KICNlbmRpZgorIAkJaWYg KHJ4cSAhPSAodWludDMyX3QpLTEpCisgCQkJcGNhcF9zZXRfcnhxX21hc2socGQsIHJ4cSk7Cisg CQlpZiAodHhxICE9ICh1aW50MzJfdCktMSkKKyAJCQlwY2FwX3NldF90eHFfbWFzayhwZCwgdHhx KTsKKyAJCWlmIChvdGhlciAhPSAodWludDMyX3QpLTEpCisgCQkJcGNhcF9zZXRfb3RoZXJfbWFz ayhwZCwgb3RoZXIpOworCiAJCXN0YXR1cyA9IHBjYXBfYWN0aXZhdGUocGQpOwogCQlpZiAoc3Rh dHVzIDwgMCkgewogCQkJLyoKQEAgLTIwNzgsNyArMjEwMCw3IEBACiAjZW5kaWYgLyogV0lOMzIg Ki8KICNlbmRpZiAvKiBIQVZFX1BDQVBfTElCX1ZFUlNJT04gKi8KIAkodm9pZClmcHJpbnRmKHN0 ZGVyciwKLSJVc2FnZTogJXMgWy1hQWJkIiBEX0ZMQUcgImVmaEgiIElfRkxBRyBKX0ZMQUcgIkts TG5OT3BxUlN0dSIgVV9GTEFHICJ2eFhdIiBCX0ZMQUdfVVNBR0UgIiBbIC1jIGNvdW50IF1cbiIs IHByb2dyYW1fbmFtZSk7CisiVXNhZ2U6ICVzIFstYUFiZCIgRF9GTEFHICJlZmdoSCIgSV9GTEFH IEpfRkxBRyAia0tsTG5OT3BxUVJTdHUiIFVfRkxBRyAidnhYXSIgQl9GTEFHX1VTQUdFICIgWyAt YyBjb3VudCBdXG4iLCBwcm9ncmFtX25hbWUpOwogCSh2b2lkKWZwcmludGYoc3RkZXJyLAogIlx0 XHRbIC1DIGZpbGVfc2l6ZSBdIFsgLUUgYWxnbzpzZWNyZXQgXSBbIC1GIGZpbGUgXSBbIC1HIHNl Y29uZHMgXVxuIik7CiAJKHZvaWQpZnByaW50ZihzdGRlcnIsCkluZGV4OiBwY2FwLWludC5oCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHBjYXAtaW50LmgJKC4uLi9oZWFkL2NvbnRyaWIvbGlicGNhcC9wY2FwLWlu dC5oKQkocmV2aXNpb24gMjUyNTA5KQorKysgcGNhcC1pbnQuaAkoLi4uL3VzZXIvc3l1dS9tcV9i cGYvY29udHJpYi9saWJwY2FwL3BjYXAtaW50LmgpCShyZXZpc2lvbiAyNTI1MDkpCkBAIC0zMzcs NiArMzM3LDkgQEAKIAl1X2ludCAqdHN0YW1wX3R5cGVfbGlzdDsKIAogCXN0cnVjdCBwY2FwX3Br dGhkciBwY2FwX2hlYWRlcjsJLyogVGhpcyBpcyBuZWVkZWQgZm9yIHRoZSBwY2FwX25leHRfZXgo KSB0byB3b3JrICovCisKKwl1aW50MzJfdCByeHFfbnVtLCB0eHFfbnVtOworCXVpbnQzMl90IG90 aGVyX21hc2s7CiB9OwogCiAvKgpJbmRleDogcGNhcC5oCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHBjYXAuaAko Li4uL2hlYWQvY29udHJpYi9saWJwY2FwL3BjYXAvcGNhcC5oKQkocmV2aXNpb24gMjUyNTA5KQor KysgcGNhcC5oCSguLi4vdXNlci9zeXV1L21xX2JwZi9jb250cmliL2xpYnBjYXAvcGNhcC9wY2Fw LmgpCShyZXZpc2lvbiAyNTI1MDkpCkBAIC0zMzEsNiArMzMxLDEwIEBACiAjZGVmaW5lIFBDQVBf VFNUQU1QX0FEQVBURVIJCTMJLyogZGV2aWNlLXByb3ZpZGVkLCBzeW5jZWQgd2l0aCB0aGUgc3lz dGVtIGNsb2NrICovCiAjZGVmaW5lIFBDQVBfVFNUQU1QX0FEQVBURVJfVU5TWU5DRUQJNAkvKiBk ZXZpY2UtcHJvdmlkZWQsIG5vdCBzeW5jZWQgd2l0aCB0aGUgc3lzdGVtIGNsb2NrICovCiAKK2lu dAlwY2FwX3NldF9yeHFfbWFzayhwY2FwX3QgKiwgdWludDMyX3QpOworaW50CXBjYXBfc2V0X3R4 cV9tYXNrKHBjYXBfdCAqLCB1aW50MzJfdCk7CitpbnQJcGNhcF9zZXRfb3RoZXJfbWFzayhwY2Fw X3QgKiwgdWludDMyX3QpOworCiBwY2FwX3QJKnBjYXBfb3Blbl9saXZlKGNvbnN0IGNoYXIgKiwg aW50LCBpbnQsIGludCwgY2hhciAqKTsKIHBjYXBfdAkqcGNhcF9vcGVuX2RlYWQoaW50LCBpbnQp OwogcGNhcF90CSpwY2FwX29wZW5fb2ZmbGluZShjb25zdCBjaGFyICosIGNoYXIgKik7CkluZGV4 OiBwY2FwLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gcGNhcC5jCSguLi4vaGVhZC9jb250cmliL2xpYnBjYXAv cGNhcC5jKQkocmV2aXNpb24gMjUyNTA5KQorKysgcGNhcC5jCSguLi4vdXNlci9zeXV1L21xX2Jw Zi9jb250cmliL2xpYnBjYXAvcGNhcC5jKQkocmV2aXNpb24gMjUyNTA5KQpAQCAtNTA1LDYgKzUw NSw5IEBACiAJcC0+b3B0LnByb21pc2MgPSAwOwogCXAtPm9wdC5idWZmZXJfc2l6ZSA9IDA7CiAJ cC0+b3B0LnRzdGFtcF90eXBlID0gLTE7CS8qIGRlZmF1bHQgdG8gbm90IHNldHRpbmcgdGltZSBz dGFtcCB0eXBlICovCisgCXAtPnJ4cV9udW0gPSAodWludDMyX3QpLTE7CisgCXAtPnR4cV9udW0g PSAodWludDMyX3QpLTE7CisgCXAtPm90aGVyX21hc2sgPSAodWludDMyX3QpLTE7CiAJcmV0dXJu IChwKTsKIH0KIApAQCAtNjM3LDYgKzY0MCwzMyBAQAogCXJldHVybiAoc3RhdHVzKTsKIH0KIAor aW50CitwY2FwX3NldF9yeHFfbWFzayhwY2FwX3QgKnAsIHVpbnQzMl90IG51bSkKK3sKKwlpZiAo cGNhcF9jaGVja19hY3RpdmF0ZWQocCkpCisJCXJldHVybiBQQ0FQX0VSUk9SX0FDVElWQVRFRDsK KwlwLT5yeHFfbnVtID0gbnVtOworCXJldHVybiAwOworfQorCitpbnQKK3BjYXBfc2V0X3R4cV9t YXNrKHBjYXBfdCAqcCwgdWludDMyX3QgbnVtKQoreworCWlmIChwY2FwX2NoZWNrX2FjdGl2YXRl ZChwKSkKKwkJcmV0dXJuIFBDQVBfRVJST1JfQUNUSVZBVEVEOworCXAtPnR4cV9udW0gPSBudW07 CisJcmV0dXJuIDA7Cit9CisKK2ludAorcGNhcF9zZXRfb3RoZXJfbWFzayhwY2FwX3QgKnAsIHVp bnQzMl90IG1hc2spCit7CisJaWYgKHBjYXBfY2hlY2tfYWN0aXZhdGVkKHApKQorCQlyZXR1cm4g UENBUF9FUlJPUl9BQ1RJVkFURUQ7CisJcC0+b3RoZXJfbWFzayA9IG1hc2s7CisJcmV0dXJuIDA7 Cit9CisKIHBjYXBfdCAqCiBwY2FwX29wZW5fbGl2ZShjb25zdCBjaGFyICpzb3VyY2UsIGludCBz bmFwbGVuLCBpbnQgcHJvbWlzYywgaW50IHRvX21zLCBjaGFyICplcnJidWYpCiB7CkluZGV4OiBw Y2FwLWJwZi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHBjYXAtYnBmLmMJKC4uLi9oZWFkL2NvbnRyaWIvbGli cGNhcC9wY2FwLWJwZi5jKQkocmV2aXNpb24gMjUyNTA5KQorKysgcGNhcC1icGYuYwkoLi4uL3Vz ZXIvc3l1dS9tcV9icGYvY29udHJpYi9saWJwY2FwL3BjYXAtYnBmLmMpCShyZXZpc2lvbiAyNTI1 MDkpCkBAIC0zNCw2ICszNCw3IEBACiAjaW5jbHVkZSA8c3lzL21tYW4uaD4KICNlbmRpZgogI2lu Y2x1ZGUgPHN5cy9zb2NrZXQuaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KICNpbmNsdWRlIDx0 aW1lLmg+CiAvKgogICogPG5ldC9icGYuaD4gZGVmaW5lcyBpb2N0bHMsIGJ1dCBkb2Vzbid0IGlu Y2x1ZGUgPHN5cy9pb2Njb20uaD4uCkBAIC0yMTg3LDYgKzIxODgsNDAgQEAKIAl9CiAjZW5kaWYK IAorCWlmIChwLT5yeHFfbnVtICE9ICh1aW50MzJfdCktMSB8fCBwLT50eHFfbnVtICE9ICh1aW50 MzJfdCktMSB8fAorCQlwLT5vdGhlcl9tYXNrICE9ICh1aW50MzJfdCktMSkgeworCQlpZiAoaW9j dGwoZmQsIEJJT0NFTkFRTUFTSywgTlVMTCkgPCAwKSB7CisJCQlzbnByaW50ZihwLT5lcnJidWYs IFBDQVBfRVJSQlVGX1NJWkUsICJCSU9DRU5BUU1BU0s6ICVzIiwKKwkJCSAgICBwY2FwX3N0cmVy cm9yKGVycm5vKSk7CisJCQlzdGF0dXMgPSBQQ0FQX0VSUk9SOworCQkJZ290byBiYWQ7CisJCX0K KwkJaWYgKHAtPnJ4cV9udW0gIT0gKHVpbnQzMl90KS0xKSB7CisJCQlpZiAoaW9jdGwoZmQsIEJJ T0NTVFJYUU1BU0ssICZwLT5yeHFfbnVtKSA8IDApIHsKKwkJCQlzbnByaW50ZihwLT5lcnJidWYs IFBDQVBfRVJSQlVGX1NJWkUsICJCSU9DU1RSWFFNQVNLOiAlcyIsCisJCQkJICAgIHBjYXBfc3Ry ZXJyb3IoZXJybm8pKTsKKwkJCQlzdGF0dXMgPSBQQ0FQX0VSUk9SOworCQkJCWdvdG8gYmFkOwor CQkJfQorCQl9CisJCWlmIChwLT50eHFfbnVtICE9ICh1aW50MzJfdCktMSkgeworCQkJaWYgKGlv Y3RsKGZkLCBCSU9DU1RUWFFNQVNLLCAmcC0+dHhxX251bSkgPCAwKSB7CisJCQkJc25wcmludGYo cC0+ZXJyYnVmLCBQQ0FQX0VSUkJVRl9TSVpFLCAiQklPQ1NUVFhRTUFTSzogJXMiLAorCQkJCSAg ICBwY2FwX3N0cmVycm9yKGVycm5vKSk7CisJCQkJc3RhdHVzID0gUENBUF9FUlJPUjsKKwkJCQln b3RvIGJhZDsKKwkJCX0KKwkJfQorCQlpZiAocC0+b3RoZXJfbWFzayAhPSAodWludDMyX3QpLTEp IHsKKwkJCWlmIChpb2N0bChmZCwgQklPQ1NUT1RIRVJNQVNLLCAmcC0+b3RoZXJfbWFzaykgPCAw KSB7CisJCQkJc25wcmludGYocC0+ZXJyYnVmLCBQQ0FQX0VSUkJVRl9TSVpFLCAiQklPQ1NUT1RI RVJRTUFTSzogJXMiLAorCQkJCSAgICBwY2FwX3N0cmVycm9yKGVycm5vKSk7CisJCQkJc3RhdHVz ID0gUENBUF9FUlJPUjsKKwkJCQlnb3RvIGJhZDsKKwkJCX0KKwkJfQorCX0KKwogCS8qCiAJICog SWYgdGhlcmUncyBubyBmaWx0ZXIgcHJvZ3JhbSBpbnN0YWxsZWQsIHRoZXJlJ3MKIAkgKiBubyBp bmRpY2F0aW9uIHRvIHRoZSBrZXJuZWwgb2Ygd2hhdCB0aGUgc25hcHNob3QKSW5kZXg6IGlmbmV0 LjkKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gaWZuZXQuOQkoLi4uL2hlYWQvc2hhcmUvbWFuL21hbjkvaWZuZXQu OSkJKHJldmlzaW9uIDI1MjUwOSkKKysrIGlmbmV0LjkJKC4uLi91c2VyL3N5dXUvbXFfYnBmL3No YXJlL21hbi9tYW45L2lmbmV0LjkpCShyZXZpc2lvbiAyNTI1MDkpCkBAIC0xMTksNiArMTE5LDE0 IEBACiAuRm8gXCoobHAqaWZfcmVzb2x2ZW11bHRpXCoocnAKIC5GYSAic3RydWN0IGlmbmV0ICpp ZnAiICJzdHJ1Y3Qgc29ja2FkZHIgKipyZXRzYSIgInN0cnVjdCBzb2NrYWRkciAqYWRkciIKIC5G YworLkZ0IGludAorLkZuIFwqKGxwKmlmX2dldF9yeHF1ZXVlX2xlblwqKHJwICJzdHJ1Y3QgaWZu ZXQgKmlmcCIKKy5GdCBpbnQKKy5GbiBcKihscCppZl9nZXRfdHhxdWV1ZV9sZW5cKihycCAic3Ry dWN0IGlmbmV0ICppZnAiCisuRnQgaW50CisuRm4gXCoobHAqaWZfZ2V0X3J4cXVldWVfYWZmaW5p dHlcKihycCAic3RydWN0IGlmbmV0ICppZnAiICJpbnQgcXVlaWQiCisuRnQgaW50CisuRm4gXCoo bHAqaWZfZ2V0X3R4cXVldWVfYWZmaW5pdHlcKihycCAic3RydWN0IGlmbmV0ICppZnAiICJpbnQg cXVlaWQiCiAuU3MgInN0cnVjdCBpZmFkZHIgbWVtYmVyIGZ1bmN0aW9uIgogLkZ0IHZvaWQKIC5G byBcKihscCppZmFfcnRyZXF1ZXN0XCoocnAKQEAgLTUzNyw2ICs1NDUsMTQgQEAKIGNvcnJlc3Bv bmRzIHRvIHRoYXQgYWRkcmVzcyB3aGljaCBpcyByZXR1cm5lZCBpbgogLkZhICpyZXRzYSAuCiBS ZXR1cm5zIHplcm8gb24gc3VjY2Vzcywgb3IgYW4gZXJyb3IgY29kZSBvbiBmYWlsdXJlLgorLkl0 IEZuIGlmX2dldF9yeHF1ZXVlX2xlbgorR2V0IFJYIHF1ZXVlIGxlbmd0aCwgb25seSByZXF1aXJl ZCBmb3IgbXVsdGlxdWV1ZSBzdXBwb3J0ZWQgaW50ZXJmYWNlcy4KKy5JdCBGbiBpZl9nZXRfdHhx dWV1ZV9sZW4KK0dldCBUWCBxdWV1ZSBsZW5ndGgsIG9ubHkgcmVxdWlyZWQgZm9yIG11bHRpcXVl dWUgc3VwcG9ydGVkIGludGVyZmFjZXMuCisuSXQgRm4gaWZfZ2V0X3J4cXVldWVfYWZmaW5pdHkK K0dldCBSWCBxdWV1ZSBhZmZpbml0eSwgb25seSByZXF1aXJlZCBmb3IgbXVsdGlxdWV1ZSBzdXBw b3J0ZWQgaW50ZXJmYWNlcy4KKy5JdCBGbiBpZl9nZXRfdHhxdWV1ZV9hZmZpbml0eQorR2V0IFRY IHF1ZXVlIGFmZmluaXR5LCBvbmx5IHJlcXVpcmVkIGZvciBtdWx0aXF1ZXVlIHN1cHBvcnRlZCBp bnRlcmZhY2VzLgogLkVsCiAuU3MgIkludGVyZmFjZSBGbGFncyIKIEludGVyZmFjZSBmbGFncyBh cmUgdXNlZCBmb3IgYSBudW1iZXIgb2YgZGlmZmVyZW50IHB1cnBvc2VzLgpJbmRleDogbmV0aW50 cm8uNAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBuZXRpbnRyby40CSguLi4vaGVhZC9zaGFyZS9tYW4vbWFuNC9u ZXRpbnRyby40KQkocmV2aXNpb24gMjUyNTA5KQorKysgbmV0aW50cm8uNAkoLi4uL3VzZXIvc3l1 dS9tcV9icGYvc2hhcmUvbWFuL21hbjQvbmV0aW50cm8uNCkJKHJldmlzaW9uIDI1MjUwOSkKQEAg LTIxMyw2ICsyMTMsOCBAQAogICAgICAgICBpbnQgICAgICAgaWZydV9tZWRpYTsKICAgICAgICAg Y2FkZHJfdCAgIGlmcnVfZGF0YTsKICAgICAgICAgaW50ICAgICAgIGlmcnVfY2FwWzJdOworICAg ICAgICBpbnQgICAgICAgaWZydV9xdWV1ZV9sZW5bMl07CisgICAgICAgIGludCAgICAgICBpZnJ1 X3F1ZXVlX2FmZmluaXR5WzJdOwogICAgIH0gaWZyX2lmcnU7CiAjZGVmaW5lIGlmcl9hZGRyICAg ICAgaWZyX2lmcnUuaWZydV9hZGRyICAgICAgLyogYWRkcmVzcyAqLwogI2RlZmluZSBpZnJfZHN0 YWRkciAgIGlmcl9pZnJ1LmlmcnVfZHN0YWRkciAgIC8qIG90aGVyIGVuZCBvZiBwLXRvLXAgbGlu ayAqLwpAQCAtMjI4LDYgKzIzMCwxMCBAQAogI2RlZmluZSBpZnJfcmVxY2FwICAgIGlmcl9pZnJ1 LmlmcnVfY2FwWzBdICAgIC8qIHJlcXVlc3RlZCBjYXBhYmlsaXRpZXMgKi8KICNkZWZpbmUgaWZy X2N1cmNhcCAgICBpZnJfaWZydS5pZnJ1X2NhcFsxXSAgICAvKiBjdXJyZW50IGNhcGFiaWxpdGll cyAqLwogI2RlZmluZSBpZnJfaW5kZXggICAgIGlmcl9pZnJ1LmlmcnVfaW5kZXggICAgIC8qIGlu dGVyZmFjZSBpbmRleCAqLworI2RlZmluZSBpZnJfcnhxdWV1ZV9sZW4JaWZyX2lmcnUuaWZydV9x dWV1ZV9sZW5bMF0gLyogcnhxdWV1ZSBsZW4gKi8KKyNkZWZpbmUgaWZyX3R4cXVldWVfbGVuCWlm cl9pZnJ1LmlmcnVfcXVldWVfbGVuWzFdIC8qIHR4cXVldWUgbGVuICovCisjZGVmaW5lIGlmcl9x dWV1ZV9hZmZpbml0eV9pbmRleCBpZnJfaWZydS5pZnJ1X3F1ZXVlX2FmZmluaXR5WzBdIC8qIHF1 ZXVlIGlkICovCisjZGVmaW5lIGlmcl9xdWV1ZV9hZmZpbml0eV9jcHUgaWZyX2lmcnUuaWZydV9x dWV1ZV9hZmZpbml0eVsxXSAvKiBjcHUgaWQgKi8KIH07CiAuRWQKIC5QcApAQCAtMzE5LDYgKzMy NSwxMiBAQAogZmllbGQgd2lsbCBjb250YWluIHRoZSBuZXcgaW50ZXJmYWNlIG5hbWUuCiAuSXQg RHYgU0lPQ0lGREVTVFJPWQogQXR0ZW1wdCB0byBkZXN0cm95IHRoZSBzcGVjaWZpZWQgaW50ZXJm YWNlLgorLkl0IER2IFNJT0NHSUZRTEVOCitHZXQgaW50ZXJmYWNlIFJYL1RYIHF1ZXVlIGxlbmd0 aC4KKy5JdCBEdiBTSU9DR0lGUlhRQUZGSU5JVFkKK0dldCBpbnRlcmZhY2UgUlggcXVldWUgYWZm aW5pdHkuCisuSXQgRHYgU0lPQ0dJRlRYUUFGRklOSVRZCitHZXQgaW50ZXJmYWNlIFRYIHF1ZXVl IGFmZmluaXR5LgogLkVsCiAuUHAKIFRoZXJlIGFyZSB0d28gcmVxdWVzdHMgdGhhdCBtYWtlIHVz ZSBvZiBhIG5ldyBzdHJ1Y3R1cmU6CkluZGV4OiBicGYuNAo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBicGYuNAko Li4uL2hlYWQvc2hhcmUvbWFuL21hbjQvYnBmLjQpCShyZXZpc2lvbiAyNTI1MDkpCisrKyBicGYu NAkoLi4uL3VzZXIvc3l1dS9tcV9icGYvc2hhcmUvbWFuL21hbjQvYnBmLjQpCShyZXZpc2lvbiAy NTI1MDkpCkBAIC02MzEsNiArNjMxLDQ2IEBACiAuVnQgYnpoX2tlcm5lbF9nZW4KIGFnYWluc3QK IC5WdCBiemhfdXNlcl9nZW4gLgorLkl0IER2IEJJT0NFTkFRTUFTSworRW5hYmxlcyBtdWx0aXF1 ZXVlIGZpbHRlciBvbiB0aGUgZGVzY3JpcHRvci4KKworLkl0IER2IEJJT0NESVNRTUFTSworRGlz YWJsZXMgbXVsdGlxdWV1ZSBmaWx0ZXIgb24gdGhlIGRlc2NyaXB0b3IuCisKKy5JdCBEdiBCSU9D U1RSWFFNQVNLCisuUHEgTGkgdWludDMyX3QKK1NldCBtYXNrIGJpdCBvbiBzcGVjaWZpZWQgUlgg cXVldWUuCisKKy5JdCBEdiBCSU9DQ1JSWFFNQVNLCisuUHEgTGkgdWludDMyX3QKK0NsZWFyIG1h c2sgYml0IG9uIHNwZWNpZmllZCBSWCBxdWV1ZS4KKworLkl0IER2IEJJT0NHVFJYUU1BU0sKKy5Q cSBMaSB1aW50MzJfdAorR2V0IG1hc2sgYml0IG9uIHNwZWNpZmllZCBSWCBxdWV1ZS4KKworLkl0 IER2IEJJT0NTVFRYUU1BU0sKKy5QcSBMaSB1aW50MzJfdAorU2V0IG1hc2sgYml0IG9uIHNwZWNp ZmllZCBUWCBxdWV1ZS4KKworLkl0IER2IEJJT0NDUlRYUU1BU0sKKy5QcSBMaSB1aW50MzJfdAor Q2xlYXIgbWFzayBiaXQgb24gc3BlY2lmaWVkIFRYIHF1ZXVlLgorCisuSXQgRHYgQklPQ0dUVFhR TUFTSworLlBxIExpIHVpbnQzMl90CitHZXQgbWFzayBiaXQgb24gc3BlY2lmaWVkIFRYIHF1ZXVl LgorCisuSXQgRHYgQklPQ1NUT1RIRVJNQVNLCitTZXQgbWFzayBiaXQgZm9yIHRoZSBwYWNrZXRz IHdoaWNoIG5vdCB0aWVkIHdpdGggYW55IHF1ZXVlcy4KKworLkl0IER2IEJJT0NDUk9USEVSTUFT SworQ2xlYXIgbWFzayBiaXQgZm9yIHRoZSBwYWNrZXRzIHdoaWNoIG5vdCB0aWVkIHdpdGggYW55 IHF1ZXVlcy4KKworLkl0IER2IEJJT0NHVE9USEVSTUFTSworLlBxIExpIHVpbnQzMl90CitHZXQg bWFzayBiaXQgZm9yIHRoZSBwYWNrZXRzIHdoaWNoIG5vdCB0aWVkIHdpdGggYW55IHF1ZXVlcy4K KwogLkVsCiAuU2ggQlBGIEhFQURFUgogT25lIG9mIHRoZSBmb2xsb3dpbmcgc3RydWN0dXJlcyBp cyBwcmVwZW5kZWQgdG8gZWFjaCBwYWNrZXQgcmV0dXJuZWQgYnkKQEAgLTEwMzcsNiArMTA3Nywy NCBAQAogCUJQRl9TVE1UKEJQRl9SRVQrQlBGX0ssIDApLAogfTsKIC5FZAorLlNoIE1VTFRJUVVF VUUgU1VQUE9SVAorTXVsdGlxdWV1ZSBuZXR3b3JrIGludGVyZmFjZSBzdXBwb3J0IGZ1bmN0aW9u IHByb3ZpZGVzIGludGVyZmFjZXMgZm9yIAorbXVsdGl0aHJlYWRlZCBwYWNrZXQgcHJvY2Vzc2lu ZyB1c2luZyBicGYuCisKK05vcm1hbCBicGYgY2FuIHJlY2VpdmUgcGFja2V0cyBmcm9tIHNwZWNp ZmllZCBpbnRlcmZhY2UsIG11bHRpcXVldWUgc3VwcG9ydCAKK2Z1bmN0aW9uIGNhbiByZWNlaXZl IHBhY2tldHMgZnJvbSBzcGVjaWZpZWQgaGFyZHdhcmUgcXVldWUuCisKK1RoaXMgZGlzdHJpYnV0 ZXMgYnBmIHdvcmtsb2FkIG9uIG11bHRpcGxlIHRocmVhZHMsIGFsc28gcmVkdWNlcyBsb2NrIAor Y29udGVudGlvbiBvbiBicGYuCisKK1RvIG1ha2UgeW91ciBwcm9ncmFtIG11bHRpdGhyZWFkZWQs IHlvdSdsbCBuZWVkIHRvIG9wZW4gYnBmIGRlc2NyaXB0b3Igb24gZWFjaCAKK3RocmVhZCwgZW5h YmxlIG11bHRpcXVldWUgc3VwcG9ydCBieSBCSU9DRU5BUU1BU0sgaW9jdGwsIGFuZCBzZXQgcXVl dWUgbWFzayBieSAKK0JJT0NTVFJYUU1BU0sgLyBCSU9DU1RUWFFNQVNLIC8gQklPQ1NUT1RIRVJN QVNLIGlvY3Rscy4KKworUXVldWUgbGVuZ3RoIGFuZCBxdWV1ZSBhZmZpbml0eSBpbmZvcm1hdGlv biBtYXkgdXNlZnVsIHRvIG9wdGltaXplIHNldHRpbmcgCitxdWV1ZSBtYXNrIG9uIGJwZiBkZXNj cmlwdG9yLCBzZWUKKy5YciBuZXRpbnRybyA0IC4KKwogLlNoIFNFRSBBTFNPCiAuWHIgdGNwZHVt cCAxICwKIC5YciBpb2N0bCAyICwKSW5kZXg6IGlmX214Z2UuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBpZl9t eGdlLmMJKC4uLi9oZWFkL3N5cy9kZXYvbXhnZS9pZl9teGdlLmMpCShyZXZpc2lvbiAyNTI1MDkp CisrKyBpZl9teGdlLmMJKC4uLi91c2VyL3N5dXUvbXFfYnBmL3N5cy9kZXYvbXhnZS9pZl9teGdl LmMpCShyZXZpc2lvbiAyNTI1MDkpCkBAIC0xMjAsNiArMTIwLDExIEBACiBzdGF0aWMgaW50IG14 Z2Vfc2h1dGRvd24oZGV2aWNlX3QgZGV2KTsKIHN0YXRpYyB2b2lkIG14Z2VfaW50cih2b2lkICph cmcpOwogCitzdGF0aWMgaW50IG14Z2VfZ2V0X3J4cXVldWVfbGVuKHN0cnVjdCBpZm5ldCAqKTsK K3N0YXRpYyBpbnQgbXhnZV9nZXRfdHhxdWV1ZV9sZW4oc3RydWN0IGlmbmV0ICopOworc3RhdGlj IGludCBteGdlX2dldF9yeHF1ZXVlX2FmZmluaXR5KHN0cnVjdCBpZm5ldCAqLCBpbnQpOworc3Rh dGljIGludCBteGdlX2dldF90eHF1ZXVlX2FmZmluaXR5KHN0cnVjdCBpZm5ldCAqLCBpbnQpOwor CiBzdGF0aWMgZGV2aWNlX21ldGhvZF90IG14Z2VfbWV0aG9kc1tdID0KIHsKICAgLyogRGV2aWNl IGludGVyZmFjZSAqLwpAQCAtMjI3Miw2ICsyMjc3LDkgQEAKIAkJaWYgKG0gPT0gTlVMTCkgewog CQkJcmV0dXJuOwogCQl9CisJCW0tPm1fcGt0aGRyLnJ4cXVldWUgPSAodWludDMyX3QpLTE7CisJ CW0tPm1fcGt0aGRyLnR4cXVldWUgPSAoc3MgLSBzYy0+c3MpOworCiAJCS8qIGxldCBCUEYgc2Vl IGl0ICovCiAJCUJQRl9NVEFQKGlmcCwgbSk7CiAKQEAgLTIzMDYsNiArMjMxNCw5IEBACiAKIAlp ZiAoIWRyYnJfbmVlZHNfZW5xdWV1ZShpZnAsIHR4LT5icikgJiYKIAkgICAgKCh0eC0+bWFzayAt ICh0eC0+cmVxIC0gdHgtPmRvbmUpKSA+IHR4LT5tYXhfZGVzYykpIHsKKwkJbS0+bV9wa3RoZHIu cnhxdWV1ZSA9ICh1aW50MzJfdCktMTsKKwkJbS0+bV9wa3RoZHIudHhxdWV1ZSA9IChzcyAtIHNj LT5zcyk7CisKIAkJLyogbGV0IEJQRiBzZWUgaXQgKi8KIAkJQlBGX01UQVAoaWZwLCBtKTsKIAkJ LyogZ2l2ZSBpdCB0byB0aGUgbmljICovCkBAIC0yNzE5LDYgKzI3MzAsOCBAQAogCWlmIChzYy0+ bnVtX3NsaWNlcyA+IDEpIHsKIAkJbS0+bV9wa3RoZHIuZmxvd2lkID0gKHNzIC0gc2MtPnNzKTsK IAkJbS0+bV9mbGFncyB8PSBNX0ZMT1dJRDsKKwkJbS0+bV9wa3RoZHIucnhxdWV1ZSA9IChzcyAt IHNjLT5zcyk7CisJCW0tPm1fcGt0aGRyLnR4cXVldWUgPSAodWludDMyX3QpLTE7CiAJfQogCS8q IHBhc3MgdGhlIGZyYW1lIHVwIHRoZSBzdGFjayAqLwogCSgqaWZwLT5pZl9pbnB1dCkoaWZwLCBt KTsKQEAgLTQ4OTYsNiArNDkwOSw3IEBACiAjaWYgZGVmaW5lZChJTkVUKSB8fCBkZWZpbmVkKElO RVQ2KQogCWlmcC0+aWZfY2FwYWJpbGl0aWVzIHw9IElGQ0FQX0xSTzsKICNlbmRpZgorCWlmcC0+ aWZfY2FwYWJpbGl0aWVzIHw9IElGQ0FQX01VTFRJUVVFVUU7CiAKICNpZmRlZiBNWEdFX05FV19W TEFOX0FQSQogCWlmcC0+aWZfY2FwYWJpbGl0aWVzIHw9IElGQ0FQX1ZMQU5fSFdUQUdHSU5HIHwg SUZDQVBfVkxBTl9IV0NTVU07CkBAIC00OTI5LDYgKzQ5NDMsMTEgQEAKICAgICAgICAgaWZwLT5p Zl9mbGFncyA9IElGRl9CUk9BRENBU1QgfCBJRkZfU0lNUExFWCB8IElGRl9NVUxUSUNBU1Q7CiAg ICAgICAgIGlmcC0+aWZfaW9jdGwgPSBteGdlX2lvY3RsOwogICAgICAgICBpZnAtPmlmX3N0YXJ0 ID0gbXhnZV9zdGFydDsKKwlpZnAtPmlmX2dldF9yeHF1ZXVlX2xlbiA9IG14Z2VfZ2V0X3J4cXVl dWVfbGVuOworCWlmcC0+aWZfZ2V0X3R4cXVldWVfbGVuID0gbXhnZV9nZXRfdHhxdWV1ZV9sZW47 CisJaWZwLT5pZl9nZXRfcnhxdWV1ZV9hZmZpbml0eSA9IG14Z2VfZ2V0X3J4cXVldWVfYWZmaW5p dHk7CisJaWZwLT5pZl9nZXRfdHhxdWV1ZV9hZmZpbml0eSA9IG14Z2VfZ2V0X3R4cXVldWVfYWZm aW5pdHk7CisKIAkvKiBJbml0aWFsaXNlIHRoZSBpZm1lZGlhIHN0cnVjdHVyZSAqLwogCWlmbWVk aWFfaW5pdCgmc2MtPm1lZGlhLCAwLCBteGdlX21lZGlhX2NoYW5nZSwgCiAJCSAgICAgbXhnZV9t ZWRpYV9zdGF0dXMpOwpAQCAtNTAyNSw2ICs1MDQ0LDMzIEBACiAJcmV0dXJuIDA7CiB9CiAKKwor c3RhdGljIGludAorbXhnZV9nZXRfcnhxdWV1ZV9sZW4oc3RydWN0IGlmbmV0ICppZnApCit7CisJ bXhnZV9zb2Z0Y190ICpzYyA9IGlmcC0+aWZfc29mdGM7CisJcmV0dXJuIChzYy0+bnVtX3NsaWNl cyk7Cit9CisKK3N0YXRpYyBpbnQKK214Z2VfZ2V0X3R4cXVldWVfbGVuKHN0cnVjdCBpZm5ldCAq aWZwKQoreworCW14Z2Vfc29mdGNfdCAqc2MgPSBpZnAtPmlmX3NvZnRjOworCXJldHVybiAoc2Mt Pm51bV9zbGljZXMpOworfQorCitzdGF0aWMgaW50CitteGdlX2dldF9yeHF1ZXVlX2FmZmluaXR5 KHN0cnVjdCBpZm5ldCAqaWZwLCBpbnQgcXVlaWQpCit7CisJcmV0dXJuIChxdWVpZCk7Cit9CisK K3N0YXRpYyBpbnQKK214Z2VfZ2V0X3R4cXVldWVfYWZmaW5pdHkoc3RydWN0IGlmbmV0ICppZnAs IGludCBxdWVpZCkKK3sKKwlyZXR1cm4gKHF1ZWlkKTsKK30KKwogLyoKICAgVGhpcyBmaWxlIHVz ZXMgTXlyaTEwR0UgZHJpdmVyIGluZGVudGF0aW9uLgogCkluZGV4OiBpeGdiZS5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIGl4Z2JlLmMJKC4uLi9oZWFkL3N5cy9kZXYvaXhnYmUvaXhnYmUuYykJKHJldmlzaW9u IDI1MjUwOSkKKysrIGl4Z2JlLmMJKC4uLi91c2VyL3N5dXUvbXFfYnBmL3N5cy9kZXYvaXhnYmUv aXhnYmUuYykJKHJldmlzaW9uIDI1MjUwOSkKQEAgLTIxMCw2ICsyMTAsMTIgQEAKIC8qIE1pc3Np bmcgc2hhcmVkIGNvZGUgcHJvdG90eXBlICovCiBleHRlcm4gdm9pZCBpeGdiZV9zdG9wX21hY19s aW5rX29uX2QzXzgyNTk5KHN0cnVjdCBpeGdiZV9odyAqaHcpOwogCitzdGF0aWMgaW50CWl4Z2Jl X2dldF9yeHF1ZXVlX2xlbihzdHJ1Y3QgaWZuZXQgKik7CitzdGF0aWMgaW50CWl4Z2JlX2dldF90 eHF1ZXVlX2xlbihzdHJ1Y3QgaWZuZXQgKik7CitzdGF0aWMgaW50CWl4Z2JlX2dldF9yeHF1ZXVl X2FmZmluaXR5KHN0cnVjdCBpZm5ldCAqLCBpbnQpOworc3RhdGljIGludAlpeGdiZV9nZXRfdHhx dWV1ZV9hZmZpbml0eShzdHJ1Y3QgaWZuZXQgKiwgaW50KTsKKworCiAvKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCiAg KiAgRnJlZUJTRCBEZXZpY2UgSW50ZXJmYWNlIEVudHJ5IFBvaW50cwogICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8K QEAgLTc1Myw2ICs3NTksMTAgQEAKIAkJCQlJRlFfRFJWX1BSRVBFTkQoJmlmcC0+aWZfc25kLCBt X2hlYWQpOwogCQkJYnJlYWs7CiAJCX0KKworCQltX2hlYWQtPm1fcGt0aGRyLnJ4cXVldWUgPSAo dWludDMyX3QpLTE7CisJCW1faGVhZC0+bV9wa3RoZHIudHhxdWV1ZSA9IHR4ci0+bWU7CisKIAkJ LyogU2VuZCBhIGNvcHkgb2YgdGhlIGZyYW1lIHRvIHRoZSBCUEYgbGlzdGVuZXIgKi8KIAkJRVRI RVJfQlBGX01UQVAoaWZwLCBtX2hlYWQpOwogCkBAIC04NTEsNiArODYxLDEwIEBACiAJCWRyYnJf YWR2YW5jZShpZnAsIHR4ci0+YnIpOwogI2VuZGlmCiAJCWVucXVldWVkKys7CisgCisgCQluZXh0 LT5tX3BrdGhkci5yeHF1ZXVlID0gKHVpbnQzMl90KS0xOworIAkJbmV4dC0+bV9wa3RoZHIudHhx dWV1ZSA9IHR4ci0+bWU7CisKIAkJLyogU2VuZCBhIGNvcHkgb2YgdGhlIGZyYW1lIHRvIHRoZSBC UEYgbGlzdGVuZXIgKi8KIAkJRVRIRVJfQlBGX01UQVAoaWZwLCBuZXh0KTsKIAkJaWYgKChpZnAt PmlmX2Rydl9mbGFncyAmIElGRl9EUlZfUlVOTklORykgPT0gMCkKQEAgLTI2MTgsNiArMjYzMiwx MCBAQAogCWlmcC0+aWZfc29mdGMgPSBhZGFwdGVyOwogCWlmcC0+aWZfZmxhZ3MgPSBJRkZfQlJP QURDQVNUIHwgSUZGX1NJTVBMRVggfCBJRkZfTVVMVElDQVNUOwogCWlmcC0+aWZfaW9jdGwgPSBp eGdiZV9pb2N0bDsKKyAJaWZwLT5pZl9nZXRfcnhxdWV1ZV9sZW4gPSBpeGdiZV9nZXRfcnhxdWV1 ZV9sZW47CisgCWlmcC0+aWZfZ2V0X3R4cXVldWVfbGVuID0gaXhnYmVfZ2V0X3R4cXVldWVfbGVu OworIAlpZnAtPmlmX2dldF9yeHF1ZXVlX2FmZmluaXR5ID0gaXhnYmVfZ2V0X3J4cXVldWVfYWZm aW5pdHk7CisgCWlmcC0+aWZfZ2V0X3R4cXVldWVfYWZmaW5pdHkgPSBpeGdiZV9nZXRfdHhxdWV1 ZV9hZmZpbml0eTsKICNpZm5kZWYgSVhHQkVfTEVHQUNZX1RYCiAJaWZwLT5pZl90cmFuc21pdCA9 IGl4Z2JlX21xX3N0YXJ0OwogCWlmcC0+aWZfcWZsdXNoID0gaXhnYmVfcWZsdXNoOwpAQCAtMjY0 NCw2ICsyNjYyLDcgQEAKIAlpZnAtPmlmX2NhcGFiaWxpdGllcyB8PSBJRkNBUF9WTEFOX0hXVEFH R0lORwogCQkJICAgICB8ICBJRkNBUF9WTEFOX0hXVFNPCiAJCQkgICAgIHwgIElGQ0FQX1ZMQU5f TVRVOworCWlmcC0+aWZfY2FwYWJpbGl0aWVzIHw9IElGQ0FQX01VTFRJUVVFVUU7CiAJaWZwLT5p Zl9jYXBlbmFibGUgPSBpZnAtPmlmX2NhcGFiaWxpdGllczsKIAogCS8qCkBAIC00NTQ3LDYgKzQ1 NjYsOCBAQAogCQkJc2VuZG1wLT5tX3BrdGhkci5mbG93aWQgPSBxdWUtPm1zaXg7CiAJCQlzZW5k bXAtPm1fZmxhZ3MgfD0gTV9GTE9XSUQ7CiAjZW5kaWYKKwkJCXNlbmRtcC0+bV9wa3RoZHIucnhx dWV1ZSA9IHF1ZS0+bXNpeDsKKwkJCXNlbmRtcC0+bV9wa3RoZHIudHhxdWV1ZSA9ICh1aW50MzJf dCktMTsKIAkJfQogbmV4dF9kZXNjOgogCQlidXNfZG1hbWFwX3N5bmMocnhyLT5yeGRtYS5kbWFf dGFnLCByeHItPnJ4ZG1hLmRtYV9tYXAsCkBAIC01NzQzLDYgKzU3NjQsMzIgQEAKIAlyZXR1cm4g KGVycm9yKTsKIH0KIAorc3RhdGljIGludAoraXhnYmVfZ2V0X3J4cXVldWVfbGVuKHN0cnVjdCBp Zm5ldCAqaWZwKQoreworCXN0cnVjdCBhZGFwdGVyCSphZGFwdGVyID0gaWZwLT5pZl9zb2Z0YzsK KwlyZXR1cm4gKGFkYXB0ZXItPm51bV9xdWV1ZXMpOworfQorCitzdGF0aWMgaW50CitpeGdiZV9n ZXRfdHhxdWV1ZV9sZW4oc3RydWN0IGlmbmV0ICppZnApCit7CisJc3RydWN0IGFkYXB0ZXIJKmFk YXB0ZXIgPSBpZnAtPmlmX3NvZnRjOworCXJldHVybiAoYWRhcHRlci0+bnVtX3F1ZXVlcyk7Cit9 CisKK3N0YXRpYyBpbnQKK2l4Z2JlX2dldF9yeHF1ZXVlX2FmZmluaXR5KHN0cnVjdCBpZm5ldCAq aWZwLCBpbnQgcXVlaWQpCit7CisJcmV0dXJuIChxdWVpZCk7Cit9CisKK3N0YXRpYyBpbnQKK2l4 Z2JlX2dldF90eHF1ZXVlX2FmZmluaXR5KHN0cnVjdCBpZm5ldCAqaWZwLCBpbnQgcXVlaWQpCit7 CisJcmV0dXJuIChxdWVpZCk7Cit9CisKIC8qCiAqKiBUaGVybWFsIFNodXRkb3duIFRyaWdnZXIK ICoqICAgLSBjYXVzZSBhIFRoZXJtYWwgT3ZlcnRlbXAgSVJRCkluZGV4OiBpZl9pZ2IuYwo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBpZl9pZ2IuYwkoLi4uL2hlYWQvc3lzL2Rldi9lMTAwMC9pZl9pZ2IuYykJKHJl dmlzaW9uIDI1MjUwOSkKKysrIGlmX2lnYi5jCSguLi4vdXNlci9zeXV1L21xX2JwZi9zeXMvZGV2 L2UxMDAwL2lmX2lnYi5jKQkocmV2aXNpb24gMjUyNTA5KQpAQCAtMjc4LDYgKzI3OCwxMSBAQAog c3RhdGljIGludAlpZ2Jfc3lzY3RsX2RtYWMoU1lTQ1RMX0hBTkRMRVJfQVJHUyk7CiBzdGF0aWMg aW50CWlnYl9zeXNjdGxfZWVlKFNZU0NUTF9IQU5ETEVSX0FSR1MpOwogCitzdGF0aWMgaW50CWln Yl9nZXRfcnhxdWV1ZV9sZW4oc3RydWN0IGlmbmV0ICopOworc3RhdGljIGludAlpZ2JfZ2V0X3R4 cXVldWVfbGVuKHN0cnVjdCBpZm5ldCAqKTsKK3N0YXRpYyBpbnQJaWdiX2dldF9yeHF1ZXVlX2Fm ZmluaXR5KHN0cnVjdCBpZm5ldCAqLCBpbnQpOworc3RhdGljIGludAlpZ2JfZ2V0X3R4cXVldWVf YWZmaW5pdHkoc3RydWN0IGlmbmV0ICosIGludCk7CisKICNpZmRlZiBERVZJQ0VfUE9MTElORwog c3RhdGljIHBvbGxfaGFuZGxlcl90IGlnYl9wb2xsOwogI2VuZGlmIC8qIFBPTExJTkcgKi8KQEAg LTkxOSw2ICs5MjQsOSBAQAogCQkJYnJlYWs7CiAJCX0KIAorCQltX2hlYWQtPm1fcGt0aGRyLnJ4 cXVldWUgPSAodWludDMyX3QpLTE7CisJCW1faGVhZC0+bV9wa3RoZHIudHhxdWV1ZSA9IHR4ci0+ bWU7CisKIAkJLyogU2VuZCBhIGNvcHkgb2YgdGhlIGZyYW1lIHRvIHRoZSBCUEYgbGlzdGVuZXIg Ki8KIAkJRVRIRVJfQlBGX01UQVAoaWZwLCBtX2hlYWQpOwogCkBAIC0xMDEyLDYgKzEwMjAsOCBA QAogCQlpZnAtPmlmX29ieXRlcyArPSBuZXh0LT5tX3BrdGhkci5sZW47CiAJCWlmIChuZXh0LT5t X2ZsYWdzICYgTV9NQ0FTVCkKIAkJCWlmcC0+aWZfb21jYXN0cysrOworCQluZXh0LT5tX3BrdGhk ci5yeHF1ZXVlID0gKHVpbnQzMl90KS0xOworCQluZXh0LT5tX3BrdGhkci50eHF1ZXVlID0gdHhy LT5tZTsKIAkJRVRIRVJfQlBGX01UQVAoaWZwLCBuZXh0KTsKIAkJaWYgKChpZnAtPmlmX2Rydl9m bGFncyAmIElGRl9EUlZfUlVOTklORykgPT0gMCkKIAkJCWJyZWFrOwpAQCAtMzExMiw2ICszMTIy LDEwIEBACiAJaWZwLT5pZl9zb2Z0YyA9IGFkYXB0ZXI7CiAJaWZwLT5pZl9mbGFncyA9IElGRl9C Uk9BRENBU1QgfCBJRkZfU0lNUExFWCB8IElGRl9NVUxUSUNBU1Q7CiAJaWZwLT5pZl9pb2N0bCA9 IGlnYl9pb2N0bDsKKyAJaWZwLT5pZl9nZXRfcnhxdWV1ZV9sZW4gPSBpZ2JfZ2V0X3J4cXVldWVf bGVuOworIAlpZnAtPmlmX2dldF90eHF1ZXVlX2xlbiA9IGlnYl9nZXRfdHhxdWV1ZV9sZW47Cisg CWlmcC0+aWZfZ2V0X3J4cXVldWVfYWZmaW5pdHkgPSBpZ2JfZ2V0X3J4cXVldWVfYWZmaW5pdHk7 CisgCWlmcC0+aWZfZ2V0X3R4cXVldWVfYWZmaW5pdHkgPSBpZ2JfZ2V0X3R4cXVldWVfYWZmaW5p dHk7CiAjaWZuZGVmIElHQl9MRUdBQ1lfVFgKIAlpZnAtPmlmX3RyYW5zbWl0ID0gaWdiX21xX3N0 YXJ0OwogCWlmcC0+aWZfcWZsdXNoID0gaWdiX3FmbHVzaDsKQEAgLTMxNTksNiArMzE3Myw3IEBA CiAJKiogZW5hYmxlIHRoaXMgYW5kIGdldCBmdWxsIGhhcmR3YXJlIHRhZyBmaWx0ZXJpbmcuCiAJ Ki8KIAlpZnAtPmlmX2NhcGFiaWxpdGllcyB8PSBJRkNBUF9WTEFOX0hXRklMVEVSOworCWlmcC0+ aWZfY2FwYWJpbGl0aWVzIHw9IElGQ0FQX01VTFRJUVVFVUU7CiAKIAkvKgogCSAqIFNwZWNpZnkg dGhlIG1lZGlhIHR5cGVzIHN1cHBvcnRlZCBieSB0aGlzIGFkYXB0ZXIgYW5kIHJlZ2lzdGVyCkBA IC00ODgzLDYgKzQ4OTgsOSBAQAogCQkJcnhyLT5mbXAtPm1fcGt0aGRyLmZsb3dpZCA9IHF1ZS0+ bXNpeDsKIAkJCXJ4ci0+Zm1wLT5tX2ZsYWdzIHw9IE1fRkxPV0lEOwogI2VuZGlmCisJCQlyeHIt PmZtcC0+bV9wa3RoZHIucnhxdWV1ZSA9IHF1ZS0+bXNpeDsKKwkJCXJ4ci0+Zm1wLT5tX3BrdGhk ci50eHF1ZXVlID0gKHVpbnQzMl90KS0xOworCiAJCQlzZW5kbXAgPSByeHItPmZtcDsKIAkJCS8q IE1ha2Ugc3VyZSB0byBzZXQgTV9QS1RIRFIuICovCiAJCQlzZW5kbXAtPm1fZmxhZ3MgfD0gTV9Q S1RIRFI7CkBAIC02MDQ3LDMgKzYwNjUsMjkgQEAKIAlJR0JfQ09SRV9VTkxPQ0soYWRhcHRlcik7 CiAJcmV0dXJuICgwKTsKIH0KKworc3RhdGljIGludAoraWdiX2dldF9yeHF1ZXVlX2xlbihzdHJ1 Y3QgaWZuZXQgKmlmcCkKK3sKKwlzdHJ1Y3QgYWRhcHRlcgkqYWRhcHRlciA9IGlmcC0+aWZfc29m dGM7CisJcmV0dXJuIChhZGFwdGVyLT5udW1fcXVldWVzKTsKK30KKworc3RhdGljIGludAoraWdi X2dldF90eHF1ZXVlX2xlbihzdHJ1Y3QgaWZuZXQgKmlmcCkKK3sKKwlzdHJ1Y3QgYWRhcHRlcgkq YWRhcHRlciA9IGlmcC0+aWZfc29mdGM7CisJcmV0dXJuIChhZGFwdGVyLT5udW1fcXVldWVzKTsK K30KKworc3RhdGljIGludAoraWdiX2dldF9yeHF1ZXVlX2FmZmluaXR5KHN0cnVjdCBpZm5ldCAq aWZwLCBpbnQgcXVlaWQpCit7CisJcmV0dXJuIChxdWVpZCk7Cit9CisKK3N0YXRpYyBpbnQKK2ln Yl9nZXRfdHhxdWV1ZV9hZmZpbml0eShzdHJ1Y3QgaWZuZXQgKmlmcCwgaW50IHF1ZWlkKQorewor CXJldHVybiAocXVlaWQpOworfQpJbmRleDogYnBmZGVzYy5oCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGJwZmRl c2MuaAkoLi4uL2hlYWQvc3lzL25ldC9icGZkZXNjLmgpCShyZXZpc2lvbiAyNTI1MDkpCisrKyBi cGZkZXNjLmgJKC4uLi91c2VyL3N5dXUvbXFfYnBmL3N5cy9uZXQvYnBmZGVzYy5oKQkocmV2aXNp b24gMjUyNTA5KQpAQCAtNDUsNiArNDUsMjAgQEAKICNpbmNsdWRlIDxzeXMvY29uZi5oPgogI2lu Y2x1ZGUgPG5ldC9pZi5oPgogCitzdHJ1Y3QgYnBmX3FtYXNrIHsKKwlib29sZWFuX3QJcW1fZW5h YmxlZDsKKwlib29sZWFuX3QgKglxbV9yeHFfbWFzazsKKwlib29sZWFuX3QgKglxbV90eHFfbWFz azsKKwlib29sZWFuX3QJcW1fb3RoZXJfbWFzazsKKwlzdHJ1Y3Qgcndsb2NrCXFtX2xvY2s7Cit9 OworCisjZGVmaW5lIEJQRlFfTE9DS19ERVNUUk9ZKHFtKQkJcndfZGVzdHJveSgmKHFtKS0+cW1f bG9jaykKKyNkZWZpbmUgQlBGUV9STE9DSyhxbSkJCQlyd19ybG9jaygmKHFtKS0+cW1fbG9jaykK KyNkZWZpbmUgQlBGUV9SVU5MT0NLKHFtKQkJcndfcnVubG9jaygmKHFtKS0+cW1fbG9jaykKKyNk ZWZpbmUgQlBGUV9XTE9DSyhxbSkJCQlyd193bG9jaygmKHFtKS0+cW1fbG9jaykKKyNkZWZpbmUg QlBGUV9XVU5MT0NLKHFtKQkJcndfd3VubG9jaygmKHFtKS0+cW1fbG9jaykKKwogLyoKICAqIERl c2NyaXB0b3IgYXNzb2NpYXRlZCB3aXRoIGVhY2ggb3BlbiBicGYgZmlsZS4KICAqLwpAQCAtMTAx LDYgKzExNSw3IEBACiAJdV9pbnQ2NF90CWJkX3dkY291bnQ7CS8qIG51bWJlciBvZiBwYWNrZXRz IGRyb3BwZWQgZHVyaW5nIGEgd3JpdGUgKi8KIAl1X2ludDY0X3QJYmRfemNvcHk7CS8qIG51bWJl ciBvZiB6ZXJvIGNvcHkgb3BlcmF0aW9ucyAqLwogCXVfY2hhcgkJYmRfY29tcGF0MzI7CS8qIDMy LWJpdCBzdHJlYW0gb24gTFA2NCBzeXN0ZW0gKi8KKwlzdHJ1Y3QgYnBmX3FtYXNrIGJkX3FtYXNr OwogfTsKIAogLyogVmFsdWVzIGZvciBiZF9zdGF0ZSAqLwpJbmRleDogaWZfdmFyLmgKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gaWZfdmFyLmgJKC4uLi9oZWFkL3N5cy9uZXQvaWZfdmFyLmgpCShyZXZpc2lvbiAy NTI1MDkpCisrKyBpZl92YXIuaAkoLi4uL3VzZXIvc3l1dS9tcV9icGYvc3lzL25ldC9pZl92YXIu aCkJKHJldmlzaW9uIDI1MjUwOSkKQEAgLTE3Niw2ICsxNzYsMTUgQEAKIAkJKHN0cnVjdCBpZm5l dCAqLCBzdHJ1Y3QgbWJ1ZiAqKTsKIAl2b2lkCSgqaWZfcmVhc3NpZ24pCQkvKiByZWFzc2lnbiB0 byB2bmV0IHJvdXRpbmUgKi8KIAkJKHN0cnVjdCBpZm5ldCAqLCBzdHJ1Y3Qgdm5ldCAqLCBjaGFy ICopOworCWludAkoKmlmX2dldF9yeHF1ZXVlX2xlbikKKwkJKHN0cnVjdCBpZm5ldCAqKTsKKwlp bnQJKCppZl9nZXRfdHhxdWV1ZV9sZW4pCisJCShzdHJ1Y3QgaWZuZXQgKik7CisJaW50CSgqaWZf Z2V0X3J4cXVldWVfYWZmaW5pdHkpCisJCShzdHJ1Y3QgaWZuZXQgKiwgaW50KTsKKwlpbnQJKCpp Zl9nZXRfdHhxdWV1ZV9hZmZpbml0eSkKKwkJKHN0cnVjdCBpZm5ldCAqLCBpbnQpOworCiAJc3Ry dWN0CXZuZXQgKmlmX2hvbWVfdm5ldDsJLyogd2hlcmUgdGhpcyBpZm5ldCBvcmlnaW5hdGVzIGZy b20gKi8KIAlzdHJ1Y3QJaWZhZGRyCSppZl9hZGRyOwkvKiBwb2ludGVyIHRvIGxpbmstbGV2ZWwg YWRkcmVzcyAqLwogCXZvaWQJKmlmX2xsc29mdGM7CQkvKiBsaW5rIGxheWVyIHNvZnRjICovCklu ZGV4OiBicGYuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBicGYuaAkoLi4uL2hlYWQvc3lzL25ldC9icGYuaCkJ KHJldmlzaW9uIDI1MjUwOSkKKysrIGJwZi5oCSguLi4vdXNlci9zeXV1L21xX2JwZi9zeXMvbmV0 L2JwZi5oKQkocmV2aXNpb24gMjUyNTA5KQpAQCAtMTQ3LDYgKzE0NywxNyBAQAogI2RlZmluZQlC SU9DU0VURk5SCV9JT1coJ0InLCAxMzAsIHN0cnVjdCBicGZfcHJvZ3JhbSkKICNkZWZpbmUJQklP Q0dUU1RBTVAJX0lPUignQicsIDEzMSwgdV9pbnQpCiAjZGVmaW5lCUJJT0NTVFNUQU1QCV9JT1co J0InLCAxMzIsIHVfaW50KQorI2RlZmluZQlCSU9DRU5BUU1BU0sJX0lPKCdCJywgMTMzKQorI2Rl ZmluZQlCSU9DRElTUU1BU0sJX0lPKCdCJywgMTM0KQorI2RlZmluZQlCSU9DU1RSWFFNQVNLCV9J T1dSKCdCJywgMTM1LCB1aW50MzJfdCkKKyNkZWZpbmUJQklPQ0NSUlhRTUFTSwlfSU9XUignQics IDEzNiwgdWludDMyX3QpCisjZGVmaW5lCUJJT0NHVFJYUU1BU0sJX0lPUignQicsIDEzNywgdWlu dDMyX3QpCisjZGVmaW5lCUJJT0NTVFRYUU1BU0sJX0lPV1IoJ0InLCAxMzgsIHVpbnQzMl90KQor I2RlZmluZQlCSU9DQ1JUWFFNQVNLCV9JT1dSKCdCJywgMTM5LCB1aW50MzJfdCkKKyNkZWZpbmUJ QklPQ0dUVFhRTUFTSwlfSU9SKCdCJywgMTQwLCB1aW50MzJfdCkKKyNkZWZpbmUJQklPQ1NUT1RI RVJNQVNLCV9JTygnQicsIDE0MSkKKyNkZWZpbmUJQklPQ0NST1RIRVJNQVNLCV9JTygnQicsIDE0 MikKKyNkZWZpbmUJQklPQ0dUT1RIRVJNQVNLCV9JT1IoJ0InLCAxNDMsIHVpbnQzMl90KQogCiAv KiBPYnNvbGV0ZSAqLwogI2RlZmluZQlCSU9DR1NFRVNFTlQJQklPQ0dESVJFQ1RJT04KSW5kZXg6 IGlmLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gaWYuYwkoLi4uL2hlYWQvc3lzL25ldC9pZi5jKQkocmV2aXNp b24gMjUyNTA5KQorKysgaWYuYwkoLi4uL3VzZXIvc3l1dS9tcV9icGYvc3lzL25ldC9pZi5jKQko cmV2aXNpb24gMjUyNTA5KQpAQCAtMjQyOCw2ICsyNDI4LDMxIEBACiAJCWJyZWFrOwogCX0KIAor CWNhc2UgU0lPQ0dJRlFMRU46CisJCWlmICghKGlmcC0+aWZfY2FwYWJpbGl0aWVzICYgSUZDQVBf TVVMVElRVUVVRSkpCisJCQlyZXR1cm4gKEVPUE5PVFNVUFApOworCQlLQVNTRVJUKGlmcC0+aWZf Z2V0X3J4cXVldWVfbGVuLCAoImlmX2dldF9yeHF1ZXVlX2xlbiBub3Qgc2V0IikpOworCQlLQVNT RVJUKGlmcC0+aWZfZ2V0X3R4cXVldWVfbGVuLCAoImlmX2dldF90eHF1ZXVlX2xlbiBub3Qgc2V0 IikpOworCQlpZnItPmlmcl9yeHF1ZXVlX2xlbiA9IGlmcC0+aWZfZ2V0X3J4cXVldWVfbGVuKGlm cCk7CisJCWlmci0+aWZyX3R4cXVldWVfbGVuID0gaWZwLT5pZl9nZXRfdHhxdWV1ZV9sZW4oaWZw KTsKKwkJYnJlYWs7CisKKwljYXNlIFNJT0NHSUZSWFFBRkZJTklUWToKKwkJaWYgKCEoaWZwLT5p Zl9jYXBhYmlsaXRpZXMgJiBJRkNBUF9NVUxUSVFVRVVFKSkKKwkJCXJldHVybiAoRU9QTk9UU1VQ UCk7CisJCUtBU1NFUlQoaWZwLT5pZl9nZXRfcnhxdWV1ZV9hZmZpbml0eSwgKCJpZl9nZXRfcnhx dWV1ZV9hZmZpbml0eSBub3Qgc2V0IikpOworCQlpZnItPmlmcl9xdWV1ZV9hZmZpbml0eV9jcHUg PQorCQkJaWZwLT5pZl9nZXRfcnhxdWV1ZV9hZmZpbml0eShpZnAsIGlmci0+aWZyX3F1ZXVlX2Fm ZmluaXR5X2luZGV4KTsKKwkJYnJlYWs7CisKKwljYXNlIFNJT0NHSUZUWFFBRkZJTklUWToKKwkJ aWYgKCEoaWZwLT5pZl9jYXBhYmlsaXRpZXMgJiBJRkNBUF9NVUxUSVFVRVVFKSkKKwkJCXJldHVy biAoRU9QTk9UU1VQUCk7CisJCUtBU1NFUlQoaWZwLT5pZl9nZXRfcnhxdWV1ZV9hZmZpbml0eSwg KCJpZl9nZXRfcnhxdWV1ZV9hZmZpbml0eSBub3Qgc2V0IikpOworCQlpZnItPmlmcl9xdWV1ZV9h ZmZpbml0eV9jcHUgPSAKKwkJCWlmcC0+aWZfZ2V0X3J4cXVldWVfYWZmaW5pdHkoaWZwLCBpZnIt Pmlmcl9xdWV1ZV9hZmZpbml0eV9pbmRleCk7CisJCWJyZWFrOworCiAJZGVmYXVsdDoKIAkJZXJy b3IgPSBFTk9JT0NUTDsKIAkJYnJlYWs7CkluZGV4OiBpZi5oCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGlmLmgJ KC4uLi9oZWFkL3N5cy9uZXQvaWYuaCkJKHJldmlzaW9uIDI1MjUwOSkKKysrIGlmLmgJKC4uLi91 c2VyL3N5dXUvbXFfYnBmL3N5cy9uZXQvaWYuaCkJKHJldmlzaW9uIDI1MjUwOSkKQEAgLTIzMSw2 ICsyMzEsNyBAQAogI2RlZmluZQlJRkNBUF9ORVRNQVAJCTB4MTAwMDAwIC8qIG5ldG1hcCBtb2Rl IHN1cHBvcnRlZC9lbmFibGVkICovCiAjZGVmaW5lCUlGQ0FQX1JYQ1NVTV9JUFY2CTB4MjAwMDAw ICAvKiBjYW4gb2ZmbG9hZCBjaGVja3N1bSBvbiBJUHY2IFJYICovCiAjZGVmaW5lCUlGQ0FQX1RY Q1NVTV9JUFY2CTB4NDAwMDAwICAvKiBjYW4gb2ZmbG9hZCBjaGVja3N1bSBvbiBJUHY2IFRYICov CisjZGVmaW5lCUlGQ0FQX01VTFRJUVVFVUUJMHg4MDAwMDAKIAogI2RlZmluZSBJRkNBUF9IV0NT VU1fSVBWNgkoSUZDQVBfUlhDU1VNX0lQVjYgfCBJRkNBUF9UWENTVU1fSVBWNikKIApAQCAtMzg1 LDYgKzM4Niw4IEBACiAJCWNhZGRyX3QJaWZydV9kYXRhOwogCQlpbnQJaWZydV9jYXBbMl07CiAJ CXVfaW50CWlmcnVfZmliOworCQlpbnQJaWZydV9xdWV1ZV9sZW5bMl07CisJCWludAlpZnJ1X3F1 ZXVlX2FmZmluaXR5WzJdOwogCX0gaWZyX2lmcnU7CiAjZGVmaW5lCWlmcl9hZGRyCWlmcl9pZnJ1 LmlmcnVfYWRkcgkvKiBhZGRyZXNzICovCiAjZGVmaW5lCWlmcl9kc3RhZGRyCWlmcl9pZnJ1Lmlm cnVfZHN0YWRkcgkvKiBvdGhlciBlbmQgb2YgcC10by1wIGxpbmsgKi8KQEAgLTQwMiw2ICs0MDUs MTEgQEAKICNkZWZpbmUJaWZyX2N1cmNhcAlpZnJfaWZydS5pZnJ1X2NhcFsxXQkvKiBjdXJyZW50 IGNhcGFiaWxpdGllcyAqLwogI2RlZmluZQlpZnJfaW5kZXgJaWZyX2lmcnUuaWZydV9pbmRleAkv KiBpbnRlcmZhY2UgaW5kZXggKi8KICNkZWZpbmUJaWZyX2ZpYgkJaWZyX2lmcnUuaWZydV9maWIJ LyogaW50ZXJmYWNlIGZpYiAqLworI2RlZmluZSBpZnJfcnhxdWV1ZV9sZW4JaWZyX2lmcnUuaWZy dV9xdWV1ZV9sZW5bMF0gLyogcnhxdWV1ZSBsZW4gKi8KKyNkZWZpbmUgaWZyX3R4cXVldWVfbGVu CWlmcl9pZnJ1LmlmcnVfcXVldWVfbGVuWzFdIC8qIHR4cXVldWUgbGVuICovCisjZGVmaW5lIGlm cl9xdWV1ZV9hZmZpbml0eV9pbmRleCBpZnJfaWZydS5pZnJ1X3F1ZXVlX2FmZmluaXR5WzBdIC8q IHF1ZXVlIGlkICovCisjZGVmaW5lIGlmcl9xdWV1ZV9hZmZpbml0eV9jcHUgaWZyX2lmcnUuaWZy dV9xdWV1ZV9hZmZpbml0eVsxXSAvKiBjcHUgaWQgKi8KKwogfTsKIAogI2RlZmluZQlfU0laRU9G X0FERFJfSUZSRVEoaWZyKSBcCkluZGV4OiBicGYuYwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBicGYuYwkoLi4u L2hlYWQvc3lzL25ldC9icGYuYykJKHJldmlzaW9uIDI1MjUwOSkKKysrIGJwZi5jCSguLi4vdXNl ci9zeXV1L21xX2JwZi9zeXMvbmV0L2JwZi5jKQkocmV2aXNpb24gMjUyNTA5KQpAQCAtODE5LDYg KzgxOSwxMiBAQAogCXNpemUgPSBkLT5iZF9idWZzaXplOwogCWJwZl9idWZmZXJfaW9jdGxfc2Js ZW4oZCwgJnNpemUpOwogCisgCWQtPmJkX3FtYXNrLnFtX2VuYWJsZWQgPSBGQUxTRTsKKyAJZC0+ YmRfcW1hc2sucW1fcnhxX21hc2sgPSBOVUxMOworIAlkLT5iZF9xbWFzay5xbV90eHFfbWFzayA9 IE5VTEw7CisgCWQtPmJkX3FtYXNrLnFtX290aGVyX21hc2sgPSBGQUxTRTsKKyAJcndfaW5pdCgm ZC0+YmRfcW1hc2sucW1fbG9jaywgInFtYXNrIGxvY2siKTsKKwogCXJldHVybiAoMCk7CiB9CiAK QEAgLTE2OTcsNiArMTcwMywyNjYgQEAKIAljYXNlIEJJT0NST1RaQlVGOgogCQllcnJvciA9IGJw Zl9pb2N0bF9yb3R6YnVmKHRkLCBkLCAoc3RydWN0IGJwZl96YnVmICopYWRkcik7CiAJCWJyZWFr OworCisJY2FzZSBCSU9DRU5BUU1BU0s6CisJCXsKKwkJCXN0cnVjdCBpZm5ldCAqaWZwOworCisJ CQlpZiAoZC0+YmRfYmlmID09IE5VTEwpIHsKKwkJCQkvKgorCQkJCSAqIE5vIGludGVyZmFjZSBh dHRhY2hlZCB5ZXQuCisJCQkJICovCisJCQkJZXJyb3IgPSBFSU5WQUw7CisJCQkJYnJlYWs7CisJ CQl9CisJCQlCUEZRX1dMT0NLKCZkLT5iZF9xbWFzayk7CisJCQlpZiAoZC0+YmRfcW1hc2sucW1f ZW5hYmxlZCkgeworCQkJCUJQRlFfV1VOTE9DSygmZC0+YmRfcW1hc2spOworCQkJCWVycm9yID0g RUlOVkFMOworCQkJCWJyZWFrOworCQkJfQorCQkJaWZwID0gZC0+YmRfYmlmLT5iaWZfaWZwOwor CQkJaWYgKCEoaWZwLT5pZl9jYXBhYmlsaXRpZXMgJiBJRkNBUF9NVUxUSVFVRVVFKSkgeworCQkJ CUJQRlFfV1VOTE9DSygmZC0+YmRfcW1hc2spOworCQkJCWVycm9yID0gRUlOVkFMOworCQkJCWJy ZWFrOworCQkJfQorCQkJS0FTU0VSVChpZnAtPmlmX2dldF9yeHF1ZXVlX2xlbiwgKCJpZnAtPmlm X2dldF9yeHF1ZXVlX2xlbiBub3Qgc2V0XG4iKSk7CisJCQlLQVNTRVJUKGlmcC0+aWZfZ2V0X3R4 cXVldWVfbGVuLCAoImlmcC0+aWZfZ2V0X3J4cXVldWVfbGVuIG5vdCBzZXRcbiIpKTsKKwkJCWQt PmJkX3FtYXNrLnFtX2VuYWJsZWQgPSBUUlVFOworCQkJZC0+YmRfcW1hc2sucW1fcnhxX21hc2sg PQorCQkJCW1hbGxvYyhpZnAtPmlmX2dldF9yeHF1ZXVlX2xlbihpZnApICogc2l6ZW9mKGJvb2xl YW5fdCksIE1fQlBGLCAKKwkJCQkJTV9XQUlUT0sgfCBNX1pFUk8pOworCQkJZC0+YmRfcW1hc2su cW1fdHhxX21hc2sgPQorCQkJCW1hbGxvYyhpZnAtPmlmX2dldF90eHF1ZXVlX2xlbihpZnApICog c2l6ZW9mKGJvb2xlYW5fdCksIE1fQlBGLCAKKwkJCQkJTV9XQUlUT0sgfCBNX1pFUk8pOworCQkJ ZC0+YmRfcW1hc2sucW1fb3RoZXJfbWFzayA9IEZBTFNFOworCQkJQlBGUV9XVU5MT0NLKCZkLT5i ZF9xbWFzayk7CisJCQlicmVhazsKKwkJfQorCisJY2FzZSBCSU9DRElTUU1BU0s6CisJCXsKKwkJ CWlmIChkLT5iZF9iaWYgPT0gTlVMTCkgeworCQkJCS8qCisJCQkJICogTm8gaW50ZXJmYWNlIGF0 dGFjaGVkIHlldC4KKwkJCQkgKi8KKwkJCQllcnJvciA9IEVJTlZBTDsKKwkJCQlicmVhazsKKwkJ CX0KKwkJCUJQRlFfV0xPQ0soJmQtPmJkX3FtYXNrKTsKKwkJCWlmICghZC0+YmRfcW1hc2sucW1f ZW5hYmxlZCkgeworCQkJCUJQRlFfV1VOTE9DSygmZC0+YmRfcW1hc2spOworCQkJCWVycm9yID0g RUlOVkFMOworCQkJCWJyZWFrOworCQkJfQorCQkJZC0+YmRfcW1hc2sucW1fZW5hYmxlZCA9IEZB TFNFOworCQkJCisJCQlmcmVlKGQtPmJkX3FtYXNrLnFtX3J4cV9tYXNrLCBNX0JQRik7CisJCQlm cmVlKGQtPmJkX3FtYXNrLnFtX3R4cV9tYXNrLCBNX0JQRik7CisJCQlCUEZRX1dVTkxPQ0soJmQt PmJkX3FtYXNrKTsKKwkJCWJyZWFrOworCQl9CisKKwljYXNlIEJJT0NTVFJYUU1BU0s6CisJCXsK KwkJCXN0cnVjdCBpZm5ldCAqaWZwOworCQkJaW50IGluZGV4OworCisJCQlpZiAoZC0+YmRfYmlm ID09IE5VTEwpIHsKKwkJCQkvKgorCQkJCSAqIE5vIGludGVyZmFjZSBhdHRhY2hlZCB5ZXQuCisJ CQkJICovCisJCQkJZXJyb3IgPSBFSU5WQUw7CQorCQkJCWJyZWFrOworCQkJfQorCQkJQlBGUV9X TE9DSygmZC0+YmRfcW1hc2spOworCQkJaWYgKCFkLT5iZF9xbWFzay5xbV9lbmFibGVkKSB7CisJ CQkJQlBGUV9XVU5MT0NLKCZkLT5iZF9xbWFzayk7CisJCQkJZXJyb3IgPSBFSU5WQUw7CisJCQkJ YnJlYWs7CisJCQl9CisJCQlpZnAgPSBkLT5iZF9iaWYtPmJpZl9pZnA7CisJCQlpbmRleCA9ICoo dWludDMyX3QgKilhZGRyOworCQkJaWYgKGluZGV4ID4gaWZwLT5pZl9nZXRfcnhxdWV1ZV9sZW4o aWZwKSkgeworCQkJCUJQRlFfV1VOTE9DSygmZC0+YmRfcW1hc2spOworCQkJCWVycm9yID0gRUlO VkFMOworCQkJCWJyZWFrOworCQkJfQorCQkJZC0+YmRfcW1hc2sucW1fcnhxX21hc2tbaW5kZXhd ID0gVFJVRTsKKwkJCUJQRlFfV1VOTE9DSygmZC0+YmRfcW1hc2spOworCQkJYnJlYWs7CisJCX0K KworCWNhc2UgQklPQ0NSUlhRTUFTSzoKKwkJeworCQkJaW50IGluZGV4OworCQkJc3RydWN0IGlm bmV0ICppZnA7CisKKwkJCWlmIChkLT5iZF9iaWYgPT0gTlVMTCkgeworCQkJCS8qCisJCQkJICog Tm8gaW50ZXJmYWNlIGF0dGFjaGVkIHlldC4KKwkJCQkgKi8KKwkJCQllcnJvciA9IEVJTlZBTDsK KwkJCQlicmVhazsKKwkJCX0KKwkJCUJQRlFfV0xPQ0soJmQtPmJkX3FtYXNrKTsKKwkJCWlmICgh ZC0+YmRfcW1hc2sucW1fZW5hYmxlZCkgeworCQkJCUJQRlFfV1VOTE9DSygmZC0+YmRfcW1hc2sp OworCQkJCWVycm9yID0gRUlOVkFMOworCQkJCWJyZWFrOworCQkJfQorCQkJaWZwID0gZC0+YmRf YmlmLT5iaWZfaWZwOworCQkJaW5kZXggPSAqKHVpbnQzMl90ICopYWRkcjsKKwkJCWlmIChpbmRl eCA+IGlmcC0+aWZfZ2V0X3J4cXVldWVfbGVuKGlmcCkpIHsKKwkJCQlCUEZRX1dVTkxPQ0soJmQt PmJkX3FtYXNrKTsKKwkJCQllcnJvciA9IEVJTlZBTDsKKwkJCQlicmVhazsKKwkJCX0KKwkJCWQt PmJkX3FtYXNrLnFtX3J4cV9tYXNrW2luZGV4XSA9IEZBTFNFOworCQkJQlBGUV9XVU5MT0NLKCZk LT5iZF9xbWFzayk7CisJCQlicmVhazsKKwkJfQorCisJY2FzZSBCSU9DR1RSWFFNQVNLOgorCQl7 CisJCQlpbnQgaW5kZXg7CisJCQlzdHJ1Y3QgaWZuZXQgKmlmcDsKKworCQkJaWYgKGQtPmJkX2Jp ZiA9PSBOVUxMKSB7CisJCQkJLyoKKwkJCQkgKiBObyBpbnRlcmZhY2UgYXR0YWNoZWQgeWV0Lgor CQkJCSAqLworCQkJCWVycm9yID0gRUlOVkFMOworCQkJCWJyZWFrOworCQkJfQorCQkJQlBGUV9X TE9DSygmZC0+YmRfcW1hc2spOworCQkJaWYgKCFkLT5iZF9xbWFzay5xbV9lbmFibGVkKSB7CisJ CQkJQlBGUV9XVU5MT0NLKCZkLT5iZF9xbWFzayk7CisJCQkJZXJyb3IgPSBFSU5WQUw7CisJCQkJ YnJlYWs7CisJCQl9CisJCQlpZnAgPSBkLT5iZF9iaWYtPmJpZl9pZnA7CisJCQlpbmRleCA9ICoo dWludDMyX3QgKilhZGRyOworCQkJaWYgKGluZGV4ID4gaWZwLT5pZl9nZXRfcnhxdWV1ZV9sZW4o aWZwKSkgeworCQkJCUJQRlFfV1VOTE9DSygmZC0+YmRfcW1hc2spOworCQkJCWVycm9yID0gRUlO VkFMOworCQkJCWJyZWFrOworCQkJfQorCQkJKih1aW50MzJfdCAqKWFkZHIgPSBkLT5iZF9xbWFz ay5xbV9yeHFfbWFza1tpbmRleF07CisJCQlCUEZRX1dVTkxPQ0soJmQtPmJkX3FtYXNrKTsKKwkJ CWJyZWFrOworCQl9CisKKwljYXNlIEJJT0NTVFRYUU1BU0s6CisJCXsKKwkJCXN0cnVjdCBpZm5l dCAqaWZwOworCQkJaW50IGluZGV4OworCisJCQlpZiAoZC0+YmRfYmlmID09IE5VTEwpIHsKKwkJ CQkvKgorCQkJCSAqIE5vIGludGVyZmFjZSBhdHRhY2hlZCB5ZXQuCisJCQkJICovCisJCQkJZXJy b3IgPSBFSU5WQUw7CisJCQkJYnJlYWs7CisJCQl9CisJCQlCUEZRX1dMT0NLKCZkLT5iZF9xbWFz ayk7CisJCQlpZiAoIWQtPmJkX3FtYXNrLnFtX2VuYWJsZWQpIHsKKwkJCQlCUEZRX1dVTkxPQ0so JmQtPmJkX3FtYXNrKTsKKwkJCQllcnJvciA9IEVJTlZBTDsKKwkJCQlicmVhazsKKwkJCX0KKwor CQkJaWZwID0gZC0+YmRfYmlmLT5iaWZfaWZwOworCQkJaW5kZXggPSAqKHVpbnQzMl90ICopYWRk cjsKKwkJCWlmIChpbmRleCA+IGlmcC0+aWZfZ2V0X3R4cXVldWVfbGVuKGlmcCkpIHsKKwkJCQlC UEZRX1dVTkxPQ0soJmQtPmJkX3FtYXNrKTsKKwkJCQllcnJvciA9IEVJTlZBTDsKKwkJCQlicmVh azsKKwkJCX0KKwkJCWQtPmJkX3FtYXNrLnFtX3R4cV9tYXNrW2luZGV4XSA9IFRSVUU7CisJCQlC UEZRX1dVTkxPQ0soJmQtPmJkX3FtYXNrKTsKKwkJCWJyZWFrOworCQl9CisKKwljYXNlIEJJT0ND UlRYUU1BU0s6CisJCXsKKwkJCXN0cnVjdCBpZm5ldCAqaWZwOworCQkJaW50IGluZGV4OworCisJ CQlpZiAoZC0+YmRfYmlmID09IE5VTEwpIHsKKwkJCQkvKgorCQkJCSAqIE5vIGludGVyZmFjZSBh dHRhY2hlZCB5ZXQuCisJCQkJICovCisJCQkJZXJyb3IgPSBFSU5WQUw7CisJCQkJYnJlYWs7CisJ CQl9CisJCQlCUEZRX1dMT0NLKCZkLT5iZF9xbWFzayk7CisJCQlpZiAoIWQtPmJkX3FtYXNrLnFt X2VuYWJsZWQpIHsKKwkJCQlCUEZRX1dVTkxPQ0soJmQtPmJkX3FtYXNrKTsKKwkJCQllcnJvciA9 IEVJTlZBTDsKKwkJCQlicmVhazsKKwkJCX0KKworCQkJaWZwID0gZC0+YmRfYmlmLT5iaWZfaWZw OworCQkJaW5kZXggPSAqKHVpbnQzMl90ICopYWRkcjsKKwkJCWlmIChpbmRleCA+IGlmcC0+aWZf Z2V0X3R4cXVldWVfbGVuKGlmcCkpIHsKKwkJCQlCUEZRX1dVTkxPQ0soJmQtPmJkX3FtYXNrKTsK KwkJCQllcnJvciA9IEVJTlZBTDsKKwkJCQlicmVhazsKKwkJCX0KKwkJCWQtPmJkX3FtYXNrLnFt X3R4cV9tYXNrW2luZGV4XSA9IEZBTFNFOworCQkJQlBGUV9XVU5MT0NLKCZkLT5iZF9xbWFzayk7 CisJCQlicmVhazsKKwkJfQorCisJY2FzZSBCSU9DR1RUWFFNQVNLOgorCQl7CisJCQlpbnQgaW5k ZXg7CisJCQlzdHJ1Y3QgaWZuZXQgKmlmcDsKKworCQkJaWYgKGQtPmJkX2JpZiA9PSBOVUxMKSB7 CisJCQkJLyoKKwkJCQkgKiBObyBpbnRlcmZhY2UgYXR0YWNoZWQgeWV0LgorCQkJCSAqLworCQkJ CWVycm9yID0gRUlOVkFMOworCQkJCWJyZWFrOworCQkJfQorCQkJQlBGUV9XTE9DSygmZC0+YmRf cW1hc2spOworCQkJaWYgKCFkLT5iZF9xbWFzay5xbV9lbmFibGVkKSB7CisJCQkJQlBGUV9XVU5M T0NLKCZkLT5iZF9xbWFzayk7CisJCQkJZXJyb3IgPSBFSU5WQUw7CisJCQkJYnJlYWs7CisJCQl9 CisJCQlpZnAgPSBkLT5iZF9iaWYtPmJpZl9pZnA7CisJCQlpbmRleCA9ICoodWludDMyX3QgKilh ZGRyOworCQkJaWYgKGluZGV4ID4gaWZwLT5pZl9nZXRfdHhxdWV1ZV9sZW4oaWZwKSkgeworCQkJ CUJQRlFfV1VOTE9DSygmZC0+YmRfcW1hc2spOworCQkJCWVycm9yID0gRUlOVkFMOworCQkJCWJy ZWFrOworCQkJfQorCQkJKih1aW50MzJfdCAqKWFkZHIgPSBkLT5iZF9xbWFzay5xbV90eHFfbWFz a1tpbmRleF07CisJCQlCUEZRX1dVTkxPQ0soJmQtPmJkX3FtYXNrKTsKKwkJCWJyZWFrOworCQl9 CisKKwljYXNlIEJJT0NTVE9USEVSTUFTSzoKKwkJQlBGUV9XTE9DSygmZC0+YmRfcW1hc2spOwor CQlkLT5iZF9xbWFzay5xbV9vdGhlcl9tYXNrID0gVFJVRTsKKwkJQlBGUV9XVU5MT0NLKCZkLT5i ZF9xbWFzayk7CisJCWJyZWFrOworCisJY2FzZSBCSU9DQ1JPVEhFUk1BU0s6CisJCUJQRlFfV0xP Q0soJmQtPmJkX3FtYXNrKTsKKwkJZC0+YmRfcW1hc2sucW1fb3RoZXJfbWFzayA9IEZBTFNFOwor CQlCUEZRX1dVTkxPQ0soJmQtPmJkX3FtYXNrKTsKKwkJYnJlYWs7CisKKwljYXNlIEJJT0NHVE9U SEVSTUFTSzoKKwkJQlBGUV9XTE9DSygmZC0+YmRfcW1hc2spOworCQkqKHVpbnQzMl90ICopYWRk ciA9ICh1aW50MzJfdClkLT5iZF9xbWFzay5xbV9vdGhlcl9tYXNrOworCQlCUEZRX1dVTkxPQ0so JmQtPmJkX3FtYXNrKTsKKwkJYnJlYWs7CiAJfQogCUNVUlZORVRfUkVTVE9SRSgpOwogCXJldHVy biAoZXJyb3IpOwpAQCAtMjA1MCw2ICsyMzE2LDE0IEBACiAJCSAqIDIpIGRlc3Ryb3lpbmcvZGV0 YWNoaW5nIGQgaXMgcHJvdGVjdGVkIGJ5IGludGVyZmFjZQogCQkgKiB3cml0ZSBsb2NrLCB0b28K IAkJICovCisgCQlCUEZRX1JMT0NLKCZkLT5iZF9xbWFzayk7CisgCQlpZiAoZC0+YmRfcW1hc2su cW1fZW5hYmxlZCkgeworIAkJCWlmICghZC0+YmRfcW1hc2sucW1fb3RoZXJfbWFzaykgeworCQkJ CUJQRlFfUlVOTE9DSygmZC0+YmRfcW1hc2spOworIAkJCQljb250aW51ZTsKKyAJCQl9CisgCQl9 CisJCUJQRlFfUlVOTE9DSygmZC0+YmRfcW1hc2spOwogCiAJCS8qIFhYWDogRG8gbm90IHByb3Rl Y3QgY291bnRlciBmb3IgdGhlIHNha2Ugb2YgcGVyZm9ybWFuY2UuICovCiAJCSsrZC0+YmRfcmNv dW50OwpAQCAtMjExNyw2ICsyMzkxLDQyIEBACiAJQlBGSUZfUkxPQ0soYnApOwogCiAJTElTVF9G T1JFQUNIKGQsICZicC0+YmlmX2RsaXN0LCBiZF9uZXh0KSB7CisgCQlCUEZRX1JMT0NLKCZkLT5i ZF9xbWFzayk7CisgCQlpZiAoZC0+YmRfcW1hc2sucW1fZW5hYmxlZCkgeworIAkJCU1fQVNTRVJU UEtUSERSKG0pOworIAkJCWlmICghKG0tPm1fZmxhZ3MgJiBNX0ZMT1dJRCkpIHsKKyAJCQkJaWYg KCFkLT5iZF9xbWFzay5xbV9vdGhlcl9tYXNrKSB7CisgCQkJCQlCUEZRX1JVTkxPQ0soJmQtPmJk X3FtYXNrKTsKKyAJCQkJCWNvbnRpbnVlOworIAkJCQl9CisgCQkJfSBlbHNlIHsKKyAJCQkJc3Ry dWN0IGlmbmV0ICppZnAgPSBicC0+YmlmX2lmcDsKKyAJCQkJaWYgKG0tPm1fcGt0aGRyLnJ4cXVl dWUgIT0gKHVpbnQzMl90KS0xKSB7CisgCQkJCQlpZiAobS0+bV9wa3RoZHIucnhxdWV1ZSA+PSBp ZnAtPmlmX2dldF9yeHF1ZXVlX2xlbihpZnApKSB7CisgCQkJCQkJQlBGUV9SVU5MT0NLKCZkLT5i ZF9xbWFzayk7CisgCQkJCQkJQlBGSUZfUlVOTE9DSyhicCk7CisgCQkJCQkJcmV0dXJuOworCQkJ CQl9CisgCQkJCQlpZiAoIWQtPmJkX3FtYXNrLnFtX3J4cV9tYXNrW20tPm1fcGt0aGRyLnJ4cXVl dWVdKSB7CisgCQkJCQkJQlBGUV9SVU5MT0NLKCZkLT5iZF9xbWFzayk7CisgCQkJCQkJY29udGlu dWU7CisgCQkJCQl9CisgCQkJCX0KKyAJCQkJaWYgKG0tPm1fcGt0aGRyLnR4cXVldWUgIT0gKHVp bnQzMl90KS0xKSB7CisgCQkJCQlpZiAobS0+bV9wa3RoZHIudHhxdWV1ZSA+PSBpZnAtPmlmX2dl dF90eHF1ZXVlX2xlbihpZnApKSB7CisgCQkJCQkJQlBGUV9SVU5MT0NLKCZkLT5iZF9xbWFzayk7 CisgCQkJCQkJQlBGSUZfUlVOTE9DSyhicCk7CisgCQkJCQkJcmV0dXJuOworIAkJCQkJfQorIAkJ CQkJaWYgKCFkLT5iZF9xbWFzay5xbV90eHFfbWFza1ttLT5tX3BrdGhkci50eHF1ZXVlXSkgewor IAkJCQkJCUJQRlFfUlVOTE9DSygmZC0+YmRfcW1hc2spOworIAkJCQkJCWNvbnRpbnVlOworIAkJ CQkJfQorIAkJCQl9CisgCQkJfQorIAkJfQorIAkJQlBGUV9SVU5MT0NLKCZkLT5iZF9xbWFzayk7 CisgCiAJCWlmIChCUEZfQ0hFQ0tfRElSRUNUSU9OKGQsIG0tPm1fcGt0aGRyLnJjdmlmLCBicC0+ YmlmX2lmcCkpCiAJCQljb250aW51ZTsKIAkJKytkLT5iZF9yY291bnQ7CkBAIC0yMTgwLDYgKzI0 OTAsNDIgQEAKIAlCUEZJRl9STE9DSyhicCk7CiAKIAlMSVNUX0ZPUkVBQ0goZCwgJmJwLT5iaWZf ZGxpc3QsIGJkX25leHQpIHsKKyAJCUJQRlFfUkxPQ0soJmQtPmJkX3FtYXNrKTsKKyAJCWlmIChk LT5iZF9xbWFzay5xbV9lbmFibGVkKSB7CisgCQkJTV9BU1NFUlRQS1RIRFIobSk7CisgCQkJaWYg KCEobS0+bV9mbGFncyAmIE1fRkxPV0lEKSkgeworIAkJCQlpZiAoIWQtPmJkX3FtYXNrLnFtX290 aGVyX21hc2spIHsKKyAJCQkJCUJQRlFfUlVOTE9DSygmZC0+YmRfcW1hc2spOworIAkJCQkJY29u dGludWU7CisgCQkJCX0KKyAJCQl9IGVsc2UgeworIAkJCQlzdHJ1Y3QgaWZuZXQgKmlmcCA9IGJw LT5iaWZfaWZwOworIAkJCQlpZiAobS0+bV9wa3RoZHIucnhxdWV1ZSAhPSAodWludDMyX3QpLTEp IHsKKyAJCQkJCWlmIChtLT5tX3BrdGhkci5yeHF1ZXVlID49IGlmcC0+aWZfZ2V0X3J4cXVldWVf bGVuKGlmcCkpIHsKKyAJCQkJCQlCUEZRX1JVTkxPQ0soJmQtPmJkX3FtYXNrKTsKKyAJCQkJCQlC UEZJRl9SVU5MT0NLKGJwKTsKKyAJCQkJCQlyZXR1cm47CisgCQkJCQl9CisgCQkJCQlpZiAoIWQt PmJkX3FtYXNrLnFtX3J4cV9tYXNrW20tPm1fcGt0aGRyLnJ4cXVldWVdKSB7CisgCQkJCQkJQlBG UV9SVU5MT0NLKCZkLT5iZF9xbWFzayk7CisgCQkJCQkJY29udGludWU7CisgCQkJCQl9CisgCQkJ CX0KKyAJCQkJaWYgKG0tPm1fcGt0aGRyLnR4cXVldWUgIT0gKHVpbnQzMl90KS0xKSB7CisgCQkJ CQlpZiAobS0+bV9wa3RoZHIudHhxdWV1ZSA+PSBpZnAtPmlmX2dldF90eHF1ZXVlX2xlbihpZnAp KSB7CisgCQkJCQkJQlBGUV9SVU5MT0NLKCZkLT5iZF9xbWFzayk7CisgCQkJCQkJQlBGSUZfUlVO TE9DSyhicCk7CisgCQkJCQkJcmV0dXJuOworIAkJCQkJfQorIAkJCQkJaWYgKCFkLT5iZF9xbWFz ay5xbV90eHFfbWFza1ttLT5tX3BrdGhkci50eHF1ZXVlXSkgeworIAkJCQkJCUJQRlFfUlVOTE9D SygmZC0+YmRfcW1hc2spOworIAkJCQkJCWNvbnRpbnVlOworIAkJCQkJfQorIAkJCQl9CisgCQkJ fQorIAkJfQorIAkJQlBGUV9SVU5MT0NLKCZkLT5iZF9xbWFzayk7CisgCiAJCWlmIChCUEZfQ0hF Q0tfRElSRUNUSU9OKGQsIG0tPm1fcGt0aGRyLnJjdmlmLCBicC0+YmlmX2lmcCkpCiAJCQljb250 aW51ZTsKIAkJKytkLT5iZF9yY291bnQ7CkBAIC0yNDQzLDYgKzI3ODksMTIgQEAKIAl9CiAJaWYg KGQtPmJkX3dmaWx0ZXIgIT0gTlVMTCkKIAkJZnJlZSgoY2FkZHJfdClkLT5iZF93ZmlsdGVyLCBN X0JQRik7CisgCisgCWlmIChkLT5iZF9xbWFzay5xbV9lbmFibGVkKSB7CisgCQlmcmVlKGQtPmJk X3FtYXNrLnFtX3J4cV9tYXNrLCBNX0JQRik7CisgCQlmcmVlKGQtPmJkX3FtYXNrLnFtX3R4cV9t YXNrLCBNX0JQRik7CisgCX0KKyAKIAltdHhfZGVzdHJveSgmZC0+YmRfbG9jayk7CiB9CiAKSW5k ZXg6IHNvY2tpby5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNvY2tpby5oCSguLi4vaGVhZC9zeXMvc3lzL3Nv Y2tpby5oKQkocmV2aXNpb24gMjUyNTA5KQorKysgc29ja2lvLmgJKC4uLi91c2VyL3N5dXUvbXFf YnBmL3N5cy9zeXMvc29ja2lvLmgpCShyZXZpc2lvbiAyNTI1MDkpCkBAIC04Miw2ICs4MiwxMCBA QAogI2RlZmluZQlTSU9DR0lGREVTQ1IJX0lPV1IoJ2knLCA0Miwgc3RydWN0IGlmcmVxKQkvKiBn ZXQgaWZuZXQgZGVzY3IgKi8gCiAjZGVmaW5lCVNJT0NBSUZBRERSCSBfSU9XKCdpJywgNDMsIHN0 cnVjdCBpZmFsaWFzcmVxKS8qIGFkZC9jaGcgSUYgYWxpYXMgKi8KIAorI2RlZmluZQlTSU9DR0lG UUxFTiAJX0lPV1IoJ2knLCA0NSwgc3RydWN0IGlmcmVxKQkvKiBnZXQgSUYgcXVldWUgbGVuICov CisjZGVmaW5lCVNJT0NHSUZSWFFBRkZJTklUWSBfSU9XUignaScsIDQ2LCBzdHJ1Y3QgaWZyZXEp CS8qIGdldCBJRiByeCBxdWV1ZSBhZmZpbml0eSAqLworI2RlZmluZQlTSU9DR0lGVFhRQUZGSU5J VFkgX0lPV1IoJ2knLCA0Nywgc3RydWN0IGlmcmVxKQkvKiBnZXQgSUYgdHggcXVldWUgYWZmaW5p dHkgKi8KKwogI2RlZmluZQlTSU9DQURETVVMVEkJIF9JT1coJ2knLCA0OSwgc3RydWN0IGlmcmVx KQkvKiBhZGQgbSdjYXN0IGFkZHIgKi8KICNkZWZpbmUJU0lPQ0RFTE1VTFRJCSBfSU9XKCdpJywg NTAsIHN0cnVjdCBpZnJlcSkJLyogZGVsIG0nY2FzdCBhZGRyICovCiAjZGVmaW5lCVNJT0NHSUZN VFUJX0lPV1IoJ2knLCA1MSwgc3RydWN0IGlmcmVxKQkvKiBnZXQgSUYgbXR1ICovCkluZGV4OiBt YnVmLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gbWJ1Zi5oCSguLi4vaGVhZC9zeXMvc3lzL21idWYuaCkJKHJl dmlzaW9uIDI1MjUwOSkKKysrIG1idWYuaAkoLi4uL3VzZXIvc3l1dS9tcV9icGYvc3lzL3N5cy9t YnVmLmgpCShyZXZpc2lvbiAyNTI1MDkpCkBAIC0xMjEsNiArMTIxLDggQEAKIAl1aW50MzJfdAkg Zmxvd2lkOwkvKiBwYWNrZXQncyA0LXR1cGxlIHN5c3RlbQogCQkJCQkgKiBmbG93IGlkZW50aWZp ZXIKIAkJCQkJICovCisJdWludDMyX3QJcnhxdWV1ZTsKKwl1aW50MzJfdAl0eHF1ZXVlOwogCS8q IHZhcmlhYmxlcyBmb3IgaGFyZHdhcmUgY2hlY2tzdW0gKi8KIAlpbnQJCSBjc3VtX2ZsYWdzOwkv KiBmbGFncyByZWdhcmRpbmcgY2hlY2tzdW0gKi8KIAlpbnQJCSBjc3VtX2RhdGE7CS8qIGRhdGEg ZmllbGQgdXNlZCBieSBjc3VtIHJvdXRpbmVzICovCg== --bcaec518248ea5c9a804e089646d-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 2 20:30:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A4C409F0 for ; Tue, 2 Jul 2013 20:30:46 +0000 (UTC) (envelope-from ncardwell@google.com) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id 388E613BD for ; Tue, 2 Jul 2013 20:30:46 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id c50so2979710eek.39 for ; Tue, 02 Jul 2013 13:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=VxrBKrI+6HtCUZ76Va1o2sPsM+yCeq4PYHHj/xsYumo=; b=Yy6afIvsCzk1oZ7RIwe+mIY63V3U5hQtTSI5ct6u1vDnuTp6DdOkAodZIRimHUVHcT pJm7CX/4ujKjLU2fbc3MfxNruh+rI0kOYnPvp2nvyxax08yEvcmiPvMI8IDOaax3Nwgw fAXttXM9UKh2zR8ZxeG7J+D1r98KTECXGz0fT0NVUjUGKOgLBcmrKHvUMRoebKnQ+1Pp SebbNL50iPhkX7CmrZNwRN4TgzuuZq9qMzb5KoPC7qZTOQlJKkIlrSCxYxX5UATLIRm1 wq+bkQTyTWljI3RDr5CE+8g2/tWO7f/HsAaBjNM8Y4ttbU+yKJnsZk81f8P/fg4RXHXR Jv6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=VxrBKrI+6HtCUZ76Va1o2sPsM+yCeq4PYHHj/xsYumo=; b=B+pO6QDjV4+nFwbG28EKskv7z2kCrItb3Fh+uXQId4alXZoYvEb4m+nnD0TF0yGah7 9q9jo8GE1f/QEn3a09EGlL9V56Xh1GyTrlpqzjARuJtgNpflqKXVzaNNoTg7WFESAguf rQA6gQiKCLX78IjYTbY4J1P/LPiXGBZmxHE1nb0hERWGSTh0MYxQn3lOp0z+Fo4PswDT cwTTCthKyDNT++q2tvxf9M6X/OQ+e0RXC5ZkjPoDbt29gZG2eWmWLBX0ugiiavuA4QmK bnSzll+EXurLq6EFYcSbZIDX0AScBNSPRrj3AAoaFp36ObtJQgVhm7Xf1cuKLcjrNE3+ x6Cg== MIME-Version: 1.0 X-Received: by 10.15.82.132 with SMTP id a4mr28011274eez.107.1372797045204; Tue, 02 Jul 2013 13:30:45 -0700 (PDT) Received: by 10.14.140.71 with HTTP; Tue, 2 Jul 2013 13:30:45 -0700 (PDT) Date: Tue, 2 Jul 2013 13:30:45 -0700 Message-ID: Subject: packetdrill: a scriptable network stack testing tool (for FreeBSD, etc.) From: Neal Cardwell To: freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlcQO3BsXRHi6PLXEhDcsQjKtNyrfQukKZzEJS7eYOuXqF6Slj87ooSNF5GQqMHRSMuZYUh5DClE11bz947S5/L8NgacV0ROEgEhziSu+0/dk3lq4ghnJmTFB3GvXYFhzfcsqVvTQk7mIQtaQvY+jinwSZ86aR2oXA2BfMRBtH9jFfsGHyfsr7CENLksqUl/xKJjB61G71x61/193l481wBk3LWrA== X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Jul 2013 20:30:46 -0000 I'd like to announce the availability of the packetdrill network stack testing tool. The packetdrill scripting tool enables users to quickly write precise tests for entire TCP/UDP/IPv4/IPv6 network stacks, from the system call layer down to the NIC hardware. packetdrill currently works on Linux, FreeBSD, OpenBSD, and NetBSD. It can test network stack behavior over physical NICs on a LAN, or on a single machine using a tun virtual network device. The code is licensed under version 2 of the GPL, and available in a git repository at: https://code.google.com/p/packetdrill/ Here's a USENIX 2013 paper about the tool: http://research.google.com/pubs/pub41316.html This paper describes the design and implementation of the tool, and our experiences using it to execute 657 test cases. The tool was instrumental in our development of three new features for Linux TCP=97Early Retransmit, Fast Open, and Loss Probes=97and allowed us to find and fix 10 bugs in Linux. Our team uses packetdrill in all phases of the development process. Currently the source for the testing tool is in the git repository, along with an example script for each supported OS. We will also be posting tests from our team's Linux TCP test suite (described in the paper), as time permits. There is a mailing list for questions, discussions and patches: http://groups.google.com/group/packetdrill Enjoy! neal From owner-freebsd-net@FreeBSD.ORG Tue Jul 2 21:15:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5CCB0600 for ; Tue, 2 Jul 2013 21:15:56 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by mx1.freebsd.org (Postfix) with ESMTP id BF54D175D for ; Tue, 2 Jul 2013 21:15:55 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id t13so3821882lbd.15 for ; Tue, 02 Jul 2013 14:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rO8IOQfm+5fYF4pfVHUZhKSf6/3nDEKXpUITxYc57ok=; b=HJxO8MCsZTdl3qa9xfCGykiFa++lVAlkYqRChOcqNqA/8k53kzq4nnRnM5hfQiwNbK 9DP1WT1WbwDKz18Rzo7oNG1YpP3kC6f0UFZe5AwNiwvsalZp0RUtSTKn+v332dbMxXVH 9ReBiY1ctf5+JHRFBo+TQgzbTyksKoIkqHHwxfW6ikuzF8vSi7KQkKQbZbBP5qSsRQml 9q/Lw+/32Z2n3uOeogaZUyHgeR/ccR7KCYXq3CCrp6BGZz/V/C6brS7d6g9AwzhqpzjK rEca7aJjaW1+ch99ygLt1eq1EYfPb0aMm7ZPzoC1m5VEtOPpigCxVpQoO4VK1HtmgXKh RW6g== MIME-Version: 1.0 X-Received: by 10.112.156.42 with SMTP id wb10mr14821709lbb.62.1372799754532; Tue, 02 Jul 2013 14:15:54 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.15 with HTTP; Tue, 2 Jul 2013 14:15:54 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Jul 2013 23:15:54 +0200 X-Google-Sender-Auth: a9OytJFYPwGh1t9rd6WP0wtuXd8 Message-ID: Subject: Re: Multiqueue support for bpf From: Luigi Rizzo To: Takuya ASADA Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Jul 2013 21:15:56 -0000 On Tue, Jul 2, 2013 at 5:56 PM, Takuya ASADA wrote: > Hi, > > Do you have an updated URL for the diffs ? The link below from your >> original message >> seems not working now (NXDOMAIN) >> >> http://www.dokukino.com/mq_bpf_20110813.diff >> > > Changes with recent head is on my repository: > http://svnweb.freebsd.org/base/user/syuu/mq_bpf/ > And I attached a diff file on this mail. > > thanks for the diffs (the URL to the repo is useful too, but a URL to generate diffs is more convenient for reviewing changes). I believe it still needs a bit of work before being merged. My comments (in order of the patch): === ifnet.9 (and related code in if.c, sockio.h) === - if_get_rxqueue_len()/if_get_rxqueue_len() is not a good name, as to me at least it suggests that it returns the size of the individual queue, rather than the number of queues. - cpu affinity (in userspace) is a bitmask, whereas in the BSD kernel we almost never use the term "affinity", and favour "couid" or "oncpu" (i.e. an individual CPU id). I think you should either rename if_get_txqueue_affinity(), or make the return type a cpuset (which seems more sensible as the return value is passed to userspace) === bpf.4 (and related code) === - the ioctl() to attach/detach/report queues attached to a specific bpf descriptor talk about "mask bit" but neither the internal nor the external implementation deal with bits. I'd rather document those ioctl as "attaching queue to file descriptor". - the BPF ioctl names are generally inconsistent (using either S or SET and G or GET for the setter and getter methods). But you should pick one of the patterns and stick with it, not introduce a third variant (GT/ST). Given we are in 2013 we might go for the long form GET and SET so i suggest the following (spaces for clarity) +#define BIOC ENA QMASK _IO('B', 133) +#define BIOC DIS QMASK _IO('B', 134) +#define BIOC SET RXQMASK _IOWR('B', 135, uint32_t) +#define BIOC CLR RXQMASK _IOWR('B', 136, uint32_t) +#define BIOC GET RXQMASK _IOR('B', 137, uint32_t) +#define BIOC SET TXQMASK _IOWR('B', 138, uint32_t) +#define BIOC CLR TXQMASK _IOWR('B', 139, uint32_t) +#define BIOC GET TXQMASK _IOR('B', 140, uint32_t) +#define BIOC SET OTHERMASK _IO('B', 141) +#define BIOC CLR OTHERMASK _IO('B', 142) +#define BIOC GET OTHERMASK _IOR('B', 143, uint32_t) Also related: the existing ioctls() use u_int as argumnts, rather than uint32_t. I personally prefer the uint32_t form, but you should at least add a comment to indicate that the choice is deliberate. === if.c === - you have a KASSERT to report if ifp->if_get_*xqueue_affinity() is not set, but i'd rather run the function only if is set, so you can have a multiqueue interface which does not bind queues to specific cores (which i am not sure is always a great idea; too many processes statically bound to the same queue mean you lose opportunity to parallelize work.) === mbuf.h === as mentioned earlier, the modification to struct mbuf should be avoided if possible at all. It seems that you need just one direction bit (which maybe is available already from the context) and one queue identifier, which in the rx path, at least in your implementation is always a replica of the 'flowid' field. Can you see if perhaps the flowid field can be (ab)used on the tx path as well ? === if.h === - in if.h, can you use individual variables instead of arrays for ifr_queue_affinity_index and friends ? The macros to map the fields of ifr_ifru one level up are a necessary evil, but there is no point in using the arrays. - SIOCGIFTXQAFFINITY seems to use the receive function (copy&paste typo) talks about Also, this function is probably something that should be coordinated with work on generic multiqueue support === bpf.c === - in linux (and hopefully in FreeBSD at some point) the number of queues can be changed at runtime. So i suggest that you cache the current number of queues when you allocate the arrays (qm_*xq_qmask[] ) rather than invoking ifp->if_get_*xqueue_len() everytime you need to do a boundary check. This will save us from all sort of problems later. - in terms of code, the six BIOC*XQMASK are very similar, you are probably better off having one single case in the switch - can you some comments in the code for the chunk at @@ -2117,6 +2391,42 @@ I do not completely understand why you are returning if the *queue tag in the mbuf is out of range (my impression is that you should just continue, or if you think the packet is incorrect it should be filtered out before entering the LIST_FOREACH() ). Secondly, you should use the cached value of *queue_len cheers luigi -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 00:52:41 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 604B0317; Wed, 3 Jul 2013 00:52:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 390E01E97; Wed, 3 Jul 2013 00:52:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r630qfCR066966; Wed, 3 Jul 2013 00:52:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r630qeCJ066965; Wed, 3 Jul 2013 00:52:40 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 00:52:40 GMT Message-Id: <201307030052.r630qeCJ066965@freefall.freebsd.org> To: roart@nvg.ntnu.no, linimon@FreeBSD.org, davidch@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/100858: [bce] Broadcom bce driver and SMP hangup X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 00:52:41 -0000 Synopsis: [bce] Broadcom bce driver and SMP hangup State-Changed-From-To: feedback->closed State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: Feedback timeout. Responsible-Changed-From-To: davidch->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: commit bit has been taken in for safekeeping. http://www.freebsd.org/cgi/query-pr.cgi?pr=100858 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 00:53:53 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6699B40A; Wed, 3 Jul 2013 00:53:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3E7A71EAF; Wed, 3 Jul 2013 00:53:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r630rr72067057; Wed, 3 Jul 2013 00:53:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r630rqWo067056; Wed, 3 Jul 2013 00:53:52 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 00:53:52 GMT Message-Id: <201307030053.r630rqWo067056@freefall.freebsd.org> To: freebsd@spatula.net, linimon@FreeBSD.org, jinmei@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/108197: [panic] [gif] [ip6] if_delmulti reference counting panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 00:53:53 -0000 Synopsis: [panic] [gif] [ip6] if_delmulti reference counting panic State-Changed-From-To: feedback->feedback State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. to submitter: is this aging PR still relevant? Responsible-Changed-From-To: jinmei->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=108197 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:02:38 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B13CEBC9; Wed, 3 Jul 2013 01:02:38 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8C1D31F86; Wed, 3 Jul 2013 01:02:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6312cOC069886; Wed, 3 Jul 2013 01:02:38 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6312bUZ069885; Wed, 3 Jul 2013 01:02:37 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:02:37 GMT Message-Id: <201307030102.r6312bUZ069885@freefall.freebsd.org> To: jguyett@andrew.cmu.edu, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/17109: [ipfilter] fastroute crashes for lo0 udp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:02:38 -0000 Old Synopsis: fastroute crashes for lo0 udp New Synopsis: [ipfilter] fastroute crashes for lo0 udp State-Changed-From-To: suspended->suspended State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=17109 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:03:48 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 10D25CBC; Wed, 3 Jul 2013 01:03:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DE51A1FA2; Wed, 3 Jul 2013 01:03:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6313lm4069983; Wed, 3 Jul 2013 01:03:47 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6313lM1069981; Wed, 3 Jul 2013 01:03:47 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:03:47 GMT Message-Id: <201307030103.r6313lM1069981@freefall.freebsd.org> To: vampiro@rusunix.org, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: conf/46913: [ipfilter] denied packets of security run output contains nonmatched rules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:03:48 -0000 Synopsis: [ipfilter] denied packets of security run output contains nonmatched rules State-Changed-From-To: suspended->suspended State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=46913 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:04:21 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 035F7D62; Wed, 3 Jul 2013 01:04:21 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id D13FB1FB3; Wed, 3 Jul 2013 01:04:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6314KFv070028; Wed, 3 Jul 2013 01:04:20 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6314JCI070027; Wed, 3 Jul 2013 01:04:19 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:04:19 GMT Message-Id: <201307030104.r6314JCI070027@freefall.freebsd.org> To: alexd@vinf.ru, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/48741: [ipfilter] ipnat corrupts packets on gre interface with rules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:04:21 -0000 Old Synopsis: ipnat corrupts packets on gre interface with rules New Synopsis: [ipfilter] ipnat corrupts packets on gre interface with rules State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. To submitter: is this aging PR still a problem? Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=48741 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:05:09 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 23122E03; Wed, 3 Jul 2013 01:05:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id F18171FC5; Wed, 3 Jul 2013 01:05:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r631586M070178; Wed, 3 Jul 2013 01:05:08 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r631553F070169; Wed, 3 Jul 2013 01:05:05 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:05:05 GMT Message-Id: <201307030105.r631553F070169@freefall.freebsd.org> To: mitya@demos.su, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/70401: [modules] Could not load ipl.ko when no INET6 in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:05:09 -0000 Synopsis: [modules] Could not load ipl.ko when no INET6 in the kernel State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. To submitter: is this aging PR still relevant? Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=70401 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:05:30 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC6CDEA7; Wed, 3 Jul 2013 01:05:30 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 86A5D1FD4; Wed, 3 Jul 2013 01:05:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6315U34070400; Wed, 3 Jul 2013 01:05:30 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6315Tfq070387; Wed, 3 Jul 2013 01:05:29 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:05:29 GMT Message-Id: <201307030105.r6315Tfq070387@freefall.freebsd.org> To: remy@unix-asp.com, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/72210: [ipfilter] ipnat problem with IP Fastforward enabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:05:30 -0000 Old Synopsis: ipnat problem with IP Fastforward enabled New Synopsis: [ipfilter] ipnat problem with IP Fastforward enabled State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=72210 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:05:43 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A2C22F36; Wed, 3 Jul 2013 01:05:43 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7C5461FD8; Wed, 3 Jul 2013 01:05:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6315hcI070451; Wed, 3 Jul 2013 01:05:43 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6315hLQ070450; Wed, 3 Jul 2013 01:05:43 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:05:43 GMT Message-Id: <201307030105.r6315hLQ070450@freefall.freebsd.org> To: rushani@FreeBSD.org, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: conf/74213: [ipfilter] [patch] Connect src/etc/periodic/security/610.ipf6denied to the build X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:05:43 -0000 Synopsis: [ipfilter] [patch] Connect src/etc/periodic/security/610.ipf6denied to the build State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=74213 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:06:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E356FDE; Wed, 3 Jul 2013 01:06:01 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 681F01FEE; Wed, 3 Jul 2013 01:06:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r63161e2070489; Wed, 3 Jul 2013 01:06:01 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r63160jm070488; Wed, 3 Jul 2013 01:06:00 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:06:00 GMT Message-Id: <201307030106.r63160jm070488@freefall.freebsd.org> To: stefanolteanu@yahoo.com, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/79988: [ipfilter] [panic] page faults while in kernel mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:06:01 -0000 Old Synopsis: [panic] page faults while in kernel mode New Synopsis: [ipfilter] [panic] page faults while in kernel mode State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=79988 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:06:32 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD59110F; Wed, 3 Jul 2013 01:06:32 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A80A01FFF; Wed, 3 Jul 2013 01:06:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6316W5q070537; Wed, 3 Jul 2013 01:06:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6316W1T070536; Wed, 3 Jul 2013 01:06:32 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:06:32 GMT Message-Id: <201307030106.r6316W1T070536@freefall.freebsd.org> To: mailhelp@leadhill.net, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/81606: [ipfilter] ipnat fails to start after upgrade to RELENG_5_4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:06:32 -0000 Old Synopsis: ipnat fails to start after upgrade to RELENG_5_4 New Synopsis: [ipfilter] ipnat fails to start after upgrade to RELENG_5_4 State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. To submitter: is this ancient PR still relevant? Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=81606 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:06:54 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 45AF31AA; Wed, 3 Jul 2013 01:06:54 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 205AF1015; Wed, 3 Jul 2013 01:06:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6316s12070599; Wed, 3 Jul 2013 01:06:54 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6316r6g070598; Wed, 3 Jul 2013 01:06:53 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:06:53 GMT Message-Id: <201307030106.r6316r6g070598@freefall.freebsd.org> To: Mark_Andrews@isc.org, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/82806: [ipfilter] ipnat doesn't handle out of order fragments. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:06:54 -0000 Old Synopsis: ipnat doesn't handle out of order fragments. New Synopsis: [ipfilter] ipnat doesn't handle out of order fragments. State-Changed-From-To: suspended->suspended State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=82806 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:07:12 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2013D24B; Wed, 3 Jul 2013 01:07:12 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id EED2E1023; Wed, 3 Jul 2013 01:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6317BOc070647; Wed, 3 Jul 2013 01:07:11 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6317AfK070646; Wed, 3 Jul 2013 01:07:10 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:07:10 GMT Message-Id: <201307030107.r6317AfK070646@freefall.freebsd.org> To: vd@datamax.bg, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/85809: [ipfilter] panic: mutex "ipf state entry" already initialized X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:07:12 -0000 Synopsis: [ipfilter] panic: mutex "ipf state entry" already initialized State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=85809 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:07:25 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0D5A32DF; Wed, 3 Jul 2013 01:07:25 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DB8CF1028; Wed, 3 Jul 2013 01:07:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6317O4B070688; Wed, 3 Jul 2013 01:07:24 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6317OYk070687; Wed, 3 Jul 2013 01:07:24 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:07:24 GMT Message-Id: <201307030107.r6317OYk070687@freefall.freebsd.org> To: gleban@mail.ru, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/91908: [ipfilter] loading ipl.ko to the kernel compiled with options (IPFILTER) causes a problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:07:25 -0000 Synopsis: [ipfilter] loading ipl.ko to the kernel compiled with options (IPFILTER) causes a problem State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=91908 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:09:03 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9C51741F; Wed, 3 Jul 2013 01:09:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 763D7105A; Wed, 3 Jul 2013 01:09:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r63193X9071266; Wed, 3 Jul 2013 01:09:03 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r63193WP071265; Wed, 3 Jul 2013 01:09:03 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:09:03 GMT Message-Id: <201307030109.r63193WP071265@freefall.freebsd.org> To: scf@freebsd.org, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/121274: [ipfilter] [gif] Panic in ether_input() with different NIC's. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:09:03 -0000 Old Synopsis: [panic] Panic in ether_input() with different NIC's. New Synopsis: [ipfilter] [gif] Panic in ether_input() with different NIC's. State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=121274 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:09:39 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C416A4C7; Wed, 3 Jul 2013 01:09:39 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9EBE2106A; Wed, 3 Jul 2013 01:09:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6319dIQ071342; Wed, 3 Jul 2013 01:09:39 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6319dc6071341; Wed, 3 Jul 2013 01:09:39 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:09:39 GMT Message-Id: <201307030109.r6319dc6071341@freefall.freebsd.org> To: ericnk@esreco.net, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/121534: [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:09:39 -0000 Synopsis: [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=121534 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:09:54 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A6DDB558; Wed, 3 Jul 2013 01:09:54 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7ED391071; Wed, 3 Jul 2013 01:09:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6319s5Z071385; Wed, 3 Jul 2013 01:09:54 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6319rtQ071384; Wed, 3 Jul 2013 01:09:53 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:09:53 GMT Message-Id: <201307030109.r6319rtQ071384@freefall.freebsd.org> To: keith@waters.co.za, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/127233: [ipfilter]: ipnat + ipfilter source routing not handling ftp properly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:09:54 -0000 Synopsis: [ipfilter]: ipnat + ipfilter source routing not handling ftp properly State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=127233 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:10:39 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1AEB4600; Wed, 3 Jul 2013 01:10:39 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E92341086; Wed, 3 Jul 2013 01:10:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r631AcX2072959; Wed, 3 Jul 2013 01:10:38 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r631Ac4t072958; Wed, 3 Jul 2013 01:10:38 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:10:38 GMT Message-Id: <201307030110.r631Ac4t072958@freefall.freebsd.org> To: bsdbug@bospaling.nl, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/167768: [ipfilter] Fatal trap in ipfilter/ipnat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:10:39 -0000 Synopsis: [ipfilter] Fatal trap in ipfilter/ipnat State-Changed-From-To: feedback->feedback State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. To submitter: is this still a problem? Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=167768 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:10:52 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 42C8F6AA; Wed, 3 Jul 2013 01:10:52 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1E980108B; Wed, 3 Jul 2013 01:10:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r631ApER073002; Wed, 3 Jul 2013 01:10:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r631ApfL073001; Wed, 3 Jul 2013 01:10:51 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:10:51 GMT Message-Id: <201307030110.r631ApfL073001@freefall.freebsd.org> To: olevole@olevole.ru, linimon@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/176992: [ipfilter] panic from ipfilter/ipnat when VIMAGE options used X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:10:52 -0000 Synopsis: [ipfilter] panic from ipfilter/ipnat when VIMAGE options used State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=176992 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:33:36 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5EE72DA4; Wed, 3 Jul 2013 01:33:36 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 383EC119F; Wed, 3 Jul 2013 01:33:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r631Xadb078419; Wed, 3 Jul 2013 01:33:36 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r631XZrK078418; Wed, 3 Jul 2013 01:33:35 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:33:35 GMT Message-Id: <201307030133.r631XZrK078418@freefall.freebsd.org> To: nodummy@yeah.net, linimon@FreeBSD.org, mlaier@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/104738: [inet] [patch] Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:33:36 -0000 Synopsis: [inet] [patch] Reentrant problem with inet_ntoa in the kernel State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 State-Changed-Why: commit bit has been taken in for safekeeping. Responsible-Changed-From-To: mlaier->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=104738 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:43:38 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 14F0C5CA; Wed, 3 Jul 2013 01:43:38 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E0DB01292; Wed, 3 Jul 2013 01:43:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r631hbkS081214; Wed, 3 Jul 2013 01:43:37 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r631hbAb081213; Wed, 3 Jul 2013 01:43:37 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:43:37 GMT Message-Id: <201307030143.r631hbAb081213@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/121274: [ipfilter] [gif] Panic in ether_input() with different NIC's. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:43:38 -0000 Synopsis: [ipfilter] [gif] Panic in ether_input() with different NIC's. Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 3 01:43:20 UTC 2013 Responsible-Changed-Why: by request. http://www.freebsd.org/cgi/query-pr.cgi?pr=121274 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:52:35 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0321D75B; Wed, 3 Jul 2013 01:52:35 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id D1D8012FE; Wed, 3 Jul 2013 01:52:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r631qY50083054; Wed, 3 Jul 2013 01:52:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r631qYsu083053; Wed, 3 Jul 2013 01:52:34 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:52:34 GMT Message-Id: <201307030152.r631qYsu083053@freefall.freebsd.org> To: mitya@demos.su, linimon@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/70401: [modules] Could not load ipl.ko when no INET6 in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:52:35 -0000 Synopsis: [modules] Could not load ipl.ko when no INET6 in the kernel State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Wed Jul 3 01:52:17 UTC 2013 State-Changed-Why: Submitter's email address bounces. http://www.freebsd.org/cgi/query-pr.cgi?pr=70401 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 01:53:19 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1EDE0800; Wed, 3 Jul 2013 01:53:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id ED9CB130F; Wed, 3 Jul 2013 01:53:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r631rIqW083110; Wed, 3 Jul 2013 01:53:18 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r631rH5J083107; Wed, 3 Jul 2013 01:53:17 GMT (envelope-from linimon) Date: Wed, 3 Jul 2013 01:53:17 GMT Message-Id: <201307030153.r631rH5J083107@freefall.freebsd.org> To: mailhelp@leadhill.net, linimon@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/81606: [ipfilter] ipnat fails to start after upgrade to RELENG_5_4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 01:53:19 -0000 Synopsis: [ipfilter] ipnat fails to start after upgrade to RELENG_5_4 State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Wed Jul 3 01:53:09 UTC 2013 State-Changed-Why: Submitter's email address bounces. http://www.freebsd.org/cgi/query-pr.cgi?pr=81606 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 02:47:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 75F6C2A6; Wed, 3 Jul 2013 02:47:52 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 30A661654; Wed, 3 Jul 2013 02:47:51 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-226-51.lns20.per1.internode.on.net [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r632ljxK084463 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 19:47:48 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51D390CA.5020803@freebsd.org> Date: Wed, 03 Jul 2013 10:47:38 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Sami Halabi Subject: Re: DNAT in freebsd References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> <51D15D06.9030300@grosbein.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-ipfw , Eugene Grosbein , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 02:47:52 -0000 On 7/2/13 10:21 PM, Sami Halabi wrote: > Hi again, > So far no solution.... > > Is there really no alternative in FreeBSD? oh I'm sure there are several solutions.. I looked at the original email but have since deleted it.. ah archives to the rescue.... ok so your request is a bit short on information.. > Here is the situation i want to handle: > My box is a router that handles several /24 behind. > One of my links (em0) is connected to a private network > 192.168.0.1 is me, my neighbour is 192.168.0.2. So you are supplying your neighbour with internet access? > I want to make that any connection comes to 192.168.0.1 to go to ip > 193.xxx.yyy.2 using specific public ip 84.xx.yy.1 comes to 192.168.0.1 from where? from your neighbour? Do you want to intercept all his packets that arrive at that interface or just packets that are addressed to 192.168.0.1? Where is 193.xxx.yyy.2? On one of your networks, or out on the internet? IS it the interface marked "D" in the diagram below? or at [Q]? what is it? a proxy cache? Where is 84.xx.yy.1? Is it your interface "A" in the diagram below? (I assume so) By "using", do you mean that they arrive at 193.xxx.yyy.2 with a rewritten source address of 84.xx.yy.1 or that they think they are going TO 84.xx.yy.1? Where do you want the reply packets to go, and what should they look like? By "go to" do you mean a rewritten destination address of 193.xxx.yyy.2, or just routed to it with the original destination address untouched? > And packets coming to my public 84.xx.yy.1 ip to be trsnslated as came > from 192.168.0.1 and sent to 192.168.0.2/or ant other ips > behind(192.168.1.xx/24). ALL packets that arrive at 84.xx.yy.1 or just some? > > Hope that makes it clearer, and I appreciate any help. so let's draw a picture of what I think we know.. ----------- [a] ------------------------- [b] ------------- internet B|------|84.xx.yy.1 192.168.0.1|-----|192.168.0.2 | |A C D | | neighbour ----------- ------------------------- -------------- | | | [Q] | | your networks ? I think we know what normal packets at [a] and [b] look like but we still need to know what 'changed' packets want to look like. > > Sami > בתאריך 1 ביול 2013 14:16, מאת "Sami Halabi" : > >> Hi, >> I did ping 10.0.1.1 from 10.0.1.2, so packet is 10.0.1.2 ->10.0.1.1 >>> ipfw add 1000 nat 1 all from 10.0.1.2 to 10.0.1.1 >> if I have 10.0.1.1 in em1 no translation is done! >> if I delete it (and add a static arp entry in 10.0.1.2 for mac of >> 10.0.1.1) >> rule 1000 translates well and I get packet from 11.0.3.1->10.0.1.1 >> >>> ipfw add 2000 nat 2 all from 11.0.3.1 to 10.0.1.1 >> no translation is done at all! >> >> Sami >> >>> ipfw add 3000 nat 2 all from 11.0.4.2 to 11.0.3.1 >>> ipfw add 4000 nat 1 all from 10.0.1.1 to 11.0.3.1 >>> >>> >>> ipfw nat 1 config same_ports ureg_only ip 11.0.3.1 >>> ipfw nat 1 config reverse same_ports ureg_only ip 11.0.4.2 >> >> >> On Mon, Jul 1, 2013 at 1:42 PM, Eugene Grosbein wrote: >> >>> On 01.07.2013 17:05, Sami Halabi wrote: >>>> Hi, >>>> forgot to mention that but this sysctl is already set to 0. >>>> i see in the logs packets pass 1000 rule. >>> Use rules like 'ipfw add 1500 count log ip from any to any' to check >>> intermediate results of translation. >>> >>> >> >> -- >> Sami Halabi >> Information Systems Engineer >> NMS Projects Expert >> FreeBSD SysAdmin Expert >> > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 03:59:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ECEF5FA1; Wed, 3 Jul 2013 03:59:48 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9BA6A19E1; Wed, 3 Jul 2013 03:59:48 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-226-51.lns20.per1.internode.on.net [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r633xZB2084693 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 20:59:37 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51D3A1A0.8090904@freebsd.org> Date: Wed, 03 Jul 2013 11:59:28 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Sami Halabi Subject: Re: DNAT in freebsd References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> <51D15D06.9030300@grosbein.net> <51D390CA.5020803@freebsd.org> In-Reply-To: <51D390CA.5020803@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-ipfw , Eugene Grosbein , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 03:59:49 -0000 On 7/3/13 10:47 AM, Julian Elischer wrote: > On 7/2/13 10:21 PM, Sami Halabi wrote: >> Hi again, >> So far no solution.... >> >> Is there really no alternative in FreeBSD? > > oh I'm sure there are several solutions.. > I looked at the original email but have since deleted it.. > > ah archives to the rescue.... > > ok so your request is a bit short on information.. thinking about your request I think what you want to do is to make it look as if you have a web server or something at 192.168.0.1 to your neighbour, but to in fact serve those requests from a machine at 193.xxx.yyy.2. In addition, you need the requests to appear to come from your external address, so that the responses can find their way back to you. my next question is: Do you control 193.xxx.yyy.2? (is it FreeBSD?) because there are several ways you could solve that problem if you do, and it is.. basically by making a tunnel directly between that machine and you. if you want to not use a tunnel there are several steps on the way. we need to think abut what packets look like at each step. at em0, incoming packet A from neighbour, on the wire: To: 192.168.0.1 port 80 From: 192.168.0.x port MMM0 we want to change this packet. packet B from neighbour, on the wire: To: www.google.com port 80 From: 192.168.0.x port MMM1 we want to leave this packet alone (for now) At this stage, (on the incoming packet A on em0) we need to change the DESTINATION address, so we need a regular NAT, acting as if it were accepting an incoming connection. (which it is). so from the natd man page, the NAT 'rule' is: redirect_address 193.xxx.yyy.2 192.168.0.1 This must only happen on incoming packets from the neighbour, *addressed to you* so ipfw has a rule: ipfw add xx ${NAT_ACTION} ip from ${NEIGHBOUR_NET} to ${MY_NIGHBOUR_ADDR} in recv ${MY_NEIGHBOUR_IFACE} NAT_ACTION is either "nat 1" or "divert ${INTERNAL_DIVER_PORT} MY_NEIGHBOUR_ADDR="192.168.0.0/24" MY_NEIGHBOUR_IFACE="em0" now you need a rule to match this one for retranslation of return packets so on output you have: ipfw add yy ${NAT_ACTION} ip from 193.xxx.yyy.zzz to ${NEIGHBOUR_NET} out xmit ${MY_NEIGHBOUR_IFACE} and the nat must be set up to leave unmapped packets alone. so deny_incoming must NOT be set in the NAT configuration. so theoretically this is the destination address taken care of (in outgoing packets, source address on incoming packets). So then you need to take care of the source address of the outgoing packets. this takes place on the INTERNET facing interface, and really, it should all be taken care of already if you have NAT enabled and you can ping the internet from the neighbour's net. hope this helps.... Julian > >> Here is the situation i want to handle: >> My box is a router that handles several /24 behind. >> One of my links (em0) is connected to a private network >> 192.168.0.1 is me, my neighbour is 192.168.0.2. > > So you are supplying your neighbour with internet access? > >> I want to make that any connection comes to 192.168.0.1 to go to ip >> 193.xxx.yyy.2 using specific public ip 84.xx.yy.1 > > comes to 192.168.0.1 from where? from your neighbour? > Do you want to intercept all his packets that arrive at > that interface or just packets that are addressed to 192.168.0.1? > > Where is 193.xxx.yyy.2? On one of your networks, or out on the > internet? > IS it the interface marked "D" in the diagram below? or at [Q]? > what is it? a proxy cache? > > Where is 84.xx.yy.1? Is it your interface "A" in the diagram below? > (I assume so) > By "using", do you mean that they > arrive at 193.xxx.yyy.2 with a rewritten source address of 84.xx.yy.1 > or that they think they are going TO 84.xx.yy.1? Where do you want the > reply packets to go, and what should they look like? > > By "go to" do you mean a rewritten destination address of > 193.xxx.yyy.2, > or just routed to it with the original destination address untouched? > >> And packets coming to my public 84.xx.yy.1 ip to be trsnslated as came >> from 192.168.0.1 and sent to 192.168.0.2/or ant other ips >> behind(192.168.1.xx/24). > > ALL packets that arrive at 84.xx.yy.1 or just some? > >> >> Hope that makes it clearer, and I appreciate any help. > > so let's draw a picture of what I think we know.. > > ----------- [a] ------------------------- [b] ------------- > internet B|------|84.xx.yy.1 192.168.0.1|-----|192.168.0.2 > | |A C D | | neighbour > ----------- ------------------------- -------------- > | | | > [Q] | | > your networks ? > > I think we know what normal packets at [a] and [b] look like > but we still need to know what 'changed' packets want to look like. > > >> >> Sami >> בתאריך 1 ביול 2013 14:16, מאת "Sami Halabi" : >> >>> Hi, >>> I did ping 10.0.1.1 from 10.0.1.2, so packet is 10.0.1.2 ->10.0.1.1 >>>> ipfw add 1000 nat 1 all from 10.0.1.2 to 10.0.1.1 >>> if I have 10.0.1.1 in em1 no translation is done! >>> if I delete it (and add a static arp entry in 10.0.1.2 for mac of >>> 10.0.1.1) >>> rule 1000 translates well and I get packet from 11.0.3.1->10.0.1.1 >>> >>>> ipfw add 2000 nat 2 all from 11.0.3.1 to 10.0.1.1 >>> no translation is done at all! >>> >>> Sami >>> >>>> ipfw add 3000 nat 2 all from 11.0.4.2 to 11.0.3.1 >>>> ipfw add 4000 nat 1 all from 10.0.1.1 to 11.0.3.1 >>>> >>>> >>>> ipfw nat 1 config same_ports ureg_only ip 11.0.3.1 >>>> ipfw nat 1 config reverse same_ports ureg_only ip 11.0.4.2 >>> >>> >>> On Mon, Jul 1, 2013 at 1:42 PM, Eugene Grosbein >>> wrote: >>> >>>> On 01.07.2013 17:05, Sami Halabi wrote: >>>>> Hi, >>>>> forgot to mention that but this sysctl is already set to 0. >>>>> i see in the logs packets pass 1000 rule. >>>> Use rules like 'ipfw add 1500 count log ip from any to any' to check >>>> intermediate results of translation. >>>> >>>> >>> >>> -- >>> Sami Halabi >>> Information Systems Engineer >>> NMS Projects Expert >>> FreeBSD SysAdmin Expert >>> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to >> "freebsd-ipfw-unsubscribe@freebsd.org" >> >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 04:07:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D60DB254; Wed, 3 Jul 2013 04:07:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9F4301A2D; Wed, 3 Jul 2013 04:07:03 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-226-51.lns20.per1.internode.on.net [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r6346wPI084737 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 21:07:01 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51D3A35C.8070305@freebsd.org> Date: Wed, 03 Jul 2013 12:06:52 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Sami Halabi Subject: Re: DNAT in freebsd References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> <51D15D06.9030300@grosbein.net> <51D390CA.5020803@freebsd.org> <51D3A1A0.8090904@freebsd.org> In-Reply-To: <51D3A1A0.8090904@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw , Eugene Grosbein , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 04:07:03 -0000 On 7/3/13 11:59 AM, Julian Elischer wrote: > On 7/3/13 10:47 AM, Julian Elischer wrote: >> On 7/2/13 10:21 PM, Sami Halabi wrote: >>> Hi again, >>> So far no solution.... >>> >>> Is there really no alternative in FreeBSD? >> >> oh I'm sure there are several solutions.. >> I looked at the original email but have since deleted it.. >> >> ah archives to the rescue.... >> >> ok so your request is a bit short on information.. > > thinking about your request I think what you want to do is to make > it look as if you have a web server or something at 192.168.0.1 to > your neighbour, but to in fact serve those requests from a machine > at 193.xxx.yyy.2. In addition, you need the requests to appear to > come from your external address, so that the responses can find > their way back to you. > > my next question is: Do you control 193.xxx.yyy.2? (is it FreeBSD?) > because there are several ways you could solve that problem if you > do, and it is.. > basically by making a tunnel directly between that machine and you. > > if you want to not use a tunnel there are several steps on the way. > we need to think abut what packets look like at each step. > > at em0, incoming > > packet A from neighbour, on the wire: > To: 192.168.0.1 port 80 > From: 192.168.0.x port MMM0 > we want to change this packet. > > packet B from neighbour, on the wire: > To: www.google.com port 80 > From: 192.168.0.x port MMM1 > we want to leave this packet alone (for now) > > At this stage, (on the incoming packet A on em0) > we need to change the DESTINATION address, > so we need a regular NAT, acting as if it were accepting an incoming > connection. > (which it is). > > so from the natd man page, the NAT 'rule' is: > redirect_address 193.xxx.yyy.2 192.168.0.1 > > This must only happen on incoming packets from the neighbour, > *addressed to you* so > ipfw has a rule: > ipfw add xx ${NAT_ACTION} ip from ${NEIGHBOUR_NET} to > ${MY_NIGHBOUR_ADDR} in recv ${MY_NEIGHBOUR_IFACE} > > NAT_ACTION is either "nat 1" or "divert ${INTERNAL_DIVER_PORT} > MY_NEIGHBOUR_ADDR="192.168.0.0/24" > MY_NEIGHBOUR_IFACE="em0" > > now you need a rule to match this one for retranslation of return > packets > so on output you have: > ipfw add yy ${NAT_ACTION} ip from 193.xxx.yyy.zzz to > ${NEIGHBOUR_NET} out xmit ${MY_NEIGHBOUR_IFACE} > > and the nat must be set up to leave unmapped packets alone. > so deny_incoming must NOT be set in the NAT configuration. I am talking all theoretically here as I don't have such a setup at the moment, and I can't remember if the packet direction is given to natd/ipfw-nat if so then you MAY need the 'reverse' setting, but I don't guarantee it. If you use natd you will need a separae instance, or natd. If you use ipfw internal nat then you must use a separate nat instance there too. > > > > so theoretically this is the destination address taken care of (in > outgoing packets, source address on incoming packets). > > So then you need to take care of the source address of the outgoing > packets. > this takes place on the INTERNET facing interface, and really, it > should all be taken care of already if you have NAT enabled and you > can ping the internet from the neighbour's net. > > > hope this helps.... > > Julian > > > > From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 04:13:24 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A3BB54B0; Wed, 3 Jul 2013 04:13:24 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7D97B1A7D; Wed, 3 Jul 2013 04:13:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r634DOsx011862; Wed, 3 Jul 2013 04:13:24 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r634DOm1011861; Wed, 3 Jul 2013 04:13:24 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 04:13:24 GMT Message-Id: <201307030413.r634DOm1011861@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/91908: [ipfilter] loading ipl.ko to the kernel compiled with options (IPFILTER) causes a problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 04:13:24 -0000 Synopsis: [ipfilter] loading ipl.ko to the kernel compiled with options (IPFILTER) causes a problem Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 04:12:56 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=91908 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 04:28:59 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 483E1B4B for ; Wed, 3 Jul 2013 04:28:59 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id 1B0051AF5 for ; Wed, 3 Jul 2013 04:28:59 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id g12so7376681oah.25 for ; Tue, 02 Jul 2013 21:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=P83rM3GQmtdwZaF6ZooVv/GR5DeI2rfgWChxbEzQ7ec=; b=lv5764cagt8mFyLzDyYmkdI2//RusMtRBC+//kPawOspDcDWNxzQsmEEoxkRSL1idj rU5HYCO6ttShEsDBcy8TiuqhyOb9hC8qZRHdULGY3h2JahP3K0BUVbBSIm8eL9Z5Oqk+ w7CeWbJIFrjmZM4J25wnV4KG+CvnhfMJJTh30W+kyKUYCrSVA/4gmbZyhZqrHXFJ0a8Z xm5Wxa9JwLky5qMT8ekyvAMfOfU8PMhgda8cNPHedrhyxSfAAvBKIDV8uVBI8T0Dr62P Ybp0xxPLHKlgoKQECFJaMSl3h9rnHhFtPeb5acMT5t29TYykIZ7RAqleA73QzI5HsXId bPNA== MIME-Version: 1.0 X-Received: by 10.182.46.230 with SMTP id y6mr15205316obm.79.1372825738660; Tue, 02 Jul 2013 21:28:58 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Tue, 2 Jul 2013 21:28:58 -0700 (PDT) Date: Wed, 3 Jul 2013 00:28:58 -0400 Message-ID: Subject: Terrible ix performance From: Outback Dingo To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 04:28:59 -0000 Ive got a high end storage server here, iperf shows decent network io iperf -i 10 -t 20 -c 10.0.96.1 -w 2.5M -l 2.5M ------------------------------------------------------------ Client connecting to 10.0.96.1, TCP port 5001 TCP window size: 2.50 MByte (WARNING: requested 2.50 MByte) ------------------------------------------------------------ [ 3] local 10.0.96.2 port 34753 connected with 10.0.96.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 9.78 GBytes 8.40 Gbits/sec [ 3] 10.0-20.0 sec 8.95 GBytes 7.69 Gbits/sec [ 3] 0.0-20.0 sec 18.7 GBytes 8.05 Gbits/sec the card has a 3 meter twinax cable from cisco connected to it, going through a fujitsu switch. We have tweaked various networking, and kernel sysctls, however from a sftp and nfs session i cant get better then 100MBs from a zpool with 8 mirrored vdevs. We also have an identical box that will get 1.4Gbs with a 1 meter cisco twinax cables that writes 2.4Gbs compared to reads only 1.4Gbs... does anyone have an idea of what the bottle neck could be?? This is a shared storage array with dual LSI controllers connected to 32 drives via an enclosure, local dd and other tests show the zpool performs quite well. however as soon as we introduce any type of protocol, sftp, samba, nfs performance plummets. Im quite puzzled and have run out of ideas. so now curiousity has me........ its loading the ix driver and working but not up to speed, it is feasible it should be using the ixgbe driver?? ix0@pci0:2:0:0: class=0x020000 card=0x000c8086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' class = network subclass = ethernet ix1@pci0:2:0:1: class=0x020000 card=0x000c8086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' class = network subclass = ethernet From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:08:16 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E3AC817E; Wed, 3 Jul 2013 05:08:16 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id BF6701C00; Wed, 3 Jul 2013 05:08:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6358GWK021278; Wed, 3 Jul 2013 05:08:16 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6358GsQ021277; Wed, 3 Jul 2013 05:08:16 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:08:16 GMT Message-Id: <201307030508.r6358GsQ021277@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/17109: [ipfilter] fastroute crashes for lo0 udp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:08:17 -0000 Synopsis: [ipfilter] fastroute crashes for lo0 udp Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:07:39 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=17109 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:09:07 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1C7E021C; Wed, 3 Jul 2013 05:09:07 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id EBBD41C10; Wed, 3 Jul 2013 05:09:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r63596rv021347; Wed, 3 Jul 2013 05:09:06 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r63596DY021346; Wed, 3 Jul 2013 05:09:06 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:09:06 GMT Message-Id: <201307030509.r63596DY021346@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/27474: [ipfilter] [ppp] Interactive use of user PPP and ipfilter can be insecure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:09:07 -0000 Synopsis: [ipfilter] [ppp] Interactive use of user PPP and ipfilter can be insecure Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:08:47 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=27474 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:09:37 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DACF52B2; Wed, 3 Jul 2013 05:09:37 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B182A1C1E; Wed, 3 Jul 2013 05:09:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6359bTW021402; Wed, 3 Jul 2013 05:09:37 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6359bLt021401; Wed, 3 Jul 2013 05:09:37 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:09:37 GMT Message-Id: <201307030509.r6359bLt021401@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/34665: [ipfilter] [hang] ipfilter rcmd proxy "hangs". X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:09:37 -0000 Synopsis: [ipfilter] [hang] ipfilter rcmd proxy "hangs". Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:09:22 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=34665 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:10:08 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 216B3346; Wed, 3 Jul 2013 05:10:08 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id F133A1C29; Wed, 3 Jul 2013 05:10:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635A7Ss022269; Wed, 3 Jul 2013 05:10:07 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635A7w7022255; Wed, 3 Jul 2013 05:10:07 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:10:07 GMT Message-Id: <201307030510.r635A7w7022255@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: conf/46913: [ipfilter] denied packets of security run output contains nonmatched rules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:10:08 -0000 Synopsis: [ipfilter] denied packets of security run output contains nonmatched rules Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:09:50 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=46913 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:10:40 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0EE923FD; Wed, 3 Jul 2013 05:10:40 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DE49A1C38; Wed, 3 Jul 2013 05:10:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635Ad6j023037; Wed, 3 Jul 2013 05:10:39 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635AdBk023036; Wed, 3 Jul 2013 05:10:39 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:10:39 GMT Message-Id: <201307030510.r635AdBk023036@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/48741: [ipfilter] ipnat corrupts packets on gre interface with rules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:10:40 -0000 Synopsis: [ipfilter] ipnat corrupts packets on gre interface with rules Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:10:26 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=48741 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:11:07 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D831149A; Wed, 3 Jul 2013 05:11:07 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B37C21C4A; Wed, 3 Jul 2013 05:11:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635B7DA023103; Wed, 3 Jul 2013 05:11:07 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635B7Je023102; Wed, 3 Jul 2013 05:11:07 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:11:07 GMT Message-Id: <201307030511.r635B7Je023102@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/70904: [ipfilter] ipfilter ipnat problem with h323 proxy support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:11:07 -0000 Synopsis: [ipfilter] ipfilter ipnat problem with h323 proxy support Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:10:54 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=70904 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:16:42 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BC842572; Wed, 3 Jul 2013 05:16:42 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 960D91C72; Wed, 3 Jul 2013 05:16:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635Ggtl024865; Wed, 3 Jul 2013 05:16:42 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635GgkO024864; Wed, 3 Jul 2013 05:16:42 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:16:42 GMT Message-Id: <201307030516.r635GgkO024864@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/72210: [ipfilter] ipnat problem with IP Fastforward enabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:16:42 -0000 Synopsis: [ipfilter] ipnat problem with IP Fastforward enabled Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:16:26 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=72210 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:16:58 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C007D606; Wed, 3 Jul 2013 05:16:58 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5991C7C; Wed, 3 Jul 2013 05:16:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635GwpY024913; Wed, 3 Jul 2013 05:16:58 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635GwtV024912; Wed, 3 Jul 2013 05:16:58 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:16:58 GMT Message-Id: <201307030516.r635GwtV024912@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: conf/74213: [ipfilter] [patch] Connect src/etc/periodic/security/610.ipf6denied to the build X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:16:58 -0000 Synopsis: [ipfilter] [patch] Connect src/etc/periodic/security/610.ipf6denied to the build Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:16:43 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=74213 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:17:13 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F6C36A0; Wed, 3 Jul 2013 05:17:13 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5A0A81C89; Wed, 3 Jul 2013 05:17:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635HDvk024961; Wed, 3 Jul 2013 05:17:13 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635HDu2024960; Wed, 3 Jul 2013 05:17:13 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:17:13 GMT Message-Id: <201307030517.r635HDu2024960@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/77195: [ipfilter] [patch] ipfilter ioctl SIOCGNATL does not match active sessions properly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:17:13 -0000 Synopsis: [ipfilter] [patch] ipfilter ioctl SIOCGNATL does not match active sessions properly Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:16:59 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=77195 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:17:30 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 438D2739; Wed, 3 Jul 2013 05:17:30 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1EFBE1C97; Wed, 3 Jul 2013 05:17:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635HTO7025009; Wed, 3 Jul 2013 05:17:29 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635HTOv025008; Wed, 3 Jul 2013 05:17:29 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:17:29 GMT Message-Id: <201307030517.r635HTOv025008@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/79988: [ipfilter] [panic] page faults while in kernel mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:17:30 -0000 Synopsis: [ipfilter] [panic] page faults while in kernel mode Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:17:14 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=79988 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:17:51 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B41D7D4; Wed, 3 Jul 2013 05:17:51 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 467E21CA7; Wed, 3 Jul 2013 05:17:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635HpHA025064; Wed, 3 Jul 2013 05:17:51 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635HpxB025063; Wed, 3 Jul 2013 05:17:51 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:17:51 GMT Message-Id: <201307030517.r635HpxB025063@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/82806: [ipfilter] ipnat doesn't handle out of order fragments. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:17:51 -0000 Synopsis: [ipfilter] ipnat doesn't handle out of order fragments. Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:17:30 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=82806 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:18:10 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 543E686A; Wed, 3 Jul 2013 05:18:10 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8D51CB5; Wed, 3 Jul 2013 05:18:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635IATN025114; Wed, 3 Jul 2013 05:18:10 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635IAwo025113; Wed, 3 Jul 2013 05:18:10 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:18:10 GMT Message-Id: <201307030518.r635IAwo025113@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/85809: [ipfilter] panic: mutex "ipf state entry" already initialized X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:18:10 -0000 Synopsis: [ipfilter] panic: mutex "ipf state entry" already initialized Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:17:52 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=85809 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:18:26 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A4A7A904; Wed, 3 Jul 2013 05:18:26 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8174C1CC1; Wed, 3 Jul 2013 05:18:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635IQNS025160; Wed, 3 Jul 2013 05:18:26 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635IQe6025159; Wed, 3 Jul 2013 05:18:26 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:18:26 GMT Message-Id: <201307030518.r635IQe6025159@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/86103: [ipfilter] Illegal NAT Traversal in IPFilter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:18:26 -0000 Synopsis: [ipfilter] Illegal NAT Traversal in IPFilter Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:18:11 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=86103 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:18:45 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E36BF9A9; Wed, 3 Jul 2013 05:18:45 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id BEB2F1CD1; Wed, 3 Jul 2013 05:18:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635Ij2i025215; Wed, 3 Jul 2013 05:18:45 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635IjN6025214; Wed, 3 Jul 2013 05:18:45 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:18:45 GMT Message-Id: <201307030518.r635IjN6025214@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/87521: [ipfilter] [panic] using ipfilter "auth" keyword leads to kernel fault [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:18:46 -0000 Synopsis: [ipfilter] [panic] using ipfilter "auth" keyword leads to kernel fault [regression] Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:18:27 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=87521 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:19:05 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 74D3DA3E; Wed, 3 Jul 2013 05:19:05 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4FE1E1CDC; Wed, 3 Jul 2013 05:19:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635J5oP025268; Wed, 3 Jul 2013 05:19:05 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635J5NV025267; Wed, 3 Jul 2013 05:19:05 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:19:05 GMT Message-Id: <201307030519.r635J5NV025267@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/91777: [ipfilter] [patch] wrong behaviour with skip rule inside an ipfilter group with a 'quick' head X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:19:05 -0000 Synopsis: [ipfilter] [patch] wrong behaviour with skip rule inside an ipfilter group with a 'quick' head Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:18:46 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=91777 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:19:41 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 128AAAE0; Wed, 3 Jul 2013 05:19:41 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E26B91CE7; Wed, 3 Jul 2013 05:19:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635Jew1025341; Wed, 3 Jul 2013 05:19:40 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635Jedf025340; Wed, 3 Jul 2013 05:19:40 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:19:40 GMT Message-Id: <201307030519.r635Jedf025340@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/98978: [ipfilter] [patch] ipfilter drops OOW packets under 6.1-Release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:19:41 -0000 Synopsis: [ipfilter] [patch] ipfilter drops OOW packets under 6.1-Release Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:19:20 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=98978 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:20:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1017FB73; Wed, 3 Jul 2013 05:20:02 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DFA261CF2; Wed, 3 Jul 2013 05:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635K11I025488; Wed, 3 Jul 2013 05:20:01 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635K1EO025487; Wed, 3 Jul 2013 05:20:01 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:20:01 GMT Message-Id: <201307030520.r635K1EO025487@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/101948: [ipfilter] [panic] Kernel Panic Trap No 12 Page Fault - caused by IpFilter? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:20:02 -0000 Synopsis: [ipfilter] [panic] Kernel Panic Trap No 12 Page Fault - caused by IpFilter? Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:19:41 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=101948 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:20:21 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9034FC0A; Wed, 3 Jul 2013 05:20:21 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6BDA51CFD; Wed, 3 Jul 2013 05:20:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635KL4I026981; Wed, 3 Jul 2013 05:20:21 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635KLTf026980; Wed, 3 Jul 2013 05:20:21 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:20:21 GMT Message-Id: <201307030520.r635KLTf026980@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/123796: [ipfilter] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not work X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:20:21 -0000 Synopsis: [ipfilter] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not work Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:20:07 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=123796 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:20:34 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C469C9C; Wed, 3 Jul 2013 05:20:34 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6E3231D05; Wed, 3 Jul 2013 05:20:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635KYVg027031; Wed, 3 Jul 2013 05:20:34 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635KYrY027030; Wed, 3 Jul 2013 05:20:34 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:20:34 GMT Message-Id: <201307030520.r635KYrY027030@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/127233: [ipfilter]: ipnat + ipfilter source routing not handling ftp properly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:20:34 -0000 Synopsis: [ipfilter]: ipnat + ipfilter source routing not handling ftp properly Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:20:22 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=127233 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:20:54 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9D285D37; Wed, 3 Jul 2013 05:20:54 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 783C61D17; Wed, 3 Jul 2013 05:20:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635KsKq027081; Wed, 3 Jul 2013 05:20:54 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635Ksxm027080; Wed, 3 Jul 2013 05:20:54 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:20:54 GMT Message-Id: <201307030520.r635Ksxm027080@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: conf/130555: [ipfilter] [rc.d] [patch] No good way to set ipfilter variables at boot time X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:20:54 -0000 Synopsis: [ipfilter] [rc.d] [patch] No good way to set ipfilter variables at boot time Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:20:35 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=130555 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:21:18 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B5989DCA; Wed, 3 Jul 2013 05:21:18 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 910CB1D21; Wed, 3 Jul 2013 05:21:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635LIU3027135; Wed, 3 Jul 2013 05:21:18 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635LISK027134; Wed, 3 Jul 2013 05:21:18 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:21:18 GMT Message-Id: <201307030521.r635LISK027134@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/131601: [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp=0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:21:18 -0000 Synopsis: [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp=0) Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:20:55 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=131601 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:21:35 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 48F56E5D; Wed, 3 Jul 2013 05:21:35 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1E5531D2B; Wed, 3 Jul 2013 05:21:35 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635LYse027187; Wed, 3 Jul 2013 05:21:34 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635LYDq027186; Wed, 3 Jul 2013 05:21:34 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:21:34 GMT Message-Id: <201307030521.r635LYDq027186@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/132554: [ipfilter] There is no ippool start script/ipfilter magic to load them X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:21:35 -0000 Synopsis: [ipfilter] There is no ippool start script/ipfilter magic to load them Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:21:19 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=132554 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:21:50 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2C73EED; Wed, 3 Jul 2013 05:21:50 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7601D33; Wed, 3 Jul 2013 05:21:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635Loch027237; Wed, 3 Jul 2013 05:21:50 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635Loma027236; Wed, 3 Jul 2013 05:21:50 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:21:50 GMT Message-Id: <201307030521.r635Loma027236@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/138177: [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:2577 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:21:50 -0000 Synopsis: [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:2577 Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:21:35 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=138177 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:22:05 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D4DB1F83; Wed, 3 Jul 2013 05:22:05 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B06F71D40; Wed, 3 Jul 2013 05:22:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635M5sp027303; Wed, 3 Jul 2013 05:22:05 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635M5Rb027302; Wed, 3 Jul 2013 05:22:05 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:22:05 GMT Message-Id: <201307030522.r635M5Rb027302@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/139058: [ipfilter] mbuf cluster leak on FreeBSD 7.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:22:05 -0000 Synopsis: [ipfilter] mbuf cluster leak on FreeBSD 7.2 Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:21:51 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=139058 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:22:21 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 090CC7E; Wed, 3 Jul 2013 05:22:21 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DA24D1D4B; Wed, 3 Jul 2013 05:22:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635MKnd027350; Wed, 3 Jul 2013 05:22:20 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635MKZe027349; Wed, 3 Jul 2013 05:22:20 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:22:20 GMT Message-Id: <201307030522.r635MKZe027349@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/139565: [ipfilter] ipfilter ioctl SIOCDELST broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:22:21 -0000 Synopsis: [ipfilter] ipfilter ioctl SIOCDELST broken Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:22:06 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=139565 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:22:39 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 97BB3138; Wed, 3 Jul 2013 05:22:39 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 730321D55; Wed, 3 Jul 2013 05:22:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635MdQ4027402; Wed, 3 Jul 2013 05:22:39 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635MdVr027401; Wed, 3 Jul 2013 05:22:39 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:22:39 GMT Message-Id: <201307030522.r635MdVr027401@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/149937: [ipfilter] [patch] kernel panic in ipfilter IP fragments with TCP paylaod in reverse order X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:22:39 -0000 Synopsis: [ipfilter] [patch] kernel panic in ipfilter IP fragments with TCP paylaod in reverse order Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:22:21 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=149937 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:22:54 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 02C6529B; Wed, 3 Jul 2013 05:22:54 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id D24AE1D61; Wed, 3 Jul 2013 05:22:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635MrdF027454; Wed, 3 Jul 2013 05:22:53 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635MrtT027453; Wed, 3 Jul 2013 05:22:53 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:22:53 GMT Message-Id: <201307030522.r635MrtT027453@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/162926: [ipfilter] Infinite loop in ipfilter with fragmented IPv6 traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:22:54 -0000 Synopsis: [ipfilter] Infinite loop in ipfilter with fragmented IPv6 traffic Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:22:40 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=162926 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:23:11 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C4F4386; Wed, 3 Jul 2013 05:23:11 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id ECD1E1D6A; Wed, 3 Jul 2013 05:23:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635NAGw027502; Wed, 3 Jul 2013 05:23:10 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635NAs8027501; Wed, 3 Jul 2013 05:23:10 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:23:10 GMT Message-Id: <201307030523.r635NAs8027501@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/165963: [panic] [ipfilter] ipfilter/nat NULL pointer deference X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:23:11 -0000 Synopsis: [panic] [ipfilter] ipfilter/nat NULL pointer deference Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:22:54 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=165963 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:23:29 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 46BF5423; Wed, 3 Jul 2013 05:23:29 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 220241D7B; Wed, 3 Jul 2013 05:23:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635NTRT027549; Wed, 3 Jul 2013 05:23:29 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635NSZi027548; Wed, 3 Jul 2013 05:23:28 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:23:28 GMT Message-Id: <201307030523.r635NSZi027548@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/166372: [patch] [ipfilter] drops UDP packets with zero checksum on some interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:23:29 -0000 Synopsis: [patch] [ipfilter] drops UDP packets with zero checksum on some interfaces Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:23:11 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=166372 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:23:43 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 87D274B8; Wed, 3 Jul 2013 05:23:43 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 63B721D86; Wed, 3 Jul 2013 05:23:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635NhDW027602; Wed, 3 Jul 2013 05:23:43 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635NhJd027601; Wed, 3 Jul 2013 05:23:43 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:23:43 GMT Message-Id: <201307030523.r635NhJd027601@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/166940: [ipfilter] [panic] Double fault in kern 8.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:23:43 -0000 Synopsis: [ipfilter] [panic] Double fault in kern 8.2 Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:23:30 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=166940 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:23:56 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0A801548; Wed, 3 Jul 2013 05:23:56 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DABA51D8F; Wed, 3 Jul 2013 05:23:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635NtnI027651; Wed, 3 Jul 2013 05:23:55 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635NtZ5027650; Wed, 3 Jul 2013 05:23:55 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:23:55 GMT Message-Id: <201307030523.r635NtZ5027650@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/167768: [ipfilter] Fatal trap in ipfilter/ipnat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:23:56 -0000 Synopsis: [ipfilter] Fatal trap in ipfilter/ipnat Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:23:44 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=167768 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:24:54 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2024D645; Wed, 3 Jul 2013 05:24:54 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id F02D61DAA; Wed, 3 Jul 2013 05:24:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635OrSu027768; Wed, 3 Jul 2013 05:24:53 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635OrXh027767; Wed, 3 Jul 2013 05:24:53 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:24:53 GMT Message-Id: <201307030524.r635OrXh027767@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/176992: [ipfilter] panic from ipfilter/ipnat when VIMAGE options used X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:24:54 -0000 Synopsis: [ipfilter] panic from ipfilter/ipnat when VIMAGE options used Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:24:38 UTC 2013 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=176992 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 05:25:29 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B760B6E8; Wed, 3 Jul 2013 05:25:29 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 927111DBF; Wed, 3 Jul 2013 05:25:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r635PT44027843; Wed, 3 Jul 2013 05:25:29 GMT (envelope-from cy@freefall.freebsd.org) Received: (from cy@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r635PT7x027842; Wed, 3 Jul 2013 05:25:29 GMT (envelope-from cy) Date: Wed, 3 Jul 2013 05:25:29 GMT Message-Id: <201307030525.r635PT7x027842@freefall.freebsd.org> To: cy@FreeBSD.org, freebsd-net@FreeBSD.org, cy@FreeBSD.org From: cy@FreeBSD.org Subject: Re: kern/178116: [ipfilter] [panic] Kernel panic: general protection fault in tcp_do_segment X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 05:25:29 -0000 Synopsis: [ipfilter] [panic] Kernel panic: general protection fault in tcp_do_segment Responsible-Changed-From-To: freebsd-net->cy Responsible-Changed-By: cy Responsible-Changed-When: Wed Jul 3 05:24:54 UTC 2013 Responsible-Changed-Why: Assign to myself. http://www.freebsd.org/cgi/query-pr.cgi?pr=178116 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 06:00:54 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C707D61B for ; Wed, 3 Jul 2013 06:00:54 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 8D6081ECF for ; Wed, 3 Jul 2013 06:00:54 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p14so5254280vbm.4 for ; Tue, 02 Jul 2013 23:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qU7TvWo6eH9FokUvmry56R4gVNdOLGKBsH2QAbByMMg=; b=jkmo/+NYdjjJqW6PlSrMK5cybgKGKAch3EsN8czHhD/9GAAJwuMqAkLk566Lw4NnQC vcCsm7qphJq4utaBajQdVm7mvhURZh4tAW+6kf1AAg2f4L06ncur85zYgBIoS6LqluGe 4kTz+B99iW7wC7IzR1hSobEsMySkesbtjm24S2zFK2nQZTJx4eN5GsYmZ4RkvpMblUFY gfuPcTu2ow68vOgZi1xH8Zr358gCXk6pJwPnReRyZS59vniBxoELhePirhwQwUWbZWFO j7xqdb4l2qJ7jy93JFSexeA5d8cqMaQvWa8wqYwCzOLm38OyHmXZw4/d4y3oPE+3BxbE Jl5A== MIME-Version: 1.0 X-Received: by 10.52.233.234 with SMTP id tz10mr3877690vdc.26.1372831254003; Tue, 02 Jul 2013 23:00:54 -0700 (PDT) Received: by 10.220.52.200 with HTTP; Tue, 2 Jul 2013 23:00:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Jul 2013 23:00:53 -0700 Message-ID: Subject: Re: Terrible ix performance From: Jack Vogel To: Outback Dingo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 06:00:54 -0000 ix is just the device name, it is using the ixgbe driver. The driver should print some kind of banner when it loads, what version of the OS and driver are you using?? I have little experience testing nfs or samba so I am not sure right off what might be the problem. Jack On Tue, Jul 2, 2013 at 9:28 PM, Outback Dingo wrote: > Ive got a high end storage server here, iperf shows decent network io > > iperf -i 10 -t 20 -c 10.0.96.1 -w 2.5M -l 2.5M > ------------------------------------------------------------ > Client connecting to 10.0.96.1, TCP port 5001 > TCP window size: 2.50 MByte (WARNING: requested 2.50 MByte) > ------------------------------------------------------------ > [ 3] local 10.0.96.2 port 34753 connected with 10.0.96.1 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 9.78 GBytes 8.40 Gbits/sec > [ 3] 10.0-20.0 sec 8.95 GBytes 7.69 Gbits/sec > [ 3] 0.0-20.0 sec 18.7 GBytes 8.05 Gbits/sec > > > the card has a 3 meter twinax cable from cisco connected to it, going > through a fujitsu switch. We have tweaked various networking, and kernel > sysctls, however from a sftp and nfs session i cant get better then 100MBs > from a zpool with 8 mirrored vdevs. We also have an identical box that will > get 1.4Gbs with a 1 meter cisco twinax cables that writes 2.4Gbs compared > to reads only 1.4Gbs... > > does anyone have an idea of what the bottle neck could be?? This is a > shared storage array with dual LSI controllers connected to 32 drives via > an enclosure, local dd and other tests show the zpool performs quite well. > however as soon as we introduce any type of protocol, sftp, samba, nfs > performance plummets. Im quite puzzled and have run out of ideas. so now > curiousity has me........ its loading the ix driver and working but not up > to speed, > it is feasible it should be using the ixgbe driver?? > > ix0@pci0:2:0:0: class=0x020000 card=0x000c8086 chip=0x10fb8086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' > class = network > subclass = ethernet > ix1@pci0:2:0:1: class=0x020000 card=0x000c8086 chip=0x10fb8086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' > class = network > subclass = ethernet > _______________________________________________ > 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 Jul 3 08:44:46 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3199918A for ; Wed, 3 Jul 2013 08:44:46 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm1-vm10.bullet.mail.gq1.yahoo.com (nm1-vm10.bullet.mail.gq1.yahoo.com [98.136.218.89]) by mx1.freebsd.org (Postfix) with ESMTP id D45271675 for ; Wed, 3 Jul 2013 08:44:45 +0000 (UTC) Received: from [98.137.12.56] by nm1.bullet.mail.gq1.yahoo.com with NNFMP; 03 Jul 2013 08:41:24 -0000 Received: from [208.71.42.200] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 03 Jul 2013 08:41:23 -0000 Received: from [127.0.0.1] by smtp211.mail.gq1.yahoo.com with NNFMP; 03 Jul 2013 08:41:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372840883; bh=x9oAhiyf4herWuhktueebQqJnHpXdNqlRNGiXOjmJjA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=P6+bkbrXiG452jP3+uWa/wdtrzylWBDuzL6FK348FT4KyvbTgm8w0HxUm46wOG/2wWyQ+Lr8fnExULRlP9eR6bncQUHsdTAbzOXIEc2rGFvfxiozjjo5Hf4MaBT3kOZICgdlwqGh3OZZSBoQp0l0bBiePne+js9d0VPu1jxTqcE= X-Yahoo-Newman-Id: 960422.49157.bm@smtp211.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: xG1m2tsVM1kuwLthGzICaLtNcQ4uSFNW8zPgz80EXp3Qmod .bqlWtU2rnPECjI1Rk2sU7JpatHXfzJictg2zMA4q3iGYYobFUuOr_qPIcIK IPYquRd5Cya5eeFzbEh66W4JYOxC3g_Qbqv1HV0Jp9rdkw9xJvqYJUfSf0G5 Kzkb4SIBgT6FfocYUXQwCNhxQxUPc3Ki1WYMVC.lBFxeOsYXTRnuM_SgTRdc u0ymPm7qjXuw_sdvdEGBb2bYR.9o5n37YVd7AZnXitbbEygtI2r3FAbhV79d 9A.Sqnn5yDfdGi15nWV4gMAGucSwXVMuKH6H0blzle9884iBdTRShQr1mXZD ikZuNEWJ2PQqJZHUnH87KXxaIoZqSa22V0bCans9.9CtBmh57TU_4PiET1qU iDJ1n4gtAA5QANNC350sBF6xasiTA9w51K_uP6ar6H7bP8xc47pmMrUQtXmn nbSHAA7GHeAUItaTrWjHZUP5_7Z0x8K8QO.aaHuLBgr0uiFMlXXkjV3144Wa JLcjofcfKRSQ8QhI0roXaCYs3GFoid9mV7BkUu67hsqcRGxKNrzKy.EEZRQ2 szA-- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [10.64.26.20] (scott4long@69.53.237.126 with ) by smtp211.mail.gq1.yahoo.com with SMTP; 03 Jul 2013 01:41:23 -0700 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Terrible ix performance From: Scott Long In-Reply-To: Date: Wed, 3 Jul 2013 02:41:23 -0600 Content-Transfer-Encoding: 7bit Message-Id: <97FD4CAC-4648-40F8-94CD-4B8D181C4BCC@yahoo.com> References: To: Outback Dingo X-Mailer: Apple Mail (2.1508) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 08:44:46 -0000 On Jul 2, 2013, at 10:28 PM, Outback Dingo wrote: > Ive got a high end storage server here, iperf shows decent network io > > > the card has a 3 meter twinax cable from cisco connected to it, going > through a fujitsu switch. We have tweaked various networking, and kernel > sysctls, however from a sftp and nfs session i cant get better then 100MBs > from a zpool with 8 mirrored vdevs. We also have an identical box that will > get 1.4Gbs with a 1 meter cisco twinax cables that writes 2.4Gbs compared > to reads only 1.4Gbs... > > does anyone have an idea of what the bottle neck could be?? This is a > shared storage array with dual LSI controllers connected to 32 drives via > an enclosure, local dd and other tests show the zpool performs quite well. > however as soon as we introduce any type of protocol, sftp, samba, nfs > performance plummets. Im quite puzzled and have run out of ideas. so now > curiousity has me........ its loading the ix driver and working but not up > to speed, > it is feasible it should be using the ixgbe driver?? Try turning off interrupt moderation. Add the following to /boot/loader.conf hw.ixgbe.enable_aim=0 NAS workloads are extremely sensitive to latency, and interrupt moderation only adds latency. We tune some other things as well at Netflix and manage to get quite good performance, though with a fairly different workload. Let me know if this does or does not work for you. Thanks, Scott From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 08:50:07 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2A5DD2CC for ; Wed, 3 Jul 2013 08:50:07 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id E877716C4 for ; Wed, 3 Jul 2013 08:50:06 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id B66027E84A; Wed, 3 Jul 2013 18:50:04 +1000 (EST) Message-ID: <51D3E5BC.1000604@freebsd.org> Date: Wed, 03 Jul 2013 18:50:04 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130521 Thunderbird/17.0.6 MIME-Version: 1.0 To: Outback Dingo Subject: Re: Terrible ix performance References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 08:50:07 -0000 On 07/03/13 14:28, Outback Dingo wrote: > Ive got a high end storage server here, iperf shows decent network io > > iperf -i 10 -t 20 -c 10.0.96.1 -w 2.5M -l 2.5M > ------------------------------------------------------------ > Client connecting to 10.0.96.1, TCP port 5001 > TCP window size: 2.50 MByte (WARNING: requested 2.50 MByte) > ------------------------------------------------------------ > [ 3] local 10.0.96.2 port 34753 connected with 10.0.96.1 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 9.78 GBytes 8.40 Gbits/sec > [ 3] 10.0-20.0 sec 8.95 GBytes 7.69 Gbits/sec > [ 3] 0.0-20.0 sec 18.7 GBytes 8.05 Gbits/sec Given that iperf exercises the ixgbe driver (ix), network path and TCP, I would suggest that your subject is rather misleading ;) > the card has a 3 meter twinax cable from cisco connected to it, going > through a fujitsu switch. We have tweaked various networking, and kernel > sysctls, however from a sftp and nfs session i cant get better then 100MBs > from a zpool with 8 mirrored vdevs. We also have an identical box that will > get 1.4Gbs with a 1 meter cisco twinax cables that writes 2.4Gbs compared > to reads only 1.4Gbs... I take it the RTT between both hosts is very low i.e. sub 1ms? > does anyone have an idea of what the bottle neck could be?? This is a > shared storage array with dual LSI controllers connected to 32 drives via > an enclosure, local dd and other tests show the zpool performs quite well. > however as soon as we introduce any type of protocol, sftp, samba, nfs > performance plummets. Im quite puzzled and have run out of ideas. so now > curiousity has me........ its loading the ix driver and working but not up > to speed, ssh (and sftp by extension) aren't often tuned for high speed operation. Are you running with the HPN patch applied or a new enough FreeBSD that has the patch included? Samba and NFS are both likely to need tuning for multi-Gbps operation. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 11:06:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 22937482; Wed, 3 Jul 2013 11:06:33 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id E18091DE2; Wed, 3 Jul 2013 11:06:32 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id 10so4541251pdc.33 for ; Wed, 03 Jul 2013 04:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8NAoVxZicruPIWNq47O7qvhtyQTDBA3c+i5Hnl7aP/Y=; b=vClhI67/novkjRPrieIre61mqK3BzLbwfv7EukBV/c1lRL4C+ZDxa23uDPqmbwFyz5 iTFEidLzC6ECb0r2IlXAJytux6AXRurRq/CqMe+3UbuJAh6S6QccWJSNpgiMpK5uNrD6 Ls27Ex7Eug47JqQK4kWO8A7JYJ5Eni7E1DfUCaccTgAIOHwMP+mu52CJz0ERrvY2KgoJ dqi6bNJY7FC9AbV6FxA2WvheyxwbDLVhaL8tWtJDUG6MveY1nUEKp+DKL8tz5iNEhaEs mJu/vqNJYxox/bkZy2rMP6j6ySs8rIGrOmqArqwpZwjMTyv5xNlY9NXdG1TwQ5q5i1qG cFtA== MIME-Version: 1.0 X-Received: by 10.68.171.99 with SMTP id at3mr369438pbc.64.1372849592649; Wed, 03 Jul 2013 04:06:32 -0700 (PDT) Received: by 10.70.71.7 with HTTP; Wed, 3 Jul 2013 04:06:32 -0700 (PDT) In-Reply-To: <51D3A35C.8070305@freebsd.org> References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> <51D15D06.9030300@grosbein.net> <51D390CA.5020803@freebsd.org> <51D3A1A0.8090904@freebsd.org> <51D3A35C.8070305@freebsd.org> Date: Wed, 3 Jul 2013 14:06:32 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-ipfw , Eugene Grosbein , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 11:06:33 -0000 Hi Julian, I appreciate your willing to help me. My Situation in short is: ----------- [a] ------------------------- [b] ------------- internet B |---BGP---|84.xx.yy.1 192.168.0.1|-----|192.168.0.2/24 193.xx.yy.2| |Aem1 Cem3 D em0| | | neighbour ----------- ------------------------- | -------------- | | | [Q] | | your networks private network I Have control only over the middle machine, so i cant establish a tunnel. So I want it to act as MAN IN THE MIDDLE/ proxy. every packet comes from private network to 192.168.0.1 ie: packet hdr: src: 192.168.0.2 dst 192.168.0.1 should be translated as: packet hdr: src: 84.xx.yy.1 dst 193.xx.yy.2 ports and data untouched. and every packet from 193.xx.yy.2 (incoming/setup...) as: packet hdr: src: 193.xx.yy.2 dst: 84.xx.yy.1 to be translated as: packet hdr: src: 192.168.0.1 dst 192.168.0.2 btw: any other packet from src other than 193.xx.yy.2 to dst 84.xx.yy.1 should be dropped. Again thanks for you help, I hope I supplied all the info needed to help me. Sami On Wed, Jul 3, 2013 at 7:06 AM, Julian Elischer wrote: > On 7/3/13 11:59 AM, Julian Elischer wrote: > >> On 7/3/13 10:47 AM, Julian Elischer wrote: >> >>> On 7/2/13 10:21 PM, Sami Halabi wrote: >>> >>>> Hi again, >>>> So far no solution.... >>>> >>>> Is there really no alternative in FreeBSD? >>>> >>> >>> oh I'm sure there are several solutions.. >>> I looked at the original email but have since deleted it.. >>> >>> ah archives to the rescue.... >>> >>> ok so your request is a bit short on information.. >>> >> >> thinking about your request I think what you want to do is to make it >> look as if you have a web server or something at 192.168.0.1 to your >> neighbour, but to in fact serve those requests from a machine at >> 193.xxx.yyy.2. In addition, you need the requests to appear to come from >> your external address, so that the responses can find their way back to you. >> >> my next question is: Do you control 193.xxx.yyy.2? (is it FreeBSD?) >> because there are several ways you could solve that problem if you do, >> and it is.. >> basically by making a tunnel directly between that machine and you. >> >> if you want to not use a tunnel there are several steps on the way. >> we need to think abut what packets look like at each step. >> >> at em0, incoming >> >> packet A from neighbour, on the wire: >> To: 192.168.0.1 port 80 >> From: 192.168.0.x port MMM0 >> we want to change this packet. >> >> packet B from neighbour, on the wire: >> To: www.google.com port 80 >> From: 192.168.0.x port MMM1 >> we want to leave this packet alone (for now) >> >> At this stage, (on the incoming packet A on em0) >> we need to change the DESTINATION address, >> so we need a regular NAT, acting as if it were accepting an incoming >> connection. >> (which it is). >> >> so from the natd man page, the NAT 'rule' is: >> redirect_address 193.xxx.yyy.2 192.168.0.1 >> >> This must only happen on incoming packets from the neighbour, *addressed >> to you* so >> >> ipfw has a rule: >> ipfw add xx ${NAT_ACTION} ip from ${NEIGHBOUR_NET} to ${MY_NIGHBOUR_ADDR} >> in recv ${MY_NEIGHBOUR_IFACE} >> >> NAT_ACTION is either "nat 1" or "divert ${INTERNAL_DIVER_PORT} >> MY_NEIGHBOUR_ADDR="192.168.0.**0/24 " >> MY_NEIGHBOUR_IFACE="em0" >> >> now you need a rule to match this one for retranslation of return packets >> so on output you have: >> ipfw add yy ${NAT_ACTION} ip from 193.xxx.yyy.zzz to ${NEIGHBOUR_NET} out >> xmit ${MY_NEIGHBOUR_IFACE} >> >> and the nat must be set up to leave unmapped packets alone. >> so deny_incoming must NOT be set in the NAT configuration. >> > > I am talking all theoretically here as I don't have such a setup at the > moment, > and I can't remember if the packet direction is given to natd/ipfw-nat > if so then you MAY need the 'reverse' setting, but I don't guarantee it. > > If you use natd you will need a separae instance, or natd. If you use > ipfw internal nat > then you must use a separate nat instance there too. > > >> >> >> so theoretically this is the destination address taken care of (in >> outgoing packets, source address on incoming packets). >> >> So then you need to take care of the source address of the outgoing >> packets. >> this takes place on the INTERNET facing interface, and really, it should >> all be taken care of already if you have NAT enabled and you can ping the >> internet from the neighbour's net. >> >> >> hope this helps.... >> >> Julian >> >> >> >> >> > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 12:58:42 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BFE8969A; Wed, 3 Jul 2013 12:58:42 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6F51AA5; Wed, 3 Jul 2013 12:58:42 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id q10so72479pdj.38 for ; Wed, 03 Jul 2013 05:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JcqsUSgi6ujjlyb/oyccU2MUhBBRbIUfyu/b/7bxUJ4=; b=HiW1h5R0uPzoa4Y6EztaaLlecVTMhYPiBgBddQsVTKWd0KrWUtAH7l7eg/U4nz0luZ bSqVnU9HwHWB5sp+kV9/uCAK6jmp2VpElhhEH+LycSIjMGDDtwhYmHgXv2ZShkIWQS0d sTpMI9dXCeapUHBcwnXfXk7zIIdvxEA4L4JBq7xhlB4hb5ywOo3IkaJi/dJWhysDxt9X CWnGlQyX5JepNefXZFxkFcJTKnFhrmtQ4/M6OYy4FkjFL4j6L2rI4go8KpjjZ5PQUGGh tnkTKDgL9TKb9lWOOB1LIIkWdQV2JtM+x4sAN43m2a1PQ8CfaH8Pv/JDlhoUYQQYIcdG 3Nsg== MIME-Version: 1.0 X-Received: by 10.66.252.234 with SMTP id zv10mr2297422pac.186.1372856321497; Wed, 03 Jul 2013 05:58:41 -0700 (PDT) Received: by 10.66.216.169 with HTTP; Wed, 3 Jul 2013 05:58:41 -0700 (PDT) In-Reply-To: <51D3E5BC.1000604@freebsd.org> References: <51D3E5BC.1000604@freebsd.org> Date: Wed, 3 Jul 2013 08:58:41 -0400 Message-ID: Subject: Re: Terrible ix performance From: Outback Dingo To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 12:58:42 -0000 On Wed, Jul 3, 2013 at 4:50 AM, Lawrence Stewart wrote: > On 07/03/13 14:28, Outback Dingo wrote: > > Ive got a high end storage server here, iperf shows decent network io > > > > iperf -i 10 -t 20 -c 10.0.96.1 -w 2.5M -l 2.5M > > ------------------------------------------------------------ > > Client connecting to 10.0.96.1, TCP port 5001 > > TCP window size: 2.50 MByte (WARNING: requested 2.50 MByte) > > ------------------------------------------------------------ > > [ 3] local 10.0.96.2 port 34753 connected with 10.0.96.1 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-10.0 sec 9.78 GBytes 8.40 Gbits/sec > > [ 3] 10.0-20.0 sec 8.95 GBytes 7.69 Gbits/sec > > [ 3] 0.0-20.0 sec 18.7 GBytes 8.05 Gbits/sec > > Given that iperf exercises the ixgbe driver (ix), network path and TCP, > I would suggest that your subject is rather misleading ;) > > > the card has a 3 meter twinax cable from cisco connected to it, going > > through a fujitsu switch. We have tweaked various networking, and kernel > > sysctls, however from a sftp and nfs session i cant get better then > 100MBs > > from a zpool with 8 mirrored vdevs. We also have an identical box that > will > > get 1.4Gbs with a 1 meter cisco twinax cables that writes 2.4Gbs compared > > to reads only 1.4Gbs... > > I take it the RTT between both hosts is very low i.e. sub 1ms? > > > does anyone have an idea of what the bottle neck could be?? This is a > > shared storage array with dual LSI controllers connected to 32 drives via > > an enclosure, local dd and other tests show the zpool performs quite > well. > > however as soon as we introduce any type of protocol, sftp, samba, nfs > > performance plummets. Im quite puzzled and have run out of ideas. so now > > curiousity has me........ its loading the ix driver and working but not > up > > to speed, > > ssh (and sftp by extension) aren't often tuned for high speed operation. > Are you running with the HPN patch applied or a new enough FreeBSD that > has the patch included? Samba and NFS are both likely to need tuning for > multi-Gbps operation. > Running 9-STABLE as of 3 days ago, what are you referring to s i can validate i dont need to apply it as for tuning for NFS/SAMBA sambas configured with AIO, and sendfile, and there so much information on tuninig these things that its a bit hard to decipher whats right and not right > > Cheers, > Lawrence > _______________________________________________ > 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 Jul 3 13:05:31 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1D529BF9 for ; Wed, 3 Jul 2013 13:05:31 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id EF92E1B1F for ; Wed, 3 Jul 2013 13:05:30 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id rr13so95744pbb.6 for ; Wed, 03 Jul 2013 06:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=34YHoKuXz8H9RAPcJpAgGXpFfrWwaVi9KRSI4/SC+EM=; b=kZqhdNXvrXtgF2sTBr8tyeXK9azc1Z0/CzEF99GxtTxkdGSJLFX5V3Oevzec2AaBNk I85MWrt9xHSscgrEQuHcxDHHe5JUDMEm9frnL7xs/3J4ZRhVc1flgyGsifNx9N2qkVV4 MFWkXANuPkUzNPrDhIlLr1wHggaLs3w1Awv7cBlC4TXFz5cO1C8tI0ObeG+GVV+z6yQr BYSBUMUerWQuBz1DL/OuoyZ0p4caXXuCaPvcA/gwzflKNFsAD6sOKuSFrudxJa5JhV6s 4OESomiMid1F3ANzp9D4mQcSuqUx/RBx2Ak7oUkeAhtouW4lnt7u0m2x7csybHU0Xcu6 52IQ== MIME-Version: 1.0 X-Received: by 10.68.218.8 with SMTP id pc8mr780892pbc.115.1372856730603; Wed, 03 Jul 2013 06:05:30 -0700 (PDT) Received: by 10.66.216.169 with HTTP; Wed, 3 Jul 2013 06:05:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 09:05:30 -0400 Message-ID: Subject: Re: Terrible ix performance From: Outback Dingo To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 13:05:31 -0000 On Wed, Jul 3, 2013 at 2:00 AM, Jack Vogel wrote: > ix is just the device name, it is using the ixgbe driver. The driver should > print some kind of banner when it loads, what version of the OS and driver > are you using?? I have little experience testing nfs or samba so I am > not sure right off what might be the problem. > > Jack > > uname -a FreeBSD XXXX.XXX.net 9.1-STABLE FreeBSD 9.1-STABLE #0 r249621M: Thu Apr 18 08:46:50 UTC 2013 root@builder-9:/usr/obj/san/usr/src/sys/SAN-amd64 amd64 loader.conf kernel="kernel" bootfile="kernel" kernel_options="" kern.hz="20000" hw.est.msr_info="0" hw.hptrr.attach_generic="0" kern.maxfiles="65536" kern.maxfilesperproc="50000" kern.cam.boot_delay="8000" autoboot_delay="5" isboot_load="YES" zfs_load="YES" kern.geom.label.gptid.enable="0" kern.geom.label.gpt.enable="1" geom_multipath_load="YES" aio_load="yes" hw.ixgbe.enable_aim=0 # ZFS kernel tune vm.kmem_size="128000M" vfs.zfs.arc_min="124928M" vfs.zfs.arc_max="124928M" vfs.zfs.prefetch_disable="0" vfs.zfs.txg.timeout="5" vfs.zfs.vdev.max_pending="10" vfs.zfs.vdev.min_pending="4" vfs.zfs.write_limit_override="0" vfs.zfs.no_write_throttle="0" cat /etc/sysctl.conf # System tuning hw.intr_storm_threshold=9000 # Disable core dump kern.coredump=0 # System tuning kern.ipc.maxsockbuf=16777216 # System tuning kern.ipc.nmbclusters=262144 # System tuning kern.ipc.nmbjumbo9=131072 # System tuning kern.ipc.nmbjumbo16=65536 # System tuning kern.ipc.nmbjumbop=262144 # System tuning kern.ipc.somaxconn=8192 # System tuning kern.maxfiles=65536 # System tuning kern.maxfilesperproc=50000 # System tuning net.inet.icmp.icmplim=300 # System tuning net.inet.icmp.icmplim_output=1 # System tuning net.inet.tcp.delayed_ack=0 # System tuning net.inet.tcp.path_mtu_discovery=0 # System tuning net.inet.tcp.recvbuf_auto=1 # System tuning net.inet.tcp.recvbuf_inc=262144 # System tuning net.inet.tcp.recvbuf_max=4194304 # System tuning net.inet.tcp.recvspace=262144 # System tuning net.inet.tcp.rfc1323=1 # System tuning net.inet.tcp.sendbuf_auto=1 # System tuning net.inet.tcp.sendbuf_inc=262144 # System tuning net.inet.tcp.sendbuf_max=4194304 # System tuning net.inet.tcp.sendspace=262144 # System tuning net.inet.udp.maxdgram=57344 # System tuning net.inet.udp.recvspace=65536 # System tuning net.local.stream.recvspace=65536 # System tuning net.local.stream.sendspace=65536 On Tue, Jul 2, 2013 at 9:28 PM, Outback Dingo wrote: > Ive got a high end storage server here, iperf shows decent network io >> >> iperf -i 10 -t 20 -c 10.0.96.1 -w 2.5M -l 2.5M >> ------------------------------------------------------------ >> Client connecting to 10.0.96.1, TCP port 5001 >> TCP window size: 2.50 MByte (WARNING: requested 2.50 MByte) >> ------------------------------------------------------------ >> [ 3] local 10.0.96.2 port 34753 connected with 10.0.96.1 port 5001 >> [ ID] Interval Transfer Bandwidth >> [ 3] 0.0-10.0 sec 9.78 GBytes 8.40 Gbits/sec >> [ 3] 10.0-20.0 sec 8.95 GBytes 7.69 Gbits/sec >> [ 3] 0.0-20.0 sec 18.7 GBytes 8.05 Gbits/sec >> >> >> the card has a 3 meter twinax cable from cisco connected to it, going >> through a fujitsu switch. We have tweaked various networking, and kernel >> sysctls, however from a sftp and nfs session i cant get better then 100MBs >> from a zpool with 8 mirrored vdevs. We also have an identical box that >> will >> get 1.4Gbs with a 1 meter cisco twinax cables that writes 2.4Gbs compared >> to reads only 1.4Gbs... >> >> does anyone have an idea of what the bottle neck could be?? This is a >> shared storage array with dual LSI controllers connected to 32 drives via >> an enclosure, local dd and other tests show the zpool performs quite well. >> however as soon as we introduce any type of protocol, sftp, samba, nfs >> performance plummets. Im quite puzzled and have run out of ideas. so now >> curiousity has me........ its loading the ix driver and working but not up >> to speed, >> it is feasible it should be using the ixgbe driver?? >> >> ix0@pci0:2:0:0: class=0x020000 card=0x000c8086 chip=0x10fb8086 rev=0x01 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' >> class = network >> subclass = ethernet >> ix1@pci0:2:0:1: class=0x020000 card=0x000c8086 chip=0x10fb8086 rev=0x01 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' >> class = network >> subclass = ethernet >> _______________________________________________ >> 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 Jul 3 13:39:05 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0AD794CF for ; Wed, 3 Jul 2013 13:39:05 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 92E781CFC for ; Wed, 3 Jul 2013 13:39:04 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id E44627E81E; Wed, 3 Jul 2013 23:39:02 +1000 (EST) Message-ID: <51D42976.9020206@freebsd.org> Date: Wed, 03 Jul 2013 23:39:02 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: Outback Dingo Subject: Re: Terrible ix performance References: <51D3E5BC.1000604@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 13:39:05 -0000 On 07/03/13 22:58, Outback Dingo wrote: > On Wed, Jul 3, 2013 at 4:50 AM, Lawrence Stewart > wrote: > > On 07/03/13 14:28, Outback Dingo wrote: > > Ive got a high end storage server here, iperf shows decent network io > > > > iperf -i 10 -t 20 -c 10.0.96.1 -w 2.5M -l 2.5M > > ------------------------------------------------------------ > > Client connecting to 10.0.96.1, TCP port 5001 > > TCP window size: 2.50 MByte (WARNING: requested 2.50 MByte) > > ------------------------------------------------------------ > > [ 3] local 10.0.96.2 port 34753 connected with 10.0.96.1 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-10.0 sec 9.78 GBytes 8.40 Gbits/sec > > [ 3] 10.0-20.0 sec 8.95 GBytes 7.69 Gbits/sec > > [ 3] 0.0-20.0 sec 18.7 GBytes 8.05 Gbits/sec > > Given that iperf exercises the ixgbe driver (ix), network path and TCP, > I would suggest that your subject is rather misleading ;) > > > the card has a 3 meter twinax cable from cisco connected to it, going > > through a fujitsu switch. We have tweaked various networking, and > kernel > > sysctls, however from a sftp and nfs session i cant get better > then 100MBs > > from a zpool with 8 mirrored vdevs. We also have an identical box > that will > > get 1.4Gbs with a 1 meter cisco twinax cables that writes 2.4Gbs > compared > > to reads only 1.4Gbs... > > I take it the RTT between both hosts is very low i.e. sub 1ms? An answer to the above question would be useful. > > does anyone have an idea of what the bottle neck could be?? This is a > > shared storage array with dual LSI controllers connected to 32 > drives via > > an enclosure, local dd and other tests show the zpool performs > quite well. > > however as soon as we introduce any type of protocol, sftp, samba, nfs > > performance plummets. Im quite puzzled and have run out of ideas. > so now > > curiousity has me........ its loading the ix driver and working > but not up > > to speed, > > ssh (and sftp by extension) aren't often tuned for high speed operation. > Are you running with the HPN patch applied or a new enough FreeBSD that > has the patch included? Samba and NFS are both likely to need tuning for > multi-Gbps operation. > > > Running 9-STABLE as of 3 days ago, what are you referring to s i can > validate i dont need to apply it Ok so your SSH should have the HPN patch. > as for tuning for NFS/SAMBA sambas configured with AIO, and sendfile, > and there so much information > on tuninig these things that its a bit hard to decipher whats right and > not right Before looking at tuning, I'd suggest testing with a protocol that involves the disk but isn't as heavy weight as SSH/NFS/CIFS. FTP is the obvious choice. Set up an inetd-based FTP instance, serve a file large enough that it will take ~60s to transfer to the client and report back what data rates you get from 5 back-to-back transfer trials. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 14:14:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 39B45BB3 for ; Wed, 3 Jul 2013 14:14:25 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm5-vm5.bullet.mail.ne1.yahoo.com (nm5-vm5.bullet.mail.ne1.yahoo.com [98.138.91.227]) by mx1.freebsd.org (Postfix) with ESMTP id B86E01EF2 for ; Wed, 3 Jul 2013 14:14:24 +0000 (UTC) Received: from [98.138.90.51] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2013 14:14:18 -0000 Received: from [98.138.89.173] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2013 14:14:18 -0000 Received: from [127.0.0.1] by omp1029.mail.ne1.yahoo.com with NNFMP; 03 Jul 2013 14:14:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 145765.13979.bm@omp1029.mail.ne1.yahoo.com Received: (qmail 99285 invoked by uid 60001); 3 Jul 2013 14:14:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372860858; bh=s9wRKd22LzZuUdgUo7giQZjzjRCK+RX+hNzFDBZLD1w=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ESOTtkcs/xy1HuatBCf4s9Wve6tvJbj7AD7jw80sIqCyVwLAng8tUxwjYHybafuXEOq7LuJLOaZ6CTOCraNiJXZ+6FSH28rxENvy2rq9T36y9Ns6QfOoSM2a9pm6YmPJNWO6bg2WPKKWONhTSXVNsizOEU7h1kjmv743/JZrTGU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0ZizniBI7scbRHjUE/C66nk+zRMJILCOAUOlhi8lPAEtC8kcOxIy3nF9nuGyS/1tDYqWCDqWHMUjq7YOqNJhsvNjUyURI/KiNh9Lk/YGNrJVVAqdr91tXXW39FfnvL9P0tqNex9Fg9WoZosiCnjTbNQe1tK89tsi6suB6Jujomk= ; X-YMail-OSG: tzzSKGAVM1l7xnS4Ld3LxP7h897fEmU5lTbU4Jy7GUdRQKa lKQyQUNiTawqn8NcQ0_Rdei84f_p2lrGxjrH.HPrryMwqE4uHvzZxwd8EgsN CTTox34IgVwRPNug7m9vf1xAdiaPcKb1gYKjD4DJAd5vRyrD0moMFo4S6jnO mjlM.q_FxSmZU381iO8uIzg30EYjjdjvjUY7bVk_Qfmy5KyxpbKxC4LNidjK 6f56EdoDfZIFiECzNS6JBc1gpVbbotNG9Wq1JS_dxGvbYS2phgBFRZkO59NS kwPBOKSxi0DEFtUc0zLNl5bQ5KJXFxOBlY7PYymLM__jLoutsGkIcUkACxRg hNZgqqeOv6Kj6T1CiriUkHTdK8VRILWyVLfDFXk34vK9v4JaL3624xx8lzA8 u.a9Rh.BfQ_mJ3Q.6lD.7LRi.E_8.xDxCon8wFujCrD0vn2tjym..xGj7_o4 K6SwJAn4Q.Ld4hAEYMf2j.gdkzxt7EIb1OLd0yQKQHF1r0FVz9JL8bDPfw7e NPaNR4pSWahlETgysc1XLCw01J0D.sEK3osL3rpL9Ia5MCdoXYTuc6AirDvP hgia1qfrs5YH2hgPNg0v3TG6_UK5YrQPFprJFTaEbjLj9Ip6_W.xY Received: from [98.203.118.124] by web121604.mail.ne1.yahoo.com via HTTP; Wed, 03 Jul 2013 07:14:17 PDT X-Rocket-MIMEInfo: 002.001, DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT24gTW9uLCA3LzEvMTMsIFphcGhvZCBCZWVibGVicm94IDx6YmVlYmxlQGdtYWlsLmNvbT4gd3JvdGU6DQoNCiBTdWJqZWN0OiBSZTogSW5jb25zaXN0ZW50IE5JQyBiZWhhdmlvcg0KIFRvOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.DQogRGF0ZTogTW9uZGF5LCBKdWx5IDEsIDIwMTMsIDc6MzggUE0NCiANCiBPbiBTdW4sIEp1biAzMCwgMjAxMyBhdA0KIDEyOjA0IFBNLCBCYXJuZXkgQ28BMAEBAQE- X-Mailer: YahooMailClassic/231 YahooMailWebService/0.8.148.557 Message-ID: <1372860857.99080.YahooMailBasic@web121604.mail.ne1.yahoo.com> Date: Wed, 3 Jul 2013 07:14:17 -0700 (PDT) From: Barney Cordoba Subject: Re: Inconsistent NIC behavior To: Zaphod Beeblebrox In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 14:14:25 -0000 -------------------------------------------- On Mon, 7/1/13, Zaphod Beeblebrox wrote: Subject: Re: Inconsistent NIC behavior To: "Barney Cordoba" Date: Monday, July 1, 2013, 7:38 PM =20 On Sun, Jun 30, 2013 at 12:04 PM, Barney Cordoba wrote: =20 One particular annoyance with Freebsd is that different NICs have different dormant behavior. =20 =20 On this we agree.=20 =20 =20 For example em and igb both will show the link being active or not on boot whether the interface =20 has been UPed or not, while ixgbe and bce do not. =20 =20 =20 I think it's a worthy goal to have NICs work the same in this manner. It's very valuable to know that =20 a nic is connected without having to UP it. And an annoyance when =A0you fire up a new box with a =20 new nic that shows No Carrier when the link light is on. =20 I disagree here.=A0 If an interface is shutdown, it should give no link to the far end.=A0 I consider it an error that many FreeBSD NIC drivers cannot shutdown the link.=20 =20 ---------------------- I think thats a different issue. The ability to shut down a link could easi= ly be a "feature". However when you boot a machine, say with a 4 port NIC, having to "UP" them= all to see which one is=20 plugged in is simply a logistical disaster, particularly with admins with m= arginal skills. While shutting down a link may occasionally be useful, the preponderance of uses = would lean towards having some way of knowing when a nic is plugged into a switch regardless o= f whether it's been fully initialized. BC From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 21:34:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A1C4E6E for ; Wed, 3 Jul 2013 21:34:13 +0000 (UTC) (envelope-from upgrade@service.administrator.org) Received: from mx1.dcssrl.it (mx1.dcssrl.it [213.215.220.143]) by mx1.freebsd.org (Postfix) with ESMTP id 1B99D19C5 for ; Wed, 3 Jul 2013 21:34:12 +0000 (UTC) Received: from mx1.dcssrl.it (unknown [192.168.30.155]) by mx1.dcssrl.it (Postfix) with ESMTP id 6C2C875E745 for ; Wed, 3 Jul 2013 23:28:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at dcssrl.it Received: from mailuser1.dcssrl.it ([192.168.30.165]) by mx1.dcssrl.it (mx1.dcssrl.it [192.168.30.155]) (amavisd-new, port 10024) with ESMTP id 74ujcH7RzybM for ; Wed, 3 Jul 2013 23:28:20 +0200 (CEST) Received: from renejansen14.39e4c5178d5e4953892bdb524871f897.renejansen14.3261344107.useast.internal.cloudapp.net (unknown [137.117.65.126]) (Authenticated sender: elena@dcssrl.it) by mailuser1.dcssrl.it (Postfix) with ESMTPA id F2E15A459D5 for ; Wed, 3 Jul 2013 23:27:59 +0200 (CEST) MIME-Version: 1.0 Subject: Email Security Reset To: freebsd-net@freebsd.org From: "E-mail Administrator" Date: Wed, 03 Jul 2013 21:27:59 +0000 Message-Id: <20130703212822.6C2C875E745@mx1.dcssrl.it> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 21:34:13 -0000 Dear Subscriber: = Please, be informed that the email server has just been upgraded and your e= mail needs reset immediately through the Email Administrator's page. = This process is to keep your email functions updated and protected as alway= s. Click here to reset your email now Regards, = Email Administrator. Copyright 2013 =A9 Administrator=20 From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 23:06:48 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C07A649; Wed, 3 Jul 2013 23:06:48 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id F2D571D4A; Wed, 3 Jul 2013 23:06:47 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id 16so839149obc.40 for ; Wed, 03 Jul 2013 16:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gggR0eOzzLZsFSIJnliJMaJl5k4rI/QO0cKIU/o6u7o=; b=qv1YMP687X6eCdTBMq2nfnxxK6wP0botnQYocPIkomEXVjVY9Xb6JW2f6w1LOwa/qg y27K8heODqlY5d4nk14znoWWpBVLdUUlqrx8jC4YwBgKCS907Kc4nZX6zCvL3aDIsFuQ Izaki9XYBIWC29apoGJjpDtpgtf0YyJZ6ll8PqBFLsK4DXQUynmW0Z7wNehstNaIJ6R0 wMZdoa6zyuDX0Rszmlj/ofnhcf7XRqzHcxhPYn82VhFeLAIKJKPtJXrZFByMyaeAvtyx fYcqn9zZg2kSmFtwZVoim7Un+Fei3eqekdddWHkf1UxpJcZBc/BJp6pjEup1fjHn57ey JKFA== MIME-Version: 1.0 X-Received: by 10.60.145.173 with SMTP id sv13mr3183531oeb.63.1372892807558; Wed, 03 Jul 2013 16:06:47 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Wed, 3 Jul 2013 16:06:47 -0700 (PDT) In-Reply-To: <51D42976.9020206@freebsd.org> References: <51D3E5BC.1000604@freebsd.org> <51D42976.9020206@freebsd.org> Date: Wed, 3 Jul 2013 19:06:47 -0400 Message-ID: Subject: Re: Terrible ix performance From: Outback Dingo To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 23:06:48 -0000 On Wed, Jul 3, 2013 at 9:39 AM, Lawrence Stewart wrote: > On 07/03/13 22:58, Outback Dingo wrote: > > On Wed, Jul 3, 2013 at 4:50 AM, Lawrence Stewart > > wrote: > > > > On 07/03/13 14:28, Outback Dingo wrote: > > > Ive got a high end storage server here, iperf shows decent network > io > > > > > > iperf -i 10 -t 20 -c 10.0.96.1 -w 2.5M -l 2.5M > > > ------------------------------------------------------------ > > > Client connecting to 10.0.96.1, TCP port 5001 > > > TCP window size: 2.50 MByte (WARNING: requested 2.50 MByte) > > > ------------------------------------------------------------ > > > [ 3] local 10.0.96.2 port 34753 connected with 10.0.96.1 port 5001 > > > [ ID] Interval Transfer Bandwidth > > > [ 3] 0.0-10.0 sec 9.78 GBytes 8.40 Gbits/sec > > > [ 3] 10.0-20.0 sec 8.95 GBytes 7.69 Gbits/sec > > > [ 3] 0.0-20.0 sec 18.7 GBytes 8.05 Gbits/sec > > > > Given that iperf exercises the ixgbe driver (ix), network path and > TCP, > > I would suggest that your subject is rather misleading ;) > > > > > the card has a 3 meter twinax cable from cisco connected to it, > going > > > through a fujitsu switch. We have tweaked various networking, and > > kernel > > > sysctls, however from a sftp and nfs session i cant get better > > then 100MBs > > > from a zpool with 8 mirrored vdevs. We also have an identical box > > that will > > > get 1.4Gbs with a 1 meter cisco twinax cables that writes 2.4Gbs > > compared > > > to reads only 1.4Gbs... > > > > I take it the RTT between both hosts is very low i.e. sub 1ms? > > An answer to the above question would be useful. > > > > does anyone have an idea of what the bottle neck could be?? This > is a > > > shared storage array with dual LSI controllers connected to 32 > > drives via > > > an enclosure, local dd and other tests show the zpool performs > > quite well. > > > however as soon as we introduce any type of protocol, sftp, samba, > nfs > > > performance plummets. Im quite puzzled and have run out of ideas. > > so now > > > curiousity has me........ its loading the ix driver and working > > but not up > > > to speed, > > > > ssh (and sftp by extension) aren't often tuned for high speed > operation. > > Are you running with the HPN patch applied or a new enough FreeBSD > that > > has the patch included? Samba and NFS are both likely to need tuning > for > > multi-Gbps operation. > > > > > > Running 9-STABLE as of 3 days ago, what are you referring to s i can > > validate i dont need to apply it > > Ok so your SSH should have the HPN patch. > > > as for tuning for NFS/SAMBA sambas configured with AIO, and sendfile, > > and there so much information > > on tuninig these things that its a bit hard to decipher whats right and > > not right > > Before looking at tuning, I'd suggest testing with a protocol that > involves the disk but isn't as heavy weight as SSH/NFS/CIFS. FTP is the > obvious choice. Set up an inetd-based FTP instance, serve a file large > enough that it will take ~60s to transfer to the client and report back > what data rates you get from 5 back-to-back transfer trials. > > on the 1GB interface i get 100MB/s, on the 10GB interface i get 250MB/s via NFS on the 1GB Interface 1 get 112MB/s, on the 10GB interface i get ftp> put TEST3 53829697536 bytes sent in 01:56 (439.28 MiB/s) ftp> get TEST3 53829697536 bytes received in 01:21 (632.18 MiB/s) ftp> get TEST3 53829697536 bytes received in 01:37 (525.37 MiB/s) ftp> put TEST3 43474223104 bytes sent in 01:50 (376.35 MiB/s) ftp> put TEST3 local: TEST3 remote: TEST3 229 Entering Extended Passive Mode (|||10613|) 226 Transfer complete 43474223104 bytes sent in 01:41 (410.09 MiB/s) ftp> so still about 50% performance on 10GB Cheers, > Lawrence > From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 23:21:26 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 039F1EBD; Wed, 3 Jul 2013 23:21:26 +0000 (UTC) (envelope-from prvs=189683e577=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 783DE1E07; Wed, 3 Jul 2013 23:21:25 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004713063.msg; Thu, 04 Jul 2013 00:21:24 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 04 Jul 2013 00:21:24 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=189683e577=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Outback Dingo" , "Lawrence Stewart" References: <51D3E5BC.1000604@freebsd.org> <51D42976.9020206@freebsd.org> Subject: Re: Terrible ix performance Date: Thu, 4 Jul 2013 00:21:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Jul 2013 23:21:26 -0000 ----- Original Message ----- From: "Outback Dingo" To: "Lawrence Stewart" Cc: Sent: Thursday, July 04, 2013 12:06 AM Subject: Re: Terrible ix performance > On Wed, Jul 3, 2013 at 9:39 AM, Lawrence Stewart wrote: > >> On 07/03/13 22:58, Outback Dingo wrote: >> > On Wed, Jul 3, 2013 at 4:50 AM, Lawrence Stewart > > > wrote: >> > >> > On 07/03/13 14:28, Outback Dingo wrote: >> > > Ive got a high end storage server here, iperf shows decent network >> io >> > > >> > > iperf -i 10 -t 20 -c 10.0.96.1 -w 2.5M -l 2.5M >> > > ------------------------------------------------------------ >> > > Client connecting to 10.0.96.1, TCP port 5001 >> > > TCP window size: 2.50 MByte (WARNING: requested 2.50 MByte) >> > > ------------------------------------------------------------ >> > > [ 3] local 10.0.96.2 port 34753 connected with 10.0.96.1 port 5001 >> > > [ ID] Interval Transfer Bandwidth >> > > [ 3] 0.0-10.0 sec 9.78 GBytes 8.40 Gbits/sec >> > > [ 3] 10.0-20.0 sec 8.95 GBytes 7.69 Gbits/sec >> > > [ 3] 0.0-20.0 sec 18.7 GBytes 8.05 Gbits/sec >> > >> > Given that iperf exercises the ixgbe driver (ix), network path and >> TCP, >> > I would suggest that your subject is rather misleading ;) >> > >> > > the card has a 3 meter twinax cable from cisco connected to it, >> going >> > > through a fujitsu switch. We have tweaked various networking, and >> > kernel >> > > sysctls, however from a sftp and nfs session i cant get better >> > then 100MBs >> > > from a zpool with 8 mirrored vdevs. We also have an identical box >> > that will >> > > get 1.4Gbs with a 1 meter cisco twinax cables that writes 2.4Gbs >> > compared >> > > to reads only 1.4Gbs... >> > >> > I take it the RTT between both hosts is very low i.e. sub 1ms? >> >> An answer to the above question would be useful. >> >> > > does anyone have an idea of what the bottle neck could be?? This >> is a >> > > shared storage array with dual LSI controllers connected to 32 >> > drives via >> > > an enclosure, local dd and other tests show the zpool performs >> > quite well. >> > > however as soon as we introduce any type of protocol, sftp, samba, >> nfs >> > > performance plummets. Im quite puzzled and have run out of ideas. >> > so now >> > > curiousity has me........ its loading the ix driver and working >> > but not up >> > > to speed, >> > >> > ssh (and sftp by extension) aren't often tuned for high speed >> operation. >> > Are you running with the HPN patch applied or a new enough FreeBSD >> that >> > has the patch included? Samba and NFS are both likely to need tuning >> for >> > multi-Gbps operation. >> > >> > >> > Running 9-STABLE as of 3 days ago, what are you referring to s i can >> > validate i dont need to apply it >> >> Ok so your SSH should have the HPN patch. >> >> > as for tuning for NFS/SAMBA sambas configured with AIO, and sendfile, >> > and there so much information >> > on tuninig these things that its a bit hard to decipher whats right and >> > not right >> >> Before looking at tuning, I'd suggest testing with a protocol that >> involves the disk but isn't as heavy weight as SSH/NFS/CIFS. FTP is the >> obvious choice. Set up an inetd-based FTP instance, serve a file large >> enough that it will take ~60s to transfer to the client and report back >> what data rates you get from 5 back-to-back transfer trials. >> >> > on the 1GB interface i get 100MB/s, on the 10GB interface i get 250MB/s > via NFS > on the 1GB Interface 1 get 112MB/s, on the 10GB interface i get > > ftp> put TEST3 > 53829697536 bytes sent in 01:56 (439.28 MiB/s) > ftp> get TEST3 > 53829697536 bytes received in 01:21 (632.18 MiB/s) > ftp> get TEST3 > 53829697536 bytes received in 01:37 (525.37 MiB/s) > ftp> put TEST3 > 43474223104 bytes sent in 01:50 (376.35 MiB/s) > ftp> put TEST3 > local: TEST3 remote: TEST3 > 229 Entering Extended Passive Mode (|||10613|) > 226 Transfer complete > 43474223104 bytes sent in 01:41 (410.09 MiB/s) > ftp> > > so still about 50% performance on 10GB Out of interest have you tried limiting the number of queues? If not give it a try see if it helps, add the following to /boot/loader.conf: hw.ixgbe.num_queues=1 If nothing else will give you another data point. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 00:18:57 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD4676D7; Thu, 4 Jul 2013 00:18:57 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF3E102A; Thu, 4 Jul 2013 00:18:57 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n9so1088051oag.22 for ; Wed, 03 Jul 2013 17:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kBj3TwRKj9f06fy1aWRNUdVs6aVVWzEfVo0vUjt93EA=; b=Wu6ddogZR4vCnXcLV/Oq3+OAT18Obh8UqdMjGSR6GGETlYUuc092fJKc2JfK8GC9/Z 6ilMSQFRWh4/uF6Q4OFMc7lQrJZqh+CvN+SMLgfqSKyiV3CSVti4rxAiX1LwUI5sff5X ed3xm/bjTQfBz3nkSKgb5biBlSSg5AVnZIyFL9G/+BhXR5ZSolJvac1sDb4PcgoE+To6 jKBxK8t/jXzblqEYdLpSZCo+R08RQNNM1uYjFCZTPEeofA0YBECnE81bUtI5OVqLBPr+ fGWgm2Sm3WnbwT/H5HWBiutqz9QtFu+A8VDq/EKHmqoFvyTvQ7q07P6h/CG77LCmUAeA dKXw== MIME-Version: 1.0 X-Received: by 10.182.88.202 with SMTP id bi10mr3409868obb.91.1372897136996; Wed, 03 Jul 2013 17:18:56 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Wed, 3 Jul 2013 17:18:56 -0700 (PDT) In-Reply-To: References: <51D3E5BC.1000604@freebsd.org> <51D42976.9020206@freebsd.org> Date: Wed, 3 Jul 2013 17:18:56 -0700 X-Google-Sender-Auth: 3CIlW3vfEyvbBWxPjdUCtNA3vZg Message-ID: Subject: Re: Terrible ix performance From: Kevin Oberman To: Steven Hartland Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Outback Dingo , net@freebsd.org, Lawrence Stewart X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Jul 2013 00:18:57 -0000 On Wed, Jul 3, 2013 at 4:21 PM, Steven Hartland wrote: > > ----- Original Message ----- From: "Outback Dingo" > > To: "Lawrence Stewart" > Cc: > Sent: Thursday, July 04, 2013 12:06 AM > Subject: Re: Terrible ix performance > > > > On Wed, Jul 3, 2013 at 9:39 AM, Lawrence Stewart > >wrote: >> >> On 07/03/13 22:58, Outback Dingo wrote: >>> > On Wed, Jul 3, 2013 at 4:50 AM, Lawrence Stewart >> > > wrote: >>> > >>> > On 07/03/13 14:28, Outback Dingo wrote: >>> > > Ive got a high end storage server here, iperf shows decent >>> network >>> io >>> > > >>> > > iperf -i 10 -t 20 -c 10.0.96.1 -w 2.5M -l 2.5M >>> > > ------------------------------**------------------------------ >>> > > Client connecting to 10.0.96.1, TCP port 5001 >>> > > TCP window size: 2.50 MByte (WARNING: requested 2.50 MByte) >>> > > ------------------------------**------------------------------ >>> > > [ 3] local 10.0.96.2 port 34753 connected with 10.0.96.1 port >>> 5001 >>> > > [ ID] Interval Transfer Bandwidth >>> > > [ 3] 0.0-10.0 sec 9.78 GBytes 8.40 Gbits/sec >>> > > [ 3] 10.0-20.0 sec 8.95 GBytes 7.69 Gbits/sec >>> > > [ 3] 0.0-20.0 sec 18.7 GBytes 8.05 Gbits/sec >>> > >>> > Given that iperf exercises the ixgbe driver (ix), network path and >>> TCP, >>> > I would suggest that your subject is rather misleading ;) >>> > >>> > > the card has a 3 meter twinax cable from cisco connected to it, >>> going >>> > > through a fujitsu switch. We have tweaked various networking, and >>> > kernel >>> > > sysctls, however from a sftp and nfs session i cant get better >>> > then 100MBs >>> > > from a zpool with 8 mirrored vdevs. We also have an identical box >>> > that will >>> > > get 1.4Gbs with a 1 meter cisco twinax cables that writes 2.4Gbs >>> > compared >>> > > to reads only 1.4Gbs... >>> > >>> > I take it the RTT between both hosts is very low i.e. sub 1ms? >>> >>> An answer to the above question would be useful. >>> >>> > > does anyone have an idea of what the bottle neck could be?? This >>> is a >>> > > shared storage array with dual LSI controllers connected to 32 >>> > drives via >>> > > an enclosure, local dd and other tests show the zpool performs >>> > quite well. >>> > > however as soon as we introduce any type of protocol, sftp, >>> samba, >>> nfs >>> > > performance plummets. Im quite puzzled and have run out of ideas. >>> > so now >>> > > curiousity has me........ its loading the ix driver and working >>> > but not up >>> > > to speed, >>> > >>> > ssh (and sftp by extension) aren't often tuned for high speed >>> operation. >>> > Are you running with the HPN patch applied or a new enough FreeBSD >>> that >>> > has the patch included? Samba and NFS are both likely to need >>> tuning >>> for >>> > multi-Gbps operation. >>> > >>> > >>> > Running 9-STABLE as of 3 days ago, what are you referring to s i can >>> > validate i dont need to apply it >>> >>> Ok so your SSH should have the HPN patch. >>> >>> > as for tuning for NFS/SAMBA sambas configured with AIO, and sendfile, >>> > and there so much information >>> > on tuninig these things that its a bit hard to decipher whats right and >>> > not right >>> >>> Before looking at tuning, I'd suggest testing with a protocol that >>> involves the disk but isn't as heavy weight as SSH/NFS/CIFS. FTP is the >>> obvious choice. Set up an inetd-based FTP instance, serve a file large >>> enough that it will take ~60s to transfer to the client and report back >>> what data rates you get from 5 back-to-back transfer trials. >>> >>> >>> on the 1GB interface i get 100MB/s, on the 10GB interface i get 250MB/s >> via NFS >> on the 1GB Interface 1 get 112MB/s, on the 10GB interface i get >> >> ftp> put TEST3 >> 53829697536 bytes sent in 01:56 (439.28 MiB/s) >> ftp> get TEST3 >> 53829697536 bytes received in 01:21 (632.18 MiB/s) >> ftp> get TEST3 >> 53829697536 bytes received in 01:37 (525.37 MiB/s) >> ftp> put TEST3 >> 43474223104 bytes sent in 01:50 (376.35 MiB/s) >> ftp> put TEST3 >> local: TEST3 remote: TEST3 >> 229 Entering Extended Passive Mode (|||10613|) >> 226 Transfer complete >> 43474223104 bytes sent in 01:41 (410.09 MiB/s) >> ftp> >> >> so still about 50% performance on 10GB >> > > Out of interest have you tried limiting the number of queues? > > If not give it a try see if it helps, add the following to > /boot/loader.conf: > hw.ixgbe.num_queues=1 > > If nothing else will give you another data point. > > Regards > Steve > > ==============================**================== > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of misdirection, > the recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > You might also try SIFTR to analyze the behavior and perhaps even figure out what the limiting factor might be. kldload siftr See "Run-time Configuration" in the siftr(4) man page for details. I'm a little surprised Lawrence didn't already suggest this as he is one of the authors. (The "Bugs" section is rather long and he might know that it won't be useful in this case, but it has greatly helped me look at performance issues.) -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 02:01:35 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D0F8C9F for ; Thu, 4 Jul 2013 02:01:35 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id C77F61341 for ; Thu, 4 Jul 2013 02:01:34 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 059727E81E; Thu, 4 Jul 2013 12:01:31 +1000 (EST) Message-ID: <51D4D77B.60804@freebsd.org> Date: Thu, 04 Jul 2013 12:01:31 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130521 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: Terrible ix performance References: <51D3E5BC.1000604@freebsd.org> <51D42976.9020206@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: Outback Dingo , Steven Hartland , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Jul 2013 02:01:35 -0000 On 07/04/13 10:18, Kevin Oberman wrote: > On Wed, Jul 3, 2013 at 4:21 PM, Steven Hartland wrote: > >> >> ----- Original Message ----- From: "Outback Dingo" >> >> To: "Lawrence Stewart" >> Cc: >> Sent: Thursday, July 04, 2013 12:06 AM >> Subject: Re: Terrible ix performance >> >> >> >> On Wed, Jul 3, 2013 at 9:39 AM, Lawrence Stewart >>> wrote: >>> >>> On 07/03/13 22:58, Outback Dingo wrote: >>>>> On Wed, Jul 3, 2013 at 4:50 AM, Lawrence Stewart >>>> > wrote: >>>>> >>>>> On 07/03/13 14:28, Outback Dingo wrote: >>>>> > Ive got a high end storage server here, iperf shows decent >>>> network >>>> io >>>>> > >>>>> > iperf -i 10 -t 20 -c 10.0.96.1 -w 2.5M -l 2.5M >>>>> > ------------------------------**------------------------------ >>>>> > Client connecting to 10.0.96.1, TCP port 5001 >>>>> > TCP window size: 2.50 MByte (WARNING: requested 2.50 MByte) >>>>> > ------------------------------**------------------------------ >>>>> > [ 3] local 10.0.96.2 port 34753 connected with 10.0.96.1 port >>>> 5001 >>>>> > [ ID] Interval Transfer Bandwidth >>>>> > [ 3] 0.0-10.0 sec 9.78 GBytes 8.40 Gbits/sec >>>>> > [ 3] 10.0-20.0 sec 8.95 GBytes 7.69 Gbits/sec >>>>> > [ 3] 0.0-20.0 sec 18.7 GBytes 8.05 Gbits/sec >>>>> >>>>> Given that iperf exercises the ixgbe driver (ix), network path and >>>> TCP, >>>>> I would suggest that your subject is rather misleading ;) >>>>> >>>>> > the card has a 3 meter twinax cable from cisco connected to it, >>>> going >>>>> > through a fujitsu switch. We have tweaked various networking, and >>>>> kernel >>>>> > sysctls, however from a sftp and nfs session i cant get better >>>>> then 100MBs >>>>> > from a zpool with 8 mirrored vdevs. We also have an identical box >>>>> that will >>>>> > get 1.4Gbs with a 1 meter cisco twinax cables that writes 2.4Gbs >>>>> compared >>>>> > to reads only 1.4Gbs... >>>>> >>>>> I take it the RTT between both hosts is very low i.e. sub 1ms? >>>> >>>> An answer to the above question would be useful. >>>> >>>>> > does anyone have an idea of what the bottle neck could be?? This >>>> is a >>>>> > shared storage array with dual LSI controllers connected to 32 >>>>> drives via >>>>> > an enclosure, local dd and other tests show the zpool performs >>>>> quite well. >>>>> > however as soon as we introduce any type of protocol, sftp, >>>> samba, >>>> nfs >>>>> > performance plummets. Im quite puzzled and have run out of ideas. >>>>> so now >>>>> > curiousity has me........ its loading the ix driver and working >>>>> but not up >>>>> > to speed, >>>>> >>>>> ssh (and sftp by extension) aren't often tuned for high speed >>>> operation. >>>>> Are you running with the HPN patch applied or a new enough FreeBSD >>>> that >>>>> has the patch included? Samba and NFS are both likely to need >>>> tuning >>>> for >>>>> multi-Gbps operation. >>>>> >>>>> >>>>> Running 9-STABLE as of 3 days ago, what are you referring to s i can >>>>> validate i dont need to apply it >>>> >>>> Ok so your SSH should have the HPN patch. >>>> >>>>> as for tuning for NFS/SAMBA sambas configured with AIO, and sendfile, >>>>> and there so much information >>>>> on tuninig these things that its a bit hard to decipher whats right and >>>>> not right >>>> >>>> Before looking at tuning, I'd suggest testing with a protocol that >>>> involves the disk but isn't as heavy weight as SSH/NFS/CIFS. FTP is the >>>> obvious choice. Set up an inetd-based FTP instance, serve a file large >>>> enough that it will take ~60s to transfer to the client and report back >>>> what data rates you get from 5 back-to-back transfer trials. >>>> >>>> >>>> on the 1GB interface i get 100MB/s, on the 10GB interface i get 250MB/s >>> via NFS >>> on the 1GB Interface 1 get 112MB/s, on the 10GB interface i get >>> >>> ftp> put TEST3 >>> 53829697536 bytes sent in 01:56 (439.28 MiB/s) >>> ftp> get TEST3 >>> 53829697536 bytes received in 01:21 (632.18 MiB/s) >>> ftp> get TEST3 >>> 53829697536 bytes received in 01:37 (525.37 MiB/s) >>> ftp> put TEST3 >>> 43474223104 bytes sent in 01:50 (376.35 MiB/s) >>> ftp> put TEST3 >>> local: TEST3 remote: TEST3 >>> 229 Entering Extended Passive Mode (|||10613|) >>> 226 Transfer complete >>> 43474223104 bytes sent in 01:41 (410.09 MiB/s) >>> ftp> >>> >>> so still about 50% performance on 10GB >>> >> >> Out of interest have you tried limiting the number of queues? >> >> If not give it a try see if it helps, add the following to >> /boot/loader.conf: >> hw.ixgbe.num_queues=1 >> >> If nothing else will give you another data point. As noted in my first post to this thread, if iperf is able to push a single flow at 8Gbps, then the NIC is unlikely to be the source of the problem and trying to tune it is a waste of time (at least at this stage). iperf tests memory-network-memory transfer speed without any disk involvement, so the fact that it can get 8Gbps and ftp is getting around 4Gbps implies that either the iperf TCP tuning is better (only likely to be relevant if the RTT is very large - Outback Dingo you still haven't provided us with the RTT) or the disk subsystem at one or both ends is slowing things down. Outback Dingo: can you please run another iperf test without the -w switch on both client and server to see if your send/receive window autotuning on both ends is working. If all is well, you should see the same results of ~8Gbps. >> You might also try SIFTR to analyze the behavior and perhaps even figure > out what the limiting factor might be. > > kldload siftr > See "Run-time Configuration" in the siftr(4) man page for details. > > I'm a little surprised Lawrence didn't already suggest this as he is one of > the authors. (The "Bugs" section is rather long and he might know that it > won't be useful in this case, but it has greatly helped me look at > performance issues.) siftr is useful if you suspect a TCP/netstack tuning issue. Given that iperf gets good results and the OP's tuning settings should be adequate to achieve good performance if the RTT is low (4MB sendbuf_max/recvbuf_max), I suspect the disk subsystem and/or VM is more likely to be the issue i.e. siftr data is probably irrelevant. Outback Dingo: Can you confirm you have appropriate tuning on both sides of the connection? You didn't specify if the loader.conf/sysctl.conf parameters you provided in the reply to Jack are only on one side of the connection or both. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 03:06:22 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3EA21887; Thu, 4 Jul 2013 03:06:22 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id EF9CC1858; Thu, 4 Jul 2013 03:06:21 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id n10so1260183oag.0 for ; Wed, 03 Jul 2013 20:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4mAS8iou3x/JUMnhvdMSU3I+fD7wnQhl3rJ0FMbL8Ow=; b=vupbASr8Rhk2i8O4Pjl/VPfv+KuGuSAuRU0FSIiVt9X2zpzehDYaJGpDo184B93BGV 9eIy59EEECOttMtMeM180EmkHILele2T2AQKTgr1CtE1YOjaV3CdGSFXljpFWWUYOc7D eRyx8iLN4AysiBnBpS54sAGbp4ScVbs660JPrgdP97eyTCUEec5nC8L0JyLoQnptTk3I gBRltaPeCNxz55pMnCzqbA5I/A8F2+cEpufvZy4uKTX0p9jJ4Y++TTUSeXnT5ncbFQBw NTf8hA/8Bu+sbn4jy0/XJqaedAoD6YvBhSSjVSV22py1e4atKXXCbcA4PTh71hzJy2sF 1K9A== MIME-Version: 1.0 X-Received: by 10.182.61.73 with SMTP id n9mr3855011obr.86.1372907181483; Wed, 03 Jul 2013 20:06:21 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Wed, 3 Jul 2013 20:06:21 -0700 (PDT) In-Reply-To: <51D4D77B.60804@freebsd.org> References: <51D3E5BC.1000604@freebsd.org> <51D42976.9020206@freebsd.org> <51D4D77B.60804@freebsd.org> Date: Wed, 3 Jul 2013 23:06:21 -0400 Message-ID: Subject: Re: Terrible ix performance From: Outback Dingo To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Kevin Oberman , Steven Hartland , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Jul 2013 03:06:22 -0000 On Wed, Jul 3, 2013 at 10:01 PM, Lawrence Stewart wrote: > On 07/04/13 10:18, Kevin Oberman wrote: > > On Wed, Jul 3, 2013 at 4:21 PM, Steven Hartland >wrote: > > > >> > >> ----- Original Message ----- From: "Outback Dingo" < > outbackdingo@gmail.com > >>> > >> To: "Lawrence Stewart" > >> Cc: > >> Sent: Thursday, July 04, 2013 12:06 AM > >> Subject: Re: Terrible ix performance > >> > >> > >> > >> On Wed, Jul 3, 2013 at 9:39 AM, Lawrence Stewart >>>> wrote: > >>> > >>> On 07/03/13 22:58, Outback Dingo wrote: > >>>>> On Wed, Jul 3, 2013 at 4:50 AM, Lawrence Stewart < > lstewart@freebsd.org > >>>>> > wrote: > >>>>> > >>>>> On 07/03/13 14:28, Outback Dingo wrote: > >>>>> > Ive got a high end storage server here, iperf shows decent > >>>> network > >>>> io > >>>>> > > >>>>> > iperf -i 10 -t 20 -c 10.0.96.1 -w 2.5M -l 2.5M > >>>>> > ------------------------------**------------------------------ > >>>>> > Client connecting to 10.0.96.1, TCP port 5001 > >>>>> > TCP window size: 2.50 MByte (WARNING: requested 2.50 MByte) > >>>>> > ------------------------------**------------------------------ > >>>>> > [ 3] local 10.0.96.2 port 34753 connected with 10.0.96.1 port > >>>> 5001 > >>>>> > [ ID] Interval Transfer Bandwidth > >>>>> > [ 3] 0.0-10.0 sec 9.78 GBytes 8.40 Gbits/sec > >>>>> > [ 3] 10.0-20.0 sec 8.95 GBytes 7.69 Gbits/sec > >>>>> > [ 3] 0.0-20.0 sec 18.7 GBytes 8.05 Gbits/sec > >>>>> > >>>>> Given that iperf exercises the ixgbe driver (ix), network path > and > >>>> TCP, > >>>>> I would suggest that your subject is rather misleading ;) > >>>>> > >>>>> > the card has a 3 meter twinax cable from cisco connected to it, > >>>> going > >>>>> > through a fujitsu switch. We have tweaked various networking, > and > >>>>> kernel > >>>>> > sysctls, however from a sftp and nfs session i cant get better > >>>>> then 100MBs > >>>>> > from a zpool with 8 mirrored vdevs. We also have an identical > box > >>>>> that will > >>>>> > get 1.4Gbs with a 1 meter cisco twinax cables that writes > 2.4Gbs > >>>>> compared > >>>>> > to reads only 1.4Gbs... > >>>>> > >>>>> I take it the RTT between both hosts is very low i.e. sub 1ms? > >>>> > >>>> An answer to the above question would be useful. > >>>> > >>>>> > does anyone have an idea of what the bottle neck could be?? > This > >>>> is a > >>>>> > shared storage array with dual LSI controllers connected to 32 > >>>>> drives via > >>>>> > an enclosure, local dd and other tests show the zpool performs > >>>>> quite well. > >>>>> > however as soon as we introduce any type of protocol, sftp, > >>>> samba, > >>>> nfs > >>>>> > performance plummets. Im quite puzzled and have run out of > ideas. > >>>>> so now > >>>>> > curiousity has me........ its loading the ix driver and working > >>>>> but not up > >>>>> > to speed, > >>>>> > >>>>> ssh (and sftp by extension) aren't often tuned for high speed > >>>> operation. > >>>>> Are you running with the HPN patch applied or a new enough > FreeBSD > >>>> that > >>>>> has the patch included? Samba and NFS are both likely to need > >>>> tuning > >>>> for > >>>>> multi-Gbps operation. > >>>>> > >>>>> > >>>>> Running 9-STABLE as of 3 days ago, what are you referring to s i can > >>>>> validate i dont need to apply it > >>>> > >>>> Ok so your SSH should have the HPN patch. > >>>> > >>>>> as for tuning for NFS/SAMBA sambas configured with AIO, and sendfile, > >>>>> and there so much information > >>>>> on tuninig these things that its a bit hard to decipher whats right > and > >>>>> not right > >>>> > >>>> Before looking at tuning, I'd suggest testing with a protocol that > >>>> involves the disk but isn't as heavy weight as SSH/NFS/CIFS. FTP is > the > >>>> obvious choice. Set up an inetd-based FTP instance, serve a file large > >>>> enough that it will take ~60s to transfer to the client and report > back > >>>> what data rates you get from 5 back-to-back transfer trials. > >>>> > >>>> > >>>> on the 1GB interface i get 100MB/s, on the 10GB interface i get > 250MB/s > >>> via NFS > >>> on the 1GB Interface 1 get 112MB/s, on the 10GB interface i get > >>> > >>> ftp> put TEST3 > >>> 53829697536 bytes sent in 01:56 (439.28 MiB/s) > >>> ftp> get TEST3 > >>> 53829697536 bytes received in 01:21 (632.18 MiB/s) > >>> ftp> get TEST3 > >>> 53829697536 bytes received in 01:37 (525.37 MiB/s) > >>> ftp> put TEST3 > >>> 43474223104 bytes sent in 01:50 (376.35 MiB/s) > >>> ftp> put TEST3 > >>> local: TEST3 remote: TEST3 > >>> 229 Entering Extended Passive Mode (|||10613|) > >>> 226 Transfer complete > >>> 43474223104 bytes sent in 01:41 (410.09 MiB/s) > >>> ftp> > >>> > >>> so still about 50% performance on 10GB > >>> > >> > >> Out of interest have you tried limiting the number of queues? > >> > >> If not give it a try see if it helps, add the following to > >> /boot/loader.conf: > >> hw.ixgbe.num_queues=1 > >> > >> If nothing else will give you another data point. > > As noted in my first post to this thread, if iperf is able to push a > single flow at 8Gbps, then the NIC is unlikely to be the source of the > problem and trying to tune it is a waste of time (at least at this stage). > > iperf tests memory-network-memory transfer speed without any disk > involvement, so the fact that it can get 8Gbps and ftp is getting around > 4Gbps implies that either the iperf TCP tuning is better (only likely to > be relevant if the RTT is very large - Outback Dingo you still haven't > provided us with the RTT) or the disk subsystem at one or both ends is > slowing things down. > > Outback Dingo: can you please run another iperf test without the -w > switch on both client and server to see if your send/receive window > autotuning on both ends is working. If all is well, you should see the > same results of ~8Gbps. > > >> You might also try SIFTR to analyze the behavior and perhaps even figure > > out what the limiting factor might be. > > > > kldload siftr > > See "Run-time Configuration" in the siftr(4) man page for details. > > > > I'm a little surprised Lawrence didn't already suggest this as he is one > of > > the authors. (The "Bugs" section is rather long and he might know that it > > won't be useful in this case, but it has greatly helped me look at > > performance issues.) > > siftr is useful if you suspect a TCP/netstack tuning issue. Given that > iperf gets good results and the OP's tuning settings should be adequate > to achieve good performance if the RTT is low (4MB > sendbuf_max/recvbuf_max), I suspect the disk subsystem and/or VM is more > likely to be the issue i.e. siftr data is probably irrelevant. > > Outback Dingo: Can you confirm you have appropriate tuning on both sides > of the connection? You didn't specify if the loader.conf/sysctl.conf > parameters you provided in the reply to Jack are only on one side of the > connection or both. > > Yeah i concur, im starting to think the bottleneck is the zpool iperf -i 10 -t 20 -c 10.10.1.11 -l 2.5M ------------------------------------------------------------ Client connecting to 10.10.1.11, TCP port 5001 TCP window size: 257 KByte (default) ------------------------------------------------------------ [ 3] local 10.10.1.178 port 47360 connected with 10.10.1.11 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 9.61 GBytes 8.26 Gbits/sec [ 3] 10.0-20.0 sec 8.83 GBytes 7.58 Gbits/sec [ 3] 0.0-20.0 sec 18.4 GBytes 7.92 Gbits/sec nas4free: /testing # iperf -i 10 -t 20 -c 10.10.1.11 -l 2.5M ------------------------------------------------------------ Client connecting to 10.10.1.11, TCP port 5001 TCP window size: 257 KByte (default) ------------------------------------------------------------ [ 3] local 10.10.1.178 port 37691 connected with 10.10.1.11 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 5.29 GBytes 4.54 Gbits/sec [ 3] 10.0-20.0 sec 8.06 GBytes 6.93 Gbits/sec [ 3] 0.0-20.0 sec 13.4 GBytes 5.73 Gbits/sec nas4free: /testing # iperf -i 10 -t 20 -c 10.10.1.11 -l 2.5M ------------------------------------------------------------ Client connecting to 10.10.1.11, TCP port 5001 TCP window size: 257 KByte (default) ------------------------------------------------------------ [ 3] local 10.10.1.178 port 17560 connected with 10.10.1.11 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 9.48 GBytes 8.14 Gbits/sec [ 3] 10.0-20.0 sec 8.68 GBytes 7.46 Gbits/sec [ 3] 0.0-20.0 sec 18.2 GBytes 7.80 Gbits/sec nas4free: /testing # iperf -i 10 -t 20 -c 10.10.1.11 -l 2.5M ------------------------------------------------------------ Client connecting to 10.10.1.11, TCP port 5001 TCP window size: 257 KByte (default) ------------------------------------------------------------ [ 3] local 10.10.1.178 port 14729 connected with 10.10.1.11 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 7.81 GBytes 6.71 Gbits/sec [ 3] 10.0-20.0 sec 9.11 GBytes 7.82 Gbits/sec [ 3] 0.0-20.0 sec 16.9 GBytes 7.27 Gbits/sec The current configuration on both boxes is kernel="kernel" bootfile="kernel" kernel_options="" kern.hz="20000" hw.est.msr_info="0" hw.hptrr.attach_generic="0" kern.maxfiles="65536" kern.maxfilesperproc="50000" kern.cam.boot_delay="8000" autoboot_delay="5" isboot_load="YES" zfs_load="YES" hw.ixgbe.enable_aim=0 and cat /etc/sysctl.conf # Disable core dump kern.coredump=0 # System tuning net.inet.tcp.delayed_ack=0 # System tuning net.inet.tcp.rfc1323=1 # System tuning net.inet.tcp.sendspace=262144 # System tuning net.inet.tcp.recvspace=262144 # System tuning net.inet.tcp.sendbuf_max=4194304 # System tuning net.inet.tcp.sendbuf_inc=262144 # System tuning net.inet.tcp.sendbuf_auto=1 # System tuning net.inet.tcp.recvbuf_max=4194304 # System tuning net.inet.tcp.recvbuf_inc=262144 # System tuning net.inet.tcp.recvbuf_auto=1 # System tuning net.inet.udp.recvspace=65536 # System tuning net.inet.udp.maxdgram=57344 # System tuning net.local.stream.recvspace=65536 # System tuning net.local.stream.sendspace=65536 # System tuning kern.ipc.maxsockbuf=16777216 # System tuning kern.ipc.somaxconn=8192 # System tuning kern.ipc.nmbclusters=262144 # System tuning kern.ipc.nmbjumbop=262144 # System tuning kern.ipc.nmbjumbo9=131072 # System tuning kern.ipc.nmbjumbo16=65536 # System tuning kern.maxfiles=65536 # System tuning kern.maxfilesperproc=50000 # System tuning net.inet.icmp.icmplim=300 # System tuning net.inet.icmp.icmplim_output=1 # System tuning net.inet.tcp.path_mtu_discovery=0 # System tuning hw.intr_storm_threshold=9000 Box A is zpool status pool: testing state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM testing ONLINE 0 0 0 da0.nop ONLINE 0 0 0 da1.nop ONLINE 0 0 0 da2.nop ONLINE 0 0 0 da3.nop ONLINE 0 0 0 da4.nop ONLINE 0 0 0 da5.nop ONLINE 0 0 0 da6.nop ONLINE 0 0 0 da7.nop ONLINE 0 0 0 da8.nop ONLINE 0 0 0 da9.nop ONLINE 0 0 0 da10.nop ONLINE 0 0 0 da11.nop ONLINE 0 0 0 da12.nop ONLINE 0 0 0 da13.nop ONLINE 0 0 0 da14.nop ONLINE 0 0 0 da15.nop ONLINE 0 0 0 fio --direct=1 --rw=randwrite --bs=4k --size=2G --numjobs=1 --runtime=60 --group_reporting --name=randwrite fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning. randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1 fio-2.0.15 Starting 1 process Jobs: 1 (f=1): [w] [100.0% done] [0K/150.9M/0K /s] [0 /38.7K/0 iops] [eta 00m:00s] randwrite: (groupid=0, jobs=1): err= 0: pid=101192: Wed Jul 3 23:01:09 2013 write: io=2048.0MB, bw=147916KB/s, iops=36978 , runt= 14178msec clat (usec): min=9 , max=122101 , avg=24.17, stdev=229.23 lat (usec): min=10 , max=122101 , avg=24.42, stdev=229.23 clat percentiles (usec): | 1.00th=[ 11], 5.00th=[ 12], 10.00th=[ 14], 20.00th=[ 21], | 30.00th=[ 21], 40.00th=[ 22], 50.00th=[ 22], 60.00th=[ 23], | 70.00th=[ 23], 80.00th=[ 24], 90.00th=[ 29], 95.00th=[ 35], | 99.00th=[ 99], 99.50th=[ 114], 99.90th=[ 131], 99.95th=[ 137], | 99.99th=[ 181] bw (KB/s) : min=58200, max=223112, per=99.93%, avg=147815.61, stdev=31976.97 lat (usec) : 10=0.01%, 20=15.49%, 50=82.15%, 100=1.39%, 250=0.96% lat (usec) : 500=0.01%, 750=0.01%, 1000=0.01% lat (msec) : 2=0.01%, 20=0.01%, 250=0.01% cpu : usr=11.05%, sys=87.08%, ctx=563, majf=0, minf=0 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued : total=r=0/w=524288/d=0, short=r=0/w=0/d=0 Run status group 0 (all jobs): WRITE: io=2048.0MB, aggrb=147915KB/s, minb=147915KB/s, maxb=147915KB/s, mint=14178msec, maxt=14178msec fio --direct=1 --rw=randread --bs=4k --size=2G --numjobs=1 --runtime=60 --group_reporting --name=randread fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning. randread: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1 fio-2.0.15 Starting 1 process randread: Laying out IO file(s) (1 file(s) / 2048MB) Jobs: 1 (f=1): [r] [100.0% done] [292.9M/0K/0K /s] [74.1K/0 /0 iops] [eta 00m:00s] randread: (groupid=0, jobs=1): err= 0: pid=101304: Wed Jul 3 23:02:08 2013 read : io=2048.0MB, bw=327578KB/s, iops=81894 , runt= 6402msec clat (usec): min=4 , max=20418 , avg=10.15, stdev=28.54 lat (usec): min=4 , max=20418 , avg=10.27, stdev=28.54 clat percentiles (usec): | 1.00th=[ 5], 5.00th=[ 6], 10.00th=[ 6], 20.00th=[ 8], | 30.00th=[ 10], 40.00th=[ 10], 50.00th=[ 10], 60.00th=[ 11], | 70.00th=[ 11], 80.00th=[ 11], 90.00th=[ 12], 95.00th=[ 13], | 99.00th=[ 22], 99.50th=[ 31], 99.90th=[ 77], 99.95th=[ 95], | 99.99th=[ 145] bw (KB/s) : min=290024, max=520016, per=100.00%, avg=328490.00, stdev=63941.66 lat (usec) : 10=28.85%, 20=69.83%, 50=1.19%, 100=0.09%, 250=0.05% lat (msec) : 50=0.01% cpu : usr=18.08%, sys=81.57%, ctx=144, majf=0, minf=1 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued : total=r=524288/w=0/d=0, short=r=0/w=0/d=0 Run status group 0 (all jobs): READ: io=2048.0MB, aggrb=327577KB/s, minb=327577KB/s, maxb=327577KB/s, mint=6402msec, maxt=6402msec Box B zpool status pool: backup state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM backup ONLINE 0 0 0 mfid0.nop ONLINE 0 0 0 mfid1.nop ONLINE 0 0 0 mfid2.nop ONLINE 0 0 0 mfid3.nop ONLINE 0 0 0 mfid4.nop ONLINE 0 0 0 mfid5.nop ONLINE 0 0 0 mfid6.nop ONLINE 0 0 0 mfid7.nop ONLINE 0 0 0 mfid8.nop ONLINE 0 0 0 mfid9.nop ONLINE 0 0 0 mfid10.nop ONLINE 0 0 0 mfid11.nop ONLINE 0 0 0 mfid12.nop ONLINE 0 0 0 mfid13.nop ONLINE 0 0 0 mfid14.nop ONLINE 0 0 0 mfid15.nop ONLINE 0 0 0 mfid16.nop ONLINE 0 0 0 mfid17.nop ONLINE 0 0 0 mfid18.nop ONLINE 0 0 0 mfid19.nop ONLINE 0 0 0 mfid20.nop ONLINE 0 0 0 mfid21.nop ONLINE 0 0 0 mfid22.nop ONLINE 0 0 0 mfid23.nop ONLINE 0 0 0 fio --direct=1 --rw=randwrite --bs=4k --size=2G --numjobs=1 --runtime=60 --group_reporting --name=randwrite fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning. randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1 fio-2.0.15 Starting 1 process Jobs: 1 (f=1): [w] [100.0% done] [0K/1948K/0K /s] [0 /487 /0 iops] [eta 00m:00s] randwrite: (groupid=0, jobs=1): err= 0: pid=101023: Thu Jul 4 03:03:05 2013 write: io=65592KB, bw=1093.2KB/s, iops=273 , runt= 60002msec clat (usec): min=9 , max=157723 , avg=3654.65, stdev=5733.27 lat (usec): min=9 , max=157724 , avg=3654.98, stdev=5733.29 clat percentiles (usec): | 1.00th=[ 12], 5.00th=[ 13], 10.00th=[ 18], 20.00th=[ 23], | 30.00th=[ 25], 40.00th=[ 740], 50.00th=[ 756], 60.00th=[ 4048], | 70.00th=[ 5856], 80.00th=[ 7648], 90.00th=[ 9408], 95.00th=[10304], | 99.00th=[11584], 99.50th=[19072], 99.90th=[96768], 99.95th=[117248], | 99.99th=[140288] bw (KB/s) : min= 174, max= 2184, per=99.67%, avg=1089.37, stdev=392.80 lat (usec) : 10=0.21%, 20=11.34%, 50=25.24%, 100=0.04%, 750=9.51% lat (usec) : 1000=5.17% lat (msec) : 2=0.30%, 4=7.89%, 10=33.89%, 20=5.99%, 50=0.28% lat (msec) : 100=0.05%, 250=0.10% cpu : usr=0.16%, sys=1.01%, ctx=10488, majf=0, minf=0 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued : total=r=0/w=16398/d=0, short=r=0/w=0/d=0 Run status group 0 (all jobs): WRITE: io=65592KB, aggrb=1093KB/s, minb=1093KB/s, maxb=1093KB/s, mint=60002msec, maxt=60002msec fio --direct=1 --rw=randread --bs=4k --size=2G --numjobs=1 --runtime=60 --group_reporting --name=randread fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning. randread: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1 fio-2.0.15 Starting 1 process randread: Laying out IO file(s) (1 file(s) / 2048MB) Jobs: 1 (f=1): [r] [-.-% done] [608.5M/0K/0K /s] [156K/0 /0 iops] [eta 00m:00s] randread: (groupid=0, jobs=1): err= 0: pid=101025: Thu Jul 4 03:04:35 2013 read : io=2048.0MB, bw=637045KB/s, iops=159261 , runt= 3292msec clat (usec): min=3 , max=83 , avg= 5.25, stdev= 1.39 lat (usec): min=3 , max=83 , avg= 5.32, stdev= 1.39 clat percentiles (usec): | 1.00th=[ 4], 5.00th=[ 4], 10.00th=[ 5], 20.00th=[ 5], | 30.00th=[ 5], 40.00th=[ 5], 50.00th=[ 5], 60.00th=[ 5], | 70.00th=[ 5], 80.00th=[ 6], 90.00th=[ 6], 95.00th=[ 6], | 99.00th=[ 10], 99.50th=[ 14], 99.90th=[ 22], 99.95th=[ 25], | 99.99th=[ 45] bw (KB/s) : min=621928, max=644736, per=99.72%, avg=635281.33, stdev=10139.68 lat (usec) : 4=0.05%, 10=98.94%, 20=0.86%, 50=0.14%, 100=0.01% cpu : usr=14.83%, sys=85.14%, ctx=60, majf=0, minf=1 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued : total=r=524288/w=0/d=0, short=r=0/w=0/d=0 Run status group 0 (all jobs): READ: io=2048.0MB, aggrb=637044KB/s, minb=637044KB/s, maxb=637044KB/s, mint=3292msec, maxt=3292msec > Cheers, > Lawrence > From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 03:41:07 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 11A9335F for ; Thu, 4 Jul 2013 03:41:07 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 64B3519FC for ; Thu, 4 Jul 2013 03:41:05 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 1BA537E824; Thu, 4 Jul 2013 13:41:03 +1000 (EST) Message-ID: <51D4EECE.4010808@freebsd.org> Date: Thu, 04 Jul 2013 13:41:02 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130521 Thunderbird/17.0.6 MIME-Version: 1.0 To: Outback Dingo Subject: Re: Terrible ix performance References: <51D3E5BC.1000604@freebsd.org> <51D42976.9020206@freebsd.org> <51D4D77B.60804@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: Kevin Oberman , Steven Hartland , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Jul 2013 03:41:07 -0000 On 07/04/13 13:06, Outback Dingo wrote: > On Wed, Jul 3, 2013 at 10:01 PM, Lawrence Stewart > wrote: > > On 07/04/13 10:18, Kevin Oberman wrote: > > On Wed, Jul 3, 2013 at 4:21 PM, Steven Hartland > >wrote: [snip] > >> > >> Out of interest have you tried limiting the number of queues? > >> > >> If not give it a try see if it helps, add the following to > >> /boot/loader.conf: > >> hw.ixgbe.num_queues=1 > >> > >> If nothing else will give you another data point. > > As noted in my first post to this thread, if iperf is able to push a > single flow at 8Gbps, then the NIC is unlikely to be the source of the > problem and trying to tune it is a waste of time (at least at this > stage). > > iperf tests memory-network-memory transfer speed without any disk > involvement, so the fact that it can get 8Gbps and ftp is getting around > 4Gbps implies that either the iperf TCP tuning is better (only likely to > be relevant if the RTT is very large - Outback Dingo you still haven't > provided us with the RTT) or the disk subsystem at one or both ends is > slowing things down. > > Outback Dingo: can you please run another iperf test without the -w > switch on both client and server to see if your send/receive window > autotuning on both ends is working. If all is well, you should see the > same results of ~8Gbps. > > >> You might also try SIFTR to analyze the behavior and perhaps even > figure > > out what the limiting factor might be. > > > > kldload siftr > > See "Run-time Configuration" in the siftr(4) man page for details. > > > > I'm a little surprised Lawrence didn't already suggest this as he > is one of > > the authors. (The "Bugs" section is rather long and he might know > that it > > won't be useful in this case, but it has greatly helped me look at > > performance issues.) > > siftr is useful if you suspect a TCP/netstack tuning issue. Given that > iperf gets good results and the OP's tuning settings should be adequate > to achieve good performance if the RTT is low (4MB > sendbuf_max/recvbuf_max), I suspect the disk subsystem and/or VM is more > likely to be the issue i.e. siftr data is probably irrelevant. > > Outback Dingo: Can you confirm you have appropriate tuning on both sides > of the connection? You didn't specify if the loader.conf/sysctl.conf > parameters you provided in the reply to Jack are only on one side of the > connection or both. > > > Yeah i concur, im starting to think the bottleneck is the zpool > > > iperf -i 10 -t 20 -c 10.10.1.11 -l 2.5M > ------------------------------------------------------------ > Client connecting to 10.10.1.11, TCP port 5001 > TCP window size: 257 KByte (default) > ------------------------------------------------------------ > [ 3] local 10.10.1.178 port 47360 connected with 10.10.1.11 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 9.61 GBytes 8.26 Gbits/sec > [ 3] 10.0-20.0 sec 8.83 GBytes 7.58 Gbits/sec > [ 3] 0.0-20.0 sec 18.4 GBytes 7.92 Gbits/sec > nas4free: /testing # iperf -i 10 -t 20 -c 10.10.1.11 -l 2.5M > ------------------------------------------------------------ > Client connecting to 10.10.1.11, TCP port 5001 > TCP window size: 257 KByte (default) > ------------------------------------------------------------ > [ 3] local 10.10.1.178 port 37691 connected with 10.10.1.11 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 5.29 GBytes 4.54 Gbits/sec > [ 3] 10.0-20.0 sec 8.06 GBytes 6.93 Gbits/sec > [ 3] 0.0-20.0 sec 13.4 GBytes 5.73 Gbits/sec > nas4free: /testing # iperf -i 10 -t 20 -c 10.10.1.11 -l 2.5M > ------------------------------------------------------------ > Client connecting to 10.10.1.11, TCP port 5001 > TCP window size: 257 KByte (default) > ------------------------------------------------------------ > [ 3] local 10.10.1.178 port 17560 connected with 10.10.1.11 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 9.48 GBytes 8.14 Gbits/sec > [ 3] 10.0-20.0 sec 8.68 GBytes 7.46 Gbits/sec > [ 3] 0.0-20.0 sec 18.2 GBytes 7.80 Gbits/sec > nas4free: /testing # iperf -i 10 -t 20 -c 10.10.1.11 -l 2.5M > ------------------------------------------------------------ > Client connecting to 10.10.1.11, TCP port 5001 > TCP window size: 257 KByte (default) > ------------------------------------------------------------ > [ 3] local 10.10.1.178 port 14729 connected with 10.10.1.11 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 7.81 GBytes 6.71 Gbits/sec > [ 3] 10.0-20.0 sec 9.11 GBytes 7.82 Gbits/sec > [ 3] 0.0-20.0 sec 16.9 GBytes 7.27 Gbits/sec Ok. It does seem like your issue is VM/disk related rather than network/protocol related in that case. Going forward, I suggest that you test with FTP as you make tweaks in order to keep things as close to raw TCP bulk transfer as possible but including the disks/VM i.e. don't use NFS/SSH/CIFS to evaluate effectiveness of tuning tweaks. > The current configuration on both boxes is > kernel="kernel" > bootfile="kernel" > kernel_options="" > kern.hz="20000" Why such a high hz setting? I'd suggest lowering to 2000 on both machines unless you have good reason for it to be so high. > hw.est.msr_info="0" > hw.hptrr.attach_generic="0" > kern.maxfiles="65536" > kern.maxfilesperproc="50000" > kern.cam.boot_delay="8000" > autoboot_delay="5" > isboot_load="YES" > zfs_load="YES" > hw.ixgbe.enable_aim=0 > > and > cat /etc/sysctl.conf > # Disable core dump > kern.coredump=0 > # System tuning > net.inet.tcp.delayed_ack=0 > # System tuning > net.inet.tcp.rfc1323=1 > # System tuning > net.inet.tcp.sendspace=262144 > # System tuning > net.inet.tcp.recvspace=262144 > # System tuning > net.inet.tcp.sendbuf_max=4194304 > # System tuning > net.inet.tcp.sendbuf_inc=262144 > # System tuning > net.inet.tcp.sendbuf_auto=1 > # System tuning > net.inet.tcp.recvbuf_max=4194304 > # System tuning > net.inet.tcp.recvbuf_inc=262144 > # System tuning > net.inet.tcp.recvbuf_auto=1 > # System tuning > net.inet.udp.recvspace=65536 > # System tuning > net.inet.udp.maxdgram=57344 > # System tuning > net.local.stream.recvspace=65536 > # System tuning > net.local.stream.sendspace=65536 > # System tuning > kern.ipc.maxsockbuf=16777216 > # System tuning > kern.ipc.somaxconn=8192 > # System tuning > kern.ipc.nmbclusters=262144 > # System tuning > kern.ipc.nmbjumbop=262144 > # System tuning > kern.ipc.nmbjumbo9=131072 > # System tuning > kern.ipc.nmbjumbo16=65536 > # System tuning > kern.maxfiles=65536 > # System tuning > kern.maxfilesperproc=50000 > # System tuning > net.inet.icmp.icmplim=300 > # System tuning > net.inet.icmp.icmplim_output=1 > # System tuning > net.inet.tcp.path_mtu_discovery=0 > # System tuning > hw.intr_storm_threshold=9000 Your network-related tuning looks good to me. > Box A is > zpool status > pool: testing > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > testing ONLINE 0 0 0 > da0.nop ONLINE 0 0 0 > da1.nop ONLINE 0 0 0 > da2.nop ONLINE 0 0 0 > da3.nop ONLINE 0 0 0 > da4.nop ONLINE 0 0 0 > da5.nop ONLINE 0 0 0 > da6.nop ONLINE 0 0 0 > da7.nop ONLINE 0 0 0 > da8.nop ONLINE 0 0 0 > da9.nop ONLINE 0 0 0 > da10.nop ONLINE 0 0 0 > da11.nop ONLINE 0 0 0 > da12.nop ONLINE 0 0 0 > da13.nop ONLINE 0 0 0 > da14.nop ONLINE 0 0 0 > da15.nop ONLINE 0 0 0 > > fio --direct=1 --rw=randwrite --bs=4k --size=2G --numjobs=1 --runtime=60 > --group_reporting --name=randwrite > fio: this platform does not support process shared mutexes, forcing use > of threads. Use the 'thread' option to get rid of this warning. > randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, > iodepth=1 > fio-2.0.15 > Starting 1 process > Jobs: 1 (f=1): [w] [100.0% done] [0K/150.9M/0K /s] [0 /38.7K/0 iops] > [eta 00m:00s] > randwrite: (groupid=0, jobs=1): err= 0: pid=101192: Wed Jul 3 23:01:09 2013 > write: io=2048.0MB, bw=147916KB/s, iops=36978 , runt= 14178msec > clat (usec): min=9 , max=122101 , avg=24.17, stdev=229.23 > lat (usec): min=10 , max=122101 , avg=24.42, stdev=229.23 > clat percentiles (usec): > | 1.00th=[ 11], 5.00th=[ 12], 10.00th=[ 14], 20.00th=[ 21], > | 30.00th=[ 21], 40.00th=[ 22], 50.00th=[ 22], 60.00th=[ 23], > | 70.00th=[ 23], 80.00th=[ 24], 90.00th=[ 29], 95.00th=[ 35], > | 99.00th=[ 99], 99.50th=[ 114], 99.90th=[ 131], 99.95th=[ 137], > | 99.99th=[ 181] > bw (KB/s) : min=58200, max=223112, per=99.93%, avg=147815.61, > stdev=31976.97 > lat (usec) : 10=0.01%, 20=15.49%, 50=82.15%, 100=1.39%, 250=0.96% > lat (usec) : 500=0.01%, 750=0.01%, 1000=0.01% > lat (msec) : 2=0.01%, 20=0.01%, 250=0.01% > cpu : usr=11.05%, sys=87.08%, ctx=563, majf=0, minf=0 > IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >>=64=0.0% > submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >>=64=0.0% > complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >>=64=0.0% > issued : total=r=0/w=524288/d=0, short=r=0/w=0/d=0 > > Run status group 0 (all jobs): > WRITE: io=2048.0MB, aggrb=147915KB/s, minb=147915KB/s, > maxb=147915KB/s, mint=14178msec, maxt=14178msec > fio --direct=1 --rw=randread --bs=4k --size=2G --numjobs=1 --runtime=60 > --group_reporting --name=randread > fio: this platform does not support process shared mutexes, forcing use > of threads. Use the 'thread' option to get rid of this warning. > randread: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1 > fio-2.0.15 > Starting 1 process > randread: Laying out IO file(s) (1 file(s) / 2048MB) > Jobs: 1 (f=1): [r] [100.0% done] [292.9M/0K/0K /s] [74.1K/0 /0 iops] > [eta 00m:00s] > randread: (groupid=0, jobs=1): err= 0: pid=101304: Wed Jul 3 23:02:08 2013 > read : io=2048.0MB, bw=327578KB/s, iops=81894 , runt= 6402msec > clat (usec): min=4 , max=20418 , avg=10.15, stdev=28.54 > lat (usec): min=4 , max=20418 , avg=10.27, stdev=28.54 > clat percentiles (usec): > | 1.00th=[ 5], 5.00th=[ 6], 10.00th=[ 6], 20.00th=[ 8], > | 30.00th=[ 10], 40.00th=[ 10], 50.00th=[ 10], 60.00th=[ 11], > | 70.00th=[ 11], 80.00th=[ 11], 90.00th=[ 12], 95.00th=[ 13], > | 99.00th=[ 22], 99.50th=[ 31], 99.90th=[ 77], 99.95th=[ 95], > | 99.99th=[ 145] > bw (KB/s) : min=290024, max=520016, per=100.00%, avg=328490.00, > stdev=63941.66 > lat (usec) : 10=28.85%, 20=69.83%, 50=1.19%, 100=0.09%, 250=0.05% > lat (msec) : 50=0.01% > cpu : usr=18.08%, sys=81.57%, ctx=144, majf=0, minf=1 > IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >>=64=0.0% > submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >>=64=0.0% > complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >>=64=0.0% > issued : total=r=524288/w=0/d=0, short=r=0/w=0/d=0 > > Run status group 0 (all jobs): > READ: io=2048.0MB, aggrb=327577KB/s, minb=327577KB/s, > maxb=327577KB/s, mint=6402msec, maxt=6402msec > > > Box B > zpool status > pool: backup > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > backup ONLINE 0 0 0 > mfid0.nop ONLINE 0 0 0 > mfid1.nop ONLINE 0 0 0 > mfid2.nop ONLINE 0 0 0 > mfid3.nop ONLINE 0 0 0 > mfid4.nop ONLINE 0 0 0 > mfid5.nop ONLINE 0 0 0 > mfid6.nop ONLINE 0 0 0 > mfid7.nop ONLINE 0 0 0 > mfid8.nop ONLINE 0 0 0 > mfid9.nop ONLINE 0 0 0 > mfid10.nop ONLINE 0 0 0 > mfid11.nop ONLINE 0 0 0 > mfid12.nop ONLINE 0 0 0 > mfid13.nop ONLINE 0 0 0 > mfid14.nop ONLINE 0 0 0 > mfid15.nop ONLINE 0 0 0 > mfid16.nop ONLINE 0 0 0 > mfid17.nop ONLINE 0 0 0 > mfid18.nop ONLINE 0 0 0 > mfid19.nop ONLINE 0 0 0 > mfid20.nop ONLINE 0 0 0 > mfid21.nop ONLINE 0 0 0 > mfid22.nop ONLINE 0 0 0 > mfid23.nop ONLINE 0 0 0 > > > > fio --direct=1 --rw=randwrite --bs=4k --size=2G --numjobs=1 --runtime=60 > --group_reporting --name=randwrite > fio: this platform does not support process shared mutexes, forcing use > of threads. Use the 'thread' option to get rid of this warning. > randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, > iodepth=1 > fio-2.0.15 > Starting 1 process > Jobs: 1 (f=1): [w] [100.0% done] [0K/1948K/0K /s] [0 /487 /0 iops] [eta > 00m:00s] > randwrite: (groupid=0, jobs=1): err= 0: pid=101023: Thu Jul 4 03:03:05 2013 > write: io=65592KB, bw=1093.2KB/s, iops=273 , runt= 60002msec > clat (usec): min=9 , max=157723 , avg=3654.65, stdev=5733.27 > lat (usec): min=9 , max=157724 , avg=3654.98, stdev=5733.29 > clat percentiles (usec): > | 1.00th=[ 12], 5.00th=[ 13], 10.00th=[ 18], 20.00th=[ 23], > | 30.00th=[ 25], 40.00th=[ 740], 50.00th=[ 756], 60.00th=[ 4048], > | 70.00th=[ 5856], 80.00th=[ 7648], 90.00th=[ 9408], 95.00th=[10304], > | 99.00th=[11584], 99.50th=[19072], 99.90th=[96768], 99.95th=[117248], > | 99.99th=[140288] > bw (KB/s) : min= 174, max= 2184, per=99.67%, avg=1089.37, stdev=392.80 > lat (usec) : 10=0.21%, 20=11.34%, 50=25.24%, 100=0.04%, 750=9.51% > lat (usec) : 1000=5.17% > lat (msec) : 2=0.30%, 4=7.89%, 10=33.89%, 20=5.99%, 50=0.28% > lat (msec) : 100=0.05%, 250=0.10% > cpu : usr=0.16%, sys=1.01%, ctx=10488, majf=0, minf=0 > IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >>=64=0.0% > submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >>=64=0.0% > complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >>=64=0.0% > issued : total=r=0/w=16398/d=0, short=r=0/w=0/d=0 > > Run status group 0 (all jobs): > WRITE: io=65592KB, aggrb=1093KB/s, minb=1093KB/s, maxb=1093KB/s, > mint=60002msec, maxt=60002msec > > fio --direct=1 --rw=randread --bs=4k --size=2G --numjobs=1 --runtime=60 > --group_reporting --name=randread > fio: this platform does not support process shared mutexes, forcing use > of threads. Use the 'thread' option to get rid of this warning. > randread: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1 > fio-2.0.15 > Starting 1 process > randread: Laying out IO file(s) (1 file(s) / 2048MB) > Jobs: 1 (f=1): [r] [-.-% done] [608.5M/0K/0K /s] [156K/0 /0 iops] [eta > 00m:00s] > randread: (groupid=0, jobs=1): err= 0: pid=101025: Thu Jul 4 03:04:35 2013 > read : io=2048.0MB, bw=637045KB/s, iops=159261 , runt= 3292msec > clat (usec): min=3 , max=83 , avg= 5.25, stdev= 1.39 > lat (usec): min=3 , max=83 , avg= 5.32, stdev= 1.39 > clat percentiles (usec): > | 1.00th=[ 4], 5.00th=[ 4], 10.00th=[ 5], 20.00th=[ 5], > | 30.00th=[ 5], 40.00th=[ 5], 50.00th=[ 5], 60.00th=[ 5], > | 70.00th=[ 5], 80.00th=[ 6], 90.00th=[ 6], 95.00th=[ 6], > | 99.00th=[ 10], 99.50th=[ 14], 99.90th=[ 22], 99.95th=[ 25], > | 99.99th=[ 45] > bw (KB/s) : min=621928, max=644736, per=99.72%, avg=635281.33, > stdev=10139.68 > lat (usec) : 4=0.05%, 10=98.94%, 20=0.86%, 50=0.14%, 100=0.01% > cpu : usr=14.83%, sys=85.14%, ctx=60, majf=0, minf=1 > IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >>=64=0.0% > submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >>=64=0.0% > complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >>=64=0.0% > issued : total=r=524288/w=0/d=0, short=r=0/w=0/d=0 > > Run status group 0 (all jobs): > READ: io=2048.0MB, aggrb=637044KB/s, minb=637044KB/s, > maxb=637044KB/s, mint=3292msec, maxt=3292msec So if I interpret the above correctly, Box A can crank ~140MB/s random write and ~300MB/s random read and Box B cranks ~1MB/s random write and 630MB/s random read? A few thoughts: - What's up with Box B's 1MB/s write bandwidth? I'm guessing something fired up at the same time as your IO test and killed your random write throughput. - Random read/write is not really a useful test here as ftp is effectively a sequential streaming read/write workload. The random read/write throughput is irrelevant. - I recall some advice that zpool's should not have more than about 8 or 10 disks in them, and you should instead create multiple zpools if you have more disks. Perhaps investigate the source of that rumour and if it's true, try create 2 x 8 disk zpools in Box A and 3 x 8 disk zpools in box B and see if that changes things at all. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 04:00:18 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD13C87D; Thu, 4 Jul 2013 04:00:18 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 8918A1BA7; Thu, 4 Jul 2013 04:00:18 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id ef5so1099706obb.15 for ; Wed, 03 Jul 2013 21:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CpgHFgwP/PjErfzUBbqyz2UXT3I8tDArO5PyPodu0Vw=; b=0XcyT0ZaaQcD28uL6nrlAfO4qmWWonML0hRi8Nz+/LoUbR3ARt2j5L9B8BFb4a5mMg P4ySzlZBByc2imEz0UIqbu0KcrB4sRmDufNhsgPN8lVHjUktQHq8Lvgue8yXhJRSd5Dz 7nZrAzAIsQUPkTD2yJeVeVUrzBGZV67YHl/92u5YQjqn03b7Gu6UUhA0FHorwYhwWRSj oyhfjqiCRaWcxOUilL/XNPA69LAOe+PiKSjs6xKeO78rDUUCCJwdjRsHln0fphRtbVeI DQ9mSM3ilYE4ic0oIY20/uTSmxqhdW3zMK9/OFbAmjxRRUbDQyuA7X4JULK3EdWORMPr 5k1A== MIME-Version: 1.0 X-Received: by 10.60.37.74 with SMTP id w10mr4064289oej.30.1372910418005; Wed, 03 Jul 2013 21:00:18 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Wed, 3 Jul 2013 21:00:17 -0700 (PDT) In-Reply-To: <51D4EECE.4010808@freebsd.org> References: <51D3E5BC.1000604@freebsd.org> <51D42976.9020206@freebsd.org> <51D4D77B.60804@freebsd.org> <51D4EECE.4010808@freebsd.org> Date: Thu, 4 Jul 2013 00:00:17 -0400 Message-ID: Subject: Re: Terrible ix performance From: Outback Dingo To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Kevin Oberman , Steven Hartland , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Jul 2013 04:00:18 -0000 On Wed, Jul 3, 2013 at 11:41 PM, Lawrence Stewart wrote: > On 07/04/13 13:06, Outback Dingo wrote: > > On Wed, Jul 3, 2013 at 10:01 PM, Lawrence Stewart > > wrote: > > > > On 07/04/13 10:18, Kevin Oberman wrote: > > > On Wed, Jul 3, 2013 at 4:21 PM, Steven Hartland > > >wrote: > [snip] > > >> > > >> Out of interest have you tried limiting the number of queues? > > >> > > >> If not give it a try see if it helps, add the following to > > >> /boot/loader.conf: > > >> hw.ixgbe.num_queues=1 > > >> > > >> If nothing else will give you another data point. > > > > As noted in my first post to this thread, if iperf is able to push a > > single flow at 8Gbps, then the NIC is unlikely to be the source of > the > > problem and trying to tune it is a waste of time (at least at this > > stage). > > > > iperf tests memory-network-memory transfer speed without any disk > > involvement, so the fact that it can get 8Gbps and ftp is getting > around > > 4Gbps implies that either the iperf TCP tuning is better (only > likely to > > be relevant if the RTT is very large - Outback Dingo you still > haven't > > provided us with the RTT) or the disk subsystem at one or both ends > is > > slowing things down. > > > > Outback Dingo: can you please run another iperf test without the -w > > switch on both client and server to see if your send/receive window > > autotuning on both ends is working. If all is well, you should see > the > > same results of ~8Gbps. > > > > >> You might also try SIFTR to analyze the behavior and perhaps even > > figure > > > out what the limiting factor might be. > > > > > > kldload siftr > > > See "Run-time Configuration" in the siftr(4) man page for details. > > > > > > I'm a little surprised Lawrence didn't already suggest this as he > > is one of > > > the authors. (The "Bugs" section is rather long and he might know > > that it > > > won't be useful in this case, but it has greatly helped me look at > > > performance issues.) > > > > siftr is useful if you suspect a TCP/netstack tuning issue. Given > that > > iperf gets good results and the OP's tuning settings should be > adequate > > to achieve good performance if the RTT is low (4MB > > sendbuf_max/recvbuf_max), I suspect the disk subsystem and/or VM is > more > > likely to be the issue i.e. siftr data is probably irrelevant. > > > > Outback Dingo: Can you confirm you have appropriate tuning on both > sides > > of the connection? You didn't specify if the loader.conf/sysctl.conf > > parameters you provided in the reply to Jack are only on one side of > the > > connection or both. > > > > > > Yeah i concur, im starting to think the bottleneck is the zpool > > > > > > iperf -i 10 -t 20 -c 10.10.1.11 -l 2.5M > > ------------------------------------------------------------ > > Client connecting to 10.10.1.11, TCP port 5001 > > TCP window size: 257 KByte (default) > > ------------------------------------------------------------ > > [ 3] local 10.10.1.178 port 47360 connected with 10.10.1.11 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-10.0 sec 9.61 GBytes 8.26 Gbits/sec > > [ 3] 10.0-20.0 sec 8.83 GBytes 7.58 Gbits/sec > > [ 3] 0.0-20.0 sec 18.4 GBytes 7.92 Gbits/sec > > nas4free: /testing # iperf -i 10 -t 20 -c 10.10.1.11 -l 2.5M > > ------------------------------------------------------------ > > Client connecting to 10.10.1.11, TCP port 5001 > > TCP window size: 257 KByte (default) > > ------------------------------------------------------------ > > [ 3] local 10.10.1.178 port 37691 connected with 10.10.1.11 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-10.0 sec 5.29 GBytes 4.54 Gbits/sec > > [ 3] 10.0-20.0 sec 8.06 GBytes 6.93 Gbits/sec > > [ 3] 0.0-20.0 sec 13.4 GBytes 5.73 Gbits/sec > > nas4free: /testing # iperf -i 10 -t 20 -c 10.10.1.11 -l 2.5M > > ------------------------------------------------------------ > > Client connecting to 10.10.1.11, TCP port 5001 > > TCP window size: 257 KByte (default) > > ------------------------------------------------------------ > > [ 3] local 10.10.1.178 port 17560 connected with 10.10.1.11 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-10.0 sec 9.48 GBytes 8.14 Gbits/sec > > [ 3] 10.0-20.0 sec 8.68 GBytes 7.46 Gbits/sec > > [ 3] 0.0-20.0 sec 18.2 GBytes 7.80 Gbits/sec > > nas4free: /testing # iperf -i 10 -t 20 -c 10.10.1.11 -l 2.5M > > ------------------------------------------------------------ > > Client connecting to 10.10.1.11, TCP port 5001 > > TCP window size: 257 KByte (default) > > ------------------------------------------------------------ > > [ 3] local 10.10.1.178 port 14729 connected with 10.10.1.11 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-10.0 sec 7.81 GBytes 6.71 Gbits/sec > > [ 3] 10.0-20.0 sec 9.11 GBytes 7.82 Gbits/sec > > [ 3] 0.0-20.0 sec 16.9 GBytes 7.27 Gbits/sec > > Ok. It does seem like your issue is VM/disk related rather than > network/protocol related in that case. Going forward, I suggest that you > test with FTP as you make tweaks in order to keep things as close to raw > TCP bulk transfer as possible but including the disks/VM i.e. don't use > NFS/SSH/CIFS to evaluate effectiveness of tuning tweaks. > > The current configuration on both boxes is > > kernel="kernel" > > bootfile="kernel" > > kernel_options="" > > kern.hz="20000" > > Why such a high hz setting? I'd suggest lowering to 2000 on both > machines unless you have good reason for it to be so high. > > hw.est.msr_info="0" > > hw.hptrr.attach_generic="0" > > kern.maxfiles="65536" > > kern.maxfilesperproc="50000" > > kern.cam.boot_delay="8000" > > autoboot_delay="5" > > isboot_load="YES" > > zfs_load="YES" > > hw.ixgbe.enable_aim=0 > > > > and > > cat /etc/sysctl.conf > > # Disable core dump > > kern.coredump=0 > > # System tuning > > net.inet.tcp.delayed_ack=0 > > # System tuning > > net.inet.tcp.rfc1323=1 > > # System tuning > > net.inet.tcp.sendspace=262144 > > # System tuning > > net.inet.tcp.recvspace=262144 > > # System tuning > > net.inet.tcp.sendbuf_max=4194304 > > # System tuning > > net.inet.tcp.sendbuf_inc=262144 > > # System tuning > > net.inet.tcp.sendbuf_auto=1 > > # System tuning > > net.inet.tcp.recvbuf_max=4194304 > > # System tuning > > net.inet.tcp.recvbuf_inc=262144 > > # System tuning > > net.inet.tcp.recvbuf_auto=1 > > # System tuning > > net.inet.udp.recvspace=65536 > > # System tuning > > net.inet.udp.maxdgram=57344 > > # System tuning > > net.local.stream.recvspace=65536 > > # System tuning > > net.local.stream.sendspace=65536 > > # System tuning > > kern.ipc.maxsockbuf=16777216 > > # System tuning > > kern.ipc.somaxconn=8192 > > # System tuning > > kern.ipc.nmbclusters=262144 > > # System tuning > > kern.ipc.nmbjumbop=262144 > > # System tuning > > kern.ipc.nmbjumbo9=131072 > > # System tuning > > kern.ipc.nmbjumbo16=65536 > > # System tuning > > kern.maxfiles=65536 > > # System tuning > > kern.maxfilesperproc=50000 > > # System tuning > > net.inet.icmp.icmplim=300 > > # System tuning > > net.inet.icmp.icmplim_output=1 > > # System tuning > > net.inet.tcp.path_mtu_discovery=0 > > # System tuning > > hw.intr_storm_threshold=9000 > > Your network-related tuning looks good to me. > > > Box A is > > zpool status > > pool: testing > > state: ONLINE > > scan: none requested > > config: > > > > NAME STATE READ WRITE CKSUM > > testing ONLINE 0 0 0 > > da0.nop ONLINE 0 0 0 > > da1.nop ONLINE 0 0 0 > > da2.nop ONLINE 0 0 0 > > da3.nop ONLINE 0 0 0 > > da4.nop ONLINE 0 0 0 > > da5.nop ONLINE 0 0 0 > > da6.nop ONLINE 0 0 0 > > da7.nop ONLINE 0 0 0 > > da8.nop ONLINE 0 0 0 > > da9.nop ONLINE 0 0 0 > > da10.nop ONLINE 0 0 0 > > da11.nop ONLINE 0 0 0 > > da12.nop ONLINE 0 0 0 > > da13.nop ONLINE 0 0 0 > > da14.nop ONLINE 0 0 0 > > da15.nop ONLINE 0 0 0 > > > > fio --direct=1 --rw=randwrite --bs=4k --size=2G --numjobs=1 --runtime=60 > > --group_reporting --name=randwrite > > fio: this platform does not support process shared mutexes, forcing use > > of threads. Use the 'thread' option to get rid of this warning. > > randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, > > iodepth=1 > > fio-2.0.15 > > Starting 1 process > > Jobs: 1 (f=1): [w] [100.0% done] [0K/150.9M/0K /s] [0 /38.7K/0 iops] > > [eta 00m:00s] > > randwrite: (groupid=0, jobs=1): err= 0: pid=101192: Wed Jul 3 23:01:09 > 2013 > > write: io=2048.0MB, bw=147916KB/s, iops=36978 , runt= 14178msec > > clat (usec): min=9 , max=122101 , avg=24.17, stdev=229.23 > > lat (usec): min=10 , max=122101 , avg=24.42, stdev=229.23 > > clat percentiles (usec): > > | 1.00th=[ 11], 5.00th=[ 12], 10.00th=[ 14], 20.00th=[ > 21], > > | 30.00th=[ 21], 40.00th=[ 22], 50.00th=[ 22], 60.00th=[ > 23], > > | 70.00th=[ 23], 80.00th=[ 24], 90.00th=[ 29], 95.00th=[ > 35], > > | 99.00th=[ 99], 99.50th=[ 114], 99.90th=[ 131], 99.95th=[ > 137], > > | 99.99th=[ 181] > > bw (KB/s) : min=58200, max=223112, per=99.93%, avg=147815.61, > > stdev=31976.97 > > lat (usec) : 10=0.01%, 20=15.49%, 50=82.15%, 100=1.39%, 250=0.96% > > lat (usec) : 500=0.01%, 750=0.01%, 1000=0.01% > > lat (msec) : 2=0.01%, 20=0.01%, 250=0.01% > > cpu : usr=11.05%, sys=87.08%, ctx=563, majf=0, minf=0 > > IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, > >>=64=0.0% > > submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, > >>=64=0.0% > > complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, > >>=64=0.0% > > issued : total=r=0/w=524288/d=0, short=r=0/w=0/d=0 > > > > Run status group 0 (all jobs): > > WRITE: io=2048.0MB, aggrb=147915KB/s, minb=147915KB/s, > > maxb=147915KB/s, mint=14178msec, maxt=14178msec > > fio --direct=1 --rw=randread --bs=4k --size=2G --numjobs=1 --runtime=60 > > --group_reporting --name=randread > > fio: this platform does not support process shared mutexes, forcing use > > of threads. Use the 'thread' option to get rid of this warning. > > randread: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, > iodepth=1 > > fio-2.0.15 > > Starting 1 process > > randread: Laying out IO file(s) (1 file(s) / 2048MB) > > Jobs: 1 (f=1): [r] [100.0% done] [292.9M/0K/0K /s] [74.1K/0 /0 iops] > > [eta 00m:00s] > > randread: (groupid=0, jobs=1): err= 0: pid=101304: Wed Jul 3 23:02:08 > 2013 > > read : io=2048.0MB, bw=327578KB/s, iops=81894 , runt= 6402msec > > clat (usec): min=4 , max=20418 , avg=10.15, stdev=28.54 > > lat (usec): min=4 , max=20418 , avg=10.27, stdev=28.54 > > clat percentiles (usec): > > | 1.00th=[ 5], 5.00th=[ 6], 10.00th=[ 6], 20.00th=[ > 8], > > | 30.00th=[ 10], 40.00th=[ 10], 50.00th=[ 10], 60.00th=[ > 11], > > | 70.00th=[ 11], 80.00th=[ 11], 90.00th=[ 12], 95.00th=[ > 13], > > | 99.00th=[ 22], 99.50th=[ 31], 99.90th=[ 77], 99.95th=[ > 95], > > | 99.99th=[ 145] > > bw (KB/s) : min=290024, max=520016, per=100.00%, avg=328490.00, > > stdev=63941.66 > > lat (usec) : 10=28.85%, 20=69.83%, 50=1.19%, 100=0.09%, 250=0.05% > > lat (msec) : 50=0.01% > > cpu : usr=18.08%, sys=81.57%, ctx=144, majf=0, minf=1 > > IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, > >>=64=0.0% > > submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, > >>=64=0.0% > > complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, > >>=64=0.0% > > issued : total=r=524288/w=0/d=0, short=r=0/w=0/d=0 > > > > Run status group 0 (all jobs): > > READ: io=2048.0MB, aggrb=327577KB/s, minb=327577KB/s, > > maxb=327577KB/s, mint=6402msec, maxt=6402msec > > > > > > Box B > > zpool status > > pool: backup > > state: ONLINE > > scan: none requested > > config: > > > > NAME STATE READ WRITE CKSUM > > backup ONLINE 0 0 0 > > mfid0.nop ONLINE 0 0 0 > > mfid1.nop ONLINE 0 0 0 > > mfid2.nop ONLINE 0 0 0 > > mfid3.nop ONLINE 0 0 0 > > mfid4.nop ONLINE 0 0 0 > > mfid5.nop ONLINE 0 0 0 > > mfid6.nop ONLINE 0 0 0 > > mfid7.nop ONLINE 0 0 0 > > mfid8.nop ONLINE 0 0 0 > > mfid9.nop ONLINE 0 0 0 > > mfid10.nop ONLINE 0 0 0 > > mfid11.nop ONLINE 0 0 0 > > mfid12.nop ONLINE 0 0 0 > > mfid13.nop ONLINE 0 0 0 > > mfid14.nop ONLINE 0 0 0 > > mfid15.nop ONLINE 0 0 0 > > mfid16.nop ONLINE 0 0 0 > > mfid17.nop ONLINE 0 0 0 > > mfid18.nop ONLINE 0 0 0 > > mfid19.nop ONLINE 0 0 0 > > mfid20.nop ONLINE 0 0 0 > > mfid21.nop ONLINE 0 0 0 > > mfid22.nop ONLINE 0 0 0 > > mfid23.nop ONLINE 0 0 0 > > > > > > > > fio --direct=1 --rw=randwrite --bs=4k --size=2G --numjobs=1 --runtime=60 > > --group_reporting --name=randwrite > > fio: this platform does not support process shared mutexes, forcing use > > of threads. Use the 'thread' option to get rid of this warning. > > randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, > > iodepth=1 > > fio-2.0.15 > > Starting 1 process > > Jobs: 1 (f=1): [w] [100.0% done] [0K/1948K/0K /s] [0 /487 /0 iops] [eta > > 00m:00s] > > randwrite: (groupid=0, jobs=1): err= 0: pid=101023: Thu Jul 4 03:03:05 > 2013 > > write: io=65592KB, bw=1093.2KB/s, iops=273 , runt= 60002msec > > clat (usec): min=9 , max=157723 , avg=3654.65, stdev=5733.27 > > lat (usec): min=9 , max=157724 , avg=3654.98, stdev=5733.29 > > clat percentiles (usec): > > | 1.00th=[ 12], 5.00th=[ 13], 10.00th=[ 18], 20.00th=[ > 23], > > | 30.00th=[ 25], 40.00th=[ 740], 50.00th=[ 756], 60.00th=[ > 4048], > > | 70.00th=[ 5856], 80.00th=[ 7648], 90.00th=[ 9408], > 95.00th=[10304], > > | 99.00th=[11584], 99.50th=[19072], 99.90th=[96768], > 99.95th=[117248], > > | 99.99th=[140288] > > bw (KB/s) : min= 174, max= 2184, per=99.67%, avg=1089.37, > stdev=392.80 > > lat (usec) : 10=0.21%, 20=11.34%, 50=25.24%, 100=0.04%, 750=9.51% > > lat (usec) : 1000=5.17% > > lat (msec) : 2=0.30%, 4=7.89%, 10=33.89%, 20=5.99%, 50=0.28% > > lat (msec) : 100=0.05%, 250=0.10% > > cpu : usr=0.16%, sys=1.01%, ctx=10488, majf=0, minf=0 > > IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, > >>=64=0.0% > > submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, > >>=64=0.0% > > complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, > >>=64=0.0% > > issued : total=r=0/w=16398/d=0, short=r=0/w=0/d=0 > > > > Run status group 0 (all jobs): > > WRITE: io=65592KB, aggrb=1093KB/s, minb=1093KB/s, maxb=1093KB/s, > > mint=60002msec, maxt=60002msec > > > > fio --direct=1 --rw=randread --bs=4k --size=2G --numjobs=1 --runtime=60 > > --group_reporting --name=randread > > fio: this platform does not support process shared mutexes, forcing use > > of threads. Use the 'thread' option to get rid of this warning. > > randread: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, > iodepth=1 > > fio-2.0.15 > > Starting 1 process > > randread: Laying out IO file(s) (1 file(s) / 2048MB) > > Jobs: 1 (f=1): [r] [-.-% done] [608.5M/0K/0K /s] [156K/0 /0 iops] [eta > > 00m:00s] > > randread: (groupid=0, jobs=1): err= 0: pid=101025: Thu Jul 4 03:04:35 > 2013 > > read : io=2048.0MB, bw=637045KB/s, iops=159261 , runt= 3292msec > > clat (usec): min=3 , max=83 , avg= 5.25, stdev= 1.39 > > lat (usec): min=3 , max=83 , avg= 5.32, stdev= 1.39 > > clat percentiles (usec): > > | 1.00th=[ 4], 5.00th=[ 4], 10.00th=[ 5], 20.00th=[ > 5], > > | 30.00th=[ 5], 40.00th=[ 5], 50.00th=[ 5], 60.00th=[ > 5], > > | 70.00th=[ 5], 80.00th=[ 6], 90.00th=[ 6], 95.00th=[ > 6], > > | 99.00th=[ 10], 99.50th=[ 14], 99.90th=[ 22], 99.95th=[ > 25], > > | 99.99th=[ 45] > > bw (KB/s) : min=621928, max=644736, per=99.72%, avg=635281.33, > > stdev=10139.68 > > lat (usec) : 4=0.05%, 10=98.94%, 20=0.86%, 50=0.14%, 100=0.01% > > cpu : usr=14.83%, sys=85.14%, ctx=60, majf=0, minf=1 > > IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, > >>=64=0.0% > > submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, > >>=64=0.0% > > complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, > >>=64=0.0% > > issued : total=r=524288/w=0/d=0, short=r=0/w=0/d=0 > > > > Run status group 0 (all jobs): > > READ: io=2048.0MB, aggrb=637044KB/s, minb=637044KB/s, > > maxb=637044KB/s, mint=3292msec, maxt=3292msec > > So if I interpret the above correctly, Box A can crank ~140MB/s random > write and ~300MB/s random read and Box B cranks ~1MB/s random write and > 630MB/s random read? > > A few thoughts: > > - What's up with Box B's 1MB/s write bandwidth? I'm guessing something > fired up at the same time as your IO test and killed your random write > throughput. > > - Random read/write is not really a useful test here as ftp is > effectively a sequential streaming read/write workload. The random > read/write throughput is irrelevant. > > - I recall some advice that zpool's should not have more than about 8 or > 10 disks in them, and you should instead create multiple zpools if you > have more disks. Perhaps investigate the source of that rumour and if > it's true, try create 2 x 8 disk zpools in Box A and 3 x 8 disk zpools > in box B and see if that changes things at all. > > Cheers, > Lawrence > Damn, good catch on the hz, typoed that...... Yeah im aware of the 8 device zpool rules, ive started benchmarking the pool in various configurations from 16 devs, 8 dev, mirrored devs, z2, z3 to find the best config for iops and i reran the fio on Box B fio --direct=1 --rw=randwrite --bs=4k --size=2G --numjobs=1 --runtime=60 --group_reporting --name=randwrite fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning. randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1 fio-2.0.15 Starting 1 process Jobs: 1 (f=1): [w] [100.0% done] [0K/7796K/0K /s] [0 /1949 /0 iops] [eta 00m:00s] randwrite: (groupid=0, jobs=1): err= 0: pid=101027: Thu Jul 4 03:53:38 2013 write: io=171064KB, bw=2850.1KB/s, iops=712 , runt= 60002msec clat (usec): min=8 , max=228477 , avg=1399.79, stdev=5136.25 lat (usec): min=8 , max=228477 , avg=1400.04, stdev=5136.25 clat percentiles (usec): | 1.00th=[ 9], 5.00th=[ 10], 10.00th=[ 11], 20.00th=[ 12], | 30.00th=[ 13], 40.00th=[ 17], 50.00th=[ 22], 60.00th=[ 24], | 70.00th=[ 748], 80.00th=[ 764], 90.00th=[ 5536], 95.00th=[ 8512], | 99.00th=[10816], 99.50th=[11968], 99.90th=[79360], 99.95th=[122368], | 99.99th=[150528] bw (KB/s) : min= 226, max= 9285, per=99.03%, avg=2822.35, stdev=1846.42 lat (usec) : 10=4.45%, 20=39.13%, 50=20.64%, 100=0.12%, 250=0.01% lat (usec) : 750=8.06%, 1000=11.45% lat (msec) : 2=0.92%, 4=2.44%, 10=10.48%, 20=2.01%, 50=0.15% lat (msec) : 100=0.06%, 250=0.08% cpu : usr=0.19%, sys=2.08%, ctx=15380, majf=0, minf=0 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued : total=r=0/w=42766/d=0, short=r=0/w=0/d=0 Run status group 0 (all jobs): WRITE: io=171064KB, aggrb=2850KB/s, minb=2850KB/s, maxb=2850KB/s, mint=60002msec, maxt=60002msec From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 04:39:26 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E7E1BEA6; Thu, 4 Jul 2013 04:39:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4091D0E; Thu, 4 Jul 2013 04:39:26 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id f14so4006128qak.7 for ; Wed, 03 Jul 2013 21:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vkw7h5Fi9n6kx7NdmiM8q1wWMyI/tgjeap0GP9wGI3I=; b=aYOcqguk+GgQjAT1+RUHgmRVa36JmL6A2GPTqwhjs4GwpRITyVanFlsY+n+sVjmGjW nFjPbBtHnyvq934eIwyJpaVmyToNPKH9eC8gbpA+T6quCbwoNUyb9QJd3qkHgfI/5oDY pRkROWQHcYy3QmynvLLOtM3wz6fgyqO9sBF6VEELRxNPAsoME8swLa9Towb/Z54CJHCk cgZ6hp6lOq61qty+HERXCEdtV9Vz38KqFIVKlLI+r6X+N2xx2at76oxoU83P/dVVx/3x zY8vGS358c4JFUuIRqvT8NQWqjME6Vzbo48k2OvA9cqISgHqB2MkXG6duUeIMowJXc0d 5QdQ== MIME-Version: 1.0 X-Received: by 10.229.164.203 with SMTP id f11mr960138qcy.107.1372912766151; Wed, 03 Jul 2013 21:39:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Wed, 3 Jul 2013 21:39:26 -0700 (PDT) In-Reply-To: <51D4EECE.4010808@freebsd.org> References: <51D3E5BC.1000604@freebsd.org> <51D42976.9020206@freebsd.org> <51D4D77B.60804@freebsd.org> <51D4EECE.4010808@freebsd.org> Date: Wed, 3 Jul 2013 21:39:26 -0700 X-Google-Sender-Auth: F9eyBQIvRr_NfLewpzfaYG5gPno Message-ID: Subject: Re: Terrible ix performance From: Adrian Chadd To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 Cc: Outback Dingo , net@freebsd.org, Steven Hartland , Kevin Oberman X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Jul 2013 04:39:27 -0000 .. please file a bug if hz is affecting your performance. Ew. -adrian From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 05:03:27 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A13D1DC for ; Thu, 4 Jul 2013 05:03:27 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id 25A231E06 for ; Thu, 4 Jul 2013 05:03:26 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id c13so730463vea.21 for ; Wed, 03 Jul 2013 22:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U8fsYGvQYzX8vrAZed8EHXO8T1CHEQnuMCuEF56hBMs=; b=30+jbIrQoZ47ejNZFMJXylrOcWY1G/BtaQ3+gIeXDwVYy80WJyqk0LTGpJdJp5+eb5 lUZ67M7DFXJQaO9TgP4dn8zxUUp93HjAgp/Dqu7wYZwXb9gZLIdNuGuktltjK4d05h2G 8NjniI8d/U/Po3guZgvLZkkD1SZEZnAwRLjM8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=U8fsYGvQYzX8vrAZed8EHXO8T1CHEQnuMCuEF56hBMs=; b=oDYfj1wbE0yW+2zooqt0X5pD57bGQvy0wH1MmWeMnstpUxXQvPFsjlGvZAhiKqb5Vy UN57ixrbceKggZ4d3Pb1Tu4jUFiDyyN3djAmfXHc4vXmKMnnSWx4RfgrSynWJ4i/ZAbz 7bI7C6JLpUPAF84Ww5z2gwknRvOKDCGRPI5c0N3eXrKOmkV5u9S7ljpNFUoG5CYdLXu6 GWyeNuYebBuOLBGc5cfZfT+85KqAGC3EboEn4kgbVIJpSrW+JUNzqtg1c49gzuwmP/48 SgKgvJ5rNnSH+W2txy2M3AR6UPPBMBgqT2SVa1sFjmvxMOm0LLWmOz2sBc4PH+IfSKEB TLWQ== MIME-Version: 1.0 X-Received: by 10.52.31.170 with SMTP id b10mr1395969vdi.115.1372914206587; Wed, 03 Jul 2013 22:03:26 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Wed, 3 Jul 2013 22:03:26 -0700 (PDT) In-Reply-To: <51D4EECE.4010808@freebsd.org> References: <51D3E5BC.1000604@freebsd.org> <51D42976.9020206@freebsd.org> <51D4D77B.60804@freebsd.org> <51D4EECE.4010808@freebsd.org> Date: Wed, 3 Jul 2013 22:03:26 -0700 Message-ID: Subject: Re: Terrible ix performance From: Peter Wemm To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkkC8azUuIKqN5Max5YtYc9rOL/6f6EbfXjHfx7UOTTEZ9KAyoW6I/qKYIki7dS81sw3KjK Cc: Outback Dingo , net@freebsd.org, Steven Hartland , Kevin Oberman X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Jul 2013 05:03:27 -0000 On Wed, Jul 3, 2013 at 8:41 PM, Lawrence Stewart wrote: > - I recall some advice that zpool's should not have more than about 8 or > 10 disks in them, and you should instead create multiple zpools if you > have more disks. Perhaps investigate the source of that rumour and if > it's true, try create 2 x 8 disk zpools in Box A and 3 x 8 disk zpools > in box B and see if that changes things at all. http://nex7.blogspot.com/2013/03/readme1st.html Item #1: "1. Virtual Devices Determine IOPS IOPS (I/O per second) are mostly a factor of the number of virtual devices (vdevs) in a zpool. They are not a factor of the raw number of disks in the zpool. This is probably the single most important thing to realize and understand, and is commonly not. ZFS stripes writes across vdevs (not individual disks). A vdev is typically IOPS bound to the speed of the slowest disk within it. So if you have one vdev of 100 disks, your zpool's raw IOPS potential is effectively only a single disk, not 100. " -- end quote I made this mistake myself a number of times before I found out. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: So you can \342\200\231 .. for when a ' just won't do From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 05:41:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5DC369C8 for ; Thu, 4 Jul 2013 05:41:01 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1A57A1F3A for ; Thu, 4 Jul 2013 05:41:00 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r645exEL044061; Thu, 4 Jul 2013 01:40:59 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r645ewsv044060; Thu, 4 Jul 2013 01:40:58 -0400 (EDT) (envelope-from wollman) Date: Thu, 4 Jul 2013 01:40:58 -0400 (EDT) From: Garrett Wollman Message-Id: <201307040540.r645ewsv044060@hergotha.csail.mit.edu> To: peter@wemm.org Subject: Re: Terrible ix performance In-Reply-To: References: <51D3E5BC.1000604@freebsd.org> <51D42976.9020206@freebsd.org> <51D4D77B.60804@freebsd.org> <51D4EECE.4010808@freebsd.org> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 04 Jul 2013 01:40:59 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Jul 2013 05:41:01 -0000 In article , Peter Wemm quotes some advice about ZFS filesystem vdev layout: >"1. Virtual Devices Determine IOPS >IOPS (I/O per second) are mostly a factor of the number of virtual >devices (vdevs) in a zpool. They are not a factor of the raw number of >disks in the zpool. This is probably the single most important thing >to realize and understand, and is commonly not. > >ZFS stripes writes across vdevs (not individual disks). A vdev is >typically IOPS bound to the speed of the slowest disk within it. So if >you have one vdev of 100 disks, your zpool's raw IOPS potential is >effectively only a single disk, not 100. >" -- end quote > >I made this mistake myself a number of times before I found out. Getting a bit off-topic for this mailing-list, but I'll note that the fileservers that I built earlier this year (which also use the Intel 10G NIC) were able to get nearly good-as-local performance over NFS when connected through a single layer-2 switch. This hardware platform can do (local) about 5 GB/s from ARC, or 1.6 GB/s from disk, both reading single-threaded with compression disabled; writes are about 1.2 GB/s; a single-threaded FreeBSD NFS client could do between 750 MB/s and 1 GB/s, or about 80% of full link speed. The disk configuration here is 11 x 8-disk RAID-Z2 with separate ZIL and L2ARC, but reading is no faster on a 44 x 2-disk mirror. Both of these are on 7200-RPM drives on two 16-port LSI eSAS HBAs with gmultipath interposed for labeling and fault-tolerance. (Both layouts are largely determined by the hardware: we have four 24-drive shelves per server, one SSD and one hot spare per shelf, leaving 88 drives, which only factorizes as 44x2, 22x4, or 11x8, and 22x4 RAID-Z2 has the same capacity as 44x2 mirrored but with higher overhead.) A simple four-disk, two-way mirror configuration (i.e., two mirror vdevs of two disks each) on the same machine can do about 120 MB/s in the same tests. -GAWollman From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 08:16:03 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A4913F46; Thu, 4 Jul 2013 08:16:03 +0000 (UTC) (envelope-from prvs=1897fed9ea=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 21AE6166B; Thu, 4 Jul 2013 08:16:02 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004718354.msg; Thu, 04 Jul 2013 09:16:01 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 04 Jul 2013 09:16:01 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1897fed9ea=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Lawrence Stewart" , "Outback Dingo" References: <51D3E5BC.1000604@freebsd.org> <51D42976.9020206@freebsd.org> <51D4D77B.60804@freebsd.org> <51D4EECE.4010808@freebsd.org> Subject: Re: Terrible ix performance Date: Thu, 4 Jul 2013 09:16:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Kevin Oberman , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Jul 2013 08:16:03 -0000 ----- Original Message ----- >> On Wed, Jul 3, 2013 at 10:01 PM, Lawrence Stewart>> >> On 07/04/13 10:18, Kevin Oberman wrote: >> > On Wed, Jul 3, 2013 at 4:21 PM, Steven Hartland >> >> >> >> Out of interest have you tried limiting the number of queues? >> >> >> >> If not give it a try see if it helps, add the following to >> >> /boot/loader.conf: >> >> hw.ixgbe.num_queues=1 >> >> >> >> If nothing else will give you another data point. >> >> As noted in my first post to this thread, if iperf is able to push a >> single flow at 8Gbps, then the NIC is unlikely to be the source of the >> problem and trying to tune it is a waste of time (at least at this >> stage). >> >> iperf tests memory-network-memory transfer speed without any disk >> involvement, so the fact that it can get 8Gbps and ftp is getting around >> 4Gbps implies that either the iperf TCP tuning is better (only likely to >> be relevant if the RTT is very large - Outback Dingo you still haven't >> provided us with the RTT) or the disk subsystem at one or both ends is >> slowing things down. That may not be all the story, you'll have significantly different data patterns between the two, so don't discount anything till you've tested. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 11:16:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C2839CF3 for ; Thu, 4 Jul 2013 11:16:24 +0000 (UTC) (envelope-from noname.esst@yahoo.com) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id 6A68C1F1A for ; Thu, 4 Jul 2013 11:16:24 +0000 (UTC) Received: from [98.139.215.142] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jul 2013 11:16:18 -0000 Received: from [98.139.212.238] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jul 2013 11:16:18 -0000 Received: from [127.0.0.1] by omp1047.mail.bf1.yahoo.com with NNFMP; 04 Jul 2013 11:16:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 831781.15881.bm@omp1047.mail.bf1.yahoo.com Received: (qmail 82791 invoked by uid 60001); 4 Jul 2013 11:16:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372936578; bh=6BNQHPWSbPL53dKLtHvibjHwuvOne3klXjwPc3gNclI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=LVmDh4hydusBjNue0IqHXYsx5+AY4XxXBZpa8vi8Ew86kptH6XuzSz7dS5DahQzu19F5Ii6CbniuJ83WeTWEptMLJppV+eU4UktVh3yEXNY/qNsjyeKVHtjITEOHUGqA+1uFnIYPQSdKYAk9/hj3H+ctLd5l9v9ospoaF1Ziiy0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=ugO0kTVJq45yNvz7oRGjaXKjwQpWPYgTEHqUiAFEb0Y+qhp2mjMUcgcEDE0VITqmUVNpLuhy2p8gk/GeKwOJGFH/66CEx69QNpHfAaVtR6DJyOGMQryZzPe1JTCtD1lpdanNQDj/UEL/ci0/WAb/ClaNEZBWXa6/QnGoEuunVQ4= ; X-YMail-OSG: ljfqs7QVM1ksbzVREx75S7AcI6PVTlE4fsI0DmqEqQi8Y7s PojLcr3fPpDthKayFKfMpT1Iaum0mufZvTMnOCxCPtEnUPBU7Zbi_c7LfB2v uNSPkJydfrBtr9HeDII5bhjaSWNUe9SGjxf.iKk.E2cK_e7aDceIRgwjbTGw U3vsykoMioc2VgynxHTq0TUQ8behRLlMOc26lrnYEOXyHPsJxgrD.QB1wZ8Y NAerp66x_HQV9b8qIo7_K7s4Bgibi0u.73xHZjVLJCG8TKyUAJS7SO0hNrmv mBk8wQI16C37GgIZCnOu0hsxXrnqzf4jA1rzPT75AiH0SSewC2689aBLICiu 8.gErq5OjGk.4t1izkyJzWDa6_6jBI2dJdytNRK36ZamJB7dY3RyG5MoDWD8 udTUJKCaBDtC.N18P5VYBajWwCmd4SDDcvAOpvrXeH_WoxKpLRkC61wzbdnQ PHvclHD4xMblW97DxXQgrNNwrpq3pri7x_S81dLoU9t7WwS1VokLYWDUtEyr dHtXU9HqyYLugIbNwWba8uA23qK4r57wlkwsuo2H3WS_ig3FhZTick59lV5m ndsaOK7yr1jHq1T3WAPV29KyojjqmF9g9sx4bUXp1_QipKKiE7nVKkd1bOQ- - Received: from [65.49.2.176] by web162701.mail.bf1.yahoo.com via HTTP; Thu, 04 Jul 2013 04:16:18 PDT X-Rocket-MIMEInfo: 002.001, SGkgbGlzdApJIGhhdmUgdGhlIHNhbWUgcHJvYmxlbSBhcyB0aGlzwqBodHRwOi8vc2VjbGlzdHMub3JnL3Nub3J0LzIwMTIvcTQvNDY1CkFmdGVyIHRhbGtpbmcgdG8gdGhpcyBndXksIEhlIHNhaWQgdGhhdCB0aGV5IGNvdWxkIG5vdCBzb2x2ZSB0aGlzIHByb2JsZW0gYW5kIHRoZXkgaGF2ZSBtaWdyYXRlZCB0byBTdXJpY2F0YS4gRG8gaGF2ZSBhbnkgaWRlYXM_IElzIHRoaXMgYSBidWc_ATABAQEB X-Mailer: YahooMailWebService/0.8.148.557 Message-ID: <1372936578.82526.YahooMailNeo@web162701.mail.bf1.yahoo.com> Date: Thu, 4 Jul 2013 04:16:18 -0700 (PDT) From: Nomad Esst Subject: snort does not block packets in inline mode in FreeBSD To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Nomad Esst List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 11:16:24 -0000 Hi list=0AI have the same problem as this=A0http://seclists.org/snort/2012/= q4/465=0AAfter talking to this guy, He said that they could not solve this = problem and they have migrated to Suricata. Do have any ideas? Is this a bu= g? From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 11:40:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 00CE6F3E for ; Thu, 4 Jul 2013 11:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id CE1751FC3 for ; Thu, 4 Jul 2013 11:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r64Be1Bg038536 for ; Thu, 4 Jul 2013 11:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r64Be1tD038535; Thu, 4 Jul 2013 11:40:01 GMT (envelope-from gnats) Date: Thu, 4 Jul 2013 11:40:01 GMT Message-Id: <201307041140.r64Be1tD038535@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Sergey Maltsev Subject: Re: kern/178612: [run] kernel panic due the problems with run driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Sergey Maltsev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 11:40:02 -0000 The following reply was made to PR kern/178612; it has been noted by GNATS. From: Sergey Maltsev To: bug-followup@FreeBSD.org, core.dumped.sm@gmail.com Cc: Subject: Re: kern/178612: [run] kernel panic due the problems with run driver Date: Thu, 4 Jul 2013 17:39:45 +0600 --047d7b3a8016f2661204e0ae0806 Content-Type: text/plain; charset=ISO-8859-1 The problem disappeared. Can make a commit to the releng 8? --047d7b3a8016f2661204e0ae0806 Content-Type: text/html; charset=ISO-8859-1
The problem disappeared. Can make a commit to the releng 8?
--047d7b3a8016f2661204e0ae0806-- From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 12:50:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 17D266E3 for ; Thu, 4 Jul 2013 12:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E31501310 for ; Thu, 4 Jul 2013 12:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r64Co1k0052283 for ; Thu, 4 Jul 2013 12:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r64Co13m052282; Thu, 4 Jul 2013 12:50:01 GMT (envelope-from gnats) Date: Thu, 4 Jul 2013 12:50:01 GMT Message-Id: <201307041250.r64Co13m052282@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Shahar Klein Subject: RE: kern/179999: [ofed] [patch] Bug assigning HCA from IB to ETH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Shahar Klein List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 12:50:02 -0000 The following reply was made to PR kern/179999; it has been noted by GNATS. From: Shahar Klein To: John Baldwin , "bug-followup@freebsd.org" Cc: Orit Moskovich , Oded Shanoon Subject: RE: kern/179999: [ofed] [patch] Bug assigning HCA from IB to ETH Date: Thu, 4 Jul 2013 12:34:09 +0000 Thanks John I've tested this version and it works fine. Shahar Klein -----Original Message----- From: John Baldwin [mailto:jhb@freebsd.org]=20 Sent: Friday, June 28, 2013 12:20 AM To: bug-followup@freebsd.org; Shahar Klein Subject: Re: kern/179999: [ofed] [patch] Bug assigning HCA from IB to ETH Thanks, I think the sysfs fix has a few issues though (it writes to buf[] e= ven if the copyin() fails, and it doesn't enforce a bounds check). It does= seem that this should probably be using sysctl_handle_string() instead of = doing it by hand, but for now I've just adjusted your patch. Can you pleas= e test this version? Index: ofed/drivers/net/mlx4/main.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ofed/drivers/net/mlx4/main.c (revision 252306) +++ ofed/drivers/net/mlx4/main.c (working copy) @@ -479,11 +479,11 @@ int i; int err =3D 0; =20 - if (!strcmp(buf, "ib\n")) + if (!strcmp(buf, "ib")) info->tmp_type =3D MLX4_PORT_TYPE_IB; - else if (!strcmp(buf, "eth\n")) + else if (!strcmp(buf, "eth")) info->tmp_type =3D MLX4_PORT_TYPE_ETH; - else if (!strcmp(buf, "auto\n")) + else if (!strcmp(buf, "auto")) info->tmp_type =3D MLX4_PORT_TYPE_AUTO; else { mlx4_err(mdev, "%s is not supported port type\n", buf); Index: ofed/include/linux/sysfs.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ofed/include/linux/sysfs.h (revision 252306) +++ ofed/include/linux/sysfs.h (working copy) @@ -104,10 +104,15 @@ error =3D SYSCTL_OUT(req, buf, len); if (error || !req->newptr || ops->store =3D=3D NULL) goto out; - error =3D SYSCTL_IN(req, buf, PAGE_SIZE); + len =3D req->newlen - req->newidx; + if (len >=3D PAGE_SIZE) + error =3D EINVAL; + else=20 + error =3D SYSCTL_IN(req, buf, len); if (error) goto out; - len =3D ops->store(kobj, attr, buf, req->newlen); + ((char *)buf)[len] =3D '\0'; + len =3D ops->store(kobj, attr, buf, len); if (len < 0) error =3D -len; out: -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 15:37:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3AFCBB29 for ; Thu, 4 Jul 2013 15:37:19 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 118811D45 for ; Thu, 4 Jul 2013 15:37:18 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-226-51.lns20.per1.internode.on.net [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r64FbErg095516 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 4 Jul 2013 08:37:17 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51D596A5.1050301@freebsd.org> Date: Thu, 04 Jul 2013 23:37:09 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nomad Esst Subject: Re: snort does not block packets in inline mode in FreeBSD References: <1372936578.82526.YahooMailNeo@web162701.mail.bf1.yahoo.com> In-Reply-To: <1372936578.82526.YahooMailNeo@web162701.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Jul 2013 15:37:19 -0000 On 7/4/13 7:16 PM, Nomad Esst wrote: > Hi list > I have the same problem as this http://seclists.org/snort/2012/q4/465 > After talking to this guy, He said that they could not solve this problem and they have migrated to Suricata. Do have any ideas? Is this a bug? > _______________________________________________ > 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" > > > unless divert has been broken,(*) the problem must be in snort. it must be resubmitting the packets to be forwarded. (*)if you look at the packet that are going out of the box after being approved by snort, are there duplicate packets? From owner-freebsd-net@FreeBSD.ORG Thu Jul 4 18:40:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5D032D59 for ; Thu, 4 Jul 2013 18:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4D00D1868 for ; Thu, 4 Jul 2013 18:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r64Ie17C022872 for ; Thu, 4 Jul 2013 18:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r64Ie0Dc022871; Thu, 4 Jul 2013 18:40:00 GMT (envelope-from gnats) Date: Thu, 4 Jul 2013 18:40:00 GMT Message-Id: <201307041840.r64Ie0Dc022871@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: kern/179901: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 18:40:01 -0000 The following reply was made to PR kern/179901; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/179901: commit references a PR Date: Thu, 4 Jul 2013 18:38:19 +0000 (UTC) Author: trociny Date: Thu Jul 4 18:38:00 2013 New Revision: 252710 URL: http://svnweb.freebsd.org/changeset/base/252710 Log: In r227207, to fix the issue with possible NULL inp_socket pointer dereferencing, when checking for SO_REUSEPORT option (and SO_REUSEADDR for multicast), INP_REUSEPORT flag was introduced to cache the socket option. It was decided then that one flag would be enough to cache both SO_REUSEPORT and SO_REUSEADDR: when processing SO_REUSEADDR setsockopt(2), it was checked if it was called for a multicast address and INP_REUSEPORT was set accordingly. Unfortunately that approach does not work when setsockopt(2) is called before binding to a multicast address: the multicast check fails and INP_REUSEPORT is not set. Fix this by adding INP_REUSEADDR flag to unconditionally cache SO_REUSEADDR. PR: 179901 Submitted by: Michael Gmelin freebsd grem.de (initial version) Reviewed by: rwatson MFC after: 1 week Modified: head/sys/netinet/in_pcb.c head/sys/netinet/in_pcb.h head/sys/netinet/ip_output.c head/sys/netinet6/in6_pcb.c head/sys/netinet6/ip6_output.c Modified: head/sys/netinet/in_pcb.c ============================================================================== --- head/sys/netinet/in_pcb.c Thu Jul 4 18:00:27 2013 (r252709) +++ head/sys/netinet/in_pcb.c Thu Jul 4 18:38:00 2013 (r252710) @@ -467,6 +467,23 @@ in_pcb_lport(struct inpcb *inp, struct i return (0); } + +/* + * Return cached socket options. + */ +short +inp_so_options(const struct inpcb *inp) +{ + short so_options; + + so_options = 0; + + if ((inp->inp_flags2 & INP_REUSEPORT) != 0) + so_options |= SO_REUSEPORT; + if ((inp->inp_flags2 & INP_REUSEADDR) != 0) + so_options |= SO_REUSEADDR; + return (so_options); +} #endif /* INET || INET6 */ #ifdef INET @@ -595,8 +612,7 @@ in_pcbbind_setup(struct inpcb *inp, stru if (tw == NULL || (reuseport & tw->tw_so_options) == 0) return (EADDRINUSE); - } else if (t && (reuseport == 0 || - (t->inp_flags2 & INP_REUSEPORT) == 0)) { + } else if (t && (reuseport & inp_so_options(t)) == 0) { #ifdef INET6 if (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || Modified: head/sys/netinet/in_pcb.h ============================================================================== --- head/sys/netinet/in_pcb.h Thu Jul 4 18:00:27 2013 (r252709) +++ head/sys/netinet/in_pcb.h Thu Jul 4 18:38:00 2013 (r252710) @@ -442,6 +442,7 @@ struct tcpcb * inp_inpcbtotcpcb(struct inpcb *inp); void inp_4tuple_get(struct inpcb *inp, uint32_t *laddr, uint16_t *lp, uint32_t *faddr, uint16_t *fp); +short inp_so_options(const struct inpcb *inp); #endif /* _KERNEL */ @@ -543,6 +544,7 @@ void inp_4tuple_get(struct inpcb *inp, #define INP_PCBGROUPWILD 0x00000004 /* in pcbgroup wildcard list */ #define INP_REUSEPORT 0x00000008 /* SO_REUSEPORT option is set */ #define INP_FREED 0x00000010 /* inp itself is not valid */ +#define INP_REUSEADDR 0x00000020 /* SO_REUSEADDR option is set */ /* * Flags passed to in_pcblookup*() functions. Modified: head/sys/netinet/ip_output.c ============================================================================== --- head/sys/netinet/ip_output.c Thu Jul 4 18:00:27 2013 (r252709) +++ head/sys/netinet/ip_output.c Thu Jul 4 18:38:00 2013 (r252710) @@ -900,13 +900,10 @@ ip_ctloutput(struct socket *so, struct s switch (sopt->sopt_name) { case SO_REUSEADDR: INP_WLOCK(inp); - if (IN_MULTICAST(ntohl(inp->inp_laddr.s_addr))) { - if ((so->so_options & - (SO_REUSEADDR | SO_REUSEPORT)) != 0) - inp->inp_flags2 |= INP_REUSEPORT; - else - inp->inp_flags2 &= ~INP_REUSEPORT; - } + if ((so->so_options & SO_REUSEADDR) != 0) + inp->inp_flags2 |= INP_REUSEADDR; + else + inp->inp_flags2 &= ~INP_REUSEADDR; INP_WUNLOCK(inp); error = 0; break; Modified: head/sys/netinet6/in6_pcb.c ============================================================================== --- head/sys/netinet6/in6_pcb.c Thu Jul 4 18:00:27 2013 (r252709) +++ head/sys/netinet6/in6_pcb.c Thu Jul 4 18:38:00 2013 (r252710) @@ -243,8 +243,7 @@ in6_pcbbind(register struct inpcb *inp, if (tw == NULL || (reuseport & tw->tw_so_options) == 0) return (EADDRINUSE); - } else if (t && (reuseport == 0 || - (t->inp_flags2 & INP_REUSEPORT) == 0)) { + } else if (t && (reuseport & inp_so_options(t)) == 0) { return (EADDRINUSE); } #ifdef INET @@ -265,8 +264,8 @@ in6_pcbbind(register struct inpcb *inp, INP_IPV6PROTO) == (t->inp_vflag & INP_IPV6PROTO)))) return (EADDRINUSE); - } else if (t && (reuseport == 0 || - (t->inp_flags2 & INP_REUSEPORT) == 0) && + } else if (t && + (reuseport & inp_so_options(t)) == 0 && (ntohl(t->inp_laddr.s_addr) != INADDR_ANY || (t->inp_vflag & INP_IPV6PROTO) != 0)) return (EADDRINUSE); Modified: head/sys/netinet6/ip6_output.c ============================================================================== --- head/sys/netinet6/ip6_output.c Thu Jul 4 18:00:27 2013 (r252709) +++ head/sys/netinet6/ip6_output.c Thu Jul 4 18:38:00 2013 (r252710) @@ -1477,13 +1477,10 @@ ip6_ctloutput(struct socket *so, struct switch (sopt->sopt_name) { case SO_REUSEADDR: INP_WLOCK(in6p); - if (IN_MULTICAST(ntohl(in6p->inp_laddr.s_addr))) { - if ((so->so_options & - (SO_REUSEADDR | SO_REUSEPORT)) != 0) - in6p->inp_flags2 |= INP_REUSEPORT; - else - in6p->inp_flags2 &= ~INP_REUSEPORT; - } + if ((so->so_options & SO_REUSEADDR) != 0) + in6p->inp_flags2 |= INP_REUSEADDR; + else + in6p->inp_flags2 &= ~INP_REUSEADDR; INP_WUNLOCK(in6p); error = 0; break; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Jul 6 03:13:31 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DC6DD3D1; Sat, 6 Jul 2013 03:13:31 +0000 (UTC) (envelope-from markj@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B4D201249; Sat, 6 Jul 2013 03:13:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r663DVaI052668; Sat, 6 Jul 2013 03:13:31 GMT (envelope-from markj@freefall.freebsd.org) Received: (from markj@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r663DVtF052667; Sat, 6 Jul 2013 03:13:31 GMT (envelope-from markj) Date: Sat, 6 Jul 2013 03:13:31 GMT Message-Id: <201307060313.r663DVtF052667@freefall.freebsd.org> To: mm@FreeBSD.org, markj@FreeBSD.org, freebsd-net@FreeBSD.org, jfv@FreeBSD.org From: markj@FreeBSD.org Subject: Re: kern/155030: [igb] igb(4) DEVICE_POLLING does not work with carp(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 06 Jul 2013 03:13:31 -0000 Synopsis: [igb] igb(4) DEVICE_POLLING does not work with carp(4) State-Changed-From-To: patched->closed State-Changed-By: markj State-Changed-When: Sat Jul 6 03:13:23 UTC 2013 State-Changed-Why: The fix was merged to stable/9 in r239109 and stable/8 in r247430. Responsible-Changed-From-To: freebsd-net->jfv Responsible-Changed-By: markj Responsible-Changed-When: Sat Jul 6 03:13:23 UTC 2013 Responsible-Changed-Why: The fix was merged to stable/9 in r239109 and stable/8 in r247430. http://www.freebsd.org/cgi/query-pr.cgi?pr=155030 From owner-freebsd-net@FreeBSD.ORG Sat Jul 6 07:47:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5056991D; Sat, 6 Jul 2013 07:47:34 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1C31C56; Sat, 6 Jul 2013 07:47:34 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id x11so2592678pdj.15 for ; Sat, 06 Jul 2013 00:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RI6yuqpvL3VTKhUkJaBcVu5ksaTSNsg8meWPuD3YTpg=; b=MIMXednR4oXN3d4qKFDe5aMdDDfsMEQusruaOfXa+wpC02soDPbF7shMcOF0jfY8zx 6X7YobpLCq/HZGHjrvCynlQAGGACaClbJtljgndYbXcGHCK9J4AhuFsi09qXi0RkcPIH Uvph1CrkWMWk3EHlYIsm2rcV4WdbLDHmVj6dM7lID9jKxWjc403i6OBHfTEurNPz2OZ3 cjfG2dPXvCdIraOZTuOssgI0McxYp/Edyhuq94cjScnE9SqoUIDcQhfMHFrm4wNjFH1b lMr4p50CQY4NpmDWZ5okB5oxQd9tr3oeB0+fMDbqkrBYdTI7OgluSjdWYQ4wd/GWaaN9 lBIg== MIME-Version: 1.0 X-Received: by 10.68.169.97 with SMTP id ad1mr12582108pbc.84.1373096853465; Sat, 06 Jul 2013 00:47:33 -0700 (PDT) Received: by 10.70.71.7 with HTTP; Sat, 6 Jul 2013 00:47:33 -0700 (PDT) Received: by 10.70.71.7 with HTTP; Sat, 6 Jul 2013 00:47:33 -0700 (PDT) In-Reply-To: References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> <51D15D06.9030300@grosbein.net> <51D390CA.5020803@freebsd.org> <51D3A1A0.8090904@freebsd.org> <51D3A35C.8070305@freebsd.org> Date: Sat, 6 Jul 2013 10:47:33 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, Eugene Grosbein , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 06 Jul 2013 07:47:34 -0000 Hi, Any hope? Thanks in advance, Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 3 =D7=91=D7=99=D7=95=D7=9C 2013 14:06,= =D7=9E=D7=90=D7=AA "Sami Halabi" : > Hi Julian, > > I appreciate your willing to help me. > > My Situation in short is: > > ----------- [a] ------------------------- [b] ------------- > internet B |---BGP---|84.xx.yy.1 192.168.0.1|-----|192.168.0.2/24 > 193.xx.yy.2| |Aem1 Cem3 D em0| | | neighbour > ----------- ------------------------- | -------------- > | | | > [Q] | | > your networks private network > > I Have control only over the middle machine, so i cant establish a tunnel= . > So I want it to act as MAN IN THE MIDDLE/ proxy. > every packet comes from private network to 192.168.0.1 ie: > packet hdr: src: 192.168.0.2 dst 192.168.0.1 > should be translated as: > packet hdr: src: 84.xx.yy.1 dst 193.xx.yy.2 > ports and data untouched. > > and every packet from 193.xx.yy.2 (incoming/setup...) as: > packet hdr: src: 193.xx.yy.2 dst: 84.xx.yy.1 > to be translated as: > packet hdr: src: 192.168.0.1 dst 192.168.0.2 > > btw: any other packet from src other than 193.xx.yy.2 to dst 84.xx.yy.1 > should be dropped. > > > Again thanks for you help, I hope I supplied all the info needed to help > me. > Sami > > > > On Wed, Jul 3, 2013 at 7:06 AM, Julian Elischer wrote= : > >> On 7/3/13 11:59 AM, Julian Elischer wrote: >> >>> On 7/3/13 10:47 AM, Julian Elischer wrote: >>> >>>> On 7/2/13 10:21 PM, Sami Halabi wrote: >>>> >>>>> Hi again, >>>>> So far no solution.... >>>>> >>>>> Is there really no alternative in FreeBSD? >>>>> >>>> >>>> oh I'm sure there are several solutions.. >>>> I looked at the original email but have since deleted it.. >>>> >>>> ah archives to the rescue.... >>>> >>>> ok so your request is a bit short on information.. >>>> >>> >>> thinking about your request I think what you want to do is to make it >>> look as if you have a web server or something at 192.168.0.1 to your >>> neighbour, but to in fact serve those requests from a machine at >>> 193.xxx.yyy.2. In addition, you need the requests to appear to come fro= m >>> your external address, so that the responses can find their way back to= you. >>> >>> my next question is: Do you control 193.xxx.yyy.2? (is it FreeBSD?) >>> because there are several ways you could solve that problem if you do, >>> and it is.. >>> basically by making a tunnel directly between that machine and you. >>> >>> if you want to not use a tunnel there are several steps on the way. >>> we need to think abut what packets look like at each step. >>> >>> at em0, incoming >>> >>> packet A from neighbour, on the wire: >>> To: 192.168.0.1 port 80 >>> From: 192.168.0.x port MMM0 >>> we want to change this packet. >>> >>> packet B from neighbour, on the wire: >>> To: www.google.com port 80 >>> From: 192.168.0.x port MMM1 >>> we want to leave this packet alone (for now) >>> >>> At this stage, (on the incoming packet A on em0) >>> we need to change the DESTINATION address, >>> so we need a regular NAT, acting as if it were accepting an incoming >>> connection. >>> (which it is). >>> >>> so from the natd man page, the NAT 'rule' is: >>> redirect_address 193.xxx.yyy.2 192.168.0.1 >>> >>> This must only happen on incoming packets from the neighbour, *addresse= d >>> to you* so >>> >>> ipfw has a rule: >>> ipfw add xx ${NAT_ACTION} ip from ${NEIGHBOUR_NET} to >>> ${MY_NIGHBOUR_ADDR} in recv ${MY_NEIGHBOUR_IFACE} >>> >>> NAT_ACTION is either "nat 1" or "divert ${INTERNAL_DIVER_PORT} >>> MY_NEIGHBOUR_ADDR=3D"192.168.0.**0/24 " >>> MY_NEIGHBOUR_IFACE=3D"em0" >>> >>> now you need a rule to match this one for retranslation of return packe= ts >>> so on output you have: >>> ipfw add yy ${NAT_ACTION} ip from 193.xxx.yyy.zzz to ${NEIGHBOUR_NET} >>> out xmit ${MY_NEIGHBOUR_IFACE} >>> >>> and the nat must be set up to leave unmapped packets alone. >>> so deny_incoming must NOT be set in the NAT configuration. >>> >> >> I am talking all theoretically here as I don't have such a setup at the >> moment, >> and I can't remember if the packet direction is given to natd/ipfw-nat >> if so then you MAY need the 'reverse' setting, but I don't guarantee it. >> >> If you use natd you will need a separae instance, or natd. If you use >> ipfw internal nat >> then you must use a separate nat instance there too. >> >> >>> >>> >>> so theoretically this is the destination address taken care of (in >>> outgoing packets, source address on incoming packets). >>> >>> So then you need to take care of the source address of the outgoing >>> packets. >>> this takes place on the INTERNET facing interface, and really, it shoul= d >>> all be taken care of already if you have NAT enabled and you can ping t= he >>> internet from the neighbour's net. >>> >>> >>> hope this helps.... >>> >>> Julian >>> >>> >>> >>> >>> >> > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert > From owner-freebsd-net@FreeBSD.ORG Sat Jul 6 11:38:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 82C9BDDA; Sat, 6 Jul 2013 11:38:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id DEE5312E2; Sat, 6 Jul 2013 11:38:05 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id r66Bc0SF091595; Sat, 6 Jul 2013 18:38:00 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <51D80193.5080401@grosbein.net> Date: Sat, 06 Jul 2013 18:37:55 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Sami Halabi Subject: Re: DNAT in freebsd References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> <51D15D06.9030300@grosbein.net> <51D390CA.5020803@freebsd.org> <51D3A1A0.8090904@freebsd.org> <51D3A35C.8070305@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 06 Jul 2013 11:38:06 -0000 On 06.07.2013 14:47, Sami Halabi wrote: > Hi, > Any hope? Have you used intedmediate "ipfw count log" rules between "ipfw nat" rules I recommended? If yes, why have not you show that logs yet? Include tcpdump output from external and internal interfaces too. From owner-freebsd-net@FreeBSD.ORG Sat Jul 6 13:02:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 75C37F81; Sat, 6 Jul 2013 13:02:47 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id DA9BD1754; Sat, 6 Jul 2013 13:02:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r66D2a4M027697; Sat, 6 Jul 2013 23:02:36 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 6 Jul 2013 23:02:36 +1000 (EST) From: Ian Smith To: Sami Halabi Subject: Re: DNAT in freebsd In-Reply-To: <51D80193.5080401@grosbein.net> Message-ID: <20130706224310.R26496@sola.nimnet.asn.au> References: <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> <51D15D06.9030300@grosbein.net> <51D390CA.5020803@freebsd.org> <51D3A1A0.8090904@freebsd.org> <51D3A35C.8070305@freebsd.org> <51D80193.5080401@grosbein.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Eugene Grosbein , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 06 Jul 2013 13:02:47 -0000 On Sat, 6 Jul 2013 18:37:55 +0700, Eugene Grosbein wrote: > On 06.07.2013 14:47, Sami Halabi wrote: > > Hi, > > Any hope? > > Have you used intedmediate "ipfw count log" rules between "ipfw nat" rules > I recommended? If yes, why have not you show that logs yet? > Include tcpdump output from external and internal interfaces too. Sami, this was very good advice. I'll go further and say add _lots_ of 'count log' rules before and after each nat rule, one each for packets you might expect from different sources of interest, and to different destinations expected from your nat mapping, and also the unexpected. Then run some test packets, afterwards running 'ipfw -t show' so you (and we) can clearly see which packets went which way and when. This may help debugging greatly; we need you to tell less, and show us more. Julian also put some time into a well detailed plan, based of course on assumptions reached with not a lot to go on; you should try using that, and feeding back some very specific results. cheers, Ian