From owner-freebsd-net@FreeBSD.ORG Sun Mar 15 01:28:46 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5317D3C6 for ; Sun, 15 Mar 2015 01:28:46 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3959161A for ; Sun, 15 Mar 2015 01:28:46 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2F1Skb2056970 for ; Sun, 15 Mar 2015 01:28:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 192325] [PATCH] snmp_pf: add support for retrieving ALTQ counters Date: Sun, 15 Mar 2015 01:28:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: philip@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: philip@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Mar 2015 01:28:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192325 Philip Paeps changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |philip@FreeBSD.org Status|New |In Progress CC| |philip@FreeBSD.org --- Comment #1 from Philip Paeps --- I perpetrated snmp_pf, once upon a time. This patch looks sane. I'll do some more testing and commit it. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Mar 15 04:36:05 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA3AB3DB for ; Sun, 15 Mar 2015 04:36:05 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90531945 for ; Sun, 15 Mar 2015 04:36:05 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2F4a5jB046652 for ; Sun, 15 Mar 2015 04:36:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193762] [cc_cdg] crash after change net.inet.tcp.cc.cdg.smoothing_factor Date: Sun, 15 Mar 2015 04:36:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Mar 2015 04:36:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193762 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org Keywords| |patch -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Mar 15 06:36:57 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A65B58D; Sun, 15 Mar 2015 06:36:57 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB2C33E2; Sun, 15 Mar 2015 06:36:56 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 63FDD100E2; Sun, 15 Mar 2015 07:36:52 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 2196D780E0; Sun, 15 Mar 2015 07:36:51 +0100 (CET) Date: Sun, 15 Mar 2015 07:36:51 +0100 From: Kristof Provost To: freebsd-net@freebsd.org Subject: Padded packets in ip6_input() Message-ID: <20150315063651.GA2036@vega.codepro.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Philip Paeps X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Mar 2015 06:36:57 -0000 Hi, While having a quick look at PR 169630 I wound up looking at what happens with short IP and IPv6 packets in their input paths. On Ethernet frames have to have a minimum size and for both legacy and modern IP it's possible to have shorter packets. In that case the sender just adds some padding after the packet so it can be transported over Ethernet. The way we deal with that is different for IPv4 and IPv6. In v4 we check packet size (is the packet big enough for what IP claims the size is) and remove the trailing bytes very early in the processing. In ip6_input() that isn't done until after the pfil() hook and nexthop processing. I think it's risky to wait with the check and trim (as in PR 169360: it's possible firewalls would reassemble and include the padding. That'd be a bug in the firewall of course, but this would ensure it couldn't happen at all). On the flip size, I see no downside of doing the size check earlier. We have to check the packet size anyway. Below is a patch which does just that. commit 04efb7e62ab6ae2d3bdac362b1da8a1de9f0a531 Author: Kristof Provost Date: Sun Mar 15 05:25:00 2015 +0100 Check ip6 packet size and trim before the firewall In the ip6 input path we don't check the packet size ("Is the entire IP frame there?") or trim it down (e.g. on Ethernet where short packets get padding at the tail) until after the pfil() hook. That means that the firewall can get packets with unwanted trailing bytes. This could cause issues with careless reassembly code. There's no reason to wait with this check so align with the ip4 input path and do the check before the pfil() hook. Note that we re-read the plen after the pfil() hook, just in case the firewall code does something to the packet length. This may or may not be required. diff --git a/sys/netinet6/ip6_input.c b/sys/netinet6/ip6_input.c index 78e8ef3..d7b20fa 100644 --- a/sys/netinet6/ip6_input.c +++ b/sys/netinet6/ip6_input.c @@ -563,6 +563,26 @@ ip6_input(struct mbuf *m) in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_addrerr); goto bad; } + + /* + * Check that the amount of data in the buffers + * is as at least much as the IPv6 header would have us expect. + * Trim mbufs if longer than we expect. + * Drop packet if shorter than we expect. + */ + plen = (u_int32_t)ntohs(ip6->ip6_plen); + if (m->m_pkthdr.len - sizeof(struct ip6_hdr) < plen) { + IP6STAT_INC(ip6s_tooshort); + in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_truncated); + goto bad; + } + if (m->m_pkthdr.len > sizeof(struct ip6_hdr) + plen) { + if (m->m_len == m->m_pkthdr.len) { + m->m_len = sizeof(struct ip6_hdr) + plen; + m->m_pkthdr.len = sizeof(struct ip6_hdr) + plen; + } else + m_adj(m, sizeof(struct ip6_hdr) + plen - m->m_pkthdr.len); + } #if 0 /* * Reject packets with IPv4 compatible addresses (auto tunnel). @@ -702,25 +722,6 @@ passin: nxt = ip6->ip6_nxt; /* - * Check that the amount of data in the buffers - * is as at least much as the IPv6 header would have us expect. - * Trim mbufs if longer than we expect. - * Drop packet if shorter than we expect. - */ - if (m->m_pkthdr.len - sizeof(struct ip6_hdr) < plen) { - IP6STAT_INC(ip6s_tooshort); - in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_truncated); - goto bad; - } - if (m->m_pkthdr.len > sizeof(struct ip6_hdr) + plen) { - if (m->m_len == m->m_pkthdr.len) { - m->m_len = sizeof(struct ip6_hdr) + plen; - m->m_pkthdr.len = sizeof(struct ip6_hdr) + plen; - } else - m_adj(m, sizeof(struct ip6_hdr) + plen - m->m_pkthdr.len); - } - - /* * Forward if desirable. */ if (V_ip6_mrouter && From owner-freebsd-net@FreeBSD.ORG Sun Mar 15 10:38:44 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 691C9E for ; Sun, 15 Mar 2015 10:38:44 +0000 (UTC) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23532DAC for ; Sun, 15 Mar 2015 10:38:44 +0000 (UTC) Received: by qcbkw5 with SMTP id kw5so22172769qcb.2 for ; Sun, 15 Mar 2015 03:38:42 -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=s7SLogciVE3FGA2UbJaJ336wPDYk9J+lqFR25JHYsow=; b=w1OGsX2k8rlys3bK3H0xKSCJRvUunkP0fMh+i+ithE0ribluGjiCKilFHkYb0JY4hA osSHkR/y6kCLVa2QovNwCw9KjvR8d6e0tbLklysUb4VZPvmwko0Puk6isRb1Y9MxXyaG SLMs7w/QJMQHp6ABKrrBTkSPTDKERxU0CqZV720nz0Ev4OtH0OTcw3ja0NORZfkyxTWv Cjw87YZrnB4pbNw3YkAv1Q6NAPE/LNKBU+u+8/nAC2lh/sNqUO4LEjYLCaq+BiK9wPE0 Ms4SPPMnZZ3PNCCjYWAs13YXeTqnSOAfZ2KFEeQumerCbKjhvwq3pxViaBfV+L0gyo1d Ec3Q== MIME-Version: 1.0 X-Received: by 10.140.145.9 with SMTP id 9mr69161053qhr.104.1426415922899; Sun, 15 Mar 2015 03:38:42 -0700 (PDT) Received: by 10.229.226.1 with HTTP; Sun, 15 Mar 2015 03:38:42 -0700 (PDT) Date: Sun, 15 Mar 2015 12:38:42 +0200 Message-ID: Subject: Unbalanced LACP link From: Vitalii Duk To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Mar 2015 10:38:44 -0000 Hello, guys. I have a problem with my LACP link (2*1GbE) between FreeBSD 10 and D-Link DGS-3610-26G switch. This link worked fine last two years on FreeBSD 9.2-STABLE, but when I've updated my FreeBSD to 10.1-RELEASE traffic started to go mostly through one interface. lagg0 - input interface (no IP-address, only VLANs). lagg1 - output interface. [router]# ifconfig lagg0 lagg0: flags=8843 metric 0 mtu 1500 options=400b8 ether 90:e2:ba:02:d0:ae nd6 options=29 media: Ethernet autoselect status: active laggproto lacp lagghash l2 laggport: igb1 flags=1c laggport: igb0 flags=1c [#router]# ifconfig lagg1 lagg1: flags=8843 metric 0 mtu 1500 options=400b8 ether 00:1b:21:93:52:d4 inet 172.16.204.9 netmask 0xfffffff8 broadcast 172.16.204.15 nd6 options=29 media: Ethernet autoselect status: active laggproto lacp lagghash l2 laggport: igb3 flags=1c laggport: igb2 flags=1c [router]# netstat -hw1 -I igb0 input igb0 output packets errs idrops bytes packets errs bytes colls 27K 0 0 12M 5 0 350 0 26K 0 0 12M 7 0 693 0 29K 0 0 12M 8 0 838 0 29K 0 0 11M 10 0 1.0K 0 27K 0 0 10M 7 0 770 0 As you can see most traffic is going through igb1 (lagg0) and igb3 (lagg1) interfaces. In peak times there are more that 1 Gbps of traffic mostly through one 1GbE interface, and it cause an errors. So this link is assymetric. [router]# netstat -hw1 -I igb1 input igb1 output packets errs idrops bytes packets errs bytes colls 22K 0 0 8.5M 63K 0 69M 0 20K 0 0 7.7M 58K 0 62M 0 20K 0 0 7.3M 57K 0 61M 0 19K 0 0 6.8M 56K 0 61M 0 18K 0 0 6.5M 57K 0 62M 0 [router]# netstat -hw1 -I igb2 input igb2 output packets errs idrops bytes packets errs bytes colls 40K 0 0 49M 1 0 93 0 41K 0 0 51M 1 0 88 0 38K 0 0 45M 1 0 88 0 33K 0 0 39M 2 0 174 0 31K 0 0 35M 1 0 89 0 [router]# netstat -hw1 -I igb3 input igb3 output packets errs idrops bytes packets errs bytes colls 32K 0 0 34M 44K 0 18M 0 29K 0 0 30M 45K 0 18M 0 32K 0 0 34M 48K 0 17M 0 28K 0 0 29M 42K 0 15M 0 25K 0 0 26M 40K 0 16M 0 [router]# netstat -hw1 -I lagg0 input lagg0 output packets errs idrops bytes packets errs bytes colls 45K 0 0 17M 62K 0 69M 0 46K 0 0 17M 66K 0 75M 0 43K 0 0 17M 62K 0 69M 0 50K 0 0 19M 71K 1 82M 0 46K 0 0 18M 66K 0 75M 0 [router]# netstat -hw1 -I lagg1 input lagg1 output packets errs idrops bytes packets errs bytes colls 70K 0 0 79M 49K 0 18M 0 71K 0 0 79M 49K 0 19M 0 79K 0 0 91M 54K 0 20M 0 65K 0 0 72M 45K 0 17M 0 65K 0 0 72M 45K 0 17M 0 All igb interfaces are the same: igb0@pci0:1:0:0: class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82576 Gigabit Network Connection' class = network subclass = ethernet I've tried to disable/enable strict_mode, put switch into active/passive mode and trying to set duplex/speed manyally. Nothing helps. Also I've changed lagghash from l2,l3,l4 to l2 only on FreeBSD because switch supports only l2 load-balancing, but it also doesn't helps. net.link.lagg.lacp.debug: 0 net.link.lagg.0.lacp.lacp_strict_mode: 0 net.link.lagg.0.lacp.debug.rx_test: 0 net.link.lagg.0.lacp.debug.tx_test: 0 net.link.lagg.1.lacp.lacp_strict_mode: 0 net.link.lagg.1.lacp.debug.rx_test: 0 net.link.lagg.1.lacp.debug.tx_test: 0 I've read that there were some problems with LACP on FreeBSD 10. Information from the switch: # show lacp summary Aggregate port 6: Local information: LACP port Oper Port Port Port Flags State Priority Key Number State ---------------------------------------------------------------------- Gi0/18 SP bndl 4096 0x6 0x12 0x3c Gi0/22 SP bndl 4096 0x6 0x16 0x3c Partner information: LACP port Oper Port Port Port Flags Priority Dev ID Key Number State --------------------------------------------------------------------- Gi0/18 SA 32768 001b.2193.52d4 0x12b 0x3 0x3d Gi0/22 SA 32768 001b.2193.52d4 0x12b 0x4 0x3d Aggregate port 7: Local information: LACP port Oper Port Port Port Flags State Priority Key Number State ---------------------------------------------------------------------- Gi0/19 SP bndl 4096 0x7 0x13 0x3c Gi0/21 SP bndl 4096 0x7 0x15 0x3c Partner information: LACP port Oper Port Port Port Flags Priority Dev ID Key Number State --------------------------------------------------------------------- Gi0/19 SA 32768 90e2.ba02.d0ae 0x10b 0x1 0x3d Gi0/21 SA 32768 90e2.ba02.d0ae 0x10b 0x2 0x3d From owner-freebsd-net@FreeBSD.ORG Sun Mar 15 13:01:17 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 482D3B35 for ; Sun, 15 Mar 2015 13:01:17 +0000 (UTC) Received: from relay.netserv.kiev.ua (relay.netserv.kiev.ua [77.88.208.26]) by mx1.freebsd.org (Postfix) with ESMTP id C9F4CE45 for ; Sun, 15 Mar 2015 13:01:16 +0000 (UTC) Received: from 00-w01.mgcnet.local (sa1.mcnet [172.26.139.41]) by relay.netserv.kiev.ua (8.13.5/8.13.5) with ESMTP id t2FCmU1w029419 for ; Sun, 15 Mar 2015 14:48:31 +0200 Date: Sun, 15 Mar 2015 13:46:50 +0200 From: Subscriber Reply-To: Subscriber X-Priority: 3 (Normal) Message-ID: <109182408.20150315134650@agoris.net.ua> To: freebsd-net@freebsd.org Subject: Re: Unbalanced LACP link In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Mar 2015 13:01:17 -0000 Hello Vitalii, Sunday, March 15, 2015, 12:38:42 PM, you wrote: > Hello, guys. > I have a problem with my LACP link (2*1GbE) between FreeBSD 10 and D-Link > DGS-3610-26G switch. This link worked fine last two years on FreeBSD > 9.2-STABLE, but when I've updated my FreeBSD to 10.1-RELEASE traffic > started to go mostly through one interface. I have similar problem with FreeBSD 10.1 and Cisco 3750. # uname -srmp FreeBSD 10.1-RELEASE-p5 amd64 amd64 # ifconfig lagg0 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3Dc01bb ether 00:1d:09:66:d8:d1 inet XXX netmask 0xffffff00 broadcast XXX media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: bce1 flags=3D1c laggport: bce0 flags=3D1c --=20 Best regards, Subscriber mailto:ml-lists@agoris.net.ua From owner-freebsd-net@FreeBSD.ORG Sun Mar 15 13:30:23 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDE00363; Sun, 15 Mar 2015 13:30:23 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 980E7E1; Sun, 15 Mar 2015 13:30:23 +0000 (UTC) Received: from smtp3m.mail.yandex.net (smtp3m.mail.yandex.net [77.88.61.130]) by forward7l.mail.yandex.net (Yandex) with ESMTP id AC66CBC1054; Sun, 15 Mar 2015 16:30:19 +0300 (MSK) Received: from smtp3m.mail.yandex.net (localhost [127.0.0.1]) by smtp3m.mail.yandex.net (Yandex) with ESMTP id 27B4B27A038F; Sun, 15 Mar 2015 16:30:19 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:6::bb]) by smtp3m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id vxyKT49d6m-UIamZA6p; Sun, 15 Mar 2015 16:30:18 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1426426218; bh=/hjYmjHLKMB4zKcSKVY5l709gSH0uWqpPFJLVbclB2E=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=VDxAFyjQpUNpBp5hKq1GmS/xBW0L86OK7awyuqmH6jC9tqQuWMOGpz5J0I0uuD2jE ecV1coeUp8CCIi/BxnYMl5A2fLMZbtI+Mo2zQSajsJWsiLyKfVi0yGgBFk1yYZcSes +9f5CmKPYIXWVon2FMn8Zt8F+f8pdaG+RENmwu2g= Authentication-Results: smtp3m.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5505891E.4060109@yandex.ru> Date: Sun, 15 Mar 2015 16:29:02 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kristof Provost , freebsd-net@freebsd.org Subject: Re: Padded packets in ip6_input() References: <20150315063651.GA2036@vega.codepro.be> In-Reply-To: <20150315063651.GA2036@vega.codepro.be> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fehWO7T0modUimUf4LW491lNlD2t7dSp1" Cc: Philip Paeps X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Mar 2015 13:30:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fehWO7T0modUimUf4LW491lNlD2t7dSp1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 15.03.2015 09:36, Kristof Provost wrote: > Hi, >=20 > While having a quick look at PR 169630 I wound up looking at what > happens with short IP and IPv6 packets in their input paths. >=20 > On Ethernet frames have to have a minimum size and for both legacy and > modern IP it's possible to have shorter packets. In that case the sende= r > just adds some padding after the packet so it can be transported over > Ethernet. >=20 > The way we deal with that is different for IPv4 and IPv6. In v4 we chec= k > packet size (is the packet big enough for what IP claims the size is) > and remove the trailing bytes very early in the processing. In > ip6_input() that isn't done until after the pfil() hook and nexthop > processing. >=20 > I think it's risky to wait with the check and trim (as in PR 169360: > it's possible firewalls would reassemble and include the padding. That'= d > be a bug in the firewall of course, but this would ensure it couldn't > happen at all). > On the flip size, I see no downside of doing the size check earlier. We= > have to check the packet size anyway. >=20 > Below is a patch which does just that. >=20 > commit 04efb7e62ab6ae2d3bdac362b1da8a1de9f0a531 > Author: Kristof Provost > Date: Sun Mar 15 05:25:00 2015 +0100 >=20 > Check ip6 packet size and trim before the firewall > =20 > In the ip6 input path we don't check the packet size ("Is the entir= e IP > frame there?") or trim it down (e.g. on Ethernet where short packet= s get > padding at the tail) until after the pfil() hook. > That means that the firewall can get packets with unwanted trailing= > bytes. This could cause issues with careless reassembly code. > There's no reason to wait with this check so align with the ip4 inp= ut > path and do the check before the pfil() hook. > =20 > Note that we re-read the plen after the pfil() hook, just in case t= he > firewall code does something to the packet length. This may or may = not > be required. >=20 > diff --git a/sys/netinet6/ip6_input.c b/sys/netinet6/ip6_input.c > index 78e8ef3..d7b20fa 100644 > --- a/sys/netinet6/ip6_input.c > +++ b/sys/netinet6/ip6_input.c > @@ -563,6 +563,26 @@ ip6_input(struct mbuf *m) > in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_addrerr); > goto bad; > } > + > + /* > + * Check that the amount of data in the buffers > + * is as at least much as the IPv6 header would have us expect. > + * Trim mbufs if longer than we expect. > + * Drop packet if shorter than we expect. > + */ > + plen =3D (u_int32_t)ntohs(ip6->ip6_plen); > + if (m->m_pkthdr.len - sizeof(struct ip6_hdr) < plen) { > + IP6STAT_INC(ip6s_tooshort); > + in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_truncated); > + goto bad; > + } This is very rare case, I think, but plen can be zero in case, when jumbo payload option is present. Probably this is the reason why this check is done after hop-by-hop options parsing. --=20 WBR, Andrey V. Elsukov --fehWO7T0modUimUf4LW491lNlD2t7dSp1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVBYkeAAoJEAHF6gQQyKF6dTQIAITQOJ19+d7BElpTRb/klmCf Dqic08AxBckG72MBU2WuzYo7YPgJRQinAHMJG6IJuTmf6r1ngIOQ0F73pVnpW8fp zW9zN5CcedPkqRZZ+Z0bxiudU3hhfD3YlVfowutRFxV+GY72Z1PIQLU5OtYqKTD6 kQfJo/HaaeGNcMUXitWsfrm2Dk+4dgaCvQNSlcmkzNDDIZwMMY77qMnlJ9nqtnQ1 PWZm10diCfRw+TlfpwFG0LvH1tJ0Rm8YXqBPqH3RaoIEQWwtqF8Fxodg+ARBZd7N qSP1h9oDeDj+jNPb3g0/GiRgDrhN5uKOKXlG7DCJWCNYWTygGSjoRrQVzv/Owns= =9F/B -----END PGP SIGNATURE----- --fehWO7T0modUimUf4LW491lNlD2t7dSp1-- From owner-freebsd-net@FreeBSD.ORG Sun Mar 15 19:57:47 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98A37A53 for ; Sun, 15 Mar 2015 19:57:47 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7FAD6C06 for ; Sun, 15 Mar 2015 19:57:47 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2FJvlct054833 for ; Sun, 15 Mar 2015 19:57:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 198580] Kernel panic when destroying VLANs with traffic Date: Sun, 15 Mar 2015 19:57:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Mar 2015 19:57:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198580 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Mar 15 21:00:05 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC8819E7 for ; Sun, 15 Mar 2015 21:00:05 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B39C2359 for ; Sun, 15 Mar 2015 21:00:05 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2FL05Mo053499 for ; Sun, 15 Mar 2015 21:00:05 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201503152100.t2FL05Mo053499@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 15 Mar 2015 21:00:05 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Mar 2015 21:00:05 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 197535 | [re] [panic] if_re (Realtek 8168) causes memory w 1 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Sun Mar 15 23:49:21 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EABFAD4D for ; Sun, 15 Mar 2015 23:49:20 +0000 (UTC) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DB4D9AD for ; Sun, 15 Mar 2015 23:49:19 +0000 (UTC) Received: by lamx15 with SMTP id x15so26757551lam.3 for ; Sun, 15 Mar 2015 16:49:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=jWY27SPfe4psrcAar0Fer550FbyDkOOhYn+u8FBdWr4=; b=SVLwS1N8djl0OcXfy75wSt5XrgbNMeZZmc6R6/YqOixS6jofkc08yn2halVjX29LQh /rkSGzmF3oWUIs8XnlhAo8LNuQczw8bOrFpw53tVZn2/EHDXIRr68qJci0MgJ2lwgdQy 7q8jaU5qcEFxpxq9UEdNTiThzcZPluSnTpS50dBH82ck32NdmNR0N/w0o1V9pXS6G/e5 /1B0xsNZkgda2zVEih/TeO+otZm61S9xE9fMEp0ASpdBLWdcWh+k9E/VKj8QrP29mTLT 8fjlfYP+DbIXh3N79hz21Yg5XgaL0+0mhVu+krqzT3hJaxbP/NfyWZUa1A2kBu6GJU0h Q33g== X-Gm-Message-State: ALoCoQmp3XSbUZZ1Kk3ol+t3La5U4rlJlBePaDn0xebLHSprPc18kfoMWJBl31G1XFdzf35Geb5s X-Received: by 10.112.50.38 with SMTP id z6mr31487229lbn.122.1426463350615; Sun, 15 Mar 2015 16:49:10 -0700 (PDT) Received: from kde4.my.domain (pppoe.178-66-19-232.dynamic.avangarddsl.ru. [178.66.19.232]) by mx.google.com with ESMTPSA id n12sm1835786lbg.31.2015.03.15.16.49.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Mar 2015 16:49:09 -0700 (PDT) From: Oleg Ginzburg To: Bryan Venteicher Subject: Re: SIOCSVH, SIOCGVH ioctl(2) and virtio ethernet driver Date: Mon, 16 Mar 2015 02:49:58 +0300 Message-ID: <3860521.yJlCc0OyhB@kde4.my.domain> User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <36413168.TE9MLvZCzL@kde4.my.domain> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Mar 2015 23:49:21 -0000 On Monday 29 December 2014 14:18:01 Bryan Venteicher wrote: > On Fri, Dec 26, 2014 at 8:09 AM, Oleg Ginzburg wrote: > > is it possible to use the carp(4) protocol with > > vtnet(4) interfaces ( which is used, for example, in bhyve(8) ) > > Currently, the standard carp init operation causes an SIOCGVH error: > > > > /sbin/ifconfig vtnet0 vhid 1 advskew 100 pass pass 10.10.10.10/24 alias > > ifconfig: SIOCGVH: Protocol not supported > > You probably don't have the carp(4) module loaded. Sorry for delay. Unfortunately the problem somewhere else. Depending on the FreeBSD revision there is a different behavior except usual. E.g: a) 10.1-RELEASE and 10-STABLE: % kldload carp % kldstat -m carp Id Refs Name 486 1 carp % /sbin/ifconfig vtnet0 vhid 1 advskew 100 pass navuhodonosor 192.168.1.210/24 state master alias ifconfig: SIOCSVH: Invalid argument b) On FreeBSD-current r276500M CARP IP is established for some seconds, then vanishes: % /sbin/ifconfig vtnet0 vhid 1 advskew 100 pass navuhodonosor 192.168.1.210/24 state master alias % ifconfig vtnet0 vtnet0: flags=8943 metric 0 mtu 1500 options=80028 ether 00:a0:98:d7:e3:65 inet 192.168.1.170 netmask 0xffffff00 broadcast 192.168.1.255 inet 192.168.1.210 netmask 0xffffff00 broadcast 192.168.1.255 vhid 1 nd6 options=29 media: Ethernet 10Gbase-T status: active carp: BACKUP vhid 1 advbase 1 advskew 100 % ifconfig vtnet0 vtnet0: flags=8943 metric 0 mtu 1500 options=80028 ether 00:a0:98:d7:e3:65 inet 192.168.1.170 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=29 media: Ethernet 10Gbase-T status: active % dmesg ... carp_alloc_if: ifpromisc(vtnet0) failed: 45 carp: VHID 1@vtnet0: INIT -> BACKUP carp: VHID 1@vtnet0: BACKUP -> MASTER (master down) ifa_del_loopback_route: deletion failed: 3 ifa_del_loopback_route: deletion failed: 3 And one more dmesg from the server with more fresher revision (r280012M): carp_alloc_if: ifpromisc(vtnet0) failed: 45 carp: 1@vtnet0: INIT -> BACKUP (initialization complete) carp: 1@vtnet0: BACKUP -> MASTER (master timed out) -- TOX ID: olevole@toxme.se (B4A584A75560D5A93DBF387FAAC56669DA18797078A46B9A9818726BEE643E52A43A6A2E3DA0) E-mail: olevole at olevole.ru XMPP/jabber: olevole at jabber.ru Voice: 199.48.133.74/1001 PGP public key: http://www.olevole.ru/olevole_pgpkey.asc From owner-freebsd-net@FreeBSD.ORG Mon Mar 16 01:01:55 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23EF890D for ; Mon, 16 Mar 2015 01:01:55 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DBFC108 for ; Mon, 16 Mar 2015 01:01:54 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 7B425105CFF; Sun, 15 Mar 2015 18:01:47 -0700 (PDT) Date: Sun, 15 Mar 2015 18:01:47 -0700 From: hiren panchasara To: Vitalii Duk Subject: Re: Unbalanced LACP link Message-ID: <20150316010147.GY88380@strugglingcoder.info> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1ugEqy3masBx2OgH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 01:01:55 -0000 --1ugEqy3masBx2OgH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 03/15/15 at 12:38P, Vitalii Duk wrote: > Hello, guys. > I have a problem with my LACP link (2*1GbE) between FreeBSD 10 and D-Link > DGS-3610-26G switch. This link worked fine last two years on FreeBSD > 9.2-STABLE, but when I've updated my FreeBSD to 10.1-RELEASE traffic > started to go mostly through one interface. I am having a similerish problem that I am debugging right now. I am not too familiar with your setup but does setting following sysctl to 0 help? net.link.lagg.N.flowid_shift: 0 cheers, Hiren --1ugEqy3masBx2OgH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVBit5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lwbEIAJcnCzfCmSC/R0n9MvggDX+C mUpjHgGXhQNfuDTGcTt9MxRPrfBhdbrZ33f8wii+KG4NMRwNKZ++Qu1i0jHXJZMo kK8baXnTHnB55GyHu8yiv4Sdr+MawWGmEbieqmAEs2X/b550bMB/0m91o8V4GzvR 8zyWVKuegpB4P7fmKmvtry6mjGpYh9Oajmkf08dUsCeohBNgaIyAK9GgB4gS0oHd +dDSTo4RJLWAw6nwfHtIYWqcb/44wdVcoO5ld8eO1hX969ocJZ5gP04KoeRutdn/ a2v4g4E01z5r2wZSuPi4HvGEO194YnF0ncckwxG4IWtRODK3rhhZ+MjR+avSE4A= =arwP -----END PGP SIGNATURE----- --1ugEqy3masBx2OgH-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 16 03:36:42 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC2D81A9 for ; Mon, 16 Mar 2015 03:36:42 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2698887 for ; Mon, 16 Mar 2015 03:36:42 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2G3agLh068229 for ; Mon, 16 Mar 2015 03:36:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196011] if_gre tunnel works without rebooting system only in any one direction (send or receive) Date: Mon, 16 Mar 2015 03:36:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kvas@bf.pstu.ru X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 03:36:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196011 --- Comment #3 from Vassily --- New variant of if_gre works fine simultaneously in both directions more then 60 hours for now. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Mar 16 05:09:44 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8CE77F9 for ; Mon, 16 Mar 2015 05:09:44 +0000 (UTC) Received: from masa.qt7.net (masa.qt7.net [104.140.67.88]) by mx1.freebsd.org (Postfix) with ESMTP id A779D2F for ; Mon, 16 Mar 2015 05:09:44 +0000 (UTC) To: freebsd-net@freebsd.org Subject: wish to introduce our fleece blankets and bathrobes factory Message-ID: <292e565dde3ccd892d015a6eee47bce6@canon.com> Date: Mon, 16 Mar 2015 06:06:16 +0100 From: "James" Reply-To: wanshancon@tom.com MIME-Version: 1.0 X-Mailer-LID: 26 X-Mailer-RecptId: 20219482 X-Mailer-SID: 118 X-Mailer-Sent-By: 1 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 05:09:45 -0000 We wish to introduce our fleece blankets and bathrobes factory Our factory based in China has been engaged in the manufacture and sales of fleece products for many years. Over the past years, we have got much professional experience in this industry. We produce below: polar fleece blankets micro coral fleece blankets picnic blankets cushions/cushion covers baby blankets embroidered blankets bathrobes voile curtains sauna quits fleece clothing washmachine covers Our products have been exported to North Amercia, Europe, Japan and so on. We are looking forward to start business with you soon. Best regards: James Contact: rightmm@tom.com From owner-freebsd-net@FreeBSD.ORG Mon Mar 16 07:50:26 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16F669AC for ; Mon, 16 Mar 2015 07:50:26 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D222E16E for ; Mon, 16 Mar 2015 07:50:25 +0000 (UTC) Received: by ignm3 with SMTP id m3so27642098ign.0 for ; Mon, 16 Mar 2015 00:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tucZWYrYDbWE/Nlz5SRw7jD7UIaVUN9jgbUhsMV6bgc=; b=Sc7UMpla0lULI2x2PpMt2Ik2divdW/FVYJlvsUKXVM+gYxk98kppEZpkl0Szgfi0Ai 8DEOUSxz3GdMqUdpU5awZOrgVW52xdA53m0TgQa0N6RTdFSWe3r7WrDbNcJMRxlICJQN sxufzUtCzXtaVy6y65zKgZ9SnNMNZ4fZJVV9qtdCQ08YYTHXf9/Awyk1coL03nPD40tx RacAj4XqJxHBeaxccN0hGAoktygIS09GtDY4K+It6eLX5ltOVKeN+gdq1ywdQ4sVeoCP w/NERin7L4cNCmesE1oNv7XEoKtREnLEkNIUiBSMZmuILqRAkMqh/bqgi/CS0K0HrBGw 5R4Q== X-Received: by 10.50.73.99 with SMTP id k3mr132104793igv.21.1426492225315; Mon, 16 Mar 2015 00:50:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.71.72 with HTTP; Mon, 16 Mar 2015 00:50:04 -0700 (PDT) In-Reply-To: References: From: Konstantin Kulikov Date: Mon, 16 Mar 2015 10:50:04 +0300 Message-ID: Subject: Re: Unbalanced LACP link To: Vitalii Duk Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 07:50:26 -0000 Hello, Vitalii. Make sure following sysctl are set to zero: sysctl net.link.lagg.default_use_flowid=0 sysctl net.link.lagg.0.use_flowid=0 sysctl net.link.lagg.1.use_flowid=0 Then adjust lagghash depending on your configuration. For example if you freebsd machine acts as router with single, default, route, you should set lagghash to l3, since for l2 both src and dst MACs will always be same and you'd get unbalanced load. On Sun, Mar 15, 2015 at 1:38 PM, Vitalii Duk wrote: > Hello, guys. > I have a problem with my LACP link (2*1GbE) between FreeBSD 10 and D-Link > DGS-3610-26G switch. This link worked fine last two years on FreeBSD > 9.2-STABLE, but when I've updated my FreeBSD to 10.1-RELEASE traffic > started to go mostly through one interface. > > lagg0 - input interface (no IP-address, only VLANs). > lagg1 - output interface. > > [router]# ifconfig lagg0 > lagg0: flags=8843 metric 0 mtu 1500 > > options=400b8 > ether 90:e2:ba:02:d0:ae > nd6 options=29 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2 > laggport: igb1 flags=1c > laggport: igb0 flags=1c > > [#router]# ifconfig lagg1 > lagg1: flags=8843 metric 0 mtu 1500 > > options=400b8 > ether 00:1b:21:93:52:d4 > inet 172.16.204.9 netmask 0xfffffff8 broadcast 172.16.204.15 > nd6 options=29 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2 > laggport: igb3 flags=1c > laggport: igb2 flags=1c > > [router]# netstat -hw1 -I igb0 > input igb0 output > packets errs idrops bytes packets errs bytes colls > 27K 0 0 12M 5 0 350 0 > 26K 0 0 12M 7 0 693 0 > 29K 0 0 12M 8 0 838 0 > 29K 0 0 11M 10 0 1.0K 0 > 27K 0 0 10M 7 0 770 0 > > As you can see most traffic is going through igb1 (lagg0) and igb3 (lagg1) > interfaces. In peak times there are more that 1 Gbps of traffic mostly > through one 1GbE interface, and it cause an errors. So this link is > assymetric. > > [router]# netstat -hw1 -I igb1 > input igb1 output > packets errs idrops bytes packets errs bytes colls > 22K 0 0 8.5M 63K 0 69M 0 > 20K 0 0 7.7M 58K 0 62M 0 > 20K 0 0 7.3M 57K 0 61M 0 > 19K 0 0 6.8M 56K 0 61M 0 > 18K 0 0 6.5M 57K 0 62M 0 > > [router]# netstat -hw1 -I igb2 > input igb2 output > packets errs idrops bytes packets errs bytes colls > 40K 0 0 49M 1 0 93 0 > 41K 0 0 51M 1 0 88 0 > 38K 0 0 45M 1 0 88 0 > 33K 0 0 39M 2 0 174 0 > 31K 0 0 35M 1 0 89 0 > > [router]# netstat -hw1 -I igb3 > input igb3 output > packets errs idrops bytes packets errs bytes colls > 32K 0 0 34M 44K 0 18M 0 > 29K 0 0 30M 45K 0 18M 0 > 32K 0 0 34M 48K 0 17M 0 > 28K 0 0 29M 42K 0 15M 0 > 25K 0 0 26M 40K 0 16M 0 > > [router]# netstat -hw1 -I lagg0 > input lagg0 output > packets errs idrops bytes packets errs bytes colls > 45K 0 0 17M 62K 0 69M 0 > 46K 0 0 17M 66K 0 75M 0 > 43K 0 0 17M 62K 0 69M 0 > 50K 0 0 19M 71K 1 82M 0 > 46K 0 0 18M 66K 0 75M 0 > > [router]# netstat -hw1 -I lagg1 > input lagg1 output > packets errs idrops bytes packets errs bytes colls > 70K 0 0 79M 49K 0 18M 0 > 71K 0 0 79M 49K 0 19M 0 > 79K 0 0 91M 54K 0 20M 0 > 65K 0 0 72M 45K 0 17M 0 > 65K 0 0 72M 45K 0 17M 0 > > All igb interfaces are the same: > igb0@pci0:1:0:0: class=0x020000 card=0xa03c8086 chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82576 Gigabit Network Connection' > class = network > subclass = ethernet > > I've tried to disable/enable strict_mode, put switch into active/passive > mode and trying to set duplex/speed manyally. Nothing helps. > Also I've changed lagghash from l2,l3,l4 to l2 only on FreeBSD because > switch supports only l2 load-balancing, but it also doesn't helps. > > net.link.lagg.lacp.debug: 0 > net.link.lagg.0.lacp.lacp_strict_mode: 0 > net.link.lagg.0.lacp.debug.rx_test: 0 > net.link.lagg.0.lacp.debug.tx_test: 0 > net.link.lagg.1.lacp.lacp_strict_mode: 0 > net.link.lagg.1.lacp.debug.rx_test: 0 > net.link.lagg.1.lacp.debug.tx_test: 0 > > I've read that there were some problems with LACP on FreeBSD 10. > > Information from the switch: > > # show lacp summary > Aggregate port 6: > > Local information: > LACP port Oper Port Port > Port Flags State Priority Key Number State > ---------------------------------------------------------------------- > Gi0/18 SP bndl 4096 0x6 0x12 0x3c > Gi0/22 SP bndl 4096 0x6 0x16 0x3c > > Partner information: > LACP port Oper Port Port > Port Flags Priority Dev ID Key Number State > --------------------------------------------------------------------- > Gi0/18 SA 32768 001b.2193.52d4 0x12b 0x3 0x3d > Gi0/22 SA 32768 001b.2193.52d4 0x12b 0x4 0x3d > > Aggregate port 7: > > Local information: > LACP port Oper Port Port > Port Flags State Priority Key Number State > ---------------------------------------------------------------------- > Gi0/19 SP bndl 4096 0x7 0x13 0x3c > Gi0/21 SP bndl 4096 0x7 0x15 0x3c > > Partner information: > LACP port Oper Port Port > Port Flags Priority Dev ID Key Number State > --------------------------------------------------------------------- > Gi0/19 SA 32768 90e2.ba02.d0ae 0x10b 0x1 0x3d > Gi0/21 SA 32768 90e2.ba02.d0ae 0x10b 0x2 0x3d > _______________________________________________ > 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 Mar 16 09:37:18 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A1FCC41 for ; Mon, 16 Mar 2015 09:37:18 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3251EEE for ; Mon, 16 Mar 2015 09:37:17 +0000 (UTC) Received: by qcaz10 with SMTP id z10so38276176qca.1 for ; Mon, 16 Mar 2015 02:37:16 -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=lmMsSFyw87/suiV1i8R0Am7WC++Jyf1bjugrdxMF8Fo=; b=m3ZeLytONiGcNA/426eNxc51cGTTWo1dyUeGRqQ/Dk0ccLikFJmAp3pycvaBwFu9g+ jSY4CcxHyxAm8/9w0UEu1ztABaFwPtHFc0HBIQep5uNkdPd6QoAHrfYZ5SW8TlMrboI2 uTIDtjtLWfDNuFN06DefZdxXNWWwH3/1tp6CCl2aux4+92tvPSq2YMxnFoBC5HQ+YhGe GMA43MJEpIzHPbqnQW70Sj2cFDtI8PppVUK0JkFSdPIruCZjQCC5y+fMGS669HnJwJMu rrtd1BW/A5Kjw1Zaw/5pdHPFj4Nv1F942MKAp3UH3ANMVZBzx/YMhu603q0Hu+eIDoef 03cw== MIME-Version: 1.0 X-Received: by 10.55.40.9 with SMTP id o9mr89737682qkh.55.1426498636875; Mon, 16 Mar 2015 02:37:16 -0700 (PDT) Received: by 10.229.226.1 with HTTP; Mon, 16 Mar 2015 02:37:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Mar 2015 11:37:16 +0200 Message-ID: Subject: Re: Unbalanced LACP link From: Vitalii Duk To: Konstantin Kulikov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 09:37:18 -0000 I've changed use_flowid to 0 and it helped! But isn't it setting significant? In a description it says "Shift flowid bits to prevent multiqueue collisions". On 16 March 2015 at 09:50, Konstantin Kulikov wrote: > Hello, Vitalii. > > Make sure following sysctl are set to zero: > sysctl net.link.lagg.default_use_flowid=0 > sysctl net.link.lagg.0.use_flowid=0 > sysctl net.link.lagg.1.use_flowid=0 > > Then adjust lagghash depending on your configuration. > For example if you freebsd machine acts as router with single, default, > route, > you should set lagghash to l3, since for l2 both src and dst MACs will > always be same and you'd get unbalanced load. > > On Sun, Mar 15, 2015 at 1:38 PM, Vitalii Duk wrote: > > Hello, guys. > > I have a problem with my LACP link (2*1GbE) between FreeBSD 10 and D-Link > > DGS-3610-26G switch. This link worked fine last two years on FreeBSD > > 9.2-STABLE, but when I've updated my FreeBSD to 10.1-RELEASE traffic > > started to go mostly through one interface. > > > > lagg0 - input interface (no IP-address, only VLANs). > > lagg1 - output interface. > > > > [router]# ifconfig lagg0 > > lagg0: flags=8843 metric 0 mtu > 1500 > > > > options=400b8 > > ether 90:e2:ba:02:d0:ae > > nd6 options=29 > > media: Ethernet autoselect > > status: active > > laggproto lacp lagghash l2 > > laggport: igb1 flags=1c > > laggport: igb0 flags=1c > > > > [#router]# ifconfig lagg1 > > lagg1: flags=8843 metric 0 mtu > 1500 > > > > options=400b8 > > ether 00:1b:21:93:52:d4 > > inet 172.16.204.9 netmask 0xfffffff8 broadcast 172.16.204.15 > > nd6 options=29 > > media: Ethernet autoselect > > status: active > > laggproto lacp lagghash l2 > > laggport: igb3 flags=1c > > laggport: igb2 flags=1c > > > > [router]# netstat -hw1 -I igb0 > > input igb0 output > > packets errs idrops bytes packets errs bytes colls > > 27K 0 0 12M 5 0 350 0 > > 26K 0 0 12M 7 0 693 0 > > 29K 0 0 12M 8 0 838 0 > > 29K 0 0 11M 10 0 1.0K 0 > > 27K 0 0 10M 7 0 770 0 > > > > As you can see most traffic is going through igb1 (lagg0) and igb3 > (lagg1) > > interfaces. In peak times there are more that 1 Gbps of traffic mostly > > through one 1GbE interface, and it cause an errors. So this link is > > assymetric. > > > > [router]# netstat -hw1 -I igb1 > > input igb1 output > > packets errs idrops bytes packets errs bytes colls > > 22K 0 0 8.5M 63K 0 69M 0 > > 20K 0 0 7.7M 58K 0 62M 0 > > 20K 0 0 7.3M 57K 0 61M 0 > > 19K 0 0 6.8M 56K 0 61M 0 > > 18K 0 0 6.5M 57K 0 62M 0 > > > > [router]# netstat -hw1 -I igb2 > > input igb2 output > > packets errs idrops bytes packets errs bytes colls > > 40K 0 0 49M 1 0 93 0 > > 41K 0 0 51M 1 0 88 0 > > 38K 0 0 45M 1 0 88 0 > > 33K 0 0 39M 2 0 174 0 > > 31K 0 0 35M 1 0 89 0 > > > > [router]# netstat -hw1 -I igb3 > > input igb3 output > > packets errs idrops bytes packets errs bytes colls > > 32K 0 0 34M 44K 0 18M 0 > > 29K 0 0 30M 45K 0 18M 0 > > 32K 0 0 34M 48K 0 17M 0 > > 28K 0 0 29M 42K 0 15M 0 > > 25K 0 0 26M 40K 0 16M 0 > > > > [router]# netstat -hw1 -I lagg0 > > input lagg0 output > > packets errs idrops bytes packets errs bytes colls > > 45K 0 0 17M 62K 0 69M 0 > > 46K 0 0 17M 66K 0 75M 0 > > 43K 0 0 17M 62K 0 69M 0 > > 50K 0 0 19M 71K 1 82M 0 > > 46K 0 0 18M 66K 0 75M 0 > > > > [router]# netstat -hw1 -I lagg1 > > input lagg1 output > > packets errs idrops bytes packets errs bytes colls > > 70K 0 0 79M 49K 0 18M 0 > > 71K 0 0 79M 49K 0 19M 0 > > 79K 0 0 91M 54K 0 20M 0 > > 65K 0 0 72M 45K 0 17M 0 > > 65K 0 0 72M 45K 0 17M 0 > > > > All igb interfaces are the same: > > igb0@pci0:1:0:0: class=0x020000 card=0xa03c8086 chip=0x10c98086 > > rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > device = '82576 Gigabit Network Connection' > > class = network > > subclass = ethernet > > > > I've tried to disable/enable strict_mode, put switch into active/passive > > mode and trying to set duplex/speed manyally. Nothing helps. > > Also I've changed lagghash from l2,l3,l4 to l2 only on FreeBSD because > > switch supports only l2 load-balancing, but it also doesn't helps. > > > > net.link.lagg.lacp.debug: 0 > > net.link.lagg.0.lacp.lacp_strict_mode: 0 > > net.link.lagg.0.lacp.debug.rx_test: 0 > > net.link.lagg.0.lacp.debug.tx_test: 0 > > net.link.lagg.1.lacp.lacp_strict_mode: 0 > > net.link.lagg.1.lacp.debug.rx_test: 0 > > net.link.lagg.1.lacp.debug.tx_test: 0 > > > > I've read that there were some problems with LACP on FreeBSD 10. > > > > Information from the switch: > > > > # show lacp summary > > Aggregate port 6: > > > > Local information: > > LACP port Oper Port Port > > Port Flags State Priority Key Number State > > ---------------------------------------------------------------------- > > Gi0/18 SP bndl 4096 0x6 0x12 0x3c > > Gi0/22 SP bndl 4096 0x6 0x16 0x3c > > > > Partner information: > > LACP port Oper Port Port > > Port Flags Priority Dev ID Key Number State > > --------------------------------------------------------------------- > > Gi0/18 SA 32768 001b.2193.52d4 0x12b 0x3 0x3d > > Gi0/22 SA 32768 001b.2193.52d4 0x12b 0x4 0x3d > > > > Aggregate port 7: > > > > Local information: > > LACP port Oper Port Port > > Port Flags State Priority Key Number State > > ---------------------------------------------------------------------- > > Gi0/19 SP bndl 4096 0x7 0x13 0x3c > > Gi0/21 SP bndl 4096 0x7 0x15 0x3c > > > > Partner information: > > LACP port Oper Port Port > > Port Flags Priority Dev ID Key Number State > > --------------------------------------------------------------------- > > Gi0/19 SA 32768 90e2.ba02.d0ae 0x10b 0x1 0x3d > > Gi0/21 SA 32768 90e2.ba02.d0ae 0x10b 0x2 0x3d > > _______________________________________________ > > 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 Mar 16 09:42:40 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30FA2D82 for ; Mon, 16 Mar 2015 09:42:40 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3CE4FB3 for ; Mon, 16 Mar 2015 09:42:39 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 3CEA91FE023; Mon, 16 Mar 2015 10:42:37 +0100 (CET) Message-ID: <5506A5BB.5060204@selasky.org> Date: Mon, 16 Mar 2015 10:43:23 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Vitalii Duk , Konstantin Kulikov Subject: Re: Unbalanced LACP link References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 09:42:40 -0000 On 03/16/15 10:37, Vitalii Duk wrote: > I've changed use_flowid to 0 and it helped! But isn't it setting > significant? In a description it says "Shift flowid bits to prevent > multiqueue collisions". Hi, Maybe your ethernet hardware is not properly setting the m_flowid ... --HPS From owner-freebsd-net@FreeBSD.ORG Mon Mar 16 10:29:05 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A83C2C0B; Mon, 16 Mar 2015 10:29:05 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 12B1D787; Mon, 16 Mar 2015 10:29:04 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t2GA5w3m049360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Mar 2015 13:05:58 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t2GA5vM2049359; Mon, 16 Mar 2015 13:05:57 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 16 Mar 2015 13:05:57 +0300 From: Gleb Smirnoff To: John Baldwin Subject: Re: Adding new media types to if_media.h Message-ID: <20150316100557.GS17947@glebius.int.ru> References: <20150226230031.GN17947@glebius.int.ru> <1919032.aFEK3un8ig@ralph.baldwin.cx> <5501ABCA.7020203@selasky.org> <1740987.7L4GidWlzm@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1740987.7L4GidWlzm@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Hans Petter Selasky , Adrian Chadd , mike@karels.net, "freebsd-net@freebsd.org" , Jack Vogel , freebsd-arch@freebsd.org, Eric Joyner X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 10:29:05 -0000 On Thu, Mar 12, 2015 at 12:01:13PM -0400, John Baldwin wrote: J> On Thursday, March 12, 2015 04:07:54 PM Hans Petter Selasky wrote: J> > On 02/28/15 13:28, John Baldwin wrote: J> > > On Friday, February 27, 2015 10:23:10 PM Gleb Smirnoff wrote: J> > >> On Thu, Feb 26, 2015 at 08:25:59PM -0800, Adrian Chadd wrote: J> > >> A> [snip] J> > >> A> J> > >> A> I think Mike's approach is good - it makes it easy to MFC to 10.2 J> > >> A> since there's extended lifecycle stuff to do there - and then we can J> > >> A> plan out how do the "betterer" fix after it's landed and churned J> > >> A> things. J> > >> J> > >> ... and we will be ought to support the "betterer" fix along with J> > >> the "not so betterer" for a very long time. J> > >> J> > >> The rock on which we split in this argument is that some developers J> > >> write their code for stable/x and then forward-port it to head, J> > >> focused on quality of result for stable/x; while other developers J> > >> do the opposite: write code to head, then consider or not consider J> > >> merging it stable/x. J> > > J> > > No, this is not quite true. Some folks have to write drivers on HEAD but also J> > > support running those drivers on older branches. The MFC's get harder when J> > > you have very different APIs on the different branches. It's already harder J> > > to test stat changes now since it requires completely different patches for J> > > <= 10 (the only thing people are supposed to use in production) vs head due to J> > > if_getcounter() and friends. Also, since 11 won't be out until 2016, that is J> > > far, far too long to wait for more media types. The stuff we need to support J> > > is already shipping in products today. We can't not support these in 10 (and J> > > possibly 9). J> > > J> > J> > Any news on this issue? Is anyone working on a solution for -head ? J> J> I believe a variant of Mike's patch is in phabricator now? There is also my patch in phab: https://reviews.freebsd.org/D2008 Mike already gave feedback on it, but I didn'y yet respond. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Mar 16 13:52:31 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 407EA9E2; Mon, 16 Mar 2015 13:52:31 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 1C96824D; Mon, 16 Mar 2015 13:52:30 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 912DD56467; Mon, 16 Mar 2015 08:52:29 -0500 (CDT) Message-ID: <5506DFFB.7050302@FreeBSD.org> Date: Mon, 16 Mar 2015 09:51:55 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kristof Provost , freebsd-pf@freebsd.org, freebsd-net@freebsd.org Subject: Re: PF IPv6 fragments handling References: <20150203202519.GD2167@vega.codepro.be> <20150209232416.GB37777@vega.codepro.be> <20150314020500.GW1975@vega.codepro.be> In-Reply-To: <20150314020500.GW1975@vega.codepro.be> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qr4U7lrVe1SHhDRsKSca87alQaau6r17R" Cc: ae@FreeBSD.org, bz@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 13:52:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qr4U7lrVe1SHhDRsKSca87alQaau6r17R Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/13/2015 22:05, Kristof Provost wrote: > At that point we run into the packet size check, which in ip6_forward()= > is done before the pfil(PFIL_OUT) hook. That means that we'll send an > ICMP6_PACKET_TOO_BIG error rather than forwarding the packet. >=20 > The proposed fix in D1815 is to simply move the size check after the > pfil(PFIL_OUT) hook so pf has the chance to refragment the packet (whic= h > it does in pf_test6() -> pf_refragment6() because the packet has the > PF_REASSEMBLED tag). > That's also what the OpenBSD stack does. >=20 > In the D1815 review Gleb Smirnoff proposed a different solution. Instea= d > of returning a reassembled packet from pfil(PFIL_IN) in ip6_input() we > could change netpfil so we could return multiple packets. That means > we'd reassemble and immediately refragment on the input, and then do th= e > same on the output side. >=20 >=20 > I have a preference for the solution in D1815 for two reasons: > - it's less work for me. It's a relatively small change in ip6_output(= ) > and nothing else. Changing netpfil so it can return multiple packets= > is a more invasive change and will impact other firewalls too. > - it's less work for the kernel when forwarding. Not only do we only > reassemble and refragment once, but we also only need to do > ip6_forward() processing on a single packet, rather than for each > fragment. Here is a brainstorm that might give the best of both: Return the reassembled packet from PFIL_IN, but with the original fragment chain stashed in metadata. Most of the stack operates on the single, reassembled packet. ip6_output() sends the original fragment chain. Sure, it uses more memory, but reduced CPU time might be worth it. I am sure there are numerous challenges. When the stack modifies the packet, it will need to modify the fragment chain to match. Size checks would probably need to look at the fragment chain instead of the reassembled packet. This could be a maintenance problem when people forget to handle the rare case of the fragment chain. Like I said, it is a brainstorm. Treat it accordingly. Eric --qr4U7lrVe1SHhDRsKSca87alQaau6r17R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVBt/7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzRTcwNEY0QTBEMTM0MUU4QkNFNEQ3M0RB RkMxMkExM0VDMjBEQUI4AAoJEK/BKhPsINq4sOsIAIpD3poy5Q9T1lePn0ZO7zMN eXV/hBau+eQ8WygRmMqeGLKhAWVvffqp/fJn29T9zeICXC+/wvUYlCEQkZITtIFC pyKg9grzblufzkYCkGdXihZNqN48BlyubTfsU8xNeCsRwGtu8PpHHBtCbO6YVFA/ tg3WbRdFpwMI9wse5RIA/uE10p3/OGAxCWTkz/SUm9xBUa00uVt09lq0s8kEfApF idruQOPv6VrY2GCkRYlYgK5GVfdHWYzjRcNkxaa89xLuxqROJ8cIlLlL4LINSOQQ HY8J8uUtezuoguS7qoYnKkdTkqgx7OEG/VBRAAZvbdiCHG/jAvrkk6Ov0RIm1IQ= =v9U3 -----END PGP SIGNATURE----- --qr4U7lrVe1SHhDRsKSca87alQaau6r17R-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 16 14:29:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55AC6221 for ; Mon, 16 Mar 2015 14:29:32 +0000 (UTC) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7C7C900 for ; Mon, 16 Mar 2015 14:29:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t2GETMbP027582 for ; Mon, 16 Mar 2015 15:29:22 +0100 (CET) Received: from [IPv6:2001:470:7408:0:21f6:de18:2f98:b330] (unknown [IPv6:2001:470:7408:0:21f6:de18:2f98:b330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3l5Kl60zD6z2nX7 for ; Mon, 16 Mar 2015 15:29:22 +0100 (CET) Message-ID: <5506E8C1.70602@tzi.de> Date: Mon, 16 Mar 2015 15:29:21 +0100 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: gre(4) over IPv6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 14:29:32 -0000 Hi, is anyone interested in implementing gre(4) over IPv6? It seems that there has not been any progress since 2012: https://wiki.freebsd.org/IPv6TODO#gre.284.29_over_IPv6 Kind Regards Julian From owner-freebsd-net@FreeBSD.ORG Mon Mar 16 18:37:46 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 262B0BF5 for ; Mon, 16 Mar 2015 18:37:46 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD1EFEF2 for ; Mon, 16 Mar 2015 18:37:45 +0000 (UTC) Received: by igbue6 with SMTP id ue6so38148853igb.1 for ; Mon, 16 Mar 2015 11:37:45 -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:message-id:subject :from:to:cc:content-type; bh=6oXd68GaLLupLxzQwbiIWhOJ5EatLFR8xnTHBVqjDso=; b=O4b7icRMpUGT1JpHpH+Tu0aUKY8kQDx9IbXJfJKyJRFc6vFfpNug08x4I4k0P4JaOd 0aQgtTgQ/G/IX9op/JU0wtFRxMFy3iucWvCuxQSAzgp0hEbqs3gMJht1O0QyioH0LBoF 7b58Rx4/Q8h3Pjf1r6fk/LVwAePXm9O84ECJAJcBiZTKedE9EOxja8KezWoCzlggFGOB I5g0KkG//DWZNJuhG8Td9aEkHAXrnmu/Tn3BQ2fi2SiPBAGmV2y7aR7wOR11onzZHbVQ r/FIYNjKyQtj5fs55d7Iaaem8PuKlBlTilPIOD37FwZ96gLfMO0Kpr0m5IWWPeMmH2+D Xs1w== MIME-Version: 1.0 X-Received: by 10.107.136.206 with SMTP id s75mr76656715ioi.8.1426531065418; Mon, 16 Mar 2015 11:37:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Mon, 16 Mar 2015 11:37:45 -0700 (PDT) In-Reply-To: <5506A5BB.5060204@selasky.org> References: <5506A5BB.5060204@selasky.org> Date: Mon, 16 Mar 2015 11:37:45 -0700 X-Google-Sender-Auth: 42-hOdu4OC3lbpCeWq87tOGm5Ek Message-ID: Subject: Re: Unbalanced LACP link From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , Konstantin Kulikov , Vitalii Duk X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 18:37:46 -0000 if_igb and ixgbe iirc don't set the full flowid unless you're using RSS. They're just setting the CPU/MSIX id. -a From owner-freebsd-net@FreeBSD.ORG Mon Mar 16 18:42:22 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B986DD91 for ; Mon, 16 Mar 2015 18:42:22 +0000 (UTC) Received: from forward1l.mail.yandex.net (forward1l.mail.yandex.net [IPv6:2a02:6b8:0:1819::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EF3CFDD for ; Mon, 16 Mar 2015 18:42:22 +0000 (UTC) Received: from smtp3m.mail.yandex.net (smtp3m.mail.yandex.net [77.88.61.130]) by forward1l.mail.yandex.net (Yandex) with ESMTP id 4D1D41520E0C; Mon, 16 Mar 2015 21:42:08 +0300 (MSK) Received: from smtp3m.mail.yandex.net (localhost [127.0.0.1]) by smtp3m.mail.yandex.net (Yandex) with ESMTP id D9B6F27A038F; Mon, 16 Mar 2015 21:42:07 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:6::bb]) by smtp3m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 9iFw2qyXaN-g7LaNfWJ; Mon, 16 Mar 2015 21:42:07 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1426531327; bh=eGFnxGcmkBEIoa5yMVDtAE0XjSVNZzy6RW9/XxcdEjQ=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=buVUcmMmY+tQYb4UQWi6dTnkFltt67mOINE3+l9XGE23mZ+QmbX839ubZIxABaIXx Z5PVk8gFyc1cWYQ9LJr6cORR0emBEGq+orP8bhF2htkGTxzmTV3iTPFGK+/xH08rSt aTGVMBlR+gjVLcIuMma849MrmkRQQJTCyoTMjVSc= Authentication-Results: smtp3m.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <550723AA.7040707@yandex.ru> Date: Mon, 16 Mar 2015 21:40:42 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Kornberger , freebsd-net@freebsd.org Subject: Re: gre(4) over IPv6 References: <5506E8C1.70602@tzi.de> In-Reply-To: <5506E8C1.70602@tzi.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GNNGi2Eod6luSobBfvLl3diVjiuObnIUJ" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 18:42:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GNNGi2Eod6luSobBfvLl3diVjiuObnIUJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 16.03.2015 17:29, Julian Kornberger wrote: > Hi, >=20 > is anyone interested in implementing gre(4) over IPv6? > It seems that there has not been any progress since 2012: > https://wiki.freebsd.org/IPv6TODO#gre.284.29_over_IPv6 Hi, I already have implemented generic IPv6 support for gre(4) in r274246. But if you want to add something, there are some missing features, e.g. GRE keepalives (1), IPv6 tunnel encapsulation limit option (2). 1. http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulatio= n-gre/64565-gre-tunnel-keepalive.html 2. http://tools.ietf.org/html/rfc2473 --=20 WBR, Andrey V. Elsukov --GNNGi2Eod6luSobBfvLl3diVjiuObnIUJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVByOqAAoJEAHF6gQQyKF608cIALWob2yKG5EphN2m5rszPujJ nm4aB/AAjMPU06YMiHTfd1KWN5DpWmfQaqqZAO7G14274p0NgjDYjEuwFsU58ctR Rs3K5j23YBd0vGMXX70XJJZxNnvkrbyioGWtqqoCDKj446G2/fimCMXHNRC467wM ZIeBy9l5f6b0+sWc9hwHX0PLfxSpZ4qH9yvtZdbcsbvQMt+/4YSlLnxO7uI4ImiN KvP1nncVmxfXvPiyAvVQ7nMZDkLJQp+F4GlPAQNAJOVOKD30Vr6uGXyK7DAERO0s Ls20TZDHgJCROTVukXu9nXFBBQ1VPe4zvMsxfFY69pffhG2wDQGa4i81kh6gXtA= =mh4w -----END PGP SIGNATURE----- --GNNGi2Eod6luSobBfvLl3diVjiuObnIUJ-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 16 18:54:15 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E69372EC for ; Mon, 16 Mar 2015 18:54:15 +0000 (UTC) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77DD7177 for ; Mon, 16 Mar 2015 18:54:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t2GIsCsM028478 for ; Mon, 16 Mar 2015 19:54:12 +0100 (CET) Received: from [IPv6:2001:470:7408:0:c18e:26a0:c339:e8c8] (unknown [IPv6:2001:470:7408:0:c18e:26a0:c339:e8c8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3l5Rch0CFYz2nkV for ; Mon, 16 Mar 2015 19:54:12 +0100 (CET) Message-ID: <550726D2.5030504@tzi.de> Date: Mon, 16 Mar 2015 19:54:10 +0100 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: gre(4) over IPv6 References: <5506E8C1.70602@tzi.de> <550723AA.7040707@yandex.ru> In-Reply-To: <550723AA.7040707@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 18:54:16 -0000 On 16.03.2015 at 19:40 wrote Andrey V. Elsukov: > Hi, > > I already have implemented generic IPv6 support for gre(4) in r274246. > But if you want to add something, there are some missing features, e.g. > GRE keepalives (1), IPv6 tunnel encapsulation limit option (2). Hi Andrey, Great work! I will take a look at it. The IPv6TODO at wiki.freebsd.org should be updated to reflect the current state. Regards Julian From owner-freebsd-net@FreeBSD.ORG Mon Mar 16 21:26:50 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7F9EFEB for ; Mon, 16 Mar 2015 21:26:50 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD84C9CB for ; Mon, 16 Mar 2015 21:26:50 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2GLQo7A079962 for ; Mon, 16 Mar 2015 21:26:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 138782] [panic] sbflush_internal: cc 0 || mb 0xffffff004127b000 || mbcnt 2304 Date: Mon, 16 Mar 2015 21:26:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: version cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Mar 2015 21:26:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138782 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- Version|8.0-BETA4 |10.1-STABLE CC| |hiren@FreeBSD.org --- Comment #5 from Hiren Panchasara --- We randomly see this panic on 10.1 stable. I'll try to get more info here. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Mar 17 01:15:12 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57B69152; Tue, 17 Mar 2015 01:15:12 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16FCE3C9; Tue, 17 Mar 2015 01:15:11 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 736FE126D5; Tue, 17 Mar 2015 02:15:08 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 2473F78399; Tue, 17 Mar 2015 02:15:08 +0100 (CET) Date: Tue, 17 Mar 2015 02:15:08 +0100 From: Kristof Provost To: Eric van Gyzen Subject: Re: PF IPv6 fragments handling Message-ID: <20150317011507.GC2036@vega.codepro.be> References: <20150203202519.GD2167@vega.codepro.be> <20150209232416.GB37777@vega.codepro.be> <20150314020500.GW1975@vega.codepro.be> <5506DFFB.7050302@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5506DFFB.7050302@FreeBSD.org> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, bz@FreeBSD.org, ae@FreeBSD.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Mar 2015 01:15:12 -0000 On 2015-03-16 09:51:55 (-0400), Eric van Gyzen wrote: > Here is a brainstorm that might give the best of both: Return the > reassembled packet from PFIL_IN, but with the original fragment chain > stashed in metadata. Most of the stack operates on the single, > reassembled packet. ip6_output() sends the original fragment chain. > Sure, it uses more memory, but reduced CPU time might be worth it. > It's an interesting idea. There are a number of advantages (like not modifying the fragment ID or the sizes of each packet). It won't reduce CPU usage though because we'd have to copy the packet which is something we don't do at the moment. In addition to that there's the concern you pointed out that we'd forget to adapt them both, or that we'd end up checking the wrong one at any point in the stack. Regards, Kristof From owner-freebsd-net@FreeBSD.ORG Tue Mar 17 01:22:26 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 597B02C1; Tue, 17 Mar 2015 01:22:26 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B10E671; Tue, 17 Mar 2015 01:22:25 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 40DCC126E8; Tue, 17 Mar 2015 02:22:22 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id E3B30783BE; Tue, 17 Mar 2015 02:22:21 +0100 (CET) Date: Tue, 17 Mar 2015 02:22:21 +0100 From: Kristof Provost To: "Andrey V. Elsukov" Subject: Re: Padded packets in ip6_input() Message-ID: <20150317012221.GD2036@vega.codepro.be> References: <20150315063651.GA2036@vega.codepro.be> <5505891E.4060109@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5505891E.4060109@yandex.ru> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, Philip Paeps X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Mar 2015 01:22:26 -0000 On 2015-03-15 16:29:02 (+0300), Andrey V. Elsukov wrote: > This is very rare case, I think, but plen can be zero in case, when > jumbo payload option is present. Probably this is the reason why this > check is done after hop-by-hop options parsing. > You're right, I missed that. The proposed patch is wrong. I think we can get away with doing the trim before the pfil() hook (only if plen != 0). That'd mean we don't do the size check before pfil(), but that's almost certainly something the firewalls handle (I'll check when I find a bit of time). There's perhaps also a risk of not doing the trim in the jumbo frame case, but the existing code already (correctly) drops jumbo packets shorter than 65k. I'll look at it a bit more (either doing the above or ensuring all firewalls handle trailing data correctly) later. Regards, Kristof From owner-freebsd-net@FreeBSD.ORG Tue Mar 17 12:25:19 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68692C2C; Tue, 17 Mar 2015 12:25:19 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DFDA479A; Tue, 17 Mar 2015 12:25:18 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t2HCP9YZ057193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Mar 2015 15:25:09 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t2HCP9tU057192; Tue, 17 Mar 2015 15:25:09 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 17 Mar 2015 15:25:09 +0300 From: Gleb Smirnoff To: Oleg Ginzburg Subject: Re: SIOCSVH, SIOCGVH ioctl(2) and virtio ethernet driver Message-ID: <20150317122509.GR17947@glebius.int.ru> References: <36413168.TE9MLvZCzL@kde4.my.domain> <3860521.yJlCc0OyhB@kde4.my.domain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3860521.yJlCc0OyhB@kde4.my.domain> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Bryan Venteicher , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Mar 2015 12:25:19 -0000 On Mon, Mar 16, 2015 at 02:49:58AM +0300, Oleg Ginzburg wrote: O> b) On FreeBSD-current r276500M CARP IP is established for some seconds, then O> vanishes: O> O> % /sbin/ifconfig vtnet0 vhid 1 advskew 100 pass navuhodonosor 192.168.1.210/24 O> state master alias O> % ifconfig vtnet0 O> vtnet0: flags=8943 metric 0 mtu O> 1500 O> options=80028 O> ether 00:a0:98:d7:e3:65 O> inet 192.168.1.170 netmask 0xffffff00 broadcast 192.168.1.255 O> inet 192.168.1.210 netmask 0xffffff00 broadcast 192.168.1.255 vhid 1 O> nd6 options=29 O> media: Ethernet 10Gbase-T O> status: active O> carp: BACKUP vhid 1 advbase 1 advskew 100 O> O> % ifconfig vtnet0 O> vtnet0: flags=8943 metric 0 mtu O> 1500 O> options=80028 O> ether 00:a0:98:d7:e3:65 O> inet 192.168.1.170 netmask 0xffffff00 broadcast 192.168.1.255 O> nd6 options=29 O> media: Ethernet 10Gbase-T O> status: active O> O> % dmesg O> ... O> carp_alloc_if: ifpromisc(vtnet0) failed: 45 O> carp: VHID 1@vtnet0: INIT -> BACKUP O> carp: VHID 1@vtnet0: BACKUP -> MASTER (master down) O> ifa_del_loopback_route: deletion failed: 3 O> ifa_del_loopback_route: deletion failed: 3 O> O> O> And one more dmesg from the server with more fresher revision (r280012M): O> O> carp_alloc_if: ifpromisc(vtnet0) failed: 45 O> carp: 1@vtnet0: INIT -> BACKUP (initialization complete) O> carp: 1@vtnet0: BACKUP -> MASTER (master timed out) In my case on r280167, all works okay, despite the carp_alloc_if warning: #/sbin/ifconfig vtnet0 vhid 1 advskew 100 pass navuhodonosor 192.168.1.210/24 state master alias #dmesg | tail -n 3 carp_alloc_if: ifpromisc(vtnet0) failed: 45 carp: 1@vtnet0: INIT -> BACKUP (initialization complete) carp: 1@vtnet0: BACKUP -> MASTER (master timed out) #ifconfig vtnet0 vtnet0: flags=8943 metric 0 mtu 1500 options=80028 ether 00:a0:98:83:f4:f1 inet 10.6.6.9 netmask 0xfffffffe broadcast 255.255.255.255 inet 192.168.1.210 netmask 0xffffff00 broadcast 192.168.1.255 vhid 1 inet6 fe80::2a0:98ff:fe83:f4f1%vtnet0 prefixlen 64 scopeid 0x1 nd6 options=21 media: Ethernet 10Gbase-T status: active carp: MASTER vhid 1 advbase 1 advskew 100 -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Mar 17 18:33:54 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9164312 for ; Tue, 17 Mar 2015 18:33:54 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 374E76CA for ; Tue, 17 Mar 2015 18:33:54 +0000 (UTC) Received: by wibdy8 with SMTP id dy8so70572508wib.0 for ; Tue, 17 Mar 2015 11:33:52 -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=NSLpTy7HI10aEOp2qyX05PuWqXagha/ApNq5mftRUDE=; b=QbOvAf88RjfTOlM2G+gHck5UTSwtqZ/DEmHydagSlSMxYLVlWMX2skYiha00X50LaK eSAhHTvcQRyzSxgBNL7BC4IxX2ENC8/rQ6kpkDgu5o7xvg8ZMOLzgAyENUiJhc8L+KdJ w2PWCG8xVk53FJraN8Qm1nwogmDw+uFzYCbWy7crK98JenfqjwKVhiELONRe1AFjq3gC W3jsFXA+xbwkXxpe63QhGRFbt6LzeoElWnjT3dVthcN0rh4JM549Dh7lVkBGgwjTFobS q7BZ9Mogl0i8xfBYxKvc1zbw6xb8DAMRuKSJTR1rfRikPYqbPpM8AeywWOEFi1/Hi9yT ZuhQ== MIME-Version: 1.0 X-Received: by 10.180.106.197 with SMTP id gw5mr182727wib.58.1426617232580; Tue, 17 Mar 2015 11:33:52 -0700 (PDT) Received: by 10.27.52.75 with HTTP; Tue, 17 Mar 2015 11:33:52 -0700 (PDT) In-Reply-To: <5506A5BB.5060204@selasky.org> References: <5506A5BB.5060204@selasky.org> Date: Tue, 17 Mar 2015 11:33:52 -0700 Message-ID: Subject: Re: Unbalanced LACP link From: Jason Wolfe To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, Konstantin Kulikov , Vitalii Duk X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Mar 2015 18:33:54 -0000 On Mon, Mar 16, 2015 at 2:43 AM, Hans Petter Selasky wrote: > On 03/16/15 10:37, Vitalii Duk wrote: >> >> I've changed use_flowid to 0 and it helped! But isn't it setting >> significant? In a description it says "Shift flowid bits to prevent >> multiqueue collisions". > > > Hi, > > Maybe your ethernet hardware is not properly setting the m_flowid ... > > --HPS > Flip use_flowid back to 1 and try setting net.link.lagg.default_flowid_shift / net.link.lagg.X.flowid_shift to 0 as Hiren suggested. r260179 added this shift, which has caused us balancing issues with the i350/igb. https://svnweb.freebsd.org/base?view=revision&revision=260179 Based on Adrian's comment about igb/ixgbe not setting the 'full flowid' under normal conditions, does that mean this shift should be 0 by default to ensure we don't break balancing for devices that only set the CPU/MSIX queue? Jason From owner-freebsd-net@FreeBSD.ORG Tue Mar 17 19:34:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 489F56F8 for ; Tue, 17 Mar 2015 19:34:32 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 09B40EC4 for ; Tue, 17 Mar 2015 19:34:32 +0000 (UTC) Received: by iegc3 with SMTP id c3so20394387ieg.3 for ; Tue, 17 Mar 2015 12:34:31 -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:message-id:subject :from:to:cc:content-type; bh=UsTUjMJv5NaPAlcT+v9QP/A97KG2BAvRqbHVkEJEYiQ=; b=MP6r+N50VuCGOaHaxF8mkmjUUpF24/m0iMl7cFYpzK+u8YKW4Jb+E9D5LhBwAz5LtR TksaEoo6TW9Kzh9bwee9PmP/eRqf6tRYZXhT/4Q+MADhCmZIjyb690FH8KL8bD9aaYUD AoOqTkcxUiQgCuIJ84CFFsawOanKUpoy94W/Wblqc4uUzEI0sMDDIgpf5hdh44Dg5JoT U/JfKikkEhFqTZM7hpVmYk75vJH03qiBBtT+9dKSEwWH6D7y5z94/Afxq32xmE8PqxQ7 ErZsIqgzCg23ABOvp/CQ9IEk3PfAdYEiCaGHxk/PNsIlYnKxeNS5O+mfWJRhj6XmALUp VyLw== MIME-Version: 1.0 X-Received: by 10.50.143.42 with SMTP id sb10mr577329igb.49.1426620871333; Tue, 17 Mar 2015 12:34:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Tue, 17 Mar 2015 12:34:31 -0700 (PDT) In-Reply-To: References: <5506A5BB.5060204@selasky.org> Date: Tue, 17 Mar 2015 12:34:31 -0700 X-Google-Sender-Auth: 3Buda-AUw59gOZMxibhclaR7HAQ Message-ID: Subject: Re: Unbalanced LACP link From: Adrian Chadd To: Jason Wolfe Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , FreeBSD Net , Konstantin Kulikov , Vitalii Duk X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Mar 2015 19:34:32 -0000 On 17 March 2015 at 11:33, Jason Wolfe wrote: > On Mon, Mar 16, 2015 at 2:43 AM, Hans Petter Selasky wrote: >> On 03/16/15 10:37, Vitalii Duk wrote: >>> >>> I've changed use_flowid to 0 and it helped! But isn't it setting >>> significant? In a description it says "Shift flowid bits to prevent >>> multiqueue collisions". >> >> >> Hi, >> >> Maybe your ethernet hardware is not properly setting the m_flowid ... >> >> --HPS >> > > Flip use_flowid back to 1 and try setting > net.link.lagg.default_flowid_shift / net.link.lagg.X.flowid_shift to 0 > as Hiren suggested. r260179 added this shift, which has caused us > balancing issues with the i350/igb. > > https://svnweb.freebsd.org/base?view=revision&revision=260179 > > Based on Adrian's comment about igb/ixgbe not setting the 'full > flowid' under normal conditions, does that mean this shift should be 0 > by default to ensure we don't break balancing for devices that only > set the CPU/MSIX queue? Or we can just see if there's anything wrong with putting the full 32 bit RSS flowid in received packets that have them. -adrian From owner-freebsd-net@FreeBSD.ORG Wed Mar 18 17:37:09 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C1FB9B2 for ; Wed, 18 Mar 2015 17:37:09 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 713ADDB8 for ; Wed, 18 Mar 2015 17:37:09 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2IHb9pc016564 for ; Wed, 18 Mar 2015 17:37:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 138782] [panic] sbflush_internal: cc 0 || mb 0xffffff004127b000 || mbcnt 2304 Date: Wed, 18 Mar 2015 17:37:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Mar 2015 17:37:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138782 --- Comment #6 from Hiren Panchasara --- I could not figure out the root-cause but found an interesting fix that stops possible overflow in sockbuf which _may_ cause this. Discussion: https://lists.freebsd.org/pipermail/freebsd-arch/2015-February/016739.html Fix: https://svnweb.freebsd.org/changeset/base/278729 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Mar 18 17:58:17 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD708C6D for ; Wed, 18 Mar 2015 17:58:17 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B14E9FB6 for ; Wed, 18 Mar 2015 17:58:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2IHwH4B039916 for ; Wed, 18 Mar 2015 17:58:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] 8.1-RELEASE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" under heavy load Date: Wed, 18 Mar 2015 17:58:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: version cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Mar 2015 17:58:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- Version|8.1-RELEASE |10.1-STABLE CC| |hiren@FreeBSD.org, | |nitroboost@gmail.com --- Comment #15 from Hiren Panchasara --- We saw this panic on stable10 from Jan. Dump header from device /dev/da0s1b Architecture: amd64 Architecture Version: 2 Dump Length: 1050050560B (1001 MB) Blocksize: 512 Dumptime: Wed Mar 11 23:12:59 2015 Hostname: xxxxxxxxxxxxxxxxxx Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.1-STABLE-llnw10 #0: Fri Jan 16 00:19:27 MST 2015 xxxx@xxxxxxxxxxx:/usr/obj/usr/src/sys/SIXFOUR Panic String: sbsndptr: sockbuf 0xfffff802d3e79440 and mbuf 0xfffff80238089b00 clashing Dump Parity: 747892521 Bounds: 0 Dump Status: good (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff8072d397 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff8072d774 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff807a38a0 in sbsndptr (sb=, off=, len=, moff=) at /usr/src/sys/kern/uipc_sockbuf.c:1011 #4 0xffffffff80895f1f in tcp_output (tp=0xfffff802d5315400) at /usr/src/sys/netinet/tcp_output.c:1092 #5 0xffffffff80891685 in tcp_do_segment (m=0xfffff80128e51d00, th=0xfffff8020ca95022, so=0xfffff802d3e792b8, tp=0xfffff802d5315400, drop_hdrlen=, tlen=0, iptos=, ti_locked=-1) at /usr/src/sys/netinet/tcp_input.c:2729 #6 0xffffffff8088f54d in tcp_input (m=, off0=) at /usr/src/sys/netinet/tcp_input.c:1388 #7 0xffffffff808216b7 in ip_input (m=0xfffff80128e51d00) at /usr/src/sys/netinet/ip_input.c:734 #8 0xffffffff807fbc92 in netisr_dispatch_src (proto=, source=, m=0x0) at /usr/src/sys/net/netisr.c:972 #9 0xffffffff807f4656 in ether_demux (ifp=, m=0xfffff80128e51d00) at /usr/src/sys/net/if_ethersubr.c:851 #10 0xffffffff807f52e9 in ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:646 #11 0xffffffff807fbc92 in netisr_dispatch_src (proto=, source=, m=0x0) at /usr/src/sys/net/netisr.c:972 #12 0xffffffff8042332b in em_rxeof (count=94) at /usr/src/sys/dev/e1000/if_em.c:4532 #13 0xffffffff80423703 in em_msix_rx (arg=0xfffff80003ce6600) at /usr/src/sys/dev/e1000/if_em.c:1600 #14 0xffffffff806fe0fb in intr_event_execute_handlers ( p=, ie=0xfffff80003d04200) at /usr/src/sys/kern/kern_intr.c:1264 #15 0xffffffff806fea96 in ithread_loop (arg=0xfffff80003cfb3c0) at /usr/src/sys/kern/kern_intr.c:1277 #16 0xffffffff806fbd1a in fork_exit ( callout=0xffffffff806fea00 , arg=0xfffff80003cfb3c0, frame=0xfffffe03438d7c00) at /usr/src/sys/kern/kern_fork.c:1017 #17 0xffffffff80acdf5e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611 #18 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) Unfortunately I do not have a crashdump to investigate further. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Mar 18 17:59:50 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E12A6E37 for ; Wed, 18 Mar 2015 17:59:50 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5548FEA for ; Wed, 18 Mar 2015 17:59:50 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2IHxo9l040754 for ; Wed, 18 Mar 2015 17:59:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" Date: Wed, 18 Mar 2015 17:59:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Mar 2015 17:59:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[panic] 8.1-RELEASE "panic: |[panic] |sbdrop" and "panic: |8.1-RELEASE/10.1-STABLE |sbsndptr: sockbuf _ and |"panic: sbdrop" and "panic: |mbuf _ clashing" under |sbsndptr: sockbuf _ and |heavy load |mbuf _ clashing" -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Mar 18 20:25:22 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2ECC7761 for ; Wed, 18 Mar 2015 20:25:22 +0000 (UTC) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A62ED66D for ; Wed, 18 Mar 2015 20:25:20 +0000 (UTC) Received: by lbcgn8 with SMTP id gn8so38366530lbc.2 for ; Wed, 18 Mar 2015 13:25:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=OEgpZDk9T0x+6QsWSzwvQDo91U8Ee5VYGERlEK8BdiY=; b=RrSNU9zPJjmK6Yq8ntPskvasIsQYT8UD3VGXRNujpRrktXGbKxvu4j85ePRbjzrHf/ Fnqv0uxOkcfOqKWuNwfTvkMfHXv7M4YmJKIBgrQWszKk/2VMmuBPMDqWvOPMtN5qz95u DB+xiAl3jNOA0Zw047qbikSC0VPPTrJ+JKJXzCwkbXecp4+6NzOVZ7PBEQ3mzRcdeUcE RknZ9Y9rRFPTwXbm78qV4jiIDqRWJHHcTS/b+k7NfRUg67lV1orrjrGJfoIOxD7RiE6w IWtsGR8DE3D/IVPFGgyrZzTYMuEjnneGyuqia+vDUncNvMrH8y94Ia272ctzGPi0XaPi e95A== X-Gm-Message-State: ALoCoQnda5rmW1r1ZLuO1LMTnjmWZ4+8oKwLQ0KL3ldv7qYHc1UGfnbcTWKu6+y9fnjCvVgC6swK X-Received: by 10.152.179.42 with SMTP id dd10mr35274701lac.122.1426710318103; Wed, 18 Mar 2015 13:25:18 -0700 (PDT) Received: from kde4.my.domain (pppoe.178-66-76-72.dynamic.avangarddsl.ru. [178.66.76.72]) by mx.google.com with ESMTPSA id ci4sm3576794lad.16.2015.03.18.13.25.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 13:25:17 -0700 (PDT) From: Oleg Ginzburg To: Gleb Smirnoff Subject: Re: SIOCSVH, SIOCGVH ioctl(2) and virtio ethernet driver Date: Wed, 18 Mar 2015 23:26:06 +0300 Message-ID: <1500988.Vk4IEs63Dt@kde4.my.domain> User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150317122509.GR17947@glebius.int.ru> References: <36413168.TE9MLvZCzL@kde4.my.domain> <3860521.yJlCc0OyhB@kde4.my.domain> <20150317122509.GR17947@glebius.int.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: Bryan Venteicher , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Mar 2015 20:25:22 -0000 On Tuesday 17 March 2015 15:25:09 Gleb Smirnoff wrote: > On Mon, Mar 16, 2015 at 02:49:58AM +0300, Oleg Ginzburg wrote: > O> b) On FreeBSD-current r276500M CARP IP is established for some seconds, then vanishes: > In my case on r280167, all works okay, despite the carp_alloc_if warning: > > #/sbin/ifconfig vtnet0 vhid 1 advskew 100 pass navuhodonosor > 192.168.1.210/24 state master alias #dmesg | tail -n 3 > carp_alloc_if: ifpromisc(vtnet0) failed: 45 > carp: 1@vtnet0: INIT -> BACKUP (initialization complete) > carp: 1@vtnet0: BACKUP -> MASTER (master timed out) Yes. On FreeBSD HEAD everything is good now (except carp_alloc_if warning message). Carp removal after seconds in my case was retated toh devd subsystem. From owner-freebsd-net@FreeBSD.ORG Wed Mar 18 20:57:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC4E93CB; Wed, 18 Mar 2015 20:57:59 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83A08A2D; Wed, 18 Mar 2015 20:57:59 +0000 (UTC) Received: by iegc3 with SMTP id c3so49939330ieg.3; Wed, 18 Mar 2015 13:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Ia1N5MFcFNMrIzL7i2KgVoi8va/CxbGU8AtEv4aliR4=; b=PfM0urc/+qOk46A3LTaZd8KDcZvSGhqgNqi2qL7z8tSdORE2ewUleVVo9eiMxYG87t oW0TL73pmrMeWX21dbKOfpWvtSAqZR14PJY3HEEiANHmv5dJ2FgAUVObxepsNVh+nD7g M1aSY3rvn8bQOMZBmxAwO887tJxwYXC/bHaAVZO16188DMEju1DaFeBJkbGEBZL3LfbN /t0q6QTdjbIW+Bw97RsCBjn030iiIoW/7BvvO8Y7rP1jRvS71aPUVHXMQ3fndz4mwL4y +WwJc4nwshDbYSPqCQBvyyazBAB+gn0rnfXVGO/3EaIlMJiIIpK/W8Bb+Un2ULIfhMy4 k4QQ== MIME-Version: 1.0 X-Received: by 10.50.43.201 with SMTP id y9mr10642372igl.6.1426712278878; Wed, 18 Mar 2015 13:57:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Wed, 18 Mar 2015 13:57:58 -0700 (PDT) Date: Wed, 18 Mar 2015 13:57:58 -0700 X-Google-Sender-Auth: WJWsGTk-ZZnWpL6Gj9l95rWNTto Message-ID: Subject: RFT: break out IPv4 fragment reassembly locking into per-bucket locks From: Adrian Chadd To: "freebsd-arch@freebsd.org" , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Mar 2015 20:57:59 -0000 Hi, I've created a review for this: https://reviews.freebsd.org/D2095 It does a couple things: * The IPv4 reassembly locking is now per-bucket, rather than global * If space needs to be made, it's made /after/ the reassembly queue manipulation is done. This way it's done without the queue lock held, rather than trying to grab a lock for bucket X whilst doing work in bucket Y. This dramatically reduces the lock contention when doing IPv4 fragment reassembly. I'd prefer this to be done along RSS bucket lines so there's /no/ lock contention during RSS based IPv4 fragment reassembly, but this is a good first step and applies even if RSS isn't being done. I'd appreciate any testing/reviews people may have. Thanks, -adrian From owner-freebsd-net@FreeBSD.ORG Thu Mar 19 02:20:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 800608E7 for ; Thu, 19 Mar 2015 02:20:45 +0000 (UTC) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54196164 for ; Thu, 19 Mar 2015 02:20:44 +0000 (UTC) Received: by pdbop1 with SMTP id op1so60913423pdb.2 for ; Wed, 18 Mar 2015 19:20:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=4XvaHy05KakiBA34tN4UW5sI1PaCynJ2zOT8y6qfqro=; b=Y15K979xpn7MvTO0DdUbaOyiriR+abwikOyi1jW5qbBTJoY377lowo02xranydQF2j JA8CItGydtncFozsc+8IQMsK3VXR7PAM+oOxEmKJxcdIYc3fzihkQC8SQo6j81Ke9Y4+ +RG4MxVqYjgHPNjAlNSQ812ARwx1rtNadb72Auy3VA/5BzxmfM2XG0iHrG170v0yhChI yTazZd0Vcwue3LpPZHBgrv9xO5WXyzTLADyxiI6iDj6mPH3FmQyU8WaDt0QysweT8U96 CR4AD44XgSeCeQHHcOB2Jaf4xycctEnvY8xJogcvfE+mfL5NgxdlDu/1/ADci0ehnR4t 3E8Q== X-Gm-Message-State: ALoCoQlVeRoTvvUBd2orjb93yTKoQa2ksFuppnxt2nNQvuFQxG5H0BtN4ksIYZBT9FOTvFh529Cg X-Received: by 10.66.66.196 with SMTP id h4mr167252243pat.127.1426731638244; Wed, 18 Mar 2015 19:20:38 -0700 (PDT) Received: from [128.199.254.70] (sgp.sin.winterei.se. [128.199.254.70]) by mx.google.com with ESMTPSA id mk1sm2078067pdb.71.2015.03.18.19.20.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 19:20:37 -0700 (PDT) Message-ID: <550A3271.2040501@winterei.se> Date: Thu, 19 Mar 2015 11:20:33 +0900 From: "Paul S." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-net Subject: Unremovable ARP entry and 'address already in use' Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Mar 2015 02:20:45 -0000 Hi, Seeing this on 10.1-release p5. FreeBSD ipfw-0.syd.fqdn.tld 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #0 r278455: Mon Feb 9 07:18:21 UTC 2015 root@ipfw-0.syd.fqdn.tld:/usr/obj/usr/src/sys/qfkern amd64 Basically, I have a static arp entry that I cannot remove. This in itself is not a problem. Problem is, when trying to assign that IP address to the same interface, it says the 'address is in use' (which it is not) ? (110.62..211.87) at 00:12:c0:88:03:8f on ix1 permanent [ethernet] Attempting to remove the entry produces an invalid argument error. root@ipfw-0:~ # arp -d 110.62..211.87 arp: writing to routing socket: Invalid argument ix1 does not have this IP configured anymore either. ix1: flags=8843 metric 0 mtu 1500 description: FW Upstream 0 options=8400bb ether 00:12:c0:88:03:8f inet6 fe80::212:c0ff:fe88:38f%ix1 prefixlen 64 scopeid 0x2 nd6 options=21 media: Ethernet autoselect (10Gbase-LR ) status: active When I try to assign it back to ix1, I get this root@ipfw-0:~ # ifconfig ix1 inet 110.62..211.87 netmask 255.255.254.0 ifconfig: ioctl (SIOCAIFADDR): Address already in use I've verified with the provider that there isn't an arp entry at present for this IP address, so the issue seems local to freebsd. Anyone ever see anything like this? I'm aware rebooting will fix it, but this is a live firewall and I'd rather not do that. From owner-freebsd-net@FreeBSD.ORG Thu Mar 19 02:25:05 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDF89A88 for ; Thu, 19 Mar 2015 02:25:04 +0000 (UTC) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0173218 for ; Thu, 19 Mar 2015 02:25:04 +0000 (UTC) Received: by pdbni2 with SMTP id ni2so61093310pdb.1 for ; Wed, 18 Mar 2015 19:25:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m0VpigRw57LJ3Fx/85HjYspFCPg6YsWy/WyjudHxndo=; b=L81gV6CJOwbkbXGP0I6m/IP0rGNmLUd2BcaGQmN2d37XHnYsH8HYZ2Qvh2f/9yESaW WDIIxWN7+kycD4DMMEIsO+2h5v4pVX0HHoqt+C4f39iOe0mPvpXzlAYxOGeRmmmRN3kW WtQiwr62TS8ecGqhBKnGptW9YLkkj0C5T7bBWvFVKQCD289usboixG31NFEYBNtj4O7e vFyHho87AISbGjQ2+YULxZfbFGjptxCvNhhK0yuOD6pmcm8M4isIbBfowWXMJyh9zVEk iAzKQfjrGhVdiLzdiuRVPNfbV3ko2yCd8Z8ZTt687Rf5tuh0LGQ794Sk0GjOJ/rJLJ1c qE2w== X-Gm-Message-State: ALoCoQlFV6L+ULfilCqNgdQuZ4eIX8tP3Xsn679aFnqP6xJgi1zWWmVJ/uydJ9LaQYaTPqi55rcf X-Received: by 10.70.55.132 with SMTP id s4mr5494713pdp.107.1426731903895; Wed, 18 Mar 2015 19:25:03 -0700 (PDT) Received: from [128.199.254.70] (sgp.sin.winterei.se. [128.199.254.70]) by mx.google.com with ESMTPSA id n10sm29750894pdp.18.2015.03.18.19.25.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 19:25:03 -0700 (PDT) Message-ID: <550A337C.9030905@winterei.se> Date: Thu, 19 Mar 2015 11:25:00 +0900 From: "Paul S." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-net Subject: Re: Unremovable ARP entry and 'address already in use' References: <550A3271.2040501@winterei.se> In-Reply-To: <550A3271.2040501@winterei.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Mar 2015 02:25:05 -0000 I just noticed that when obfuscating the IP, I added two dots. Please excuse them, the IP is proper (110.62.211.87 for the purposes of this thread) On 3/19/2015 午前 11:20, Paul S. wrote: > Hi, > > Seeing this on 10.1-release p5. > > FreeBSD ipfw-0.syd.fqdn.tld 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #0 > r278455: Mon Feb 9 07:18:21 UTC 2015 > root@ipfw-0.syd.fqdn.tld:/usr/obj/usr/src/sys/qfkern amd64 > > Basically, I have a static arp entry that I cannot remove. This in > itself is not a problem. Problem is, when trying to assign that IP > address to the same interface, it says the 'address is in use' (which > it is not) > > ? (110.62..211.87) at 00:12:c0:88:03:8f on ix1 permanent [ethernet] > > Attempting to remove the entry produces an invalid argument error. > > root@ipfw-0:~ # arp -d 110.62..211.87 > arp: writing to routing socket: Invalid argument > > ix1 does not have this IP configured anymore either. > > ix1: flags=8843 metric 0 mtu 1500 > description: FW Upstream 0 > options=8400bb > > ether 00:12:c0:88:03:8f > inet6 fe80::212:c0ff:fe88:38f%ix1 prefixlen 64 scopeid 0x2 > nd6 options=21 > media: Ethernet autoselect (10Gbase-LR ) > status: active > > When I try to assign it back to ix1, I get this > > root@ipfw-0:~ # ifconfig ix1 inet 110.62..211.87 netmask 255.255.254.0 > ifconfig: ioctl (SIOCAIFADDR): Address already in use > > I've verified with the provider that there isn't an arp entry at > present for this IP address, so the issue seems local to freebsd. > > Anyone ever see anything like this? > > I'm aware rebooting will fix it, but this is a live firewall and I'd > rather not do that. From owner-freebsd-net@FreeBSD.ORG Thu Mar 19 11:38:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31576470 for ; Thu, 19 Mar 2015 11:38:32 +0000 (UTC) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id E774B21B for ; Thu, 19 Mar 2015 11:38:31 +0000 (UTC) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id A55F32700618 for ; Thu, 19 Mar 2015 12:38:29 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 7F14727004F0 for ; Thu, 19 Mar 2015 12:38:29 +0100 (CET) Received: from work.netasq.com ([127.0.0.1]) by localhost (work.netasq.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id No4GlBdk6DoD for ; Thu, 19 Mar 2015 12:38:29 +0100 (CET) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 4EE562700239 for ; Thu, 19 Mar 2015 12:38:29 +0100 (CET) Date: Thu, 19 Mar 2015 12:38:29 +0100 (CET) From: Emeric POUPON To: freebsd-net Message-ID: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> In-Reply-To: <1199418178.25515724.1426763725517.JavaMail.zimbra@stormshield.eu> Subject: Fragment questions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Thread-Topic: Fragment questions Thread-Index: xZ/5lVsqWl2lqj6e4F5zlr+fIibc+A== X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Mar 2015 11:38:32 -0000 Hello, I noticed two questionable things in the fragmentation code: - in ip_fragment, we do not copy the flowid from the original mbuf to the fragmented mbuf. Therefore we may output very desynchronized fragments (first fragment emitted far later the second fragment, etc.) - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use randomized id. In multi core systems, we may emit successive packets with the same id. Both problems combined lead to bad packet reassembly on the remote host. What do you think? Emeric From owner-freebsd-net@FreeBSD.ORG Thu Mar 19 12:53:50 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 007C749E for ; Thu, 19 Mar 2015 12:53:49 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2E8FCE7 for ; Thu, 19 Mar 2015 12:53:49 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0FE131FE023; Thu, 19 Mar 2015 13:53:46 +0100 (CET) Message-ID: <550AC709.1050404@selasky.org> Date: Thu, 19 Mar 2015 13:54:33 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Emeric POUPON , freebsd-net Subject: Re: Fragment questions References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> In-Reply-To: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Mar 2015 12:53:50 -0000 On 03/19/15 12:38, Emeric POUPON wrote: > Hello, > > I noticed two questionable things in the fragmentation code: > - in ip_fragment, we do not copy the flowid from the original mbuf to the fragmented mbuf. Therefore we may output very desynchronized fragments (first fragment emitted far later the second fragment, etc.) > - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use randomized id. In multi core systems, we may emit successive packets with the same id. > > Both problems combined lead to bad packet reassembly on the remote host. > > What do you think? > Hi, I think this issue is already fixed: https://svnweb.freebsd.org/base/head/sys/netinet/ip_output.c?revision=278103&view=markup --HPS From owner-freebsd-net@FreeBSD.ORG Thu Mar 19 15:43:23 2015 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27249B28; Thu, 19 Mar 2015 15:43:23 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A38F728A; Thu, 19 Mar 2015 15:43:18 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t2JFh9Kq072445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Mar 2015 18:43:09 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t2JFh9RM072444; Thu, 19 Mar 2015 18:43:09 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 19 Mar 2015 18:43:09 +0300 From: Gleb Smirnoff To: net@FreeBSD.org, arch@FreeBSD.org Subject: opaque ifnet progress Message-ID: <20150319154309.GT64665@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Mar 2015 15:43:23 -0000 Hi! It is already several years as the "opaque ifnet" has been discussed, and almost a year since it was announced to be worked on. For now I've got a branch in svn, where some proof of concept is done: http://svn.freebsd.org/base/projects/ifnet I've described what's going on in wiki: https://wiki.freebsd.org/projects/ifnet If you are writing/maintaining a NIC driver, you must look there and share your opinion with me. You should also look at already converted drivers and again share your opinion. At current stage I need feeling of approvement and agreement from people who write drivers, since being on my own I don't feel confident that I am doing things right. So, please look at wiki and code! P.S. Of course job of converting all drivers to new KPI is extremely heavy lifting, so any help with the project if very much appreciated. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Mar 19 15:58:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADCCE48A for ; Thu, 19 Mar 2015 15:58:45 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 909236AC for ; Thu, 19 Mar 2015 15:58:45 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id C9E7456467; Thu, 19 Mar 2015 10:58:44 -0500 (CDT) Message-ID: <550AF20C.2040304@vangyzen.net> Date: Thu, 19 Mar 2015 11:58:04 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Paul S." , freebsd-net Subject: Re: Unremovable ARP entry and 'address already in use' References: <550A3271.2040501@winterei.se> <550A337C.9030905@winterei.se> In-Reply-To: <550A337C.9030905@winterei.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Mar 2015 15:58:45 -0000 > On 3/19/2015 =E5=8D=88=E5=89=8D 11:20, Paul S. wrote: >> root@ipfw-0:~ # arp -d 110.62..211.87 >> arp: writing to routing socket: Invalid argument I have a vague memory of similar behavior when I had a misconfigured route. I think there was a route for a local interface address with an off-box gateway. (Don't ask. Long story. Not my fault! :) ) Eric From owner-freebsd-net@FreeBSD.ORG Thu Mar 19 17:51:52 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1BA92CA; Thu, 19 Mar 2015 17:51:52 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B53FE94A; Thu, 19 Mar 2015 17:51:52 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 9D762106AF6; Thu, 19 Mar 2015 10:51:45 -0700 (PDT) Date: Thu, 19 Mar 2015 10:51:45 -0700 From: hiren panchasara To: Adrian Chadd Subject: Re: Unbalanced LACP link Message-ID: <20150319175145.GH53237@strugglingcoder.info> References: <5506A5BB.5060204@selasky.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZPDwMsyfds7q4mrK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Hans Petter Selasky , FreeBSD Net , Konstantin Kulikov , Vitalii Duk , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Mar 2015 17:51:52 -0000 --ZPDwMsyfds7q4mrK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/17/15 at 12:34P, Adrian Chadd wrote: > On 17 March 2015 at 11:33, Jason Wolfe wrote: > > On Mon, Mar 16, 2015 at 2:43 AM, Hans Petter Selasky = wrote: > >> On 03/16/15 10:37, Vitalii Duk wrote: > >>> > >>> I've changed use_flowid to 0 and it helped! But isn't it setting > >>> significant? In a description it says "Shift flowid bits to prevent > >>> multiqueue collisions". > >> > >> > >> Hi, > >> > >> Maybe your ethernet hardware is not properly setting the m_flowid ... > >> > >> --HPS > >> > > > > Flip use_flowid back to 1 and try setting > > net.link.lagg.default_flowid_shift / net.link.lagg.X.flowid_shift to 0 > > as Hiren suggested. r260179 added this shift, which has caused us > > balancing issues with the i350/igb. > > > > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D260179 > > > > Based on Adrian's comment about igb/ixgbe not setting the 'full > > flowid' under normal conditions, does that mean this shift should be 0 > > by default to ensure we don't break balancing for devices that only > > set the CPU/MSIX queue? >=20 > Or we can just see if there's anything wrong with putting the full 32 > bit RSS flowid in received packets that have them. It'd be nice to have but for now I am proposing following to fix a known broken case because of an optimization: https://reviews.freebsd.org/D2098 Cheers, Hiren --ZPDwMsyfds7q4mrK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVCwywXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lsesH/02upw4F9JtJkb4fecFb6URi miXS1cjOBVah2ayhhCUHa0KQNIRG1kc3mtbk62GmF3PsF2Ryvjd8GqbNl+Vb118d R56tdlrm9nADZcRVo36ZsLVpbiCMfmnt+BQ/tsSMVCKHI68XNXuHV/oBYsgEwL93 7PrNOqHLE3oI0HIYV5eAfi9FHK0GJma3UzNcVu3uWjid/Jcc1579qVsJewjlrRJA Pcj/NWxvXCSBqeT04NwPRNmDRax4QG59/vUoNbiR3ROn5NjvNCeo1IS3ttIxpE7e n6DASChfNzsOwD8kGs7IiRrWqLJLpkoQxzbbY/6OLvugDYovelNtMUUw6rPbiVg= =GtJT -----END PGP SIGNATURE----- --ZPDwMsyfds7q4mrK-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 19 18:12:58 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B3E3BA3 for ; Thu, 19 Mar 2015 18:12:58 +0000 (UTC) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2901DDE for ; Thu, 19 Mar 2015 18:12:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t2JICqgp013684 for ; Thu, 19 Mar 2015 19:12:52 +0100 (CET) Received: from [IPv6:2003:55:6b60:3200:1cd9:c517:27f3:cb29] (p200300556B6032001CD9C51727F3CB29.dip0.t-ipconnect.de [IPv6:2003:55:6b60:3200:1cd9:c517:27f3:cb29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3l7GYc60b4z2pZS for ; Thu, 19 Mar 2015 19:12:52 +0100 (CET) Message-ID: <550B11A4.4090507@tzi.de> Date: Thu, 19 Mar 2015 19:12:52 +0100 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: gre(4) over IPv6 References: <5506E8C1.70602@tzi.de> <550723AA.7040707@yandex.ru> In-Reply-To: <550723AA.7040707@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Mar 2015 18:12:58 -0000 Hi, is anyone going to include gre over IPv6 into the current stable branch? It would be nice to have it in the upcoming 10.2 release. Kind regards Julian From owner-freebsd-net@FreeBSD.ORG Thu Mar 19 20:26:09 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B66E8C93 for ; Thu, 19 Mar 2015 20:26:09 +0000 (UTC) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 872C0243 for ; Thu, 19 Mar 2015 20:26:08 +0000 (UTC) Received: by pabyw6 with SMTP id yw6so85706698pab.2 for ; Thu, 19 Mar 2015 13:26:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Xcr6VoZ7Co9dWFf3kWn99/hD+NExY6HlkH3OtTRB2aA=; b=SkP7P1p1VvQI3lJNrbAC14wesP/FvOqtI5+d6BzsM2zwOJE5e+pAz5Ul34weTNOUyX CpSe4xc+kQ8/vomtrQFJoIKsXjVasn4ste+mV7O7lwXNC3X02rvZwcy3g6rcp2nWjD28 KHKriIWdnexbpYsjfpUjLQclHAZ3O8sPZf8+SCvQWfktAUr+m15Iyji16TtwtjnxOC7D EBOPli2cPwJFGLVRfNt1QlNy/A5TEH9JHKxJANbMCwcfn/1+rv9iaNyiPqe9j0Feg7fK qxNuC+2nz0FcmJUHZ96h4Ho7NT4Y7YPN5vL/CeSv2/RaZL+sFtNNxUxIXg6OttTiAwko WeBA== X-Gm-Message-State: ALoCoQnE3NxUcdqbuMJh+KWdJXCduPTvNI/5DMdCiKaY1mKr5N0IHwpsPV09mA5ONKvW9dTd7j2u X-Received: by 10.70.45.169 with SMTP id o9mr123714807pdm.81.1426796762489; Thu, 19 Mar 2015 13:26:02 -0700 (PDT) Received: from [128.199.254.70] (sgp.sin.winterei.se. [128.199.254.70]) by mx.google.com with ESMTPSA id cb9sm4432469pad.46.2015.03.19.13.26.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 13:26:01 -0700 (PDT) Message-ID: <550B30D8.7070000@winterei.se> Date: Fri, 20 Mar 2015 05:26:00 +0900 From: "Paul S." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Eric van Gyzen Subject: Re: Unremovable ARP entry and 'address already in use' References: <550A3271.2040501@winterei.se> <550A337C.9030905@winterei.se> <550AF20C.2040304@vangyzen.net> In-Reply-To: <550AF20C.2040304@vangyzen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Mar 2015 20:26:09 -0000 Guess was right on the money, thank you! It turns out that there was a route for that entire /23 on another interface for some unfathomable reason. I had to turn that iface down too to remove it, but once I did so, everything is once again peachy! Thank you! On 3/20/2015 午前 12:58, Eric van Gyzen wrote: >> On 3/19/2015 午前 11:20, Paul S. wrote: >>> root@ipfw-0:~ # arp -d 110.62..211.87 >>> arp: writing to routing socket: Invalid argument > I have a vague memory of similar behavior when I had a misconfigured > route. I think there was a route for a local interface address with an > off-box gateway. (Don't ask. Long story. Not my fault! :) ) > > Eric > From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 09:23:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF7B3AC5 for ; Fri, 20 Mar 2015 09:23:32 +0000 (UTC) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A072EC6 for ; Fri, 20 Mar 2015 09:23:31 +0000 (UTC) Received: by wixw10 with SMTP id w10so23426876wix.0 for ; Fri, 20 Mar 2015 02:23:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=IExX5DcaBzi9bwR8WJytTDl2UUTkvDQZo/yN6GMgK5E=; b=kwbODqSPOarXW/+cD8Y+fXXgYF6h8ZQoPQ8yLZ6ep4h84rl9G+HpgKpHA3Ag9q/UpG 1lzdRc6nhxZeuv+wO1O1EjYoKZ1TaeBtnqZ7z/lwF5JnRDB/J97PG8tCHlcHmNXJLcut tBzGlXFdG+Ms4P3Pi0Fz+1ZY8KdBTu23tIbcVLELxckFiYCz3DB1hFbkA62Hn0t8+B7x ulIAxPQ4TxtglRnBQ6L/Q+9tA+QlB3ZenVxHF/2cJlKGoZwW4vrHDVWqNfTJOI4Yc8TG MoDSXTGI8dpcr9/CdEQv3M3151Nq5DC6ON45vLWUOgxSK0CXkIfd2LoSTxUg0pWH+NEi i6dg== X-Gm-Message-State: ALoCoQnO1ojMtR7AJpPkU36ZukNI7u+yvKSW2LkO0mXMc+liN5zJX+8qAOJjYD/aiMxXS18gqPeZ X-Received: by 10.180.126.38 with SMTP id mv6mr23055583wib.22.1426843404442; Fri, 20 Mar 2015 02:23:24 -0700 (PDT) Received: from [10.15.38.46] ([5.20.223.100]) by mx.google.com with ESMTPSA id a6sm2161768wiy.17.2015.03.20.02.23.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Mar 2015 02:23:23 -0700 (PDT) From: =?utf-8?Q?Vaidas_Damo=C5=A1evi=C4=8Dius?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Troubles with 'em' driver and UDP packets Message-Id: <7F780FA4-E826-4C83-98CC-549FECEDA35E@par.lt> Date: Fri, 20 Mar 2015 11:23:21 +0200 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 09:23:32 -0000 Hello, I have 2 boxes with FreeBSD 10.1-RELEASE/amd64 and "Intel(R) PRO/1000 = Network Connection 7.4.2" NIC's directly connected to each other. I = noticed strange problem - I'm loosing small UDP packets under high load. = I've tried to test it with iperf and got the following: --- vd@v0s4:~ % iperf3 -u -c 1.2.3.4 Connecting to host 1.2.3.4, port 5201 [ 4] local 1.2.3.3 port 64254 connected to 1.2.3.4 port 5201 [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-1.01 sec 120 KBytes 976 Kbits/sec 15 =20 [ 4] 1.01-2.01 sec 128 KBytes 1.05 Mbits/sec 16 =20 [ 4] 2.01-3.01 sec 128 KBytes 1.05 Mbits/sec 16 =20 [ 4] 3.01-4.01 sec 128 KBytes 1.05 Mbits/sec 16 =20 [ 4] 4.01-5.01 sec 128 KBytes 1.05 Mbits/sec 16 =20 [ 4] 5.01-6.01 sec 128 KBytes 1.05 Mbits/sec 16 =20 [ 4] 6.01-7.01 sec 128 KBytes 1.05 Mbits/sec 16 =20 [ 4] 7.01-8.00 sec 128 KBytes 1.05 Mbits/sec 16 =20 [ 4] 8.00-9.01 sec 128 KBytes 1.05 Mbits/sec 16 =20 [ 4] 9.01-10.01 sec 128 KBytes 1.05 Mbits/sec 16 =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Jitter = Lost/Total Datagrams [ 4] 0.00-10.01 sec 1.24 MBytes 1.04 Mbits/sec 0.325 ms 0/159 = (0%) =20 [ 4] Sent 159 datagrams Any advice how to solve it ? Thank you.= From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 09:29:41 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A478DAF for ; Fri, 20 Mar 2015 09:29:41 +0000 (UTC) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C72F8F01 for ; Fri, 20 Mar 2015 09:29:40 +0000 (UTC) Received: by yhjf44 with SMTP id f44so37221061yhj.3 for ; Fri, 20 Mar 2015 02:29:39 -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=tEDSdjm2QOclIUHeCtlUdsDn71LwGOak1/ks9/syB4k=; b=DaGtoPhbdvxIhqgEztchvTzOc88Ktdk7alhd+V5nltSfCqobMaEt49lsTSjbuCz9jI dahFxbw/GDxmMaj6HcZEFlJQft5/aC8g9VH80bZcPJvQALvBQqR3YnQaVnLsH4Ga6knt k0GYFZLKZ/MOCMnSgKkDvGTJpQ2sziCOaV8R0t7hLJDtoW2FrjwX0LmljBi/BK85Kx8T 4yFZgSWO+x6fLzSmGU2WgL5FHNG+F7WwC1Z+E1uIZYmKDmKjUKNZqPLNLjkhNSEdXTSu p3fxxYJ1h3QJhYs8J3+sPJav4ZDTDALGswI0WbVzy3l9p6SY07JrsFcZ6DkpAIVAcQ/Z qsvw== MIME-Version: 1.0 X-Received: by 10.170.90.70 with SMTP id h67mr92771144yka.46.1426843779852; Fri, 20 Mar 2015 02:29:39 -0700 (PDT) Received: by 10.170.60.69 with HTTP; Fri, 20 Mar 2015 02:29:39 -0700 (PDT) In-Reply-To: <7F780FA4-E826-4C83-98CC-549FECEDA35E@par.lt> References: <7F780FA4-E826-4C83-98CC-549FECEDA35E@par.lt> Date: Fri, 20 Mar 2015 02:29:39 -0700 Message-ID: Subject: Re: Troubles with 'em' driver and UDP packets From: Mehmet Erol Sanliturk To: =?UTF-8?B?VmFpZGFzIERhbW/FoWV2acSNaXVz?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 09:29:41 -0000 On Fri, Mar 20, 2015 at 2:23 AM, Vaidas Damo=C5=A1evi=C4=8Dius = wrote: > Hello, > > I have 2 boxes with FreeBSD 10.1-RELEASE/amd64 and "Intel(R) PRO/1000 > Network Connection 7.4.2" NIC's directly connected to each other. I notic= ed > strange problem - I'm loosing small UDP packets under high load. I've tri= ed > to test it with iperf and got the following: > > --- > > vd@v0s4:~ % iperf3 -u -c 1.2.3.4 > Connecting to host 1.2.3.4, port 5201 > [ 4] local 1.2.3.3 port 64254 connected to 1.2.3.4 port 5201 > [ ID] Interval Transfer Bandwidth Total Datagrams > [ 4] 0.00-1.01 sec 120 KBytes 976 Kbits/sec 15 > [ 4] 1.01-2.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 2.01-3.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 3.01-4.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 4.01-5.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 5.01-6.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 6.01-7.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 7.01-8.00 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 8.00-9.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 9.01-10.01 sec 128 KBytes 1.05 Mbits/sec 16 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth Jitter Lost/Tota= l > Datagrams > [ 4] 0.00-10.01 sec 1.24 MBytes 1.04 Mbits/sec 0.325 ms 0/159 (0%= ) > [ 4] Sent 159 datagrams > > Any advice how to solve it ? > > Thank you. > _______________________________________________ > > I think you use Gigabit CROSS cable ( cat 5e or cat 6 ) . CROSS cable is required if connection is from computer to computer . Only for remaindering . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 09:42:15 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98832220 for ; Fri, 20 Mar 2015 09:42:15 +0000 (UTC) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F8E5101 for ; Fri, 20 Mar 2015 09:42:14 +0000 (UTC) Received: by wixw10 with SMTP id w10so23675002wix.0 for ; Fri, 20 Mar 2015 02:42:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=yZH/P1AYn2jPqg9nFa3ZRE1sXne45IhhrDGhZgmlybg=; b=DrNFuFyvO7yH4sbx8Uttp9MP5fn4lG2YuAvbWvy/Gp0iW1HnAIKTxV4jZfLH9lMSF8 ojxLwhZ9zwgMYU1e4jW/L4pa+3DhxkM2Bx6POdNHr5IPVi1hPxWYRVLlkKmLd5hdWZQZ FaAtI6v/Ir0G23n38pFJ2Xfs7uyOa2+oZQzkRFS4JDQ4JK/KrQw9mitdIIFM27/ZlA6I CNWrhkyaFDgv94WpXiNNED01t/TWuGl12d9F2jHafSgNgDnMoU+xWViFnyXiKpbSyawu jlRbqI510vojiInQ4A1MFoEItAJwh8wmWKY6ihdTIfP+SDyq8S7QtI0XW6zW8m+al5yE rElg== X-Gm-Message-State: ALoCoQnVeK7+dbAmU12QbCkr5u6gCjblB7SNrbyu4hUsUlxtHk70hXX5ZrZJZzpdaRTgfx4hj/5f X-Received: by 10.180.72.98 with SMTP id c2mr23467057wiv.87.1426844532513; Fri, 20 Mar 2015 02:42:12 -0700 (PDT) Received: from [10.15.38.46] ([5.20.223.100]) by mx.google.com with ESMTPSA id xy2sm5580628wjc.14.2015.03.20.02.42.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Mar 2015 02:42:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Troubles with 'em' driver and UDP packets From: =?utf-8?Q?Vaidas_Damo=C5=A1evi=C4=8Dius?= In-Reply-To: Date: Fri, 20 Mar 2015 11:42:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F780FA4-E826-4C83-98CC-549FECEDA35E@par.lt> To: Mehmet Erol Sanliturk X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 09:42:15 -0000 It's not cabling problem :) Another example with -b and -i : vd@v0s4:~ % iperf3 -u -c 1.2.3.4 -i4 -b1000m -P1 Connecting to host 1.2.3.4, port 5201 [ 4] local 1.2.3.3 port 10672 connected to 1.2.3.4 port 5201 [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-4.00 sec 446 MBytes 935 Mbits/sec 1761605 =20 [ 4] 4.00-8.00 sec 457 MBytes 958 Mbits/sec 1809551 =20 [ 4] 8.00-10.00 sec 228 MBytes 958 Mbits/sec 900740 =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Jitter = Lost/Total Datagrams [ 4] 0.00-10.00 sec 1.10 GBytes 949 Mbits/sec 770.668 ms 0/35 = (0%) =20 [ 4] Sent 35 datagrams Result is totaly different. > On 20 Mar 2015, at 11:29, Mehmet Erol Sanliturk = wrote: >=20 >=20 >=20 > On Fri, Mar 20, 2015 at 2:23 AM, Vaidas Damo=C5=A1evi=C4=8Dius = wrote: > Hello, >=20 > I have 2 boxes with FreeBSD 10.1-RELEASE/amd64 and "Intel(R) PRO/1000 = Network Connection 7.4.2" NIC's directly connected to each other. I = noticed strange problem - I'm loosing small UDP packets under high load. = I've tried to test it with iperf and got the following: >=20 > --- >=20 > vd@v0s4:~ % iperf3 -u -c 1.2.3.4 > Connecting to host 1.2.3.4, port 5201 > [ 4] local 1.2.3.3 port 64254 connected to 1.2.3.4 port 5201 > [ ID] Interval Transfer Bandwidth Total Datagrams > [ 4] 0.00-1.01 sec 120 KBytes 976 Kbits/sec 15 > [ 4] 1.01-2.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 2.01-3.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 3.01-4.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 4.01-5.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 5.01-6.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 6.01-7.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 7.01-8.00 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 8.00-9.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 9.01-10.01 sec 128 KBytes 1.05 Mbits/sec 16 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth Jitter = Lost/Total Datagrams > [ 4] 0.00-10.01 sec 1.24 MBytes 1.04 Mbits/sec 0.325 ms 0/159 = (0%) > [ 4] Sent 159 datagrams >=20 > Any advice how to solve it ? >=20 > Thank you. > _______________________________________________ >=20 >=20 >=20 >=20 > I think you use Gigabit CROSS cable ( cat 5e or cat 6 ) . > CROSS cable is required if connection is from computer to computer . >=20 > Only for remaindering . >=20 >=20 >=20 > Thank you very much . >=20 > Mehmet Erol Sanliturk >=20 >=20 >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 09:49:36 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB12A3EA for ; Fri, 20 Mar 2015 09:49:36 +0000 (UTC) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59314135 for ; Fri, 20 Mar 2015 09:49:36 +0000 (UTC) Received: by wgra20 with SMTP id a20so84680727wgr.3 for ; Fri, 20 Mar 2015 02:49:34 -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:message-id :subject:to:cc:content-type; bh=RenYdv+IRGDVY8ZNWR8QSo+RFpl5GB09NLI385YAC20=; b=y6ZFIJC7flvpZ9wS7pRxciYgQ/1m9vRDvO0gECjoZzVoLnt2NaiZs/FbbecWiyQkte Cgl2KDb+ISKqotEH09VVCJCmiOd/pxVHNY1zuHZlNFE32rJasMDp8qTM6+3JCuoJpIpJ 15coUhM9BLVVRO4eayZa269rpOPIEyXpxARoUqfOGMyJjIZrAp+xqvuiWod/B7IffIb+ 13g6EZy0t+3TBkd/cTRDxk578j5H3pMBii4NKl0m48PDV3F1lVvyzNxBBdJH7oVvaUq0 dtOD83gfBdCTHyqVblh03xYlDINBNm5iPPIGAqcofG8mxIAkMbBfLix475KlMJxsIxHj UXzQ== X-Received: by 10.181.13.82 with SMTP id ew18mr23815577wid.84.1426844974525; Fri, 20 Mar 2015 02:49:34 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.63.34 with HTTP; Fri, 20 Mar 2015 02:49:14 -0700 (PDT) In-Reply-To: <7F780FA4-E826-4C83-98CC-549FECEDA35E@par.lt> References: <7F780FA4-E826-4C83-98CC-549FECEDA35E@par.lt> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Fri, 20 Mar 2015 10:49:14 +0100 X-Google-Sender-Auth: 2y5ZmLPCxUWx3Wxj92qkMBjhR1o Message-ID: Subject: Re: Troubles with 'em' driver and UDP packets To: =?ISO-8859-13?Q?Vaidas_Damo=F0evi=E8ius?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 09:49:36 -0000 On Fri, Mar 20, 2015 at 10:23 AM, Vaidas Damo=C5=A1evi=C4=8Dius = wrote: > Hello, > =E2=80=8BHi, =E2=80=8B > > I have 2 boxes with FreeBSD 10.1-RELEASE/amd64 and "Intel(R) PRO/1000 > Network Connection 7.4.2" NIC's directly connected to each other. I notic= ed > strange problem - I'm loosing small UDP packets under high load. I've tri= ed > to test it with iperf and got the following: > > --- > > vd@v0s4:~ % iperf3 -u -c 1.2.3.4 > Connecting to host 1.2.3.4, port 5201 > [ 4] local 1.2.3.3 port 64254 connected to 1.2.3.4 port 5201 > [ ID] Interval Transfer Bandwidth Total Datagrams > [ 4] 0.00-1.01 sec 120 KBytes 976 Kbits/sec 15 > [ 4] 1.01-2.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 2.01-3.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 3.01-4.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 4.01-5.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 5.01-6.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 6.01-7.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 7.01-8.00 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 8.00-9.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 9.01-10.01 sec 128 KBytes 1.05 Mbits/sec 16 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth Jitter Lost/Tota= l > Datagrams > [ 4] 0.00-10.01 sec 1.24 MBytes 1.04 Mbits/sec 0.325 ms 0/159 (0%= ) > [ 4] Sent 159 datagrams > > =E2=80=8BThe result display a Lost/Total ratio of 0/159: Where do you see m= issing UDP packets ? By default iperf send only 1 Mbit/sec in UDP mode: I didn't see any problem on these stats. Regards, Olivier =E2=80=8B From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 09:57:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 890EF646 for ; Fri, 20 Mar 2015 09:57:45 +0000 (UTC) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C9FE21F for ; Fri, 20 Mar 2015 09:57:44 +0000 (UTC) Received: by wibg7 with SMTP id g7so23854345wib.1 for ; Fri, 20 Mar 2015 02:57:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=jiSEb06B4tXnpF9E/B3alCH5S7y0Y04HqT7uqrvCAFw=; b=RgwF1lnJ3vfKxpj/Sdqxly+rU+6imzFtuCBsN237wPcNsR4YbYTk81PpgAV6R1Yi+Y gXUDOzlboqDSuX+kvfP6XcQynCw2MwS0v8PmWjxQosGcRVLsw5ClARmlBGrJkCcy8RPK tRWJQ9CICJOYM5Ih4/d4ZG+KyqP/EHbvsnRf6gjlf9HN6zInrbHQ5QHwhlj+rrR+cYoh iJf1CXMokiobg6USudt9GsoDDp0+YjJS1RlBT5jaBMBm/GTuBS7Lw1zasNEVxJb+sAT8 ijGZ5y/G+jKUyKv6Dj1jIzxaVy1XDemhnIm9nvLoCe3Q2Zd1ZXSCG2RUO/HehYL7ADyp YmEQ== X-Gm-Message-State: ALoCoQmPN32eVzUgCKp7J6a09EexUuu9+iVEszT9VNfMb0X5OH5S/MIHe4/RePmjgofHkmk4dTo7 X-Received: by 10.194.177.132 with SMTP id cq4mr153188174wjc.99.1426845155252; Fri, 20 Mar 2015 02:52:35 -0700 (PDT) Received: from [10.15.38.46] ([5.20.223.100]) by mx.google.com with ESMTPSA id fs8sm2275001wib.8.2015.03.20.02.52.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Mar 2015 02:52:34 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Troubles with 'em' driver and UDP packets From: =?utf-8?Q?Vaidas_Damo=C5=A1evi=C4=8Dius?= In-Reply-To: Date: Fri, 20 Mar 2015 11:52:33 +0200 Message-Id: <0D7B72DF-8365-4E2A-931F-ABD710D9E9B3@par.lt> References: <7F780FA4-E826-4C83-98CC-549FECEDA35E@par.lt> To: =?utf-8?Q?Olivier_Cochard-Labb=C3=A9?= X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 09:57:45 -0000 If I start freeradius under high load, packets doesn't reach the = destination - on sender side I see packets passing out (with tcpdump), = on receiver side tcpdump "see" only part of these packets - some of them = are missing. > On 20 Mar 2015, at 11:49, Olivier Cochard-Labb=C3=A9 = wrote: >=20 > On Fri, Mar 20, 2015 at 10:23 AM, Vaidas Damo=C5=A1evi=C4=8Dius = > wrote: > Hello, >=20 > =E2=80=8BHi, > =E2=80=8B=20 >=20 > I have 2 boxes with FreeBSD 10.1-RELEASE/amd64 and "Intel(R) PRO/1000 = Network Connection 7.4.2" NIC's directly connected to each other. I = noticed strange problem - I'm loosing small UDP packets under high load. = I've tried to test it with iperf and got the following: >=20 > --- >=20 > vd@v0s4:~ % iperf3 -u -c 1.2.3.4 > Connecting to host 1.2.3.4, port 5201 > [ 4] local 1.2.3.3 port 64254 connected to 1.2.3.4 port 5201 > [ ID] Interval Transfer Bandwidth Total Datagrams > [ 4] 0.00-1.01 sec 120 KBytes 976 Kbits/sec 15 > [ 4] 1.01-2.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 2.01-3.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 3.01-4.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 4.01-5.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 5.01-6.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 6.01-7.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 7.01-8.00 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 8.00-9.01 sec 128 KBytes 1.05 Mbits/sec 16 > [ 4] 9.01-10.01 sec 128 KBytes 1.05 Mbits/sec 16 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth Jitter = Lost/Total Datagrams > [ 4] 0.00-10.01 sec 1.24 MBytes 1.04 Mbits/sec 0.325 ms 0/159 = (0%) > [ 4] Sent 159 datagrams >=20 >=20 >=20 > =E2=80=8BThe result display a Lost/Total ratio of 0/159: Where do you = see missing UDP packets ? > By default iperf send only 1 Mbit/sec in UDP mode: I didn't see any = problem on these stats. >=20 > Regards, >=20 > Olivier >=20 >=20 > =E2=80=8B=20 From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 13:31:17 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76E647BC for ; Fri, 20 Mar 2015 13:31:17 +0000 (UTC) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 38AB7CBD for ; Fri, 20 Mar 2015 13:31:16 +0000 (UTC) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 1D9F82700781; Fri, 20 Mar 2015 14:31:09 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id E9AF0270078F; Fri, 20 Mar 2015 14:31:08 +0100 (CET) Received: from work.netasq.com ([127.0.0.1]) by localhost (work.netasq.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IJxJocpSbMNw; Fri, 20 Mar 2015 14:31:08 +0100 (CET) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id AFDBC2700781; Fri, 20 Mar 2015 14:31:08 +0100 (CET) Date: Fri, 20 Mar 2015 14:31:07 +0100 (CET) From: Emeric POUPON To: Hans Petter Selasky Message-ID: <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> In-Reply-To: <550AC709.1050404@selasky.org> References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> <550AC709.1050404@selasky.org> Subject: Re: Fragment questions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thread-Topic: Fragment questions Thread-Index: OUhKPrNSVR/pF0IjNqFko5qpn37xjw== Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 13:31:17 -0000 Hello, Yes indeed, it has already been fixed! However, the second point seems to be still here... Regards, Emeric ----- Mail original ----- De: "Hans Petter Selasky" =C3=80: "Emeric POUPON" , "freebsd-net" Envoy=C3=A9: Jeudi 19 Mars 2015 13:54:33 Objet: Re: Fragment questions On 03/19/15 12:38, Emeric POUPON wrote: > Hello, > > I noticed two questionable things in the fragmentation code: > - in ip_fragment, we do not copy the flowid from the original mbuf to the= fragmented mbuf. Therefore we may output very desynchronized fragments (fi= rst fragment emitted far later the second fragment, etc.) > - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use rando= mized id. In multi core systems, we may emit successive packets with the sa= me id. > > Both problems combined lead to bad packet reassembly on the remote host. > > What do you think? > Hi, I think this issue is already fixed: https://svnweb.freebsd.org/base/head/sys/netinet/ip_output.c?revision=3D278= 103&view=3Dmarkup --HPS From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 14:00:08 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A80DBD98 for ; Fri, 20 Mar 2015 14:00:08 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66484F62 for ; Fri, 20 Mar 2015 14:00:08 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 514B61FE022; Fri, 20 Mar 2015 15:00:05 +0100 (CET) Message-ID: <550C2813.3030806@selasky.org> Date: Fri, 20 Mar 2015 15:00:51 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Emeric POUPON Subject: Re: Fragment questions References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> <550AC709.1050404@selasky.org> <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> In-Reply-To: <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 14:00:08 -0000 On 03/20/15 14:31, Emeric POUPON wrote: > Hello, > > Yes indeed, it has already been fixed! > However, the second point seems to be still here... > > Regards, > > Emeric > Can you suggest a patch for the second issue? --HPS From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 15:19:10 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33BE797E for ; Fri, 20 Mar 2015 15:19:10 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 006C2AA2 for ; Fri, 20 Mar 2015 15:19:09 +0000 (UTC) Received: by iedm5 with SMTP id m5so30863371ied.3 for ; Fri, 20 Mar 2015 08:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=mMJAoS90RHy/UA1gGRHXFSv/fn6jtMQoXO7cVmKVk5E=; b=uiqyWRjPz5G4jzgPgNvF69v6ApXWaSCn2hf4be+V5scvab3Bqcrq7IgpajqwPXuZ4U OidIfm3J/slhwdpNN3osOlLilUaK8rTec7An+EnTGueY+U+qqVfuBIinHPiOgadheVir 0bVl7G45BVn2PcWAXm7lCBDrG+lz1NFd14kVWrrJD1bDmUXuBw4Prx5cDmnH0Xc6iCGE N6qMuI0taDEg9inI97/ff65nJSgWHrHIeobad6qq0ilN2oL6ULbCrZjUU/yWmjipKyJx APPm0PO7jTY2AObiTrAMpAdLsRqoUhB0fOLHUQmMPb8vz9MOrSjW96dBb4w/iP2FegkB 3zBw== X-Received: by 10.107.32.73 with SMTP id g70mr109686681iog.55.1426864749243; Fri, 20 Mar 2015 08:19:09 -0700 (PDT) Received: from [10.10.1.5] ([192.252.130.194]) by mx.google.com with ESMTPSA id t1sm3593829igs.0.2015.03.20.08.19.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 08:19:08 -0700 (PDT) Message-ID: <550C3A62.3080403@gmail.com> Date: Fri, 20 Mar 2015 11:18:58 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-net Subject: Another fragment question / patch Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 15:19:10 -0000 Hi, While reading through a previous comment on this list about fragments I've noticed that mbuf tags aren't being copied from the leading fragment (header) to the subsequent fragment packets. In other words, one would expect that all fragments of a packet are carrying the same tags that were set on the original packet. I have built a simple test were I use ipfw with ALTQ and sent large packet (bigger then MTU) off that BSD machine. I have observed that the leading fragment (m0) packet is going through the right class although the next fragments are hitting the default class for unclassified packets. Here is a patch that makes things works as expected (all fragments carry the ALTQ tag): diff --git a/freebsd/sys/netinet/ip_output.c b/freebsd/sys/netinet/ip_output.c index d650949..7d8f041 100644 --- a/freebsd/sys/netinet/ip_output.c +++ b/freebsd/sys/netinet/ip_output.c @@ -1184,7 +1184,10 @@ smart_frag_failure: ipstat.ips_odropped++; goto done; } - m->m_flags |= (m0->m_flags & M_MCAST) | M_FRAG; + + m->m_flags |= (m0->m_flags & M_COPYFLAGS) | M_FRAG; + m_tag_copy_chain(m, m0, M_NOWAIT); + /* * In the first mbuf, leave room for the link header, then * copy the original IP header including options. The payload diff --git a/freebsd/sys/sys/mbuf.h b/freebsd/sys/sys/mbuf.h index 2efff38..6ad8439 100644 --- a/freebsd/sys/sys/mbuf.h I hope this helps, Karim. From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 17:56:18 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C3D8F87 for ; Fri, 20 Mar 2015 17:56:18 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D03D1F0D for ; Fri, 20 Mar 2015 17:56:17 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2BB331FE022; Fri, 20 Mar 2015 18:56:15 +0100 (CET) Message-ID: <550C5F6C.3080302@selasky.org> Date: Fri, 20 Mar 2015 18:57:00 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Karim Fodil-Lemelin , freebsd-net Subject: Re: Another fragment question / patch References: <550C3A62.3080403@gmail.com> In-Reply-To: <550C3A62.3080403@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 17:56:18 -0000 On 03/20/15 16:18, Karim Fodil-Lemelin wrote: > Hi, > > While reading through a previous comment on this list about fragments > I've noticed that mbuf tags aren't being copied from the leading > fragment (header) to the subsequent fragment packets. In other words, > one would expect that all fragments of a packet are carrying the same > tags that were set on the original packet. I have built a simple test > were I use ipfw with ALTQ and sent large packet (bigger then MTU) off > that BSD machine. I have observed that the leading fragment (m0) packet > is going through the right class although the next fragments are hitting > the default class for unclassified packets. > > Here is a patch that makes things works as expected (all fragments carry > the ALTQ tag): > > diff --git a/freebsd/sys/netinet/ip_output.c > b/freebsd/sys/netinet/ip_output.c > index d650949..7d8f041 100644 > --- a/freebsd/sys/netinet/ip_output.c > +++ b/freebsd/sys/netinet/ip_output.c > @@ -1184,7 +1184,10 @@ smart_frag_failure: > ipstat.ips_odropped++; > goto done; > } > - m->m_flags |= (m0->m_flags & M_MCAST) | M_FRAG; > + > + m->m_flags |= (m0->m_flags & M_COPYFLAGS) | M_FRAG; > + m_tag_copy_chain(m, m0, M_NOWAIT); > + > /* > * In the first mbuf, leave room for the link header, then > * copy the original IP header including options. The > payload > diff --git a/freebsd/sys/sys/mbuf.h b/freebsd/sys/sys/mbuf.h > index 2efff38..6ad8439 100644 > --- a/freebsd/sys/sys/mbuf.h > Hi, I see your point about copying the tags. I'm not sure however that M_COPYFLAGS is correct, because it also copies M_RDONLY, which is not relevant for this case. Can you explain what flags need copying in addition to M_MCAST ? Maybe we need to define these flags separately. Thank you! --HPS From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 17:57:46 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2A0FC0 for ; Fri, 20 Mar 2015 17:57:46 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8211BF2C for ; Fri, 20 Mar 2015 17:57:46 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A7E461FE022; Fri, 20 Mar 2015 18:57:44 +0100 (CET) Message-ID: <550C5FC6.6020401@selasky.org> Date: Fri, 20 Mar 2015 18:58:30 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Emeric POUPON Subject: Re: Fragment questions References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> <550AC709.1050404@selasky.org> <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> In-Reply-To: <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 17:57:46 -0000 On 03/20/15 14:31, Emeric POUPON wrote: > - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use randomized id. > In multi core systems, we may emit successive packets with the same id. Will using a mutex or an atomic macro fix this issue when incrementing the V_ip_id ? --HPS From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 18:02:03 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 469942ED for ; Fri, 20 Mar 2015 18:02:03 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AABBB for ; Fri, 20 Mar 2015 18:02:03 +0000 (UTC) Received: by ieclw3 with SMTP id lw3so98613065iec.2 for ; Fri, 20 Mar 2015 11:02:02 -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:message-id:subject :from:to:cc:content-type; bh=a7wpNn3FWAzTW/SjH5DiXHWCpu8sDlBOx/41ag+6XpY=; b=VJ06D1ujraNidug+kdmktpivmRiis90B7LoR45JsRPHVZPmWB33c7YIxu0XBWaXC29 CN9/q+OXyiSafdDrRQ9iKOomxzt5ToZOgsSei1lYUYQgUDBBUVBOkv8sOrMS7RCj7JiI ZedsOSwtOvqDqsctgHcKU3srzsYgUy/e6xURJgbc7HGqUjx4tIbkmJ/QNMA0RyHfC4Tk E6ica24zYjCQ22fqDxw6BO7DOmDrdB1NataK5jbirrG6hmabq5bdoTavSMbX0sGB/pAN 6PlwTQ0JQGmm0esN8dMzNt8pmofWrx6zcnJn1ZdPG/oV2QNJeDpIxjRBgEw0Fq8B966r lUpA== MIME-Version: 1.0 X-Received: by 10.50.67.100 with SMTP id m4mr7230763igt.32.1426874522333; Fri, 20 Mar 2015 11:02:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Fri, 20 Mar 2015 11:02:02 -0700 (PDT) In-Reply-To: <550C5FC6.6020401@selasky.org> References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> <550AC709.1050404@selasky.org> <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> <550C5FC6.6020401@selasky.org> Date: Fri, 20 Mar 2015 11:02:02 -0700 X-Google-Sender-Auth: eFK37e_GJZCtC4cM70pUHUtxJLo Message-ID: Subject: Re: Fragment questions From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Emeric POUPON , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 18:02:03 -0000 On 20 March 2015 at 10:58, Hans Petter Selasky wrote: > On 03/20/15 14:31, Emeric POUPON wrote: >> >> - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use >> randomized id. > >> In multi core systems, we may emit successive packets with the same id. > > Will using a mutex or an atomic macro fix this issue when incrementing the > V_ip_id ? It will, but it'll ping-pong between multiple cores and slow things down at high pps. -a From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 18:14:55 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7307499C for ; Fri, 20 Mar 2015 18:14:55 +0000 (UTC) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 33B4819A for ; Fri, 20 Mar 2015 18:14:54 +0000 (UTC) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-02v.sys.comcast.net with comcast id 5uEi1q00A2Fh1PH01uEse0; Fri, 20 Mar 2015 18:14:52 +0000 Received: from resmail-ch2-217v.sys.comcast.net ([162.150.48.251]) by resomta-ch2-08v.sys.comcast.net with comcast id 5uEs1q00d5RAVJS01uEsvf; Fri, 20 Mar 2015 18:14:53 +0000 Date: Fri, 20 Mar 2015 18:14:52 +0000 (UTC) From: rondzierwa@comcast.net To: freebsd-net@FreeBSD.org Message-ID: <1366749342.11996850.1426875292282.JavaMail.zimbra@comcast.net> In-Reply-To: <1247051661.11988589.1426874816055.JavaMail.zimbra@comcast.net> Subject: em resource allocation fails on SunFire X4500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_11996846_1496547758.1426875292278" X-Originating-IP: [::ffff:50.241.136.195] X-Mailer: Zimbra 8.0.7_GA_6031 (ZimbraWebClient - FF28 (Win)/8.0.7_GA_6031) Thread-Topic: em resource allocation fails on SunFire X4500 Thread-Index: X1mtW9onBvrMxrC7mG1XMlPaWuBt6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1426875292; bh=+slC+mm7ddy5bP8J0BXskQ5dfXmBctDsArjMro1kjgo=; h=Received:Received:Date:From:To:Message-ID:Subject:MIME-Version: Content-Type; b=Rp7CqMXT09KujdTotu0twmgF29uHkFenWAaBQrSeyEbRXzQaVMIVCO4ii3fVZ8WjU 1SemgnJ9JvhLDKVA2bwjStoRzLzSbUIEjoyaX5PfbFyPJ21kQEwEGldHg8P9JGX2gC rDOYRLNEwb9GQVOF3e53iKfFN2Xi2UbSJyObhp3C6CQT1jLagqR54e/0V+6ZYPwqMH 5yk7C9QbSCuNOSu79A3ryANeL2tzeZ17blAZf/XNBSLXZ9WEcRUI77f4wJwOnDAUFt rb+Vb4ghowPK6b+Fv2usVcgXidFT42X1PTmsCObt7ojD0mF9RWaAefk635VlcHtrIZ 8N+UYRwqDPy/A== X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 18:14:55 -0000 ------=_Part_11996846_1496547758.1426875292278 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I am using 10.1-RELEASE on a SunFire X4500 (thumper). It has 4 em devices, of which only the first two work due to a resource failure: em0: port 0xcc00-0xcc3f mem 0xfdae0000-0xfdafffff irq 52 at device 1.0 on pci7 em0: Ethernet address: 00:14:4f:21:09:94 em1: port 0xc800-0xc83f mem 0xfdac0000-0xfdadffff irq 53 at device 1.1 on pci7 em1: Ethernet address: 00:14:4f:21:09:95 em2: mem 0xfdbe0000-0xfdbfffff irq 61 at device 1.0 on pci8 em2: 0x40 bytes of rid 0x20 res 4 failed (0, 0xffffffffffffffff). em2: Unable to allocate bus resource: ioport em2: Allocation of PCI resources failed em2: mem 0xfdbc0000-0xfdbdffff irq 62 at device 1.1 on pci8 em2: 0x40 bytes of rid 0x20 res 4 failed (0, 0xffffffffffffffff). em2: Unable to allocate bus resource: ioport em2: Allocation of PCI resources failed a previous bug, #196501 was closed by setting 'hint.agp.0.disabled=1' in loader.conf, but this had no effect on the X4500. I have attached the pciconf output. Thanks in advance for any help or suggestions! ron. ------=_Part_11996846_1496547758.1426875292278 Content-Type: application/octet-stream; name=pciconf.out Content-Disposition: attachment; filename=pciconf.out Content-Transfer-Encoding: base64 cm9vdEB0aHVtcGVyMTp+ICMgcGNpY29uZiAtbGJjVg0KcGNpYjFAcGNpMDowOjE6MDogICAgICAg Y2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHg3NDU4MTAyMiByZXY9MHgxMiBo ZHI9MHgwMQ0KICAgIGNhcCAwN1s2MF0gPSBQQ0ktWCA2NC1iaXQgYnJpZGdlIHN1cHBvcnRzIDEz M01Ieg0KICAgIGNhcCAwOFtiOF0gPSBIVCBpbnRlcnJ1cHQNCiAgICBjYXAgMDhbYzBdID0gSFQg c2xhdmUNCiAgICBjYXAgMDhbZjRdID0gSFQgTVNJIGFkZHJlc3Mgd2luZG93IGRpc2FibGVkIGF0 IDB4ZmVlMDAwMDANCmlvYXBpYzBAcGNpMDowOjE6MTogICAgIGNsYXNzPTB4MDgwMDEwIGNhcmQ9 MHg3NDU5MTAyMiBjaGlwPTB4NzQ1OTEwMjIgcmV2PTB4MTIgaGRyPTB4MDANCiAgICBiYXIgICBb MTBdID0gdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmQyZmYwMDAsIHNpemUgNDA5Niwg ZW5hYmxlZA0KcGNpYjJAcGNpMDowOjI6MDogICAgICAgY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAw MDAwMDAwIGNoaXA9MHg3NDU4MTAyMiByZXY9MHgxMiBoZHI9MHgwMQ0KICAgIGNhcCAwN1s2MF0g PSBQQ0ktWCA2NC1iaXQgYnJpZGdlIHN1cHBvcnRzIDEzM01Ieg0KICAgIGNhcCAwOFtiOF0gPSBI VCBpbnRlcnJ1cHQNCiAgICBjYXAgMDhbYzBdID0gSFQgcmV2aXNpb24gSUQNCiAgICBjYXAgMDhb ZjRdID0gSFQgTVNJIGFkZHJlc3Mgd2luZG93IGRpc2FibGVkIGF0IDB4ZmVlMDAwMDANCmlvYXBp YzFAcGNpMDowOjI6MTogICAgIGNsYXNzPTB4MDgwMDEwIGNhcmQ9MHg3NDU5MTAyMiBjaGlwPTB4 NzQ1OTEwMjIgcmV2PTB4MTIgaGRyPTB4MDANCiAgICBiYXIgICBbMTBdID0gdHlwZSBNZW1vcnks IHJhbmdlIDY0LCBiYXNlIDB4ZmQyZmUwMDAsIHNpemUgNDA5NiwgZW5hYmxlZA0KcGNpYjNAcGNp MDowOjY6MDogICAgICAgY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHg3NDYw MTAyMiByZXY9MHgwNyBoZHI9MHgwMQ0KICAgIGNhcCAwOFtjMF0gPSBIVCBzbGF2ZQ0KICAgIGNh cCAwOFtmMF0gPSBIVCBpbnRlcnJ1cHQNCmlzYWIwQHBjaTA6MDo3OjA6ICAgICAgIGNsYXNzPTB4 MDYwMTAwIGNhcmQ9MHg3NDY4MTAyMiBjaGlwPTB4NzQ2ODEwMjIgcmV2PTB4MDUgaGRyPTB4MDAN CmF0YXBjaTBAcGNpMDowOjc6MTogICAgIGNsYXNzPTB4MDEwMThhIGNhcmQ9MHg3NDY5MTAyMiBj aGlwPTB4NzQ2OTEwMjIgcmV2PTB4MDMgaGRyPTB4MDANCiAgICBiYXIgICBbMjBdID0gdHlwZSBJ L08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhmZmEwLCBzaXplIDE2LCBlbmFibGVkDQpub25lMEBw Y2kwOjA6NzoyOiAgICAgICBjbGFzcz0weDBjMDUwMCBjYXJkPTB4NzQ2YTEwMjIgY2hpcD0weDc0 NmExMDIyIHJldj0weDAyIGhkcj0weDAwDQogICAgYmFyICAgWzEwXSA9IHR5cGUgSS9PIFBvcnQs IHJhbmdlIDMyLCBiYXNlIDB4MTkwMCwgc2l6ZSAzMiwgZW5hYmxlZA0Kbm9uZTFAcGNpMDowOjc6 MzogICAgICAgY2xhc3M9MHgwNjgwMDAgY2FyZD0weDc0NmIxMDIyIGNoaXA9MHg3NDZiMTAyMiBy ZXY9MHgwNSBoZHI9MHgwMA0KaG9zdGIwQHBjaTA6MDoyNDowOiAgICAgY2xhc3M9MHgwNjAwMDAg Y2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAwMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KICAgIGNh cCAwOFs4MF0gPSBIVCBob3N0DQogICAgY2FwIDA4W2EwXSA9IEhUIGhvc3QNCiAgICBjYXAgMDhb YzBdID0gSFQgaG9zdA0KaG9zdGIxQHBjaTA6MDoyNDoxOiAgICAgY2xhc3M9MHgwNjAwMDAgY2Fy ZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAxMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KaG9zdGIyQHBj aTA6MDoyNDoyOiAgICAgY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAy MTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KaG9zdGIzQHBjaTA6MDoyNDozOiAgICAgY2xhc3M9MHgw NjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAzMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0K aG9zdGI0QHBjaTA6MDoyNTowOiAgICAgY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNo aXA9MHgxMTAwMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KICAgIGNhcCAwOFs4MF0gPSBIVCBob3N0 DQogICAgY2FwIDA4W2EwXSA9IEhUIGhvc3QNCiAgICBjYXAgMDhbYzBdID0gSFQgaG9zdA0KaG9z dGI1QHBjaTA6MDoyNToxOiAgICAgY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9 MHgxMTAxMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KaG9zdGI2QHBjaTA6MDoyNToyOiAgICAgY2xh c3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAyMTAyMiByZXY9MHgwMCBoZHI9 MHgwMA0KaG9zdGI3QHBjaTA6MDoyNTozOiAgICAgY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAw MDAwIGNoaXA9MHgxMTAzMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KbXZzMEBwY2kwOjE6MTowOiAg ICAgICAgY2xhc3M9MHgwMTAwMDAgY2FyZD0weDExYWIxMWFiIGNoaXA9MHg2MDgxMTFhYiByZXY9 MHgwOSBoZHI9MHgwMA0KICAgIGJhciAgIFsxMF0gPSB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJh c2UgMHhmYWUwMDAwMCwgc2l6ZSAxMDQ4NTc2LCBlbmFibGVkDQogICAgYmFyICAgWzE4XSA9IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4N2MwMCwgc2l6ZSAyNTYsIGVuYWJsZWQNCiAg ICBjYXAgMDFbNDBdID0gcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwDQog ICAgY2FwIDA1WzUwXSA9IE1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdA0KICAgIGNhcCAw N1s2MF0gPSBQQ0ktWCA2NC1iaXQgc3VwcG9ydHMgMTMzTUh6LCA1MTIgYnVyc3QgcmVhZCwgNCBz cGxpdCB0cmFuc2FjdGlvbnMNCm12czFAcGNpMDoyOjE6MDogICAgICAgIGNsYXNzPTB4MDEwMDAw IGNhcmQ9MHgxMWFiMTFhYiBjaGlwPTB4NjA4MTExYWIgcmV2PTB4MDkgaGRyPTB4MDANCiAgICBi YXIgICBbMTBdID0gdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmIwMDAwMDAsIHNpemUg MTA0ODU3NiwgZW5hYmxlZA0KICAgIGJhciAgIFsxOF0gPSB0eXBlIEkvTyBQb3J0LCByYW5nZSAz MiwgYmFzZSAweDhjMDAsIHNpemUgMjU2LCBlbmFibGVkDQogICAgY2FwIDAxWzQwXSA9IHBvd2Vy c3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KICAgIGNhcCAwNVs1MF0gPSBNU0kg c3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQNCiAgICBjYXAgMDdbNjBdID0gUENJLVggNjQtYml0 IHN1cHBvcnRzIDEzM01IeiwgNTEyIGJ1cnN0IHJlYWQsIDQgc3BsaXQgdHJhbnNhY3Rpb25zDQpv aGNpMEBwY2kwOjM6MDowOiAgICAgICBjbGFzcz0weDBjMDMxMCBjYXJkPTB4NzQ2NDEwMjIgY2hp cD0weDc0NjQxMDIyIHJldj0weDBiIGhkcj0weDAwDQogICAgYmFyICAgWzEwXSA9IHR5cGUgTWVt b3J5LCByYW5nZSAzMiwgYmFzZSAweGZkMWZlMDAwLCBzaXplIDQwOTYsIGVuYWJsZWQNCm9oY2kx QHBjaTA6MzowOjE6ICAgICAgIGNsYXNzPTB4MGMwMzEwIGNhcmQ9MHg3NDY0MTAyMiBjaGlwPTB4 NzQ2NDEwMjIgcmV2PTB4MGIgaGRyPTB4MDANCiAgICBiYXIgICBbMTBdID0gdHlwZSBNZW1vcnks IHJhbmdlIDMyLCBiYXNlIDB4ZmQxZmQwMDAsIHNpemUgNDA5NiwgZW5hYmxlZA0KdmdhcGNpMEBw Y2kwOjM6MzowOiAgICAgY2xhc3M9MHgwMzAwMDAgY2FyZD0weDQ1MzExMDhlIGNoaXA9MHg0NzUy MTAwMiByZXY9MHgyNyBoZHI9MHgwMA0KICAgIGJhciAgIFsxMF0gPSB0eXBlIE1lbW9yeSwgcmFu Z2UgMzIsIGJhc2UgMHhmYzAwMDAwMCwgc2l6ZSAxNjc3NzIxNiwgZW5hYmxlZA0KICAgIGJhciAg IFsxNF0gPSB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDk4MDAsIHNpemUgMjU2LCBl bmFibGVkDQogICAgYmFyICAgWzE4XSA9IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZk MWZmMDAwLCBzaXplIDQwOTYsIGVuYWJsZWQNCiAgICBjYXAgMDFbNWNdID0gcG93ZXJzcGVjIDIg IHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwDQpvaGNpMkBwY2kwOjM6NDowOiAgICAg ICBjbGFzcz0weDBjMDMxMCBjYXJkPTB4MDAzNTEwMzMgY2hpcD0weDAwMzUxMDMzIHJldj0weDQz IGhkcj0weDAwDQogICAgYmFyICAgWzEwXSA9IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAw eGZkMWZjMDAwLCBzaXplIDQwOTYsIGVuYWJsZWQNCiAgICBjYXAgMDFbNDBdID0gcG93ZXJzcGVj IDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwDQpvaGNpM0BwY2kwOjM6NDoxOiAg ICAgICBjbGFzcz0weDBjMDMxMCBjYXJkPTB4MDAzNTEwMzMgY2hpcD0weDAwMzUxMDMzIHJldj0w eDQzIGhkcj0weDAwDQogICAgYmFyICAgWzEwXSA9IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFz ZSAweGZkMWZiMDAwLCBzaXplIDQwOTYsIGVuYWJsZWQNCiAgICBjYXAgMDFbNDBdID0gcG93ZXJz cGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwDQplaGNpMEBwY2kwOjM6NDoy OiAgICAgICBjbGFzcz0weDBjMDMyMCBjYXJkPTB4MDBlMDEwMzMgY2hpcD0weDAwZTAxMDMzIHJl dj0weDA0IGhkcj0weDAwDQogICAgYmFyICAgWzEwXSA9IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwg YmFzZSAweGZkMWZhYzAwLCBzaXplIDI1NiwgZW5hYmxlZA0KICAgIGNhcCAwMVs0MF0gPSBwb3dl cnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDANCnBjaWI1QHBjaTA6NDoz OjA6ICAgICAgIGNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4NzQ1ODEwMjIg cmV2PTB4MTIgaGRyPTB4MDENCiAgICBjYXAgMDdbNjBdID0gUENJLVggNjQtYml0IGJyaWRnZSBz dXBwb3J0cyAxMzNNSHoNCiAgICBjYXAgMDhbYjhdID0gSFQgaW50ZXJydXB0DQogICAgY2FwIDA4 W2MwXSA9IEhUIHNsYXZlDQogICAgY2FwIDA4W2Y0XSA9IEhUIE1TSSBhZGRyZXNzIHdpbmRvdyBk aXNhYmxlZCBhdCAweGZlZTAwMDAwDQppb2FwaWMyQHBjaTA6NDozOjE6ICAgICBjbGFzcz0weDA4 MDAxMCBjYXJkPTB4NzQ1OTEwMjIgY2hpcD0weDc0NTkxMDIyIHJldj0weDEyIGhkcj0weDAwDQog ICAgYmFyICAgWzEwXSA9IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGZkY2ZmMDAwLCBz aXplIDQwOTYsIGVuYWJsZWQNCnBjaWI2QHBjaTA6NDo0OjA6ICAgICAgIGNsYXNzPTB4MDYwNDAw IGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4NzQ1ODEwMjIgcmV2PTB4MTIgaGRyPTB4MDENCiAgICBj YXAgMDdbNjBdID0gUENJLVggNjQtYml0IGJyaWRnZSBzdXBwb3J0cyAxMzNNSHoNCiAgICBjYXAg MDhbYjhdID0gSFQgaW50ZXJydXB0DQogICAgY2FwIDA4W2MwXSA9IEhUIHJldmlzaW9uIElEDQog ICAgY2FwIDA4W2Y0XSA9IEhUIE1TSSBhZGRyZXNzIHdpbmRvdyBkaXNhYmxlZCBhdCAweGZlZTAw MDAwDQppb2FwaWMzQHBjaTA6NDo0OjE6ICAgICBjbGFzcz0weDA4MDAxMCBjYXJkPTB4NzQ1OTEw MjIgY2hpcD0weDc0NTkxMDIyIHJldj0weDEyIGhkcj0weDAwDQogICAgYmFyICAgWzEwXSA9IHR5 cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGZkY2ZlMDAwLCBzaXplIDQwOTYsIGVuYWJsZWQN CnBjaWI3QHBjaTA6NDo1OjA6ICAgICAgIGNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMDAwMCBj aGlwPTB4NzQ1ODEwMjIgcmV2PTB4MTIgaGRyPTB4MDENCiAgICBjYXAgMDdbNjBdID0gUENJLVgg NjQtYml0IGJyaWRnZSBzdXBwb3J0cyAxMzNNSHoNCiAgICBjYXAgMDhbYjhdID0gSFQgaW50ZXJy dXB0DQogICAgY2FwIDA4W2MwXSA9IEhUIHNsYXZlDQogICAgY2FwIDA4W2Y0XSA9IEhUIE1TSSBh ZGRyZXNzIHdpbmRvdyBkaXNhYmxlZCBhdCAweGZlZTAwMDAwDQppb2FwaWM0QHBjaTA6NDo1OjE6 ICAgICBjbGFzcz0weDA4MDAxMCBjYXJkPTB4NzQ1OTEwMjIgY2hpcD0weDc0NTkxMDIyIHJldj0w eDEyIGhkcj0weDAwDQogICAgYmFyICAgWzEwXSA9IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFz ZSAweGZkY2ZkMDAwLCBzaXplIDQwOTYsIGVuYWJsZWQNCnBjaWI4QHBjaTA6NDo2OjA6ICAgICAg IGNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4NzQ1ODEwMjIgcmV2PTB4MTIg aGRyPTB4MDENCiAgICBjYXAgMDdbNjBdID0gUENJLVggNjQtYml0IGJyaWRnZSBzdXBwb3J0cyAx MzNNSHoNCiAgICBjYXAgMDhbYjhdID0gSFQgaW50ZXJydXB0DQogICAgY2FwIDA4W2MwXSA9IEhU IHJldmlzaW9uIElEDQogICAgY2FwIDA4W2Y0XSA9IEhUIE1TSSBhZGRyZXNzIHdpbmRvdyBkaXNh YmxlZCBhdCAweGZlZTAwMDAwDQppb2FwaWM1QHBjaTA6NDo2OjE6ICAgICBjbGFzcz0weDA4MDAx MCBjYXJkPTB4NzQ1OTEwMjIgY2hpcD0weDc0NTkxMDIyIHJldj0weDEyIGhkcj0weDAwDQogICAg YmFyICAgWzEwXSA9IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGZkY2ZjMDAwLCBzaXpl IDQwOTYsIGVuYWJsZWQNCm12czJAcGNpMDo1OjE6MDogICAgICAgIGNsYXNzPTB4MDEwMDAwIGNh cmQ9MHgxMWFiMTFhYiBjaGlwPTB4NjA4MTExYWIgcmV2PTB4MDkgaGRyPTB4MDANCiAgICBiYXIg ICBbMTBdID0gdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmQ3MDAwMDAsIHNpemUgMTA0 ODU3NiwgZW5hYmxlZA0KICAgIGJhciAgIFsxOF0gPSB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwg YmFzZSAweGFjMDAsIHNpemUgMjU2LCBlbmFibGVkDQogICAgY2FwIDAxWzQwXSA9IHBvd2Vyc3Bl YyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KICAgIGNhcCAwNVs1MF0gPSBNU0kgc3Vw cG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQNCiAgICBjYXAgMDdbNjBdID0gUENJLVggNjQtYml0IHN1 cHBvcnRzIDEzM01IeiwgNTEyIGJ1cnN0IHJlYWQsIDQgc3BsaXQgdHJhbnNhY3Rpb25zDQptdnMz QHBjaTA6NjoxOjA6ICAgICAgICBjbGFzcz0weDAxMDAwMCBjYXJkPTB4MTFhYjExYWIgY2hpcD0w eDYwODExMWFiIHJldj0weDA5IGhkcj0weDAwDQogICAgYmFyICAgWzEwXSA9IHR5cGUgTWVtb3J5 LCByYW5nZSA2NCwgYmFzZSAweGZkOTAwMDAwLCBzaXplIDEwNDg1NzYsIGVuYWJsZWQNCiAgICBi YXIgICBbMThdID0gdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhiYzAwLCBzaXplIDI1 NiwgZW5hYmxlZA0KICAgIGNhcCAwMVs0MF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMg IGN1cnJlbnQgRDANCiAgICBjYXAgMDVbNTBdID0gTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQg Yml0DQogICAgY2FwIDA3WzYwXSA9IFBDSS1YIDY0LWJpdCBzdXBwb3J0cyAxMzNNSHosIDUxMiBi dXJzdCByZWFkLCA0IHNwbGl0IHRyYW5zYWN0aW9ucw0KZW0wQHBjaTA6NzoxOjA6IGNsYXNzPTB4 MDIwMDAwIGNhcmQ9MHgxMDExODA4NiBjaGlwPTB4MTAxMDgwODYgcmV2PTB4MDMgaGRyPTB4MDAN CiAgICBiYXIgICBbMTBdID0gdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmRhZTAwMDAs IHNpemUgMTMxMDcyLCBlbmFibGVkDQogICAgYmFyICAgWzIwXSA9IHR5cGUgSS9PIFBvcnQsIHJh bmdlIDMyLCBiYXNlIDB4Y2MwMCwgc2l6ZSA2NCwgZW5hYmxlZA0KICAgIGNhcCAwMVtkY10gPSBw b3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMDdbZTRdID0g UENJLVggNjQtYml0IHN1cHBvcnRzIDEzM01IeiwgMjA0OCBidXJzdCByZWFkLCAxIHNwbGl0IHRy YW5zYWN0aW9uDQogICAgY2FwIDA1W2YwXSA9IE1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJp dA0KZW0xQHBjaTA6NzoxOjE6IGNsYXNzPTB4MDIwMDAwIGNhcmQ9MHgxMDExODA4NiBjaGlwPTB4 MTAxMDgwODYgcmV2PTB4MDMgaGRyPTB4MDANCiAgICBiYXIgICBbMTBdID0gdHlwZSBNZW1vcnks IHJhbmdlIDY0LCBiYXNlIDB4ZmRhYzAwMDAsIHNpemUgMTMxMDcyLCBlbmFibGVkDQogICAgYmFy ICAgWzIwXSA9IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4YzgwMCwgc2l6ZSA2NCwg ZW5hYmxlZA0KICAgIGNhcCAwMVtkY10gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDANCiAgICBjYXAgMDdbZTRdID0gUENJLVggNjQtYml0IHN1cHBvcnRzIDEzM01Ieiwg MjA0OCBidXJzdCByZWFkLCAxIHNwbGl0IHRyYW5zYWN0aW9uDQogICAgY2FwIDA1W2YwXSA9IE1T SSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdA0Kbm9uZTJAcGNpMDo4OjE6MDogICAgICAgY2xh c3M9MHgwMjAwMDAgY2FyZD0weDEwMTE4MDg2IGNoaXA9MHgxMDEwODA4NiByZXY9MHgwMyBoZHI9 MHgwMA0KICAgIGJhciAgIFsxMF0gPSB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmZGJl MDAwMCwgc2l6ZSAxMzEwNzIsIGVuYWJsZWQNCiAgICBiYXIgICBbMjBdID0gdHlwZSBJL08gUG9y dCwgcmFuZ2UgMzIsIGJhc2UgMHhkYzAwLCBzaXplIDY0LCBkaXNhYmxlZA0KICAgIGNhcCAwMVtk Y10gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMDdb ZTRdID0gUENJLVggNjQtYml0IHN1cHBvcnRzIDEzM01IeiwgMjA0OCBidXJzdCByZWFkLCAxIHNw bGl0IHRyYW5zYWN0aW9uDQogICAgY2FwIDA1W2YwXSA9IE1TSSBzdXBwb3J0cyAxIG1lc3NhZ2Us IDY0IGJpdA0Kbm9uZTNAcGNpMDo4OjE6MTogICAgICAgY2xhc3M9MHgwMjAwMDAgY2FyZD0weDEw MTE4MDg2IGNoaXA9MHgxMDEwODA4NiByZXY9MHgwMyBoZHI9MHgwMA0KICAgIGJhciAgIFsxMF0g PSB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmZGJjMDAwMCwgc2l6ZSAxMzEwNzIsIGVu YWJsZWQNCiAgICBiYXIgICBbMjBdID0gdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhk ODAwLCBzaXplIDY0LCBkaXNhYmxlZA0KICAgIGNhcCAwMVtkY10gPSBwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMDdbZTRdID0gUENJLVggNjQtYml0IHN1 cHBvcnRzIDEzM01IeiwgMjA0OCBidXJzdCByZWFkLCAxIHNwbGl0IHRyYW5zYWN0aW9uDQogICAg Y2FwIDA1W2YwXSA9IE1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdA0KcGNpYjEwQHBjaTA6 MTI6OTowOiAgICAgY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHg3NDU4MTAy MiByZXY9MHgxMiBoZHI9MHgwMQ0KICAgIGNhcCAwN1s2MF0gPSBQQ0ktWCA2NC1iaXQgYnJpZGdl IHN1cHBvcnRzIDEzM01Ieg0KICAgIGNhcCAwOFtiOF0gPSBIVCBpbnRlcnJ1cHQNCiAgICBjYXAg MDhbYzBdID0gSFQgc2xhdmUNCiAgICBjYXAgMDhbZjRdID0gSFQgTVNJIGFkZHJlc3Mgd2luZG93 IGRpc2FibGVkIGF0IDB4ZmVlMDAwMDANCmlvYXBpYzZAcGNpMDoxMjo5OjE6ICAgIGNsYXNzPTB4 MDgwMDEwIGNhcmQ9MHg3NDU5MTAyMiBjaGlwPTB4NzQ1OTEwMjIgcmV2PTB4MTIgaGRyPTB4MDAN CiAgICBiYXIgICBbMTBdID0gdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmVhZmYwMDAs IHNpemUgNDA5NiwgZW5hYmxlZA0KcGNpYjExQHBjaTA6MTI6MTA6MDogICAgY2xhc3M9MHgwNjA0 MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHg3NDU4MTAyMiByZXY9MHgxMiBoZHI9MHgwMQ0KICAg IGNhcCAwN1s2MF0gPSBQQ0ktWCA2NC1iaXQgYnJpZGdlIHN1cHBvcnRzIDEzM01Ieg0KICAgIGNh cCAwOFtiOF0gPSBIVCBpbnRlcnJ1cHQNCiAgICBjYXAgMDhbYzBdID0gSFQgcmV2aXNpb24gSUQN CiAgICBjYXAgMDhbZjRdID0gSFQgTVNJIGFkZHJlc3Mgd2luZG93IGRpc2FibGVkIGF0IDB4ZmVl MDAwMDANCmlvYXBpYzdAcGNpMDoxMjoxMDoxOiAgIGNsYXNzPTB4MDgwMDEwIGNhcmQ9MHg3NDU5 MTAyMiBjaGlwPTB4NzQ1OTEwMjIgcmV2PTB4MTIgaGRyPTB4MDANCiAgICBiYXIgICBbMTBdID0g dHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmVhZmUwMDAsIHNpemUgNDA5NiwgZW5hYmxl ZA0KcGNpYjEzQHBjaTA6OTo3OjA6ICAgICAgY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDAw IGNoaXA9MHg3NDU4MTAyMiByZXY9MHgxMiBoZHI9MHgwMQ0KICAgIGNhcCAwN1s2MF0gPSBQQ0kt WCA2NC1iaXQgYnJpZGdlIHN1cHBvcnRzIDEzM01Ieg0KICAgIGNhcCAwOFtiOF0gPSBIVCBpbnRl cnJ1cHQNCiAgICBjYXAgMDhbYzBdID0gSFQgc2xhdmUNCiAgICBjYXAgMDhbZjRdID0gSFQgTVNJ IGFkZHJlc3Mgd2luZG93IGRpc2FibGVkIGF0IDB4ZmVlMDAwMDANCmlvYXBpYzhAcGNpMDo5Ojc6 MTogICAgIGNsYXNzPTB4MDgwMDEwIGNhcmQ9MHg3NDU5MTAyMiBjaGlwPTB4NzQ1OTEwMjIgcmV2 PTB4MTIgaGRyPTB4MDANCiAgICBiYXIgICBbMTBdID0gdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBi YXNlIDB4ZmU2ZmYwMDAsIHNpemUgNDA5NiwgZW5hYmxlZA0KcGNpYjE0QHBjaTA6OTo4OjA6ICAg ICAgY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHg3NDU4MTAyMiByZXY9MHgx MiBoZHI9MHgwMQ0KICAgIGNhcCAwN1s2MF0gPSBQQ0ktWCA2NC1iaXQgYnJpZGdlIHN1cHBvcnRz IDEzM01Ieg0KICAgIGNhcCAwOFtiOF0gPSBIVCBpbnRlcnJ1cHQNCiAgICBjYXAgMDhbYzBdID0g SFQgcmV2aXNpb24gSUQNCiAgICBjYXAgMDhbZjRdID0gSFQgTVNJIGFkZHJlc3Mgd2luZG93IGRp c2FibGVkIGF0IDB4ZmVlMDAwMDANCmlvYXBpYzlAcGNpMDo5Ojg6MTogICAgIGNsYXNzPTB4MDgw MDEwIGNhcmQ9MHg3NDU5MTAyMiBjaGlwPTB4NzQ1OTEwMjIgcmV2PTB4MTIgaGRyPTB4MDANCiAg ICBiYXIgICBbMTBdID0gdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmU2ZmUwMDAsIHNp emUgNDA5NiwgZW5hYmxlZA0KbXZzNEBwY2kwOjEwOjE6MDogICAgICAgY2xhc3M9MHgwMTAwMDAg Y2FyZD0weDExYWIxMWFiIGNoaXA9MHg2MDgxMTFhYiByZXY9MHgwOSBoZHI9MHgwMA0KICAgIGJh ciAgIFsxMF0gPSB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmZTMwMDAwMCwgc2l6ZSAx MDQ4NTc2LCBlbmFibGVkDQogICAgYmFyICAgWzE4XSA9IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMy LCBiYXNlIDB4ZWMwMCwgc2l6ZSAyNTYsIGVuYWJsZWQNCiAgICBjYXAgMDFbNDBdID0gcG93ZXJz cGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwDQogICAgY2FwIDA1WzUwXSA9IE1TSSBz dXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdA0KICAgIGNhcCAwN1s2MF0gPSBQQ0ktWCA2NC1iaXQg c3VwcG9ydHMgMTMzTUh6LCA1MTIgYnVyc3QgcmVhZCwgNCBzcGxpdCB0cmFuc2FjdGlvbnMNCm12 czVAcGNpMDoxMToxOjA6ICAgICAgIGNsYXNzPTB4MDEwMDAwIGNhcmQ9MHgxMWFiMTFhYiBjaGlw PTB4NjA4MTExYWIgcmV2PTB4MDkgaGRyPTB4MDANCiAgICBiYXIgICBbMTBdID0gdHlwZSBNZW1v cnksIHJhbmdlIDY0LCBiYXNlIDB4ZmU1MDAwMDAsIHNpemUgMTA0ODU3NiwgZW5hYmxlZA0KICAg IGJhciAgIFsxOF0gPSB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGZjMDAsIHNpemUg MjU2LCBkaXNhYmxlZA0KICAgIGNhcCAwMVs0MF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMDVbNTBdID0gTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwg NjQgYml0DQogICAgY2FwIDA3WzYwXSA9IFBDSS1YIDY0LWJpdCBzdXBwb3J0cyAxMzNNSHosIDUx MiBidXJzdCByZWFkLCA0IHNwbGl0IHRyYW5zYWN0aW9ucw0Kcm9vdEB0aHVtcGVyMTp+ICMNCg== ------=_Part_11996846_1496547758.1426875292278-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 18:55:53 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB4673E2; Fri, 20 Mar 2015 18:55:53 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9992905; Fri, 20 Mar 2015 18:55:53 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 439851FE022; Fri, 20 Mar 2015 19:55:51 +0100 (CET) Message-ID: <550C6D65.6070409@selasky.org> Date: Fri, 20 Mar 2015 19:56:37 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Fragment questions References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> <550AC709.1050404@selasky.org> <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> <550C5FC6.6020401@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Emeric POUPON , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 18:55:54 -0000 On 03/20/15 19:02, Adrian Chadd wrote: > On 20 March 2015 at 10:58, Hans Petter Selasky wrote: >> On 03/20/15 14:31, Emeric POUPON wrote: >>> >>> - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use >>> randomized id. >> >>> In multi core systems, we may emit successive packets with the same id. >> >> Will using a mutex or an atomic macro fix this issue when incrementing the >> V_ip_id ? > > It will, but it'll ping-pong between multiple cores and slow things > down at high pps. > Hi, Maybe we can have the V_ip_id per CPU and use the lower 8-bits as random CPU core number? OK? --HPS From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 19:04:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69F88A40 for ; Fri, 20 Mar 2015 19:04:45 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C1ADAC0 for ; Fri, 20 Mar 2015 19:04:45 +0000 (UTC) Received: by iedm5 with SMTP id m5so36131978ied.3 for ; Fri, 20 Mar 2015 12:04:44 -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:message-id:subject :from:to:cc:content-type; bh=AavXpiOmSzlsyI18zMJdwrg5ttPOj8ExNEAOUKbXFvQ=; b=T/AIJeNbLm0sYC/zBwjyXLYk+axyadrAeYjWkiO7O323eRGwkbdWsOTbnTa1U3Iyuo inYl//aZKQRqpIHb79tkEjRNTsyzwqSpCwR4xwx5R+B8hI8B151IpdMjjU0p4QF+foF2 LB+7papQAM4EbajHXhKVtvqm/p5pqAQ3F4tZgdtH1G22l2nvIzrYlOn3Wu3Zps0XC0i/ hvXWyFTA0RuGBFE7H103Bv08kA9OXldHHvC+H/Ui+BzNnP2POSdPwGwlU4djjGiNNGhK SB30CRU8dmhYfuNMJpvxggs8pzXbEAeiTqssd9utcBk2bQ2GtorZJ76OELaH+rePZkkk 6gDw== MIME-Version: 1.0 X-Received: by 10.42.41.200 with SMTP id q8mr2858993ice.61.1426878284557; Fri, 20 Mar 2015 12:04:44 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Fri, 20 Mar 2015 12:04:44 -0700 (PDT) In-Reply-To: <550C6D65.6070409@selasky.org> References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> <550AC709.1050404@selasky.org> <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> <550C5FC6.6020401@selasky.org> <550C6D65.6070409@selasky.org> Date: Fri, 20 Mar 2015 12:04:44 -0700 X-Google-Sender-Auth: No50U30fYbexct0B-fkY5zDXscQ Message-ID: Subject: Re: Fragment questions From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Emeric POUPON , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 19:04:45 -0000 On 20 March 2015 at 11:56, Hans Petter Selasky wrote: > On 03/20/15 19:02, Adrian Chadd wrote: >> >> On 20 March 2015 at 10:58, Hans Petter Selasky wrote: >>> >>> On 03/20/15 14:31, Emeric POUPON wrote: >>>> >>>> >>>> - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use >>>> randomized id. >>> >>> >>>> In multi core systems, we may emit successive packets with the same id. >>> >>> >>> Will using a mutex or an atomic macro fix this issue when incrementing >>> the >>> V_ip_id ? >> >> >> It will, but it'll ping-pong between multiple cores and slow things >> down at high pps. >> > > Hi, > > Maybe we can have the V_ip_id per CPU and use the lower 8-bits as random CPU > core number? Hm, someone with more cycles to spend on analysing the repercussions from this should investigate it. I think in the short term using an atomic is fine, as it's no worse than what is currently there. But as we get more PPS unlocked and happening we may need to fix it. -adrian From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 20:03:36 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38A27135 for ; Fri, 20 Mar 2015 20:03:36 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EEBA3251 for ; Fri, 20 Mar 2015 20:03:35 +0000 (UTC) Received: by igcqo1 with SMTP id qo1so904945igc.0 for ; Fri, 20 Mar 2015 13:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=n7DxMTTpVjSINKYOrw+CZJuSlL7N3ErOJ6r/kYH219E=; b=m/AKirbWNcpZktdcnzKLQ+gFyFIcs5QBKIcAusRYtiehCSiXoce6d8WzjSZiPCuhg4 /273XJTr8zcsyhwIKm1knGwo/jib5QPQfkMbOO5Q8rMYfuVzwszJrB1Cz7duimLgIYBF TMFsxPuPCsustxC0UJUTbAH5uUvN8ppdq/jZr/OLGvo/81CRk47MgILxmexgMvTxePkw d8mRM4t2bdttbILYAXqW9VCmDJ52BUPnmAB/rUptQ31vJsYikf3qJyiH5saq5/ea++B7 pBjuwTbYCZMm0wfA8EnHHc/oqR241ic7dQ/CgrSoNA+odMTAYKiFtpMy7YyWUVDpOnFh ZnZg== X-Received: by 10.107.10.157 with SMTP id 29mr126152949iok.79.1426881815446; Fri, 20 Mar 2015 13:03:35 -0700 (PDT) Received: from [10.10.1.5] ([192.252.130.194]) by mx.google.com with ESMTPSA id l64sm3811669iod.19.2015.03.20.13.03.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 13:03:34 -0700 (PDT) Message-ID: <550C7D0C.3090603@gmail.com> Date: Fri, 20 Mar 2015 16:03:24 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Another fragment question / patch References: <550C3A62.3080403@gmail.com> <550C5F6C.3080302@selasky.org> In-Reply-To: <550C5F6C.3080302@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 20:03:36 -0000 On 2015-03-20 1:57 PM, Hans Petter Selasky wrote: > On 03/20/15 16:18, Karim Fodil-Lemelin wrote: >> Hi, >> >> While reading through a previous comment on this list about fragments >> I've noticed that mbuf tags aren't being copied from the leading >> fragment (header) to the subsequent fragment packets. In other words, >> one would expect that all fragments of a packet are carrying the same >> tags that were set on the original packet. I have built a simple test >> were I use ipfw with ALTQ and sent large packet (bigger then MTU) off >> that BSD machine. I have observed that the leading fragment (m0) packet >> is going through the right class although the next fragments are hitting >> the default class for unclassified packets. >> >> Here is a patch that makes things works as expected (all fragments carry >> the ALTQ tag): >> >> diff --git a/freebsd/sys/netinet/ip_output.c >> b/freebsd/sys/netinet/ip_output.c >> index d650949..7d8f041 100644 >> --- a/freebsd/sys/netinet/ip_output.c >> +++ b/freebsd/sys/netinet/ip_output.c >> @@ -1184,7 +1184,10 @@ smart_frag_failure: >> ipstat.ips_odropped++; >> goto done; >> } >> - m->m_flags |= (m0->m_flags & M_MCAST) | M_FRAG; >> + >> + m->m_flags |= (m0->m_flags & M_COPYFLAGS) | M_FRAG; >> + m_tag_copy_chain(m, m0, M_NOWAIT); >> + >> /* >> * In the first mbuf, leave room for the link >> header, then >> * copy the original IP header including options. The >> payload >> diff --git a/freebsd/sys/sys/mbuf.h b/freebsd/sys/sys/mbuf.h >> index 2efff38..6ad8439 100644 >> --- a/freebsd/sys/sys/mbuf.h >> > > Hi, > > I see your point about copying the tags. I'm not sure however that > M_COPYFLAGS is correct, because it also copies M_RDONLY, which is not > relevant for this case. Can you explain what flags need copying in > addition to M_MCAST ? Maybe we need to define these flags separately. > > Thank you! > > --HPS Hi, Arguably the M_RDONLY is added when m_copy() is called a bit later in that function. m_copym() does a shallow copy (through a call to mb_dupcl) and will set the RDONLY flag when doing so. So the fact it was copied over from M_COPYFLAGS shouldn't be a problem in terms of functionality. A similar logic applies to the M_VLANTAG since it should never be set in ip_output() (severe layer violation). I guess M_COPYFLAGS is kinda safe but not necessarily correct. In terms of appropriate behavior (whats the real purpose of M_COPYFLAGS?) my initial patch is debatable and to answer your question I would consider to copy the remaining flags: M_PKTHDR => already in there through the m_gethdr() call M_BCAST => no need to copy M_MCAST => already in there in ip_fragment() M_PROTOFLAGS M_SKIP_FIREWALL => for layer 2 fire-walling? So something like? - m->m_flags |= (m0->m_flags & M_MCAST); + m->m_flags |= (m0->m_flags & (M_MCAST | M_PROTOFLAGS)); + m_tag_copy_chain(m, m0, M_NOWAIT); Cheers! Karim. From owner-freebsd-net@FreeBSD.ORG Fri Mar 20 22:51:07 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95BE64E8 for ; Fri, 20 Mar 2015 22:51:07 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FF2E97B for ; Fri, 20 Mar 2015 22:51:06 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 16E9F16A404; Fri, 20 Mar 2015 23:50:58 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWIPdrTiwE0y; Fri, 20 Mar 2015 23:50:31 +0100 (CET) Received: from [192.168.10.211] (unknown [192.168.10.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 8782B16A402; Fri, 20 Mar 2015 23:50:31 +0100 (CET) Message-ID: <550CA439.7040500@digiware.nl> Date: Fri, 20 Mar 2015 23:50:33 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?VmFpZGFzIERhbW/FoWV2acSNaXVz?= , Mehmet Erol Sanliturk Subject: Re: Troubles with 'em' driver and UDP packets References: <7F780FA4-E826-4C83-98CC-549FECEDA35E@par.lt> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 22:51:07 -0000 On 20/03/2015 10:42, Vaidas Damoševičius wrote: > It's not cabling problem :) > > Another example with -b and -i : > > vd@v0s4:~ % iperf3 -u -c 1.2.3.4 -i4 -b1000m -P1 > Connecting to host 1.2.3.4, port 5201 > [ 4] local 1.2.3.3 port 10672 connected to 1.2.3.4 port 5201 > [ ID] Interval Transfer Bandwidth Total Datagrams > [ 4] 0.00-4.00 sec 446 MBytes 935 Mbits/sec 1761605 > [ 4] 4.00-8.00 sec 457 MBytes 958 Mbits/sec 1809551 > [ 4] 8.00-10.00 sec 228 MBytes 958 Mbits/sec 900740 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams > [ 4] 0.00-10.00 sec 1.10 GBytes 949 Mbits/sec 770.668 ms 0/35 (0%) > [ 4] Sent 35 datagrams > > Result is totaly different. > >> On 20 Mar 2015, at 11:29, Mehmet Erol Sanliturk wrote: >> I think you use Gigabit CROSS cable ( cat 5e or cat 6 ) . >> CROSS cable is required if connection is from computer to computer . >> >> Only for remaindering . to the best of my knowledge: The standard for 1Gbit requires the media interface to do crossover automagically, thus removing the requirement for X-cables. And that also holds for computer <> computer connections. --WjW From owner-freebsd-net@FreeBSD.ORG Sat Mar 21 02:28:20 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1C09D92 for ; Sat, 21 Mar 2015 02:28:20 +0000 (UTC) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.f5.com", Issuer "Entrust Certification Authority - L1C" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C84308C for ; Sat, 21 Mar 2015 02:28:20 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.11,440,1422921600"; d="scan'208";a="154381104" X-IPAS-Result: A2CnBACf1QxV/+sKqMBchDaDCsNKhiKBWgEBAQEBAX2EGyMRVwEiAiYCBDAVEQEEG7oJmkIBH4EhkWSBRQWuZYQQgjN/AQEB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 21 Mar 2015 02:27:11 +0000 Received: from SEAEXCHMBX03.olympus.F5Net.com (192.168.15.225) by SEAEXCHMBX07.olympus.F5Net.com (192.168.15.50) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 20 Mar 2015 19:27:11 -0700 Received: from SEAEXCHMBX03.olympus.F5Net.com ([fe80::f95f:ea5d:773b:29b8]) by seaexchmbx03.olympus.F5Net.com ([fe80::f95f:ea5d:773b:29b8%13]) with mapi id 15.00.1044.021; Fri, 20 Mar 2015 19:27:11 -0700 From: Clive Philbrick To: "freebsd-net@freebsd.org" Subject: Netmap and the host stack Thread-Topic: Netmap and the host stack Thread-Index: AdBjew9dt/5fF9xbRd+zTO+vhKG3vg== Date: Sat, 21 Mar 2015 02:27:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Mar 2015 02:28:21 -0000 SSdtIGNvbmZ1c2VkIGJ5IHRoZSBkb2N1bWVudGF0aW9uIEkndmUgZm91bmQgb24gaG9zdCBzdGFj ayBhY2Nlc3MgdXNpbmcgbmV0bWFwLiANClRoZSBkb2N1bWVudGF0aW9uIHNheXM6DQoiUGFja2V0 cyBnZW5lcmF0ZWQgYnkgdGhlIGhvc3Qgc3RhY2sgYXJlIGV4dHJhY3RlZCBmcm9tIHRoZSBtYnVm cyBhbmQgc3RvcmVkIGluIHRoZSBzbG90cyBvZiBhbiBpbnB1dCByaW5nLCBzaW1pbGFyIHRvIHRo b3NlIHVzZWQgZm9yIHRyYWZmaWMgY29taW5nIGZyb20gdGhlIG5ldHdvcmsuIFBhY2tldHMgZGVz dGluZWQgdG8gdGhlIGhvc3Qgc3RhY2sgYXJlIHF1ZXVlZCBieSB0aGUgbmV0bWFwIGNsaWVudCBp bnRvIGFuICBvdXRwdXQgbmV0bWFwIHJpbmcsIGFuZCBmcm9tIHRoZXJlIGVuY2Fwc3VsYXRlZCBp bnRvIG1idWZzIGFuZCBwYXNzZWQgdG8gdGhlIGhvc3Qgc3RhY2sgYXMgaWYgdGhleSB3ZXJlIGNv bWluZyBmcm9tIHRoZSBjb3JyZXNwb25kaW5nIG5ldG1hcC1lbmFibGVkIE5JQy4iDQoNCkRvZXMg dGhpcyByZWZlciBvbmx5IHRvIHBhY2tldHMgZ2VuZXJhdGVkIGludGVybmFsbHkgYnkgdGhlIGhv c3Qgc3RhY2ssIG9yIGNhbiB0aGV5IGJlIHRyaWdnZXJlZCBieSB1c2VyLWxldmVsIGNvZGU/IA0K U3VwcG9zZSBJIHB1dCBhbiBpbnRlcmZhY2UgaW50byBuZXRtYXAgbW9kZSAoZWcgZXRoMSkgd2l0 aCB0aGUgTklPQ1JFR0lGIGZsYWdzIGluZGljYXRpbmcgTkVUTUFQX1NXX1JJTkcuIElzIHRoZXJl IGFueSB3YXkgdG8gdGhlbiBvcGVuIGEgc29ja2V0LCBiaW5kIGl0IHRvIHRoZSBJUCBhZGRyZXNz IG9mIHRoYXQgaW50ZXJmYWNlIGFuZCB0aGVuIHRyeSB0byBpc3N1ZSBhIGNvbm5lY3QgdmlhIHRo YXQgaW50ZXJmYWNlPyBEbyBJIGluc3RlYWQgaGF2ZSB0byBjcmFmdCB0aGUgZW50aXJlIGNvbm5l Y3QgcGFja2V0IChpZSBhIFRDUCBTWU4pIGFuZCBzZW5kIGl0IHZpYSBhIE5ldG1hcCByaW5nPyAN Cg0K From owner-freebsd-net@FreeBSD.ORG Sat Mar 21 04:13:10 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4AE23E8 for ; Sat, 21 Mar 2015 04:13:10 +0000 (UTC) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 771DFD8D for ; Sat, 21 Mar 2015 04:13:10 +0000 (UTC) Received: by yhpt93 with SMTP id t93so48250169yhp.0 for ; Fri, 20 Mar 2015 21:13:09 -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=6QU00ikuUeutKgZ13mve4NLZ8qd0EJKTTq+99cP7Lk0=; b=YmINJcwW7ChO7gcAAeuNZEehufaDPt8JOWN+ENJkRtZ+EcHAJUSgRTA17GwfHSn9DG ceJYzgzsNvDMq5OL+VIZzkDS5D+Vv4KASmpzKpUWw/5lDSIU4t+G32Osmkdy1THl9Beo BdBeAS0oGs2eHEVb7XTnvPOgG8QbqlZf4maxyowWhx3xhvAiCKZ3nnZdTkuT7qh02mkv /XM4+TYjPjx50zUaEyDuqjDj4oQRCHh0R7K1p0KZqOzb5Ae2FfdQcQff3kzeJ7MDi9f+ xl9T9c8iNe+pPAnQ4SWs07DvKVrmkZPICunYGq8F1PkJJNAqlge9wPDWrDke1PyQncuQ taZw== MIME-Version: 1.0 X-Received: by 10.170.90.70 with SMTP id h67mr96339802yka.46.1426911189364; Fri, 20 Mar 2015 21:13:09 -0700 (PDT) Received: by 10.170.60.69 with HTTP; Fri, 20 Mar 2015 21:13:09 -0700 (PDT) In-Reply-To: <550CA439.7040500@digiware.nl> References: <7F780FA4-E826-4C83-98CC-549FECEDA35E@par.lt> <550CA439.7040500@digiware.nl> Date: Fri, 20 Mar 2015 21:13:09 -0700 Message-ID: Subject: Re: Troubles with 'em' driver and UDP packets From: Mehmet Erol Sanliturk To: Willem Jan Withagen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org, =?UTF-8?B?VmFpZGFzIERhbW/FoWV2acSNaXVz?= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Mar 2015 04:13:10 -0000 On Fri, Mar 20, 2015 at 3:50 PM, Willem Jan Withagen wrote: > On 20/03/2015 10:42, Vaidas Damo=C5=A1evi=C4=8Dius wrote: > > It's not cabling problem :) > > > > Another example with -b and -i : > > > > vd@v0s4:~ % iperf3 -u -c 1.2.3.4 -i4 -b1000m -P1 > > Connecting to host 1.2.3.4, port 5201 > > [ 4] local 1.2.3.3 port 10672 connected to 1.2.3.4 port 5201 > > [ ID] Interval Transfer Bandwidth Total Datagrams > > [ 4] 0.00-4.00 sec 446 MBytes 935 Mbits/sec 1761605 > > [ 4] 4.00-8.00 sec 457 MBytes 958 Mbits/sec 1809551 > > [ 4] 8.00-10.00 sec 228 MBytes 958 Mbits/sec 900740 > > - - - - - - - - - - - - - - - - - - - - - - - - - > > [ ID] Interval Transfer Bandwidth Jitter > Lost/Total Datagrams > > [ 4] 0.00-10.00 sec 1.10 GBytes 949 Mbits/sec 770.668 ms 0/35 > (0%) > > [ 4] Sent 35 datagrams > > > > Result is totaly different. > > > > >> On 20 Mar 2015, at 11:29, Mehmet Erol Sanliturk < > m.e.sanliturk@gmail.com> wrote: > >> I think you use Gigabit CROSS cable ( cat 5e or cat 6 ) . > >> CROSS cable is required if connection is from computer to computer . > >> > >> Only for remaindering . > > to the best of my knowledge: > The standard for 1Gbit requires the media interface to do crossover > automagically, thus removing the requirement for X-cables. > And that also holds for computer <> computer connections. > > --WjW > > > You are right . In case of failures this point may be checked whether it is affecting the communication or not . http://en.wikipedia.org/wiki/Crossover_cable http://en.wikipedia.org/wiki/Ethernet_crossover_cable http://en.wikipedia.org/wiki/Medium_Dependent_Interface#Auto_MDI-X In some computer related shops , they are sold separately as cables and cable connectors . If there were not any need , no one would produce , sell , and buy such two different products . From owner-freebsd-net@FreeBSD.ORG Sat Mar 21 09:13:52 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5350B246 for ; Sat, 21 Mar 2015 09:13:52 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA316CBF for ; Sat, 21 Mar 2015 09:13:51 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A19F11FE022; Sat, 21 Mar 2015 10:13:42 +0100 (CET) Message-ID: <550D3675.5030900@selasky.org> Date: Sat, 21 Mar 2015 10:14:29 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Karim Fodil-Lemelin , freebsd-net@freebsd.org Subject: Re: Another fragment question / patch References: <550C3A62.3080403@gmail.com> <550C5F6C.3080302@selasky.org> <550C7D0C.3090603@gmail.com> In-Reply-To: <550C7D0C.3090603@gmail.com> Content-Type: multipart/mixed; boundary="------------030400090601090601060304" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Mar 2015 09:13:52 -0000 This is a multi-part message in MIME format. --------------030400090601090601060304 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 03/20/15 21:03, Karim Fodil-Lemelin wrote: > On 2015-03-20 1:57 PM, Hans Petter Selasky wrote: >> On 03/20/15 16:18, Karim Fodil-Lemelin wrote: >>> Hi, >>> >>> While reading through a previous comment on this list about fragments >>> I've noticed that mbuf tags aren't being copied from the leading >>> fragment (header) to the subsequent fragment packets. In other words, >>> one would expect that all fragments of a packet are carrying the same >>> tags that were set on the original packet. I have built a simple test >>> were I use ipfw with ALTQ and sent large packet (bigger then MTU) off >>> that BSD machine. I have observed that the leading fragment (m0) packet >>> is going through the right class although the next fragments are hitting >>> the default class for unclassified packets. >>> >>> Here is a patch that makes things works as expected (all fragments carry >>> the ALTQ tag): >>> >>> diff --git a/freebsd/sys/netinet/ip_output.c >>> b/freebsd/sys/netinet/ip_output.c >>> index d650949..7d8f041 100644 >>> --- a/freebsd/sys/netinet/ip_output.c >>> +++ b/freebsd/sys/netinet/ip_output.c >>> @@ -1184,7 +1184,10 @@ smart_frag_failure: >>> ipstat.ips_odropped++; >>> goto done; >>> } >>> - m->m_flags |= (m0->m_flags & M_MCAST) | M_FRAG; >>> + >>> + m->m_flags |= (m0->m_flags & M_COPYFLAGS) | M_FRAG; >>> + m_tag_copy_chain(m, m0, M_NOWAIT); >>> + >>> /* >>> * In the first mbuf, leave room for the link >>> header, then >>> * copy the original IP header including options. The >>> payload >>> diff --git a/freebsd/sys/sys/mbuf.h b/freebsd/sys/sys/mbuf.h >>> index 2efff38..6ad8439 100644 >>> --- a/freebsd/sys/sys/mbuf.h >>> >> >> Hi, >> >> I see your point about copying the tags. I'm not sure however that >> M_COPYFLAGS is correct, because it also copies M_RDONLY, which is not >> relevant for this case. Can you explain what flags need copying in >> addition to M_MCAST ? Maybe we need to define these flags separately. >> >> Thank you! >> >> --HPS > Hi, > > Arguably the M_RDONLY is added when m_copy() is called a bit later in > that function. m_copym() does a shallow copy (through a call to > mb_dupcl) and will set the RDONLY flag when doing so. So the fact it was > copied over from M_COPYFLAGS shouldn't be a problem in terms of > functionality. A similar logic applies to the M_VLANTAG since it should > never be set in ip_output() (severe layer violation). I guess > M_COPYFLAGS is kinda safe but not necessarily correct. > > In terms of appropriate behavior (whats the real purpose of > M_COPYFLAGS?) my initial patch is debatable and to answer your question > I would consider to copy the remaining flags: > > M_PKTHDR => already in there through the m_gethdr() call > M_BCAST => no need to copy > M_MCAST => already in there in ip_fragment() > M_PROTOFLAGS > M_SKIP_FIREWALL => for layer 2 fire-walling? > > So something like? > > - m->m_flags |= (m0->m_flags & M_MCAST); > + m->m_flags |= (m0->m_flags & (M_MCAST | M_PROTOFLAGS)); > + m_tag_copy_chain(m, m0, M_NOWAIT); > Hi, Could you have a look at the attached patch, test and give some comments? I believe the right thing to do in this case is to use the copy packet header function. --HPS --------------030400090601090601060304 Content-Type: text/x-diff; name="ip_output.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ip_output.c.diff" Index: ip_output.c =================================================================== --- ip_output.c (revision 279890) +++ ip_output.c (working copy) @@ -787,11 +787,13 @@ IPSTAT_INC(ips_odropped); goto done; } - /* make sure the flowid is the same for the fragmented mbufs */ - M_HASHTYPE_SET(m, M_HASHTYPE_GET(m0)); - m->m_pkthdr.flowid = m0->m_pkthdr.flowid; - /* copy multicast flag, if any */ - m->m_flags |= (m0->m_flags & M_MCAST); + /* make sure the packet header gets copied */ + if (m_dup_pkthdr(m, m0, M_NOWAIT) == 0) { + m_free(m); + error = ENOBUFS; + IPSTAT_INC(ips_odropped); + goto done; + } /* * In the first mbuf, leave room for the link header, then * copy the original IP header including options. The payload @@ -821,11 +823,9 @@ goto done; } m->m_pkthdr.len = mhlen + len; - m->m_pkthdr.rcvif = NULL; #ifdef MAC mac_netinet_fragment(m0, m); #endif - m->m_pkthdr.csum_flags = m0->m_pkthdr.csum_flags; mhip->ip_off = htons(mhip->ip_off); mhip->ip_sum = 0; if (m->m_pkthdr.csum_flags & CSUM_IP & ~if_hwassist_flags) { --------------030400090601090601060304--