From owner-freebsd-net@FreeBSD.ORG Sun Jun 23 06:22:19 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C4E6579F; Sun, 23 Jun 2013 06:22:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9E83810C6; Sun, 23 Jun 2013 06:22:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5N6MJdM017103; Sun, 23 Jun 2013 06:22:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5N6MJUr017102; Sun, 23 Jun 2013 06:22:19 GMT (envelope-from linimon) Date: Sun, 23 Jun 2013 06:22:19 GMT Message-Id: <201306230622.r5N6MJUr017102@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/179824: [ixgbe] System (9.1-p4) hangs on heavy ixgbe network traffic with hw.ixgbe.num_queues=6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 06:22:19 -0000 Old Synopsis: System (9.1-p4) hangs on heavy ixgbe network traffic with hw.ixgbe.num_queues=6 New Synopsis: [ixgbe] System (9.1-p4) hangs on heavy ixgbe network traffic with hw.ixgbe.num_queues=6 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jun 23 06:22:04 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=179824 From owner-freebsd-net@FreeBSD.ORG Mon Jun 24 03:59:25 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 42F7A282; Mon, 24 Jun 2013 03:59:25 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0BA1BED; Mon, 24 Jun 2013 03:59:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5O3xOUN012450; Mon, 24 Jun 2013 03:59:24 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5O3xO0g012449; Mon, 24 Jun 2013 03:59:24 GMT (envelope-from linimon) Date: Mon, 24 Jun 2013 03:59:24 GMT Message-Id: <201306240359.r5O3xO0g012449@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 03:59:25 -0000 Old Synopsis: [patch] Multicast SO_REUSEADDR handled incorrectly New Synopsis: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 24 03:59:05 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=179901 From owner-freebsd-net@FreeBSD.ORG Mon Jun 24 04:05:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 33B433B2 for ; Mon, 24 Jun 2013 04:05:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id E621C1C24 for ; Mon, 24 Jun 2013 04:05:54 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-226-51.lns20.per1.internode.on.net [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r5O45f9A042740 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 23 Jun 2013 21:05:44 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51C7C590.1070308@freebsd.org> Date: Mon, 24 Jun 2013 12:05:36 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Olivier_Cochard-Labb=E9?= Subject: Re: netstat -i not accurate on -stable ? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 04:05:55 -0000 On 6/22/13 4:28 PM, Olivier Cochard-Labbé wrote: > Hi all, > > I was testing my pthread-netblbast (PR bin/179085) when I found a > problem with netstat counters (tested on 9-stable r252056). > > netreceive (src/toots/tools/netrate) display this output: > 542025 pps 43.362 Mbps - 271554 pkts in 0.500998393 ns > 541562 pps 43.325 Mbps - 271323 pkts in 0.501000754 ns > 541517 pps 43.321 Mbps - 271300 pkts in 0.500999700 ns > 540487 pps 43.239 Mbps - 270784 pkts in 0.500999904 ns > 541541 pps 43.323 Mbps - 271312 pkts in 0.500999621 ns > 540624 pps 43.250 Mbps - 270853 pkts in 0.501000361 ns > 541403 pps 43.312 Mbps - 271243 pkts in 0.500999669 ns > 541079 pps 43.286 Mbps - 271081 pkts in 0.501000212 ns > 540887 pps 43.271 Mbps - 270985 pkts in 0.501000258 ns > 541796 pps 43.344 Mbps - 271440 pkts in 0.500999971 ns > 541056 pps 43.284 Mbps - 271069 pkts in 0.500999719 ns > 541224 pps 43.298 Mbps - 271155 pkts in 0.501002856 ns > 541120 pps 43.290 Mbps - 271100 pkts in 0.500997659 ns > > But in the same time a "netstat -ihw 1" display this output: > input (Total) output > packets errs idrops bytes packets errs bytes colls > 521k 508k 0 30M 3 0 562 0 > 521k 511k 0 30M 3 0 514 0 > 521k 526k 0 30M 3 0 514 0 > 521k 538k 0 30M 4 0 616 0 > 521k 495k 0 30M 3 0 514 0 > 521k 502k 0 30M 3 0 514 0 > 521k 531k 0 30M 3 0 514 0 > 521k 502k 0 30M 3 0 514 0 > 521k 504k 0 30M 3 0 514 0 > 521k 495k 0 30M 3 0 514 0 > 521k 498k 0 30M 3 0 514 0 > 521k 516k 0 30M 3 0 514 0 > > There are about 20Kpps difference between them. check if you get 60 of each in a 1 minute period. it's possible that due to overhead one of them is going to only get 55 iterations per second producing a difference... > > Regards, > > Olivier > _______________________________________________ > 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 Jun 24 09:12:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 099B86CF; Mon, 24 Jun 2013 09:12:59 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id B256B17EE; Mon, 24 Jun 2013 09:12:58 +0000 (UTC) Received: by mail-ve0-f182.google.com with SMTP id ox1so8335028veb.41 for ; Mon, 24 Jun 2013 02:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=AiK16C68oeVpngdb82c73oIXgjkGmnx7obp/DJtC+Z8=; b=sp6o0RRmTcsmHbbeTlble4Whnj9de9HR3rd2bkVwAX30+8zHtcUwVqNAwaPyzhg+yp Svq311uP8pZ1iYiz24kGXg3HGg7ZsZYTwn7Nf4KpFi8JgQShqWvEbB5rLzkxkwavfl3x VdJZ6gLi6qmxeAbRaj1wUjA1o25SdJoAhEIySo35Pz1EhCrp56+QVstS3xEz9rY0/KHc l3X7eP+S49sFqdbrfP81ljquKIU3z5Lh+evTh569inu7+eO15w7cPGBt82OnqFt7cI5V HUfx0biJawDQ5ouGcWVlI1oexIt0ZBWbjT4UQJghumu7piUwMgnnNSvmgRzw7j4HxxFK kYtw== X-Received: by 10.52.121.7 with SMTP id lg7mr9197571vdb.68.1372065178318; Mon, 24 Jun 2013 02:12:58 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.189.132 with HTTP; Mon, 24 Jun 2013 02:12:38 -0700 (PDT) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Mon, 24 Jun 2013 11:12:38 +0200 X-Google-Sender-Auth: 934fmCcPv4G3foDkmn2rYhoxAjo Message-ID: Subject: How correctly use netmap pkt-gen "sweep n addresses" option ? To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 09:12:59 -0000 Hi, I'm using netmap pkt-gen as a packet generator/receiver and it's working great for generating one-flow (one src/dst IP address). But I would like generate packets with multiples source&destination IP addresses. pkt-gen support "range" IP and MAC address: -d dst-ip end with %n to sweep n addresses -s src-ip end with %n to sweep n addresses -D dst-mac end with %n to sweep n addresses -S src-mac end with %n to sweep n addresses I've did a try with command like this: pkt-gen -i igb2 -d 2.3.1.1-2.250.250.250 -f tx -l 42 -D 00:1b:21:d3:8f:3e -s 1.2.1.1-1.250.250.250 It seems accepted and the output of pkt-gen is: ... extract_ip_range [136] extract IP range from 1.2.1.1-1.250.250.250 extract_ip_range [171] range is 1.2.1.1 0 to 1.250.250.250 0 extract_ip_range [136] extract IP range from 2.3.1.1-2.250.250.250 extract_ip_range [171] range is 2.3.1.1 0 to 2.250.250.250 0 ... But all packet generated only use the first IP (src 1.2.1.1 and dst 2.3.1.1 from my example): There is no use of IP range given in parameters. How to correctly use this pkt-gen feature (I'm using 9.1-STABLE r252056) ? Thanks, Olivier From owner-freebsd-net@FreeBSD.ORG Mon Jun 24 09:58:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A229B266; Mon, 24 Jun 2013 09:58:01 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id F0D4F19EE; Mon, 24 Jun 2013 09:58:00 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id ea20so9815989lab.22 for ; Mon, 24 Jun 2013 02:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0knbJguPmfHD/6FlB3EJSk2AFvFzpB6YFLDJgZUalXo=; b=Kc8kmmsJGSOEWvX+D0km5bRer2TAbcZNRuYOIAL8kr3BmbSXW9eXL3PdIgMAUF8lql EQqsSVwfY1Ebkog/w1Tj0lYsHxuxJXMTgfn+kaquoz7E6Y6Z24TB9NzU9yliO2keD2yx sx/m30zQ6IAKwKT1HEuLCmtIF/R1GPoYKc0Vsys7cOZxZLSHU9hpHiOD6U5G/7wwDqrm zRM6mQ+rA4QToPQOVI/bSqabJYm+eQ3rl908rrWApjPwIQGrasLDF/v5eCcYQbTJ7HwR nsAnUybvvvUJ1802PH7BiQm7/RDsXoQc2FnQbaHex74vliWHhYXGVu9v2/uVfVWpSbSQ kLPQ== MIME-Version: 1.0 X-Received: by 10.152.28.199 with SMTP id d7mr11014145lah.67.1372067879945; Mon, 24 Jun 2013 02:57:59 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.15 with HTTP; Mon, 24 Jun 2013 02:57:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Jun 2013 11:57:59 +0200 X-Google-Sender-Auth: Swf6H6cj1IbFXWK8Zo0f6HO86EY Message-ID: Subject: Re: How correctly use netmap pkt-gen "sweep n addresses" option ? From: Luigi Rizzo To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 09:58:01 -0000 On Mon, Jun 24, 2013 at 11:12 AM, Olivier Cochard-Labb=E9 wrote: > Hi, > > I'm using netmap pkt-gen as a packet generator/receiver and it's > working great for generating one-flow (one src/dst IP address). > But I would like generate packets with multiples source&destination IP > addresses. > pkt-gen support "range" IP and MAC address: > -d dst-ip end with %n to sweep n addresses > -s src-ip end with %n to sweep n addresses > -D dst-mac end with %n to sweep n addresses > -S src-mac end with %n to sweep n addresses > > I've did a try with command like this: > pkt-gen -i igb2 -d 2.3.1.1-2.250.250.250 -f tx -l 42 -D > 00:1b:21:d3:8f:3e -s 1.2.1.1-1.250.250.250 > It seems accepted and the output of pkt-gen is: > ... > extract_ip_range [136] extract IP range from 1.2.1.1-1.250.250.250 > extract_ip_range [171] range is 1.2.1.1 0 to 1.250.250.250 0 > extract_ip_range [136] extract IP range from 2.3.1.1-2.250.250.250 > extract_ip_range [171] range is 2.3.1.1 0 to 2.250.250.250 0 > ... > > But all packet generated only use the first IP (src 1.2.1.1 and dst > 2.3.1.1 from my example): There is no use of IP range given in > parameters. > How to correctly use this pkt-gen feature (I'm using 9.1-STABLE r252056)= ? > > sorry, it was never completely implemented, you need to add some code to play with it. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Jun 24 11:06:50 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 47326150 for ; Mon, 24 Jun 2013 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 375871DD0 for ; Mon, 24 Jun 2013 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5OB6oLH001060 for ; Mon, 24 Jun 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5OB6n6P001058 for freebsd-net@FreeBSD.org; Mon, 24 Jun 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Jun 2013 11:06:49 GMT Message-Id: <201306241106.r5OB6n6P001058@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 11:06:50 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/179901 net [netinet] [patch] Multicast SO_REUSEADDR handled incor o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178116 net [ipfilter] [panic] Kernel panic: general protection fa o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] [ipfilter] drops UDP packets with zero checksu o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipfilter] ipfilter/nat NULL pointer deference p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipfilter] There is no ippool start script/ipfilter ma o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [ipfilter] [rc.d] [patch] No good way to set ipfilter o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipfilter] FreeBSD 6.1+VPN+ipnat+ipf: port mapping doe o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipfilter] [panic] Kernel Panic Trap No 12 Page Fault o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipfilter] [patch] ipfilter drops OOW packets under 6. o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipfilter] [patch] wrong behaviour with skip rule insi o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipfilter] [panic] using ipfilter "auth" keyword leads o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipfilter] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipfilter] [patch] ipfilter ioctl SIOCGNATL does not m o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipfilter] ipfilter ipnat problem with h323 proxy supp o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipfilter] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipfilter] [ppp] Interactive use of user PPP and ipfil f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 468 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 24 12:02:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C2ED4BC4 for ; Mon, 24 Jun 2013 12:02:28 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 16DDF126B for ; Mon, 24 Jun 2013 12:02:27 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id r7so4197789bkg.17 for ; Mon, 24 Jun 2013 05:02:27 -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 :content-type; bh=KqXTOgBfw+5KpNLdIrJHM5FLObDMRRJp7/Vs3MDSIk0=; b=Kk7q8Bcj7f6XT08nqzEq4a9QkJQ30qiF/lA6OahGlI+DYchs80bOT5eQt8eFxZMQTa gFtKBmr4ziIlfhxKm39VheMgB/F0By12Z+L58+sXGxBkxMJXLq6uuewR9k6SgqDY4TgT YATb/WjazIuGHCztpqah8j/HTXFykIKW7qwsKaV2PDvNwG74PcGk+T38epcW0ARwtuGU NS7QMLaNBDpXE0CVjN1hW2+X1DQOdxB462iv5pVp+bfxEb4Y8Dcqb6f6yhwZxZ1SB4YU bFP7K1Ax42JsVIyZHJ2MOnfF7f3/LtFlZhQt1BX5DyQfutnjBKSYlL7ObuW4E3M49KDg LWlw== MIME-Version: 1.0 X-Received: by 10.204.171.2 with SMTP id f2mr3647264bkz.170.1372075347054; Mon, 24 Jun 2013 05:02:27 -0700 (PDT) Received: by 10.205.114.6 with HTTP; Mon, 24 Jun 2013 05:02:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Jun 2013 15:02:26 +0300 Message-ID: Subject: Fwd: LACP: active aggregator selection bug From: Boris Astardzhiev To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=bcaec52c65ffaad33704dfe52f01 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 12:02:28 -0000 --bcaec52c65ffaad33704dfe52f01 Content-Type: text/plain; charset=ISO-8859-1 Hi, I've been investigating the LACP implementation in FreeBSD and have encountered a bug. Here's the set: " --------- ---------- " " | lagg1 | | bond0 | " " --------- | xl0--------eth0 | --------- " " | hosts |----b1----1 FBSD rl0--------eth1 Linux|---| hosts | " " --------- | 9.1 rl1--------eth2 | --------- " " | | | | " " --------- ---------- " On a FreeBSD 9.1-RELEASE #0 r243826 system a lagg is created and three interfaces are added to it: - xl0 - rl0 - rl1 On a Linux system a bonding interface is added *ONLY ONE* interface: - eth0 Note: I think the Linux may be substituted with any other LACP implementation. The lagg protocol on both of the systems is LACP. LACPDUs transmission/reception takes place only between xl0 and eth0. Here's the result: root@freebsd91:/root # ifconfig lagg1 lagg1: flags=8843 metric 0 mtu 1500 options=2008 ether 00:10:b5:7f:97:fb inet6 fe80::210:b5ff:fe7f:97fb%lagg1 prefixlen 64 scopeid 0x9 nd6 options=21 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: xl0 flags=18 laggport: rl1 flags=1c laggport: rl0 flags=1c I consider that xl0 is the only available link therefor the aggregation must rely on it. However the lacp implementation has chosen the other two links that haven't received a single LACPDU. I think the problem is related to the selection of best active aggregator - in lacp_select_active_aggregator(). I've attached the debug output of sysctl net.lacp_debug. ... snippet ... Jun 24 10:41:43 freebsd91 kernel: xl0: new pstate 3f Jun 24 10:41:43 freebsd91 kernel: rl0: lacp_sm_mux: state 4 Jun 24 10:41:43 freebsd91 kernel: rl1: lacp_sm_mux: state 4 Jun 24 10:41:43 freebsd91 kernel: xl0: lacp_sm_mux: state 3 Jun 24 10:41:43 freebsd91 kernel: xl0: enable distributing on aggregator [(8000,00-10-B5-7F-97-FB,0126,0000,0000),(FFFF,E0-8F-EC-00-B5-2F,0009,0000,0000)], nports 0 -> 1 Jun 24 10:41:43 freebsd91 kernel: lacp_select_active_aggregator Jun 24 10:41:43 freebsd91 kernel: [(8000,00-10-B5-7F-97-FB,0126,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)], speed=200000000, nports=2 Jun 24 10:41:43 freebsd91 kernel: [(8000,00-10-B5-7F-97-FB,0126,0000,0000),(FFFF,E0-8F-EC-00-B5-2F,0009,0000,0000)], speed=100000000, nports=1 Jun 24 10:41:43 freebsd91 kernel: active aggregator not changed Jun 24 10:41:43 freebsd91 kernel: new [(8000,00-10-B5-7F-97-FB,0126,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)] Jun 24 10:41:43 freebsd91 kernel: xl0: mux_state 3 -> 4 Jun 24 10:41:43 freebsd91 kernel: xl0: lacpdu transmit ... snippet ... Though there is an aggregator with an active partner the implementation has chosen the other aggregator: Jun 24 10:41:43 freebsd91 kernel: new [(8000,00-10-B5-7F-97-FB,0126,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)] Do you think that such aggregators must be skipped in favour of aggregators with active partners? I've applied a patch that fixes this issue and xl0 remains the only active link but I'm not sure it is correct and it has the correct approach. I've posted a PR - http://www.freebsd.org/cgi/query-pr.cgi?pr=179926 Any comments are appreciated. Greetings, Boris Astardzhiev, Smartcom Bulgaria AD --bcaec52c65ffaad33704dfe52f01 Content-Type: application/octet-stream; name=lacp_debug-pr Content-Disposition: attachment; filename=lacp_debug-pr Content-Transfer-Encoding: base64 X-Attachment-Id: f_hibl8qyf0 SnVuIDI0IDEwOjQxOjM1IGZyZWVic2Q5MSBrZXJuZWw6IGxhZ2cxOiBsaW5rIHN0YXRlIGNoYW5n ZWQgdG8gVVAKSnVuIDI0IDEwOjQxOjM1IGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbGluayBzdGF0 ZSBjaGFuZ2VkIHRvIERPV04KSnVuIDI0IDEwOjQxOjM1IGZyZWVic2Q5MSBrZXJuZWw6IHhsMDog bWVkaWEgY2hhbmdlZCAweDAgLT4gMHgyMiwgZXRoZXIgPSAxLCBmZHggPSAwLCBsaW5rID0gMApK dW4gMjQgMTA6NDE6MzUgZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBsYWNwX3NtX3J4X3JlY29yZF9k ZWZhdWx0Ckp1biAyNCAxMDo0MTozNSBmcmVlYnNkOTEga2VybmVsOiB4bDA6IHBhcnRuZXIgdGlt ZW91dCBjaGFuZ2VkCkp1biAyNCAxMDo0MTozNSBmcmVlYnNkOTEga2VybmVsOiB4bDA6IC0+IFVO U0VMRUNURUQKSnVuIDI0IDEwOjQxOjM1IGZyZWVic2Q5MSBrZXJuZWw6IHJsMTogbWVkaWEgY2hh bmdlZCAweDAgLT4gMHgxMDAwMjYsIGV0aGVyID0gMSwgZmR4ID0gMSwgbGluayA9IDEKSnVuIDI0 IDEwOjQxOjM1IGZyZWVic2Q5MSBrZXJuZWw6IHJsMTogLT4gVU5TRUxFQ1RFRApKdW4gMjQgMTA6 NDE6MzUgZnJlZWJzZDkxIGtlcm5lbDogcmwwOiBtZWRpYSBjaGFuZ2VkIDB4MCAtPiAweDEwMDAy NiwgZXRoZXIgPSAxLCBmZHggPSAxLCBsaW5rID0gMQpKdW4gMjQgMTA6NDE6MzUgZnJlZWJzZDkx IGtlcm5lbDogcmwwOiAtPiBVTlNFTEVDVEVECkp1biAyNCAxMDo0MTozNiBmcmVlYnNkOTEga2Vy bmVsOiBybDA6IHBvcnQgbGFnaWQ9Wyg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYsODAwMCww MDAzKSwoMDAwMCwwMC0wMC0wMC0wMC0wMC0wMCwwMDAwLDAwMDAsMDAwMCldCkp1biAyNCAxMDo0 MTozNiBmcmVlYnNkOTEga2VybmVsOiBybDA6IGFnZ3JlZ2F0b3IgY3JlYXRlZApKdW4gMjQgMTA6 NDE6MzYgZnJlZWJzZDkxIGtlcm5lbDogcmwwOiBhZ2dyZWdhdG9yIGxhZ2lkPVsoODAwMCwwMC0x MC1CNS03Ri05Ny1GQiwwMTI2LDAwMDAsMDAwMCksKDAwMDAsMDAtMDAtMDAtMDAtMDAtMDAsMDAw MCwwMDAwLDAwMDApXQpKdW4gMjQgMTA6NDE6MzYgZnJlZWJzZDkxIGtlcm5lbDogcmwwOiBsYWNw X3NtX211eDogc3RhdGUgMApKdW4gMjQgMTA6NDE6MzYgZnJlZWJzZDkxIGtlcm5lbDogcmwwOiBt dXhfc3RhdGUgMCAtPiAxCkp1biAyNCAxMDo0MTozNiBmcmVlYnNkOTEga2VybmVsOiBybDE6IHBv cnQgbGFnaWQ9Wyg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYsODAwMCwwMDA1KSwoMDAwMCww MC0wMC0wMC0wMC0wMC0wMCwwMDAwLDAwMDAsMDAwMCldCkp1biAyNCAxMDo0MTozNiBmcmVlYnNk OTEga2VybmVsOiBybDE6IGFnZ3JlZ2F0b3IgY3JlYXRlZApKdW4gMjQgMTA6NDE6MzYgZnJlZWJz ZDkxIGtlcm5lbDogcmwxOiBhZ2dyZWdhdG9yIGxhZ2lkPVsoODAwMCwwMC0xMC1CNS03Ri05Ny1G QiwwMTI2LDAwMDAsMDAwMCksKDAwMDAsMDAtMDAtMDAtMDAtMDAtMDAsMDAwMCwwMDAwLDAwMDAp XQpKdW4gMjQgMTA6NDE6MzYgZnJlZWJzZDkxIGtlcm5lbDogcmwxOiBsYWNwX3NtX211eDogc3Rh dGUgMApKdW4gMjQgMTA6NDE6MzYgZnJlZWJzZDkxIGtlcm5lbDogcmwxOiBtdXhfc3RhdGUgMCAt PiAxCkp1biAyNCAxMDo0MTozNyBmcmVlYnNkOTEga2VybmVsOiBsYWNwX3NlbGVjdF90eF9wb3J0 OiBubyBhY3RpdmUgYWdncmVnYXRvcgpKdW4gMjQgMTA6NDE6MzcgZnJlZWJzZDkxIGtlcm5lbDog eGwwOiBsYWNwZHUgcmVjZWl2ZQpKdW4gMjQgMTA6NDE6MzcgZnJlZWJzZDkxIGtlcm5lbDogYWN0 b3I9KEZGRkYsRTAtOEYtRUMtMDAtQjUtMkYsMDAwOSwwMEZGLDAwMDEpCkp1biAyNCAxMDo0MToz NyBmcmVlYnNkOTEga2VybmVsOiBhY3Rvci5zdGF0ZT1jNzxBQ1RJVklUWSxUSU1FT1VULEFHR1JF R0FUSU9OLERFRkFVTFRFRCxFWFBJUkVEPgpKdW4gMjQgMTA6NDE6MzcgZnJlZWJzZDkxIGtlcm5l bDogcGFydG5lcj0oRkZGRiwwMC0wMC0wMC0wMC0wMC0wMCwwMDAxLDAwRkYsMDAwMSkKSnVuIDI0 IDEwOjQxOjM3IGZyZWVic2Q5MSBrZXJuZWw6IHBhcnRuZXIuc3RhdGU9MTxBQ1RJVklUWT4KSnVu IDI0IDEwOjQxOjM3IGZyZWVic2Q5MSBrZXJuZWw6IG1heGRlbGF5PTAKSnVuIDI0IDEwOjQxOjM3 IGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbWVkaWEgY2hhbmdlZCAweDIyIC0+IDB4MTAwMDI2LCBl dGhlciA9IDEsIGZkeCA9IDEsIGxpbmsgPSAxCkp1biAyNCAxMDo0MTozNyBmcmVlYnNkOTEga2Vy bmVsOiB4bDA6IC0+IFVOU0VMRUNURUQKSnVuIDI0IDEwOjQxOjM3IGZyZWVic2Q5MSBrZXJuZWw6 IHhsMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCkp1biAyNCAxMDo0MTozNyBmcmVlYnNkOTEg a2VybmVsOiBybDA6IGxhY3Bfc21fbXV4OiBzdGF0ZSAxCkp1biAyNCAxMDo0MTozNyBmcmVlYnNk OTEga2VybmVsOiBybDA6IGxhY3BkdSB0cmFuc21pdApKdW4gMjQgMTA6NDE6MzcgZnJlZWJzZDkx IGtlcm5lbDogYWN0b3I9KDgwMDAsMDAtMTAtQjUtN0YtOTctRkIsMDEyNiw4MDAwLDAwMDMpCkp1 biAyNCAxMDo0MTozNyBmcmVlYnNkOTEga2VybmVsOiBhY3Rvci5zdGF0ZT04NTxBQ1RJVklUWSxB R0dSRUdBVElPTixFWFBJUkVEPgpKdW4gMjQgMTA6NDE6MzcgZnJlZWJzZDkxIGtlcm5lbDogcGFy dG5lcj0oMDAwMCwwMC0wMC0wMC0wMC0wMC0wMCwwMDAwLDAwMDAsMDAwMCkKSnVuIDI0IDEwOjQx OjM3IGZyZWVic2Q5MSBrZXJuZWw6IHBhcnRuZXIuc3RhdGU9MjxUSU1FT1VUPgpKdW4gMjQgMTA6 NDE6MzcgZnJlZWJzZDkxIGtlcm5lbDogbWF4ZGVsYXk9MApKdW4gMjQgMTA6NDE6MzcgZnJlZWJz ZDkxIGtlcm5lbDogcmwxOiBsYWNwX3NtX211eDogc3RhdGUgMQpKdW4gMjQgMTA6NDE6MzcgZnJl ZWJzZDkxIGtlcm5lbDogcmwxOiBsYWNwZHUgdHJhbnNtaXQKSnVuIDI0IDEwOjQxOjM3IGZyZWVi c2Q5MSBrZXJuZWw6IGFjdG9yPSg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYsODAwMCwwMDA1 KQpKdW4gMjQgMTA6NDE6MzcgZnJlZWJzZDkxIGtlcm5lbDogYWN0b3Iuc3RhdGU9ODU8QUNUSVZJ VFksQUdHUkVHQVRJT04sRVhQSVJFRD4KSnVuIDI0IDEwOjQxOjM3IGZyZWVic2Q5MSBrZXJuZWw6 IHBhcnRuZXI9KDAwMDAsMDAtMDAtMDAtMDAtMDAtMDAsMDAwMCwwMDAwLDAwMDApCkp1biAyNCAx MDo0MTozNyBmcmVlYnNkOTEga2VybmVsOiBwYXJ0bmVyLnN0YXRlPTI8VElNRU9VVD4KSnVuIDI0 IDEwOjQxOjM3IGZyZWVic2Q5MSBrZXJuZWw6IG1heGRlbGF5PTAKSnVuIDI0IDEwOjQxOjM3IGZy ZWVic2Q5MSBrZXJuZWw6IHhsMDogcG9ydCBsYWdpZD1bKDgwMDAsMDAtMTAtQjUtN0YtOTctRkIs MDEyNiw4MDAwLDAwMDQpLChGRkZGLDAwLTAwLTAwLTAwLTAwLTAwLDAwMDAsRkZGRiwwMDAwKV0K SnVuIDI0IDEwOjQxOjM3IGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogYWdncmVnYXRvciBjcmVhdGVk Ckp1biAyNCAxMDo0MTozNyBmcmVlYnNkOTEga2VybmVsOiB4bDA6IGFnZ3JlZ2F0b3IgbGFnaWQ9 Wyg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYsMDAwMCwwMDAwKSwoRkZGRiwwMC0wMC0wMC0w MC0wMC0wMCwwMDAwLDAwMDAsMDAwMCldCkp1biAyNCAxMDo0MTozNyBmcmVlYnNkOTEga2VybmVs OiB4bDA6IGxhY3Bfc21fbXV4OiBzdGF0ZSAwCkp1biAyNCAxMDo0MTozNyBmcmVlYnNkOTEga2Vy bmVsOiB4bDA6IG11eF9zdGF0ZSAwIC0+IDEKSnVuIDI0IDEwOjQxOjM4IGZyZWVic2Q5MSBrZXJu ZWw6IHJsMDogbGFjcF9zbV9yeF90aW1lcjogRVhQSVJFRCAtPiBERUZBVUxURUQKSnVuIDI0IDEw OjQxOjM4IGZyZWVic2Q5MSBrZXJuZWw6IHJsMDogbGFjcF9zbV9yeF91cGRhdGVfZGVmYXVsdF9z ZWxlY3RlZApKdW4gMjQgMTA6NDE6MzggZnJlZWJzZDkxIGtlcm5lbDogcmwwOiBsYWNwX3NtX3J4 X3VwZGF0ZV9zZWxlY3RlZF9mcm9tX3BlZXJpbmZvCkp1biAyNCAxMDo0MTozOCBmcmVlYnNkOTEg a2VybmVsOiBybDA6IGxhY3Bfc21fcnhfcmVjb3JkX2RlZmF1bHQKSnVuIDI0IDEwOjQxOjM4IGZy ZWVic2Q5MSBrZXJuZWw6IHJsMDogcGFydG5lciB0aW1lb3V0IGNoYW5nZWQKSnVuIDI0IDEwOjQx OjM4IGZyZWVic2Q5MSBrZXJuZWw6IHJsMDogbGFjcF9zbV9tdXhfdGltZXI6IGFnZ3JlZ2F0b3Ig Wyg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYsMDAwMCwwMDAwKSwoMDAwMCwwMC0wMC0wMC0w MC0wMC0wMCwwMDAwLDAwMDAsMDAwMCldLCBwZW5kaW5nIDEgLT4gMApKdW4gMjQgMTA6NDE6Mzgg ZnJlZWJzZDkxIGtlcm5lbDogcmwwOiBsYWNwX3NtX211eDogc3RhdGUgMQpKdW4gMjQgMTA6NDE6 MzggZnJlZWJzZDkxIGtlcm5lbDogcmwwOiBjb2xsZWN0aW5nIGRpc2FibGVkCkp1biAyNCAxMDo0 MTozOCBmcmVlYnNkOTEga2VybmVsOiBsYWNwX2FnZ3JlZ2F0b3JfZGVscmVmOiBsYWdpZD1bKDgw MDAsMDAtMTAtQjUtN0YtOTctRkIsMDEyNiwwMDAwLDAwMDApLCgwMDAwLDAwLTAwLTAwLTAwLTAw LTAwLDAwMDAsMDAwMCwwMDAwKV0sIHJlZmNudCAxIC0+IDAKSnVuIDI0IDEwOjQxOjM4IGZyZWVi c2Q5MSBrZXJuZWw6IHJsMDogbXV4X3N0YXRlIDEgLT4gMApKdW4gMjQgMTA6NDE6MzggZnJlZWJz ZDkxIGtlcm5lbDogcmwwOiBsYWNwZHUgdHJhbnNtaXQKSnVuIDI0IDEwOjQxOjM4IGZyZWVic2Q5 MSBrZXJuZWw6IGFjdG9yPSg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYsODAwMCwwMDAzKQpK dW4gMjQgMTA6NDE6MzggZnJlZWJzZDkxIGtlcm5lbDogYWN0b3Iuc3RhdGU9NDU8QUNUSVZJVFks QUdHUkVHQVRJT04sREVGQVVMVEVEPgpKdW4gMjQgMTA6NDE6MzggZnJlZWJzZDkxIGtlcm5lbDog cGFydG5lcj0oRkZGRiwwMC0wMC0wMC0wMC0wMC0wMCwwMDAwLEZGRkYsMDAwMCkKSnVuIDI0IDEw OjQxOjM4IGZyZWVic2Q5MSBrZXJuZWw6IHBhcnRuZXIuc3RhdGU9M2M8QUdHUkVHQVRJT04sU1lO QyxDT0xMRUNUSU5HLERJU1RSSUJVVElORz4KSnVuIDI0IDEwOjQxOjM4IGZyZWVic2Q5MSBrZXJu ZWw6IG1heGRlbGF5PTAKSnVuIDI0IDEwOjQxOjM4IGZyZWVic2Q5MSBrZXJuZWw6IHJsMTogbGFj cF9zbV9yeF90aW1lcjogRVhQSVJFRCAtPiBERUZBVUxURUQKSnVuIDI0IDEwOjQxOjM4IGZyZWVi c2Q5MSBrZXJuZWw6IHJsMTogbGFjcF9zbV9yeF91cGRhdGVfZGVmYXVsdF9zZWxlY3RlZApKdW4g MjQgMTA6NDE6MzggZnJlZWJzZDkxIGtlcm5lbDogcmwxOiBsYWNwX3NtX3J4X3VwZGF0ZV9zZWxl Y3RlZF9mcm9tX3BlZXJpbmZvCkp1biAyNCAxMDo0MTozOCBmcmVlYnNkOTEga2VybmVsOiBybDE6 IGxhY3Bfc21fcnhfcmVjb3JkX2RlZmF1bHQKSnVuIDI0IDEwOjQxOjM4IGZyZWVic2Q5MSBrZXJu ZWw6IHJsMTogcGFydG5lciB0aW1lb3V0IGNoYW5nZWQKSnVuIDI0IDEwOjQxOjM4IGZyZWVic2Q5 MSBrZXJuZWw6IHJsMTogbGFjcF9zbV9tdXhfdGltZXI6IGFnZ3JlZ2F0b3IgWyg4MDAwLDAwLTEw LUI1LTdGLTk3LUZCLDAxMjYsMDAwMCwwMDAwKSwoMDAwMCwwMC0wMC0wMC0wMC0wMC0wMCwwMDAw LDAwMDAsMDAwMCldLCBwZW5kaW5nIDEgLT4gMApKdW4gMjQgMTA6NDE6MzggZnJlZWJzZDkxIGtl cm5lbDogcmwxOiBsYWNwX3NtX211eDogc3RhdGUgMQpKdW4gMjQgMTA6NDE6MzggZnJlZWJzZDkx IGtlcm5lbDogcmwxOiBjb2xsZWN0aW5nIGRpc2FibGVkCkp1biAyNCAxMDo0MTozOCBmcmVlYnNk OTEga2VybmVsOiBsYWNwX2FnZ3JlZ2F0b3JfZGVscmVmOiBsYWdpZD1bKDgwMDAsMDAtMTAtQjUt N0YtOTctRkIsMDEyNiwwMDAwLDAwMDApLCgwMDAwLDAwLTAwLTAwLTAwLTAwLTAwLDAwMDAsMDAw MCwwMDAwKV0sIHJlZmNudCAxIC0+IDAKSnVuIDI0IDEwOjQxOjM4IGZyZWVic2Q5MSBrZXJuZWw6 IHJsMTogbXV4X3N0YXRlIDEgLT4gMApKdW4gMjQgMTA6NDE6MzggZnJlZWJzZDkxIGtlcm5lbDog cmwxOiBsYWNwZHUgdHJhbnNtaXQKSnVuIDI0IDEwOjQxOjM4IGZyZWVic2Q5MSBrZXJuZWw6IGFj dG9yPSg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYsODAwMCwwMDA1KQpKdW4gMjQgMTA6NDE6 MzggZnJlZWJzZDkxIGtlcm5lbDogYWN0b3Iuc3RhdGU9NDU8QUNUSVZJVFksQUdHUkVHQVRJT04s REVGQVVMVEVEPgpKdW4gMjQgMTA6NDE6MzggZnJlZWJzZDkxIGtlcm5lbDogcGFydG5lcj0oRkZG RiwwMC0wMC0wMC0wMC0wMC0wMCwwMDAwLEZGRkYsMDAwMCkKSnVuIDI0IDEwOjQxOjM4IGZyZWVi c2Q5MSBrZXJuZWw6IHBhcnRuZXIuc3RhdGU9M2M8QUdHUkVHQVRJT04sU1lOQyxDT0xMRUNUSU5H LERJU1RSSUJVVElORz4KSnVuIDI0IDEwOjQxOjM4IGZyZWVic2Q5MSBrZXJuZWw6IG1heGRlbGF5 PTAKSnVuIDI0IDEwOjQxOjM4IGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbGFjcF9zbV9tdXg6IHN0 YXRlIDEKSnVuIDI0IDEwOjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbGFjcGR1IHJlY2Vp dmUKSnVuIDI0IDEwOjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IGFjdG9yPShGRkZGLEUwLThGLUVD LTAwLUI1LTJGLDAwMDksMDBGRiwwMDAxKQpKdW4gMjQgMTA6NDE6MzkgZnJlZWJzZDkxIGtlcm5l bDogYWN0b3Iuc3RhdGU9Y2Y8QUNUSVZJVFksVElNRU9VVCxBR0dSRUdBVElPTixTWU5DLERFRkFV TFRFRCxFWFBJUkVEPgpKdW4gMjQgMTA6NDE6MzkgZnJlZWJzZDkxIGtlcm5lbDogcGFydG5lcj0o RkZGRiwwMC0wMC0wMC0wMC0wMC0wMCwwMDAxLDAwRkYsMDAwMSkKSnVuIDI0IDEwOjQxOjM5IGZy ZWVic2Q5MSBrZXJuZWw6IHBhcnRuZXIuc3RhdGU9MTxBQ1RJVklUWT4KSnVuIDI0IDEwOjQxOjM5 IGZyZWVic2Q5MSBrZXJuZWw6IG1heGRlbGF5PTAKSnVuIDI0IDEwOjQxOjM5IGZyZWVic2Q5MSBr ZXJuZWw6IHhsMDogbGFjcF9zbV9yeF91cGRhdGVfc2VsZWN0ZWQKSnVuIDI0IDEwOjQxOjM5IGZy ZWVic2Q5MSBrZXJuZWw6IHhsMDogbGFjcF9zbV9yeF91cGRhdGVfc2VsZWN0ZWRfZnJvbV9wZWVy aW5mbwpKdW4gMjQgMTA6NDE6MzkgZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBsYWNwX3NtX3J4X3Vw ZGF0ZV9udHQKSnVuIDI0IDEwOjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbGFjcF9zbV9y eF91cGRhdGVfbnR0OiBhc3NlcnQgbnR0Ckp1biAyNCAxMDo0MTozOSBmcmVlYnNkOTEga2VybmVs OiB4bDA6IGxhY3Bfc21fcnhfcmVjb3JkX3BkdQpKdW4gMjQgMTA6NDE6MzkgZnJlZWJzZDkxIGtl cm5lbDogeGwwOiBvbGQgcHN0YXRlIDM4PFNZTkMsQ09MTEVDVElORyxESVNUUklCVVRJTkc+Ckp1 biAyNCAxMDo0MTozOSBmcmVlYnNkOTEga2VybmVsOiB4bDA6IG5ldyBwc3RhdGUgY2Y8QUNUSVZJ VFksVElNRU9VVCxBR0dSRUdBVElPTixTWU5DLERFRkFVTFRFRCxFWFBJUkVEPgpKdW4gMjQgMTA6 NDE6MzkgZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBwYXJ0bmVyIHRpbWVvdXQgY2hhbmdlZApKdW4g MjQgMTA6NDE6MzkgZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBsYWNwZHUgdHJhbnNtaXQKSnVuIDI0 IDEwOjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IGFjdG9yPSg4MDAwLDAwLTEwLUI1LTdGLTk3LUZC LDAxMjYsODAwMCwwMDA0KQpKdW4gMjQgMTA6NDE6MzkgZnJlZWJzZDkxIGtlcm5lbDogYWN0b3Iu c3RhdGU9NTxBQ1RJVklUWSxBR0dSRUdBVElPTj4KSnVuIDI0IDEwOjQxOjM5IGZyZWVic2Q5MSBr ZXJuZWw6IHBhcnRuZXI9KEZGRkYsRTAtOEYtRUMtMDAtQjUtMkYsMDAwOSwwMEZGLDAwMDEpCkp1 biAyNCAxMDo0MTozOSBmcmVlYnNkOTEga2VybmVsOiBwYXJ0bmVyLnN0YXRlPWNmPEFDVElWSVRZ LFRJTUVPVVQsQUdHUkVHQVRJT04sU1lOQyxERUZBVUxURUQsRVhQSVJFRD4KSnVuIDI0IDEwOjQx OjM5IGZyZWVic2Q5MSBrZXJuZWw6IG1heGRlbGF5PTAKSnVuIDI0IDEwOjQxOjM5IGZyZWVic2Q5 MSBrZXJuZWw6IHJsMDogcG9ydCBsYWdpZD1bKDgwMDAsMDAtMTAtQjUtN0YtOTctRkIsMDEyNiw4 MDAwLDAwMDMpLChGRkZGLDAwLTAwLTAwLTAwLTAwLTAwLDAwMDAsRkZGRiwwMDAwKV0KSnVuIDI0 IDEwOjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IHJsMDogY29tcGF0aWJsZSBhZ2dyZWdhdG9yIGZv dW5kCkp1biAyNCAxMDo0MTozOSBmcmVlYnNkOTEga2VybmVsOiBsYWNwX2FnZ3JlZ2F0b3JfYWRk cmVmOiBsYWdpZD1bKDgwMDAsMDAtMTAtQjUtN0YtOTctRkIsMDEyNiwwMDAwLDAwMDApLChGRkZG LDAwLTAwLTAwLTAwLTAwLTAwLDAwMDAsMDAwMCwwMDAwKV0sIHJlZmNudCAxIC0+IDIKSnVuIDI0 IDEwOjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IHJsMDogYWdncmVnYXRvciBsYWdpZD1bKDgwMDAs MDAtMTAtQjUtN0YtOTctRkIsMDEyNiwwMDAwLDAwMDApLChGRkZGLDAwLTAwLTAwLTAwLTAwLTAw LDAwMDAsMDAwMCwwMDAwKV0KSnVuIDI0IDEwOjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IHJsMDog bGFjcF9zbV9tdXg6IHN0YXRlIDAKSnVuIDI0IDEwOjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IHJs MDogbXV4X3N0YXRlIDAgLT4gMQpKdW4gMjQgMTA6NDE6MzkgZnJlZWJzZDkxIGtlcm5lbDogcmwx OiBwb3J0IGxhZ2lkPVsoODAwMCwwMC0xMC1CNS03Ri05Ny1GQiwwMTI2LDgwMDAsMDAwNSksKEZG RkYsMDAtMDAtMDAtMDAtMDAtMDAsMDAwMCxGRkZGLDAwMDApXQpKdW4gMjQgMTA6NDE6MzkgZnJl ZWJzZDkxIGtlcm5lbDogcmwxOiBjb21wYXRpYmxlIGFnZ3JlZ2F0b3IgZm91bmQKSnVuIDI0IDEw OjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IGxhY3BfYWdncmVnYXRvcl9hZGRyZWY6IGxhZ2lkPVso ODAwMCwwMC0xMC1CNS03Ri05Ny1GQiwwMTI2LDAwMDAsMDAwMCksKEZGRkYsMDAtMDAtMDAtMDAt MDAtMDAsMDAwMCwwMDAwLDAwMDApXSwgcmVmY250IDIgLT4gMwpKdW4gMjQgMTA6NDE6MzkgZnJl ZWJzZDkxIGtlcm5lbDogcmwxOiBhZ2dyZWdhdG9yIGxhZ2lkPVsoODAwMCwwMC0xMC1CNS03Ri05 Ny1GQiwwMTI2LDAwMDAsMDAwMCksKEZGRkYsMDAtMDAtMDAtMDAtMDAtMDAsMDAwMCwwMDAwLDAw MDApXQpKdW4gMjQgMTA6NDE6MzkgZnJlZWJzZDkxIGtlcm5lbDogcmwxOiBsYWNwX3NtX211eDog c3RhdGUgMApKdW4gMjQgMTA6NDE6MzkgZnJlZWJzZDkxIGtlcm5lbDogcmwxOiBtdXhfc3RhdGUg MCAtPiAxCkp1biAyNCAxMDo0MTozOSBmcmVlYnNkOTEga2VybmVsOiB4bDA6IGxhY3Bfc21fbXV4 X3RpbWVyOiBhZ2dyZWdhdG9yIFsoODAwMCwwMC0xMC1CNS03Ri05Ny1GQiwwMTI2LDAwMDAsMDAw MCksKEZGRkYsMDAtMDAtMDAtMDAtMDAtMDAsMDAwMCwwMDAwLDAwMDApXSwgcGVuZGluZyAzIC0+ IDIKSnVuIDI0IDEwOjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbGFjcF9zbV9tdXg6IHN0 YXRlIDEKSnVuIDI0IDEwOjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogY29sbGVjdGluZyBk aXNhYmxlZApKdW4gMjQgMTA6NDE6MzkgZnJlZWJzZDkxIGtlcm5lbDogbGFjcF9hZ2dyZWdhdG9y X2RlbHJlZjogbGFnaWQ9Wyg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYsMDAwMCwwMDAwKSwo RkZGRiwwMC0wMC0wMC0wMC0wMC0wMCwwMDAwLDAwMDAsMDAwMCldLCByZWZjbnQgMyAtPiAyCkp1 biAyNCAxMDo0MTozOSBmcmVlYnNkOTEga2VybmVsOiB4bDA6IG11eF9zdGF0ZSAxIC0+IDAKSnVu IDI0IDEwOjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbGFjcGR1IHRyYW5zbWl0Ckp1biAy NCAxMDo0MTozOSBmcmVlYnNkOTEga2VybmVsOiBhY3Rvcj0oODAwMCwwMC0xMC1CNS03Ri05Ny1G QiwwMTI2LDgwMDAsMDAwNCkKSnVuIDI0IDEwOjQxOjM5IGZyZWVic2Q5MSBrZXJuZWw6IGFjdG9y LnN0YXRlPTU8QUNUSVZJVFksQUdHUkVHQVRJT04+Ckp1biAyNCAxMDo0MTozOSBmcmVlYnNkOTEg a2VybmVsOiBwYXJ0bmVyPShGRkZGLEUwLThGLUVDLTAwLUI1LTJGLDAwMDksMDBGRiwwMDAxKQpK dW4gMjQgMTA6NDE6MzkgZnJlZWJzZDkxIGtlcm5lbDogcGFydG5lci5zdGF0ZT1jZjxBQ1RJVklU WSxUSU1FT1VULEFHR1JFR0FUSU9OLFNZTkMsREVGQVVMVEVELEVYUElSRUQ+Ckp1biAyNCAxMDo0 MTozOSBmcmVlYnNkOTEga2VybmVsOiBtYXhkZWxheT0wCkp1biAyNCAxMDo0MTo0MCBmcmVlYnNk OTEga2VybmVsOiBybDA6IGxhY3Bfc21fbXV4OiBzdGF0ZSAxCkp1biAyNCAxMDo0MTo0MCBmcmVl YnNkOTEga2VybmVsOiBybDE6IGxhY3Bfc21fbXV4OiBzdGF0ZSAxCkp1biAyNCAxMDo0MTo0MCBm cmVlYnNkOTEga2VybmVsOiB4bDA6IHBvcnQgbGFnaWQ9Wyg4MDAwLDAwLTEwLUI1LTdGLTk3LUZC LDAxMjYsODAwMCwwMDA0KSwoRkZGRixFMC04Ri1FQy0wMC1CNS0yRiwwMDA5LDAwRkYsMDAwMSld Ckp1biAyNCAxMDo0MTo0MCBmcmVlYnNkOTEga2VybmVsOiB4bDA6IGFnZ3JlZ2F0b3IgY3JlYXRl ZApKdW4gMjQgMTA6NDE6NDAgZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBhZ2dyZWdhdG9yIGxhZ2lk PVsoODAwMCwwMC0xMC1CNS03Ri05Ny1GQiwwMTI2LDAwMDAsMDAwMCksKEZGRkYsRTAtOEYtRUMt MDAtQjUtMkYsMDAwOSwwMDAwLDAwMDApXQpKdW4gMjQgMTA6NDE6NDAgZnJlZWJzZDkxIGtlcm5l bDogeGwwOiBsYWNwX3NtX211eDogc3RhdGUgMApKdW4gMjQgMTA6NDE6NDAgZnJlZWJzZDkxIGtl cm5lbDogeGwwOiBtdXhfc3RhdGUgMCAtPiAxCkp1biAyNCAxMDo0MTo0MCBmcmVlYnNkOTEga2Vy bmVsOiB4bDA6IGxhY3BkdSB0cmFuc21pdApKdW4gMjQgMTA6NDE6NDAgZnJlZWJzZDkxIGtlcm5l bDogYWN0b3I9KDgwMDAsMDAtMTAtQjUtN0YtOTctRkIsMDEyNiw4MDAwLDAwMDQpCkp1biAyNCAx MDo0MTo0MCBmcmVlYnNkOTEga2VybmVsOiBhY3Rvci5zdGF0ZT01PEFDVElWSVRZLEFHR1JFR0FU SU9OPgpKdW4gMjQgMTA6NDE6NDAgZnJlZWJzZDkxIGtlcm5lbDogcGFydG5lcj0oRkZGRixFMC04 Ri1FQy0wMC1CNS0yRiwwMDA5LDAwRkYsMDAwMSkKSnVuIDI0IDEwOjQxOjQwIGZyZWVic2Q5MSBr ZXJuZWw6IHBhcnRuZXIuc3RhdGU9Y2Y8QUNUSVZJVFksVElNRU9VVCxBR0dSRUdBVElPTixTWU5D LERFRkFVTFRFRCxFWFBJUkVEPgpKdW4gMjQgMTA6NDE6NDAgZnJlZWJzZDkxIGtlcm5lbDogbWF4 ZGVsYXk9MApKdW4gMjQgMTA6NDE6NDEgZnJlZWJzZDkxIGtlcm5lbDogcmwwOiBsYWNwX3NtX211 eF90aW1lcjogYWdncmVnYXRvciBbKDgwMDAsMDAtMTAtQjUtN0YtOTctRkIsMDEyNiwwMDAwLDAw MDApLChGRkZGLDAwLTAwLTAwLTAwLTAwLTAwLDAwMDAsMDAwMCwwMDAwKV0sIHBlbmRpbmcgMiAt PiAxCkp1biAyNCAxMDo0MTo0MSBmcmVlYnNkOTEga2VybmVsOiBybDA6IGxhY3Bfc21fbXV4OiBz dGF0ZSAxCkp1biAyNCAxMDo0MTo0MSBmcmVlYnNkOTEga2VybmVsOiBybDE6IGxhY3Bfc21fbXV4 X3RpbWVyOiBhZ2dyZWdhdG9yIFsoODAwMCwwMC0xMC1CNS03Ri05Ny1GQiwwMTI2LDAwMDAsMDAw MCksKEZGRkYsMDAtMDAtMDAtMDAtMDAtMDAsMDAwMCwwMDAwLDAwMDApXSwgcGVuZGluZyAxIC0+ IDAKSnVuIDI0IDEwOjQxOjQxIGZyZWVic2Q5MSBrZXJuZWw6IHJsMTogbGFjcF9zbV9tdXg6IHN0 YXRlIDEKSnVuIDI0IDEwOjQxOjQxIGZyZWVic2Q5MSBrZXJuZWw6IHJsMTogY29sbGVjdGluZyBk aXNhYmxlZApKdW4gMjQgMTA6NDE6NDEgZnJlZWJzZDkxIGtlcm5lbDogcmwxOiBtdXhfc3RhdGUg MSAtPiAyCkp1biAyNCAxMDo0MTo0MSBmcmVlYnNkOTEga2VybmVsOiBybDE6IGNvbGxlY3Rpbmcg ZW5hYmxlZApKdW4gMjQgMTA6NDE6NDEgZnJlZWJzZDkxIGtlcm5lbDogcmwxOiBtdXhfc3RhdGUg MiAtPiAzCkp1biAyNCAxMDo0MTo0MSBmcmVlYnNkOTEga2VybmVsOiBybDE6IGVuYWJsZSBkaXN0 cmlidXRpbmcgb24gYWdncmVnYXRvciBbKDgwMDAsMDAtMTAtQjUtN0YtOTctRkIsMDEyNiwwMDAw LDAwMDApLChGRkZGLDAwLTAwLTAwLTAwLTAwLTAwLDAwMDAsMDAwMCwwMDAwKV0sIG5wb3J0cyAw IC0+IDEKSnVuIDI0IDEwOjQxOjQxIGZyZWVic2Q5MSBrZXJuZWw6IGxhY3Bfc2VsZWN0X2FjdGl2 ZV9hZ2dyZWdhdG9yCkp1biAyNCAxMDo0MTo0MSBmcmVlYnNkOTEga2VybmVsOiBbKDgwMDAsMDAt MTAtQjUtN0YtOTctRkIsMDEyNiwwMDAwLDAwMDApLChGRkZGLDAwLTAwLTAwLTAwLTAwLTAwLDAw MDAsMDAwMCwwMDAwKV0sIHNwZWVkPTEwMDAwMDAwMCwgbnBvcnRzPTEKSnVuIDI0IDEwOjQxOjQx IGZyZWVic2Q5MSBrZXJuZWw6IGFjdGl2ZSBhZ2dyZWdhdG9yIGNoYW5nZWQKSnVuIDI0IDEwOjQx OjQxIGZyZWVic2Q5MSBrZXJuZWw6IG9sZCAobm9uZSkKSnVuIDI0IDEwOjQxOjQxIGZyZWVic2Q5 MSBrZXJuZWw6IG5ldyBbKDgwMDAsMDAtMTAtQjUtN0YtOTctRkIsMDEyNiwwMDAwLDAwMDApLChG RkZGLDAwLTAwLTAwLTAwLTAwLTAwLDAwMDAsMDAwMCwwMDAwKV0KSnVuIDI0IDEwOjQxOjQxIGZy ZWVic2Q5MSBrZXJuZWw6IFNldCB0YWJsZSAxIHdpdGggMSBwb3J0cwpKdW4gMjQgMTA6NDE6NDEg ZnJlZWJzZDkxIGtlcm5lbDogbGFjcF9zdXBwcmVzc19kaXN0cmlidXRpbmcKSnVuIDI0IDEwOjQx OjQxIGZyZWVic2Q5MSBrZXJuZWw6IHJsMDogbWFya2VyIHRyYW5zbWl0LCBwb3J0PTMsIHN5cz0w MDoxMDpiNTo3Zjo5NzpmYiwgaWQ9MQpKdW4gMjQgMTA6NDE6NDEgZnJlZWJzZDkxIGtlcm5lbDog cmwxOiBtYXJrZXIgdHJhbnNtaXQsIHBvcnQ9NSwgc3lzPTAwOjEwOmI1OjdmOjk3OmZiLCBpZD0x Ckp1biAyNCAxMDo0MTo0MSBmcmVlYnNkOTEga2VybmVsOiB4bDA6IG1hcmtlciB0cmFuc21pdCwg cG9ydD00LCBzeXM9MDA6MTA6YjU6N2Y6OTc6ZmIsIGlkPTEKSnVuIDI0IDEwOjQxOjQxIGZyZWVi c2Q5MSBrZXJuZWw6IHJsMTogbXV4X3N0YXRlIDMgLT4gNApKdW4gMjQgMTA6NDE6NDEgZnJlZWJz ZDkxIGtlcm5lbDogeGwwOiBtYXJrZXIgcmVzcG9uc2UsIHBvcnQ9NCwgc3lzPTAwOjEwOmI1Ojdm Ojk3OmZiLCBpZD0xCkp1biAyNCAxMDo0MTo0MSBmcmVlYnNkOTEga2VybmVsOiBybDE6IGxhY3Bk dSB0cmFuc21pdApKdW4gMjQgMTA6NDE6NDEgZnJlZWJzZDkxIGtlcm5lbDogYWN0b3I9KDgwMDAs MDAtMTAtQjUtN0YtOTctRkIsMDEyNiw4MDAwLDAwMDUpCkp1biAyNCAxMDo0MTo0MSBmcmVlYnNk OTEga2VybmVsOiBhY3Rvci5zdGF0ZT03ZDxBQ1RJVklUWSxBR0dSRUdBVElPTixTWU5DLENPTExF Q1RJTkcsRElTVFJJQlVUSU5HLERFRkFVTFRFRD4KSnVuIDI0IDEwOjQxOjQxIGZyZWVic2Q5MSBr ZXJuZWw6IHBhcnRuZXI9KEZGRkYsMDAtMDAtMDAtMDAtMDAtMDAsMDAwMCxGRkZGLDAwMDApCkp1 biAyNCAxMDo0MTo0MSBmcmVlYnNkOTEga2VybmVsOiBwYXJ0bmVyLnN0YXRlPTNjPEFHR1JFR0FU SU9OLFNZTkMsQ09MTEVDVElORyxESVNUUklCVVRJTkc+Ckp1biAyNCAxMDo0MTo0MSBmcmVlYnNk OTEga2VybmVsOiBtYXhkZWxheT0wCkp1biAyNCAxMDo0MTo0MSBmcmVlYnNkOTEga2VybmVsOiB4 bDA6IGxhY3Bfc21fbXV4OiBzdGF0ZSAxCkp1biAyNCAxMDo0MTo0MSBmcmVlYnNkOTEga2VybmVs OiB4bDA6IGxhY3BkdSB0cmFuc21pdApKdW4gMjQgMTA6NDE6NDEgZnJlZWJzZDkxIGtlcm5lbDog YWN0b3I9KDgwMDAsMDAtMTAtQjUtN0YtOTctRkIsMDEyNiw4MDAwLDAwMDQpCkp1biAyNCAxMDo0 MTo0MSBmcmVlYnNkOTEga2VybmVsOiBhY3Rvci5zdGF0ZT01PEFDVElWSVRZLEFHR1JFR0FUSU9O PgpKdW4gMjQgMTA6NDE6NDEgZnJlZWJzZDkxIGtlcm5lbDogcGFydG5lcj0oRkZGRixFMC04Ri1F Qy0wMC1CNS0yRiwwMDA5LDAwRkYsMDAwMSkKSnVuIDI0IDEwOjQxOjQxIGZyZWVic2Q5MSBrZXJu ZWw6IHBhcnRuZXIuc3RhdGU9Y2Y8QUNUSVZJVFksVElNRU9VVCxBR0dSRUdBVElPTixTWU5DLERF RkFVTFRFRCxFWFBJUkVEPgpKdW4gMjQgMTA6NDE6NDEgZnJlZWJzZDkxIGtlcm5lbDogbWF4ZGVs YXk9MApKdW4gMjQgMTA6NDE6NDIgZnJlZWJzZDkxIGtlcm5lbDogcmwwOiBsYWNwX3NtX211eDog c3RhdGUgMQpKdW4gMjQgMTA6NDE6NDIgZnJlZWJzZDkxIGtlcm5lbDogcmwwOiBjb2xsZWN0aW5n IGRpc2FibGVkCkp1biAyNCAxMDo0MTo0MiBmcmVlYnNkOTEga2VybmVsOiBybDA6IG11eF9zdGF0 ZSAxIC0+IDIKSnVuIDI0IDEwOjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6IHJsMDogY29sbGVjdGlu ZyBlbmFibGVkCkp1biAyNCAxMDo0MTo0MiBmcmVlYnNkOTEga2VybmVsOiBybDA6IG11eF9zdGF0 ZSAyIC0+IDMKSnVuIDI0IDEwOjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6IHJsMDogZW5hYmxlIGRp c3RyaWJ1dGluZyBvbiBhZ2dyZWdhdG9yIFsoODAwMCwwMC0xMC1CNS03Ri05Ny1GQiwwMTI2LDAw MDAsMDAwMCksKEZGRkYsMDAtMDAtMDAtMDAtMDAtMDAsMDAwMCwwMDAwLDAwMDApXSwgbnBvcnRz IDEgLT4gMgpKdW4gMjQgMTA6NDE6NDIgZnJlZWJzZDkxIGtlcm5lbDogbGFjcF9zdXBwcmVzc19k aXN0cmlidXRpbmcKSnVuIDI0IDEwOjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6IHJsMDogbWFya2Vy IHRyYW5zbWl0LCBwb3J0PTMsIHN5cz0wMDoxMDpiNTo3Zjo5NzpmYiwgaWQ9MgpKdW4gMjQgMTA6 NDE6NDIgZnJlZWJzZDkxIGtlcm5lbDogcmwxOiBtYXJrZXIgdHJhbnNtaXQsIHBvcnQ9NSwgc3lz PTAwOjEwOmI1OjdmOjk3OmZiLCBpZD0yCkp1biAyNCAxMDo0MTo0MiBmcmVlYnNkOTEga2VybmVs OiB4bDA6IG1hcmtlciB0cmFuc21pdCwgcG9ydD00LCBzeXM9MDA6MTA6YjU6N2Y6OTc6ZmIsIGlk PTIKSnVuIDI0IDEwOjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6IFNldCB0YWJsZSAwIHdpdGggMiBw b3J0cwpKdW4gMjQgMTA6NDE6NDIgZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBtYXJrZXIgcmVzcG9u c2UsIHBvcnQ9NCwgc3lzPTAwOjEwOmI1OjdmOjk3OmZiLCBpZD0yCkp1biAyNCAxMDo0MTo0MiBm cmVlYnNkOTEga2VybmVsOiBybDA6IG11eF9zdGF0ZSAzIC0+IDQKSnVuIDI0IDEwOjQxOjQyIGZy ZWVic2Q5MSBrZXJuZWw6IHJsMDogbGFjcGR1IHRyYW5zbWl0Ckp1biAyNCAxMDo0MTo0MiBmcmVl YnNkOTEga2VybmVsOiBhY3Rvcj0oODAwMCwwMC0xMC1CNS03Ri05Ny1GQiwwMTI2LDgwMDAsMDAw MykKSnVuIDI0IDEwOjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6IGFjdG9yLnN0YXRlPTdkPEFDVElW SVRZLEFHR1JFR0FUSU9OLFNZTkMsQ09MTEVDVElORyxESVNUUklCVVRJTkcsREVGQVVMVEVEPgpK dW4gMjQgMTA6NDE6NDIgZnJlZWJzZDkxIGtlcm5lbDogcGFydG5lcj0oRkZGRiwwMC0wMC0wMC0w MC0wMC0wMCwwMDAwLEZGRkYsMDAwMCkKSnVuIDI0IDEwOjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6 IHBhcnRuZXIuc3RhdGU9M2M8QUdHUkVHQVRJT04sU1lOQyxDT0xMRUNUSU5HLERJU1RSSUJVVElO Rz4KSnVuIDI0IDEwOjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6IG1heGRlbGF5PTAKSnVuIDI0IDEw OjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6IHJsMTogbGFjcF9zbV9tdXg6IHN0YXRlIDQKSnVuIDI0 IDEwOjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbGFjcF9zbV9tdXhfdGltZXI6IGFnZ3Jl Z2F0b3IgWyg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYsMDAwMCwwMDAwKSwoRkZGRixFMC04 Ri1FQy0wMC1CNS0yRiwwMDA5LDAwMDAsMDAwMCldLCBwZW5kaW5nIDEgLT4gMApKdW4gMjQgMTA6 NDE6NDIgZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBsYWNwX3NtX211eDogc3RhdGUgMQpKdW4gMjQg MTA6NDE6NDIgZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBjb2xsZWN0aW5nIGRpc2FibGVkCkp1biAy NCAxMDo0MTo0MiBmcmVlYnNkOTEga2VybmVsOiB4bDA6IG11eF9zdGF0ZSAxIC0+IDIKSnVuIDI0 IDEwOjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogY29sbGVjdGluZyBlbmFibGVkCkp1biAy NCAxMDo0MTo0MiBmcmVlYnNkOTEga2VybmVsOiB4bDA6IG11eF9zdGF0ZSAyIC0+IDMKSnVuIDI0 IDEwOjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbGFjcGR1IHRyYW5zbWl0Ckp1biAyNCAx MDo0MTo0MiBmcmVlYnNkOTEga2VybmVsOiBhY3Rvcj0oODAwMCwwMC0xMC1CNS03Ri05Ny1GQiww MTI2LDgwMDAsMDAwNCkKSnVuIDI0IDEwOjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6IGFjdG9yLnN0 YXRlPTFkPEFDVElWSVRZLEFHR1JFR0FUSU9OLFNZTkMsQ09MTEVDVElORz4KSnVuIDI0IDEwOjQx OjQyIGZyZWVic2Q5MSBrZXJuZWw6IHBhcnRuZXI9KEZGRkYsRTAtOEYtRUMtMDAtQjUtMkYsMDAw OSwwMEZGLDAwMDEpCkp1biAyNCAxMDo0MTo0MiBmcmVlYnNkOTEga2VybmVsOiBwYXJ0bmVyLnN0 YXRlPWNmPEFDVElWSVRZLFRJTUVPVVQsQUdHUkVHQVRJT04sU1lOQyxERUZBVUxURUQsRVhQSVJF RD4KSnVuIDI0IDEwOjQxOjQyIGZyZWVic2Q5MSBrZXJuZWw6IG1heGRlbGF5PTAKSnVuIDI0IDEw OjQxOjQzIGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbGFjcGR1IHJlY2VpdmUKSnVuIDI0IDEwOjQx OjQzIGZyZWVic2Q5MSBrZXJuZWw6IGFjdG9yPShGRkZGLEUwLThGLUVDLTAwLUI1LTJGLDAwMDks MDBGRiwwMDAxKQpKdW4gMjQgMTA6NDE6NDMgZnJlZWJzZDkxIGtlcm5lbDogYWN0b3Iuc3RhdGU9 M2Y8QUNUSVZJVFksVElNRU9VVCxBR0dSRUdBVElPTixTWU5DLENPTExFQ1RJTkcsRElTVFJJQlVU SU5HPgpKdW4gMjQgMTA6NDE6NDMgZnJlZWJzZDkxIGtlcm5lbDogcGFydG5lcj0oODAwMCwwMC0x MC1CNS03Ri05Ny1GQiwwMTI2LDgwMDAsMDAwNCkKSnVuIDI0IDEwOjQxOjQzIGZyZWVic2Q5MSBr ZXJuZWw6IHBhcnRuZXIuc3RhdGU9MWQ8QUNUSVZJVFksQUdHUkVHQVRJT04sU1lOQyxDT0xMRUNU SU5HPgpKdW4gMjQgMTA6NDE6NDMgZnJlZWJzZDkxIGtlcm5lbDogbWF4ZGVsYXk9MApKdW4gMjQg MTA6NDE6NDMgZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBsYWNwX3NtX3J4X3VwZGF0ZV9zZWxlY3Rl ZApKdW4gMjQgMTA6NDE6NDMgZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBsYWNwX3NtX3J4X3VwZGF0 ZV9zZWxlY3RlZF9mcm9tX3BlZXJpbmZvCkp1biAyNCAxMDo0MTo0MyBmcmVlYnNkOTEga2VybmVs OiB4bDA6IGxhY3Bfc21fcnhfdXBkYXRlX250dApKdW4gMjQgMTA6NDE6NDMgZnJlZWJzZDkxIGtl cm5lbDogeGwwOiBsYWNwX3NtX3J4X3JlY29yZF9wZHUKSnVuIDI0IDEwOjQxOjQzIGZyZWVic2Q5 MSBrZXJuZWw6IHhsMDogb2xkIHBzdGF0ZSBjZjxBQ1RJVklUWSxUSU1FT1VULEFHR1JFR0FUSU9O LFNZTkMsREVGQVVMVEVELEVYUElSRUQ+Ckp1biAyNCAxMDo0MTo0MyBmcmVlYnNkOTEga2VybmVs OiB4bDA6IG5ldyBwc3RhdGUgM2Y8QUNUSVZJVFksVElNRU9VVCxBR0dSRUdBVElPTixTWU5DLENP TExFQ1RJTkcsRElTVFJJQlVUSU5HPgpKdW4gMjQgMTA6NDE6NDMgZnJlZWJzZDkxIGtlcm5lbDog cmwwOiBsYWNwX3NtX211eDogc3RhdGUgNApKdW4gMjQgMTA6NDE6NDMgZnJlZWJzZDkxIGtlcm5l bDogcmwxOiBsYWNwX3NtX211eDogc3RhdGUgNApKdW4gMjQgMTA6NDE6NDMgZnJlZWJzZDkxIGtl cm5lbDogeGwwOiBsYWNwX3NtX211eDogc3RhdGUgMwpKdW4gMjQgMTA6NDE6NDMgZnJlZWJzZDkx IGtlcm5lbDogeGwwOiBlbmFibGUgZGlzdHJpYnV0aW5nIG9uIGFnZ3JlZ2F0b3IgWyg4MDAwLDAw LTEwLUI1LTdGLTk3LUZCLDAxMjYsMDAwMCwwMDAwKSwoRkZGRixFMC04Ri1FQy0wMC1CNS0yRiww MDA5LDAwMDAsMDAwMCldLCBucG9ydHMgMCAtPiAxCkp1biAyNCAxMDo0MTo0MyBmcmVlYnNkOTEg a2VybmVsOiBsYWNwX3NlbGVjdF9hY3RpdmVfYWdncmVnYXRvcgpKdW4gMjQgMTA6NDE6NDMgZnJl ZWJzZDkxIGtlcm5lbDogWyg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYsMDAwMCwwMDAwKSwo RkZGRiwwMC0wMC0wMC0wMC0wMC0wMCwwMDAwLDAwMDAsMDAwMCldLCBzcGVlZD0yMDAwMDAwMDAs IG5wb3J0cz0yCkp1biAyNCAxMDo0MTo0MyBmcmVlYnNkOTEga2VybmVsOiBbKDgwMDAsMDAtMTAt QjUtN0YtOTctRkIsMDEyNiwwMDAwLDAwMDApLChGRkZGLEUwLThGLUVDLTAwLUI1LTJGLDAwMDks MDAwMCwwMDAwKV0sIHNwZWVkPTEwMDAwMDAwMCwgbnBvcnRzPTEKSnVuIDI0IDEwOjQxOjQzIGZy ZWVic2Q5MSBrZXJuZWw6IGFjdGl2ZSBhZ2dyZWdhdG9yIG5vdCBjaGFuZ2VkCkp1biAyNCAxMDo0 MTo0MyBmcmVlYnNkOTEga2VybmVsOiBuZXcgWyg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYs MDAwMCwwMDAwKSwoRkZGRiwwMC0wMC0wMC0wMC0wMC0wMCwwMDAwLDAwMDAsMDAwMCldCkp1biAy NCAxMDo0MTo0MyBmcmVlYnNkOTEga2VybmVsOiB4bDA6IG11eF9zdGF0ZSAzIC0+IDQKSnVuIDI0 IDEwOjQxOjQzIGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbGFjcGR1IHRyYW5zbWl0Ckp1biAyNCAx MDo0MTo0MyBmcmVlYnNkOTEga2VybmVsOiBhY3Rvcj0oODAwMCwwMC0xMC1CNS03Ri05Ny1GQiww MTI2LDgwMDAsMDAwNCkKSnVuIDI0IDEwOjQxOjQzIGZyZWVic2Q5MSBrZXJuZWw6IGFjdG9yLnN0 YXRlPTNkPEFDVElWSVRZLEFHR1JFR0FUSU9OLFNZTkMsQ09MTEVDVElORyxESVNUUklCVVRJTkc+ Ckp1biAyNCAxMDo0MTo0MyBmcmVlYnNkOTEga2VybmVsOiBwYXJ0bmVyPShGRkZGLEUwLThGLUVD LTAwLUI1LTJGLDAwMDksMDBGRiwwMDAxKQpKdW4gMjQgMTA6NDE6NDMgZnJlZWJzZDkxIGtlcm5l bDogcGFydG5lci5zdGF0ZT0zZjxBQ1RJVklUWSxUSU1FT1VULEFHR1JFR0FUSU9OLFNZTkMsQ09M TEVDVElORyxESVNUUklCVVRJTkc+Ckp1biAyNCAxMDo0MTo0MyBmcmVlYnNkOTEga2VybmVsOiBt YXhkZWxheT0wCkp1biAyNCAxMDo0MTo0NCBmcmVlYnNkOTEga2VybmVsOiBybDA6IGxhY3Bfc21f bXV4OiBzdGF0ZSA0Ckp1biAyNCAxMDo0MTo0NCBmcmVlYnNkOTEga2VybmVsOiBybDE6IGxhY3Bf c21fbXV4OiBzdGF0ZSA0Ckp1biAyNCAxMDo0MTo0NCBmcmVlYnNkOTEga2VybmVsOiB4bDA6IGxh Y3Bfc21fbXV4OiBzdGF0ZSA0Ckp1biAyNCAxMDo0MTo0NCBmcmVlYnNkOTEga2VybmVsOiB4bDA6 IGxhY3BkdSB0cmFuc21pdApKdW4gMjQgMTA6NDE6NDQgZnJlZWJzZDkxIGtlcm5lbDogYWN0b3I9 KDgwMDAsMDAtMTAtQjUtN0YtOTctRkIsMDEyNiw4MDAwLDAwMDQpCkp1biAyNCAxMDo0MTo0NCBm cmVlYnNkOTEga2VybmVsOiBhY3Rvci5zdGF0ZT0zZDxBQ1RJVklUWSxBR0dSRUdBVElPTixTWU5D LENPTExFQ1RJTkcsRElTVFJJQlVUSU5HPgpKdW4gMjQgMTA6NDE6NDQgZnJlZWJzZDkxIGtlcm5l bDogcGFydG5lcj0oRkZGRixFMC04Ri1FQy0wMC1CNS0yRiwwMDA5LDAwRkYsMDAwMSkKSnVuIDI0 IDEwOjQxOjQ0IGZyZWVic2Q5MSBrZXJuZWw6IHBhcnRuZXIuc3RhdGU9M2Y8QUNUSVZJVFksVElN RU9VVCxBR0dSRUdBVElPTixTWU5DLENPTExFQ1RJTkcsRElTVFJJQlVUSU5HPgpKdW4gMjQgMTA6 NDE6NDQgZnJlZWJzZDkxIGtlcm5lbDogbWF4ZGVsYXk9MApKdW4gMjQgMTA6NDE6NDUgZnJlZWJz ZDkxIGtlcm5lbDogbGFjcF90cmFuc2l0X2V4cGlyZQpKdW4gMjQgMTA6NDE6NDUgZnJlZWJzZDkx IGtlcm5lbDogcmwwOiBsYWNwX3NtX211eDogc3RhdGUgNApKdW4gMjQgMTA6NDE6NDUgZnJlZWJz ZDkxIGtlcm5lbDogcmwxOiBsYWNwX3NtX211eDogc3RhdGUgNApKdW4gMjQgMTA6NDE6NDUgZnJl ZWJzZDkxIGtlcm5lbDogeGwwOiBsYWNwX3NtX211eDogc3RhdGUgNApKdW4gMjQgMTA6NDE6NDUg ZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBsYWNwZHUgdHJhbnNtaXQKSnVuIDI0IDEwOjQxOjQ1IGZy ZWVic2Q5MSBrZXJuZWw6IGFjdG9yPSg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYsODAwMCww MDA0KQpKdW4gMjQgMTA6NDE6NDUgZnJlZWJzZDkxIGtlcm5lbDogYWN0b3Iuc3RhdGU9M2Q8QUNU SVZJVFksQUdHUkVHQVRJT04sU1lOQyxDT0xMRUNUSU5HLERJU1RSSUJVVElORz4KSnVuIDI0IDEw OjQxOjQ1IGZyZWVic2Q5MSBrZXJuZWw6IHBhcnRuZXI9KEZGRkYsRTAtOEYtRUMtMDAtQjUtMkYs MDAwOSwwMEZGLDAwMDEpCkp1biAyNCAxMDo0MTo0NSBmcmVlYnNkOTEga2VybmVsOiBwYXJ0bmVy LnN0YXRlPTNmPEFDVElWSVRZLFRJTUVPVVQsQUdHUkVHQVRJT04sU1lOQyxDT0xMRUNUSU5HLERJ U1RSSUJVVElORz4KSnVuIDI0IDEwOjQxOjQ1IGZyZWVic2Q5MSBrZXJuZWw6IG1heGRlbGF5PTAK SnVuIDI0IDEwOjQxOjQ2IGZyZWVic2Q5MSBrZXJuZWw6IHJsMDogbGFjcF9zbV9tdXg6IHN0YXRl IDQKSnVuIDI0IDEwOjQxOjQ2IGZyZWVic2Q5MSBrZXJuZWw6IHJsMTogbGFjcF9zbV9tdXg6IHN0 YXRlIDQKSnVuIDI0IDEwOjQxOjQ2IGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbGFjcF9zbV9tdXg6 IHN0YXRlIDQKSnVuIDI0IDEwOjQxOjQ2IGZyZWVic2Q5MSBrZXJuZWw6IHhsMDogbGFjcGR1IHRy YW5zbWl0Ckp1biAyNCAxMDo0MTo0NiBmcmVlYnNkOTEga2VybmVsOiBhY3Rvcj0oODAwMCwwMC0x MC1CNS03Ri05Ny1GQiwwMTI2LDgwMDAsMDAwNCkKSnVuIDI0IDEwOjQxOjQ2IGZyZWVic2Q5MSBr ZXJuZWw6IGFjdG9yLnN0YXRlPTNkPEFDVElWSVRZLEFHR1JFR0FUSU9OLFNZTkMsQ09MTEVDVElO RyxESVNUUklCVVRJTkc+Ckp1biAyNCAxMDo0MTo0NiBmcmVlYnNkOTEga2VybmVsOiBwYXJ0bmVy PShGRkZGLEUwLThGLUVDLTAwLUI1LTJGLDAwMDksMDBGRiwwMDAxKQpKdW4gMjQgMTA6NDE6NDYg ZnJlZWJzZDkxIGtlcm5lbDogcGFydG5lci5zdGF0ZT0zZjxBQ1RJVklUWSxUSU1FT1VULEFHR1JF R0FUSU9OLFNZTkMsQ09MTEVDVElORyxESVNUUklCVVRJTkc+Ckp1biAyNCAxMDo0MTo0NiBmcmVl YnNkOTEga2VybmVsOiBtYXhkZWxheT0wCkp1biAyNCAxMDo0MTo0NyBmcmVlYnNkOTEga2VybmVs OiBybDA6IGxhY3Bfc21fbXV4OiBzdGF0ZSA0Ckp1biAyNCAxMDo0MTo0NyBmcmVlYnNkOTEga2Vy bmVsOiBybDE6IGxhY3Bfc21fbXV4OiBzdGF0ZSA0Ckp1biAyNCAxMDo0MTo0NyBmcmVlYnNkOTEg a2VybmVsOiB4bDA6IGxhY3Bfc21fbXV4OiBzdGF0ZSA0Ckp1biAyNCAxMDo0MTo0NyBmcmVlYnNk OTEga2VybmVsOiB4bDA6IGxhY3BkdSB0cmFuc21pdApKdW4gMjQgMTA6NDE6NDcgZnJlZWJzZDkx IGtlcm5lbDogYWN0b3I9KDgwMDAsMDAtMTAtQjUtN0YtOTctRkIsMDEyNiw4MDAwLDAwMDQpCkp1 biAyNCAxMDo0MTo0NyBmcmVlYnNkOTEga2VybmVsOiBhY3Rvci5zdGF0ZT0zZDxBQ1RJVklUWSxB R0dSRUdBVElPTixTWU5DLENPTExFQ1RJTkcsRElTVFJJQlVUSU5HPgpKdW4gMjQgMTA6NDE6NDcg ZnJlZWJzZDkxIGtlcm5lbDogcGFydG5lcj0oRkZGRixFMC04Ri1FQy0wMC1CNS0yRiwwMDA5LDAw RkYsMDAwMSkKSnVuIDI0IDEwOjQxOjQ3IGZyZWVic2Q5MSBrZXJuZWw6IHBhcnRuZXIuc3RhdGU9 M2Y8QUNUSVZJVFksVElNRU9VVCxBR0dSRUdBVElPTixTWU5DLENPTExFQ1RJTkcsRElTVFJJQlVU SU5HPgpKdW4gMjQgMTA6NDE6NDcgZnJlZWJzZDkxIGtlcm5lbDogbWF4ZGVsYXk9MApKdW4gMjQg MTA6NDE6NDggZnJlZWJzZDkxIGtlcm5lbDogcmwwOiBsYWNwX3NtX211eDogc3RhdGUgNApKdW4g MjQgMTA6NDE6NDggZnJlZWJzZDkxIGtlcm5lbDogcmwxOiBsYWNwX3NtX211eDogc3RhdGUgNApK dW4gMjQgMTA6NDE6NDggZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBsYWNwX3NtX211eDogc3RhdGUg NApKdW4gMjQgMTA6NDE6NDggZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBsYWNwZHUgdHJhbnNtaXQK SnVuIDI0IDEwOjQxOjQ4IGZyZWVic2Q5MSBrZXJuZWw6IGFjdG9yPSg4MDAwLDAwLTEwLUI1LTdG LTk3LUZCLDAxMjYsODAwMCwwMDA0KQpKdW4gMjQgMTA6NDE6NDggZnJlZWJzZDkxIGtlcm5lbDog YWN0b3Iuc3RhdGU9M2Q8QUNUSVZJVFksQUdHUkVHQVRJT04sU1lOQyxDT0xMRUNUSU5HLERJU1RS SUJVVElORz4KSnVuIDI0IDEwOjQxOjQ4IGZyZWVic2Q5MSBrZXJuZWw6IHBhcnRuZXI9KEZGRkYs RTAtOEYtRUMtMDAtQjUtMkYsMDAwOSwwMEZGLDAwMDEpCkp1biAyNCAxMDo0MTo0OCBmcmVlYnNk OTEga2VybmVsOiBwYXJ0bmVyLnN0YXRlPTNmPEFDVElWSVRZLFRJTUVPVVQsQUdHUkVHQVRJT04s U1lOQyxDT0xMRUNUSU5HLERJU1RSSUJVVElORz4KSnVuIDI0IDEwOjQxOjQ4IGZyZWVic2Q5MSBr ZXJuZWw6IG1heGRlbGF5PTAKSnVuIDI0IDEwOjQxOjQ5IGZyZWVic2Q5MSBrZXJuZWw6IHJsMDog bGFjcF9zbV9tdXg6IHN0YXRlIDQKSnVuIDI0IDEwOjQxOjQ5IGZyZWVic2Q5MSBrZXJuZWw6IHJs MTogbGFjcF9zbV9tdXg6IHN0YXRlIDQKSnVuIDI0IDEwOjQxOjQ5IGZyZWVic2Q5MSBrZXJuZWw6 IHhsMDogbGFjcF9zbV9tdXg6IHN0YXRlIDQKSnVuIDI0IDEwOjQxOjQ5IGZyZWVic2Q5MSBrZXJu ZWw6IHhsMDogbGFjcGR1IHRyYW5zbWl0Ckp1biAyNCAxMDo0MTo0OSBmcmVlYnNkOTEga2VybmVs OiBhY3Rvcj0oODAwMCwwMC0xMC1CNS03Ri05Ny1GQiwwMTI2LDgwMDAsMDAwNCkKSnVuIDI0IDEw OjQxOjQ5IGZyZWVic2Q5MSBrZXJuZWw6IGFjdG9yLnN0YXRlPTNkPEFDVElWSVRZLEFHR1JFR0FU SU9OLFNZTkMsQ09MTEVDVElORyxESVNUUklCVVRJTkc+Ckp1biAyNCAxMDo0MTo0OSBmcmVlYnNk OTEga2VybmVsOiBwYXJ0bmVyPShGRkZGLEUwLThGLUVDLTAwLUI1LTJGLDAwMDksMDBGRiwwMDAx KQpKdW4gMjQgMTA6NDE6NDkgZnJlZWJzZDkxIGtlcm5lbDogcGFydG5lci5zdGF0ZT0zZjxBQ1RJ VklUWSxUSU1FT1VULEFHR1JFR0FUSU9OLFNZTkMsQ09MTEVDVElORyxESVNUUklCVVRJTkc+Ckp1 biAyNCAxMDo0MTo0OSBmcmVlYnNkOTEga2VybmVsOiBtYXhkZWxheT0wCkp1biAyNCAxMDo0MTo1 MCBmcmVlYnNkOTEga2VybmVsOiBybDA6IGxhY3Bfc21fbXV4OiBzdGF0ZSA0Ckp1biAyNCAxMDo0 MTo1MCBmcmVlYnNkOTEga2VybmVsOiBybDE6IGxhY3Bfc21fbXV4OiBzdGF0ZSA0Ckp1biAyNCAx MDo0MTo1MCBmcmVlYnNkOTEga2VybmVsOiB4bDA6IGxhY3Bfc21fbXV4OiBzdGF0ZSA0Ckp1biAy NCAxMDo0MTo1MCBmcmVlYnNkOTEga2VybmVsOiB4bDA6IGxhY3BkdSB0cmFuc21pdApKdW4gMjQg MTA6NDE6NTAgZnJlZWJzZDkxIGtlcm5lbDogYWN0b3I9KDgwMDAsMDAtMTAtQjUtN0YtOTctRkIs MDEyNiw4MDAwLDAwMDQpCkp1biAyNCAxMDo0MTo1MCBmcmVlYnNkOTEga2VybmVsOiBhY3Rvci5z dGF0ZT0zZDxBQ1RJVklUWSxBR0dSRUdBVElPTixTWU5DLENPTExFQ1RJTkcsRElTVFJJQlVUSU5H PgpKdW4gMjQgMTA6NDE6NTAgZnJlZWJzZDkxIGtlcm5lbDogcGFydG5lcj0oRkZGRixFMC04Ri1F Qy0wMC1CNS0yRiwwMDA5LDAwRkYsMDAwMSkKSnVuIDI0IDEwOjQxOjUwIGZyZWVic2Q5MSBrZXJu ZWw6IHBhcnRuZXIuc3RhdGU9M2Y8QUNUSVZJVFksVElNRU9VVCxBR0dSRUdBVElPTixTWU5DLENP TExFQ1RJTkcsRElTVFJJQlVUSU5HPgpKdW4gMjQgMTA6NDE6NTAgZnJlZWJzZDkxIGtlcm5lbDog bWF4ZGVsYXk9MApKdW4gMjQgMTA6NDE6NTEgZnJlZWJzZDkxIGtlcm5lbDogcmwwOiBsYWNwX3Nt X211eDogc3RhdGUgNApKdW4gMjQgMTA6NDE6NTEgZnJlZWJzZDkxIGtlcm5lbDogcmwxOiBsYWNw X3NtX211eDogc3RhdGUgNApKdW4gMjQgMTA6NDE6NTEgZnJlZWJzZDkxIGtlcm5lbDogeGwwOiBs YWNwX3NtX211eDogc3RhdGUgNApKdW4gMjQgMTA6NDE6NTEgZnJlZWJzZDkxIGtlcm5lbDogeGww OiBsYWNwZHUgdHJhbnNtaXQKSnVuIDI0IDEwOjQxOjUxIGZyZWVic2Q5MSBrZXJuZWw6IGFjdG9y PSg4MDAwLDAwLTEwLUI1LTdGLTk3LUZCLDAxMjYsODAwMCwwMDA0KQpKdW4gMjQgMTA6NDE6NTEg ZnJlZWJzZDkxIGtlcm5lbDogYWN0b3Iuc3RhdGU9M2Q8QUNUSVZJVFksQUdHUkVHQVRJT04sU1lO QyxDT0xMRUNUSU5HLERJU1RSSUJVVElORz4KSnVuIDI0IDEwOjQxOjUxIGZyZWVic2Q5MSBrZXJu ZWw6IHBhcnRuZXI9KEZGRkYsRTAtOEYtRUMtMDAtQjUtMkYsMDAwOSwwMEZGLDAwMDEpCkp1biAy NCAxMDo0MTo1MSBmcmVlYnNkOTEga2VybmVsOiBwYXJ0bmVyLnN0YXRlPTNmPEFDVElWSVRZLFRJ TUVPVVQsQUdHUkVHQVRJT04sU1lOQyxDT0xMRUNUSU5HLERJU1RSSUJVVElORz4KSnVuIDI0IDEw OjQxOjUxIGZyZWVic2Q5MSBrZXJuZWw6IG1heGRlbGF5PTAKCgoK --bcaec52c65ffaad33704dfe52f01 Content-Type: application/octet-stream; name="lacp-aggregator-select-skip-zero-partner.diff" Content-Disposition: attachment; filename="lacp-aggregator-select-skip-zero-partner.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hibl8wgx1 ZGlmZiAtLWdpdCBhL3N5cy9uZXQvaWVlZTgwMjNhZF9sYWNwLmMgYi9zeXMvbmV0L2llZWU4MDIz YWRfbGFjcC5jCmluZGV4IDcwZGU3NDMuLjUwNjAyMjMgMTAwNjQ0Ci0tLSBhL3N5cy9uZXQvaWVl ZTgwMjNhZF9sYWNwLmMKKysrIGIvc3lzL25ldC9pZWVlODAyM2FkX2xhY3AuYwpAQCAtOTQ3LDYg Kzk0Nyw3IEBAIGxhY3Bfc2VsZWN0X2FjdGl2ZV9hZ2dyZWdhdG9yKHN0cnVjdCBsYWNwX3NvZnRj ICpsc2MpCiAJc3RydWN0IGxhY3BfYWdncmVnYXRvciAqYmVzdF9sYSA9IE5VTEw7CiAJdWludDY0 X3QgYmVzdF9zcGVlZCA9IDA7CiAJY2hhciBidWZbTEFDUF9MQUdJRFNUUl9NQVgrMV07CisJdV9j aGFyIHplcm9fbWFjW10gPSB7IDAsIDAsIDAsIDAsIDAsIDAgfTsKIAogCUxBQ1BfVFJBQ0UoTlVM TCk7CiAKQEAgLTk1Nyw2ICs5NTgsMTMgQEAgbGFjcF9zZWxlY3RfYWN0aXZlX2FnZ3JlZ2F0b3Io c3RydWN0IGxhY3Bfc29mdGMgKmxzYykKIAkJCWNvbnRpbnVlOwogCQl9CiAKKwkJLyoKKwkJICog U2tpcCBhZ2dyZWdhdG9ycyB0aGF0IGhhcyBubyBwYXJ0bmVyLgorCQkgKi8KKwkJaWYgKCFtZW1j bXAoTEFDUF9TWVNfTUFDKGxhLT5sYV9wYXJ0bmVyKSwKKwkJICAgIHplcm9fbWFjLCBzaXplb2Yo emVyb19tYWMpKSkKKwkJCWNvbnRpbnVlOworCiAJCXNwZWVkID0gbGFjcF9hZ2dyZWdhdG9yX2Jh bmR3aWR0aChsYSk7CiAJCUxBQ1BfRFBSSU5URigoTlVMTCwgIiVzLCBzcGVlZD0lamQsIG5wb3J0 cz0lZFxuIiwKIAkJICAgIGxhY3BfZm9ybWF0X2xhZ2lkX2FnZ3JlZ2F0b3IobGEsIGJ1Ziwgc2l6 ZW9mKGJ1ZikpLApkaWZmIC0tZ2l0IGEvc3lzL25ldC9pZWVlODAyM2FkX2xhY3AuaCBiL3N5cy9u ZXQvaWVlZTgwMjNhZF9sYWNwLmgKaW5kZXggOTQ4MWNlMi4uNDA3NjUxMyAxMDA2NDQKLS0tIGEv c3lzL25ldC9pZWVlODAyM2FkX2xhY3AuaAorKysgYi9zeXMvbmV0L2llZWU4MDIzYWRfbGFjcC5o CkBAIC0yNjQsNiArMjY0LDcgQEAgc3RydWN0IGxhY3Bfc29mdGMgewogCSgoKChzMSkgXiAoczIp KSAmIChtYXNrKSkgPT0gMCkKIAogI2RlZmluZQlMQUNQX1NZU19QUkkocGVlcikJKHBlZXIpLmxp cF9zeXN0ZW1pZC5sc2lfcHJpbworI2RlZmluZSBMQUNQX1NZU19NQUMocGVlcikJKHBlZXIpLmxp cF9zeXN0ZW1pZC5sc2lfbWFjCiAKICNkZWZpbmUJTEFDUF9QT1JUKF9scCkJKChzdHJ1Y3QgbGFj cF9wb3J0ICopKF9scCktPmxwX3BzYykKICNkZWZpbmUJTEFDUF9TT0ZUQyhfc2MpCSgoc3RydWN0 IGxhY3Bfc29mdGMgKikoX3NjKS0+c2NfcHNjKQo= --bcaec52c65ffaad33704dfe52f01-- From owner-freebsd-net@FreeBSD.ORG Mon Jun 24 13:47:45 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DDCA3612; Mon, 24 Jun 2013 13:47:45 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B655318DE; Mon, 24 Jun 2013 13:47:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5ODljNo034772; Mon, 24 Jun 2013 13:47:45 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5ODljSZ034771; Mon, 24 Jun 2013 13:47:45 GMT (envelope-from linimon) Date: Mon, 24 Jun 2013 13:47:45 GMT Message-Id: <201306241347.r5ODljSZ034771@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/179926: [lacp] [patch] active aggregator selection bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 13:47:45 -0000 Old Synopsis: LACP: active aggregator selection bug New Synopsis: [lacp] [patch] active aggregator selection bug Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 24 13:47:10 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=179926 From owner-freebsd-net@FreeBSD.ORG Mon Jun 24 20:30:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A4B569C for ; Mon, 24 Jun 2013 20:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE861E57 for ; Mon, 24 Jun 2013 20:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5OKU1HL013390 for ; Mon, 24 Jun 2013 20:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5OKU1Eq013389; Mon, 24 Jun 2013 20:30:01 GMT (envelope-from gnats) Date: Mon, 24 Jun 2013 20:30:01 GMT Message-Id: <201306242030.r5OKU1Eq013389@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Mikolaj Golub Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mikolaj Golub List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 20:30:01 -0000 The following reply was made to PR kern/179901; it has been noted by GNATS. From: Mikolaj Golub To: bug-followup@FreeBSD.org, freebsd@grem.de Cc: Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Date: Mon, 24 Jun 2013 23:29:42 +0300 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Michael, Thank you for your analysis and the patch. I have the following notes to your patch though: 1) INET6 needs fixing too. 2) It looks like after introducing INP_REUSEADDR there is no need in handling the IN_MULTICAST case in ip_ctloutput(). 3) Actually you don't have to use IN_MULTICAST() in in_pcbbind_setup(): the information is already encoded in reuseport variable. 4) The patch not only fixes the regression introduced by r227207, but also changes the historical behavior before r227207. Although the change might be correct it is better to separate these issues. Feeling guilty for the regression introduced in r227207 I am eager to fix it ASAP, before 9.2 release. But I don't have strong opinion about changing the historical behavior. So, could you please look at the attached patch, which is based on your idea of INP_REUSEADDR flag? Now the code more resembles the code before r227207 in looks and I am a little more confident that there is no regression. I would appreciate any testing. Note, it is against CURRENT; STABLE will require patching in_pcb.h manually due to newly introduced INP_FREED flag. -- Mikolaj Golub --9amGYk9869ThD9tj Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="pr179901.1.patch" Index: sys/netinet/in_pcb.c =================================================================== --- sys/netinet/in_pcb.c (revision 252162) +++ sys/netinet/in_pcb.c (working copy) @@ -467,6 +467,23 @@ in_pcb_lport(struct inpcb *inp, struct in_addr *la return (0); } + +/* + * Return cached socket options. + */ +int +inp_so_options(const struct inpcb *inp) +{ + int so_options; + + so_options = 0; + + if ((inp->inp_flags2 & INP_REUSEPORT) != 0) + so_options |= SO_REUSEPORT; + if ((inp->inp_flags2 & INP_REUSEADDR) != 0) + so_options |= SO_REUSEADDR; + return (so_options); +} #endif /* INET || INET6 */ #ifdef INET @@ -595,8 +612,8 @@ in_pcbbind_setup(struct inpcb *inp, struct sockadd if (tw == NULL || (reuseport & tw->tw_so_options) == 0) return (EADDRINUSE); - } else if (t && (reuseport == 0 || - (t->inp_flags2 & INP_REUSEPORT) == 0)) { + } else if (t && + (reuseport & inp_so_options(t)) == 0) { #ifdef INET6 if (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || Index: sys/netinet/in_pcb.h =================================================================== --- sys/netinet/in_pcb.h (revision 252162) +++ sys/netinet/in_pcb.h (working copy) @@ -442,6 +442,7 @@ struct tcpcb * inp_inpcbtotcpcb(struct inpcb *inp); void inp_4tuple_get(struct inpcb *inp, uint32_t *laddr, uint16_t *lp, uint32_t *faddr, uint16_t *fp); +int inp_so_options(const struct inpcb *inp); #endif /* _KERNEL */ @@ -543,6 +544,7 @@ void inp_4tuple_get(struct inpcb *inp, uint32_t * #define INP_PCBGROUPWILD 0x00000004 /* in pcbgroup wildcard list */ #define INP_REUSEPORT 0x00000008 /* SO_REUSEPORT option is set */ #define INP_FREED 0x00000010 /* inp itself is not valid */ +#define INP_REUSEADDR 0x00000020 /* SO_REUSEADDR option is set */ /* * Flags passed to in_pcblookup*() functions. Index: sys/netinet/ip_output.c =================================================================== --- sys/netinet/ip_output.c (revision 252162) +++ sys/netinet/ip_output.c (working copy) @@ -900,13 +900,10 @@ ip_ctloutput(struct socket *so, struct sockopt *so switch (sopt->sopt_name) { case SO_REUSEADDR: INP_WLOCK(inp); - if (IN_MULTICAST(ntohl(inp->inp_laddr.s_addr))) { - if ((so->so_options & - (SO_REUSEADDR | SO_REUSEPORT)) != 0) - inp->inp_flags2 |= INP_REUSEPORT; - else - inp->inp_flags2 &= ~INP_REUSEPORT; - } + if ((so->so_options & SO_REUSEADDR) != 0) + inp->inp_flags2 |= INP_REUSEADDR; + else + inp->inp_flags2 &= ~INP_REUSEADDR; INP_WUNLOCK(inp); error = 0; break; Index: sys/netinet6/in6_pcb.c =================================================================== --- sys/netinet6/in6_pcb.c (revision 252162) +++ sys/netinet6/in6_pcb.c (working copy) @@ -265,8 +265,8 @@ in6_pcbbind(register struct inpcb *inp, struct soc INP_IPV6PROTO) == (t->inp_vflag & INP_IPV6PROTO)))) return (EADDRINUSE); - } else if (t && (reuseport == 0 || - (t->inp_flags2 & INP_REUSEPORT) == 0) && + } else if (t && + (reuseport & inp_so_options(t)) == 0 && (ntohl(t->inp_laddr.s_addr) != INADDR_ANY || (t->inp_vflag & INP_IPV6PROTO) != 0)) return (EADDRINUSE); Index: sys/netinet6/ip6_output.c =================================================================== --- sys/netinet6/ip6_output.c (revision 252162) +++ sys/netinet6/ip6_output.c (working copy) @@ -1477,13 +1477,10 @@ ip6_ctloutput(struct socket *so, struct sockopt *s switch (sopt->sopt_name) { case SO_REUSEADDR: INP_WLOCK(in6p); - if (IN_MULTICAST(ntohl(in6p->inp_laddr.s_addr))) { - if ((so->so_options & - (SO_REUSEADDR | SO_REUSEPORT)) != 0) - in6p->inp_flags2 |= INP_REUSEPORT; - else - in6p->inp_flags2 &= ~INP_REUSEPORT; - } + if ((so->so_options & SO_REUSEADDR) != 0) + in6p->inp_flags2 |= INP_REUSEADDR; + else + in6p->inp_flags2 &= ~INP_REUSEADDR; INP_WUNLOCK(in6p); error = 0; break; --9amGYk9869ThD9tj-- From owner-freebsd-net@FreeBSD.ORG Mon Jun 24 21:38:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 90CDA14C; Mon, 24 Jun 2013 21:38:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6C84F113F; Mon, 24 Jun 2013 21:38:58 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BA3B8B918; Mon, 24 Jun 2013 17:38:57 -0400 (EDT) From: John Baldwin To: "Mr. Clif" Subject: Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations Date: Mon, 24 Jun 2013 17:38:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305300113.r4U1DRGp089692@freefall.freebsd.org> <201305300929.31872.jhb@freebsd.org> <51B62547.5000207@eugeneweb.com> In-Reply-To: <51B62547.5000207@eugeneweb.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201306241738.47350.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 24 Jun 2013 17:38:57 -0400 (EDT) Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 21:38:58 -0000 On Monday, June 10, 2013 3:13:11 pm Mr. Clif wrote: > Hi John and Pyun, > > Ok got the new kernel installed and tested. Yes it works! :-) Maybe that > will also fix a simular problem with the sun cards (cas[03]), except I > don't see a define like that in if_cas.c. Suggestions? So I have a possible "real" fix for this. However, I do not have any hardware I can find that has a PCI-PCI bridge with the ISA-enable bit set. I know it compiles and boots fine on other systems. Can you please try this and capture the dmesg output? It would also be good to capture devinfo -u output before and after. http://www.freebsd.org/~jhb/patches/pci_isa_enable.patch -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jun 25 11:40:05 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C49D4304 for ; Tue, 25 Jun 2013 11:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9BE441458 for ; Tue, 25 Jun 2013 11:40:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5PBe461048649 for ; Tue, 25 Jun 2013 11:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5PBe4xe048648; Tue, 25 Jun 2013 11:40:04 GMT (envelope-from gnats) Date: Tue, 25 Jun 2013 11:40:04 GMT Message-Id: <201306251140.r5PBe4xe048648@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Michael Gmelin Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Michael Gmelin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 11:40:05 -0000 The following reply was made to PR kern/179901; it has been noted by GNATS. From: Michael Gmelin To: Mikolaj Golub Cc: bug-followup@FreeBSD.org Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Date: Tue, 25 Jun 2013 13:39:38 +0200 On Mon, 24 Jun 2013 23:29:42 +0300 Mikolaj Golub wrote: > Michael, Hi, > > Thank you for your analysis and the patch. > > I have the following notes to your patch though: > > 1) INET6 needs fixing too. Yes, but it seems like your patch is fixing the not all places in in6_pcb.c, I think you should modify the code at line 246 as well: } else if (t && (reuseport == 0 || (t->inp_flags2 & INP_REUSEPORT) == 0)) { return (EADDRINUSE); } so it says } else if (t && (reuseport & inp_so_options(t)) == 0) { Instead you're modifying the code at line 265 (which also seems to be affected, so it makes sense). > > 2) It looks like after introducing INP_REUSEADDR there is no need in > handling the IN_MULTICAST case in ip_ctloutput(). I think so too, in the end REUSEADDR and REUSEPORT are set independently now and REUSEADDR only gets its special meaning when being checked during binding. Therefore the code in ip_output should always do the right thing. > > 3) Actually you don't have to use IN_MULTICAST() in > in_pcbbind_setup(): the information is already encoded in reuseport > variable. That seems pretty implicit to me, but it also keeps the original logic more or less intact. Whatever works best for you I guess. > > 4) The patch not only fixes the regression introduced by r227207, but > also changes the historical behavior before r227207. Although the > change might be correct it is better to separate these issues. Feeling > guilty for the regression introduced in r227207 I am eager to fix it > ASAP, before 9.2 release. But I don't have strong opinion about > changing the historical behavior. I have a hard time believing anybody relied on the previous behaviour, so I wouldn't try to resemble it. > > So, could you please look at the attached patch, which is based on > your idea of INP_REUSEADDR flag? Now the code more resembles the code > before r227207 in looks and I am a little more confident that there is > no regression. > > I would appreciate any testing. Note, it is against CURRENT; STABLE > will require patching in_pcb.h manually due to newly introduced > INP_FREED flag. > Once 1) has been resolved I can test on a machine running 9.1-RELEASE later (the patch is small enough to apply it manually). I will run the "unit test" code from multicast.c I sent earlier and add IPv6 test cases to it as well. Cheers, Michael -- Michael Gmelin From owner-freebsd-net@FreeBSD.ORG Tue Jun 25 13:52:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0ADD86EC; Tue, 25 Jun 2013 13:52:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id DB3561C52; Tue, 25 Jun 2013 13:52:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 57E37B9BD; Tue, 25 Jun 2013 09:52:49 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: Failed to allocate receive buffer problem Date: Tue, 25 Jun 2013 09:38:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <64DAB3164E410447932305F50F896D8D6AF6E2C3@MTLDAG01.mtl.com> In-Reply-To: <64DAB3164E410447932305F50F896D8D6AF6E2C3@MTLDAG01.mtl.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201306250938.40137.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 25 Jun 2013 09:52:49 -0400 (EDT) Cc: Alex Liptsin , Oded Shanoon , Regev Lev , "freebsd-questions@freebsd.org" , "freebsd-infiniband@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 13:52:50 -0000 On Wednesday, June 12, 2013 3:06:26 am Alex Liptsin wrote: > Hi. > > I have a problem that when running a ping (or any other traffic) over IPoIB port, > Traffic fails after some time. > At destination server DMESG I see that errors: > > Jun 11 14:42:11 h-qa-033 kernel: ib1: failed to allocate receive buffer 253 > Jun 11 14:42:12 h-qa-033 kernel: ib1: failed to allocate receive buffer 254 > Jun 11 14:42:13 h-qa-033 kernel: ib1: failed to allocate receive buffer 255 > Jun 11 14:42:14 h-qa-033 kernel: ib1: failed to allocate receive buffer 0 > Jun 11 14:42:15 h-qa-033 kernel: ib1: failed to allocate receive buffer 1 > Jun 11 14:42:16 h-qa-033 kernel: ib1: failed to allocate receive buffer 2 > Jun 11 14:42:17 h-qa-033 kernel: ib1: failed to allocate receive buffer 3 > Jun 11 14:42:18 h-qa-033 kernel: ib1: failed to allocate receive buffer 4 > Jun 11 14:42:19 h-qa-033 kernel: ib1: failed to allocate receive buffer 5 > Jun 11 14:42:20 h-qa-033 kernel: ib1: failed to allocate receive buffer 6 > Jun 11 14:42:21 h-qa-033 kernel: ib1: failed to allocate receive buffer 7 > > I work with FreeBSD 9.1. > > Is it a bug or some configuration issues? Do you see memory allocation errors in netstat -m? Specifically this line: 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) If so, it may be that the IPoIB layer has an mbuf leak. The rest of netstat - m might be useful here as you can see if any of the zones are full. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jun 25 15:30:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 984AA93A for ; Tue, 25 Jun 2013 15:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7B7FC11FB for ; Tue, 25 Jun 2013 15:30:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5PFU22J095199 for ; Tue, 25 Jun 2013 15:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5PFU2fR095198; Tue, 25 Jun 2013 15:30:02 GMT (envelope-from gnats) Date: Tue, 25 Jun 2013 15:30:02 GMT Message-Id: <201306251530.r5PFU2fR095198@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Mikolaj Golub Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mikolaj Golub List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:30:02 -0000 The following reply was made to PR kern/179901; it has been noted by GNATS. From: Mikolaj Golub To: Michael Gmelin Cc: bug-followup@FreeBSD.org Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Date: Tue, 25 Jun 2013 18:24:55 +0300 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 25, 2013 at 01:39:38PM +0200, Michael Gmelin wrote: > Yes, but it seems like your patch is fixing the not all places in > in6_pcb.c, I think you should modify the code at line 246 as well: > > } else if (t && (reuseport == 0 || > (t->inp_flags2 & INP_REUSEPORT) == 0)) { > return (EADDRINUSE); > } > > so it says > } else if (t && > (reuseport & inp_so_options(t)) == 0) { > Good catch! I missed this because I was preparing the patch using r227207 as a reference, but this had been missed there too (fixed later in r233272 by glebius). > Once 1) has been resolved I can test on a machine running 9.1-RELEASE > later (the patch is small enough to apply it manually). I will run the > "unit test" code from multicast.c I sent earlier and add IPv6 test > cases to it as well. The updated patch is attached. Thanks. -- Mikolaj Golub --tThc/1wpZn/ma/RB Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="pr179901.2.patch" Index: sys/netinet/in_pcb.c =================================================================== --- sys/netinet/in_pcb.c (revision 251760) +++ sys/netinet/in_pcb.c (working copy) @@ -467,6 +467,23 @@ in_pcb_lport(struct inpcb *inp, struct in_addr *la return (0); } + +/* + * Return cached socket options. + */ +int +inp_so_options(const struct inpcb *inp) +{ + int so_options; + + so_options = 0; + + if ((inp->inp_flags2 & INP_REUSEPORT) != 0) + so_options |= SO_REUSEPORT; + if ((inp->inp_flags2 & INP_REUSEADDR) != 0) + so_options |= SO_REUSEADDR; + return (so_options); +} #endif /* INET || INET6 */ #ifdef INET @@ -595,8 +612,7 @@ in_pcbbind_setup(struct inpcb *inp, struct sockadd if (tw == NULL || (reuseport & tw->tw_so_options) == 0) return (EADDRINUSE); - } else if (t && (reuseport == 0 || - (t->inp_flags2 & INP_REUSEPORT) == 0)) { + } else if (t && (reuseport & inp_so_options(t)) == 0) { #ifdef INET6 if (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || Index: sys/netinet/in_pcb.h =================================================================== --- sys/netinet/in_pcb.h (revision 251760) +++ sys/netinet/in_pcb.h (working copy) @@ -442,6 +442,7 @@ struct tcpcb * inp_inpcbtotcpcb(struct inpcb *inp); void inp_4tuple_get(struct inpcb *inp, uint32_t *laddr, uint16_t *lp, uint32_t *faddr, uint16_t *fp); +int inp_so_options(const struct inpcb *inp); #endif /* _KERNEL */ @@ -543,6 +544,7 @@ void inp_4tuple_get(struct inpcb *inp, uint32_t * #define INP_PCBGROUPWILD 0x00000004 /* in pcbgroup wildcard list */ #define INP_REUSEPORT 0x00000008 /* SO_REUSEPORT option is set */ #define INP_FREED 0x00000010 /* inp itself is not valid */ +#define INP_REUSEADDR 0x00000020 /* SO_REUSEADDR option is set */ /* * Flags passed to in_pcblookup*() functions. Index: sys/netinet/ip_output.c =================================================================== --- sys/netinet/ip_output.c (revision 251760) +++ sys/netinet/ip_output.c (working copy) @@ -900,13 +900,10 @@ ip_ctloutput(struct socket *so, struct sockopt *so switch (sopt->sopt_name) { case SO_REUSEADDR: INP_WLOCK(inp); - if (IN_MULTICAST(ntohl(inp->inp_laddr.s_addr))) { - if ((so->so_options & - (SO_REUSEADDR | SO_REUSEPORT)) != 0) - inp->inp_flags2 |= INP_REUSEPORT; - else - inp->inp_flags2 &= ~INP_REUSEPORT; - } + if ((so->so_options & SO_REUSEADDR) != 0) + inp->inp_flags2 |= INP_REUSEADDR; + else + inp->inp_flags2 &= ~INP_REUSEADDR; INP_WUNLOCK(inp); error = 0; break; Index: sys/netinet6/in6_pcb.c =================================================================== --- sys/netinet6/in6_pcb.c (revision 251760) +++ sys/netinet6/in6_pcb.c (working copy) @@ -243,8 +243,7 @@ in6_pcbbind(register struct inpcb *inp, struct soc if (tw == NULL || (reuseport & tw->tw_so_options) == 0) return (EADDRINUSE); - } else if (t && (reuseport == 0 || - (t->inp_flags2 & INP_REUSEPORT) == 0)) { + } else if (t && (reuseport & inp_so_options(t)) == 0) { return (EADDRINUSE); } #ifdef INET @@ -265,8 +264,8 @@ in6_pcbbind(register struct inpcb *inp, struct soc INP_IPV6PROTO) == (t->inp_vflag & INP_IPV6PROTO)))) return (EADDRINUSE); - } else if (t && (reuseport == 0 || - (t->inp_flags2 & INP_REUSEPORT) == 0) && + } else if (t && + (reuseport & inp_so_options(t)) == 0 && (ntohl(t->inp_laddr.s_addr) != INADDR_ANY || (t->inp_vflag & INP_IPV6PROTO) != 0)) return (EADDRINUSE); Index: sys/netinet6/ip6_output.c =================================================================== --- sys/netinet6/ip6_output.c (revision 251760) +++ sys/netinet6/ip6_output.c (working copy) @@ -1477,13 +1477,10 @@ ip6_ctloutput(struct socket *so, struct sockopt *s switch (sopt->sopt_name) { case SO_REUSEADDR: INP_WLOCK(in6p); - if (IN_MULTICAST(ntohl(in6p->inp_laddr.s_addr))) { - if ((so->so_options & - (SO_REUSEADDR | SO_REUSEPORT)) != 0) - in6p->inp_flags2 |= INP_REUSEPORT; - else - in6p->inp_flags2 &= ~INP_REUSEPORT; - } + if ((so->so_options & SO_REUSEADDR) != 0) + in6p->inp_flags2 |= INP_REUSEADDR; + else + in6p->inp_flags2 &= ~INP_REUSEADDR; INP_WUNLOCK(in6p); error = 0; break; --tThc/1wpZn/ma/RB-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 26 04:43:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C73492F; Wed, 26 Jun 2013 04:43:34 +0000 (UTC) (envelope-from clif@eugeneweb.com) Received: from eugeneweb.com (eugeneweb.com [149.20.56.103]) by mx1.freebsd.org (Postfix) with ESMTP id 87C031D1F; Wed, 26 Jun 2013 04:43:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by eugeneweb.com (Postfix) with ESMTP id 23FEE22C08A; Tue, 25 Jun 2013 21:37:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at eugeneweb.com Received: from eugeneweb.com ([127.0.0.1]) by localhost (eugeneweb.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9UilbKBx0eS5; Tue, 25 Jun 2013 21:37:15 -0700 (PDT) Received: from [192.168.0.1] (unknown [71.193.185.189]) by eugeneweb.com (Postfix) with ESMTP id BAA3522C089; Tue, 25 Jun 2013 21:37:14 -0700 (PDT) Message-ID: <51CA6FF9.60805@eugeneweb.com> Date: Tue, 25 Jun 2013 21:37:13 -0700 From: "Mr. Clif" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.12) Gecko/20130119 Firefox/10.0.11esrpre Iceape/2.7.12 MIME-Version: 1.0 To: John Baldwin Subject: Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations References: <201305300113.r4U1DRGp089692@freefall.freebsd.org> <201305300929.31872.jhb@freebsd.org> <51B62547.5000207@eugeneweb.com> <201306241738.47350.jhb@freebsd.org> In-Reply-To: <201306241738.47350.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 04:43:34 -0000 Hi John, Thanks for working on this. I'm very interested in getting this fixed for everyone that uses the Affected Atom boards and other small format boards that work well in small custom routers. However right now I have a big network upgrade I'm working on and don't have time to get to it until late July, I'm hoping. So please forgive me for the long delay. Thanks for your help, Clif John Baldwin wrote: > On Monday, June 10, 2013 3:13:11 pm Mr. Clif wrote: >> Hi John and Pyun, >> >> Ok got the new kernel installed and tested. Yes it works! :-) Maybe that >> will also fix a simular problem with the sun cards (cas[03]), except I >> don't see a define like that in if_cas.c. Suggestions? > So I have a possible "real" fix for this. However, I do not have any hardware > I can find that has a PCI-PCI bridge with the ISA-enable bit set. I know it > compiles and boots fine on other systems. Can you please try this and capture > the dmesg output? It would also be good to capture devinfo -u output before > and after. > > http://www.freebsd.org/~jhb/patches/pci_isa_enable.patch > From owner-freebsd-net@FreeBSD.ORG Wed Jun 26 06:34:07 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C8363EB6; Wed, 26 Jun 2013 06:34:07 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A1FFD10F4; Wed, 26 Jun 2013 06:34:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5Q6Y7vm041737; Wed, 26 Jun 2013 06:34:07 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5Q6Y7oT041736; Wed, 26 Jun 2013 06:34:07 GMT (envelope-from linimon) Date: Wed, 26 Jun 2013 06:34:07 GMT Message-Id: <201306260634.r5Q6Y7oT041736@freefall.freebsd.org> To: anarcat@koumbit.org, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/179975: [igb] igb(4) fails to do polling(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 06:34:07 -0000 Old Synopsis: igb(4) fails to do polling(4) New Synopsis: [igb] igb(4) fails to do polling(4) State-Changed-From-To: open->patched State-Changed-By: linimon State-Changed-When: Wed Jun 26 06:32:48 UTC 2013 State-Changed-Why: apparently is already in 9-STABLE. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jun 26 06:32:48 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=179975 From owner-freebsd-net@FreeBSD.ORG Wed Jun 26 11:57:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 13578F52 for ; Wed, 26 Jun 2013 11:57:13 +0000 (UTC) (envelope-from alexl@mellanox.com) Received: from eu1sys200aog107.obsmtp.com (eu1sys200aog107.obsmtp.com [207.126.144.123]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0AF10A3 for ; Wed, 26 Jun 2013 11:57:11 +0000 (UTC) Received: from MTLCAS01.mtl.com ([193.47.165.155]) (using TLSv1) by eu1sys200aob107.postini.com ([207.126.147.11]) with SMTP ID DSNKUcrXAgcoC4JfuN22VjuDxOPwC5KVf2MX@postini.com; Wed, 26 Jun 2013 11:57:12 UTC Received: from MTLDAG01.mtl.com ([10.0.8.75]) by MTLCAS01.mtl.com ([10.0.8.71]) with mapi id 14.03.0123.003; Wed, 26 Jun 2013 14:54:27 +0300 From: Alex Liptsin To: "freebsd-net@freebsd.org" , "freebsd-questions@freebsd.org." Subject: FreeBSD:: How to set VLAN priority? Thread-Topic: FreeBSD:: How to set VLAN priority? Thread-Index: Ac5yY851fAktQa4dRZ6+YoHKySZzzg== Date: Wed, 26 Jun 2013 11:54:27 +0000 Message-ID: <64DAB3164E410447932305F50F896D8D6AF863BE@MTLDAG01.mtl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.13.1] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Oded Shanoon , Regev Lev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 11:57:13 -0000 Hello. I work with FreeBSD 9.1 RELEASE. I had configured VLANs on my server, but I can't find a way to configure VL= AN priority. How can I do it? Thanks. Regards, Alex Liptsin Software Quality Assurance Engineer | Mellanox Technologies Ltd. Office: +972 (74) 7236141 Mobile: +972(54) 7833986 Fax: +972(74) 7236161 Email: alexl@mellanox.com Mellanox, Tel-Hai Industrial Park. Building 7, M.P. Upper Galilee 12100 Isr= ael From owner-freebsd-net@FreeBSD.ORG Wed Jun 26 13:10:04 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5223C860 for ; Wed, 26 Jun 2013 13:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 336D116BA for ; Wed, 26 Jun 2013 13:10:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5QDA3M7018828 for ; Wed, 26 Jun 2013 13:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5QDA3kS018825; Wed, 26 Jun 2013 13:10:03 GMT (envelope-from gnats) Date: Wed, 26 Jun 2013 13:10:03 GMT Message-Id: <201306261310.r5QDA3kS018825@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Michael Gmelin Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Michael Gmelin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:10:04 -0000 The following reply was made to PR kern/179901; it has been noted by GNATS. From: Michael Gmelin To: Mikolaj Golub Cc: bug-followup@FreeBSD.org Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Date: Wed, 26 Jun 2013 15:03:40 +0200 On Tue, 25 Jun 2013 18:24:55 +0300 Mikolaj Golub wrote: > On Tue, Jun 25, 2013 at 01:39:38PM +0200, Michael Gmelin wrote: > > > Yes, but it seems like your patch is fixing the not all places in > > in6_pcb.c, I think you should modify the code at line 246 as well: > > > > } else if (t && (reuseport == 0 || > > (t->inp_flags2 & INP_REUSEPORT) == 0)) { > > return (EADDRINUSE); > > } > > > > so it says > > } else if (t && > > (reuseport & inp_so_options(t)) == 0) { > > > > Good catch! I missed this because I was preparing the patch using > r227207 as a reference, but this had been missed there too (fixed > later in r233272 by glebius). > > > Once 1) has been resolved I can test on a machine running > > 9.1-RELEASE later (the patch is small enough to apply it manually). > > I will run the "unit test" code from multicast.c I sent earlier and > > add IPv6 test cases to it as well. > > The updated patch is attached. Thanks. > Hi, I adapted the test code, you can find it at http://blog.grem.de/multicast.c Test output is: IPv4 Port 5555: Bind using SO_REUSEADDR.......OK (expected) Bind using SO_REUSEADDR.......OK (expected) Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in use IPv4 Port 5556: Bind using SO_REUSEPORT.......OK (expected) Bind using SO_REUSEPORT.......OK (expected) Bind using SO_REUSEADDR.......OK (expected) Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in use IPv4 Port 5557: Bind using SO_REUSEADDR x 2...OK (expected) Bind using SO_REUSEADDR x 2...OK (expected) Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in use Bind using SO_REUSEADDR.......OK (expected) Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in use IPv4 Port 5558: Bind without socketopts.......OK (expected) Bind using SO_REUSEADDR.......FAIL (expected): Address already in use Bind using SO_REUSEPORT.......FAIL (expected): Address already in use IPv4 Port 5559: Bind using SO_REUSEADDR.......OK (expected) Bind without socketopts.......FAIL (expected): Address already in use IPv4 Port 5560: Bind using SO_REUSEPORT.......OK (expected) Bind using SO_REUSEPORT.......OK (expected) Bind without socketopts.......FAIL (expected): Address already in use IPv6 Port 5555: Bind using SO_REUSEADDR.......OK (expected) Bind using SO_REUSEADDR.......OK (expected) Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in use IPv6 Port 5556: Bind using SO_REUSEPORT.......OK (expected) Bind using SO_REUSEPORT.......OK (expected) Bind using SO_REUSEADDR.......OK (expected) Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in use IPv6 Port 5557: Bind using SO_REUSEADDR x 2...OK (expected) Bind using SO_REUSEADDR x 2...OK (expected) Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in use Bind using SO_REUSEADDR.......OK (expected) Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in use IPv6 Port 5558: Bind without socketopts.......OK (expected) Bind using SO_REUSEADDR.......FAIL (expected): Address already in use Bind using SO_REUSEPORT.......FAIL (expected): Address already in use IPv6 Port 5559: Bind using SO_REUSEADDR.......OK (expected) Bind without socketopts.......FAIL (expected): Address already in use IPv6 Port 5560: Bind using SO_REUSEPORT.......OK (expected) Bind using SO_REUSEPORT.......OK (expected) Bind without socketopts.......FAIL (expected): Address already in use So you maintained the old PORT/ADDR behavior, which I think is not such a great idea. I would suggest to get another opinion on this, just because it's broken now doesn't mean we have to perpetuate it - maybe we should compare the behavior with other Unix(like) OSes like the other BSDs and Linux to see how their implementations work - usually ported software is not changed in that respect, so being compatible is valuable. Besides my rant the code works as designed and seems to resemble the behavior before r227207 correctly (I manually applied the patches to 9.1-RELEASE). Fun fact: The code in ip6_output.c could have never worked in the first place, since it used IN_MULTICAST instead of IN6_IS_ADDR_MULTICAST: if (IN_MULTICAST(ntohl(in6p->inp_laddr.s_addr))) ... Cheers, Michael -- Michael Gmelin From owner-freebsd-net@FreeBSD.ORG Wed Jun 26 16:27:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4BADC860; Wed, 26 Jun 2013 16:27:50 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 23BEA1E96; Wed, 26 Jun 2013 16:27:49 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r5QGRmTF048702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 09:27:48 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r5QGRmNF048701; Wed, 26 Jun 2013 09:27:48 -0700 (PDT) (envelope-from jmg) Date: Wed, 26 Jun 2013 09:27:48 -0700 From: John-Mark Gurney To: Alex Liptsin Subject: Re: FreeBSD:: How to set VLAN priority? Message-ID: <20130626162748.GG26412@funkthat.com> Mail-Followup-To: Alex Liptsin , "freebsd-net@freebsd.org" , "freebsd-questions@freebsd.org." , Oded Shanoon , Regev Lev References: <64DAB3164E410447932305F50F896D8D6AF863BE@MTLDAG01.mtl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64DAB3164E410447932305F50F896D8D6AF863BE@MTLDAG01.mtl.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 26 Jun 2013 09:27:48 -0700 (PDT) Cc: "freebsd-net@freebsd.org" , Oded Shanoon , "freebsd-questions@freebsd.org." , Regev Lev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 16:27:50 -0000 Alex Liptsin wrote this message on Wed, Jun 26, 2013 at 11:54 +0000: > I work with FreeBSD 9.1 RELEASE. > I had configured VLANs on my server, but I can't find a way to configure VLAN priority. > How can I do it? Looks like you can't w/ the default VLAN code: BUGS No 802.1Q features except VLAN tagging are implemented. You could probably implement it w/ ng_patch, but that would also mean you'd lose the feature of the card adding the VLAN tag for you... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Wed Jun 26 21:00:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7C3AF2A0; Wed, 26 Jun 2013 21:00:00 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 2EEB61C9C; Wed, 26 Jun 2013 21:00:00 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id i13so1969044qae.13 for ; Wed, 26 Jun 2013 13:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=yQek+ZG7sTQA4wAGW00mabgso39lrDEwxfyK3tk0Q70=; b=yYCmxewENPCiyC1l18kTLVZAEhaJuh7ROo/o3mWcW+QxNKxvocQcwqQL+oZLukglh7 /nUEMPy6l5Qi97uK7+gZSEOwzUOqRC7sQ1UMbR2VBgXRDstZadp9Y7I4Kbvd/ozfIjGw +RDFd93dIiQ2ZfXH8Mp5Jm4NMwuEsyGwtCeUnlaVs/PkTkSSDjOQY4uG/JPP1ZmFhE8H i+l9LZtFTCWhLnmOK1EwCBNcbZrPucC47TYijb51ZDQZMkxY70UxvhcIVoLakrQ5mUF6 iLWS3QY7msTTeYBwo4t8Xlj9TWWyydGwDjYBEt5BTl9Du5dngx54DtSi/bGiob10ktLR cauQ== MIME-Version: 1.0 X-Received: by 10.224.25.76 with SMTP id y12mr7941245qab.45.1372280399777; Wed, 26 Jun 2013 13:59:59 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.36.41 with HTTP; Wed, 26 Jun 2013 13:59:59 -0700 (PDT) In-Reply-To: <20130626162748.GG26412@funkthat.com> References: <64DAB3164E410447932305F50F896D8D6AF863BE@MTLDAG01.mtl.com> <20130626162748.GG26412@funkthat.com> Date: Wed, 26 Jun 2013 22:59:59 +0200 X-Google-Sender-Auth: ZLP2Ib9xFlCiWgQG6jMqz7l1rro Message-ID: Subject: Re: FreeBSD:: How to set VLAN priority? From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Alex Liptsin , "freebsd-net@freebsd.org" , "freebsd-questions@freebsd.org." , Oded Shanoon , Regev Lev Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:00:00 -0000 This is a patch originially written from rwatson@ iirc. https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/pf_802.1p.diff Remove the pf(4) craft and it should work for you. On Wed, Jun 26, 2013 at 6:27 PM, John-Mark Gurney wrote: > Alex Liptsin wrote this message on Wed, Jun 26, 2013 at 11:54 +0000: > > I work with FreeBSD 9.1 RELEASE. > > I had configured VLANs on my server, but I can't find a way to configure > VLAN priority. > > How can I do it? > > Looks like you can't w/ the default VLAN code: > BUGS > No 802.1Q features except VLAN tagging are implemented. > > You could probably implement it w/ ng_patch, but that would also mean > you'd lose the feature of the card adding the VLAN tag for you... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Wed Jun 26 22:39:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3897946A for ; Wed, 26 Jun 2013 22:39:44 +0000 (UTC) (envelope-from syuu@dokukino.com) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 15733112B for ; Wed, 26 Jun 2013 22:39:44 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kx10so178337pab.27 for ; Wed, 26 Jun 2013 15:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dokukino.com; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=Ff0oSXsUUQPjHgJ+1TsJYXSekjyNHxMxg+5IzvdwKuQ=; b=BQOFk4/8Fm6Ygs7um2/80xoBsyc/8pHmduyLXyoz2IEVHyXBJ5QJKRX1rH65YjvidG H98pEh9Kr4MQAMaP2piRIFU/RvrOPNfhj2CDM2qH3/1N3Pk5fEWWlO0je/zqIX9wW20I jgmIbetWNETy+DpdFN/nHnMOaRCEj14vSRd0I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=Ff0oSXsUUQPjHgJ+1TsJYXSekjyNHxMxg+5IzvdwKuQ=; b=b66RKaBX9/LOUxGjFdDKBDrSFJndsum5ctOrW9/jvrTtfgIUf3uwDjnABItGys8qgn LFP75UfVKZo28SLd9dg4YTdOSfPyjONJnVIMf2dgWC7tdZYWmuwA7F9Bg2ciqriFPAlg VKjgon6E107lVJ98rCHTEYR2F04eJrYHytIZJXoFQTmN62cqDG2jor0/kz2ursvhjjUd EbMPf/YLWSCxVzjXuZEc8uvYWJsF69pzRCH6Eudfb97dk/2RMJMH80oK14wlKX89I824 rF8EuYsEwMYgAd4HzW5svpVt1xBPWpDMJH2Mkhgxdb1uIgsEnqY2LK2p6fU1bjWMyhai 44CA== X-Received: by 10.68.192.103 with SMTP id hf7mr2905313pbc.168.1372286383819; Wed, 26 Jun 2013 15:39:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.222.34 with HTTP; Wed, 26 Jun 2013 15:39:03 -0700 (PDT) From: Takuya ASADA Date: Thu, 27 Jun 2013 07:39:03 +0900 Message-ID: Subject: Comparing Mutiqueue Support Linux vs FreeBSD To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQkfBWhsc57EUqvJ2dUuOq7CoDxpn2tj30z7QilIOFzgNvkNUfRwu3HHWSMS9WF3eDN1CXi+ Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 22:39:44 -0000 Hi, Because there was an discussion about new APIs to provide better support for high performance NICs in Ottawa DevSummit BoF, I wrote a note about "How Linux doing it" in that area. I haven't get a enough chance to talk about it in the summit, but I decided to upload the note on a Wiki. Here's a link: https://wiki.freebsd.org/201305DevSummit/NetworkReceivePerformance/ComparingMutiqueueSupportLinuxvsFreeBSD I hope it helps to decide what kind of interfaces/features do we need on FreeBSD. Takuya ASADA From owner-freebsd-net@FreeBSD.ORG Wed Jun 26 22:58:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D98EC14C for ; Wed, 26 Jun 2013 22:58:21 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id A9CAE1286 for ; Wed, 26 Jun 2013 22:58:21 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id eh20so41816obb.39 for ; Wed, 26 Jun 2013 15:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZS5qlZYPvgYKwPNVz3s0ur3Hafrf0FAhjWSH5bQUZwk=; b=N4oGtzFQ5q+6nxbNmMtribtbVCiNbW12iK3ctXKipD2rSdwRVXEONebTvymQlzz8tM 0maLU2BX6/vJ97swoezlevm2kK29Y9Cn0n02SerfpQz3tvJymF4nblcWBkmSSb93BAdo tjJQZ71vrF/1dQUZk9ex9gHVm84wgdciFSepSwUWIkcNCiJkKWR1EwkzQktE/5zY6gUd LeXvAn+Hb0Ce3oRL7Anb0x1MAW+TQadMK8A+cUY0PvC3hA9YUy+I4/TfIbu75RT04NKm yotzuRt9egGnYHrf45FSw+IEHO6o4pxHjMUxn+RqjgKv5nSp3vfa12hBVKcLijvErK+I 7JLw== MIME-Version: 1.0 X-Received: by 10.60.133.14 with SMTP id oy14mr1595046oeb.84.1372287501304; Wed, 26 Jun 2013 15:58:21 -0700 (PDT) Received: by 10.182.115.194 with HTTP; Wed, 26 Jun 2013 15:58:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Jun 2013 18:58:21 -0400 Message-ID: Subject: Re: Comparing Mutiqueue Support Linux vs FreeBSD From: Super Bisquit To: Takuya ASADA Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 22:58:21 -0000 If someone ports the ethtool to FreeBSD, it will only work on the i386/AMD64/ PC98 architectures. Perhaps having these suggestions as options for the kernel/GENERIC conf files would be better? On Wed, Jun 26, 2013 at 6:39 PM, Takuya ASADA wrote: > Hi, > > Because there was an discussion about new APIs to provide better support > for high performance NICs in Ottawa DevSummit BoF, I wrote a note about > "How Linux doing it" in that area. > > I haven't get a enough chance to talk about it in the summit, but I decided > to upload the note on a Wiki. > > Here's a link: > > https://wiki.freebsd.org/201305DevSummit/NetworkReceivePerformance/ComparingMutiqueueSupportLinuxvsFreeBSD > > I hope it helps to decide what kind of interfaces/features do we need on > FreeBSD. > > Takuya ASADA > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Jun 26 23:10:45 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A42BFA6E; Wed, 26 Jun 2013 23:10:45 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7F86E13BD; Wed, 26 Jun 2013 23:10:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5QNAjj6042808; Wed, 26 Jun 2013 23:10:45 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5QNAjii042807; Wed, 26 Jun 2013 23:10:45 GMT (envelope-from linimon) Date: Wed, 26 Jun 2013 23:10:45 GMT Message-Id: <201306262310.r5QNAjii042807@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/179999: [ofed] [patch] Bug assigning HCA from IB to ETH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 23:10:45 -0000 Old Synopsis: Bug assigning HCA from IB to ETH New Synopsis: [ofed] [patch] Bug assigning HCA from IB to ETH Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jun 26 23:10:19 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=179999 From owner-freebsd-net@FreeBSD.ORG Thu Jun 27 00:02:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1D4DF6C2 for ; Thu, 27 Jun 2013 00:02:05 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id D553E17C2 for ; Thu, 27 Jun 2013 00:02:04 +0000 (UTC) Received: by mail-vb0-f43.google.com with SMTP id e12so84590vbg.16 for ; Wed, 26 Jun 2013 17:02:04 -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=BIJBxvmoLt1wAPSg+Lyn9HZKBcPJH3aZvmSyyAsHUf0=; b=qkqVB2dzYE7ra2YYZnQ37y82aOvvfy6MVSxkJAXyNpvDwM7jHhkztkt+4ZHhanvLXV Kunj0mGT4pLMJXObkfHo17T36UYe+7VDzyYUxcM3UmQnwpd+s3+51VctW/HCpnPkzzP+ og+QTNFzvzV+Y5IFw8Pu34adLAe45dEwZte3IUTXHM4QoeX025C1zV4qUMfzMczfV8xd IE0upuoL/o9b1tK0a9hNX8A+4F95jwGUbd/MEL0HcPJAdfJI0wSBE9dDghWDl/TdGRGK Du5FI//Lh9oNOuEGUWW5zp1SZ27A/MpYA1nzzLzSfs9/XVDBwMX8FqkJcdmWpgpjdRTo oLug== MIME-Version: 1.0 X-Received: by 10.58.97.238 with SMTP id ed14mr2595797veb.34.1372291324459; Wed, 26 Jun 2013 17:02:04 -0700 (PDT) Received: by 10.220.52.200 with HTTP; Wed, 26 Jun 2013 17:02:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Jun 2013 17:02:04 -0700 Message-ID: Subject: Re: Comparing Mutiqueue Support Linux vs FreeBSD From: Jack Vogel To: Super Bisquit Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Takuya ASADA , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 00:02:05 -0000 ethtool is GPL so I wouldn't expect it to show up around here :) Implementing something like it for FreeBSD would be cool however, sometimes sysctl just seems clunky although its usually how i cope with driver things that might be changed via ethtool in Linux. Having to completely rebuild a kernel for controlling RSS seems horribly clunky on the other hand. On Wed, Jun 26, 2013 at 3:58 PM, Super Bisquit wrote: > If someone ports the ethtool to FreeBSD, it will only work on the > i386/AMD64/ PC98 architectures. > Perhaps having these suggestions as options for the kernel/GENERIC conf > files would be better? > > > On Wed, Jun 26, 2013 at 6:39 PM, Takuya ASADA wrote: > > > Hi, > > > > Because there was an discussion about new APIs to provide better support > > for high performance NICs in Ottawa DevSummit BoF, I wrote a note about > > "How Linux doing it" in that area. > > > > I haven't get a enough chance to talk about it in the summit, but I > decided > > to upload the note on a Wiki. > > > > Here's a link: > > > > > https://wiki.freebsd.org/201305DevSummit/NetworkReceivePerformance/ComparingMutiqueueSupportLinuxvsFreeBSD > > > > I hope it helps to decide what kind of interfaces/features do we need on > > FreeBSD. > > > > Takuya ASADA > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Jun 27 02:36:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 85D4EA2B for ; Thu, 27 Jun 2013 02:36:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 4A3041E3F for ; Thu, 27 Jun 2013 02:36:07 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id 1so64508qec.20 for ; Wed, 26 Jun 2013 19:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/YbOhBZGWisFz8BeSli8JIzfqMSwJ4N1dEbq3e6yHvc=; b=iRq8aMPRr97mbubSeb+BU/SCUmXc+O45QRKuOgpGicKHOaWndn5nubD6DimjXlQrUD fB0dy8/xHrGQRc2AcQPaHlcUwHUsI8+c6wkSwa11VyR8pNa67Tnq+b2dVFDufAPYuHTX QKTU+V+MRDNFrLUA/0pENhfq39Pg57Qf+MZ7b410kVj4mhogdQBLgfUUxbkcqcSePZ0v JR1wJmyMTET1cw6c5V5d6wVotAPxGrLJfaBit2j7hlNPkyp4dz6xPDQxByveoQGpLe2+ OammbJAJ8jh1cQ0t/O12COpmuc1ZrD/KgHToiSEpzPJoyFZtdikAzeN2ZOk7hsIpZtxs mFZA== MIME-Version: 1.0 X-Received: by 10.49.14.161 with SMTP id q1mr8231114qec.50.1372300566706; Wed, 26 Jun 2013 19:36:06 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.214.7 with HTTP; Wed, 26 Jun 2013 19:36:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Jun 2013 19:36:06 -0700 X-Google-Sender-Auth: dtmIx8mnFuPrNBaazGUIyiVYWE0 Message-ID: Subject: Re: Comparing Mutiqueue Support Linux vs FreeBSD From: Adrian Chadd To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Takuya ASADA , Super Bisquit , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 02:36:07 -0000 ethtool is just a passthrough. The drivers need to implement all of those hooks. It wouldn't be that hard to reimplement. The drivers would have to reimplement it anyway - they'd have to implement the generic set of standard statistics, then export driver-specific things. You know, the stuff our drivers already expose via sysctl. adrian On 26 June 2013 17:02, Jack Vogel wrote: > ethtool is GPL so I wouldn't expect it to show up around here :) > > Implementing something like it for FreeBSD would be cool however, sometimes > sysctl just > seems clunky although its usually how i cope with driver things that might > be changed via > ethtool in Linux. Having to completely rebuild a kernel for controlling RSS > seems horribly > clunky on the other hand. > > > > On Wed, Jun 26, 2013 at 3:58 PM, Super Bisquit wrote: > >> If someone ports the ethtool to FreeBSD, it will only work on the >> i386/AMD64/ PC98 architectures. >> Perhaps having these suggestions as options for the kernel/GENERIC conf >> files would be better? >> >> >> On Wed, Jun 26, 2013 at 6:39 PM, Takuya ASADA wrote: >> >> > Hi, >> > >> > Because there was an discussion about new APIs to provide better support >> > for high performance NICs in Ottawa DevSummit BoF, I wrote a note about >> > "How Linux doing it" in that area. >> > >> > I haven't get a enough chance to talk about it in the summit, but I >> decided >> > to upload the note on a Wiki. >> > >> > Here's a link: >> > >> > >> https://wiki.freebsd.org/201305DevSummit/NetworkReceivePerformance/ComparingMutiqueueSupportLinuxvsFreeBSD >> > >> > I hope it helps to decide what kind of interfaces/features do we need on >> > FreeBSD. >> > >> > Takuya ASADA >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jun 27 04:35:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0854CBE1 for ; Thu, 27 Jun 2013 04:35:54 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by mx1.freebsd.org (Postfix) with ESMTP id 971681687 for ; Thu, 27 Jun 2013 04:35:53 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id n11so181168wgh.9 for ; Wed, 26 Jun 2013 21:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=xPe1mIrzWj1BAff3srKgscuT2t4c/Avxzv8BC3/fX+k=; b=V8xuA7m4ArZl1cEfxpPtm8dPC7WIn4NGiXKp8rW1ErXjwa0xTtHvD2scTlOCAmalS6 fsHhRVvRAgabj0DRkc1pHDGn+IBnqvsKtDmG8A7+HX9kI4Z4fJJRWU/DMVchqxuJSydn Q6ANWj0dCmZPhYytaFE+5Y4LTSQa8KHHq96qogmwac9bdKpvGQnX4xX+IVjOFv4pzabT wT16rJHz8Y7rq6zFZUkj81mmItwuW1eKsD7+a0CY9J7fhLWGiKS78sLO7OA3cIfNzs4n HyUUx+9whQuUV/PwzUm+EX/4kKDF3TB5elsoV+JDO2bclLevYPmo5BR9LKmhaZj9G2n4 2zzA== X-Received: by 10.180.105.231 with SMTP id gp7mr247716wib.23.1372307752165; Wed, 26 Jun 2013 21:35:52 -0700 (PDT) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.22.195 with HTTP; Wed, 26 Jun 2013 21:35:32 -0700 (PDT) In-Reply-To: References: From: h bagade Date: Thu, 27 Jun 2013 09:05:32 +0430 X-Google-Sender-Auth: PWJcENHJ7fmrEcVFxh-wyW43Wb8 Message-ID: Subject: Re: probable side effects of deleting interfaces ip addresses(loopback ones) from routing table ! To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 04:35:54 -0000 On Sat, Jun 22, 2013 at 12:25 PM, h bagade wrote: > Hi all, > > I've deleted the interface ip address from routing table and only keep the > network address. Nothing is behaving unusual afterwards. I think this > loopback ip address is added for better performance. My question is would I > get in to trouble by deleting these ip addresses from routing table or > it's, as I think, just a matter of performance? > > Thanks in advance > I've done further tests after deleting loopback ip addresses and my system works correctly without any side effects! Is that really OK with deleting these ip addresses? From owner-freebsd-net@FreeBSD.ORG Thu Jun 27 06:31:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 136321C9 for ; Thu, 27 Jun 2013 06:31:22 +0000 (UTC) (envelope-from voxadam@gmail.com) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 92DC81C5E for ; Thu, 27 Jun 2013 06:31:21 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id fs12so362043lab.26 for ; Wed, 26 Jun 2013 23:31:20 -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=ayE9Sf5ChEkf8B4/K3A3WUsvo7+ykv3KbmZUnc87x0s=; b=CikufcXtIp0+CjUdIR1gQdMSgWFPJaSCC0oXJkUWBFfhS35xib/65KtzRH/MrrYekj kFu27cwBxCG5Sl/NeDMx1UW5ijHfGI0mZjAoae+W34coKaEzkG2m1EwM5Pn3NXxQzO04 LkhaC52IPfD++cc9N201k9GXcDeuXKHNzYU990MsoHQ6zxs1c3q2inc008Ayj0+FSKR0 8yl2AGhijHdT+GhOPljesXamVNkckJdZeoqdMaD72F6H2UdajtYDBHtgOwPz+RxoDsd5 N4WBkT0k9bCheKcVhLsjxom4vvgQ4xWTSzV/TESpfRWHKaOwwJVrbYSagovJPZzBhwc4 FhmQ== X-Received: by 10.152.23.99 with SMTP id l3mr3382157laf.82.1372314680506; Wed, 26 Jun 2013 23:31:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.4.200 with HTTP; Wed, 26 Jun 2013 23:31:00 -0700 (PDT) In-Reply-To: <51C579F0.3020701@innolan.dk> References: <51C579F0.3020701@innolan.dk> From: Adam Hunt Date: Wed, 26 Jun 2013 23:31:00 -0700 Message-ID: Subject: Re: Flapping WAN with axe interface To: Carsten Sonne Larsen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, wpaul@windriver.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 06:31:22 -0000 Well, after days of messing around with my setup I've come to understand that the DUB-E100 is simply not an usable interface on either the WAN or LAN side of a FreeBSD_8.3/pfSense_2.1-rc0 box. While it may take longer to trip the bug, the DUB-E100 eventually loses connectivity even when used on the LAN side of my setup. Save for any last minute thoughts I'm going to be forced to write off axe based NICs. If I want to continue using the box that I'm using (no PCI/PCIe expansion) I'm either stuck using a VLAN capable switch, or a different USB NIC. On Sat, Jun 22, 2013 at 3:18 AM, Carsten Sonne Larsen wrote: > I used to run a setup with a D-Link DUB-E100 ver. B adapter on pfSense also > using it for a DCHP WAN connection. I had a similar issues. Every time I > unplugged > the DUB-E100 things would work smoothly again. > > Now Im using the D-Link adapter on a 8.3-RELEASE and am still having > issues once > in a while. Im not a hardware guy but I think the D-Link simply just have > a buggy > hardware or somehow have some hardware restriction preventing it to be > used as > nothing else but an extra NIC in a laptop - I remember one of the issues > was the > NIC not being able to allocate buffer space. > > /carsten > > > On 06/22/2013 03:11, Adam Hunt wrote: > >> I just replaced my old WRT54GS running DD-WRT at home with a proper >> pfSense >> firewall. The only real problem I've had is my WAN link to Comcast goes >> down at least every twelve hours. I used to think it was almost exactly >> every twelve hours (leading me to think Comcast's DHCP server hated me) >> but >> I have since noticed that the WAN flaps at less predictable intervals. I >> can't figure out if it's related to DHCP or not. I can say that nothing >> out >> of the ordinary was going on on my network when this happens. It happens >> whether or not anyone is actively using any of the systems on the network. >> It can happen when I'm working, browsing, and streaming Netflix or it can >> happen everyone in the house is asleep and most everything is down or >> idle. >> >> One thing that I have learned since I starting this adventure is that it's >> in some way related to my D-Link DUB-E100 rev B1 USB NIC. I know that USB >> isn't the preferred interface for networking but it's what I had. I'm >> currently using a 3.4 GHz P4 Prescott Dell OptiPlex GX620 "ultra small >> form >> factor" desktop for my firewall and it doesn't have any PCI/PCIe expansion >> so I'm left with USB. For some reason I had a D-Link DUB-E100 ver. B >> (AX88772) adapter laying in a box, since it was on the 8.3 HCL I decided >> to >> give it a try. >> >> Below you'll find the my system, dhcp, and gateway logs for the time that >> the link goes down. If you need any other logs or other information I'll >> be >> more than happy to provide it. >> >> system.log:http://pastebin.**com/mxuXd55w >> dhcp.log:http://pastebin.com/**tvAihELQ >> gateways.log:http://pastebin.**com/2cZqjJBa >> >> >> So, after watching the logs, thinking, talking on IRC, checking with the >> pfSense forums I decided to perform a simple experiment. I swapped the >> interfaces, I connected my DOCSIS bridge to the bge0 onboard interface, >> and >> hung my LAN off the USB NIC. Ever since swapping the interfaces everything >> has been quiet. I haven't seen a single error in any of my logs. >> >> What are your thoughts? Is is a Comcast issue, an issue with the DOCSIS >> bridge, an axe bug, a USB bug, some combination of issues, or something >> different entirely? I realize I could just leave everything as is but I'd >> like to help solve this little mystery. Also, years ago I was taught it's >> bad form not to report potential bugs. >> >> Thanks for your help. >> >> --adam >> ______________________________**_________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to"freebsd-net-unsubscribe@**freebsd.org >> " >> > > From owner-freebsd-net@FreeBSD.ORG Thu Jun 27 10:05:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E1A9F46F for ; Thu, 27 Jun 2013 10:05:58 +0000 (UTC) (envelope-from syuu@dokukino.com) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id B768C185A for ; Thu, 27 Jun 2013 10:05:58 +0000 (UTC) Received: by mail-pb0-f52.google.com with SMTP id xa12so702568pbc.11 for ; Thu, 27 Jun 2013 03:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dokukino.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O1Z5ZtoqmZKNuFW2iy9+R5puIwmyfo61Nt5/vWmnjeI=; b=XVI6PjK1pcJoBGgGJBcSfCDTvgMGV6lCbyp4wP3SOJ6EAd3OoToZTXVjwdxp64NNi1 6BHAYoIs830SEV9IL5d3cLgo5Hiq+6OuOzE0TV7Lif3l1d0Dga1i7hr1j5sO9tbsbnDb CozkFg9WG0ECX8D938zbxVLk4rimVcOZpQ3/s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=O1Z5ZtoqmZKNuFW2iy9+R5puIwmyfo61Nt5/vWmnjeI=; b=LPK+m5qTen9pkGzl51FZ2+x0pk8Hgj2Liq2gY7qsB0/eUL5FZ8PG6kN5g8oCGLMJjk O+m7z6dqDx/VH6hH7y7Dwx3DJ99PTvyOlyUmyuDsrI7G0n+yIERQzTqSwu+xWVCqwn0a Xk2imi8Zdn1UOUMAw7ApRcRqiVKE7YyK92aYkQvHpCNwHdpSgOOQqbGxKarPicBg3tug zeIKebWv2OPN3m1l8FYkRM8Aj3tl9inxvXaEpqOjkflGWoha42wb6SFnw61jSd1k/LUX WC+inLGBV6jimQIhBxoCKwC3NVPSI8x6rFqz3S6aWXGICQxHdR7WCefP5IzWVsBQVbX1 gBkQ== MIME-Version: 1.0 X-Received: by 10.68.1.226 with SMTP id 2mr5129890pbp.150.1372327558485; Thu, 27 Jun 2013 03:05:58 -0700 (PDT) Received: by 10.68.222.34 with HTTP; Thu, 27 Jun 2013 03:05:58 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Jun 2013 19:05:58 +0900 Message-ID: Subject: Re: Comparing Mutiqueue Support Linux vs FreeBSD From: Takuya ASADA To: Adrian Chadd X-Gm-Message-State: ALoCoQmTktIc6kNf1hSzFX9XvMBZeDT5tKBHPZtkrGA3Wg4ISl/wsK8mDErwbzJxJzznBsKzDURe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Super Bisquit , Jack Vogel , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 10:05:58 -0000 Maybe we need to add some more generic APIs on NIC driver's ioctl, and invoke it from ifconfig. Or if you hate to add things on ifconfig, just make another command like ethtool from scratch. And driver can export driver specific things via sysctl, some driver already doing in that way. 2013=E5=B9=B46=E6=9C=8827=E6=97=A5=E6=9C=A8=E6=9B=9C=E6=97=A5 Adrian Chadd = adrian@freebsd.org: > ethtool is just a passthrough. The drivers need to implement all of those > hooks. > > It wouldn't be that hard to reimplement. The drivers would have to > reimplement it anyway - they'd have to implement the generic set of > standard statistics, then export driver-specific things. You know, the > stuff our drivers already expose via sysctl. > > > > adrian > > On 26 June 2013 17:02, Jack Vogel > > wrote: > > ethtool is GPL so I wouldn't expect it to show up around here :) > > > > Implementing something like it for FreeBSD would be cool however, > sometimes > > sysctl just > > seems clunky although its usually how i cope with driver things that > might > > be changed via > > ethtool in Linux. Having to completely rebuild a kernel for controlling > RSS > > seems horribly > > clunky on the other hand. > > > > > > > > On Wed, Jun 26, 2013 at 3:58 PM, Super Bisquit > >wrote: > > > >> If someone ports the ethtool to FreeBSD, it will only work on the > >> i386/AMD64/ PC98 architectures. > >> Perhaps having these suggestions as options for the kernel/GENERIC con= f > >> files would be better? > >> > >> > >> On Wed, Jun 26, 2013 at 6:39 PM, Takuya ASADA > > wrote: > >> > >> > Hi, > >> > > >> > Because there was an discussion about new APIs to provide better > support > >> > for high performance NICs in Ottawa DevSummit BoF, I wrote a note > about > >> > "How Linux doing it" in that area. > >> > > >> > I haven't get a enough chance to talk about it in the summit, but I > >> decided > >> > to upload the note on a Wiki. > >> > > >> > Here's a link: > >> > > >> > > >> > https://wiki.freebsd.org/201305DevSummit/NetworkReceivePerformance/Compar= ingMutiqueueSupportLinuxvsFreeBSD > >> > > >> > I hope it helps to decide what kind of interfaces/features do we nee= d > on > >> > FreeBSD. > >> > > >> > Takuya ASADA > >> > _______________________________________________ > >> > freebsd-net@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.or= g > " > >> > > >> _______________________________________________ > >> 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<= javascript:;> > " > >> > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org > " > From owner-freebsd-net@FreeBSD.ORG Thu Jun 27 15:05:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3935FA17 for ; Thu, 27 Jun 2013 15:05:37 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id 0063A1C32 for ; Thu, 27 Jun 2013 15:05:36 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id f6so272530qej.9 for ; Thu, 27 Jun 2013 08:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MOtmiJ/Cwnc2l0QZMplfIF9KXw9gO02ToVYju1UZuGk=; b=q4DwF/DdYPI4n1lPz5DW8u3DGg2ztc61NuJdPfmB9be6kHMWMj+xkHfA1GHCkdT38Q nu/puEyZ3VXOiYeAPNU4dQktNB49+LDEjf17KKoSdFFR1zWWFPv2RQ1HhQiZ3ZrorGKs b11YE0MiIrWRJfCgEk6Z4SDYtpBsplZW9BBetoFUJPCI7rjw2Sp9z4pCujkZUG7c9E12 3jOMUwnt8poyy53p2UR9OB6IvnG2nncM9kUq0Mw19YJZFS2L7EOIfTnkMnU0acxE8mS7 QQm4FrK4i5coNQIIEZrzxzjX9Gqeny8DEg/nth5z3tYcFwRG544xKFgmQNw9oqJREbPh 7jFw== MIME-Version: 1.0 X-Received: by 10.49.82.115 with SMTP id h19mr11336720qey.62.1372345536475; Thu, 27 Jun 2013 08:05:36 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.49.37.226 with HTTP; Thu, 27 Jun 2013 08:05:36 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Jun 2013 09:05:36 -0600 X-Google-Sender-Auth: qHPQUznppb8ILnMshOpsDbRYo1E Message-ID: Subject: Re: probable side effects of deleting interfaces ip addresses(loopback ones) from routing table ! From: Alan Somers To: h bagade Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 15:05:37 -0000 The network route uses your real interface, eg igb0. But the interface IP's route is bound to lo0. So if you delete your interface route, any packets sent to the interface IP will actually go out the real interface. In an experiment, my ping times suggest that those packets are actually going out to the switch and coming back. So if you delete your interface route, you will have reduced performance when talking to your interface address, and you'll also be unable to talk to your own interface address if your ethernet cable gets pulled out. I wouldn't do it if I were you. On Wed, Jun 26, 2013 at 10:35 PM, h bagade wrote: > On Sat, Jun 22, 2013 at 12:25 PM, h bagade wrote: > >> Hi all, >> >> I've deleted the interface ip address from routing table and only keep the >> network address. Nothing is behaving unusual afterwards. I think this >> loopback ip address is added for better performance. My question is would I >> get in to trouble by deleting these ip addresses from routing table or >> it's, as I think, just a matter of performance? >> >> Thanks in advance >> > > I've done further tests after deleting loopback ip addresses and my system > works correctly without any side effects! Is that really OK with deleting > these ip addresses? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jun 27 19:42:08 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EA775209; Thu, 27 Jun 2013 19:42:08 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id D8EC21B42; Thu, 27 Jun 2013 19:42:04 +0000 (UTC) Received: from alph.d.allbsd.org (p3086-ipbf906funabasi.chiba.ocn.ne.jp [122.26.46.86]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r5RJflv1005465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 04:41:57 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r5RJfjaU010693; Fri, 28 Jun 2013 04:41:46 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 28 Jun 2013 04:40:46 +0900 (JST) Message-Id: <20130628.044046.1779486668165395187.hrs@allbsd.org> To: net@FreeBSD.org Subject: RFC: if_bridge(4) ND6_IFF_AUTO_LINKLOCAL From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Fri_Jun_28_04_40_46_2013_856)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 28 Jun 2013 04:41:57 +0900 (JST) X-Spam-Status: No, score=-89.3 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,ONLY1HOPDIRECT,QENCPTR1,RCVD_IN_PBL,SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: bz@FreeBSD.org, rpaulo@FreeBSD.org, ume@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 19:42:09 -0000 ----Security_Multipart0(Fri_Jun_28_04_40_46_2013_856)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Jun_28_04_40_46_2013_678)--" Content-Transfer-Encoding: 7bit ----Next_Part(Fri_Jun_28_04_40_46_2013_678)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I would like your comments about the attached patch. This allows IFT_BRIDGE interfaces to accept ND6_IFF_AUTO_LINKLOCAL and autoconfiguration of a link-local address with EUI-64 interface id. One thing I am concerned about is the case when the parent interface and the member interfaces have own link-local scope zones at the same time since it leads to scope violation. More specifically, It does not occur only in the following cases: 1. bridge0 has an IPv6 address and the members do not. 2. bridge0 does not have an IPv6 address and only one of the members does. I think we can allow only them and forbid the other cases like both bridge0 and the members have IPv6 addresses at the same time. The attached patch implements this restriction by removing overlapped link-local scope zones. I believe the restriction does not matter in practical configurations, but please correct me if I am missing something. -- Hiroki ----Next_Part(Fri_Jun_28_04_40_46_2013_678)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="iflla_20130627-1.diff" - Allow ND6_IFF_AUTO_LINKLOCAL for IFT_BRIDGE. An interface with IFT_BRIDGE is initialized with !ND6_IFF_AUTO_LINKLOCAL && !ND6_IFF_ACCEPT_RTADV regardless of net.inet6.ip6.accept_rtadv and net.inet6.ip6.auto_linklocal. To configure an autoconfigured link-local address (RFC 4862), the following rc.conf(5) configuration can be used: ifconfig_bridge0_ipv6="inet6 auto_linklocal" - if_bridge(4) now removes IPv6 addresses on a member interface to be added when the parent interface or one of the existing member interfaces has an IPv6 address. if_bridge(4) merges each link-local scope zone which the member interfaces form respectively, so it causes address scope violation. Removal of the IPv6 addresses prevents it. - if_lagg(4) now removes IPv6 addresses on a member interfaces unconditionally. MFC after: 1 week ==== Index: sys/netinet6/in6.c =================================================================== --- sys/netinet6/in6.c (revision 252096) +++ sys/netinet6/in6.c (working copy) @@ -1987,6 +1987,32 @@ in6ifa_ifpwithaddr(struct ifnet *ifp, struct in6_a } /* + * Find a link-local scoped address on ifp and return it if any. + */ +struct in6_ifaddr * +in6ifa_llaonifp(struct ifnet *ifp) +{ + struct sockaddr_in6 *sin6; + struct ifaddr *ifa; + + if (ND_IFINFO(ifp)->flags & ND6_IFF_IFDISABLED) + return (NULL); + if_addr_rlock(ifp); + TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { + if (ifa->ifa_addr->sa_family != AF_INET6) + continue; + sin6 = (struct sockaddr_in6 *)ifa->ifa_addr; + if (IN6_IS_SCOPE_LINKLOCAL(&sin6->sin6_addr) || + IN6_IS_ADDR_MC_INTFACELOCAL(&sin6->sin6_addr) || + IN6_IS_ADDR_MC_NODELOCAL(&sin6->sin6_addr)) + break; + } + if_addr_runlock(ifp); + + return ((struct in6_ifaddr *)ifa); +} + +/* * Convert IP6 address to printable (loggable) representation. Caller * has to make sure that ip6buf is at least INET6_ADDRSTRLEN long. */ Index: sys/netinet6/in6_var.h =================================================================== --- sys/netinet6/in6_var.h (revision 252096) +++ sys/netinet6/in6_var.h (working copy) @@ -800,6 +800,7 @@ void in6_setmaxmtu(void); int in6_if2idlen(struct ifnet *); struct in6_ifaddr *in6ifa_ifpforlinklocal(struct ifnet *, int); struct in6_ifaddr *in6ifa_ifpwithaddr(struct ifnet *, struct in6_addr *); +struct in6_ifaddr *in6ifa_llaonifp(struct ifnet *); char *ip6_sprintf(char *, const struct in6_addr *); int in6_addr2zoneid(struct ifnet *, struct in6_addr *, u_int32_t *); int in6_matchlen(struct in6_addr *, struct in6_addr *); Index: sys/netinet6/in6_ifattach.c =================================================================== --- sys/netinet6/in6_ifattach.c (revision 252096) +++ sys/netinet6/in6_ifattach.c (working copy) @@ -266,6 +266,7 @@ found: /* get EUI64 */ switch (ifp->if_type) { + case IFT_BRIDGE: case IFT_ETHER: case IFT_L2VLAN: case IFT_FDDI: @@ -777,8 +778,7 @@ in6_ifattach(struct ifnet *ifp, struct ifnet *alti /* * assign a link-local address, if there's none. */ - if (ifp->if_type != IFT_BRIDGE && - !(ND_IFINFO(ifp)->flags & ND6_IFF_IFDISABLED) && + if (!(ND_IFINFO(ifp)->flags & ND6_IFF_IFDISABLED) && ND_IFINFO(ifp)->flags & ND6_IFF_AUTO_LINKLOCAL) { int error; Index: sys/netinet6/nd6.c =================================================================== --- sys/netinet6/nd6.c (revision 252096) +++ sys/netinet6/nd6.c (working copy) @@ -176,13 +176,25 @@ nd6_ifattach(struct ifnet *ifp) nd->flags = ND6_IFF_PERFORMNUD; - /* A loopback interface always has ND6_IFF_AUTO_LINKLOCAL. */ - if (V_ip6_auto_linklocal || (ifp->if_flags & IFF_LOOPBACK)) + /* A loopback interface always has ND6_IFF_AUTO_LINKLOCAL. + * XXXHRS: Clear ND6_IFF_AUTO_LINKLOCAL on an IFT_BRIDGE interface by + * default regardless of the V_ip6_auto_linklocal configuration to + * give a reasonable default behavior. + */ + if ((V_ip6_auto_linklocal && ifp->if_type != IFT_BRIDGE) || + (ifp->if_flags & IFF_LOOPBACK)) nd->flags |= ND6_IFF_AUTO_LINKLOCAL; - - /* A loopback interface does not need to accept RTADV. */ - if (V_ip6_accept_rtadv && !(ifp->if_flags & IFF_LOOPBACK)) - nd->flags |= ND6_IFF_ACCEPT_RTADV; + /* + * A loopback interface does not need to accept RTADV. + * XXXHRS: Clear ND6_IFF_ACCEPT_RTADV on an IFT_BRIDGE interface by + * default regardless of the V_ip6_accept_rtadv configuration to + * prevent the interface from accepting RA messages arrived + * on one of the member interfaces with ND6_IFF_ACCEPT_RTADV. + */ + if (V_ip6_accept_rtadv && + !(ifp->if_flags & IFF_LOOPBACK) && + (ifp->if_type != IFT_BRIDGE)) + nd->flags |= ND6_IFF_ACCEPT_RTADV; if (V_ip6_no_radr && !(ifp->if_flags & IFF_LOOPBACK)) nd->flags |= ND6_IFF_NO_RADR; Index: sys/net/if_bridge.c =================================================================== --- sys/net/if_bridge.c (revision 252096) +++ sys/net/if_bridge.c (working copy) @@ -118,6 +118,7 @@ __FBSDID("$FreeBSD$"); #ifdef INET6 #include #include +#include #endif #if defined(INET) || defined(INET6) #include @@ -1041,14 +1042,6 @@ bridge_ioctl_add(struct bridge_softc *sc, void *ar if (ifs->if_bridge != NULL) return (EBUSY); - bif = malloc(sizeof(*bif), M_DEVBUF, M_NOWAIT|M_ZERO); - if (bif == NULL) - return (ENOMEM); - - bif->bif_ifp = ifs; - bif->bif_flags = IFBIF_LEARNING | IFBIF_DISCOVER; - bif->bif_savedcaps = ifs->if_capenable; - switch (ifs->if_type) { case IFT_ETHER: case IFT_L2VLAN: @@ -1056,10 +1049,71 @@ bridge_ioctl_add(struct bridge_softc *sc, void *ar /* permitted interface types */ break; default: - error = EINVAL; - goto out; + return (EINVAL); } +#ifdef INET6 + /* + * Two valid inet6 addresses with link-local scope must not be + * on the parent interface and the member interfaces at the + * same time. This restriction is needed to prevent violation + * of link-local scope zone. Attempts to add a member + * interface which has inet6 addresses when the parent has + * inet6 triggers removal of all inet6 addresses on the member + * interface. + */ + + /* Check if the parent interface has a link-local scope addr. */ + if (in6ifa_llaonifp(sc->sc_ifp) != NULL) { + /* + * If any, remove all inet6 addresses from the member + * interfaces. + */ + BRIDGE_XLOCK(sc); + LIST_FOREACH(bif, &sc->sc_iflist, bif_next) { + if (in6ifa_llaonifp(bif->bif_ifp)) { + in6_ifdetach(bif->bif_ifp); + if_printf(sc->sc_ifp, + "IPv6 addresses on %s have been removed " + "before adding it as a member to prevent " + "IPv6 address scope violation.\n", + bif->bif_ifp->if_xname); + } + } + BRIDGE_XDROP(sc); + if (in6ifa_llaonifp(ifs)) { + in6_ifdetach(ifs); + if_printf(sc->sc_ifp, + "IPv6 addresses on %s have been removed " + "before adding it as a member to prevent " + "IPv6 address scope violation.\n", + ifs->if_xname); + } + } else { + struct in6_ifaddr *ia6_m, *ia6_s; + /* + * If not, check whether one of the existing member + * interfaces have inet6 address. If any, remove + * inet6 addresses on the interface to be added. + */ + BRIDGE_XLOCK(sc); + LIST_FOREACH(bif, &sc->sc_iflist, bif_next) { + ia6_m = in6ifa_llaonifp(bif->bif_ifp); + if (ia6_m != NULL) + break; + } + BRIDGE_XDROP(sc); + ia6_s = in6ifa_llaonifp(ifs); + + if (ia6_m != NULL && ia6_s != NULL) { + in6_ifdetach(ifs); + if_printf(sc->sc_ifp, "IPv6 addresses on %s have " + "been removed before adding it as a member " + "to prevent IPv6 address scope violation.\n", + ifs->if_xname); + } + } +#endif /* Allow the first Ethernet member to define the MTU */ if (LIST_EMPTY(&sc->sc_iflist)) sc->sc_ifp->if_mtu = ifs->if_mtu; @@ -1066,10 +1120,17 @@ bridge_ioctl_add(struct bridge_softc *sc, void *ar else if (sc->sc_ifp->if_mtu != ifs->if_mtu) { if_printf(sc->sc_ifp, "invalid MTU: %lu(%s) != %lu\n", ifs->if_mtu, ifs->if_xname, sc->sc_ifp->if_mtu); - error = EINVAL; - goto out; + return (EINVAL); } + bif = malloc(sizeof(*bif), M_DEVBUF, M_NOWAIT|M_ZERO); + if (bif == NULL) + return (ENOMEM); + + bif->bif_ifp = ifs; + bif->bif_flags = IFBIF_LEARNING | IFBIF_DISCOVER; + bif->bif_savedcaps = ifs->if_capenable; + /* * Assign the interface's MAC address to the bridge if it's the first * member and the MAC address of the bridge has not been changed from @@ -1104,12 +1165,10 @@ bridge_ioctl_add(struct bridge_softc *sc, void *ar BRIDGE_LOCK(sc); break; } - if (error) + + if (error) { bridge_delete_member(sc, bif, 0); -out: - if (error) { - if (bif != NULL) - free(bif, M_DEVBUF); + free(bif, M_DEVBUF); } return (error); } @@ -3408,7 +3467,7 @@ bridge_fragment(struct ifnet *ifp, struct mbuf *m, continue; } bcopy(eh, mtod(m0, caddr_t), ETHER_HDR_LEN); - } else + } else m_freem(m); } Index: sys/net/if_lagg.c =================================================================== --- sys/net/if_lagg.c (revision 252096) +++ sys/net/if_lagg.c (working copy) @@ -63,6 +63,8 @@ __FBSDID("$FreeBSD$"); #ifdef INET6 #include +#include +#include #endif #include @@ -543,6 +545,34 @@ lagg_port_create(struct lagg_softc *sc, struct ifn if (ifp->if_type != IFT_ETHER) return (EPROTONOSUPPORT); +#ifdef INET6 + /* + * The member interface should not have inet6 address because + * two interfaces with a valid link-local scope zone must not be + * merged in any form. This restriction is needed to + * prevent violation of link-local scope zone. Attempts to + * add a member interface which has inet6 addresses triggers + * removal of all inet6 addresses on the member interface. + */ + SLIST_FOREACH(lp, &sc->sc_ports, lp_entries) { + if (in6ifa_llaonifp(lp->lp_ifp)) { + in6_ifdetach(lp->lp_ifp); + if_printf(sc->sc_ifp, + "IPv6 addresses on %s have been removed " + "before adding it as a member to prevent " + "IPv6 address scope violation.\n", + lp->lp_ifp->if_xname); + } + } + if (in6ifa_llaonifp(ifp)) { + in6_ifdetach(ifp); + if_printf(sc->sc_ifp, + "IPv6 addresses on %s have been removed " + "before adding it as a member to prevent " + "IPv6 address scope violation.\n", + ifp->if_xname); + } +#endif /* Allow the first Ethernet member to define the MTU */ if (SLIST_EMPTY(&sc->sc_ports)) sc->sc_ifp->if_mtu = ifp->if_mtu; ----Next_Part(Fri_Jun_28_04_40_46_2013_678)---- ----Security_Multipart0(Fri_Jun_28_04_40_46_2013_856)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHMlT4ACgkQTyzT2CeTzy1KLACgwICrLP8qZFdCbp/Ov5+DAWpD w9gAn1F/Wv2Je3VtpGS6lVKqvK2MssyC =9FOy -----END PGP SIGNATURE----- ----Security_Multipart0(Fri_Jun_28_04_40_46_2013_856)---- From owner-freebsd-net@FreeBSD.ORG Thu Jun 27 20:10:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C1566DA for ; Thu, 27 Jun 2013 20:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF161C69 for ; Thu, 27 Jun 2013 20:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5RKA1OG001090 for ; Thu, 27 Jun 2013 20:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5RKA1BG001089; Thu, 27 Jun 2013 20:10:01 GMT (envelope-from gnats) Date: Thu, 27 Jun 2013 20:10:01 GMT Message-Id: <201306272010.r5RKA1BG001089@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Mikolaj Golub Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mikolaj Golub List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 20:10:01 -0000 The following reply was made to PR kern/179901; it has been noted by GNATS. From: Mikolaj Golub To: Michael Gmelin Cc: Mikolaj Golub , bug-followup@FreeBSD.org Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Date: Thu, 27 Jun 2013 23:00:16 +0300 On Wed, Jun 26, 2013 at 03:03:40PM +0200, Michael Gmelin wrote: > Hi, > > I adapted the test code, you can find it at > > http://blog.grem.de/multicast.c > > Test output is: > > IPv4 Port 5555: > Bind using SO_REUSEADDR.......OK (expected) > Bind using SO_REUSEADDR.......OK (expected) > Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in > use IPv4 Port 5556: > Bind using SO_REUSEPORT.......OK (expected) > Bind using SO_REUSEPORT.......OK (expected) > Bind using SO_REUSEADDR.......OK (expected) > Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in > use IPv4 Port 5557: > Bind using SO_REUSEADDR x 2...OK (expected) > Bind using SO_REUSEADDR x 2...OK (expected) > Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in > use Bind using SO_REUSEADDR.......OK (expected) > Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in > use IPv4 Port 5558: > Bind without socketopts.......OK (expected) > Bind using SO_REUSEADDR.......FAIL (expected): Address already in use > Bind using SO_REUSEPORT.......FAIL (expected): Address already in use > IPv4 Port 5559: > Bind using SO_REUSEADDR.......OK (expected) > Bind without socketopts.......FAIL (expected): Address already in use > IPv4 Port 5560: > Bind using SO_REUSEPORT.......OK (expected) > Bind using SO_REUSEPORT.......OK (expected) > Bind without socketopts.......FAIL (expected): Address already in use > IPv6 Port 5555: > Bind using SO_REUSEADDR.......OK (expected) > Bind using SO_REUSEADDR.......OK (expected) > Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in > use IPv6 Port 5556: > Bind using SO_REUSEPORT.......OK (expected) > Bind using SO_REUSEPORT.......OK (expected) > Bind using SO_REUSEADDR.......OK (expected) > Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in > use IPv6 Port 5557: > Bind using SO_REUSEADDR x 2...OK (expected) > Bind using SO_REUSEADDR x 2...OK (expected) > Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in > use Bind using SO_REUSEADDR.......OK (expected) > Bind using SO_REUSEPORT.......FAIL (NOT expected): Address already in > use IPv6 Port 5558: > Bind without socketopts.......OK (expected) > Bind using SO_REUSEADDR.......FAIL (expected): Address already in use > Bind using SO_REUSEPORT.......FAIL (expected): Address already in use > IPv6 Port 5559: > Bind using SO_REUSEADDR.......OK (expected) > Bind without socketopts.......FAIL (expected): Address already in use > IPv6 Port 5560: > Bind using SO_REUSEPORT.......OK (expected) > Bind using SO_REUSEPORT.......OK (expected) > Bind without socketopts.......FAIL (expected): Address already in use > Thank you for testing! > So you maintained the old PORT/ADDR behavior, which I think is not such > a great idea. I would suggest to get another opinion on this, just > because it's broken now doesn't mean we have to perpetuate it - maybe we > should compare the behavior with other Unix(like) OSes like the other > BSDs and Linux to see how their implementations work - usually ported > software is not changed in that respect, so being compatible is > valuable. It is difficult to talk about portability in the case of SO_REUSEPORT. AFAIK, there is no SO_REUSEPORT in Linux and it is recommended to always use SO_REUSEADDR for multicast in portable code. It looks like in this case we will always have expected behavior with the proposed patch. > Besides my rant the code works as designed and seems to resemble the > behavior before r227207 correctly (I manually applied the patches to > 9.1-RELEASE). > > Fun fact: The code in ip6_output.c could have never worked in the first > place, since it used IN_MULTICAST instead of IN6_IS_ADDR_MULTICAST: > > if (IN_MULTICAST(ntohl(in6p->inp_laddr.s_addr))) > ... I don't insist on maintaining the old behaviour. But as actually we have 2 issues here (regression introduced by me in FreeBSD9 and historical behavior that looks wrong), with different priority, I would like to fix the issues separately. This way it will be easier to track the changes, e.g. when after a year it turns out that the second change has broken some other case. For now I am more concerned about having SO_REUSEADDR regression fixed in CURRENT and STABLE9 before 9.2. The patch is under review and I plan to commit it next week if it is ok. The second issue might require more discussion before commiting the change. -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Thu Jun 27 21:30:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0B00118C for ; Thu, 27 Jun 2013 21:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id F14751FDA for ; Thu, 27 Jun 2013 21:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5RLU1k2016997 for ; Thu, 27 Jun 2013 21:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5RLU1x9016996; Thu, 27 Jun 2013 21:30:01 GMT (envelope-from gnats) Date: Thu, 27 Jun 2013 21:30:01 GMT Message-Id: <201306272130.r5RLU1x9016996@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: John Baldwin Subject: Re: kern/179999: [ofed] [patch] Bug assigning HCA from IB to ETH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: John Baldwin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 21:30:02 -0000 The following reply was made to PR kern/179999; it has been noted by GNATS. From: John Baldwin To: bug-followup@freebsd.org, shahark@mellanox.com Cc: Subject: Re: kern/179999: [ofed] [patch] Bug assigning HCA from IB to ETH Date: Thu, 27 Jun 2013 14:10:42 -0400 Thanks, I think the sysfs fix has a few issues though (it writes to buf[] even if the copyin() fails, and it doesn't enforce a bounds check). It does seem that this should probably be using sysctl_handle_string() instead of doing it by hand, but for now I've just adjusted your patch. Can you please test this version? Index: ofed/drivers/net/mlx4/main.c =================================================================== --- ofed/drivers/net/mlx4/main.c (revision 252306) +++ ofed/drivers/net/mlx4/main.c (working copy) @@ -479,11 +479,11 @@ int i; int err = 0; - if (!strcmp(buf, "ib\n")) + if (!strcmp(buf, "ib")) info->tmp_type = MLX4_PORT_TYPE_IB; - else if (!strcmp(buf, "eth\n")) + else if (!strcmp(buf, "eth")) info->tmp_type = MLX4_PORT_TYPE_ETH; - else if (!strcmp(buf, "auto\n")) + else if (!strcmp(buf, "auto")) info->tmp_type = MLX4_PORT_TYPE_AUTO; else { mlx4_err(mdev, "%s is not supported port type\n", buf); Index: ofed/include/linux/sysfs.h =================================================================== --- ofed/include/linux/sysfs.h (revision 252306) +++ ofed/include/linux/sysfs.h (working copy) @@ -104,10 +104,15 @@ error = SYSCTL_OUT(req, buf, len); if (error || !req->newptr || ops->store == NULL) goto out; - error = SYSCTL_IN(req, buf, PAGE_SIZE); + len = req->newlen - req->newidx; + if (len >= PAGE_SIZE) + error = EINVAL; + else + error = SYSCTL_IN(req, buf, len); if (error) goto out; - len = ops->store(kobj, attr, buf, req->newlen); + ((char *)buf)[len] = '\0'; + len = ops->store(kobj, attr, buf, len); if (len < 0) error = -len; out: -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Jun 28 10:42:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 345D3100; Fri, 28 Jun 2013 10:42:43 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id A47CC10CF; Fri, 28 Jun 2013 10:42:41 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r5SAFJpV054759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Jun 2013 12:15:19 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r5SAFFeD098701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 12:15:15 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r5SAFF5I069234; Fri, 28 Jun 2013 12:15:15 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r5SAFEAr069233; Fri, 28 Jun 2013 12:15:14 +0200 (CEST) (envelope-from ticso) Date: Fri, 28 Jun 2013 12:15:14 +0200 From: Bernd Walter To: linimon@freebsd.org Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Message-ID: <20130628101514.GX45651@cicely7.cicely.de> References: <201306240359.r5O3xO0g012449@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201306240359.r5O3xO0g012449@freefall.freebsd.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 10:42:43 -0000 On Mon, Jun 24, 2013 at 03:59:24AM +0000, linimon@freebsd.org wrote: > Old Synopsis: [patch] Multicast SO_REUSEADDR handled incorrectly > New Synopsis: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Mon Jun 24 03:59:05 UTC 2013 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=179901 > _______________________________________________ > 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" I don't know if this is related or a different bug, but the same mentioned commits are suspicious for us. We had been running with our own IPv6 software into the same REUSEADDR problem and changed to REUSEPORT as this is how it is done in mcastread from mcast-tools port. Don't know where we originally got the REUSEADDR from, probably a Stevens book. So far binding works with this change in our software. However we only receive packets from network and not packets from the host itself. We use multicast to notify multiple processes on multiple machines, including the machine itself. To reproduce: - use two hosts - start mcastread on each of them on an interface with shared LAN - send via mcastsend on one host - packets are received on the other host, but not with the mcastread on the same host -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-net@FreeBSD.ORG Fri Jun 28 15:53:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59513F1D; Fri, 28 Jun 2013 15:53:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 375941471; Fri, 28 Jun 2013 15:53:19 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 81D7AB990; Fri, 28 Jun 2013 11:53:18 -0400 (EDT) From: John Baldwin To: "Mr. Clif" Subject: Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations Date: Fri, 28 Jun 2013 11:42:01 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305300113.r4U1DRGp089692@freefall.freebsd.org> <201306241738.47350.jhb@freebsd.org> <51CA6FF9.60805@eugeneweb.com> In-Reply-To: <51CA6FF9.60805@eugeneweb.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201306281142.01250.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 28 Jun 2013 11:53:18 -0400 (EDT) Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 15:53:19 -0000 On Wednesday, June 26, 2013 12:37:13 am Mr. Clif wrote: > Hi John, > > Thanks for working on this. I'm very interested in getting this fixed > for everyone that uses the Affected Atom boards and other small format > boards that work well in small custom routers. > > However right now I have a big network upgrade I'm working on and don't > have time to get to it until late July, I'm hoping. So please forgive me > for the long delay. That is fine. I've been able to test this on a little netbook I have that has bridges with the ISA enable bit set and have fixed a few bugs. The updated patch is at the URL below. I wasn't able to test your specific use case yet however (of the BIOS using an invalid range). > Thanks for your help, > Clif > > > John Baldwin wrote: > > On Monday, June 10, 2013 3:13:11 pm Mr. Clif wrote: > >> Hi John and Pyun, > >> > >> Ok got the new kernel installed and tested. Yes it works! :-) Maybe that > >> will also fix a simular problem with the sun cards (cas[03]), except I > >> don't see a define like that in if_cas.c. Suggestions? > > So I have a possible "real" fix for this. However, I do not have any hardware > > I can find that has a PCI-PCI bridge with the ISA-enable bit set. I know it > > compiles and boots fine on other systems. Can you please try this and capture > > the dmesg output? It would also be good to capture devinfo -u output before > > and after. > > > > http://www.freebsd.org/~jhb/patches/pci_isa_enable.patch > > > > -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Jun 28 17:48:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C3D3F5E; Fri, 28 Jun 2013 17:48:53 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id ECD1C1B73; Fri, 28 Jun 2013 17:48:52 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id wz7so2549482pbc.9 for ; Fri, 28 Jun 2013 10:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Pu0/s4ycT2o/mTEW6lN5yWgu8mdecejQW9ZQas79kM0=; b=LW/j00ENlLUY8tccbb2L0Qy6CW1SNe6DvswD7qdEVH8E7C2CozaeCvG6S609rWSPKZ 9TvENOBYxDl/65KoXE2ru8E/a63RwEiCDBbcQ/Y3erR1RRm7Oax80xCyLngClMBIi7S7 eJH/2Q+q+Gb8haGrxFzp7GhVPhAgEqHSF0cxgwKLgS356i6awJnVm5ndXa9wmygTevDk jOuxPjQhbxSH/b++/cGsrmumC3z6BSEQIJPJGvP1F3CgJOAgv5vSuPNTXaUWA0c3jzl+ xLyfVRSuS8Up9z29IXKAEDCZvCOyivtHd+otMWbbngiF7OZD/q1+ttfbhX0KK4zJJ4U9 S3bA== MIME-Version: 1.0 X-Received: by 10.68.189.101 with SMTP id gh5mr4952093pbc.86.1372441732187; Fri, 28 Jun 2013 10:48:52 -0700 (PDT) Received: by 10.70.96.139 with HTTP; Fri, 28 Jun 2013 10:48:52 -0700 (PDT) Received: by 10.70.96.139 with HTTP; Fri, 28 Jun 2013 10:48:52 -0700 (PDT) Date: Fri, 28 Jun 2013 20:48:52 +0300 Message-ID: Subject: Dnay From: Sami Halabi To: freebsd-net@freebsd.org, freebsd-ipfw Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 17:48:53 -0000 Hi, I would like to perform a full dnat/snat as in iptbles in: linux-ip.net/html/nat-dnat.html How it can be done in fbsd, I use ipgw. Thanks in advance, Sami From owner-freebsd-net@FreeBSD.ORG Fri Jun 28 18:59:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 33A30D47; Fri, 28 Jun 2013 18:59:11 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id A6FFE1F9F; Fri, 28 Jun 2013 18:59:10 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r5SIwwT2062840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Jun 2013 20:58:58 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r5SIwq79009269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 20:58:52 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r5SIwqVj071395; Fri, 28 Jun 2013 20:58:52 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r5SIwq3C071394; Fri, 28 Jun 2013 20:58:52 +0200 (CEST) (envelope-from ticso) Date: Fri, 28 Jun 2013 20:58:52 +0200 From: Bernd Walter To: linimon@freebsd.org Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Message-ID: <20130628185852.GA45651@cicely7.cicely.de> References: <201306240359.r5O3xO0g012449@freefall.freebsd.org> <20130628101514.GX45651@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130628101514.GX45651@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 18:59:11 -0000 On Fri, Jun 28, 2013 at 12:15:14PM +0200, Bernd Walter wrote: > On Mon, Jun 24, 2013 at 03:59:24AM +0000, linimon@freebsd.org wrote: > > Old Synopsis: [patch] Multicast SO_REUSEADDR handled incorrectly > > New Synopsis: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > > Responsible-Changed-By: linimon > > Responsible-Changed-When: Mon Jun 24 03:59:05 UTC 2013 > > Responsible-Changed-Why: > > Over to maintainer(s). > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=179901 > > _______________________________________________ > > 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" > > I don't know if this is related or a different bug, but the same > mentioned commits are suspicious for us. > We had been running with our own IPv6 software into the same REUSEADDR > problem and changed to REUSEPORT as this is how it is done in mcastread > from mcast-tools port. > Don't know where we originally got the REUSEADDR from, probably a Stevens > book. > So far binding works with this change in our software. > However we only receive packets from network and not packets from > the host itself. > We use multicast to notify multiple processes on multiple machines, > including the machine itself. > To reproduce: > - use two hosts > - start mcastread on each of them on an interface with shared LAN > - send via mcastsend on one host > - packets are received on the other host, but not with the mcastread > on the same host It is unrelated, but I have found the cause for it and filed kern/180065 together with a working patch. The reason is that the packets have no valid checksums when processed in ip6_input because of delayed checksum changes. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-net@FreeBSD.ORG Fri Jun 28 19:59:58 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 452B2E30; Fri, 28 Jun 2013 19:59:58 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2CD1274; Fri, 28 Jun 2013 19:59:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5SJxvtq097063; Fri, 28 Jun 2013 19:59:57 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5SJxvwZ097060; Fri, 28 Jun 2013 19:59:57 GMT (envelope-from linimon) Date: Fri, 28 Jun 2013 19:59:57 GMT Message-Id: <201306281959.r5SJxvwZ097060@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/180065: [netinet6] [patch] Multicast loopback to own host broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 19:59:58 -0000 Old Synopsis: Multicast loopback to own host broken New Synopsis: [netinet6] [patch] Multicast loopback to own host broken Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 28 19:59:39 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=180065 From owner-freebsd-net@FreeBSD.ORG Fri Jun 28 20:00:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3F6A1E36 for ; Fri, 28 Jun 2013 20:00:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3235E1278 for ; Fri, 28 Jun 2013 20:00:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5SK01xr097871 for ; Fri, 28 Jun 2013 20:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5SK01qp097855; Fri, 28 Jun 2013 20:00:01 GMT (envelope-from gnats) Date: Fri, 28 Jun 2013 20:00:01 GMT Message-Id: <201306282000.r5SK01qp097855@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Mark Linimon Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mark Linimon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 20:00:02 -0000 The following reply was made to PR kern/179901; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Date: Fri, 28 Jun 2013 14:55:38 -0500 ----- Forwarded message from Bernd Walter ----- Date: Fri, 28 Jun 2013 12:15:14 +0200 From: Bernd Walter To: linimon@freebsd.org Cc: freebsd-bugs@freebsd.org, freebsd-net@freebsd.org Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly User-Agent: Mutt/1.5.11 I don't know if this is related or a different bug, but the same mentioned commits are suspicious for us. We had been running with our own IPv6 software into the same REUSEADDR problem and changed to REUSEPORT as this is how it is done in mcastread from mcast-tools port. Don't know where we originally got the REUSEADDR from, probably a Stevens book. So far binding works with this change in our software. However we only receive packets from network and not packets from the host itself. We use multicast to notify multiple processes on multiple machines, including the machine itself. To reproduce: - use two hosts - start mcastread on each of them on an interface with shared LAN - send via mcastsend on one host - packets are received on the other host, but not with the mcastread on the same host -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ----- End forwarded message ----- From owner-freebsd-net@FreeBSD.ORG Fri Jun 28 20:00:05 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B4DE1EC0 for ; Fri, 28 Jun 2013 20:00:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A7898127B for ; Fri, 28 Jun 2013 20:00:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5SK05vO098649 for ; Fri, 28 Jun 2013 20:00:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5SK05AX098647; Fri, 28 Jun 2013 20:00:05 GMT (envelope-from gnats) Date: Fri, 28 Jun 2013 20:00:05 GMT Message-Id: <201306282000.r5SK05AX098647@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Mark Linimon Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mark Linimon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 20:00:05 -0000 The following reply was made to PR kern/179901; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Date: Fri, 28 Jun 2013 14:56:07 -0500 ----- Forwarded message from Bernd Walter ----- Date: Fri, 28 Jun 2013 20:58:52 +0200 From: Bernd Walter To: linimon@freebsd.org Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly User-Agent: Mutt/1.5.11 It is unrelated, but I have found the cause for it and filed kern/180065 together with a working patch. The reason is that the packets have no valid checksums when processed in ip6_input because of delayed checksum changes. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ----- End forwarded message ----- From owner-freebsd-net@FreeBSD.ORG Fri Jun 28 22:08:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 58CB7D10; Fri, 28 Jun 2013 22:08:22 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 3534A18F5; Fri, 28 Jun 2013 22:08:22 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id z10so1274845pdj.31 for ; Fri, 28 Jun 2013 15:08:22 -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=cP3UcPhHc2pVfIpVXrd8uRa53+uYxOZXKN8Zmrcz4X8=; b=Wt7dpZrIQZ5DWxiUeNXvGpWYIJnk14wXwVMr9JJTqjwUlfJf5WPeJkz1DOmNRQid1D dsuiAd4Blfgj8IRndISb0VoEO1ezeDu9Ob8VWwrKoJsrYBIvt+JZ+sRTDxCuBD9u7/zg X8O8LAazHwEHBRAnZ3ZqXseDs97PkPDNJ5BbnL9XEj4hUR3G3yTirKDN2hbfrY65ytSP Qux0+DbgY3FXqbc3eaGaWNwfqtCzcgSAAiOfrC63tqFE6DL/Wf1P5qNl0lx2zbKG+Oe9 29yDdjKOjJ00y505z9qsD0rOxwuxotg7T1eyEpEdczqfcapXerQdvmJLyaY0OGWWYPmS HT5w== MIME-Version: 1.0 X-Received: by 10.67.3.99 with SMTP id bv3mr13427171pad.140.1372457302043; Fri, 28 Jun 2013 15:08:22 -0700 (PDT) Received: by 10.70.96.139 with HTTP; Fri, 28 Jun 2013 15:08:22 -0700 (PDT) Date: Sat, 29 Jun 2013 01:08:22 +0300 Message-ID: Subject: DNAT in freebsd From: Sami Halabi To: freebsd-ipfw , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 22:08:22 -0000 Hi, (sorry for sending again, the last email was with wrong subject) I would like to perform a full dnat/snat as in iptbles in: linux-ip.net/html/nat-dnat.html How it can be done in fbsd, I use ipfw. I seeked natd man page but its translation, and thr proxy_rule is for specefic port, not a whole transparancy. Thanks in advance, -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Fri Jun 28 22:30:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9F35ED14 for ; Fri, 28 Jun 2013 22:30:23 +0000 (UTC) (envelope-from feld@feld.me) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7566119F4 for ; Fri, 28 Jun 2013 22:30:23 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C4C1720EBD for ; Fri, 28 Jun 2013 18:30:22 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 28 Jun 2013 18:30:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= content-type:to:date:subject:mime-version :content-transfer-encoding:from:message-id; s=mesmtp; bh=wxpZ6MR NE9msAcEdyPYQLbbrA+c=; b=bPOukDWkI005xw2y7Q4/z2tb/OtiFnDqRVG8W4C TIbocDKn+IIQEk+KnAg9yoWBsjt7beHojEEG5+vs/7y5SPVxT3Xi+dr+8xteEdWr vquKAKeJvTkcPsq126rsBEez1jalrot10YJB7L9XLNjGDpcx9DA+fx1wOdIDDgys /rZ8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:date:subject:mime-version :content-transfer-encoding:from:message-id; s=smtpout; bh=wxpZ6M RNE9msAcEdyPYQLbbrA+c=; b=T7hoUNc/6SHzDkuLzvlD6E5Rnd4GvBI45GGU2y 7aaAJY8ajgRInlhapHIlk2wQArJQd+5a5/eB+d6XLkZhWFIfz17nbs7k8JtJHqKs NGqxjvbi4lq0gnwNRcofxExVS1Dssb+X+BIbw0cfC+rwtFwH5dl07hESK6gulFnU 5MQQI= X-Sasl-enc: 610dWd72Z7EafbefuNicj/Q9YqY8fDKr/0hUXnw2y/hU 1372458622 Received: from tech304.office.supranet.net (unknown [66.170.8.18]) by mail.messagingengine.com (Postfix) with ESMTPA id 9077BC00E83 for ; Fri, 28 Jun 2013 18:30:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-net@freebsd.org Date: Fri, 28 Jun 2013 17:30:21 -0500 Subject: Making net.inet6.ip6.v6only=0 default MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: User-Agent: Opera Mail/12.15 (FreeBSD) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 22:30:23 -0000 After a brief talk on IRC I figured I'd get some feelers out there about this sysctl which seems to have a long history. Background: I recently updated the net/rwhoisd port here on FreeBSD with a patch from the kind hrs@ who fixed it so it binds on both ipv4 AND ipv6 when it is built with ipv6 (default since last summer in the ports tree). I sent the patch upstream, and I received feedback from a list user that the real problem is FreeBSD's lack of compliance and we really should change net.inet6.ip6.v6only=0 to fix it. Now, originally I was just going to add an install message with the port to change that sysctl, but I was told it is dangerous and I wasn't sure of the consequences. I'm quite familiar with ipv6 networking, but not specifically this setting and its consequences among software out there and I didn't want unknown behavior on my production servers. The patch hrs@ sent me seemed a better solution at the time. Later after a bit more digging and discussion I've come to learn that the security aspect may simply be "unexpected behavior -- the binding to ipv6 sockets and endusers not realizing it, thus creating a security hole for environments with only an ipv4 firewall". We ship a dual stack firewall by default, and now since FreeBSD 9 we have the rc.conf setting ipv6_activate_all_interfaces="YES" which seems sufficient to mitigate this; the user would have to know they're enabling ipv6 and what its consequences could be. So I guess the question is: what do we do? It looks like we're in violation of both RFC 3493, Section 5.3 and POSIX 2008, Volume 2, Section 2.10.20*. *I read the RFC, but haven't looked up the POSIX spec yet. Both were listed in a forum post from 2010. From owner-freebsd-net@FreeBSD.ORG Sat Jun 29 00:30:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1D637899; Sat, 29 Jun 2013 00:30:56 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ03.datapipe-corp.net (exfesmq03.datapipe.com [64.27.120.67]) by mx1.freebsd.org (Postfix) with ESMTP id DA25C1DD4; Sat, 29 Jun 2013 00:30:55 +0000 (UTC) Received: from nat.myhome (192.168.128.103) by EXFESMQ03.datapipe-corp.net (192.168.128.28) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 28 Jun 2013 20:29:40 -0400 Date: Fri, 28 Jun 2013 19:29:59 -0500 From: "Paul A. Procacci" To: Sami Halabi Subject: Re: DNAT in freebsd Message-ID: <20130629002959.GB20376@nat.myhome> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.103] Content-Transfer-Encoding: quoted-printable Cc: freebsd-ipfw , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 00:30:56 -0000 > Hi, (sorry for sending again, the last email was with wrong subject) > I would like to perform a full dnat/snat as in iptbles in: > linux-ip.net/html/nat-dnat.html > How it can be done in fbsd, I use ipfw. > > I seeked natd man page but its translation, and thr proxy_rule is for > specefic port, not a whole transparancy. > Using in-kernel nat is probably a better choice IMHO. read `man ipfw(8)` The section labeled EXAMPLES has exactly what you need. Here is a snippet from the manpage to get you started: ------------------------------- Then to configure nat instance 123 to alias all the outgoing traffic with ip 192.168.0.123, blocking all incoming connections, trying to keep same ports on both sides, clearing aliasing table on address change and keep- ing a log of traffic/link statistics: ipfw nat 123 config ip 192.168.0.123 log deny_in reset same_ports ipfw nat 123 config redirect_addr 10.0.0.1 10.0.0.66 redirect_port tcp 192.168.0.1:80 500 redirect_proto udp 192.168.1.43 192.168.1.1 redirect_addr 192.168.0.10,192.168.0.11 10.0.0.100 # LSNAT redirect_port tcp 192.168.0.1:80,192.168.0.10:22 500 # LSNAT ------------------------------- ~Paul ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/legal/email_disclaimer/ for further inf= ormation on confidentiality and the risks of non-secure electronic communic= ation. If you cannot access these links, please notify us by reply message = and we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Sat Jun 29 01:15:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B9A42ED for ; Sat, 29 Jun 2013 01:15:59 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 7CFA11F17 for ; Sat, 29 Jun 2013 01:15:59 +0000 (UTC) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 41D1EC94AC; Sat, 29 Jun 2013 01:15:52 +0000 (UTC) (envelope-from jinmei@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372468559; bh=ZxMToLXjUfezRG/ddmkUh9nb4K5MwCbvLbFHxpQ1lEA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=O0f8WXYrU3PaJyzxs/6Q1ur30JRTMXrUtDfFW0/wc+zsDbw7iV4w72Qk68p2SHnPr h1RpmRbIA+4VqL6ZLd3mxBSuxly9x5hitR4FtIPsrXAiJes708FEGEHgjN+gJfRsHX 6rl4z/HQYrmmf2IdE6SudDS4/lz5OJ5y4Gjk9hSo= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sat, 29 Jun 2013 01:15:52 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7F5D01600AB; Sat, 29 Jun 2013 01:17:15 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id fRgGcE0Bxhtc; Sat, 29 Jun 2013 01:17:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D79D71600B7; Sat, 29 Jun 2013 01:17:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PUf-Rg8wWozN; Sat, 29 Jun 2013 01:17:14 +0000 (UTC) Received: from jmb.jinmei.org (dhcp-57.sql1.isc.org [149.20.50.57]) by zmx1.isc.org (Postfix) with ESMTPSA id BEF161600AB; Sat, 29 Jun 2013 01:17:14 +0000 (UTC) Date: Fri, 28 Jun 2013 18:15:51 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Mark Felder" Subject: Re: Making net.inet6.ip6.v6only=0 default In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-DCC--Metrics: post.isc.org; whitelist X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 01:15:59 -0000 At Fri, 28 Jun 2013 17:30:21 -0500, "Mark Felder" wrote: > Later after a bit more digging and discussion I've come to learn that the So, you've gone through the literature on this topic including http://tools.ietf.org/html/draft-cmetz-v6ops-v4mapped-api-harmful-01 ? > security aspect may simply be "unexpected behavior -- the binding to ipv6 > sockets and endusers not realizing it, thus creating a security hole for > environments with only an ipv4 firewall". > > We ship a dual stack firewall by default, and now since FreeBSD 9 we have > the rc.conf setting ipv6_activate_all_interfaces="YES" which seems > sufficient to mitigate this; the user would have to know they're enabling > ipv6 and what its consequences could be. I'm afraid it's a bit too optimistic. We also need to rely on either application programmers being careful enough to write code like this: - sin6 = (struct sockaddr_in6 *) sa; - inet_ntop( AF_INET6, (void *) sin6->sin6_addr.s6_addr, addr, sizeof - addr ); - /* If it's an IPv4 mapped address, drop the leading '::ffff:' */ - if ( IN6_IS_ADDR_V4MAPPED( &(sin6->sin6_addr) ) ) - strncpy( wrapper_addr, addr + 7, sizeof wrapper_addr ); - /* otherwise surround the address with braces to hopefully match - what tcp wrapper expects */ - else sprintf( wrapper_addr, "%s", addr ); - } (taken from the FreeBSD port patch for rwhois) so a naive user can safely write a rule like deny 192.0.2.1 allow all or the user is careful enough to write ACLs like: deny 192.0.2.1 deny ::ffff:192.0.2.1 allow all In theory, people (either or both of programmers and users) can make it safe. In practice, I personally think it's sufficiently error prone. Admittedly, however, different people may have difference senses on the severity of this point. And (in my understanding) that's why relevant people failed to get a clear consensus at the time they discussed this API. In the end the "standard" default behavior was documented with leaving lots of controversy. Unfortunately, this also left portability problems. It's not only for FreeBSD; as far as I know NetBSD still keeps the same default as FreeBSD, and, as far as I know OpenBSD still even refuses to allow this usage of IPv4-mapped IPv6 addresses. And, I suspect some of them do so "religiously", and will never change the behavior no matter what the "standard" documentations state. So... > So I guess the question is: what do we do? It looks like we're in > violation of both RFC 3493, Section 5.3 and POSIX 2008, Volume 2, Section > 2.10.20*. ...aside from what FreeBSD should do for ip6.v6only, I personally believe that realistically this issue should be resolved at the application side, i.e., explicitly set the IPV6_V6ONLY socket option to 1 and use both AF_INET (for IPv4) and AF_INET6 (for IPv6, and only for IPv6) sockets. As far as I know this is the most portable behavior. Regarding the rwhois case, I'd first suggest updating the patch with this socket option setting. Hopefully it can be accepted by the upstream because it's most portable. If they still reject it because "it's against the standard" (and even if it's less portable in reality), my next suggestion is to explicitly set the IPV6_V6ONLY socket option to 0. This setting is "redundant" in the sense of standard purity, but hopefully less controversial for those preferring the standard compliance as it only requires a small change and will make it still more portable. Going back to the question of what FreeBSD should do for ip6.v6only: Personally, I'd still suggest keeping the same default because I agree this behavior is sufficiently safer (as noted above) *and* there'll be portability issues anyway (OSes using the different default "religiously" will never change it). But I also understand the argument that standard compliance is more important than debatable safety. In either case, it would help if we provide detailed discussion for the description of this sysctl knob. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From owner-freebsd-net@FreeBSD.ORG Sat Jun 29 02:20:30 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 53B7FA94 for ; Sat, 29 Jun 2013 02:20:30 +0000 (UTC) (envelope-from feld@feld.me) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 28E9F10E7 for ; Sat, 29 Jun 2013 02:20:29 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1CD4A20920 for ; Fri, 28 Jun 2013 22:20:29 -0400 (EDT) Received: from web3.nyi.mail.srv.osa ([10.202.2.213]) by compute4.internal (MEProxy); Fri, 28 Jun 2013 22:20:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= 5ysp5IMi0bv337X8X66XnVB0GKU=; b=Ge8Ld8NVs2xUGqcsY9ziKgKbnyUX7D9W 3LC2wW0GC+LHoyCnuosz0tfRnVXiEk+OnWMJKWyKpeJHFbwggPYvo2C+A2JNemK0 2Q2LbURO8F0RoZYs3v1toFBdOyQ1lphoX6f5PeodSZdfeGbvk9mVynP8Ts5gJaFt rj3U2Xybric= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=5ysp5IMi0bv337X8X66XnVB0GKU=; b=HYPZg jm9zJZVEclQluQumMqHDgxBievouQ4dUztHRcoAC//E7nTP6z3R5i2icTImoS5vi oUBy/PP6sV5ZCrzCWg+0dus2jXaIp2eQvZQDYsm/krhYpSy0w1oyLonWu1+T2Ec4 il1hAjA0uwa9C56Gohx+/mX7lraSNgoqvXJfQ0= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id DFF7FB00003; Fri, 28 Jun 2013 22:20:28 -0400 (EDT) Message-Id: <1372472428.8289.140661249795641.4506C2CC@webmail.messagingengine.com> X-Sasl-Enc: bmvBwZOlJFQXIP7h4EMIO/dU/jZO0eSkA8dBi2+71p1W 1372472428 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ae8e04c Subject: Re: Making net.inet6.ip6.v6only=0 default Date: Fri, 28 Jun 2013 21:20:28 -0500 In-Reply-To: References: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 02:20:30 -0000 On Fri, Jun 28, 2013, at 20:15, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94= =E5=93=89 wrote: > At Fri, 28 Jun 2013 17:30:21 -0500, > "Mark Felder" wrote: >=20 > > Later after a bit more digging and discussion I've come to learn that t= he=20=20 >=20 > So, you've gone through the literature on this topic including > http://tools.ietf.org/html/draft-cmetz-v6ops-v4mapped-api-harmful-01 > ? > I had not seen that yet. Thanks for all the feedback you've provided -- you've made some excellent points. From owner-freebsd-net@FreeBSD.ORG Sat Jun 29 06:50:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7620A576; Sat, 29 Jun 2013 06:50:15 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id 4DC171B4C; Sat, 29 Jun 2013 06:50:15 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id kp12so3210964pab.21 for ; Fri, 28 Jun 2013 23:50:15 -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=obJiTNpnORlCIZgLSGHm5zwSxbZHUcNifxQtPzIdoYs=; b=e9W7ouHpqRFsMZajHO1up7wbWi8bx4ZYT/yfWiWIqsQKD2M8KvYYfRzy4hQD/mGZlu UY2EGWfgBk7WOv7G2T66DqVV7KWLK+PbEMgizsnAbt9wsVe2RY9huO/348wnjj7Cwhiv /Rm9/DBdV93OHS1mNIpOU+DK+uerbjAeTN4oG9qMT9Pln0Ev8tBHdlajhskI+AO8jEw+ qb13y1hVJScXLYVszzzn+Xfs7zEE0vi2wLy9HF4lL8K2fowhZv3gGNCBwB9RQyIaq369 M+HGaWvs56hL7C074KTOOTBXBvLjD7FwCIBpMbsMBzMh8pzpQNBivoffU5invI08zH5T agRg== MIME-Version: 1.0 X-Received: by 10.68.171.162 with SMTP id av2mr14745484pbc.104.1372488615092; Fri, 28 Jun 2013 23:50:15 -0700 (PDT) Received: by 10.70.96.139 with HTTP; Fri, 28 Jun 2013 23:50:15 -0700 (PDT) Received: by 10.70.96.139 with HTTP; Fri, 28 Jun 2013 23:50:15 -0700 (PDT) In-Reply-To: <20130629002959.GB20376@nat.myhome> References: <20130629002959.GB20376@nat.myhome> Date: Sat, 29 Jun 2013 09:50:15 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: "Paul A. Procacci" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 06:50:15 -0000 I think I was misunderstood... Here is the situation i want to handle: My box is a router that handles several /24 behind. One of my links (em0) is connected to a private network 192.168.0.1 is me, my neighbour is 192.168.0.2. I want to make that any connection comes to 192.168.0.1 to go to ip 193.xxx.yyy.2 using specific public ip 84.xx.yy.1 And packets comming to my public 84.xx.yy.1 ip to be trsnslated as came from 192.168.0.1 and sent to 192.168.0.2/or ant other ips behind(192.168.1.xx/24). Hope that makes it clearer, and I appreciate any help. Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 29 =D7=91=D7=99=D7=95=D7=A0 2013 03:30= , =D7=9E=D7=90=D7=AA "Paul A. Procacci" : > > Hi, (sorry for sending again, the last email was with wrong subject) > > I would like to perform a full dnat/snat as in iptbles in: > > linux-ip.net/html/nat-dnat.html > > How it can be done in fbsd, I use ipfw. > > > > I seeked natd man page but its translation, and thr proxy_rule is for > > specefic port, not a whole transparancy. > > > > Using in-kernel nat is probably a better choice IMHO. > > read `man ipfw(8)` > > The section labeled EXAMPLES has exactly what you need. > Here is a snippet from the manpage to get you started: > > ------------------------------- > > > Then to configure nat instance 123 to alias all the outgoing traffic with > ip 192.168.0.123, blocking all incoming connections, trying to keep same > ports on both sides, clearing aliasing table on address change and keep- > ing a log of traffic/link statistics: > > ipfw nat 123 config ip 192.168.0.123 log deny_in reset same_ports > > > > ipfw nat 123 config redirect_addr 10.0.0.1 10.0.0.66 > redirect_port tcp 192.168.0.1:80 500 > redirect_proto udp 192.168.1.43 192.168.1.1 > redirect_addr 192.168.0.10,192.168.0.11 > 10.0.0.100 # LSNAT > redirect_port tcp 192.168.0.1:80, > 192.168.0.10:22 > 500 # LSNAT > > > ------------------------------- > > > ~Paul > > ________________________________ > > This message may contain confidential or privileged information. If you > are not the intended recipient, please advise us immediately and delete > this message. See http://www.datapipe.com/legal/email_disclaimer/ for > further information on confidentiality and the risks of non-secure > electronic communication. If you cannot access these links, please notify > us by reply message and we will send the contents to you. > From owner-freebsd-net@FreeBSD.ORG Sat Jun 29 13:58:01 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 13626768 for ; Sat, 29 Jun 2013 13:58:01 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 8BC271757 for ; Sat, 29 Jun 2013 13:58:00 +0000 (UTC) Received: from alph.d.allbsd.org (p3086-ipbf906funabasi.chiba.ocn.ne.jp [122.26.46.86]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r5TDvb3f063185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Jun 2013 22:57:48 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r5TDvZib094097; Sat, 29 Jun 2013 22:57:37 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 29 Jun 2013 22:56:03 +0900 (JST) Message-Id: <20130629.225603.1610787044468429534.hrs@allbsd.org> To: jinmei@isc.org Subject: Re: Making net.inet6.ip6.v6only=0 default From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Jun_29_22_56_03_2013_155)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sat, 29 Jun 2013 22:57:48 +0900 (JST) X-Spam-Status: No, score=-89.6 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN, DYN_PBL, ISO2022JP_BODY, ONLY1HOPDIRECT, RCVD_IN_PBL, SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org, feld@feld.me X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 13:58:01 -0000 ----Security_Multipart(Sat_Jun_29_22_56_03_2013_155)-- Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit JINMEI Tatuya / $B?@L@C#:H(B wrote in : ji> > So I guess the question is: what do we do? It looks like we're in ji> > violation of both RFC 3493, Section 5.3 and POSIX 2008, Volume 2, Section ji> > 2.10.20*. ji> ji> ...aside from what FreeBSD should do for ip6.v6only, I personally ji> believe that realistically this issue should be resolved at the ji> application side, i.e., explicitly set the IPV6_V6ONLY socket option ji> to 1 and use both AF_INET (for IPv4) and AF_INET6 (for IPv6, and only ji> for IPv6) sockets. As far as I know this is the most portable ji> behavior. Regarding the rwhois case, I'd first suggest updating the ji> patch with this socket option setting. Hopefully it can be accepted ji> by the upstream because it's most portable. If they still reject it ji> because "it's against the standard" (and even if it's less portable in ji> reality), my next suggestion is to explicitly set the IPV6_V6ONLY ji> socket option to 0. This setting is "redundant" in the sense of ji> standard purity, but hopefully less controversial for those preferring ji> the standard compliance as it only requires a small change and will ji> make it still more portable. ji> ji> Going back to the question of what FreeBSD should do for ip6.v6only: ji> Personally, I'd still suggest keeping the same default because I agree ji> this behavior is sufficiently safer (as noted above) *and* there'll ji> be portability issues anyway (OSes using the different default ji> "religiously" will never change it). But I also understand the ji> argument that standard compliance is more important than debatable ji> safety. In either case, it would help if we provide detailed ji> discussion for the description of this sysctl knob. Agreed. Honestly my patch was not intended for upstream because it was too aggressive (for them). Explicitly dropping IPV6_V6ONLY may be acceptable. I am also for keeping the sysctl knob. Except for Java, most of applications which run on FreeBSD have survived with it. In addition to the points already mentioned, I do not like s/AF_INET/AF_INET6/ replacement like rwhoisd does, and I believe this kind of network programs should be implemented in an AF-independent fashion, not depending on AF_INET6, and handle each available AF separately. It prevents issues in corner cases. -- Hiroki ----Security_Multipart(Sat_Jun_29_22_56_03_2013_155)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHO53MACgkQTyzT2CeTzy3UGQCgx0fPK9zvJl0Fj9/7GIR2ACCW an8AnjxpcFqJTIYcidp5JqcKiAtHFuFe =g1GY -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Jun_29_22_56_03_2013_155)---- From owner-freebsd-net@FreeBSD.ORG Sat Jun 29 19:50:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0DEA38EA for ; Sat, 29 Jun 2013 19:50:52 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id C64B71214 for ; Sat, 29 Jun 2013 19:50:51 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id lf11so1262879vcb.26 for ; Sat, 29 Jun 2013 12:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=cZmgVmIc/6Bgq1fzm49pabbLvnOZstKH0RHlzBKpHuI=; b=tG2d1QrGTqV4sVcBV8IqbShtfiBLftpZdEcXGMHs7DKExpQDxAVR8fjF8+P3fI1EYe wmuofOiXwB2JPdvDSivq5PMBCDSVCxT9xARuKQsyyvuHVd8IYa3Be/XtC0T+N4BkdfEc IE+PIskOmPJPkfl5pYZWs4e1rq1tOyAfW3B3g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=cZmgVmIc/6Bgq1fzm49pabbLvnOZstKH0RHlzBKpHuI=; b=S4f+M0VtgGwZQFeGN8BdLDS7LCMM/5xy3vBJCtQJWIpoYpRK/7Ul9f2JZmXhbto1Tu lhfObZn1cWbcDssud990XfWm8vdUy3Uov28ie6+LqrpHoRZWPlUpPJtYKOzPg/QdhDF/ +egrdbFGV7T6puhQMabHHkrKcEbxQa7wxESLRnkXPOUs6zhFJqKLj1QDd4wLhnF9Jbi6 9bLu1WleEqXIbIxn6ii63WhJIyqYxJb5gJXgKSWsMBojJeJdPPTS57wvGXQ8uqWv1QQs cHjPFcohbtXlRtYaCo75p9EGDTmwzd8F4Wsf+Na0VWKNXqhoUR1LhN6UGvzcFOEljXu3 fAzg== MIME-Version: 1.0 X-Received: by 10.220.123.195 with SMTP id q3mr4647995vcr.64.1372535451267; Sat, 29 Jun 2013 12:50:51 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Sat, 29 Jun 2013 12:50:51 -0700 (PDT) Date: Sat, 29 Jun 2013 12:50:51 -0700 Message-ID: Subject: Looking for a bgp listener that works with RADIX_MPATH / EQMP that's in HEAD From: Peter Wemm To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmhJ9S3yyWoSx4JnZjCP8JMW/dcHPl2o5dRqCgJF1za/kt3LPyZLyRPJTB8AM3tCuKbnpYp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 19:50:52 -0000 I'm looking for pointers to something that can listen to bgp default route announcements from two outbound gateways and set a RADIX_MPATH compatible default route based on whether one or both are alive. openbgpd from ports is extremely incompatible with RADIX_MPATH on 10. You *have* to turn off fib (kernel routing table) updates or it will destroy your machine when it runs out of physical memory for duplicate routes. I know I can do an evil hack and poll the 'bgp show ...' output and manually update the default route but that means updates are delayed to the poll interval. I'm hoping there is a more elegant solution that already works and is immediately responsive to a change in bgp state. The caveat is it *must* run on 10.x, with RADIX_MPATH enabled. I'd gladly run openbgpd if it actually worked. openbgpd has some awareness of mpath so it might be fixable but openbsd's multipath is different to ours. Ideas? -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV From owner-freebsd-net@FreeBSD.ORG Sat Jun 29 20:28:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 47AECA1C for ; Sat, 29 Jun 2013 20:28:32 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm15-vm2.bullet.mail.ne1.yahoo.com (nm15-vm2.bullet.mail.ne1.yahoo.com [98.138.91.91]) by mx1.freebsd.org (Postfix) with ESMTP id DD6DC1385 for ; Sat, 29 Jun 2013 20:28:31 +0000 (UTC) Received: from [98.138.90.48] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2013 20:28:30 -0000 Received: from [98.138.104.114] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2013 20:28:30 -0000 Received: from [127.0.0.1] by smtp223.mail.ne1.yahoo.com with NNFMP; 29 Jun 2013 20:28:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372537710; bh=bj47C0/4VWO1oJutNU8kqVSTILrLN6nJ7/MxBjE/WDA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=vszTXAUkyi2foh6ywbFxWRX+7UWRH2oyy7Alg2g41rYKuRa6JgnEZEmwdHHSzQKqM3W8k8aHbdr6F4UDy5itPqvzuRMKhfgxmmodZXw5Zhpf9ijb3TljrCSlh3HkOsdj/QB4YhsvB7cTXKaQXcWD272Z/glVICskCvzKbEzjCyo= X-Yahoo-Newman-Id: 957172.89340.bm@smtp223.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MwiMOOQVM1kNm4TNbB1IAXPj8JYFExcFOti3NPlkYlyf66. vQZeLy8DqL2xb5Lra6hNzYdvLXpBV.89c0p_dSUmTcTW9_56J5krZvybiglv q1ogTBEczBX6MlPcmsxf17Q8HuVAMkAvGBVKpIY.eJURMpaiNYL5IYvMymRw Tn94r7IOF7H0GIvJRQ0_YN0eFOismoBOKdmGgvtwKBe6GYrN.L3doujGqe5U EpGdEgzlmtye7PRN6qgS7qdKOvKh_r6oKDjSaFjfLAkef3m0uWy_Pp8g_C3f 5zm1Jgc0JZt5xOSdkOnFMJaBPDsNru47lza9ocJEOzznOvyoFMEBv2eNXuF6 Y6luGDODxnhLJrWPrmxEiuNh1dRxQr3Okd_zOWK14V7_CR_MWZR9hEkeKwLe 34MPjyNEXV2ol_sRuHnnJa6lVtfZdjFyw8P81hQG4MROZR__AKTFh.UKV8Ar Q4whkX7avgFQzgI1SKxrjczTDuxK63NrQkLtlo3KPA9XgNm_msgJxWK64J7D ZCwdwb_.a_O4ZkSOXd6kC2vycvxIY7dsqBV2uQRkdboYYlHIPOh94Y6H0fik zzL4- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from lglt-nvaradarajan.corp.netflix.com (scott4long@69.53.237.126 with ) by smtp223.mail.ne1.yahoo.com with SMTP; 29 Jun 2013 20:28:30 +0000 UTC Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Looking for a bgp listener that works with RADIX_MPATH / EQMP that's in HEAD From: Scott Long In-Reply-To: Date: Sat, 29 Jun 2013 14:28:28 -0600 Content-Transfer-Encoding: 7bit Message-Id: <945C1E9B-0FEE-4999-AFFB-9AA04336F06A@yahoo.com> References: To: Peter Wemm X-Mailer: Apple Mail (2.1508) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 20:28:32 -0000 We run bird for this task. Can't say if it works on 10 since he haven't moved to 10 yet, but there have been some experiments with running a 10 kernel in the 9 userland and bird seems to behave fine with that. Scott On Jun 29, 2013, at 1:50 PM, Peter Wemm wrote: > I'm looking for pointers to something that can listen to bgp default > route announcements from two outbound gateways and set a RADIX_MPATH > compatible default route based on whether one or both are alive. > > openbgpd from ports is extremely incompatible with RADIX_MPATH on 10. > You *have* to turn off fib (kernel routing table) updates or it will > destroy your machine when it runs out of physical memory for duplicate > routes. > > I know I can do an evil hack and poll the 'bgp show ...' output and > manually update the default route but that means updates are delayed > to the poll interval. I'm hoping there is a more elegant solution > that already works and is immediately responsive to a change in bgp > state. > > The caveat is it *must* run on 10.x, with RADIX_MPATH enabled. I'd > gladly run openbgpd if it actually worked. openbgpd has some > awareness of mpath so it might be fixable but openbsd's multipath is > different to ours. > > Ideas? > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV > _______________________________________________ > 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 Sat Jun 29 20:43:29 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EC86BBD3 for ; Sat, 29 Jun 2013 20:43:28 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id C17141463 for ; Sat, 29 Jun 2013 20:43:27 +0000 (UTC) Received: from alph.d.allbsd.org (p3086-ipbf906funabasi.chiba.ocn.ne.jp [122.26.46.86]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r5TKh9Nw004160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jun 2013 05:43:19 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r5TKh6e6097502; Sun, 30 Jun 2013 05:43:09 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 30 Jun 2013 05:42:58 +0900 (JST) Message-Id: <20130630.054258.1958564335251044000.hrs@allbsd.org> To: peter@wemm.org Subject: Re: Looking for a bgp listener that works with RADIX_MPATH / EQMP that's in HEAD From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Jun_30_05_42_58_2013_630)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sun, 30 Jun 2013 05:43:20 +0900 (JST) X-Spam-Status: No, score=-89.5 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,ONLY1HOPDIRECT,RCVD_IN_PBL,SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 20:43:29 -0000 ----Security_Multipart(Sun_Jun_30_05_42_58_2013_630)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter Wemm wrote in : pe> I'm looking for pointers to something that can listen to bgp default pe> route announcements from two outbound gateways and set a RADIX_MPATH pe> compatible default route based on whether one or both are alive. pe> pe> openbgpd from ports is extremely incompatible with RADIX_MPATH on 10. pe> You *have* to turn off fib (kernel routing table) updates or it will pe> destroy your machine when it runs out of physical memory for duplicate pe> routes. pe> pe> I know I can do an evil hack and poll the 'bgp show ...' output and pe> manually update the default route but that means updates are delayed pe> to the poll interval. I'm hoping there is a more elegant solution pe> that already works and is immediately responsive to a change in bgp pe> state. pe> pe> The caveat is it *must* run on 10.x, with RADIX_MPATH enabled. I'd pe> gladly run openbgpd if it actually worked. openbgpd has some pe> awareness of mpath so it might be fixable but openbsd's multipath is pe> different to ours. pe> pe> Ideas? Unfortunately openbgpd does not work well with RADIX_MPATH yet. As you pointed out, it is due to difference of multiple routes support between FreeBSD and OpenBSD. I think FIB handling can be improved, but needs some more investigation for that. I think Quagga and BIRD can work with injecting ECMP routes into RADIX_MPATH-enabled FIB. -- Hiroki ----Security_Multipart(Sun_Jun_30_05_42_58_2013_630)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHPRtIACgkQTyzT2CeTzy3IcwCaA5FjFqz4rXU9trkwW9/jCSnJ 0qMAoN//M0QJMlHz3wLiEIHbjM9JTPRf =u4l6 -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jun_30_05_42_58_2013_630)---- From owner-freebsd-net@FreeBSD.ORG Sat Jun 29 20:48:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3942DD6C for ; Sat, 29 Jun 2013 20:48:58 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id ED6B9148A for ; Sat, 29 Jun 2013 20:48:57 +0000 (UTC) Received: by mail-vb0-f47.google.com with SMTP id x14so2608311vbb.20 for ; Sat, 29 Jun 2013 13:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/vjV/XrhRd4HdNignPPIBCKNgvyfa990+XwY6wrhAYw=; b=uf+6dbdAtsX/icGvTV9Ld+Mj5iJG2IVpFBo88GQkaJYydCs9GPFPW/prOxbT+GLvPF wWb57hrzC4n37zsUqn7cKsY+XGySWn4PMoGG/y+JD7wGMr4Y2VSfgm0H5ycPFU4sVL9M hfy5NsYKY+FLSFCrSQ2VB830P1m3AokQL7Fp0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/vjV/XrhRd4HdNignPPIBCKNgvyfa990+XwY6wrhAYw=; b=ScucZ67GSWfcC8+TeLmubROygwf74pa3IQcm+qKn3LRsdPIHcytlVeEihSyKaZevD+ EsFh7m/PXodXN49MZyTcZ4gtt/0hg/NQ0vXmOjuvwNT0V2eIJHIR7EmMPy581FCFXrx5 2gc5oi2Z4ehTz4T9q5ohFtzeZ3YITZWeImG+G+SRoYK0rHnHejyT8f9sUEZQQe5UhpDW 9AYRsYj82sO75c+gSeKrTsiWYD6b2VAD9iUETVPaj2dOhnreezejdoz6SiY2RcjKGqs9 uxWNad1i+t81HuJs2FbjeH+mTMPNDySvNypRQh8N6BG0QMDRXASc2LbVeSEJcg32dqd2 h0fA== MIME-Version: 1.0 X-Received: by 10.220.83.69 with SMTP id e5mr4868017vcl.53.1372538937174; Sat, 29 Jun 2013 13:48:57 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Sat, 29 Jun 2013 13:48:57 -0700 (PDT) In-Reply-To: <945C1E9B-0FEE-4999-AFFB-9AA04336F06A@yahoo.com> References: <945C1E9B-0FEE-4999-AFFB-9AA04336F06A@yahoo.com> Date: Sat, 29 Jun 2013 13:48:57 -0700 Message-ID: Subject: Re: Looking for a bgp listener that works with RADIX_MPATH / EQMP that's in HEAD From: Peter Wemm To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkA4AkCRvTuJBGiG/he6eEV2ELneHDvAWnI5X5Chd/lNptRM83hgqX2sNh8ZE66s5Vd6KIG Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 20:48:58 -0000 On Sat, Jun 29, 2013 at 1:28 PM, Scott Long wrote: > We run bird for this task. Can't say if it works on 10 since he haven't > moved to 10 yet, but there have been some experiments with running > a 10 kernel in the 9 userland and bird seems to behave fine with that. > > Scott You run your kernels with RADIX_MPATH on 9.x? Got an example config? In openbgpd speak, I'm doing this: AS 65xxx router-id 8.8.178.xx neighbor 8.8.178.yy { local-address 8.8.178.xx remote-as 65xxx announce none } neighbor 8.8.178.zz { local-address 8.8.178.xx remote-as 65xxx announce none } match from 8.8.178.yy set { localpref 80 } match from 8.8.178.zz set { localpref 80 } The upstream nodes are doing, in part: neighbor 8.8.178.ww { local-address 8.8.178.yy remote-as 65xxx announce default-route } neighbor 8.8.178.xx { local-address 8.8.178.yy remote-as 65xxx announce default-route } match to 8.8.178.ww set { metric 20 } match to 8.8.178.xx set { metric 20 } They're doing other things too, but thats the part that's relevant here. > On Jun 29, 2013, at 1:50 PM, Peter Wemm wrote: > >> I'm looking for pointers to something that can listen to bgp default >> route announcements from two outbound gateways and set a RADIX_MPATH >> compatible default route based on whether one or both are alive. >> >> openbgpd from ports is extremely incompatible with RADIX_MPATH on 10. >> You *have* to turn off fib (kernel routing table) updates or it will >> destroy your machine when it runs out of physical memory for duplicate >> routes. >> >> I know I can do an evil hack and poll the 'bgp show ...' output and >> manually update the default route but that means updates are delayed >> to the poll interval. I'm hoping there is a more elegant solution >> that already works and is immediately responsive to a change in bgp >> state. >> >> The caveat is it *must* run on 10.x, with RADIX_MPATH enabled. I'd >> gladly run openbgpd if it actually worked. openbgpd has some >> awareness of mpath so it might be fixable but openbsd's multipath is >> different to ours. >> >> Ideas? >> -- >> Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV >> _______________________________________________ >> 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" > -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV On IRC, talking about C++: I think that it is a good thing I will never meet Bjarne on a street cause really, I don't want to end up in prison or anything From owner-freebsd-net@FreeBSD.ORG Sat Jun 29 20:56:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA496EC2 for ; Sat, 29 Jun 2013 20:56:23 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 894F915ED for ; Sat, 29 Jun 2013 20:56:23 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id 14so2791753vea.1 for ; Sat, 29 Jun 2013 13:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y0+mYB5MS6np1ZTCEiqL2zJQw0yL8CJsfGiweRrJemU=; b=ofTIzZBn3JJeZihsOu/Wz2csEKmPlJXqaNFi/PqUMU7zj/ssLYdCydH3v0IL6dDEl+ TxfgaiUK4x4Cs4TFDO2+RSIspu8eO8ctAeV1Lv2QvVsKEXGcy1vQpEcsHeXmh64nqc+p 9o7t4xDR7EqMTMLfwQrq9E3UdAL7X23tXEeM0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Y0+mYB5MS6np1ZTCEiqL2zJQw0yL8CJsfGiweRrJemU=; b=o9/qSepc95lCv6obgrpNYXtvbut6pbPNCj0jj52Jrq2lKWzhWbeF+ZVZwKufv8thtk 2IS5tDdoLv8Wf3k/ijPBmlPLrNu08YrNln18Y2G6c4RIJyQzobq/AdBMOL66oQ8Zzh/W 5mTRhaIKEg9vhgLegtxutokvvhZebEnmcZy/OL2c4OsvaoWy6D3FR5Zwa4gFSTqFqejL dmqxL0lurTBXFSugwVNQF4JT0L7W7/jGKSbJPEsQkQ+lVFoxVUmYg7ntqrgI2+7jb0gH cjub9Y6boVp4KiHOC6hpLqT2wINPXKJOLqHvwB4i469PGyqOF1bO6MPE4wFMBEfiq1Ck 9Ogg== MIME-Version: 1.0 X-Received: by 10.52.93.244 with SMTP id cx20mr2969032vdb.114.1372539383034; Sat, 29 Jun 2013 13:56:23 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Sat, 29 Jun 2013 13:56:22 -0700 (PDT) In-Reply-To: <20130630.054258.1958564335251044000.hrs@allbsd.org> References: <20130630.054258.1958564335251044000.hrs@allbsd.org> Date: Sat, 29 Jun 2013 13:56:22 -0700 Message-ID: Subject: Re: Looking for a bgp listener that works with RADIX_MPATH / EQMP that's in HEAD From: Peter Wemm To: Hiroki Sato Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkwetklKBhx6r7bjU6/LzwrCM2Fy2Aqb2cBuztzNVvxALpBey0khGj4GBiBfUOwm7+PUjS8 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 20:56:23 -0000 On Sat, Jun 29, 2013 at 1:42 PM, Hiroki Sato wrote: > Peter Wemm wrote > in : > > pe> I'm looking for pointers to something that can listen to bgp default > pe> route announcements from two outbound gateways and set a RADIX_MPATH > pe> compatible default route based on whether one or both are alive. > pe> > pe> openbgpd from ports is extremely incompatible with RADIX_MPATH on 10. > pe> You *have* to turn off fib (kernel routing table) updates or it will > pe> destroy your machine when it runs out of physical memory for duplicate > pe> routes. > pe> > pe> I know I can do an evil hack and poll the 'bgp show ...' output and > pe> manually update the default route but that means updates are delayed > pe> to the poll interval. I'm hoping there is a more elegant solution > pe> that already works and is immediately responsive to a change in bgp > pe> state. > pe> > pe> The caveat is it *must* run on 10.x, with RADIX_MPATH enabled. I'd > pe> gladly run openbgpd if it actually worked. openbgpd has some > pe> awareness of mpath so it might be fixable but openbsd's multipath is > pe> different to ours. > pe> > pe> Ideas? > > Unfortunately openbgpd does not work well with RADIX_MPATH yet. As > you pointed out, it is due to difference of multiple routes support > between FreeBSD and OpenBSD. I think FIB handling can be improved, > but needs some more investigation for that. Yes, the port is extremely dangerous if RADIX_MPATH is enabled. It does this sort of thing: cmd = RTM_ADD retry: error = routectl(cmdl, data); if (error && cmd == RTM_ADD) { cmd = RTM_CHANGE; goto retry; } In short, it creates duplicates every single time there's a fib change if you enable RADIX_MPATH. This does not end well. It appears that openbsd allows multiple overlapping routes to coexist if they have a MPATH flag on them. Our radix structure is quite different from what I understand, but the routing socket interface causes openbgpd to accidently work and spam the rables. > I think Quagga and BIRD can work with injecting ECMP routes into > RADIX_MPATH-enabled FIB. > > -- Hiroki I'm looking for some examples. See the bgpd.conf fragments I sent Scott. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV On IRC, talking about C++: I think that it is a good thing I will never meet Bjarne on a street cause really, I don't want to end up in prison or anything