From owner-freebsd-net@FreeBSD.ORG Sun Feb 27 11:08:50 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 410C1106566C for ; Sun, 27 Feb 2011 11:08:50 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 884E88FC08 for ; Sun, 27 Feb 2011 11:08:48 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p1RB8iJw016569 for ; Sun, 27 Feb 2011 17:08:45 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D6A30B7.2010001@rdtc.ru> Date: Sun, 27 Feb 2011 17:08:39 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: ipfw nat and dual-homed box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 11:08:50 -0000 Hi! Consider LAN using private IP addresses and NAT box with two uplinks to distinct internet providers each of which supplies us with one public IP only. With natd's "multiple instances" feature it's easy to setup dual-homed NAT box correctly, so that replies for incoming packets get translated right, no matter what routing table thinks about outgoing interface for such reply. ipfw configuration: divert 8668 ip from any to any in recv $if0 # Deal with incoming packets. divert 8669 ip from any to any in recv $if1 divert 8000 ip from any to any out xmit $if0 # For outgoing packets, first try to find existing divert 8000 ip from any to any out xmit $if1 # translation table entry in all NAT instances and use it. divert 8668 ip from any to any out xmit $if0 # Create new translation entry only if it was found nowhere. divert 8669 ip from any to any out xmit $if1 fwd $if0_gate ip from $if0_ip to any out xmit $if1 # Force packet go out right interface. fwd $if1_gate ip from $if1_ip to any out xmit $if0 Corresponding natd configuration file: instance default port 8668 interface $if0 unregistered_only yes instance second port 8669 interface $if1 unregistered_only yes globalport 8000 #EOF For performance reasons, I need to create similar setup using in-kernel "ipfw nat" what does not have such "multiple instances" feature but has its own "keep-state" mechanics: nat config if $if0 unreg_only nat config if $if1 unreg_only nat 123 ip from any to any via $if0 keep-state # For incoming packets create dynamic rule. nat 124 ip from any to any via $if1 keep-state # For outgoing packet use corresponding NAT instance. fwd $if0_gate ip from $if0_ip to any out xmit $if1 # Force packet go out right interface. fwd $if1_gate ip from $if1_ip to any out xmit $if0 This works just fine if we do not try to use ipfw nat's port forwarding. Here it breaks because "keep-state" creates dynamic rule for incoming connections before translation's done, so it records external IP of the box as destination IP. Hence, replies will be translated using wrong NAT instance when routing table chooses wrong outgoing interface - replies won't match ipfw's dynamic rules. I think this is a bug in 8.2-STABLE. Am I right? Or, perhaps, there is another way to setup ipfw nat for dual-homed LAN? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Feb 27 11:29:47 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07BC4106564A for ; Sun, 27 Feb 2011 11:29:47 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 672728FC0A for ; Sun, 27 Feb 2011 11:29:45 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p1RBTiQI016694 for ; Sun, 27 Feb 2011 17:29:44 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D6A35A3.7060303@rdtc.ru> Date: Sun, 27 Feb 2011 17:29:39 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" References: <4D6A30B7.2010001@rdtc.ru> In-Reply-To: <4D6A30B7.2010001@rdtc.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: ipfw nat and dual-homed box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 11:29:47 -0000 On 27.02.2011 17:08, Eugene Grosbein wrote: [skip] > For performance reasons, I need to create similar setup using in-kernel "ipfw nat" > what does not have such "multiple instances" feature but has its own "keep-state" mechanics: To correct myself: of course, ipfw nat has multiple instances... It does not offer something like natd's "globalport" feature to check all NAT instances for entry before creation of new one. > nat config if $if0 unreg_only > nat config if $if1 unreg_only > nat 123 ip from any to any via $if0 keep-state # For incoming packets create dynamic rule. > nat 124 ip from any to any via $if1 keep-state # For outgoing packet use corresponding NAT instance. > fwd $if0_gate ip from $if0_ip to any out xmit $if1 # Force packet go out right interface. > fwd $if1_gate ip from $if1_ip to any out xmit $if0 > > This works just fine if we do not try to use ipfw nat's port forwarding. > Here it breaks because "keep-state" creates dynamic rule for incoming connections > before translation's done, so it records external IP of the box as destination IP. > Hence, replies will be translated using wrong NAT instance when routing table > chooses wrong outgoing interface - replies won't match ipfw's dynamic rules. > > I think this is a bug in 8.2-STABLE. Am I right? > Or, perhaps, there is another way to setup ipfw nat for dual-homed LAN? From owner-freebsd-net@FreeBSD.ORG Sun Feb 27 20:24:16 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0006106564A for ; Sun, 27 Feb 2011 20:24:16 +0000 (UTC) (envelope-from fernando.gont.netbook.win@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 47DB08FC08 for ; Sun, 27 Feb 2011 20:24:15 +0000 (UTC) Received: by yie12 with SMTP id 12so499904yie.13 for ; Sun, 27 Feb 2011 12:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=2ZXoIoCPmUbMxmk81g4udqESTm4Zk6xj0KY7BYxNEJ4=; b=OdwXuxgK0ITouqPATfQYtTOjMpRxY2rT13WTMP2nzoQvPR0f9R72QS6I+A2ismZ/M3 OTxr1HqeXOZ4BsTGjCVsGsFHu9IbiQHncMmqRhCI83IcA1duBur5Vo5L0ZhAnK0BIpWH 1lCQPFkKquIIcRY1d5TJmloZ+XS4XP7qoISRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=lretUvzV4wXg4YEfd01ZM18Lq4Y5P1mJDV5Rp/lS9h0TKbUckWVZVEJpPfMKIxnjX6 9goVxQEwzLZeP15Buc/0Dr5fM1lzQaj9FYVAUx7Gyv03lZ6T0JAtHrQLOCjReq8E13BI bSnKc8KoMvHOQllJD3zRY1Eam2KPesn+fzaqs= Received: by 10.151.50.14 with SMTP id c14mr6261471ybk.66.1298838255251; Sun, 27 Feb 2011 12:24:15 -0800 (PST) Received: from [192.168.0.120] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id m38sm1019396yhb.32.2011.02.27.12.24.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Feb 2011 12:24:12 -0800 (PST) Sender: Fernando Gont Message-ID: <4D6AB2BD.50208@gont.com.ar> Date: Sun, 27 Feb 2011 17:23:25 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Barton References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> <4D437B13.1070405@FreeBSD.org> <4D518FB3.3040503@FreeBSD.org> In-Reply-To: <4D518FB3.3040503@FreeBSD.org> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Ivo Vachkov , bz@freebsd.org Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 20:24:16 -0000 On 08/02/2011 03:47 p.m., Doug Barton wrote: [catching up with e-mail] > I've been up and running on this patch vs. r218391 for over 24 hours > now, using algorithm 4 (as someone said is now the default in Linux) > without any problems. > > I think Bjoern is better qualified than I to comment on the style of the > patch, but it applies cleanly, and seems to run fine on both v4 and v6. Has this been commited to the tree, already? -- If so, what's the default algorithm? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Sun Feb 27 20:38:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A6E79106566C; Sun, 27 Feb 2011 20:38:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6ECC814E37F; Sun, 27 Feb 2011 20:38:14 +0000 (UTC) Message-ID: <4D6AB636.3030708@FreeBSD.org> Date: Sun, 27 Feb 2011 12:38:14 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> <4D437B13.1070405@FreeBSD.org> <4D518FB3.3040503@FreeBSD.org> <4D6AB2BD.50208@gont.com.ar> In-Reply-To: <4D6AB2BD.50208@gont.com.ar> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Ivo Vachkov , bz@freebsd.org Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 20:38:14 -0000 On 02/27/2011 12:23, Fernando Gont wrote: > On 08/02/2011 03:47 p.m., Doug Barton wrote: > > [catching up with e-mail] > >> I've been up and running on this patch vs. r218391 for over 24 hours >> now, using algorithm 4 (as someone said is now the default in Linux) >> without any problems. >> >> I think Bjoern is better qualified than I to comment on the style of the >> patch, but it applies cleanly, and seems to run fine on both v4 and v6. > > Has this been commited to the tree, already? -- If so, what's the > default algorithm? Bjoern was planning to do it, I'm going to do it if he doesn't get around to it. As for default algorithm, is there any reason not to make it 4? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Sun Feb 27 21:04:05 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF527106566B; Sun, 27 Feb 2011 21:04:05 +0000 (UTC) (envelope-from fernando.gont.netbook.win@gmail.com) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx1.freebsd.org (Postfix) with ESMTP id 636C88FC12; Sun, 27 Feb 2011 21:04:05 +0000 (UTC) Received: by gwaa18 with SMTP id a18so3190611gwa.17 for ; Sun, 27 Feb 2011 13:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=E6zBRrVFYufDaokt96+mfZqadEh/ZMRcoeSNr7dR6oc=; b=iWEeMb3sHt7p0bQIxsz8JJVXCXmfVfHTdTf2dO3QOcnjU7tkSS06ZwPIEIPXJOWxAg /HEEpETi8ztRDnH3Ylj62bJv7C+eBBRFtJprT9x49cNqUh8qy6sZw9Oqx6aSjwvtB1Tu aw08Lbg2HWk7peQ8paADVU+203YYUU4o/Cn4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=FRVado/Cj9NlekkGWXrWYFI3AxTnTmoXgIHsylImNAI+JQgFEI8hyFzAkbZfsR3u0b QBQiP9tUNt1CF41G5sug4NmdcGp8x65FW+GCxWKjmyn3oPo0tyvzcFDO100ByTzDg12D vkgByxAiHnn5KKtT4yX1IlsP1e9c/HqYAeKE4= Received: by 10.236.108.43 with SMTP id p31mr8285661yhg.69.1298840644568; Sun, 27 Feb 2011 13:04:04 -0800 (PST) Received: from [192.168.0.120] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id u45sm1687034yhn.9.2011.02.27.13.03.45 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Feb 2011 13:04:03 -0800 (PST) Sender: Fernando Gont Message-ID: <4D6ABBB7.9060807@gont.com.ar> Date: Sun, 27 Feb 2011 18:01:43 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Barton References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> <4D437B13.1070405@FreeBSD.org> <4D518FB3.3040503@FreeBSD.org> <4D6AB2BD.50208@gont.com.ar> <4D6AB636.3030708@FreeBSD.org> In-Reply-To: <4D6AB636.3030708@FreeBSD.org> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Ivo Vachkov , bz@FreeBSD.org Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 21:04:06 -0000 On 27/02/2011 05:38 p.m., Doug Barton wrote: >> Has this been commited to the tree, already? -- If so, what's the >> default algorithm? > > Bjoern was planning to do it, I'm going to do it if he doesn't get > around to it. > > As for default algorithm, is there any reason not to make it 4? Not at all. Algorithm 4 (double-hash) is the best option, IMO. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Sun Feb 27 22:22:11 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 536AE106566C; Sun, 27 Feb 2011 22:22:11 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id F0A058FC18; Sun, 27 Feb 2011 22:22:10 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 9079725D37C4; Sun, 27 Feb 2011 22:05:04 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 416901599997; Sun, 27 Feb 2011 22:05:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id g7lSGjdJB+U4; Sun, 27 Feb 2011 22:05:02 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3C34115999B0; Sun, 27 Feb 2011 22:05:01 +0000 (UTC) Date: Sun, 27 Feb 2011 22:05:01 +0000 (UTC) From: "Bjoern A. Zeeb" To: Fernando Gont In-Reply-To: <4D6ABBB7.9060807@gont.com.ar> Message-ID: References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> <4D437B13.1070405@FreeBSD.org> <4D518FB3.3040503@FreeBSD.org> <4D6AB2BD.50208@gont.com.ar> <4D6AB636.3030708@FreeBSD.org> <4D6ABBB7.9060807@gont.com.ar> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net , Ivo Vachkov , Doug Barton Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 22:22:11 -0000 On Sun, 27 Feb 2011, Fernando Gont wrote: Hi, > On 27/02/2011 05:38 p.m., Doug Barton wrote: > >>> Has this been commited to the tree, already? -- If so, what's the >>> default algorithm? >> >> Bjoern was planning to do it, I'm going to do it if he doesn't get >> around to it. >> >> As for default algorithm, is there any reason not to make it 4? > > Not at all. Algorithm 4 (double-hash) is the best option, IMO. I am still planning to do it soon but there is another thing in the queue touching the pcb code, which are way harder to merge on conflicts than this, so I am waiting for that to happen first. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Sun Feb 27 22:29:42 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 963891065672; Sun, 27 Feb 2011 22:29:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4543C155879; Sun, 27 Feb 2011 22:29:42 +0000 (UTC) Message-ID: <4D6AD055.20506@FreeBSD.org> Date: Sun, 27 Feb 2011 14:29:41 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> <4D437B13.1070405@FreeBSD.org> <4D518FB3.3040503@FreeBSD.org> <4D6AB2BD.50208@gont.com.ar> <4D6AB636.3030708@FreeBSD.org> <4D6ABBB7.9060807@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Ivo Vachkov Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 22:29:42 -0000 On 02/27/2011 14:05, Bjoern A. Zeeb wrote: > On Sun, 27 Feb 2011, Fernando Gont wrote: > > Hi, > >> On 27/02/2011 05:38 p.m., Doug Barton wrote: >> >>>> Has this been commited to the tree, already? -- If so, what's the >>>> default algorithm? >>> >>> Bjoern was planning to do it, I'm going to do it if he doesn't get >>> around to it. >>> >>> As for default algorithm, is there any reason not to make it 4? >> >> Not at all. Algorithm 4 (double-hash) is the best option, IMO. > > I am still planning to do it soon but there is another thing in the > queue touching the pcb code, which are way harder to merge on > conflicts than this, so I am waiting for that to happen first. Do you have a timeline? It's been weeks since you and I first spoke about this, and I really don't want this change to get lost in the shuffle, or worse, to be committed late in the pre-release cycle for 9.0 (which will mean it won't get adequate testing). The patch as posted applied cleanly to HEAD when I did it locally, and I can generate a clean patch from my local tree if needed. My vote is that because the port randomization patch is ready to go now, it should go in, and other work that isn't ready will have to adapt. But I'm willing to hold off for another week for a really good reason. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 02:30:19 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 328D81065670; Mon, 28 Feb 2011 02:30:19 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 22A6B8FC08; Mon, 28 Feb 2011 02:30:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1S2UJ0b015327; Mon, 28 Feb 2011 02:30:19 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1S2UITt015284; Mon, 28 Feb 2011 02:30:18 GMT (envelope-from yongari) Date: Mon, 28 Feb 2011 02:30:18 GMT Message-Id: <201102280230.p1S2UITt015284@freefall.freebsd.org> To: jcigar@ulb.ac.be, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/154959: [age] "Bad packet length xxxxx, Disconnecting: Packet corrupt" (unless TSO, rxcsum, txcsum are disabled) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 02:30:19 -0000 Synopsis: [age] "Bad packet length xxxxx, Disconnecting: Packet corrupt" (unless TSO, rxcsum, txcsum are disabled) State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Feb 28 02:25:46 UTC 2011 State-Changed-Why: I guess TSO and TX checksum offloading have nothing to do with the issue you're seeing. If age(4) generated corrupted packets via TSO/TX checksum offloading, receiver may have dropped these corrupted packets. Anyway, would you try the patch at the following URL and let me know how it goes? http://people.freebsd.org/~yongari/age/age.csum.diff I don't have access to age(4) hardwares any more so it was not tested. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Feb 28 02:25:46 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=154959 From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 03:40:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60D47106564A for ; Mon, 28 Feb 2011 03:40:59 +0000 (UTC) (envelope-from ulsanrub@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2C1C38FC14 for ; Mon, 28 Feb 2011 03:40:58 +0000 (UTC) Received: by iyj12 with SMTP id 12so2902772iyj.13 for ; Sun, 27 Feb 2011 19:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=oSmoJTqvqx/HfC3/nNVmQtbyS6Eojrnw9OOf1RRyXy4=; b=HxHuJdTaG/+lOR/a+KAPykKEtKFOjrzVXePfSVprQ5kQSlgwu6xOvQfOr6bbu8RcwQ B0y4cL439ODFGcA5Awj3GaO+PkadQvLX0uRKRWJ/eGsi66Ji3J/5lqkRlINB19WkqCzt oEdkIi93wV7eHoQUoQb7EvZxZkjjCJ6zNKJrg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cIC2KV7+g/5VpZcUhnF7ESYo9GmwK9LUh/uLIyQyP1Q+OvL9SlxLgu3j35lJJWIetN +Zt3JL76kNdd+b0IzvH+EI8afYUkCzpnoXXVYLGyCDfqDM04wocGc4SnaclUN0v71UkF s6Rn0uUqVVWkXrNFnKTEqmU/RubsTGXpPnL38= MIME-Version: 1.0 Received: by 10.42.173.10 with SMTP id p10mr4365442icz.49.1298862859442; Sun, 27 Feb 2011 19:14:19 -0800 (PST) Received: by 10.42.229.10 with HTTP; Sun, 27 Feb 2011 19:14:19 -0800 (PST) Date: Sun, 27 Feb 2011 22:14:19 -0500 Message-ID: From: Kyungsoo Lee To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Mini PCI express cards for TDMA on FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 03:40:59 -0000 Hi guys, anyone uses mini PCI express cards for TDMA on FreeBSD? I tried to use Anatel AR5BXB6 on IBM laptops. But it doesn't work when I set the node as Master(tdmaslot 0) with PANIC or "ATH0: stuck beacons;..". Is there any solution to solve the above problem? Or does anybody succeed to use TDMA on FreeBSD with mini PCI-e cards? Please, let me know how to solve or the name of the mini PCI-e card which works well for FreeBSD TDMA. FYI, I set the node with the below command. "ifconfig wlan create wlandev ath0 wlanmode tdma tdmaslot 0 up" Thanks, K. From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 11:07:03 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BCB21065670 for ; Mon, 28 Feb 2011 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 88BD28FC1E for ; Mon, 28 Feb 2011 11:07:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1SB73F0012033 for ; Mon, 28 Feb 2011 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1SB72Jo012031 for freebsd-net@FreeBSD.org; Mon, 28 Feb 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Feb 2011 11:07:02 GMT Message-Id: <201102281107.p1SB72Jo012031@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 11:07:03 -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/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/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154831 net [arp] [patch] arp sysctl setting log_arp_permanent_mod o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154676 net [netgraph] [panic] HEAD, 8.1-RELEASE panic after some o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154567 net [ath] ath(4) lot of bad series(0) 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/154284 net [ath] Modern ath wifi cards (such as AR9285) have miss 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 o 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/154006 net [tcp] [patch] tcp "window probe" bug on 64bit o kern/153938 net [run] [panic] [patch] Workaround for use-after-free pa 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/153671 net [em] [panic] 8.2-PRERELEASE repeatable kernel in if_em 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/153255 net [panic] 8.2-PRERELEASE repeatable kernel panic under h 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/152360 net [dummynet] [panic] Crash related to dummynet. 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/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 bin/150642 net netstat(1) doesn't print anything for SCTP sockets 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/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall 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/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning 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 o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho 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 o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u 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 bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. o kern/144987 net [wpi] [panic] injecting packets with wlaninject using 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/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to 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/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout 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 conf/143079 net hostapd(8) startup missing multi wlan functionality 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 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/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault 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 o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/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/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o 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 kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re 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/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/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 o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/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/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o 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 [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/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 conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/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 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/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic o kern/125501 net [ath] atheros cardbus driver hangs f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa f kern/125332 net [ath] [panic] crash under any non-tiny networking unde o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/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 [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not 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 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node 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/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/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 p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/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/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! 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/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/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] f kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/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 [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working 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/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi 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 [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip 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 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/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r 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 o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time 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 [ipf] ipfilter ipnat problem with h323 proxy support 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 o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 383 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 16:44:29 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D67C01065672 for ; Mon, 28 Feb 2011 16:44:29 +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 A96348FC1B for ; Mon, 28 Feb 2011 16:44:29 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p1SGiGhY085216 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 28 Feb 2011 08:44:28 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D6BD0DE.1080301@freebsd.org> Date: Mon, 28 Feb 2011 08:44:14 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eugene Grosbein References: <4D6A30B7.2010001@rdtc.ru> <4D6A35A3.7060303@rdtc.ru> In-Reply-To: <4D6A35A3.7060303@rdtc.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "net@freebsd.org" Subject: Re: ipfw nat and dual-homed box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:44:29 -0000 On 2/27/11 3:29 AM, Eugene Grosbein wrote: > On 27.02.2011 17:08, Eugene Grosbein wrote: > > [skip] > >> For performance reasons, I need to create similar setup using in-kernel "ipfw nat" >> what does not have such "multiple instances" feature but has its own "keep-state" mechanics: > To correct myself: of course, ipfw nat has multiple instances... It does not offer > something like natd's "globalport" feature to check all NAT instances for entry > before creation of new one. > >> nat config if $if0 unreg_only >> nat config if $if1 unreg_only >> nat 123 ip from any to any via $if0 keep-state # For incoming packets create dynamic rule. >> nat 124 ip from any to any via $if1 keep-state # For outgoing packet use corresponding NAT instance. >> fwd $if0_gate ip from $if0_ip to any out xmit $if1 # Force packet go out right interface. >> fwd $if1_gate ip from $if1_ip to any out xmit $if0 >> >> This works just fine if we do not try to use ipfw nat's port forwarding. >> Here it breaks because "keep-state" creates dynamic rule for incoming connections >> before translation's done, so it records external IP of the box as destination IP. >> Hence, replies will be translated using wrong NAT instance when routing table >> chooses wrong outgoing interface - replies won't match ipfw's dynamic rules. >> >> I think this is a bug in 8.2-STABLE. Am I right? >> Or, perhaps, there is another way to setup ipfw nat for dual-homed LAN? Eventually one answer (which you may or may not like) is to run your NAT daemons in separate VIMAGE jails so that there are effectively separate machines on each outgoing interface. eac can have its own firewalls etc then. Unfortunately I can't tell you if the ipfw NAT will work in this set up as I have not tested it. +------------------------------------+ | | +--------------+ | | | | | | +----+ | ISP1------| | | n | | | ng0--| g | | | | | - | | +--------------+ | b | | +--------------+ | r |--ng2 +---inside interface. | | | i | | | ng1--| d | | ISP2------| | | 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" > From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 16:53:59 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FCDB106566C; Mon, 28 Feb 2011 16:53:59 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id A58EC8FC14; Mon, 28 Feb 2011 16:53:58 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p1SGroZ2051656; Mon, 28 Feb 2011 22:53:50 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D6BD319.5020403@rdtc.ru> Date: Mon, 28 Feb 2011 22:53:45 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Julian Elischer References: <4D6A30B7.2010001@rdtc.ru> <4D6A35A3.7060303@rdtc.ru> <4D6BD0DE.1080301@freebsd.org> In-Reply-To: <4D6BD0DE.1080301@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "net@freebsd.org" Subject: Re: ipfw nat and dual-homed box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:53:59 -0000 On 28.02.2011 22:44, Julian Elischer wrote: > On 2/27/11 3:29 AM, Eugene Grosbein wrote: >> On 27.02.2011 17:08, Eugene Grosbein wrote: >> >> [skip] >> >>> For performance reasons, I need to create similar setup using in-kernel "ipfw nat" >>> what does not have such "multiple instances" feature but has its own "keep-state" mechanics: >> To correct myself: of course, ipfw nat has multiple instances... It does not offer >> something like natd's "globalport" feature to check all NAT instances for entry >> before creation of new one. >> >>> nat config if $if0 unreg_only >>> nat config if $if1 unreg_only >>> nat 123 ip from any to any via $if0 keep-state # For incoming packets create dynamic rule. >>> nat 124 ip from any to any via $if1 keep-state # For outgoing packet use corresponding NAT instance. >>> fwd $if0_gate ip from $if0_ip to any out xmit $if1 # Force packet go out right interface. >>> fwd $if1_gate ip from $if1_ip to any out xmit $if0 >>> >>> This works just fine if we do not try to use ipfw nat's port forwarding. >>> Here it breaks because "keep-state" creates dynamic rule for incoming connections >>> before translation's done, so it records external IP of the box as destination IP. >>> Hence, replies will be translated using wrong NAT instance when routing table >>> chooses wrong outgoing interface - replies won't match ipfw's dynamic rules. >>> >>> I think this is a bug in 8.2-STABLE. Am I right? >>> Or, perhaps, there is another way to setup ipfw nat for dual-homed LAN? > Eventually > one answer (which you may or may not like) is to run your NAT daemons in > separate VIMAGE jails so that there are effectively separate machines > on each > outgoing interface. eac can have its own firewalls etc then. > Unfortunately I can't tell you if the ipfw NAT will work in this set up > as I have not tested it. As I've already noted, the task can be solved without separate VIMAGE using just one running natd. And I've presented working natd config for that. I want to run ipfw nat for better performance. Note again, the task is to NOT separate NAT instances but to the contrary, I need to use BOTH translation tables combined for outgoing packets. And I've presented configuration using ipfw nat that's supposed to work too, but there I've found misfeature or a bug I want to discuss :-) Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 17:00:14 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93A5C106564A for ; Mon, 28 Feb 2011 17:00:14 +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 3D2688FC12 for ; Mon, 28 Feb 2011 17:00:13 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p1SH0BMT085279 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 28 Feb 2011 09:00:12 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D6BD499.6090605@freebsd.org> Date: Mon, 28 Feb 2011 09:00:09 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eugene Grosbein References: <4D6A30B7.2010001@rdtc.ru> <4D6A35A3.7060303@rdtc.ru> <4D6BD0DE.1080301@freebsd.org> <4D6BD319.5020403@rdtc.ru> In-Reply-To: <4D6BD319.5020403@rdtc.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "net@freebsd.org" Subject: Re: ipfw nat and dual-homed box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 17:00:14 -0000 On 2/28/11 8:53 AM, Eugene Grosbein wrote: > On 28.02.2011 22:44, Julian Elischer wrote: >> On 2/27/11 3:29 AM, Eugene Grosbein wrote: >>> On 27.02.2011 17:08, Eugene Grosbein wrote: >>> >>> [skip] >>> >>>> For performance reasons, I need to create similar setup using in-kernel "ipfw nat" >>>> what does not have such "multiple instances" feature but has its own "keep-state" mechanics: >>> To correct myself: of course, ipfw nat has multiple instances... It does not offer >>> something like natd's "globalport" feature to check all NAT instances for entry >>> before creation of new one. >>> >>>> nat config if $if0 unreg_only >>>> nat config if $if1 unreg_only >>>> nat 123 ip from any to any via $if0 keep-state # For incoming packets create dynamic rule. >>>> nat 124 ip from any to any via $if1 keep-state # For outgoing packet use corresponding NAT instance. >>>> fwd $if0_gate ip from $if0_ip to any out xmit $if1 # Force packet go out right interface. >>>> fwd $if1_gate ip from $if1_ip to any out xmit $if0 >>>> >>>> This works just fine if we do not try to use ipfw nat's port forwarding. >>>> Here it breaks because "keep-state" creates dynamic rule for incoming connections >>>> before translation's done, so it records external IP of the box as destination IP. >>>> Hence, replies will be translated using wrong NAT instance when routing table >>>> chooses wrong outgoing interface - replies won't match ipfw's dynamic rules. >>>> >>>> I think this is a bug in 8.2-STABLE. Am I right? >>>> Or, perhaps, there is another way to setup ipfw nat for dual-homed LAN? >> Eventually >> one answer (which you may or may not like) is to run your NAT daemons in >> separate VIMAGE jails so that there are effectively separate machines >> on each >> outgoing interface. eac can have its own firewalls etc then. >> Unfortunately I can't tell you if the ipfw NAT will work in this set up >> as I have not tested it. > As I've already noted, the task can be solved without separate VIMAGE > using just one running natd. And I've presented working natd config for that. > > I want to run ipfw nat for better performance. Note again, > the task is to NOT separate NAT instances but to the contrary, > I need to use BOTH translation tables combined for outgoing packets. > And I've presented configuration using ipfw nat that's supposed to work too, > but there I've found misfeature or a bug I want to discuss :-) > > Eugene Grosbein > not totally relevant, but for readability and clarity as to what is actually happening, split your various flows into different sets of firewall rules using skipto rules. it makes my head hurt to have to read rules where you have to watch for packets going in opposite directions through the same rules. using From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 20:29:50 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 286D3106564A for ; Mon, 28 Feb 2011 20:29:50 +0000 (UTC) (envelope-from jayb@zoe.braeburn.org) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by mx1.freebsd.org (Postfix) with ESMTP id D253D8FC12 for ; Mon, 28 Feb 2011 20:29:49 +0000 (UTC) X-VirusChecked: Checked X-Env-Sender: jayb@zoe.braeburn.org X-Msg-Ref: server-7.tower-120.messagelabs.com!1298924988!5651368!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 22388 invoked from network); 28 Feb 2011 20:29:48 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-7.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Feb 2011 20:29:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p1SKUBeG020832 for ; Mon, 28 Feb 2011 15:30:11 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p1SKU8gW020648 for ; Mon, 28 Feb 2011 15:30:08 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p1SKTi95023096 for ; Mon, 28 Feb 2011 15:29:44 -0500 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p1SKTeJj022927 for ; Mon, 28 Feb 2011 15:29:40 -0500 Received: by oz.mt.att.com (Postfix, from userid 500) id 418DD2BF2C; Mon, 28 Feb 2011 15:29:39 -0500 (EST) X-Mailer: emacs 21.2.1 (via feedmail 8 I); VM 7.18 under Emacs 21.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19820.1457.447505.704618@oz.mt.att.com> Date: Mon, 28 Feb 2011 15:29:37 -0500 From: Jay Borkenhagen To: freebsd-net@freebsd.org In-Reply-To: <19803.61841.359853.307539@oz.mt.att.com> References: <19803.61841.359853.307539@oz.mt.att.com> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Sender: jayb@zoe.braeburn.org Subject: Re: seeking recommendation: 1000Base-SX PCI NIC for FreeBSD 8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jay Borkenhagen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:29:50 -0000 Jay Borkenhagen writes: > Hi, > > After having been disappointed by one vendor *, I am returning to this > list to seek recommendations for 1000Base-SX PCI NICs. I am looking > to run them on FreeBSD 8 and beyond, and I need support for MTU > 1500 > bytes (initially around 4470, but possibly closer to 9k later). > > On http://www.freebsd.org/releases/8.1R/hardware.html#ETHERNET I found > mention of several "SX" cards, but I have first-hand experience with > none of them. If anyone here can confirm jumbo support and current > retail availability of any such cards, I would be very appreciative. > Hi, My posting of 16-Feb elicited one private response from John-Mark Gurney (thanks!) suggesting an external media converter with a 1000Base-TX NIC. While that is a possibility, I would prefer to avoid having to purchase, test, spare, rackmount, etc. Does anyone out there have experience with any of the following SX NICs & FreeBSD? (list from http://www.freebsd.org/releases/8.1R/hardware.html#ETHERNET: + Broadcom NetXtreme II BCM5706 1000Base-SX + Broadcom NetXtreme II BCM5708 1000Base-SX + Broadcom NetXtreme II BCM5709 1000Base-SX + 3Com 3c996-SX + SysKonnect SK-9D41 (1000baseSX) + SMC TigerCard 1000 (SMC9462SX) + D-Link DGE-500SX + D-Link 550SX + D-Link 560SX + Marvell Yukon 88E8021 SX/LX + Marvell Yukon 88E8022 SX/LX + Marvell Yukon 88E8061 SX/LX + Marvell Yukon 88E8062 SX/LX + SysKonnect SK-9Sxx + SK-9843 SK-NET GE-SX + 3Com 3c985-SX + 3Com 3c985B-SX + Alteon AceNIC V + Digital EtherWORKS 1000SX + Netgear GA620 Thanks. Jay B. From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 23:19:39 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24EE41065670 for ; Mon, 28 Feb 2011 23:19:39 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 5C86C8FC0C for ; Mon, 28 Feb 2011 23:19:38 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id p1SFmWKG048300 for ; Mon, 28 Feb 2011 09:48:32 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id p1SFmWw7048299 for net@freebsd.org; Mon, 28 Feb 2011 09:48:32 -0600 (CST) (envelope-from brooks) Date: Mon, 28 Feb 2011 09:48:32 -0600 From: Brooks Davis To: net@freebsd.org Message-ID: <20110228154831.GC41129@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ZLFUWh1odzi/v6L" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 28 Feb 2011 09:48:33 -0600 (CST) Cc: Subject: any is vfs.nfsrv.nfs_privport=0 by default X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 23:19:39 -0000 --4ZLFUWh1odzi/v6L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline vfs.nfsrv.nfs_privport controls wither or not NFS enforces the traditional RPC semantics that require that requests come from "privileged" ports. By default this check is disabled. Hardening guides typically suggest this be enabled, usually via the rc.conf knob nfs_reserved_port_only=YES. I'm trying to find a good reason why the default is the way it is. Digging around in the source tree it appears that the rc.conf setting has been that way since either /etc/rc.conf or /etc/defaults/rc.conf has been in the tree. I do not consider the fact that the security provided is weak at best to be a good reason to disable it. I suspect support for PC-NFS or something like that may be the reason, but if that's the case it really doesn't make any sense. -- Brooks --4ZLFUWh1odzi/v6L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFNa8POXY6L6fI4GtQRAkmjAJ0Wa6jwdJQNuJ5Yj8F8H/fEwSKKgQCeOcWv xu+4YoAsZhaTKlHl718Z1Vc= =inYs -----END PGP SIGNATURE----- --4ZLFUWh1odzi/v6L-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 23:28:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9DFC106566C for ; Mon, 28 Feb 2011 23:28:40 +0000 (UTC) (envelope-from red35@zyni.com) Received: from esprit.zyni.com (zyni-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:a14::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9C1798FC12 for ; Mon, 28 Feb 2011 23:28:40 +0000 (UTC) Received: from esprit.zyni.com (localhost [127.0.0.1]) by esprit.zyni.com (Postfix) with ESMTP id C40304AC1F for ; Mon, 28 Feb 2011 16:28:39 -0700 (MST) X-Virus-Scanned: amavisd-new at zyni.com Received: from esprit.zyni.com ([127.0.0.1]) by esprit.zyni.com (esprit.zyni.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B-xHUqMxDh6 for ; Mon, 28 Feb 2011 16:28:27 -0700 (MST) Received: from minuit.zyni.com (unknown [IPv6:2001:470:e317:98::101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by esprit.zyni.com (Postfix) with ESMTPS id 8EE5F4AC1B for ; Mon, 28 Feb 2011 16:28:27 -0700 (MST) Received: from minuit.zyni.com (localhost [127.0.0.1]) by minuit.zyni.com (8.14.4/8.14.4) with ESMTP id p1SNSQQ7020266 for ; Mon, 28 Feb 2011 16:28:27 -0700 (MST) (envelope-from red35@minuit.zyni.com) Message-Id: <201102282328.p1SNSQQ7020266@minuit.zyni.com> To: freebsd-net@freebsd.org Date: Mon, 28 Feb 2011 16:28:26 -0700 From: User Red35 Subject: rtadvd and carp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 23:28:40 -0000 I am getting started with IPv6 and I am trying to get rtadvd working on the carp interface but it is not working so far. ### I have carp failover between two firewalls. The default gateway for ### hosts internal to the firewall is 172.31.98.103 for IPv4 ### and 2001:470:dead:98::103 for IPv6 # ifconfig carp1 carp1: flags=49 metric 0 mtu 1500 inet 172.31.98.103 netmask 0xffffffff inet6 2001:470:dead:98::103 prefixlen 64 nd6 options=3 carp: MASTER vhid 1 advbase 1 advskew 60 # ### rtadvd does not work since carp1 does not have a link local address # rtadvd -f -D carp1 rtadvd[13262]: link-layer address option has null length on carp1. Treat as not included. rtadvd[13262]: RA timer on carp1 is set to 16:0 rtadvd[13262]: IPV6_JOIN_GROUP(link) on carp1: Can't assign requested address # ### Per RFC 4861 Router advertisements are supposed to use ### link-local addresses... carp does not have one. ########################################################################### ### http://tools.ietf.org/html/rfc4861#page-39 ########################################################################### Section 6.1.2 IP Source Address is a link-local address. Routers must use their link-local address as the source for Router Advertisement and Redirect messages so that hosts can uniquely identify routers. ########################################################################### Is it possible to manually add the link-local address to a carp interface via ifconfig (or other utility)? I assume given the carp MAC 00:00:5e:00:01:01 the link-local address would look like this? fe80::200:5eff:fe00:101 Has anyone got anything similar working? Thanks, Geoffrey From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 02:49:42 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88642106566B for ; Tue, 1 Mar 2011 02:49:42 +0000 (UTC) (envelope-from ulsanrub@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 506BF8FC0A for ; Tue, 1 Mar 2011 02:49:42 +0000 (UTC) Received: by iwn33 with SMTP id 33so4217307iwn.13 for ; Mon, 28 Feb 2011 18:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=P+pxhSaANpwl1/mpFo9Bx232+/3g4oXMNLz/3eXO5e0=; b=K+PqLsDp3e1xDN23XiLDpCUMxCBSTOhU0HHkWLh9j9FPezFntDzdOYLvcyBpX/vyug OxUzciwG+DjsAZSESbolfWzKeQPwPHMZa/MVBpfMX3ixqDhom7dB61+LcnzObPh6Dkg6 FO2IkxFl0edAJQgVyGxLRbGGkNw6HBKpuZOfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AmKWO3Nly2IqiYfHAUAdIqz4nMGkzkaiji3Or/dB09om9PTbu+QxifFrtR0KV+aTZN bMZw3OkVsZFhKw5EzeWAWYaHO2SFCP3mfa0jFhlH/b3xY6qLzirdeDGmbD14pv4KAJEv 0tKOXelK3Jjayreh2TZLIKyihHpJmjWnjTRJI= MIME-Version: 1.0 Received: by 10.42.8.14 with SMTP id g14mr5925844icg.384.1298947781608; Mon, 28 Feb 2011 18:49:41 -0800 (PST) Received: by 10.42.229.10 with HTTP; Mon, 28 Feb 2011 18:49:41 -0800 (PST) Date: Mon, 28 Feb 2011 21:49:41 -0500 Message-ID: From: Kyungsoo Lee To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD TDMA kernel PANIC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 02:49:42 -0000 Hi, whenever I try to set my mini PCI-e card (Anatel AR5BXB6) as Master (tdmaslot 0), kernel shows PANIC msg like the below. It's OK when I set the card as not Master like tdmalsot 1,2, and more. What is the problem? And how can I fix it? Interestingly, the kernel PANIC occurs when I use this card with IBM T60. When I use this card with IBM T61, there is no PANIC message like the below. Instead, kernel shows never ending "Ath0: Stuck beacon; bmiss..." messages. How can I solve the problem? I searched but it is hard to find the answer for my cases. Thank you and I expect wise solutions. K. dumped core - see /var/crash/vmcore.0 Sat Feb 26 21:08:44 UTC 2011 FreeBSD 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Feb 25 23:41:00 UTC 2011 root@:/usr/obj/usr/src/sys/MYKERNEL i386 panic: non-maskable interrupt trap GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: <<2>N2MI> INSAM I ISA a0a, 0E,I SEAI SA ff f<2> RApafri t<2 >R<2>Ay Me rpraorri,t yl iekrerloyr ,h alridkwealrye hfaaridlwuarree. failure. Fatal trap 19: non-maskable interrupt trap while in kernel mode Fatal trap 19: non-maskable interrupt trap while in kernel mode cpuid = 1; cpuid = 0; apic id = 01apic id = 00 instruction pointer = 0x20:0xc0bd00b5 instruction pointer = 0x20:0xc0bd00b5 stack pointer = 0x28:0xc2fc1c58 stack pointer = 0x28:0xc2fc4c58 frame pointer = 0x28:0xc2fc1c58 frame pointer = 0x28:0xc2fc4c58 code segment = base 0x0, limit 0xfffff, type 0x1b code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 = DPL 0, pres 1, def32 1, gran 1 processor eflags = processor eflags = interrupt enabled, interrupt enabled, IOPL = 0IOPL = 0 current process = current process = 11 (idle: cpu1)11 (idle: cpu0) trap number = 19 trap number = 19 panic: non-maskable interrupt trap cpuid = 1 KDB: stack backtrace: #0 0xc08e1ab7 at kdb_backtrace+0x47 #1 0xc08b2b77 at panic+0x117 #2 0xc0beea83 at trap_fatal+0x323 #3 0xc0bef432 at trap+0x652 #4 0xc0bd5dfc at calltrap+0x6 #5 0xc04e5cc9 at acpi_cpu_idle+0xe9 #6 0xc0bdfb2b at cpu_idle_acpi+0x1b #7 0xc0be136b at cpu_idle+0x1b #8 0xc08d48f1 at sched_idletd+0x231 #9 0xc0887b01 at fork_exit+0x91 #10 0xc0bd5e74 at fork_trampoline+0x8 Uptime: 9m37s Physical memory: 490 MB Dumping 45 MB: 30 14 #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc08b2913 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc08b2bb0 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:592 #3 0xc0beea83 in trap_fatal (frame=0xc2fc1c18, eva=0) at /usr/src/sys/i386/i386/trap.c:946 #4 0xc0bef432 in trap (frame=0xc2fc1c18) at /usr/src/sys/i386/i386/trap.c:731 #5 0xc0bd5dfc in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #6 0xc0bd00b5 in acpi_cpu_c1 () at /usr/src/sys/i386/acpica/acpi_machdep.c:556 #7 0xc04e5cc9 in acpi_cpu_idle () at /usr/src/sys/dev/acpica/acpi_cpu.c:930 #8 0xc0bdfb2b in cpu_idle_acpi (busy=1) at /usr/src/sys/i386/i386/machdep.c:1224 #9 0xc0be136b in cpu_idle (busy=1) at /usr/src/sys/i386/i386/machdep.c:1314 #10 0xc08d48f1 in sched_idletd (dummy=0x0) at /usr/src/sys/kern/sched_ule.c:2555 #11 0xc0887b01 in fork_exit (callout=0xc08d46c0 , arg=0x0, frame=0xc2fc1d28) at /usr/src/sys/kern/kern_fork.c:845 #12 0xc0bd5e74 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:273 (kgdb) From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 06:37:50 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66564106564A for ; Tue, 1 Mar 2011 06:37:50 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id EC3678FC12 for ; Tue, 1 Mar 2011 06:37:49 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 05C10E902C for ; Tue, 1 Mar 2011 06:37:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=subject :from:to:content-type:date:message-id:mime-version :content-transfer-encoding; s=mail; bh=x0NtqkTEQpWj6/PMAR2Wc2B8s LY=; b=pw5nSxx5/qaOcTITyg3gPF44hW7VXSAymV59+cu4F2OmGJjh7MtCvLXzf 8D44uiFRy0/1OGhzNUJLMK8JdM6J/wuhfNF36HsbSUr+nLR247p7Z+BNSAIlZLkI 2M8Tx85kVEBwFjITSQ0BqTeC53g5qbd8Vpdgd4/nBcoihm5k+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=subject:from :to:content-type:date:message-id:mime-version :content-transfer-encoding; q=dns; s=mail; b=T5Ai6ZoQpo1Eop0GRrA BCZt+f5LQOsWsPeUalg+6vnYbMxJe9t0GG+C9z7sN1aDvjv1cTYAC096dyAEGB9p J3rNptzVFa70tsqWg/AXjgpiQwBRj6FpILKP15Mm733H5l+G5ziXUeJ9+R0Eqb5q i5WrxnFI/ux2Am+Q/n/PN7ag= Received: from [192.168.0.10] (client-86-31-236-253.oxfd.adsl.virginmedia.com [86.31.236.253]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 9E3B7E8150 for ; Tue, 1 Mar 2011 06:37:48 +0000 (GMT) From: Bruce Cran To: freebsd-net@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Tue, 01 Mar 2011 06:37:21 +0000 Message-ID: <1298961441.2888.2.camel@core.nessbank> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Interface descriptions via pcap broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 06:37:50 -0000 I installed wireshark on my 9-CURRENT machine yesterday and found that the interface description fields are all set to 0xa5. From reading the code it looks like the data is being fetched via pcap. Device: usbus1 Description: \xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5 \xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5 \xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5 \xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5 IP: unknown Has a recent change broken this? -- Bruce Cran From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 07:41:10 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6608D1065677 for ; Tue, 1 Mar 2011 07:41:10 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EB1DE8FC13 for ; Tue, 1 Mar 2011 07:41:09 +0000 (UTC) Received: by bwz12 with SMTP id 12so4852815bwz.13 for ; Mon, 28 Feb 2011 23:41:08 -0800 (PST) Received: by 10.204.15.130 with SMTP id k2mr5285694bka.1.1298965268497; Mon, 28 Feb 2011 23:41:08 -0800 (PST) Received: from jessie.localnet (p5B2ECDD3.dip0.t-ipconnect.de [91.46.205.211]) by mx.google.com with ESMTPS id a17sm3113522bku.23.2011.02.28.23.41.07 (version=SSLv3 cipher=OTHER); Mon, 28 Feb 2011 23:41:07 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Kyungsoo Lee Date: Tue, 1 Mar 2011 08:40:53 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.32-28-generic; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103010840.54005.bschmidt@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TDMA kernel PANIC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 07:41:10 -0000 On Tuesday, March 01, 2011 03:49:41 Kyungsoo Lee wrote: > Hi, > > whenever I try to set my mini PCI-e card (Anatel AR5BXB6) as Master > (tdmaslot 0), kernel shows PANIC msg like the below. > It's OK when I set the card as not Master like tdmalsot 1,2, and more. What > is the problem? And how can I fix it? > > Interestingly, the kernel PANIC occurs when I use this card with IBM T60. > When I use this card with IBM T61, there is no PANIC message like the below. > Instead, kernel shows never ending "Ath0: Stuck beacon; bmiss..." messages. > > How can I solve the problem? I searched but it is hard to find the answer > for my cases. The panic doesn't seem to be related to ath(4) or do you see ath or wlan in the backtrace? Adrian fixed a few issues regarding stuck beacons in head, you might wanna try this. Also, your last post said you configured the device with % ifconfig wlan0 create wlandev ath0 wlanmode tdma tdmaslot 0 up This is either not the whole truth or you should definitely set a SSID as otherwise no network will be opened. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 07:52:38 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26398106566C for ; Tue, 1 Mar 2011 07:52:38 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE6618FC08 for ; Tue, 1 Mar 2011 07:52:35 +0000 (UTC) Received: by qwj8 with SMTP id 8so3743828qwj.13 for ; Mon, 28 Feb 2011 23:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eWUVjhojiIMIqT+lQiIWY7c7cM/39TDMKFIJi5zpauo=; b=EdyevkRAwWLZ56SNVNU+R7Jke5xxGe5y2BMOAhY6nQRry0V5GLjhpyilSvjcSLsDp1 uMUJM1aXnwLZoB00U7I9t85DcGNysl1KzB42KlyksplX35lKlGut020pVlSSV7xt9Nc6 R8ALnndGbO/bU4SUKVt9MtipoP3csMCBG/FTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hssHpKL+rOHP0fz8ZwcO9fzOe42tKpM9/dSuRdlVo5j44tiG1a3YUOhtimJTWbipYV cK7WkM0LeWIZ/AVt/YvbX3LH1Ky25421uoSIY1ii5IjlXSBotZjzSbFqljH14InTL4/G //Gg2an0wqbGY+zCyieknrq//iqeUkNBWtXz8= MIME-Version: 1.0 Received: by 10.229.81.138 with SMTP id x10mr5062249qck.20.1298965954504; Mon, 28 Feb 2011 23:52:34 -0800 (PST) Received: by 10.229.84.129 with HTTP; Mon, 28 Feb 2011 23:52:34 -0800 (PST) In-Reply-To: <201102282328.p1SNSQQ7020266@minuit.zyni.com> References: <201102282328.p1SNSQQ7020266@minuit.zyni.com> Date: Tue, 1 Mar 2011 10:52:34 +0300 Message-ID: From: Sergey Kandaurov To: User Red35 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: rtadvd and carp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 07:52:38 -0000 On 1 March 2011 02:28, User Red35 wrote: > > I am getting started with IPv6 and I am trying to get rtadvd working on > the carp interface but it is not working so far. > > > ### I have carp failover between two firewalls. =A0The default gateway fo= r > ### =A0 =A0hosts internal to the firewall is 172.31.98.103 for IPv4 > ### =A0 =A0and 2001:470:dead:98::103 for IPv6 > > =A0 =A0# ifconfig carp1 > =A0 =A0carp1: flags=3D49 metric 0 mtu 1500 > =A0 =A0 =A0 =A0 =A0 =A0inet 172.31.98.103 netmask 0xffffffff > =A0 =A0 =A0 =A0 =A0 =A0inet6 2001:470:dead:98::103 prefixlen 64 > =A0 =A0 =A0 =A0 =A0 =A0nd6 options=3D3 > =A0 =A0 =A0 =A0 =A0 =A0carp: MASTER vhid 1 advbase 1 advskew 60 > =A0 =A0# > > > ### rtadvd does not work since carp1 does not have a link local address > > > =A0 =A0# rtadvd -f -D carp1 > =A0 =A0rtadvd[13262]: link-layer address option has null le= ngth on carp1. =A0Treat as not included. > =A0 =A0rtadvd[13262]: RA timer on carp1 is set to 16:0 > =A0 =A0rtadvd[13262]: IPV6_JOIN_GROUP(link) on carp1: Can't a= ssign requested address > =A0 =A0# > > > ### Per RFC 4861 Router advertisements are supposed to use > ### =A0 =A0 link-local addresses... =A0carp does not have one. > > > =A0 =A0##################################################################= ######### > =A0 =A0### http://tools.ietf.org/html/rfc4861#page-39 > =A0 =A0##################################################################= ######### > > =A0 =A0 =A0 =A0Section 6.1.2 > > =A0 =A0 =A0 =A0 =A0 =A0IP Source Address is a link-local address. =A0Rout= ers must use > =A0 =A0 =A0 =A0 =A0 =A0their link-local address as the source for Router = Advertisement > =A0 =A0 =A0 =A0 =A0 =A0and Redirect messages so that hosts can uniquely i= dentify > =A0 =A0 =A0 =A0 =A0 =A0routers. > > =A0 =A0##################################################################= ######### > > > Is it possible to manually add the link-local address to a carp interface > via ifconfig (or other utility)? > > I assume given the carp MAC 00:00:5e:00:01:01 the link-local address woul= d > look like this? > > fe80::200:5eff:fe00:101 > > Has anyone got anything similar working? > I'm afraid you need to specify carpdev for the carp interface to manage this work. As far as I know, FreeBSD doesn't support carpdev (yet). --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 08:39:51 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FCE7106564A for ; Tue, 1 Mar 2011 08:39:51 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E41BE8FC15 for ; Tue, 1 Mar 2011 08:39:50 +0000 (UTC) Received: by vws16 with SMTP id 16so4566322vws.13 for ; Tue, 01 Mar 2011 00:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=y0zMVjB7zbytEszbtCLositjAQfQgACVln9t1SSf8rU=; b=JhF9iv9PYE/TnGHfXcGw62jx+KajmRtp65Nn2ixplbVTbpExILe1PsUFXm9cQi1Vg/ urc2SPysfLKvCESllB3U6KPpNxGuxpeA8GbYN6bnWaljKGKN3XhEBrvgEjLusUrVxE/8 Ejki7Sq8ccEXyAi6auFKh2MoolcvapMi86iaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Xb0qmUnH9OKTNkM2DB0eISuZPeQ0uB08lDbaokxVoMjRgpJBu/e2mYpa8rvQgKPz5h QBwHNRtiiytS0LXMyL40J5HwU1y0UKtLwhGFm3RXtnESYMIjNhmva7U1svJiA3vj5nma msFBM/shn7q5yvE4SPUfqb4xG6awmRpeE0pQ8= MIME-Version: 1.0 Received: by 10.52.67.170 with SMTP id o10mr6171870vdt.197.1298967359402; Tue, 01 Mar 2011 00:15:59 -0800 (PST) Received: by 10.220.59.200 with HTTP; Tue, 1 Mar 2011 00:15:59 -0800 (PST) Date: Tue, 1 Mar 2011 16:15:59 +0800 Message-ID: From: Ganbold Tsagaankhuu To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: mav@freebsd.org Subject: mpd + pf binat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 08:39:51 -0000 Hi, One of my friends are trying to setup pppoe server with mpd and they want to give to set of users public IP dynamically and plus traffic shaping. However public IPs are limited compared to pppoe clients and they want have some kind of dynamic NAT (dynamic public IP per number of clients). Is it possible to do that with mpd + pf binat in one box? I was thinking about something like following: pppoe clients -> mpd + pf binat + altq/ng_car server -> Internet Any ideas and recommendations? thanks, Ganbold From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 09:37:28 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17F73106564A for ; Tue, 1 Mar 2011 09:37:28 +0000 (UTC) (envelope-from saurav.dasgupta@aricent.com) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by mx1.freebsd.org (Postfix) with ESMTP id 3FAF88FC0A for ; Tue, 1 Mar 2011 09:37:26 +0000 (UTC) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 316FF36B94 for ; Tue, 1 Mar 2011 14:46:22 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 1BA9036B8F for ; Tue, 1 Mar 2011 14:46:22 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.130]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Tue, 1 Mar 2011 14:49:30 +0530 From: Saurav Dasgupta To: "freebsd-net@freebsd.org" Date: Tue, 1 Mar 2011 14:49:29 +0530 Thread-Topic: TCP Buffer window size is not getting updated Thread-Index: AcvX8cSnhmodRmqaQNSfKKP34paFPQ== Message-ID: <6072DA4A344C23459096E69EB3F4570D020B03B5BD@GUREXMB02.ASIAN.AD.ARICENT.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: TCP Buffer window size is not getting updated X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 09:37:28 -0000 Hi, We are facing the issue with TCP connection buffer size. TCP session is up. By default the rx buffer window size is 64k.Traffic flow= is fine. When the buffer size is increased while connection is up, rx buff= er window size is updated automatically with the new value. But if we decrease the buffer size below the default value i.e. 64k, window= size is not getting updated. To get it updated, we need to prune the conne= ction and setup with the new value(which is lesser than the default window = size). Is this a expected behavior in FreeBSD IP stack. Currently we are using Fre= eBSD v7.2. Thanks and Regards, Saurav ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 12:25:25 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB8451065677 for ; Tue, 1 Mar 2011 12:25:25 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 0BD448FC23 for ; Tue, 1 Mar 2011 12:25:24 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id p21C5esZ027102 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 1 Mar 2011 13:05:40 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id p21C5d44008944; Tue, 1 Mar 2011 13:05:39 +0100 (MET) Date: Tue, 1 Mar 2011 13:05:39 +0100 From: Daniel Hartmeier To: Saurav Dasgupta Message-ID: <20110301120539.GB3446@insomnia.benzedrine.cx> References: <6072DA4A344C23459096E69EB3F4570D020B03B5BD@GUREXMB02.ASIAN.AD.ARICENT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6072DA4A344C23459096E69EB3F4570D020B03B5BD@GUREXMB02.ASIAN.AD.ARICENT.COM> User-Agent: Mutt/1.5.12-2006-07-14 Cc: "freebsd-net@freebsd.org" Subject: Re: TCP Buffer window size is not getting updated X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 12:25:25 -0000 On Tue, Mar 01, 2011 at 02:49:29PM +0530, Saurav Dasgupta wrote: > TCP session is up. By default the rx buffer window size is 64k.Traffic flow is fine. When the buffer size is increased while connection is up, rx buffer window size is updated automatically with the new value. > But if we decrease the buffer size below the default value i.e. 64k, window size is not getting updated. To get it updated, we need to prune the connection and setup with the new value(which is lesser than the default window size). You mean you're decreasing SO_RCVBUF with setsockopt(2) on an already established connection? I'm not sure that is well-defined in Posix, the usual case is setting SO_RCVBUF once before connect(2), changing it afterwards is probably implementation-defined and not portable, at least a brief search shows similar issues on other OSs. Looking at sys/netinet/tcp_input|output.c, it looks like the expected case is only when the buffer increases (potentially automatically with SB_AUTOSIZE), and window updates are only triggered by increasing windows. Are you only missing explicit window updates, or do you see th_win in ACKs not adjusting? There's also the question of what should happen when you start with a default buffer size, advertise that to the peer, and then (while the peer is sending segments), you decrease the buffer size. This could cause the peer to accidentially violate the (shorter) window, and you'd drop segments and cause retransmission. I haven't found the section in the TCP RFC that says you're even allowed to break a previous advertisement with a shorter, subsequent one. Also, if the default buffer size causes activation of window scaling (say, with a scaling factor of 2^7 or such), and you subsequently decrease the buffer size dramatically, you might end up with a permanent zero size window. Maybe you can explain why you are decreasing the receive buffer size on an established connection, what is the purpose or intended effect? Kind regards, Daniel From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 13:15:34 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 837631065673; Tue, 1 Mar 2011 13:15:34 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5AEB08FC1A; Tue, 1 Mar 2011 13:15:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p21DFYtZ044667; Tue, 1 Mar 2011 13:15:34 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p21DFYNe044663; Tue, 1 Mar 2011 13:15:34 GMT (envelope-from ae) Date: Tue, 1 Mar 2011 13:15:34 GMT Message-Id: <201103011315.p21DFYNe044663@freefall.freebsd.org> To: gelraen.ua@gmail.com, ae@FreeBSD.org, freebsd-net@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: kern/137775: [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 13:15:34 -0000 Synopsis: [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many State-Changed-From-To: open->patched State-Changed-By: ae State-Changed-When: Tue Mar 1 13:14:56 UTC 2011 State-Changed-Why: Commited to head/. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=137775 From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 13:20:11 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01D67106564A for ; Tue, 1 Mar 2011 13:20:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CAC218FC0C for ; Tue, 1 Mar 2011 13:20:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p21DKAIx045363 for ; Tue, 1 Mar 2011 13:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p21DKABJ045360; Tue, 1 Mar 2011 13:20:10 GMT (envelope-from gnats) Date: Tue, 1 Mar 2011 13:20:10 GMT Message-Id: <201103011320.p21DKABJ045360@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Konstantin Malov Cc: Subject: Re: kern/155004: [bce] [panic] kernel panic in bce0 driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Konstantin Malov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 13:20:11 -0000 The following reply was made to PR kern/155004; it has been noted by GNATS. From: Konstantin Malov To: "bug-followup@FreeBSD.org" Cc: Subject: Re: kern/155004: [bce] [panic] kernel panic in bce0 driver Date: Tue, 1 Mar 2011 16:12:47 +0300 --_000_6C8693CFEE208243A988360589D6145A013697A0A28EKLMAILCCRav_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks like 131209 bug report has the same root cause with 155004 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D131209 -- Konstantin Malov External Services Group system administrator Kaspersky Lab. - Russian Federation Tel: +7(495)797-8700 (ext. 2867) http://www.kaspersky.com --_000_6C8693CFEE208243A988360589D6145A013697A0A28EKLMAILCCRav_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Looks like 131209 bug report has the same root cause with 155004

http://www.freebsd.org/cgi/query-p= r.cgi?pr=3D131209

 

 

--

Konstantin Malov

External Services Group syste= m administrator

Kaspersky La= b. - Russian Federation

Tel:= +7(495)797-8700 (ext. 2867)

http://www.kaspersky.c= om

&n= bsp;

 

= --_000_6C8693CFEE208243A988360589D6145A013697A0A28EKLMAILCCRav_-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 14:21:12 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8AD71065670; Tue, 1 Mar 2011 14:21:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 6BF158FC15; Tue, 1 Mar 2011 14:21:12 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:70a2:fcc4:61cd:a28a] ([IPv6:2607:f3e0:0:4:70a2:fcc4:61cd:a28a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p21EL80d025829 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Mar 2011 09:21:08 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D6D00C1.1040805@sentex.net> Date: Tue, 01 Mar 2011 09:20:49 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Jan Koum References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, Lev Serebryakov , Jack Vogel , freebsd-stable@freebsd.org Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 14:21:12 -0000 I have been running with 7.2.2 and so far so good. However, its hard to say in my case as the box I would only periodically see the issue. Jan, have you had a chance to try 7.2.2 ? You seemed to hit the issue the most frequently. There are also some alternate patches in http://www.freebsd.org/cgi/query-pr.cgi?pr=150516 But I think Jack said 7.2.2 takes a similar strategy ? ---Mike On 2/24/2011 3:03 AM, Özkan KIRIK wrote: > Thank you. I'll test and share my experiences with you. > > On Wed, Feb 23, 2011 at 7:47 PM, Jack Vogel wrote: >> Here is the 7.2.2 tarball. IMPORTANT: if you use this DO NOT try and put it >> into your kernel source tree, it will break that. What you must do is config >> the >> em driver OUT of your kernel, then untar this, build it standalone, and then >> load it. >> >> This is just a temporary thing, once I have data to decide on this change vs >> the earlier one it will get integrated. >> >> Jack >> >> >> 2011/2/23 Özkan KIRIK >>> >>> Hi, >>> >>> How can we get 7.2.2. version of if_em driver ? >>> I wanna test it. >>> >>> I can help you for testing changes to em drivers. >>> >>> >>> Regards, >>> Ozkan KIRIK >>> >>> On Wed, Feb 23, 2011 at 1:36 PM, Lev Serebryakov >>> wrote: >>>> Hello, Mike. >>>> You wrote 23 Ñ„ÐµÐ²Ñ€Ð°Ð»Ñ 2011 г., 14:16:28: >>>> >>>>>> Driver from "em driver, 82574L chip, and possibly ASPM" thread >>>>>> doesn't help, really: it seems, that it decrease frequincy of hangs, >>>>> Looking at your sysctl output, you are not using the test drivers >>>>> posted >>>>> in that thread. >>>> Yes, as it doesn't help, I've reverted to "stock" one. >>>> >>>>> If you want to try 7.1.9-test, you can download it at >>>>> http://www.tancsa.com/if_em-8.c for releng_8. >>>> I've tried it. It has worked without hangs for 7-8 days, and after >>>> that hangs 2 times in 3 days with "7.1.9-test" :( >>>> >>>> -- >>>> // Black Lion AKA Lev Serebryakov >>>> >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to >>>> "freebsd-stable-unsubscribe@freebsd.org" >>>> >> >> > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 14:49:42 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF802106564A; Tue, 1 Mar 2011 14:49:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4E8B78FC0C; Tue, 1 Mar 2011 14:49:42 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0577346B2E; Tue, 1 Mar 2011 09:49:42 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8D2998A02B; Tue, 1 Mar 2011 09:49:41 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Tue, 1 Mar 2011 08:09:27 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <20110228154831.GC41129@lor.one-eyed-alien.net> In-Reply-To: <20110228154831.GC41129@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201103010809.27346.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 01 Mar 2011 09:49:41 -0500 (EST) Cc: Brooks Davis Subject: Re: any is vfs.nfsrv.nfs_privport=0 by default X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 14:49:42 -0000 On Monday, February 28, 2011 10:48:32 am Brooks Davis wrote: > vfs.nfsrv.nfs_privport controls wither or not NFS enforces the > traditional RPC semantics that require that requests come from > "privileged" ports. By default this check is disabled. Hardening > guides typically suggest this be enabled, usually via the rc.conf knob > nfs_reserved_port_only=YES. > > I'm trying to find a good reason why the default is the way it is. > Digging around in the source tree it appears that the rc.conf setting > has been that way since either /etc/rc.conf or /etc/defaults/rc.conf has > been in the tree. > > I do not consider the fact that the security provided is weak at best to > be a good reason to disable it. I suspect support for PC-NFS or > something like that may be the reason, but if that's the case it really > doesn't make any sense. I think it should default to on, and that the nfs_reserved_port_only setting should just be removed. Instead, folks who want to turn this off can pass '-n' to mountd, for which there are already other rc.conf flags such as mountd_weak_authentication, etc. Maybe you leave the nfs_reserved_port_only option and have it toggle the -n option to mountd? Whatever the outcome, I think we need to collapse the multiple rc.conf variables (mountd_weak_authentication and nfs_reserved_port_only) down to 1 variable and have the kernel default to requiring a privileged port. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 15:10:56 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E659E106566C; Tue, 1 Mar 2011 15:10:56 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BD0398FC1B; Tue, 1 Mar 2011 15:10:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p21FAuxS056860; Tue, 1 Mar 2011 15:10:56 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p21FAuCa056793; Tue, 1 Mar 2011 10:10:56 -0500 (EST) (envelope-from eadler) Date: Tue, 1 Mar 2011 10:10:56 -0500 (EST) Message-Id: <201103011510.p21FAuCa056793@freefall.freebsd.org> To: nox@jelal.kn-bremen.de, eadler@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:10:57 -0000 Synopsis: [run] [panic] [patch] Workaround for use-after-free panic State-Changed-From-To: open->patched State-Changed-By: eadler State-Changed-When: Tue Mar 1 10:10:55 EST 2011 State-Changed-Why: committed in head http://www.freebsd.org/cgi/query-pr.cgi?pr=153938 From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 15:14:26 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74327106566B; Tue, 1 Mar 2011 15:14:26 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1BF8FC1A; Tue, 1 Mar 2011 15:14:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p21FEQ1X061396; Tue, 1 Mar 2011 15:14:26 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p21FEPe1061392; Tue, 1 Mar 2011 10:14:25 -0500 (EST) (envelope-from eadler) Date: Tue, 1 Mar 2011 10:14:25 -0500 (EST) Message-Id: <201103011514.p21FEPe1061392@freefall.freebsd.org> To: dan@obluda.cz, eadler@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: bin/79228: [patch] extend arp(8) to be able to create blackhole records X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:14:26 -0000 Synopsis: [patch] extend arp(8) to be able to create blackhole records State-Changed-From-To: open->closed State-Changed-By: eadler State-Changed-When: Tue Mar 1 10:14:25 EST 2011 State-Changed-Why: This PR is fixed in head, 8.x and 7.x, but will not be merged to 6.x now that that branch is unsupported, sorry http://www.freebsd.org/cgi/query-pr.cgi?pr=79228 From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 15:15:34 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0CFE106567A; Tue, 1 Mar 2011 15:15:34 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C75778FC25; Tue, 1 Mar 2011 15:15:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p21FFYSl063150; Tue, 1 Mar 2011 15:15:34 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p21FFYed063145; Tue, 1 Mar 2011 10:15:34 -0500 (EST) (envelope-from eadler) Date: Tue, 1 Mar 2011 10:15:34 -0500 (EST) Message-Id: <201103011515.p21FFYed063145@freefall.freebsd.org> To: aboyer@averesystems.com, eadler@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: kern/146759: [cxgb] [patch] cxgb panic calling cxgb_set_lro() without port lock held X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:15:35 -0000 Synopsis: [cxgb] [patch] cxgb panic calling cxgb_set_lro() without port lock held State-Changed-From-To: open->patched State-Changed-By: eadler State-Changed-When: Tue Mar 1 10:15:34 EST 2011 State-Changed-Why: committed in head http://www.freebsd.org/cgi/query-pr.cgi?pr=146759 From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 15:17:39 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7768F1065672; Tue, 1 Mar 2011 15:17:39 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4EFB08FC17; Tue, 1 Mar 2011 15:17:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p21FHdOX064465; Tue, 1 Mar 2011 15:17:39 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p21FHdLV064460; Tue, 1 Mar 2011 10:17:39 -0500 (EST) (envelope-from eadler) Date: Tue, 1 Mar 2011 10:17:39 -0500 (EST) Message-Id: <201103011517.p21FHdLV064460@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-net@FreeBSD.org, hselasky@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:17:39 -0000 Synopsis: [run] [panic] [patch] Workaround for use-after-free panic Responsible-Changed-From-To: freebsd-net->hselasky Responsible-Changed-By: eadler Responsible-Changed-When: Tue Mar 1 10:16:24 EST 2011 Responsible-Changed-Why: Same as above http://www.freebsd.org/cgi/query-pr.cgi?pr=153938 From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 15:23:00 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A1F61065677; Tue, 1 Mar 2011 15:23:00 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 510808FC1C; Tue, 1 Mar 2011 15:23:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p21FN0VU074370; Tue, 1 Mar 2011 15:23:00 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p21FN0bP074365; Tue, 1 Mar 2011 10:23:00 -0500 (EST) (envelope-from eadler) Date: Tue, 1 Mar 2011 10:23:00 -0500 (EST) Message-Id: <201103011523.p21FN0bP074365@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-net@FreeBSD.org, np@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: kern/146759: [cxgb] [patch] cxgb panic calling cxgb_set_lro() without port lock held X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:23:00 -0000 Synopsis: [cxgb] [patch] cxgb panic calling cxgb_set_lro() without port lock held Responsible-Changed-From-To: freebsd-net->np Responsible-Changed-By: eadler Responsible-Changed-When: Tue Mar 1 10:22:59 EST 2011 Responsible-Changed-Why: same as above http://www.freebsd.org/cgi/query-pr.cgi?pr=146759 From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 16:13:35 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A9301065670 for ; Tue, 1 Mar 2011 16:13:35 +0000 (UTC) (envelope-from ulsanrub@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C3C358FC19 for ; Tue, 1 Mar 2011 16:13:34 +0000 (UTC) Received: by iwn33 with SMTP id 33so4822924iwn.13 for ; Tue, 01 Mar 2011 08:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FD8I2LHknICvdYmAiJpJpGm68t2udkFkyXrhFRPvu2c=; b=CRpeO4S2tzKhVs6EtLiJILstQv4ul0UfgEcYuc9tXnnrV/bKhfF0IGXXY/CYYLPURC kxicLKSDsKoGgJq2ucdtKoNFN/sPaJHoLzAJrjMefeQfbMRNsx1F+YM7g2IdvdE7ZVvn EYv2Nb/FS9rWPEbAwELcTPAPAE3bRjsIPS05E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NG3CLeaR5oPTupoLpFCUudp1qGAdp84vQxjScRRqk5RLLrAyN2jjnKwwyPl1rPVqpY 6S2CurIcy+alvFhtQ/v+DBq+bKdhhK9rWWle2W/6quUSlmURCh9HcHdy5VeD0MIAMoFv jH+6DDkj+m1InG3wNj9X2LAJhBP3BYMTxbZeo= MIME-Version: 1.0 Received: by 10.42.239.72 with SMTP id kv8mr6918918icb.183.1298996014075; Tue, 01 Mar 2011 08:13:34 -0800 (PST) Received: by 10.42.229.10 with HTTP; Tue, 1 Mar 2011 08:13:33 -0800 (PST) In-Reply-To: <201103010840.54005.bschmidt@freebsd.org> References: <201103010840.54005.bschmidt@freebsd.org> Date: Tue, 1 Mar 2011 11:13:33 -0500 Message-ID: From: Kyungsoo Lee To: bschmidt@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TDMA kernel PANIC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 16:13:35 -0000 Thank you for your answer. I'll try Adrian's fix. K. On Tue, Mar 1, 2011 at 2:40 AM, Bernhard Schmidt wrote: > On Tuesday, March 01, 2011 03:49:41 Kyungsoo Lee wrote: > > Hi, > > > > whenever I try to set my mini PCI-e card (Anatel AR5BXB6) as Master > > (tdmaslot 0), kernel shows PANIC msg like the below. > > It's OK when I set the card as not Master like tdmalsot 1,2, and more. > What > > is the problem? And how can I fix it? > > > > Interestingly, the kernel PANIC occurs when I use this card with IBM T60. > > When I use this card with IBM T61, there is no PANIC message like the > below. > > Instead, kernel shows never ending "Ath0: Stuck beacon; bmiss..." > messages. > > > > How can I solve the problem? I searched but it is hard to find the answer > > for my cases. > > The panic doesn't seem to be related to ath(4) or do you see ath or > wlan in the backtrace? > > Adrian fixed a few issues regarding stuck beacons in head, you might > wanna try this. > > Also, your last post said you configured the device with > % ifconfig wlan0 create wlandev ath0 wlanmode tdma tdmaslot 0 up > This is either not the whole truth or you should definitely set a SSID > as otherwise no network will be opened. > > -- > Bernhard > From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 18:38:46 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61D38106566C for ; Tue, 1 Mar 2011 18:38:46 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0C08FC20 for ; Tue, 1 Mar 2011 18:38:45 +0000 (UTC) Received: by iyj12 with SMTP id 12so4772585iyj.13 for ; Tue, 01 Mar 2011 10:38:45 -0800 (PST) Received: by 10.42.64.209 with SMTP id h17mr7119821ici.247.1299004725429; Tue, 01 Mar 2011 10:38:45 -0800 (PST) Received: from kkPC (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id y8sm4099447ica.14.2011.03.01.10.38.43 (version=SSLv3 cipher=OTHER); Tue, 01 Mar 2011 10:38:44 -0800 (PST) From: "kevin" To: Date: Tue, 1 Mar 2011 13:38:26 -0500 Message-ID: <018001cbd83f$db4a25c0$91de7140$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: AcvYP9kP5zsW0f+QRIWySectCvBxnA== x-cr-hashedpuzzle: Ar9c Aus9 Az0i BHfH Bfl0 BusV B7a8 CJF9 DA0K DB4d DEnm D2Q4 E8X4 IYdR JbHd LAbJ; 1; ZgByAGUAZQBiAHMAZAAtAG4AZQB0AEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnAA==; Sosha1_v1; 7; {448F75C6-DC03-4010-B33B-F6BEBCF0A182}; awBAAGsAZQB2AGkAbgBrAGUAdgBpAG4ALgBjAG8AbQA=; Tue, 01 Mar 2011 18:38:24 GMT; UABGACAAKwAgAEcAQQBUAEUAVwBBAFkAIAArACAAQgBSAEkARABHAEUAIAArACAAQwBBAFIAUAAgAGYAYQBpAGwAbwB2AGUAcgA= x-cr-puzzleid: {448F75C6-DC03-4010-B33B-F6BEBCF0A182} Subject: PF + GATEWAY + BRIDGE + CARP failover X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 18:38:46 -0000 Hello, I made a post to this list several weeks ago regarding transparent bridging + pf + rstp + failover. My experiments with RSTP / MSTP with my switch and freebsd transparent bridging produced many problems. So I would like to remove the 'transparent' item out of the equasion and assign an ip address to my bridge and provide a gateway ip to all my devices through a CARP failover IP address. So my network will look like this : [switch vlan1] | | [fw1 bridge ip x.x.x.x] [fw2 bridge ip x.x.x.y] | | [fw1 CARP gateway IP x.x.x.x] - [fw2 CARP SLAVE gateway IP x.x.x.x] | | [switch vlan2] | [devices (gateway set to CARP gatway IP)] Does anyone see a problem with this configuration? I want to get around the locking issues experienced with transparent bridging with only 1 switch and 2 vlans. My mind is a mess from all these problems so if I'm missing something obvious, please let me know! Many thanks, Kevin From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 19:58:10 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42961106566C; Tue, 1 Mar 2011 19:58:10 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id EBE068FC0A; Tue, 1 Mar 2011 19:58:09 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id CA78F13DF42; Tue, 1 Mar 2011 22:52:25 +0300 (MSK) Date: Tue, 1 Mar 2011 22:52:15 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1416421652.20110301225215@serebryakov.spb.ru> To: Mike Tancsa In-Reply-To: <4D6D00C1.1040805@sentex.net> References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Jan Koum , Jack Vogel Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 19:58:10 -0000 Hello, Mike. You wrote 1 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 17:20:49: > I have been running with 7.2.2 and so far so good. However, its hard to > say in my case as the box I would only periodically see the issue. As I wrote to Jack, my NIC hangs today with 7.2.2 --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 20:10:15 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DDA1106566B for ; Tue, 1 Mar 2011 20:10:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0324E8FC08 for ; Tue, 1 Mar 2011 20:10:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p21KAEpn043867 for ; Tue, 1 Mar 2011 20:10:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p21KAEsF043865; Tue, 1 Mar 2011 20:10:14 GMT (envelope-from gnats) Date: Tue, 1 Mar 2011 20:10:14 GMT Message-Id: <201103012010.p21KAEsF043865@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Dan Lukes Cc: Subject: Re: bin/79228: [patch] extend arp(8) to be able to create blackhole records X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dan Lukes List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 20:10:15 -0000 The following reply was made to PR bin/79228; it has been noted by GNATS. From: Dan Lukes To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/79228: [patch] extend arp(8) to be able to create blackhole records Date: Tue, 01 Mar 2011 21:05:22 +0100 Not true, it doesn't work in 8.x nor in HEAD. It disappeared during rewrite of network stack. But current problem is not related to this PR, so there is no reason to unclose it. This PR has been submited in 2005, reviewed and committed in 2008, I requested it's close in 2009. Not surprising when outdated a lot in 2011 ... Anyway, thank to anybody who spent time to solve the problem ... Dan From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 23:28:07 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E6D8106564A; Tue, 1 Mar 2011 23:28:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 03D848FC1B; Tue, 1 Mar 2011 23:28:06 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAIsIbU2DaFvO/2dsb2JhbACEKKMerRSQeYEng0R2BIUShw2FXQ X-IronPort-AV: E=Sophos;i="4.62,249,1297054800"; d="scan'208";a="112676762" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 01 Mar 2011 17:59:05 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 1AAD0B3F64; Tue, 1 Mar 2011 17:59:05 -0500 (EST) Date: Tue, 1 Mar 2011 17:59:05 -0500 (EST) From: Rick Macklem To: Brooks Davis Message-ID: <297419299.601659.1299020345042.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110228154831.GC41129@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: net@freebsd.org Subject: Re: any is vfs.nfsrv.nfs_privport=0 by default X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 23:28:07 -0000 > vfs.nfsrv.nfs_privport controls wither or not NFS enforces the > traditional RPC semantics that require that requests come from > "privileged" ports. By default this check is disabled. Hardening > guides typically suggest this be enabled, usually via the rc.conf knob > nfs_reserved_port_only=YES. > > I'm trying to find a good reason why the default is the way it is. > Digging around in the source tree it appears that the rc.conf setting > has been that way since either /etc/rc.conf or /etc/defaults/rc.conf > has > been in the tree. > > I do not consider the fact that the security provided is weak at best > to > be a good reason to disable it. I suspect support for PC-NFS or > something like that may be the reason, but if that's the case it > really > doesn't make any sense. > Two comments: 1 - RFC3530 (NFSv4) specifically states that reserved port #s cannot be required. --> If you change the defaults, it will be different for NFSv4 than NFSv2,3. Not incorrect, but a little weird. 2 - It was probably disabled by default so that clients wouldn't run out of reserved ports when doing lotsa mounts. But, I don't care what the default is for NFSv2,3, rick From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 06:48:53 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D26C1065670 for ; Wed, 2 Mar 2011 06:48:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id AE8388FC0A for ; Wed, 2 Mar 2011 06:48:52 +0000 (UTC) Received: by vxc34 with SMTP id 34so5726886vxc.13 for ; Tue, 01 Mar 2011 22:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fAE46rdIGVZxotOmsy6i4zhJvAG3jWjxzD/hgzQqQAw=; b=OoHf1JVRf9aCTsRH6aEuJijDD0XfnssuBE9fzuP29qVch5Pm8tf2ljmJVlNUxYSUjB 6QcoswLr3DcccsdbQoZoKOsFfmptsP+HgHsPZ6wqVmnn0in7gMHD9UTFvbvzvQvoxjOt h7hAoJM8lCczAw34z3TkRbCCBFiK2+vn2N+ds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=lX+8aMz+KBOd8zMP3L5byu25KuOcbMtkEBQnFX47cuncODBnMziuH7l//xJlRpp1c9 iBsumCJMKdUxJMFkaSCNawwDJ3ziu4aYwnW/5Opl7elwMxQEOrGU6qsNOGQfN1rC4Oan 4Z7u952VWCj6iO5R6yA0Eybj9ecfvdbENBf3k= MIME-Version: 1.0 Received: by 10.52.91.16 with SMTP id ca16mr7673746vdb.233.1299048530481; Tue, 01 Mar 2011 22:48:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.220.188.132 with HTTP; Tue, 1 Mar 2011 22:48:50 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Mar 2011 22:48:50 -0800 X-Google-Sender-Auth: dZyVVGqUru4L2_sq5degemDYmHg Message-ID: From: Adrian Chadd To: Kyungsoo Lee Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net Subject: Re: Mini PCI express cards for TDMA on FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 06:48:53 -0000 I don't think the TDMA code has been thoroughly tested lately. The bus shouldn't matter; it's likely the underlying chipset that matters. It's an AR5424, which should be the AR5212 driver. That should just work fine. If it's panicing, try to get a sensible panic message and backtrace showing where it's actually paniced and get back to me. Adrian On 27 February 2011 19:14, Kyungsoo Lee wrote: > Hi guys, > > anyone uses mini PCI express cards for TDMA on FreeBSD? > > I tried to use Anatel AR5BXB6 on IBM laptops. But it doesn't work when I > set > the node as Master(tdmaslot 0) with PANIC or "ATH0: stuck beacons;..". > Is there any solution to solve the above problem? Or does anybody succeed > to > use TDMA on FreeBSD with mini PCI-e cards? > Please, let me know how to solve or the name of the mini PCI-e card which > works well for FreeBSD TDMA. > > FYI, I set the node with the below command. > > "ifconfig wlan create wlandev ath0 wlanmode tdma tdmaslot 0 up" > > Thanks, > K. > _______________________________________________ > 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 Mar 2 06:55:52 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3F021065673 for ; Wed, 2 Mar 2011 06:55:51 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id B45DD8FC0C for ; Wed, 2 Mar 2011 06:55:51 +0000 (UTC) Received: by iyj12 with SMTP id 12so5358794iyj.13 for ; Tue, 01 Mar 2011 22:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Rgb5Oc55zloDeFUUUJLdJlLMtjV9+kY4BsnqaPu6K7Y=; b=iVr09my21hpBlf64PJCN0yL5Cv22zMRHMqBE8T24/3n3Hc0JGp2AnYxRxGg5tRnqGt D8c4dAz5w14kxfxqUTAl0wF1x+0/uuocM+UoBHtjuCXcW9pg3SyBiBwySa1y0QOVgw+C 0mant4aDrJw5TxUA8CtrWfp0ZdLkWDG54PxUs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fhZtrhtoEGCAy2jGr2DR0nLf3wd1llZHUiOyKdPj/OUowQ4divKcoIVtrwkt76lScp nxJzsibDk3ekB8KJFLs7NmJciHgHe/0/vBqkurPjeuVQ8eXBNvc2SBR8/IZvxTeX3N6i nDnVKhUIBX0aztbozU4KNltCJEgQN+onf2dAo= MIME-Version: 1.0 Received: by 10.42.123.204 with SMTP id t12mr7801017icr.457.1299048950890; Tue, 01 Mar 2011 22:55:50 -0800 (PST) Received: by 10.42.165.135 with HTTP; Tue, 1 Mar 2011 22:55:50 -0800 (PST) In-Reply-To: <1416421652.20110301225215@serebryakov.spb.ru> References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> Date: Wed, 2 Mar 2011 01:55:50 -0500 Message-ID: From: Arnaud Lacombe To: Lev Serebryakov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel , Jan Koum , Mike Tancsa Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 06:55:52 -0000 Hi, On Tue, Mar 1, 2011 at 2:52 PM, Lev Serebryakov wr= ote: > Hello, Mike. > You wrote 1 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 17:20:49: > >> I have been running with 7.2.2 and so far so good. =C2=A0However, its ha= rd to >> say in my case as the box I would only periodically see the issue. > =C2=A0As I wrote to Jack, my NIC hangs today with 7.2.2 > Do you have any detailed error ? What the output of sysctl "dev.em.X" where X is the index of the hung interface ? Thanks, - Arnaud > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > 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 Mar 2 07:06:25 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00285106566B; Wed, 2 Mar 2011 07:06:24 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3BC8FC13; Wed, 2 Mar 2011 07:06:24 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p2275m36034982; Wed, 2 Mar 2011 13:05:48 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D6DEC47.7060308@rdtc.ru> Date: Wed, 02 Mar 2011 13:05:43 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gleb Smirnoff References: <20110131144838.GO62007@FreeBSD.org> <4D46F655.9000701@rdtc.ru> <20110131204816.GV62007@glebius.int.ru> <4D5A989E.8020703@sentex.net> <4D5B4F07.6080801@rdtc.ru> <20110216084635.GI42041@glebius.int.ru> <4D5B9309.30508@rdtc.ru> <20110216102330.GJ42041@glebius.int.ru> In-Reply-To: <20110216102330.GJ42041@glebius.int.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Przemyslaw Frasunek , Mike Tancsa , mav@freebsd.org, bz@freebsd.org, "net@freebsd.org" Subject: Re: Netgraph/mpd5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 07:06:25 -0000 Something new in my logs yesterday: Mar 1 16:06:38 k-45-pc-1 kernel: Accessing freed node node: ID [2e5c7a]: type 'tee', 0 hooks, flags 0x9, 0 refs, mpd11699-vlan373-781-lt: Mar 1 16:06:38 k-45-pc-1 kernel: Last active @ /home/src/sys/netgraph/ng_base.c, line 2257 Mar 1 16:06:38 k-45-pc-1 kernel: problem discovered at file /home/src/sys/netgraph/ng_base.c, line 3621 Mar 1 16:06:38 k-45-pc-1 kernel: Accessing freed node node: ID [2e5c7a]: type 'tee', 0 hooks, flags 0x9, 1 refs, mpd11699-vlan373-781-lt: Mar 1 16:06:38 k-45-pc-1 kernel: Last active @ /home/src/sys/netgraph/ng_base.c, line 3621 Mar 1 16:06:38 k-45-pc-1 kernel: problem discovered at file /home/src/sys/netgraph/ng_base.c, line 2377 Mar 1 16:06:38 k-45-pc-1 kernel: Accessing freed node node: ID [2e5c7a]: type 'tee', 0 hooks, flags 0x9, 1 refs, mpd11699-vlan373-781-lt: Mar 1 16:06:38 k-45-pc-1 kernel: Last active @ /home/src/sys/netgraph/ng_base.c, line 2377 Mar 1 16:06:38 k-45-pc-1 kernel: problem discovered at file /home/src/sys/netgraph/ng_base.c, line 2257 This is the same periodically panicing 8.2-PRERELEASE with NETGRAPH_DEBUG and couple of patches from Gleb and Julian. Still cannot get crashdump (system hangs while dumping core). Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 07:35:22 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 271C71065674; Wed, 2 Mar 2011 07:35:22 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F205D8FC13; Wed, 2 Mar 2011 07:35:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p227ZLxn030142; Wed, 2 Mar 2011 07:35:21 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p227ZL8j030138; Wed, 2 Mar 2011 07:35:21 GMT (envelope-from linimon) Date: Wed, 2 Mar 2011 07:35:21 GMT Message-Id: <201103020735.p227ZL8j030138@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/155177: [route] [panic] Panic when inject routes in kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 07:35:22 -0000 Old Synopsis: Panic when inject routes in kernel New Synopsis: [route] [panic] Panic when inject routes in kernel Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 2 07:33:35 UTC 2011 Responsible-Changed-Why: Attempt to classify and reassign. http://www.freebsd.org/cgi/query-pr.cgi?pr=155177 From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 07:36:53 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8805F1065675; Wed, 2 Mar 2011 07:36:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5DA8FC14; Wed, 2 Mar 2011 07:36:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p227arpX034033; Wed, 2 Mar 2011 07:36:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p227arD1034029; Wed, 2 Mar 2011 07:36:53 GMT (envelope-from linimon) Date: Wed, 2 Mar 2011 07:36:53 GMT Message-Id: <201103020736.p227arD1034029@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/155113: [re] 'media auto' does not work X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 07:36:53 -0000 Old Synopsis: 'media auto' does not work New Synopsis: [re] 'media auto' does not work Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 2 07:36:30 UTC 2011 Responsible-Changed-Why: Reclassify and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=155113 From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 15:16:53 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8313D1065670; Wed, 2 Mar 2011 15:16:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id EE3578FC1B; Wed, 2 Mar 2011 15:16:52 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p22EcRdr061317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Mar 2011 16:38:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p22EcR10040034; Wed, 2 Mar 2011 16:38:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p22EcROd040033; Wed, 2 Mar 2011 16:38:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 2 Mar 2011 16:38:27 +0200 From: Kostik Belousov To: jfv@freebsd.org Message-ID: <20110302143827.GA78089@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GiGu7FyeuLbo3AR8" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: net@freebsd.org Subject: i386 kernel hangs, seemingly on em0 attachment. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 15:16:53 -0000 --GiGu7FyeuLbo3AR8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I have an issue with Core-i5 system and onboard em adapter on the=20 Intel DH55HC Desktop Board. em0: port 0xf040-0xf05f mem 0x= fe500000-0xfe51ffff,0xfe528000-0xfe528fff irq 20 at device 25.0 on pci0 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 em0: using IRQ 256 for MSI em0: Using an MSI interrupt The machine with i386 kernel hangs with the last lines of the kernel output listed above. amd64 version boots flawless. Interesting detail is that even reset starts to act when the machine hangs, pressing the button causes a reset only after 10-20 seconds. Removing if_em from the list of loaded modules allows kernel to finish loading and gives me the "/" selection dialog, which is unuseful since machine is pxebooted. em0 is the onboard adapter, also there is em1 in the pci slot. em0@pci0:0:25:0: class=3D0x020000 card=3D0x00378086 chip=3D0x10f08086 rev= =3D0x06 hdr=3D0x00 em1@pci0:1:2:0: class=3D0x020000 card=3D0x13768086 chip=3D0x107c8086 rev= =3D0x05 hdr=3D0x00 System is today HEAD. if_em is loaded as module. pxeboot. Any help ? --GiGu7FyeuLbo3AR8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1uVmMACgkQC3+MBN1Mb4hTRACfeyrpiD9eaaZxfa1onpUEbnYw h24AnRJJgP8N3v6rbpztZdb/5KRwsdz/ =0ulI -----END PGP SIGNATURE----- --GiGu7FyeuLbo3AR8-- From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 15:44:53 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA5221065702; Wed, 2 Mar 2011 15:44:53 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 645A18FC0A; Wed, 2 Mar 2011 15:44:53 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:b465:c134:204f:fc84] ([IPv6:2607:f3e0:0:4:b465:c134:204f:fc84]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p22FioZx092328 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Mar 2011 10:44:51 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D6E65F7.7080105@sentex.net> Date: Wed, 02 Mar 2011 10:44:55 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kostik Belousov References: <20110302143827.GA78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110302143827.GA78089@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: jfv@freebsd.org, net@freebsd.org Subject: Re: i386 kernel hangs, seemingly on em0 attachment. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 15:44:53 -0000 On 3/2/2011 9:38 AM, Kostik Belousov wrote: > Hi, > I have an issue with Core-i5 system and onboard em adapter on the > Intel DH55HC Desktop Board. > > em0: port 0xf040-0xf05f mem 0xfe500000-0xfe51ffff,0xfe528000-0xfe528fff irq 20 at device 25.0 on pci0 > em0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 49 > em0: using IRQ 256 for MSI > em0: Using an MSI interrupt > > The machine with i386 kernel hangs with the last lines of the > kernel output listed above. amd64 version boots flawless. Interesting > detail is that even reset starts to act when the machine hangs, pressing > the button causes a reset only after 10-20 seconds. > > Removing if_em from the list of loaded modules allows kernel to > finish loading and gives me the "/" selection dialog, which is unuseful > since machine is pxebooted. > > em0 is the onboard adapter, also there is em1 in the pci slot. > > em0@pci0:0:25:0: class=0x020000 card=0x00378086 chip=0x10f08086 rev=0x06 hdr=0x00 > em1@pci0:1:2:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 > > System is today HEAD. if_em is loaded as module. pxeboot. > > Any help ? This rings a bell. I saw a similar issue with the same desktop board. If I compiled em into the kernel, it would netboot just fine. But as a module, it would not for some reason. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 17:54:03 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B29241065674; Wed, 2 Mar 2011 17:54:03 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 894EE8FC1D; Wed, 2 Mar 2011 17:54:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p22Hs39e037421; Wed, 2 Mar 2011 17:54:03 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p22Hs2XW037417; Wed, 2 Mar 2011 17:54:03 GMT (envelope-from yongari) Date: Wed, 2 Mar 2011 17:54:03 GMT Message-Id: <201103021754.p22Hs2XW037417@freefall.freebsd.org> To: kes-kes@yandex.ru, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/155113: [re] 'media auto' does not work X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 17:54:03 -0000 Synopsis: [re] 'media auto' does not work State-Changed-From-To: open->closed State-Changed-By: yongari State-Changed-When: Wed Mar 2 17:47:23 UTC 2011 State-Changed-Why: Not a bug. You need 4 pairs(all 8 pins) to establish a gigabit link. You may argue PHY should do downshifting to find next available speed as well as correcting pin polarities. This feature is PHY specific one and I think RealTek PHYs do not support automatic downshifting. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Mar 2 17:47:23 UTC 2011 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=155113 From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 19:40:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BE17106566B for ; Wed, 2 Mar 2011 19:40:59 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 121878FC1D for ; Wed, 2 Mar 2011 19:40:58 +0000 (UTC) Received: by wwb31 with SMTP id 31so464471wwb.31 for ; Wed, 02 Mar 2011 11:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ah/uykxXiLswobcpBFt7482aQEEsDDxzSMWMtjor5eg=; b=ayWAtuB7jr5/t4X3dsWaZ+dQOKOn62bNiirBuG9a7DqH3ilVSCH/v7CNuEzEx2Bbuj 6LL2xo44yveKcbWZlVie96yfJVuOJFj0rTFlU8GXPEShEIYExPmlsKi7YywTxYe1FYy9 0HuIQfwRBYyI0B0uj8PQPPuxIqq4nvYeBs/sw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BshQ7rK8asrQzZh3SUPwbecJFKAJ6uH7MwRIYT3vRSjSeiuRgq80mh4v9RZUKEs/4h 5yMd64xzSQ/Yn9XSZnKuY9bKEfCoR0mNh+S7nabvxeZL6SNaII+JC3VdQ+nYFAUEIdC9 NsLUB/BCZT5VVoAjgSpL+v9QlbSJ+VFcLBLJU= MIME-Version: 1.0 Received: by 10.216.179.133 with SMTP id h5mr1018968wem.69.1299094857729; Wed, 02 Mar 2011 11:40:57 -0800 (PST) Received: by 10.216.25.72 with HTTP; Wed, 2 Mar 2011 11:40:57 -0800 (PST) In-Reply-To: <1298961441.2888.2.camel@core.nessbank> References: <1298961441.2888.2.camel@core.nessbank> Date: Wed, 2 Mar 2011 13:40:57 -0600 Message-ID: From: Brandon Gooch To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Rui Paulo Subject: Re: Interface descriptions via pcap broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:40:59 -0000 On Tue, Mar 1, 2011 at 12:37 AM, Bruce Cran wrote: > I installed wireshark on my 9-CURRENT machine yesterday and found that > the interface description fields are all set to 0xa5. From reading the > code it looks like the data is being fetched via pcap. > > Device: usbus1 > Description: \xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5 > \xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5 > \xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5 > \xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5 > IP: unknown > > Has a recent change broken this? > > -- > Bruce Cran I'm seeing the same thing. libpcap-1.1.1 was merged into HEAD about 4 months ago, so it's possible... I suspect changes to libpcap's inet.c: http://svn.freebsd.org/viewvc/base/head/contrib/libpcap/inet.c?r1=203052&r2=214518 ...although I haven't had the time to look through it thoroughly -- it's more of a "gut feeling" (if there could be such a thing regarding C code LOL). BTW, if you give your devices descriptions, libpcap starts to behave again; this could be a clue to the source of the bug :/ What do you think Rui? Any hints? -Brandon From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 19:46:16 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CAE81065675; Wed, 2 Mar 2011 19:46:16 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id E98968FC12; Wed, 2 Mar 2011 19:46:15 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id D7101E71AE; Wed, 2 Mar 2011 19:46:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=OvTZhIWyXjX1 flvCEqLA9gfNqTc=; b=OXluRvCpA8xjtkIjRGkF5UprtF6zC81BwQjW52XLPADX 8Vu8kT6077TPZCoeeDexhe3U35MC5EOodE2phPgPQ4thqLayBmPC3usNNHzLWDN7 MJIm2GCLRXcGhokmK809p2pgLjVWr3D/5RC+bvc6/OmSEM5y2ACkbn/aOqYgURE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=QP3web P1Op668Qn3tfA3n3Bv7Zmh6IuyXNCCmrPlqoAV9lCNchTRWS5rJi9Exir4hgNa5r i3U7y9MrG9s0AsoAAFTI9TyrYY3fGftfeSIHfFS7Z7KKK496WtliaQF/6dRI2xlO H+V/Q/i/mFc/F/xMyB7rs+qsm1HmSyQBsdE8I= Received: from unknown (client-86-31-236-253.oxfd.adsl.virginmedia.com [86.31.236.253]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 4BC35E71AD; Wed, 2 Mar 2011 19:46:14 +0000 (GMT) Date: Wed, 2 Mar 2011 19:45:40 +0000 From: Bruce Cran To: Brandon Gooch Message-ID: <20110302194540.0000018f@unknown> In-Reply-To: References: <1298961441.2888.2.camel@core.nessbank> X-Mailer: Claws Mail 3.7.8cvs9 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Rui Paulo Subject: Re: Interface descriptions via pcap broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:46:16 -0000 On Wed, 2 Mar 2011 13:40:57 -0600 Brandon Gooch wrote: > BTW, if you give your devices descriptions, libpcap > starts to behave again; this could be a clue to the source of the bug > :/ 0xa5 is the malloc fill pattern when debugging is enabled, and having recently reinstalled FreeBSD I forgot to create the malloc.conf symlink. So something's reading from uninitialized memory. -- Bruce Cran From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 19:58:16 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07607106564A; Wed, 2 Mar 2011 19:58:16 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward8.mail.yandex.net (forward8.mail.yandex.net [77.88.61.38]) by mx1.freebsd.org (Postfix) with ESMTP id A95828FC17; Wed, 2 Mar 2011 19:58:15 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward8.mail.yandex.net (Yandex) with ESMTP id 4FFC8F624A2; Wed, 2 Mar 2011 22:42:59 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1299094979; bh=GkIuRkGKXuSaPji9/0OuNtwQJGgq2nATT29j5jvy4Uw=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gGF1DgiFtI+hTZy/7HzK8ODge9UjAWBM1AKeQp3Aw4pfYOrGHuBiWL22v7Zon0tA3 1BcIomb8ZvIntKKQUAJclryuOdKkeFsHxLOiDgTE6Kd75OKD0+3kiwakMtR1CdkFHY qc/d98PN5G0UzyQlAg0MNw/5vcSdTP1yc/6e5aS4= Received: from HOMEUSER (unknown [77.93.52.5]) by smtp8.mail.yandex.net (Yandex) with ESMTPA id C356B4190075; Wed, 2 Mar 2011 22:42:58 +0300 (MSK) Date: Wed, 2 Mar 2011 21:43:03 +0200 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <681089083.20110302214303@yandex.ru> To: linimon@FreeBSD.org In-Reply-To: <201103020736.p227arD1034029@freefall.freebsd.org> References: <201103020736.p227arD1034029@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re[2]: kern/155113: [re] 'media auto' does not work X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:58:16 -0000 If this is auto then it SHUOLD try each media. If hardware does not, soft must (driver must) I know that for 1G I must use 8wire. but I use 4wire and expect 100Mbit Âû ïèñàëè 2 ìàðòà 2011 ã., 9:36:53: lFo> Old Synopsis: 'media auto' does not work lFo> New Synopsis: [re] 'media auto' does not work lFo> Responsible-Changed-From-To: freebsd-bugs->freebsd-net lFo> Responsible-Changed-By: linimon lFo> Responsible-Changed-When: Wed Mar 2 07:36:30 UTC 2011 lFo> Responsible-Changed-Why: lFo> Reclassify and assign. lFo> http://www.freebsd.org/cgi/query-pr.cgi?pr=155113 lFo> _______________________________________________ lFo> freebsd-net@freebsd.org mailing list lFo> http://lists.freebsd.org/mailman/listinfo/freebsd-net lFo> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Ñ óâàæåíèåì, Êîíüêîâ mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 20:39:20 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1156D106564A; Wed, 2 Mar 2011 20:39:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id CDF8E8FC14; Wed, 2 Mar 2011 20:39:19 +0000 (UTC) Received: by pzk32 with SMTP id 32so63332pzk.13 for ; Wed, 02 Mar 2011 12:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=CTqHaRi11Yp4ZKq6i+bh3gc8d1YcNcljXVcWiyWduZw=; b=eLQO3RrjGjZxX9UrefKBo+sL8DN8qfQKQW0GFhvcHdHZaXYpaaH0KLtDWqRWvtcaIi QMNDZTfPGHB41L3FBLjXI3b1Gx7dI4esN5Gr6nhbdk6J60gqKMJm/2nuPjIBCLD7hFw7 YZpQj+U2F38aGi4nVyuhDlU0gOC9aZHZvYVZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=CS6GZTydxkW5yJ0Iw7wt99mFcOYMBusfW/csPvp6vHThsxnHF+LmDu3yxcWhW//AVn Sbg05N7VZAXfEUM3dZ8BhGCdkHiCAUcyTJtGbcZ4KbH6UJEeazMHjj83JGjZf++EvWSz WGtufRG3H6Q9F8T8OUOK1UGReOvBKoWTYoYsM= Received: by 10.142.156.16 with SMTP id d16mr113936wfe.388.1299098359230; Wed, 02 Mar 2011 12:39:19 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id m10sm406567wfl.11.2011.03.02.12.39.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2011 12:39:17 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 02 Mar 2011 12:39:21 -0800 From: YongHyeon PYUN Date: Wed, 2 Mar 2011 12:39:21 -0800 To: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= Message-ID: <20110302203921.GF7076@michelle.cdnetworks.com> References: <201103020736.p227arD1034029@freefall.freebsd.org> <681089083.20110302214303@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <681089083.20110302214303@yandex.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org, linimon@freebsd.org Subject: Re: kern/155113: [re] 'media auto' does not work X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 20:39:20 -0000 On Wed, Mar 02, 2011 at 09:43:03PM +0200, ?????????????? ?????????????? wrote: > If this is auto then it SHUOLD try each media. > If hardware does not, soft must (driver must) > That depends on PHY hardware and your PHY hardware does not support down-shifting. If you want to implement all these things in driver which I don't think it is worth to implement, open a new PR about that. This issue has nothing to do with re(4). Interesting developers or users can implement software based down-shifting. From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 21:50:08 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11574106566B for ; Wed, 2 Mar 2011 21:50:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB778FC0C for ; Wed, 2 Mar 2011 21:50:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 90D0E41C7A6; Wed, 2 Mar 2011 22:50:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id gudQDQsQE6CX; Wed, 2 Mar 2011 22:50:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id B4D3041C7A4; Wed, 2 Mar 2011 22:50:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id E02FD4448FC; Wed, 2 Mar 2011 21:48:00 +0000 (UTC) Date: Wed, 2 Mar 2011 21:48:00 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Alex Povolotsky In-Reply-To: <4D4FA3DA.7010004@webmail.sub.ru> Message-ID: <20110302214601.S13400@maildrop.int.zabbadoz.net> References: <4D4FA3DA.7010004@webmail.sub.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: jail source address selection doesn't work? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 21:50:08 -0000 On Mon, 7 Feb 2011, Alex Povolotsky wrote: > Hello! > > On a multihomed FreeBSD 8.1-RELEASE, in a multihomed jail, source IP > selection suddenly refused to work. > > ifconfig on a box: ... > Seems reasonable, yes? > > Pinging from the box > > # ping 192.168.75.59 > PING 192.168.75.59 (192.168.75.59): 56 data bytes > 64 bytes from 192.168.75.59: icmp_seq=0 ttl=64 time=0.993 ms > 64 bytes from 192.168.75.59: icmp_seq=1 ttl=64 time=0.986 ms > 64 bytes from 192.168.75.59: icmp_seq=2 ttl=64 time=0.988 ms > ^C > --- 192.168.75.59 ping statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.986/0.989/0.993/0.003 ms > > 10:45:31.425232 IP 192.168.75.4 > 192.168.75.59: ICMP echo request, id 12430, > seq 0, length 64 > 10:45:31.426283 IP 192.168.75.59 > 192.168.75.4: ICMP echo reply, id 12430, > seq 0, length 64 > 10:45:32.425415 IP 192.168.75.4 > 192.168.75.59: ICMP echo request, id 12430, > seq 1, length 64 > 10:45:32.426404 IP 192.168.75.59 > 192.168.75.4: ICMP echo reply, id 12430, > seq 1, length 64 > > Okay, yes? > > From jail: > > # ping 192.168.75.59 > PING 192.168.75.59 (192.168.75.59): 56 data bytes > ^C > --- 192.168.75.59 ping statistics --- > 2 packets transmitted, 0 packets received, 100.0% packet loss > > 10:45:52.146600 IP 83.69.203.1 > 192.168.75.59: ICMP echo request, id 14222, > seq 0, length 64 > 10:45:53.146702 IP 83.69.203.1 > 192.168.75.59: ICMP echo request, id 14222, > seq 1, length 64 > > Setting ip.saddrsel to 1 or 0 did not change anything. Kernel is GENERIC+ALTQ > > What could I miss?... Don't use ping to test this. a) for ping inside the jail to work you need to enable raw sockets b) a) could give you a hint that ping does it's own thing. Try a telnet to a random port to the destination and verify with tcpdump whether things are still not working correctly, of if you establish the connection with netstat. If it still doesn't work let us know. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 22:00:08 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 032361065676; Wed, 2 Mar 2011 22:00:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id A2D478FC1D; Wed, 2 Mar 2011 22:00:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0791D41C7A4; Wed, 2 Mar 2011 23:00:07 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id yiBQUgrOrnDC; Wed, 2 Mar 2011 23:00:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 18A5541C7A8; Wed, 2 Mar 2011 23:00:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id EA94F4448FC; Wed, 2 Mar 2011 22:00:01 +0000 (UTC) Date: Wed, 2 Mar 2011 22:00:01 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Giorgos Keramidas In-Reply-To: Message-ID: <20110302215921.N13400@maildrop.int.zabbadoz.net> References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net , Ivo Vachkov , Doug Barton Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:00:08 -0000 On Sat, 5 Feb 2011, Giorgos Keramidas wrote: Hi, > On Fri, 28 Jan 2011 11:00:40 -0800, Doug Barton wrote: >> I haven't reviewed the patch in detail yet but I wanted to first thank >> you for taking on this work, and being so responsive to Fernando's >> request (which I agreed with, and you updated before I even had a >> chance to say so). :) > > Thanks from me too. > >> My one comment so far is on the name of the sysctl's. There are 2 >> problems with sysctl/variable names that use an rfc title. The first is >> that they are not very descriptive to the 99.9% of users who are not >> familiar with that particular doc. The second is more esoteric, but if >> the rfc is subsequently updated or obsoleted we're stuck with either an >> anachronism or updating code (both of which have their potential areas >> of confusion). >> >> So in order to avoid this issue, and make it more consistent with the >> existing: >> >> net.inet.ip.portrange.randomtime >> net.inet.ip.portrange.randomcps >> net.inet.ip.portrange.randomized >> >> How does net.inet.ip.portrange.randomalg sound? I would also suggest >> that the second sysctl be named >> net.inet.ip.portrange.randomalg.alg5_tradeoff so that one could do >> sysctl net.inet.ip.portrange.randomalg' and see both values. But I won't >> quibble on that. :) > > It's a usability issue too, so I'd certainly support renaming the > sysctls to something human-friendly. It's always bad enough to go > through look at a search engine to find out what net.inet.rfc1234 > means. It's worse when RFC 1234 has been obsoleted a few years ago > and now it's called RFC 54321. has anything of that ever happened and led to an updated patch again? /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 22:09:46 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B5291065672; Wed, 2 Mar 2011 22:09:46 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.49.45]) by mx1.freebsd.org (Postfix) with ESMTP id E97848FC18; Wed, 2 Mar 2011 22:09:45 +0000 (UTC) Received: by syn.atarininja.org (Postfix, from userid 1001) id 7072A5C3A; Wed, 2 Mar 2011 16:52:58 -0500 (EST) Date: Wed, 2 Mar 2011 16:52:58 -0500 From: Wesley Shields To: Bruce Cran Message-ID: <20110302215258.GA48643@atarininja.org> References: <1298961441.2888.2.camel@core.nessbank> <20110302194540.0000018f@unknown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110302194540.0000018f@unknown> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Brandon Gooch , freebsd-net@freebsd.org, Rui Paulo Subject: Re: Interface descriptions via pcap broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:09:46 -0000 On Wed, Mar 02, 2011 at 07:45:40PM +0000, Bruce Cran wrote: > On Wed, 2 Mar 2011 13:40:57 -0600 > Brandon Gooch wrote: > > > BTW, if you give your devices descriptions, libpcap > > starts to behave again; this could be a clue to the source of the bug > > :/ > > 0xa5 is the malloc fill pattern when debugging is enabled, and > having recently reinstalled FreeBSD I forgot to create the malloc.conf > symlink. So something's reading from uninitialized memory. Does commit c65292b04b98d6a76d58c5a54ca8f81463bf24de in the libpcap git tree look like it could help? I haven't checked in detail but I think it might have never made it into a release yet? https://github.com/mcr/libpcap/commit/c65292b04b98d6a76d58c5a54ca8f81463bf24de -- WXS From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 22:18:25 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFCBE106564A; Wed, 2 Mar 2011 22:18:25 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9E38FC0C; Wed, 2 Mar 2011 22:18:25 +0000 (UTC) Received: by vws16 with SMTP id 16so510332vws.13 for ; Wed, 02 Mar 2011 14:18:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5O7SN0Wu/aknJ1kZlcnBbTXP3v1M6CEDotkFG/zvoTA=; b=A67gVS9NBd9SK9u131c+b7J7QBjOrPKIJq1G62203wNVydGcpJaikhCGD+EXA/VRPg sNOofDhTFLoby6kQeHtBDPmbq6cv5k60f28Rm4/oLa0P3dVL4BqBHDSgzhFnZrE1Dn8m aII1baoHinoCnLIE8CdRkhWxKDRGOxbccbxf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=DIy7fPv8aT4I0ekYMTryzm99HOdQUtjLP3Tvhk2tKRrIieWfuOy1WV31isVPjPKjA2 eq3CIMUaMBSGQoSviEf9auL8/T3t5O3s+rXuUk9VWzqtOv7/H6FCNwhZMB3GUTZWKDh2 GsMVo+MoVNeYrScDVFENGw2vQCYnEZ0lLLWIs= Received: by 10.52.70.82 with SMTP id k18mr568334vdu.194.1299104304301; Wed, 02 Mar 2011 14:18:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.188.74 with HTTP; Wed, 2 Mar 2011 14:18:04 -0800 (PST) In-Reply-To: <20110302215921.N13400@maildrop.int.zabbadoz.net> References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> <20110302215921.N13400@maildrop.int.zabbadoz.net> From: Ivo Vachkov Date: Thu, 3 Mar 2011 00:18:04 +0200 Message-ID: To: "Bjoern A. Zeeb" Content-Type: multipart/mixed; boundary=20cf307cfff4958843049d874a67 Cc: Giorgos Keramidas , FreeBSD Net , Doug Barton Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:18:26 -0000 --20cf307cfff4958843049d874a67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 3, 2011 at 12:00 AM, Bjoern A. Zeeb wrote: > On Sat, 5 Feb 2011, Giorgos Keramidas wrote: > > Hi, > >> On Fri, 28 Jan 2011 11:00:40 -0800, Doug Barton wrot= e: >>> >>> I haven't reviewed the patch in detail yet but I wanted to first thank >>> you for taking on this work, and being so responsive to Fernando's >>> request (which I agreed with, and you updated before I even had a >>> chance to say so). :) >> >> Thanks from me too. >> >>> My one comment so far is on the name of the sysctl's. There are 2 >>> problems with sysctl/variable names that use an rfc title. The first is >>> that they are not very descriptive to the 99.9% of users who are not >>> familiar with that particular doc. The second is more esoteric, but if >>> the rfc is subsequently updated or obsoleted we're stuck with either an >>> anachronism or updating code (both of which have their potential areas >>> of confusion). >>> >>> So in order to avoid this issue, and make it more consistent with the >>> existing: >>> >>> net.inet.ip.portrange.randomtime >>> net.inet.ip.portrange.randomcps >>> net.inet.ip.portrange.randomized >>> >>> How does net.inet.ip.portrange.randomalg sound? I would also suggest >>> that the second sysctl be named >>> net.inet.ip.portrange.randomalg.alg5_tradeoff so that one could do >>> sysctl net.inet.ip.portrange.randomalg' and see both values. But I won'= t >>> quibble on that. :) >> >> It's a usability issue too, so I'd certainly support renaming the >> sysctls to something human-friendly. =C2=A0It's always bad enough to go >> through look at a search engine to find out what net.inet.rfc1234 >> means. =C2=A0It's worse when RFC 1234 has been obsoleted a few years ago >> and now it's called RFC 54321. > > has anything of that ever happened and led to an updated patch again? Yes. Those recommendations are reflected in the latest version of the patch I supplied. I attach it again for reference. It is against RELENG-8 as of 2011-01-31. However, if you need -CURRENT-based patch, please let me know, so I can prepare it asap. > /bz > > -- > Bjoern A. Zeeb =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 You have to have vi= sions! > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Stop bit received. Insert coin for new addres= s family. > _______________________________________________ > 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" > --20cf307cfff4958843049d874a67 Content-Type: text/x-patch; charset=US-ASCII; name="20110131-freebsd-RELENG_8-rfc6056.patch" Content-Disposition: attachment; filename="20110131-freebsd-RELENG_8-rfc6056.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gkst21tg0 ZGlmZiAtciAwZDY3ZjljOTgyZjcgc3JjL3N5cy9uZXRpbmV0L2luX3BjYi5jCi0tLSBhL3NyYy9z eXMvbmV0aW5ldC9pbl9wY2IuYwlNb24gSmFuIDMxIDExOjM1OjI0IDIwMTEgKzAyMDAKKysrIGIv c3JjL3N5cy9uZXRpbmV0L2luX3BjYi5jCU1vbiBKYW4gMzEgMTQ6Mjk6NTIgMjAxMSArMDIwMApA QCAtODEsNiArODEsOCBAQAogI2luY2x1ZGUgPG5ldGlwc2VjL2tleS5oPgogI2VuZGlmIC8qIElQ U0VDICovCiAKKyNpbmNsdWRlIDxzeXMvbWQ1Lmg+CQorCiAjaW5jbHVkZSA8c2VjdXJpdHkvbWFj L21hY19mcmFtZXdvcmsuaD4KIAogLyoKQEAgLTEwOSw2ICsxMTEsOCBAQAogVk5FVF9ERUZJTkUo aW50LCBpcHBvcnRfc3RvcHJhbmRvbSk7CQkvKiB0b2dnbGVkIGJ5IGlwcG9ydF90aWNrICovCiBW TkVUX0RFRklORShpbnQsIGlwcG9ydF90Y3BhbGxvY3MpOwogc3RhdGljIFZORVRfREVGSU5FKGlu dCwgaXBwb3J0X3RjcGxhc3Rjb3VudCk7CitWTkVUX0RFRklORSh1X2ludCwgaXBwb3J0X3JhbmRv bWFsZ192ZXIpID0gMTsJLyogdXNlciBjb250cm9sbGVkIHZpYSBzeXNjdGwgKi8KK1ZORVRfREVG SU5FKHVfaW50LCBpcHBvcnRfcmFuZG9tYWxnX2FsZzVfdHJhZGVvZmYpID0gNTAwOwkvKiB1c2Vy IGNvbnRyb2xsZWQgdmlhIHN5c2N0bCAqLwogCiAjZGVmaW5lCVZfaXBwb3J0X3RjcGxhc3Rjb3Vu dAkJVk5FVChpcHBvcnRfdGNwbGFzdGNvdW50KQogCkBAIC0xNDEsNyArMTQ1LDY4IEBACiAKICN1 bmRlZiBSQU5HRUNISwogCisvKgorICogVXBkYXRlcyBWX2lwcG9ydF9yYW5kb21hbGdfdmVyIHRv IHRoZSBwcm92aWRlZCB2YWx1ZQorICogYW5kIGVuc3VyZXMgaXQgaXMgaW4gdGhlIHN1cHBvcnRl ZCByYW5nZSAoMSAtIDUpCisgKi8KK3N0YXRpYyBpbnQKK3N5c2N0bF9uZXRfcmFuZG9tYWxnX3Zl cnNpb25fY2hlY2soU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sKKwl1X2ludCBhbGdvcml0aG0gPSAq KHVfaW50ICopYXJnMTsKKwlpbnQgZXJyb3I7CisKKyNpZmRlZiBWSU1BR0UKKwllcnJvciA9IHZu ZXRfc3lzY3RsX2hhbmRsZV91aW50KG9pZHAsICZhbGdvcml0aG0sIDAsIHJlcSk7CisjZWxzZQor CWVycm9yID0gc3lzY3RsX2hhbmRsZV9pbnQob2lkcCwgJmFsZ29yaXRobSwgMCwgcmVxKTsKKyNl bmRpZgorCisJaWYgKGVycm9yID09IDApIHsKKwkJc3dpdGNoIChhbGdvcml0aG0pIHsKKwkJY2Fz ZSBJTlBfUkZDNjA1Nl9BTEdfMToKKwkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfMjoKKwkJY2FzZSBJ TlBfUkZDNjA1Nl9BTEdfMzoKKwkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfNDoKKwkJY2FzZSBJTlBf UkZDNjA1Nl9BTEdfNToKKwkJCVZfaXBwb3J0X3JhbmRvbWFsZ192ZXIgPSBhbGdvcml0aG07CisJ CQlicmVhazsKKwkJZGVmYXVsdDoKKwkJCXJldHVybiAoRUlOVkFMKTsKKwkJfQorCX0gCQorCisJ cmV0dXJuIChlcnJvcik7Cit9CisKKy8qCisgKiBVcGRhdGVzIFZfaXBwb3J0X3JhbmRvbWFsZ19h bGc1X3RyYWRlb2ZmIHRvIHByb3ZpZGVkIHZhbHVlCisgKiBhbmQgZW5zdXJlcyBpdCBpcyBpbiB0 aGUgc3VwcG9ydGVkIHJhbmdlICgxIC0gNjU1MzYpCisgKi8KK3N0YXRpYyBpbnQKK3N5c2N0bF9u ZXRfcmFuZG9tYWxnX2FsZzVfdHJhZGVvZmZfY2hlY2soU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sK Kwl1X2ludCB0cmFkZW9mZiA9ICoodV9pbnQgKilhcmcxOworCWludCBlcnJvcjsKKworI2lmZGVm IFZJTUFHRQorCWVycm9yID0gdm5ldF9zeXNjdGxfaGFuZGxlX3VpbnQob2lkcCwgJnRyYWRlb2Zm LCAwLCByZXEpOworI2Vsc2UKKwllcnJvciA9IHN5c2N0bF9oYW5kbGVfaW50KG9pZHAsICZ0cmFk ZW9mZiwgMCwgcmVxKTsKKyNlbmRpZgorCisJaWYgKGVycm9yID09IDApIHsKKwkJaWYgKHRyYWRl b2ZmIDwgMSB8fCB0cmFkZW9mZiA+IDY1NTM2KQorCQkJcmV0dXJuIChFSU5WQUwpOworCQllbHNl CisJCQlWX2lwcG9ydF9yYW5kb21hbGdfYWxnNV90cmFkZW9mZiA9IHRyYWRlb2ZmOworCX0KKwor CXJldHVybiAoZXJyb3IpOworfQorCiBTWVNDVExfTk9ERShfbmV0X2luZXRfaXAsIElQUFJPVE9f SVAsIHBvcnRyYW5nZSwgQ1RMRkxBR19SVywgMCwgIklQIFBvcnRzIik7CitTWVNDVExfTk9ERShf bmV0X2luZXRfaXBfcG9ydHJhbmdlLCBJUFBST1RPX0lQLCByYW5kb21hbGcsIENUTEZMQUdfUlcs IDAsIAorCSJQb3J0IFJhbmRvbWl6YXRpb24gQWxnb3JpdGhtcyIpOwogCiBTWVNDVExfVk5FVF9Q Uk9DKF9uZXRfaW5ldF9pcF9wb3J0cmFuZ2UsIE9JRF9BVVRPLCBsb3dmaXJzdCwKIAlDVExUWVBF X0lOVHxDVExGTEFHX1JXLCAmVk5FVF9OQU1FKGlwcG9ydF9sb3dmaXJzdGF1dG8pLCAwLApAQCAt MTc0LDYgKzIzOSwxNSBAQAogCSZWTkVUX05BTUUoaXBwb3J0X3JhbmRvbXRpbWUpLCAwLAogCSJN aW5pbXVtIHRpbWUgdG8ga2VlcCBzZXF1ZW50YWwgcG9ydCAiCiAJImFsbG9jYXRpb24gYmVmb3Jl IHN3aXRjaGluZyB0byBhIHJhbmRvbSBvbmUiKTsKK1NZU0NUTF9WTkVUX1BST0MoX25ldF9pbmV0 X2lwX3BvcnRyYW5nZV9yYW5kb21hbGcsIE9JRF9BVVRPLCB2ZXJzaW9uLAorCUNUTFRZUEVfVUlO VHxDVExGTEFHX1JXLCAmVk5FVF9OQU1FKGlwcG9ydF9yYW5kb21hbGdfdmVyKSwgMCwKKwkmc3lz Y3RsX25ldF9yYW5kb21hbGdfdmVyc2lvbl9jaGVjaywgIklVIiwgCisJIlJGQyA2MDU2IFBvcnQg cmFuZG9taXphdGlvbiBhbGdvcml0aG0iKTsKK1NZU0NUTF9WTkVUX1BST0MoX25ldF9pbmV0X2lw X3BvcnRyYW5nZV9yYW5kb21hbGcsIE9JRF9BVVRPLAorCWFsZzVfdHJhZGVvZmYsIENUTFRZUEVf VUlOVHxDVExGTEFHX1JXLAorCSZWTkVUX05BTUUoaXBwb3J0X3JhbmRvbWFsZ19hbGc1X3RyYWRl b2ZmKSwgMCwKKwkmc3lzY3RsX25ldF9yYW5kb21hbGdfYWxnNV90cmFkZW9mZl9jaGVjaywgIklV IiwKKwkiUkZDIDYwNTYgQWxnb3JpdGhtIDUgY29tcHV0YXRpb25hbCB0cmFkZS1vZmYiKTsKIAog LyoKICAqIGluX3BjYi5jOiBtYW5hZ2UgdGhlIFByb3RvY29sIENvbnRyb2wgQmxvY2tzLgpAQCAt NDY4LDIxICs1NDIsMTc3IEBACiAJCQlsYXN0ID0gYXV4OwogCQl9CiAKLQkJaWYgKGRvcmFuZG9t KQotCQkJKmxhc3Rwb3J0ID0gZmlyc3QgKwotCQkJCSAgICAoYXJjNHJhbmRvbSgpICUgKGxhc3Qg LSBmaXJzdCkpOwotCiAJCWNvdW50ID0gbGFzdCAtIGZpcnN0OwogCi0JCWRvIHsKLQkJCWlmIChj b3VudC0tIDwgMCkJLyogY29tcGxldGVseSB1c2VkPyAqLwotCQkJCXJldHVybiAoRUFERFJOT1RB VkFJTCk7Ci0JCQkrKypsYXN0cG9ydDsKLQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFz dHBvcnQgPiBsYXN0KQotCQkJCSpsYXN0cG9ydCA9IGZpcnN0OwotCQkJbHBvcnQgPSBodG9ucygq bGFzdHBvcnQpOwotCQl9IHdoaWxlIChpbl9wY2Jsb29rdXBfbG9jYWwocGNiaW5mbywgbGFkZHIs Ci0JCSAgICBscG9ydCwgd2lsZCwgY3JlZCkpOworCQkvKiAKKwkJICogQWNjb3JkaW5nIHRvIFJG QyA2MDU2IHRoZXJlIGFyZSA1IChmaXZlKSBwb3NzaWJsZSBhbGdvcml0aG1zCisJCSAqIGZvciBy YW5kb20gcG9ydCBhbGxvY2F0aW9uLiBVc2FnZSBvZiBhIHBhcnRpY3VsYXIgYWxnb3JpdGhtCisJ CSAqIGlzIHNwZWNpZmllZCB3aXRoIHRoZSAnbmV0LmluZXQuaXAucG9ydHJhbmdlLnJhbmRvbWFs Zy52ZXJzaW9uJworCQkgKiBzeXNjdGwgdmFyaWFibGUuIERlZmF1bHQgdmFsdWUgaXMgMSwgd2hp Y2ggcmVwcmVzZW50cyB0aGUKKwkJICogbGVnYWN5IHJhbmRvbSBwb3J0IGFsbG9jYXRpb24gYWxn b3JpdGhtIGluIEZyZWVCU0QuCisJCSAqLworCQlpZiAoZG9yYW5kb20pIHsKKwkJCXN3aXRjaCAo Vl9pcHBvcnRfcmFuZG9tYWxnX3ZlcikgeworCQkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfNToJLyog UmFuZG9tLUluY3JlbWVudHMgUG9ydCBTZWxlY3Rpb24gKi8KKwkJCQlkbyB7CisJCQkJCWlmIChj b3VudC0tIDwgMCkJLyogY29tcGxldGVseSB1c2VkPyAqLworCQkJCQkJcmV0dXJuIChFQUREUk5P VEFWQUlMKTsKKworCQkJCQkqbGFzdHBvcnQgPSBmaXJzdCArICgoYXJjNHJhbmRvbSgpICUgNjU1 MzYpICsgCisJCQkJCSAgICAoYXJjNHJhbmRvbSgpICUgVl9pcHBvcnRfcmFuZG9tYWxnX2FsZzVf dHJhZGVvZmYpICsgMSk7CisKKwkJCQkJaWYgKCpsYXN0cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9y dCA+IGxhc3QpCisJCQkJCQkqbGFzdHBvcnQgPSBmaXJzdDsKKwkJCQkJbHBvcnQgPSBodG9ucygq bGFzdHBvcnQpOworCQkJCX0gd2hpbGUgKGluX3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRk ciwKKwkJCQkgICAgbHBvcnQsIHdpbGQsIGNyZWQpKTsKKwkJCQlicmVhazsKKwkJCWNhc2UgSU5Q X1JGQzYwNTZfQUxHXzQ6CS8qIERvdWJsZS1IYXNoIFBvcnQgU2VsZWN0aW9uIEFsZ29yaXRobSAq LworCQkJCXsKKwkJCQkJTUQ1X0NUWCBmX2N0eDsKKwkJCQkJTUQ1X0NUWCBnX2N0eDsKKwkJCQkJ dV9pbnQzMl90IEZbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQkJdV9pbnQzMl90IEdbNF0gPSB7 IDAsIDAsIDAsIDAgfTsKKwkJCQkJdV9pbnQzMl90IHNlY3JldF9mWzRdID0geyAwLCAwLCAwLCAw IH07CisJCQkJCXVfaW50MzJfdCBzZWNyZXRfZ1s0XSA9IHsgMCwgMCwgMCwgMCB9OworCQkJCQl1 X2ludDE2X3QgdGFibGVbMTZdOyAKKwkJCQkJdV9pbnQzMl90IGluZGV4ID0gMDsKKwkJCQkJdV9p bnQzMl90IG9mZnNldCA9IDA7CisKKwkJCQkJc2VjcmV0X2ZbMF0gPSBhcmM0cmFuZG9tKCk7CisJ CQkJCXNlY3JldF9mWzFdID0gYXJjNHJhbmRvbSgpOworCQkJCQlzZWNyZXRfZlsyXSA9IGFyYzRy YW5kb20oKTsKKwkJCQkJc2VjcmV0X2ZbM10gPSBhcmM0cmFuZG9tKCk7CisKKwkJCQkJc2VjcmV0 X2dbMF0gPSBhcmM0cmFuZG9tKCk7CisJCQkJCXNlY3JldF9nWzFdID0gYXJjNHJhbmRvbSgpOwor CQkJCQlzZWNyZXRfZ1syXSA9IGFyYzRyYW5kb20oKTsKKwkJCQkJc2VjcmV0X2dbM10gPSBhcmM0 cmFuZG9tKCk7CisKKwkJCQkJZm9yIChpbmRleCA9IDA7IGluZGV4IDwgc2l6ZW9mKHRhYmxlKTsg aW5kZXgrKykKKwkJCQkJCXRhYmxlW2luZGV4XSA9IGFyYzRyYW5kb20oKSAlIDY1NTM2OworCisJ CQkJCU1ENUluaXQoJmZfY3R4KTsKKwkJCQkJTUQ1VXBkYXRlKCZmX2N0eCwgKHVfY2hhciAqKSZp bnAtPmlucF9sYWRkciwKKwkJCQkJICAgIHNpemVvZihpbnAtPmlucF9sYWRkcikpOworCQkJCQlN RDVVcGRhdGUoJmZfY3R4LCAodV9jaGFyICopJmlucC0+aW5wX2ZhZGRyLAorCQkJCQkgICAgc2l6 ZW9mKGlucC0+aW5wX2ZhZGRyKSk7CisJCQkJCU1ENVVwZGF0ZSgmZl9jdHgsICh1X2NoYXIgKikm aW5wLT5pbnBfZnBvcnQsCisJCQkJCSAgICBzaXplb2YoaW5wLT5pbnBfZnBvcnQpKTsKKwkJCQkJ TUQ1VXBkYXRlKCZmX2N0eCwgKHVfY2hhciAqKXNlY3JldF9mLAorCQkJCQkgICAgc2l6ZW9mKHNl Y3JldF9mKSk7CisJCQkJCU1ENUZpbmFsKCh1X2NoYXIgKikmRiwgJmZfY3R4KTsKKworCQkJCQlv ZmZzZXQgPSAoKEZbMF0gXiBGWzFdKSBeIChGWzJdIF4gRlszXSkpOworCisJCQkJCU1ENUluaXQo JmdfY3R4KTsKKwkJCQkJTUQ1VXBkYXRlKCZnX2N0eCwgKHVfY2hhciAqKSZpbnAtPmlucF9sYWRk ciwKKwkJCQkJICAgIHNpemVvZihpbnAtPmlucF9sYWRkcikpOworCQkJCQlNRDVVcGRhdGUoJmdf Y3R4LCAodV9jaGFyICopJmlucC0+aW5wX2ZhZGRyLAorCQkJCQkgICAgc2l6ZW9mKGlucC0+aW5w X2ZhZGRyKSk7CisJCQkJCU1ENVVwZGF0ZSgmZ19jdHgsICh1X2NoYXIgKikmaW5wLT5pbnBfZnBv cnQsCisJCQkJCSAgICBzaXplb2YoaW5wLT5pbnBfZnBvcnQpKTsKKwkJCQkJTUQ1VXBkYXRlKCZn X2N0eCwgKHVfY2hhciAqKXNlY3JldF9nLAorCQkJCQkgICAgc2l6ZW9mKHNlY3JldF9nKSk7CisJ CQkJCU1ENUZpbmFsKCh1X2NoYXIgKikmRywgJmdfY3R4KTsKKworCQkJCQlpbmRleCA9ICgoR1sw XSBeIEdbMV0pIF4gKEdbMl0gXiBHWzNdKSkgJSBzaXplb2YodGFibGUpOworCisJCQkJCWRvIHsK KwkJCQkJCWlmIChjb3VudC0tIDwgMCkJLyogY29tcGxldGVseSB1c2VkPyAqLworCQkJCQkJCXJl dHVybiAoRUFERFJOT1RBVkFJTCk7CisKKwkJCQkJCSpsYXN0cG9ydCA9IGZpcnN0ICsgCisJCQkJ CQkgICAgKG9mZnNldCArIHRhYmxlW2luZGV4XSsrKSAlIGNvdW50OworCisJCQkJCQlpZiAoKmxh c3Rwb3J0IDwgZmlyc3QgfHwgKmxhc3Rwb3J0ID4gbGFzdCkKKwkJCQkJCQkqbGFzdHBvcnQgPSBm aXJzdDsKKwkJCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKKwkJCQkJfSB3aGlsZSAoaW5f cGNibG9va3VwX2xvY2FsKHBjYmluZm8sIGxhZGRyLAorCQkJCQkgICAgbHBvcnQsIHdpbGQsIGNy ZWQpKTsKKwkJCQl9CisJCQkJYnJlYWs7CisJCQljYXNlIElOUF9SRkM2MDU2X0FMR18zOgkvKiBT aW1wbGUgSGFzaC1CYXNlZCBQb3J0IFNlbGVjdGlvbiBBbGdvcml0aG0gKi8KKwkJCQl7CisJCQkJ CU1ENV9DVFggZl9jdHg7CisJCQkJCXVfaW50MzJfdCBGWzRdID0geyAwLCAwLCAwLCAwIH07CisJ CQkJCXVfaW50MzJfdCBzZWNyZXRfZls0XSA9IHsgMCwgMCwgMCwgMCB9OworCQkJCQl1X2ludDMy X3Qgb2Zmc2V0ID0gMDsKKworCQkJCQlzZWNyZXRfZlswXSA9IGFyYzRyYW5kb20oKTsKKwkJCQkJ c2VjcmV0X2ZbMV0gPSBhcmM0cmFuZG9tKCk7CisJCQkJCXNlY3JldF9mWzJdID0gYXJjNHJhbmRv bSgpOworCQkJCQlzZWNyZXRfZlszXSA9IGFyYzRyYW5kb20oKTsKKworCQkJCQlNRDVJbml0KCZm X2N0eCk7CisJCQkJCU1ENVVwZGF0ZSgmZl9jdHgsICh1X2NoYXIgKikmaW5wLT5pbnBfbGFkZHIs CisJCQkJCSAgICBzaXplb2YoaW5wLT5pbnBfbGFkZHIpKTsKKwkJCQkJTUQ1VXBkYXRlKCZmX2N0 eCwgKHVfY2hhciAqKSZpbnAtPmlucF9mYWRkciwKKwkJCQkJICAgIHNpemVvZihpbnAtPmlucF9m YWRkcikpOworCQkJCQlNRDVVcGRhdGUoJmZfY3R4LCAodV9jaGFyICopJmlucC0+aW5wX2Zwb3J0 LAorCQkJCQkgICAgc2l6ZW9mKGlucC0+aW5wX2Zwb3J0KSk7CisJCQkJCU1ENVVwZGF0ZSgmZl9j dHgsICh1X2NoYXIgKilzZWNyZXRfZiwKKwkJCQkJICAgIHNpemVvZihzZWNyZXRfZikpOworCQkJ CQlNRDVGaW5hbCgodV9jaGFyICopJkYsICZmX2N0eCk7CisKKwkJCQkJb2Zmc2V0ID0gKChGWzBd IF4gRlsxXSkgXiAoRlsyXSBeIEZbM10pKTsKKworCQkJCQlkbyB7CisJCQkJCQlpZiAoY291bnQt LSA8IDApCS8qIGNvbXBsZXRlbHkgdXNlZD8gKi8KKwkJCQkJCQlyZXR1cm4gKEVBRERSTk9UQVZB SUwpOworCisJCQkJCQkqbGFzdHBvcnQgPSBmaXJzdCArICgoYXJjNHJhbmRvbSgpICUgNjU1MzYp ICsgCisJCQkJCQkgICAgKG9mZnNldCAlIDY1NTM2KSkgJSBjb3VudDsKKworCQkJCQkJaWYgKCps YXN0cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9ydCA+IGxhc3QpCisJCQkJCQkJKmxhc3Rwb3J0ID0g Zmlyc3Q7CisJCQkJCQlscG9ydCA9IGh0b25zKCpsYXN0cG9ydCk7CisJCQkJCX0gd2hpbGUgKGlu X3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRkciwKKwkJCQkJICAgIGxwb3J0LCB3aWxkLCBj cmVkKSk7CQkJCQorCQkJCX0KKwkJCQlicmVhazsKKwkJCWNhc2UgSU5QX1JGQzYwNTZfQUxHXzI6 CS8qIFNpbXBsZSBQb3J0IFJhbmRvbWl6YXRpb24gQWxnb3JpdGhtIElJICovCisJCQkJZG8gewor CQkJCQlpZiAoY291bnQtLSA8IDApCS8qIGNvbXBsZXRlbHkgdXNlZD8gKi8KKwkJCQkJCXJldHVy biAoRUFERFJOT1RBVkFJTCk7CisKKwkJCQkJKmxhc3Rwb3J0ID0gZmlyc3QgKyAoYXJjNHJhbmRv bSgpICUgKGxhc3QgLSBmaXJzdCkpOworCisJCQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAq bGFzdHBvcnQgPiBsYXN0KQorCQkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJCWxwb3J0ID0g aHRvbnMoKmxhc3Rwb3J0KTsKKwkJCQl9IHdoaWxlIChpbl9wY2Jsb29rdXBfbG9jYWwocGNiaW5m bywgbGFkZHIsCisJCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CisJCQkJYnJlYWs7CisJCQlj YXNlIElOUF9SRkM2MDU2X0FMR18xOgkvKiBTaW1wbGUgUG9ydCBSYW5kb21pemF0aW9uIEFsZ29y aXRobSBJICovCisJCQlkZWZhdWx0OgorCQkJCSpsYXN0cG9ydCA9IGZpcnN0ICsgKGFyYzRyYW5k b20oKSAlIChsYXN0IC0gZmlyc3QpKTsKKworCQkJCWRvIHsKKwkJCQkJaWYgKGNvdW50LS0gPCAw KQkvKiBjb21wbGV0ZWx5IHVzZWQ/ICovCisJCQkJCQlyZXR1cm4gKEVBRERSTk9UQVZBSUwpOwor CisJCQkJCSsrKmxhc3Rwb3J0OworCisJCQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFz dHBvcnQgPiBsYXN0KQorCQkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJCWxwb3J0ID0gaHRv bnMoKmxhc3Rwb3J0KTsKKwkJCQl9IHdoaWxlIChpbl9wY2Jsb29rdXBfbG9jYWwocGNiaW5mbywg bGFkZHIsCisJCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CisJCQl9CisJCX0gZWxzZSB7CisJ CQlkbyB7CisJCQkJaWYgKGNvdW50LS0gPCAwKSAgICAgICAgLyogY29tcGxldGVseSB1c2VkPyAq LworCQkJCQlyZXR1cm4gKEVBRERSTk9UQVZBSUwpOworCQorCQkJCSsrKmxhc3Rwb3J0OworCisJ CQkJaWYgKCpsYXN0cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9ydCA+IGxhc3QpCisJCQkJCSpsYXN0 cG9ydCA9IGZpcnN0OworCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKKwkJCX0gd2hpbGUg KGluX3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRkciwKKwkJCSAgICBscG9ydCwgd2lsZCwg Y3JlZCkpOworCQl9CiAJfQogCSpsYWRkcnAgPSBsYWRkci5zX2FkZHI7CiAJKmxwb3J0cCA9IGxw b3J0OwpkaWZmIC1yIDBkNjdmOWM5ODJmNyBzcmMvc3lzL25ldGluZXQvaW5fcGNiLmgKLS0tIGEv c3JjL3N5cy9uZXRpbmV0L2luX3BjYi5oCU1vbiBKYW4gMzEgMTE6MzU6MjQgMjAxMSArMDIwMAor KysgYi9zcmMvc3lzL25ldGluZXQvaW5fcGNiLmgJTW9uIEphbiAzMSAxNDoyOTo1MiAyMDExICsw MjAwCkBAIC00NTIsNiArNDUyLDE1IEBACiAKICNkZWZpbmUJSU5QX0NIRUNLX1NPQ0tBRihzbywg YWYpCShJTlBfU09DS0FGKHNvKSA9PSBhZikKIAorLyoKKyAqIFJGQzYwNTYgUG9ydCBSYW5kb21p emF0aW9uIEFsZ29yaXRobXMKKyAqLworI2RlZmluZQlJTlBfUkZDNjA1Nl9BTEdfMQkxCS8qIFNp bXBsZSBQb3J0IFJhbmRvbWl6YXRpb24gQWxnb3JpdGhtIEkgKi8KKyNkZWZpbmUJSU5QX1JGQzYw NTZfQUxHXzIJMgkvKiBTaW1wbGUgUG9ydCBSYW5kb21pemF0aW9uIEFsZ29yaXRobSBJSSAqLwor I2RlZmluZQlJTlBfUkZDNjA1Nl9BTEdfMwkzCS8qIFNpbXBsZSBIYXNoLUJhc2VkIFBvcnQgU2Vs ZWN0aW9uIEFsZ29yaXRobSAqLworI2RlZmluZQlJTlBfUkZDNjA1Nl9BTEdfNAk0CS8qIERvdWJs ZS1IYXNoIFBvcnQgU2VsZWN0aW9uIEFsZ29yaXRobSAqLworI2RlZmluZQlJTlBfUkZDNjA1Nl9B TEdfNQk1CS8qIFJhbmRvbS1JbmNyZW1lbnRzIFBvcnQgU2VsZWN0aW9uIEFsZ29yaXRobSAqLwor CiAjaWZkZWYgX0tFUk5FTAogVk5FVF9ERUNMQVJFKGludCwgaXBwb3J0X3Jlc2VydmVkaGlnaCk7 CiBWTkVUX0RFQ0xBUkUoaW50LCBpcHBvcnRfcmVzZXJ2ZWRsb3cpOwpAQCAtNDY2LDYgKzQ3NSw4 IEBACiBWTkVUX0RFQ0xBUkUoaW50LCBpcHBvcnRfcmFuZG9tdGltZSk7CiBWTkVUX0RFQ0xBUkUo aW50LCBpcHBvcnRfc3RvcHJhbmRvbSk7CiBWTkVUX0RFQ0xBUkUoaW50LCBpcHBvcnRfdGNwYWxs b2NzKTsKK1ZORVRfREVDTEFSRSh1X2ludCwgaXBwb3J0X3JhbmRvbWFsZ192ZXIpOworVk5FVF9E RUNMQVJFKHVfaW50LCBpcHBvcnRfcmFuZG9tYWxnX2FsZzVfdHJhZGVvZmYpOwogCiAjZGVmaW5l CVZfaXBwb3J0X3Jlc2VydmVkaGlnaAlWTkVUKGlwcG9ydF9yZXNlcnZlZGhpZ2gpCiAjZGVmaW5l CVZfaXBwb3J0X3Jlc2VydmVkbG93CVZORVQoaXBwb3J0X3Jlc2VydmVkbG93KQpAQCAtNDgwLDYg KzQ5MSw4IEBACiAjZGVmaW5lCVZfaXBwb3J0X3JhbmRvbXRpbWUJVk5FVChpcHBvcnRfcmFuZG9t dGltZSkKICNkZWZpbmUJVl9pcHBvcnRfc3RvcHJhbmRvbQlWTkVUKGlwcG9ydF9zdG9wcmFuZG9t KQogI2RlZmluZQlWX2lwcG9ydF90Y3BhbGxvY3MJVk5FVChpcHBvcnRfdGNwYWxsb2NzKQorI2Rl ZmluZSBWX2lwcG9ydF9yYW5kb21hbGdfdmVyCVZORVQoaXBwb3J0X3JhbmRvbWFsZ192ZXIpCisj ZGVmaW5lIFZfaXBwb3J0X3JhbmRvbWFsZ19hbGc1X3RyYWRlb2ZmCVZORVQoaXBwb3J0X3JhbmRv bWFsZ19hbGc1X3RyYWRlb2ZmKQogCiBleHRlcm4gc3RydWN0IGNhbGxvdXQgaXBwb3J0X3RpY2tf Y2FsbG91dDsKIApkaWZmIC1yIDBkNjdmOWM5ODJmNyBzcmMvc3lzL25ldGluZXQ2L2luNl9zcmMu YwotLS0gYS9zcmMvc3lzL25ldGluZXQ2L2luNl9zcmMuYwlNb24gSmFuIDMxIDExOjM1OjI0IDIw MTEgKzAyMDAKKysrIGIvc3JjL3N5cy9uZXRpbmV0Ni9pbjZfc3JjLmMJTW9uIEphbiAzMSAxNDoy OTo1MiAyMDExICswMjAwCkBAIC0xMDgsNiArMTA4LDggQEAKICNpbmNsdWRlIDxuZXRpbmV0Ni9z Y29wZTZfdmFyLmg+CiAjaW5jbHVkZSA8bmV0aW5ldDYvbmQ2Lmg+CiAKKyNpbmNsdWRlIDxzeXMv bWQ1Lmg+CisKIHN0YXRpYyBzdHJ1Y3QgbXR4IGFkZHJzZWxfbG9jazsKICNkZWZpbmUJQUREUlNF TF9MT0NLX0lOSVQoKQltdHhfaW5pdCgmYWRkcnNlbF9sb2NrLCAiYWRkcnNlbF9sb2NrIiwgTlVM TCwgTVRYX0RFRikKICNkZWZpbmUJQUREUlNFTF9MT0NLKCkJCW10eF9sb2NrKCZhZGRyc2VsX2xv Y2spCkBAIC05MTksMjMgKzkyMSwxOTUgQEAKIAkJbGFzdCA9IGF1eDsKIAl9CiAKLQlpZiAoZG9y YW5kb20pCi0JCSpsYXN0cG9ydCA9IGZpcnN0ICsgKGFyYzRyYW5kb20oKSAlIChsYXN0IC0gZmly c3QpKTsKLQogCWNvdW50ID0gbGFzdCAtIGZpcnN0OwogCi0JZG8gewotCQlpZiAoY291bnQtLSA8 IDApIHsJLyogY29tcGxldGVseSB1c2VkPyAqLwotCQkJLyogVW5kbyBhbiBhZGRyZXNzIGJpbmQg dGhhdCBtYXkgaGF2ZSBvY2N1cnJlZC4gKi8KLQkJCWlucC0+aW42cF9sYWRkciA9IGluNmFkZHJf YW55OwotCQkJcmV0dXJuIChFQUREUk5PVEFWQUlMKTsKKwkvKgorCSAqIEFjY29yZGluZyB0byBS RkMgNjA1NiB0aGVyZSBhcmUgNSAoZml2ZSkgcG9zc2libGUgYWxnb3JpdGhtcworCSAqIGZvciBy YW5kb20gcG9ydCBhbGxvY2F0aW9uLiBVc2FnZSBvZiBhIHBhcnRpY3VsYXIgYWxnb3JpdGhtCisJ ICogaXMgc3BlY2lmaWVkIHdpdGggdGhlICduZXQuaW5ldC5pcC5wb3J0cmFuZ2UucmFuZG9tYWxn LnZlcnNpb24nCisJICogc3lzY3RsIHZhcmlhYmxlLiBEZWZhdWx0IHZhbHVlIGlzIDEsIHdoaWNo IHJlcHJlc2VudHMgdGhlCisJICogbGVnYWN5IHJhbmRvbSBwb3J0IGFsbG9jYXRpb24gYWxnb3Jp dGhtIGluIEZyZWVCU0QuCisJICovCisJaWYgKGRvcmFuZG9tKSB7CisJCXN3aXRjaCAoVl9pcHBv cnRfcmFuZG9tYWxnX3ZlcikgeworCQljYXNlIElOUF9SRkM2MDU2X0FMR181OgkvKiBSYW5kb20t SW5jcmVtZW50cyBQb3J0IFNlbGVjdGlvbiAqLworCQkJZG8geworCQkJCWlmIChjb3VudC0tIDwg MCkgewkvKiBjb21wbGV0ZWx5IHVzZWQ/ICovCisJCQkJCS8qIFVuZG8gYW4gYWRkcmVzcyBiaW5k IHRoYXQgbWF5IGhhdmUgb2NjdXJyZWQuICovCisJCQkJCWlucC0+aW42cF9sYWRkciA9IGluNmFk ZHJfYW55OworCQkJCQlyZXR1cm4gKEVBRERSTk9UQVZBSUwpOworCQkJCX0KKworCQkJCSpsYXN0 cG9ydCA9IGZpcnN0ICsgKChhcmM0cmFuZG9tKCkgJSA2NTUzNikgKworCQkJCSAgICAoYXJjNHJh bmRvbSgpICUgVl9pcHBvcnRfcmFuZG9tYWxnX2FsZzVfdHJhZGVvZmYpICsgMSk7CisKKwkJCQlp ZiAoKmxhc3Rwb3J0IDwgZmlyc3QgfHwgKmxhc3Rwb3J0ID4gbGFzdCkKKwkJCQkJKmxhc3Rwb3J0 ID0gZmlyc3Q7CisJCQkJbHBvcnQgPSBodG9ucygqbGFzdHBvcnQpOworCQkJfSB3aGlsZSAoaW42 X3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCAmaW5wLT5pbjZwX2xhZGRyLAorCQkJICAgIGxwb3J0 LCB3aWxkLCBjcmVkKSk7CisJCQlicmVhazsKKwkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfNDogLyog RG91YmxlLUhhc2ggUG9ydCBTZWxlY3Rpb24gQWxnb3JpdGhtICovCisJCQl7CisJCQkJTUQ1X0NU WCBmX2N0eDsKKwkJCQlNRDVfQ1RYIGdfY3R4OworCQkJCXVfaW50MzJfdCBGWzRdID0geyAwLCAw LCAwLCAwIH07CisJCQkJdV9pbnQzMl90IEdbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQl1X2lu dDMyX3Qgc2VjcmV0X2ZbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQl1X2ludDMyX3Qgc2VjcmV0 X2dbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQl1X2ludDE2X3QgdGFibGVbMTZdOworCQkJCXVf aW50MzJfdCBpbmRleCA9IDA7CisJCQkJdV9pbnQzMl90IG9mZnNldCA9IDA7CisKKwkJCQlzZWNy ZXRfZlswXSA9IGFyYzRyYW5kb20oKTsKKwkJCQlzZWNyZXRfZlsxXSA9IGFyYzRyYW5kb20oKTsK KwkJCQlzZWNyZXRfZlsyXSA9IGFyYzRyYW5kb20oKTsKKwkJCQlzZWNyZXRfZlszXSA9IGFyYzRy YW5kb20oKTsKKworCQkJCXNlY3JldF9nWzBdID0gYXJjNHJhbmRvbSgpOworCQkJCXNlY3JldF9n WzFdID0gYXJjNHJhbmRvbSgpOworCQkJCXNlY3JldF9nWzJdID0gYXJjNHJhbmRvbSgpOworCQkJ CXNlY3JldF9nWzNdID0gYXJjNHJhbmRvbSgpOworCisJCQkJZm9yIChpbmRleCA9IDA7IGluZGV4 IDwgc2l6ZW9mKHRhYmxlKTsgaW5kZXgrKykKKwkJCQkJdGFibGVbaW5kZXhdID0gYXJjNHJhbmRv bSgpICUgNjU1MzY7CisKKwkJCQlNRDVJbml0KCZmX2N0eCk7CisJCQkJTUQ1VXBkYXRlKCZmX2N0 eCwgKHVfY2hhciAqKSZpbnAtPmluNnBfbGFkZHIsCisJCQkJICAgIHNpemVvZihpbnAtPmluNnBf bGFkZHIpKTsKKwkJCQlNRDVVcGRhdGUoJmZfY3R4LCAodV9jaGFyICopJmlucC0+aW42cF9mYWRk ciwKKwkJCQkgICAgc2l6ZW9mKGlucC0+aW42cF9mYWRkcikpOworCQkJCU1ENVVwZGF0ZSgmZl9j dHgsICh1X2NoYXIgKikmaW5wLT5pbnBfZnBvcnQsCisJCQkJICAgIHNpemVvZihpbnAtPmlucF9m cG9ydCkpOworCQkJCU1ENVVwZGF0ZSgmZl9jdHgsICh1X2NoYXIgKilzZWNyZXRfZiwKKwkJCQkg ICAgc2l6ZW9mKHNlY3JldF9mKSk7CisJCQkJTUQ1RmluYWwoKHVfY2hhciAqKSZGLCAmZl9jdHgp OworCisJCQkJb2Zmc2V0ID0gKChGWzBdIF4gRlsxXSkgXiAoRlsyXSBeIEZbM10pKTsKKworCQkJ CU1ENUluaXQoJmdfY3R4KTsKKwkJCQlNRDVVcGRhdGUoJmdfY3R4LCAodV9jaGFyICopJmlucC0+ aW42cF9sYWRkciwKKwkJCQkgICAgc2l6ZW9mKGlucC0+aW42cF9sYWRkcikpOworCQkJCU1ENVVw ZGF0ZSgmZ19jdHgsICh1X2NoYXIgKikmaW5wLT5pbjZwX2ZhZGRyLAorCQkJCSAgICBzaXplb2Yo aW5wLT5pbjZwX2ZhZGRyKSk7CisJCQkJTUQ1VXBkYXRlKCZnX2N0eCwgKHVfY2hhciAqKSZpbnAt PmlucF9mcG9ydCwKKwkJCQkgICAgc2l6ZW9mKGlucC0+aW5wX2Zwb3J0KSk7CisJCQkJTUQ1VXBk YXRlKCZnX2N0eCwgKHVfY2hhciAqKXNlY3JldF9nLAorCQkJCSAgICBzaXplb2Yoc2VjcmV0X2cp KTsKKwkJCQlNRDVGaW5hbCgodV9jaGFyICopJkcsICZnX2N0eCk7CisKKwkJCQlpbmRleCA9ICgo R1swXSBeIEdbMV0pIF4gKEdbMl0gXiBHWzNdKSkgJSBzaXplb2YodGFibGUpOworCisJCQkJZG8g eworCQkJCQlpZiAoY291bnQtLSA8IDApIHsJLyogY29tcGxldGVseSB1c2VkPyAqLworCQkJCQkJ LyogVW5kbyBhbiBhZGRyZXNzIGJpbmQgdGhhdCBtYXkgaGF2ZSBvY2N1cnJlZC4gKi8KKwkJCQkJ CWlucC0+aW42cF9sYWRkciA9IGluNmFkZHJfYW55OworCQkJCQkJcmV0dXJuIChFQUREUk5PVEFW QUlMKTsKKwkJCQkJfQorCisJCQkJCSpsYXN0cG9ydCA9IGZpcnN0ICsKKwkJCQkJICAgIChvZmZz ZXQgKyB0YWJsZVtpbmRleF0rKykgJSBjb3VudDsKKworCQkJCQlpZiAoKmxhc3Rwb3J0IDwgZmly c3QgfHwgKmxhc3Rwb3J0ID4gbGFzdCkKKwkJCQkJCSpsYXN0cG9ydCA9IGZpcnN0OworCQkJCQls cG9ydCA9IGh0b25zKCpsYXN0cG9ydCk7CisJCQkJfSB3aGlsZSAoaW42X3BjYmxvb2t1cF9sb2Nh bChwY2JpbmZvLCAmaW5wLT5pbjZwX2xhZGRyLAorCQkJCSAgICBscG9ydCwgd2lsZCwgY3JlZCkp OworCQkJfQorCQkJYnJlYWs7CisJCWNhc2UgSU5QX1JGQzYwNTZfQUxHXzM6IC8qIFNpbXBsZSBI YXNoLUJhc2VkIFBvcnQgU2VsZWN0aW9uIEFsZ29yaXRobSAqLworCQkJeworCQkJCU1ENV9DVFgg Zl9jdHg7CisJCQkJdV9pbnQzMl90IEZbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQl1X2ludDMy X3Qgc2VjcmV0X2ZbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQl1X2ludDMyX3Qgb2Zmc2V0ID0g MDsKKworCQkJCXNlY3JldF9mWzBdID0gYXJjNHJhbmRvbSgpOworCQkJCXNlY3JldF9mWzFdID0g YXJjNHJhbmRvbSgpOworCQkJCXNlY3JldF9mWzJdID0gYXJjNHJhbmRvbSgpOworCQkJCXNlY3Jl dF9mWzNdID0gYXJjNHJhbmRvbSgpOworCisJCQkJTUQ1SW5pdCgmZl9jdHgpOworCQkJCU1ENVVw ZGF0ZSgmZl9jdHgsICh1X2NoYXIgKikmaW5wLT5pbjZwX2xhZGRyLAorCQkJCSAgICBzaXplb2Yo aW5wLT5pbjZwX2xhZGRyKSk7CisJCQkJTUQ1VXBkYXRlKCZmX2N0eCwgKHVfY2hhciAqKSZpbnAt PmluNnBfZmFkZHIsCisJCQkJICAgIHNpemVvZihpbnAtPmluNnBfZmFkZHIpKTsKKwkJCQlNRDVV cGRhdGUoJmZfY3R4LCAodV9jaGFyICopJmlucC0+aW5wX2Zwb3J0LAorCQkJCSAgICBzaXplb2Yo aW5wLT5pbnBfZnBvcnQpKTsKKwkJCQlNRDVVcGRhdGUoJmZfY3R4LCAodV9jaGFyICopc2VjcmV0 X2YsCisJCQkJICAgIHNpemVvZihzZWNyZXRfZikpOworCQkJCU1ENUZpbmFsKCh1X2NoYXIgKikm RiwgJmZfY3R4KTsKKworCQkJCW9mZnNldCA9ICgoRlswXSBeIEZbMV0pIF4gKEZbMl0gXiBGWzNd KSk7CisKKwkJCQlkbyB7CisJCQkJCWlmIChjb3VudC0tIDwgMCkgewkvKiBjb21wbGV0ZWx5IHVz ZWQ/ICovCisJCQkJCQkvKiBVbmRvIGFuIGFkZHJlc3MgYmluZCB0aGF0IG1heSBoYXZlIG9jY3Vy cmVkLiAqLworCQkJCQkJaW5wLT5pbjZwX2xhZGRyID0gaW42YWRkcl9hbnk7CisJCQkJCQlyZXR1 cm4gKEVBRERSTk9UQVZBSUwpOworCQkJCQl9CisKKwkJCQkJKmxhc3Rwb3J0ID0gZmlyc3QgKyAo KGFyYzRyYW5kb20oKSAlIDY1NTM2KSArCisJCQkJCSAgICAob2Zmc2V0ICUgNjU1MzYpKSAlIGNv dW50OworCisJCQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFzdHBvcnQgPiBsYXN0KQor CQkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsK KwkJCQl9IHdoaWxlIChpbjZfcGNibG9va3VwX2xvY2FsKHBjYmluZm8sICZpbnAtPmluNnBfbGFk ZHIsCisJCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CisJCQl9CisJCQlicmVhazsKKwkJY2Fz ZSBJTlBfUkZDNjA1Nl9BTEdfMjoJLyogU2ltcGxlIFBvcnQgUmFuZG9taXphdGlvbiBBbGdvcml0 aG0gSUkgKi8KKwkJCWRvIHsKKwkJCQlpZiAoY291bnQtLSA8IDApIHsJLyogY29tcGxldGVseSB1 c2VkPyAqLworCQkJCQkvKiBVbmRvIGFuIGFkZHJlc3MgYmluZCB0aGF0IG1heSBoYXZlIG9jY3Vy cmVkLiAqLworCQkJCQlpbnAtPmluNnBfbGFkZHIgPSBpbjZhZGRyX2FueTsKKwkJCQkJcmV0dXJu IChFQUREUk5PVEFWQUlMKTsKKwkJCQl9CisKKwkJCQkqbGFzdHBvcnQgPSBmaXJzdCArIChhcmM0 cmFuZG9tKCkgJSAobGFzdCAtIGZpcnN0KSk7CisKKwkJCQlpZiAoKmxhc3Rwb3J0IDwgZmlyc3Qg fHwgKmxhc3Rwb3J0ID4gbGFzdCkKKwkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJbHBvcnQg PSBodG9ucygqbGFzdHBvcnQpOworCQkJfSB3aGlsZSAoaW42X3BjYmxvb2t1cF9sb2NhbChwY2Jp bmZvLCAmaW5wLT5pbjZwX2xhZGRyLAorCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CisJCQli cmVhazsKKwkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfMToJLyogU2ltcGxlIFBvcnQgUmFuZG9taXph dGlvbiBBbGdvcml0aG0gSSAqLworCQlkZWZhdWx0OgorCQkJKmxhc3Rwb3J0ID0gZmlyc3QgKyAo YXJjNHJhbmRvbSgpICUgKGxhc3QgLSBmaXJzdCkpOworCisJCQlkbyB7CisJCQkJaWYgKGNvdW50 LS0gPCAwKSB7CS8qIGNvbXBsZXRlbHkgdXNlZD8gKi8KKwkJCQkJLyogVW5kbyBhbiBhZGRyZXNz IGJpbmQgdGhhdCBtYXkgaGF2ZSBvY2N1cnJlZC4gKi8KKwkJCQkJaW5wLT5pbjZwX2xhZGRyID0g aW42YWRkcl9hbnk7CisJCQkJCXJldHVybiAoRUFERFJOT1RBVkFJTCk7CisJCQkJfQorCisJCQkJ KysqbGFzdHBvcnQ7CisKKwkJCQlpZiAoKmxhc3Rwb3J0IDwgZmlyc3QgfHwgKmxhc3Rwb3J0ID4g bGFzdCkKKwkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJbHBvcnQgPSBodG9ucygqbGFzdHBv cnQpOworCQkJfSB3aGlsZSAoaW42X3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCAmaW5wLT5pbjZw X2xhZGRyLAorCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CiAJCX0KLQkJKysqbGFzdHBvcnQ7 Ci0JCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFzdHBvcnQgPiBsYXN0KQotCQkJKmxhc3Rw b3J0ID0gZmlyc3Q7Ci0JCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKLQl9IHdoaWxlIChpbjZf cGNibG9va3VwX2xvY2FsKHBjYmluZm8sICZpbnAtPmluNnBfbGFkZHIsCi0JICAgIGxwb3J0LCB3 aWxkLCBjcmVkKSk7CisJfSBlbHNlIHsKKwkJZG8geworCQkJaWYgKGNvdW50LS0gPCAwKSB7CS8q IGNvbXBsZXRlbHkgdXNlZD8gKi8KKwkJCQkvKiBVbmRvIGFuIGFkZHJlc3MgYmluZCB0aGF0IG1h eSBoYXZlIG9jY3VycmVkLiAqLworCQkJCWlucC0+aW42cF9sYWRkciA9IGluNmFkZHJfYW55Owor CQkJCXJldHVybiAoRUFERFJOT1RBVkFJTCk7CisJCQl9CisKKwkJCSsrKmxhc3Rwb3J0OworCisJ CQlpZiAoKmxhc3Rwb3J0IDwgZmlyc3QgfHwgKmxhc3Rwb3J0ID4gbGFzdCkKKwkJCQkqbGFzdHBv cnQgPSBmaXJzdDsKKwkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKKwkJfSB3aGlsZSAoaW42 X3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCAmaW5wLT5pbjZwX2xhZGRyLAorCQkgICAgbHBvcnQs IHdpbGQsIGNyZWQpKTsKKwl9CiAKIAlpbnAtPmlucF9scG9ydCA9IGxwb3J0OwogCWlmIChpbl9w Y2JpbnNoYXNoKGlucCkgIT0gMCkgewo= --20cf307cfff4958843049d874a67-- From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 22:57:20 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22FA11065687; Wed, 2 Mar 2011 22:57:20 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 566EB8FC12; Wed, 2 Mar 2011 22:57:19 +0000 (UTC) Received: by wyb32 with SMTP id 32so627710wyb.13 for ; Wed, 02 Mar 2011 14:57:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WdJ0ZReYMTMSw+qy6sPS791E6H6QDwiU6UtBbTCGFH4=; b=PvOPmdeZ/k5XKct1PI2Rt07kXXNTHNZ/MF7tPMsSzYGJPdJZGi/maKpI5/rSxfsOJ8 4+kdhVeqb2FUUeY5chGeEZ20Cpn8BbR2EAWHkn09A62RAW3PWWhxjBO41Ac1PbFcgULT bsE1LjPVoYWn02ycxkrpUKZYUQTBbbN8WZfvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pvVokbN/l26KYca3BI06p7BTML5lnBVaog1lAaxPrW8dokWNY0hj5y2pj9eDFu8GZt 5OG0L9QGckb4AVml5h3uakbdNSmB5wbGMVTqsSJ7Nl8meR5PebsMEdCQh+3NixtjBxrm 7EiNiXcHk4cpgFil6qDGcUHxjvTcUUkGlfC1c= MIME-Version: 1.0 Received: by 10.216.154.136 with SMTP id h8mr225276wek.84.1299106638309; Wed, 02 Mar 2011 14:57:18 -0800 (PST) Received: by 10.216.25.72 with HTTP; Wed, 2 Mar 2011 14:57:18 -0800 (PST) In-Reply-To: <20110302215258.GA48643@atarininja.org> References: <1298961441.2888.2.camel@core.nessbank> <20110302194540.0000018f@unknown> <20110302215258.GA48643@atarininja.org> Date: Wed, 2 Mar 2011 16:57:18 -0600 Message-ID: From: Brandon Gooch To: Wesley Shields Content-Type: multipart/mixed; boundary=0016e649c770b3a94d049d87d503 Cc: Bruce Cran , freebsd-net@freebsd.org, Rui Paulo Subject: Re: Interface descriptions via pcap broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:57:20 -0000 --0016e649c770b3a94d049d87d503 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 2, 2011 at 3:52 PM, Wesley Shields wrote: > On Wed, Mar 02, 2011 at 07:45:40PM +0000, Bruce Cran wrote: >> On Wed, 2 Mar 2011 13:40:57 -0600 >> Brandon Gooch wrote: >> >> > BTW, if you give your devices descriptions, libpcap >> > starts to behave again; this could be a clue to the source of the bug >> > :/ >> >> 0xa5 is the malloc fill pattern when debugging is enabled, and >> having recently reinstalled FreeBSD I forgot to create the malloc.conf >> symlink. So something's reading from uninitialized memory. > > Does commit c65292b04b98d6a76d58c5a54ca8f81463bf24de in the libpcap git > tree look like it could help? I haven't checked in detail but I think it > might have never made it into a release yet? > > https://github.com/mcr/libpcap/commit/c65292b04b98d6a76d58c5a54ca8f81463bf24de > > -- WXS I applied the patch attached (diff'd against the code from the github link above), rebuilt libpcap and wireshark, and the problem described no longer exists. Thanks for looking at this wxs@! -Brandon --0016e649c770b3a94d049d87d503 Content-Type: application/octet-stream; name="libpcap-inet.c.diff" Content-Disposition: attachment; filename="libpcap-inet.c.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gksuho9c0 LS0tIGNvbnRyaWIvbGlicGNhcC9pbmV0LmMub3JpZwkyMDExLTAyLTAxIDIzOjU3OjMyLjAwMDAw MDAwMCAtMDYwMAorKysgY29udHJpYi9saWJwY2FwL2luZXQuYwkyMDExLTAzLTAyIDE2OjI0OjM0 LjAwMDAwMDAwMCAtMDYwMApAQCAtNDMxLDI2ICs0MzEsNTQgQEAKIAlzdHJsY3B5KGlmcmRlc2Mu aWZyX25hbWUsIG5hbWUsIHNpemVvZiBpZnJkZXNjLmlmcl9uYW1lKTsKIAlzID0gc29ja2V0KEFG X0lORVQsIFNPQ0tfREdSQU0sIDApOwogCWlmIChzID49IDApIHsKKyNpZmRlZiBfX0ZyZWVCU0Rf XworCQkvKgorCQkgKiBPbiBGcmVlQlNELCBpZiB0aGUgYnVmZmVyIGlzbid0IGJpZyBlbm91Z2gg Zm9yIHRoZQorCQkgKiBkZXNjcmlwdGlvbiwgdGhlIGlvY3RsIHN1Y2NlZWRzLCBidXQgdGhlIGRl c2NyaXB0aW9uCisJCSAqIGlzbid0IGNvcGllZCwgaWZyX2J1ZmZlci5sZW5ndGggaXMgc2V0IHRv IHRoZSBkZXNjcmlwdGlvbgorCQkgKiBsZW5ndGgsIGFuZCBpZnJfYnVmZmVyLmJ1ZmZlciBpcyBz ZXQgdG8gTlVMTC4KKwkJICovCiAJCWZvciAoOzspIHsKIAkJCWZyZWUoZGVzY3JpcHRpb24pOwog CQkJaWYgKChkZXNjcmlwdGlvbiA9IG1hbGxvYyhkZXNjcmxlbikpICE9IE5VTEwpIHsKLSNpZmRl ZiBfX0ZyZWVCU0RfXwogCQkJCWlmcmRlc2MuaWZyX2J1ZmZlci5idWZmZXIgPSBkZXNjcmlwdGlv bjsKIAkJCQlpZnJkZXNjLmlmcl9idWZmZXIubGVuZ3RoID0gZGVzY3JsZW47Ci0jZWxzZSAvKiBf X0ZyZWVCU0RfXyAqLwotCQkJCWlmcmRlc2MuaWZyX2RhdGEgPSAoY2FkZHJfdClkZXNjcmlwdGlv bjsKLSNlbmRpZiAvKiBfX0ZyZWVCU0RfXyAqLwotCQkJCWlmIChpb2N0bChzLCBTSU9DR0lGREVT Q1IsICZpZnJkZXNjKSA9PSAwKQotCQkJCQlicmVhazsKLSNpZmRlZiBfX0ZyZWVCU0RfXwotCQkJ CWVsc2UgaWYgKGVycm5vID09IEVOQU1FVE9PTE9ORykKLQkJCQkJZGVzY3JsZW4gPSBpZnJkZXNj Lmlmcl9idWZmZXIubGVuZ3RoOwotI2VuZGlmIC8qIF9fRnJlZUJTRF9fICovCi0JCQkJZWxzZQor CQkJCWlmIChpb2N0bChzLCBTSU9DR0lGREVTQ1IsICZpZnJkZXNjKSA9PSAwKSB7CisJCQkJCWlm IChpZnJkZXNjLmlmcl9idWZmZXIuYnVmZmVyID09CisJCQkJCSAgICBkZXNjcmlwdGlvbikKKwkJ CQkJCWJyZWFrOworCQkJCQllbHNlCisJCQkJCQlkZXNjcmxlbiA9IGlmcmRlc2MuaWZyX2J1ZmZl ci5sZW5ndGg7CisJCQkJfSBlbHNlIHsKKwkJCQkJLyoKKwkJCQkJICogRmFpbGVkIHRvIGdldCBp bnRlcmZhY2UgZGVzY3JpcHRpb24uCisJCQkJCSAqLworCQkJCQlmcmVlKGRlc2NyaXB0aW9uKTsK KwkJCQkJZGVzY3JpcHRpb24gPSBOVUxMOwogCQkJCQlicmVhazsKKwkJCQl9CiAJCQl9IGVsc2UK IAkJCQlicmVhazsKIAkJfQorI2Vsc2UgLyogX19GcmVlQlNEX18gKi8KKwkJLyoKKwkJICogVGhl IG9ubHkgb3RoZXIgT1MgdGhhdCBjdXJyZW50bHkgc3VwcG9ydHMKKwkJICogU0lPQ0dJRkRFU0NS IGlzIE9wZW5CU0QsIGFuZCBpdCBoYXMgbm8gd2F5CisJCSAqIHRvIGdldCB0aGUgZGVzY3JpcHRp b24gbGVuZ3RoIC0gaXQncyBjbGFtcGVkCisJCSAqIHRvIGEgbWF4aW11bSBvZiBJRkRFU0NSU0la RS4KKwkJICovCisJCWlmICgoZGVzY3JpcHRpb24gPSBtYWxsb2MoZGVzY3JsZW4pKSAhPSBOVUxM KSB7CisJCQlpZnJkZXNjLmlmcl9kYXRhID0gKGNhZGRyX3QpZGVzY3JpcHRpb247CisJCQlpZiAo aW9jdGwocywgU0lPQ0dJRkRFU0NSLCAmaWZyZGVzYykgIT0gMCkgeworCQkJCS8qCisJCQkJICog RmFpbGVkIHRvIGdldCBpbnRlcmZhY2UgZGVzY3JpcHRpb24uCisJCQkJICovCisJCQkJZnJlZShk ZXNjcmlwdGlvbik7CisJCQkJZGVzY3JpcHRpb24gPSBOVUxMOworCQkJfQorCQl9IGVsc2UKKwkJ CWJyZWFrOworI2VuZGlmIC8qIF9fRnJlZUJTRF9fICovCiAJCWNsb3NlKHMpOwogCQlpZiAoZGVz Y3JpcHRpb24gIT0gTlVMTCAmJiBzdHJsZW4oZGVzY3JpcHRpb24pID09IDApIHsKIAkJCWZyZWUo ZGVzY3JpcHRpb24pOwo= --0016e649c770b3a94d049d87d503-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 04:07:41 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68BB6106566B; Thu, 3 Mar 2011 04:07:41 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.49.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED6E8FC1A; Thu, 3 Mar 2011 04:07:41 +0000 (UTC) Received: by syn.atarininja.org (Postfix, from userid 1001) id EC96E5C40; Wed, 2 Mar 2011 23:08:28 -0500 (EST) Date: Wed, 2 Mar 2011 23:08:28 -0500 From: Wesley Shields To: Brandon Gooch Message-ID: <20110303040828.GC48908@atarininja.org> References: <1298961441.2888.2.camel@core.nessbank> <20110302194540.0000018f@unknown> <20110302215258.GA48643@atarininja.org> 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) Cc: Bruce Cran , freebsd-net@freebsd.org, Rui Paulo Subject: Re: Interface descriptions via pcap broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 04:07:41 -0000 On Wed, Mar 02, 2011 at 04:57:18PM -0600, Brandon Gooch wrote: > On Wed, Mar 2, 2011 at 3:52 PM, Wesley Shields wrote: > > On Wed, Mar 02, 2011 at 07:45:40PM +0000, Bruce Cran wrote: > >> On Wed, 2 Mar 2011 13:40:57 -0600 > >> Brandon Gooch wrote: > >> > >> > BTW, if you give your devices descriptions, libpcap > >> > starts to behave again; this could be a clue to the source of the bug > >> > :/ > >> > >> 0xa5 is the malloc fill pattern when debugging is enabled, and > >> having recently reinstalled FreeBSD I forgot to create the malloc.conf > >> symlink. So something's reading from uninitialized memory. > > > > Does commit c65292b04b98d6a76d58c5a54ca8f81463bf24de in the libpcap git > > tree look like it could help? I haven't checked in detail but I think it > > might have never made it into a release yet? > > > > https://github.com/mcr/libpcap/commit/c65292b04b98d6a76d58c5a54ca8f81463bf24de > > > > -- WXS > > I applied the patch attached (diff'd against the code from the github > link above), rebuilt libpcap and wireshark, and the problem described > no longer exists. Thanks for looking at this wxs@! I've sent the patch along to someone with a src bit to commit. Hopefully it ends up in the tree soon... -- WXS From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 06:30:34 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C7AD106564A for ; Thu, 3 Mar 2011 06:30:34 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id BC1F98FC13 for ; Thu, 3 Mar 2011 06:30:33 +0000 (UTC) Received: (qmail 10130 invoked from network); 3 Mar 2011 09:30:42 +0300 Received: from tarkhil147-9.rostokino.net (tarkhil147-9.rostokino.net [89.222.147.9]) by mail.sub.ru ([88.212.205.2]) with ESMTP via TCP; 03 Mar 2011 06:30:42 -0000 Message-ID: <4D6F3581.6010906@webmail.sub.ru> Date: Thu, 03 Mar 2011 09:30:25 +0300 From: Alex Povolotsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4D4FA3DA.7010004@webmail.sub.ru> <20110302214601.S13400@maildrop.int.zabbadoz.net> In-Reply-To: <20110302214601.S13400@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org Subject: Re: jail source address selection doesn't work? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 06:30:34 -0000 03.03.2011 0:48, Bjoern A. Zeeb пишет: > On Mon, 7 Feb 2011, Alex Povolotsky wrote: > >> Hello! >> >> On a multihomed FreeBSD 8.1-RELEASE, in a multihomed jail, source IP >> selection suddenly refused to work. >> >> ifconfig on a box: > .... >> Seems reasonable, yes? >> >> Pinging from the box >> >> # ping 192.168.75.59 >> PING 192.168.75.59 (192.168.75.59): 56 data bytes >> 64 bytes from 192.168.75.59: icmp_seq=0 ttl=64 time=0.993 ms >> 64 bytes from 192.168.75.59: icmp_seq=1 ttl=64 time=0.986 ms >> 64 bytes from 192.168.75.59: icmp_seq=2 ttl=64 time=0.988 ms >> ^C >> --- 192.168.75.59 ping statistics --- >> 3 packets transmitted, 3 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 0.986/0.989/0.993/0.003 ms >> >> 10:45:31.425232 IP 192.168.75.4 > 192.168.75.59: ICMP echo request, >> id 12430, seq 0, length 64 >> 10:45:31.426283 IP 192.168.75.59 > 192.168.75.4: ICMP echo reply, id >> 12430, seq 0, length 64 >> 10:45:32.425415 IP 192.168.75.4 > 192.168.75.59: ICMP echo request, >> id 12430, seq 1, length 64 >> 10:45:32.426404 IP 192.168.75.59 > 192.168.75.4: ICMP echo reply, id >> 12430, seq 1, length 64 >> >> Okay, yes? >> >> From jail: >> >> # ping 192.168.75.59 >> PING 192.168.75.59 (192.168.75.59): 56 data bytes >> ^C >> --- 192.168.75.59 ping statistics --- >> 2 packets transmitted, 0 packets received, 100.0% packet loss >> >> 10:45:52.146600 IP 83.69.203.1 > 192.168.75.59: ICMP echo request, id >> 14222, seq 0, length 64 >> 10:45:53.146702 IP 83.69.203.1 > 192.168.75.59: ICMP echo request, id >> 14222, seq 1, length 64 >> >> Setting ip.saddrsel to 1 or 0 did not change anything. Kernel is >> GENERIC+ALTQ >> >> What could I miss?... > > Don't use ping to test this. a) for ping inside the jail to work you > need to enable raw sockets b) a) could give you a hint that ping does > it's own thing. Telnet did all the same thing. > > Try a telnet to a random port to the destination and verify with > tcpdump whether things are still not working correctly, of if you > establish the connection with netstat. I used telnet to connect to specific ports. Ok, let's try again 104:tarkhil@box2.u.energodata.local:...local/etc/ezjail # jls JID IP Address Hostname Path 1 192.168.82.2 test /usr/jails/test 107:tarkhil@box2.u.energodata.local:...local/etc/ezjail # jls -j 1 ip4.saddrsel true 108:tarkhil@box2.u.energodata.local:...local/etc/ezjail # jls -j 1 ip4.addr 192.168.82.2,192.168.75.2 114:tarkhil@box2.u.energodata.local:...local/etc/ezjail # tcpdump -l -n -i bce0 host 192.168.82.2 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bce0, link-type EN10MB (Ethernet), capture size 96 bytes 09:27:54.492105 IP 192.168.82.2.50823 > 192.168.72.3.22: Flags [S], seq 3819433473, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 1306232522 ecr 0], length 0 115:tarkhil@box2.u.energodata.local:...local/etc/ezjail # ifconfig bce0 bce0: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:14:5e:1a:a6:27 inet 192.168.80.41 netmask 0xffffff00 broadcast 192.168.80.255 media: Ethernet autoselect (100baseTX ) status: active test# sysctl security.jail.jailed security.jail.jailed: 1 test# ifconfig bce0: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:14:5e:1a:a6:27 media: Ethernet autoselect (100baseTX ) status: active bce1: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:14:5e:1a:a6:29 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 vlan75: flags=8843 metric 0 mtu 1500 options=103 ether 00:14:5e:1a:a6:29 inet 192.168.75.2 netmask 0xffffff00 broadcast 192.168.75.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 75 parent interface: bce1 vlan82: flags=8843 metric 0 mtu 1500 options=103 ether 00:14:5e:1a:a6:29 inet 192.168.82.2 netmask 0xffffff00 broadcast 192.168.82.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 82 parent interface: bce1 In other words, source address is selected as primary IP, and packet runs out on 100% improper interface. No specific routing, no firewall. Alex. From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 08:11:04 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B08E106564A; Thu, 3 Mar 2011 08:11:04 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id A2C198FC1C; Thu, 3 Mar 2011 08:11:03 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 8BE8413DF42; Thu, 3 Mar 2011 11:11:01 +0300 (MSK) Date: Thu, 3 Mar 2011 11:10:46 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1627628072.20110303111046@serebryakov.spb.ru> To: Arnaud Lacombe In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------51A718D33013DCD" Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel , Jan Koum , Mike Tancsa Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 08:11:04 -0000 ------------51A718D33013DCD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Arnaud. You wrote 2 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 9:55:50: >>> I have been running with 7.2.2 and so far so good. =C2=A0However, its h= ard to >>> say in my case as the box I would only periodically see the issue. >> =C2=A0As I wrote to Jack, my NIC hangs today with 7.2.2 > Do you have any detailed error ? What the output of sysctl "dev.em.X" > where X is the index of the hung interface ? One more hang. Two logs are attached. --=20 // Black Lion AKA Lev Serebryakov ------------51A718D33013DCD Content-Type: application/octet-stream; name="em0.7.2.2.hang1.log" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="em0.7.2.2.hang1.log" Pj4+IGlmY29uZmlnIGVtMAplbTA6IGZsYWdzPThjNDM8VVAsQlJPQURDQVNULFJVTk5JTkcs T0FDVElWRSxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKCW9wdGlvbnM9 MjE5YjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdDU1VN LFRTTzQsV09MX01BR0lDPgoJZXRoZXIgMDA6MWU6OGM6NzU6MDM6MGQKCWluZXQgMTkyLjE2 OC4xMzQuMyBuZXRtYXNrIDB4ZmZmZmZmMDAgYnJvYWRjYXN0IDE5Mi4xNjguMTM0LjI1NQoJ bWVkaWE6IEV0aGVybmV0IDEwMDBiYXNlVCA8ZnVsbC1kdXBsZXg+CglzdGF0dXM6IGFjdGl2 ZQo8PDwgaWZjb25maWcgZW0wCj4+PiB2bXN0YXQgLW0KICAgICAgICAgVHlwZSBJblVzZSBN ZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0cyAgU2l6ZShzKQogICAgICAgbW9kdWxlICAgMTUyICAg IDE5SyAgICAgICAtICAgICAgMTUyICAxMjgKICAgICAgICAgIFVTQiAgICA3NiAgICA2Nksg ICAgICAgLSAgICAgICA4MCAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0LDIwNDgsNDA5NgogICAg IG10eF9wb29sICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICAKICAgICBhY3BpdGFz ayAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMSAgMjA0OAogICBDQU0gcGVyaXBoICAg IDIyICAgICA2SyAgICAgICAtICAgICAgIDQ0ICAxNiwzMiw2NCwyNTYKICAgICAgc3VicHJv YyAgIDQ2MSAgIDQwOUsgICAgICAgLSAgICA0MTA5MSAgNTEyLDQwOTYKICAgICAgICAgcHJv YyAgICAgMiAgICAxNksgICAgICAgLSAgICAgICAgMiAgCiAgICAgIHNlc3Npb24gICAgMjUg ICAgIDRLICAgICAgIC0gICAgIDI2ODcgIDEyOAogICAgICAgICBwZ3JwICAgIDI3ICAgICA0 SyAgICAgICAtICAgICAyNzY5ICAxMjgKICAgICAgICAgY3JlZCAgICA2NiAgICAxMUsgICAg ICAgLSAgMjAzMTg3MiAgNjQsMjU2CiAgICAgIHVpZGluZm8gICAgIDggICAgIDNLICAgICAg IC0gICAzMzg4MTIgIDEyOCwyMDQ4CiAgICAgICBwbGltaXQgICAgMTEgICAgIDNLICAgICAg IC0gICAgMzQ0MTggIDI1NgogICAgIHBjaV9saW5rICAgIDE2ICAgICAySyAgICAgICAtICAg ICAgIDE2ICA2NCwxMjgKICAgICAgYWNwaXNlbSAgICAxOSAgICAgM0sgICAgICAgLSAgICAg ICAxOSAgMTI4CiAgICAgICBERVZGUzEgICAxNDMgICAgNzJLICAgICAgIC0gICAgICAxNTIg IDUxMgogICAgc3lzY3RsdG1wICAgICAwICAgICAwSyAgICAgICAtICAgICAgOTE0ICAxNiwz Miw2NCwxMjgKICAgIHN5c2N0bG9pZCAgMzI1MiAgIDE2MUsgICAgICAgLSAgICAgMzM4NiAg MTYsMzIsNjQsMTI4CiAgICAgICBzeXNjdGwgICAgIDAgICAgIDBLICAgICAgIC0gICAgMTU4 MDIgIDE2LDMyLDY0CiAgICAgIGNhbGxvdXQgICAgIDEgICA1MTJLICAgICAgIC0gICAgICAg IDEgIAogICAgICAgICB1bXR4ICAgNDg5ICAgIDYySyAgICAgICAtICAgICAgNDg5ICAxMjgK ICAgICBwMTAwMy4xYiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTYKICAgICAg ICAgU1dBUCAgICAgMiAgIDU0OUsgICAgICAgLSAgICAgICAgMiAgNjQKICAgICAgIERFVkZT MyAgIDE2OSAgICA0M0sgICAgICAgLSAgICAgIDE3OSAgMjU2CiAgICAgICBidXMtc2MgICAg NjMgICAzNzNLICAgICAgIC0gICAgIDEyNzEgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDIwNDgs NDA5NgogICAgICAgICAgYnVzICAgNjA5ICAgIDYySyAgICAgICAtICAgICAzNTkzICAxNiwz Miw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgIGRldnN0YXQgICAgMTQgICAgMjlLICAgICAg IC0gICAgICAgMTQgIDMyLDQwOTYKIGV2ZW50aGFuZGxlciAgICA2NyAgICAgNksgICAgICAg LSAgICAgICA2NyAgNjQsMTI4CiAgICAgICAgIGtvYmogICAgOTMgICAzNzJLICAgICAgIC0g ICAgICAxMjEgIDQwOTYKICAgICAgUGVyLWNwdSAgICAgMSAgICAgMUsgICAgICAgLSAgICAg ICAgMSAgMzIKICAgICAgICBERVZGUyAgICAyMCAgICAgMUsgICAgICAgLSAgICAgICAyMSAg MTYsMTI4CiAgICAgICAgIHJtYW4gICAxNzcgICAgMjJLICAgICAgIC0gICAgICA2MDEgIDE2 LDMyLDEyOAogICAgICAgREVWRlNQICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2 NAogICAgICAgICBzYnVmICAgICAwICAgICAwSyAgICAgICAtICAgICAxMzEyICAxNiwzMiw2 NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgcGZzX25vZGVzICAgIDIxICAgICA2 SyAgICAgICAtICAgICAgIDIxICAyNTYKICAgICAgQ0FNIFhQVCAgIDI5MiAgIDQyM0sgICAg ICAgLSAgICAgIDQxMyAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0LDIwNDgKICAgICAgICBzdGFj ayAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMiAgMjU2CiAgICB0YXNrcXVldWUgICAg MTUgICAgIDJLICAgICAgIC0gICAgICAgMTUgIDE2LDMyLDEyOAogICAgICAgVW5pdG5vICAg IDEyICAgICAxSyAgICAgICAtICAgICAgIDU0ICAzMiw2NAogICAgICAgICAgaW92ICAgICAw ICAgICAwSyAgICAgICAtICAgMjUwMzYzICAxNiwzMiw2NCwxMjgsMjU2LDUxMgogICAgICAg c2VsZWN0ICAgMTUwICAgIDE5SyAgICAgICAtIDk0NDczMjYyMTUgIDEyOCw1MTIsMTAyNAog ICAgIGlvY3Rsb3BzICAgICAwICAgICAwSyAgICAgICAtIDE3MjkxNTQyMCAgMTYsMzIsNjQs MTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgICAgIG1zZyAgICAgNCAgICAzMEsg ICAgICAgLSAgICAgICAgNCAgMjA0OCw0MDk2CiAgICAgICAgICBzZW0gICAgIDQgICAgMTFL ICAgICAgIC0gICAgICAgIDQgIDUxMiwxMDI0CiAgICAgICAgICBzaG0gICAgIDEgICAgMjBL ICAgICAgIC0gICAgICAgIDEgIAogICAgICAgICAgdHR5ICAgIDIxICAgIDIxSyAgICAgICAt ICAgICAgIDI2ICAxMDI0LDIwNDgKICAgICAgICAgIHB0cyAgICAgMSAgICAgMUsgICAgICAg LSAgICAgICAgNCAgMjU2CiAgICAgbWJ1Zl90YWcgICAgIDAgICAgIDBLICAgICAgIC0gICAg ICAgMzMgIDMyCiAgICAgICAgc2htZmQgICAgIDEgICAgIDhLICAgICAgIC0gICAgICAgIDEg IAogICAgICAgICBHRU9NICAgMTc1ICAgIDM4SyAgICAgICAtICAgICAgODcxICAxNiwzMiw2 NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgICAgICBwY2IgICAgOTUgICAgMTVLICAgICAgIC0g IDQ2NzU5NDggIDE2LDMyLDEwMjQsMjA0OCw0MDk2CiAgICAgICBzb25hbWUgICAgIDcgICAg IDFLICAgICAgIC0gMTgxMzkxNzYgIDE2LDMyLDEyOAogICAgICAgICAgYWNsICAgICAwICAg ICAwSyAgICAgICAtICAgICAxNDE5ICA0MDk2CiAgICAgICBiaW9idWYgICAgIDAgICAgIDBL ICAgICAgIC0gICAgICAxOTQgIDIwNDgKICAgICB2ZnNjYWNoZSAgICAgMSAgMTAyNEsgICAg ICAgLSAgICAgICAgMSAgCiAgIGNsX3NhdmVidWYgICAgIDAgICAgIDBLICAgICAgIC0gICAg NDYzNzIgIDY0LDEyOAogIGV4cG9ydF9ob3N0ICAgICAyICAgICAxSyAgICAgICAtICAgICAg ICAyICAyNTYKICAgICB2ZnNfaGFzaCAgICAgMSAgIDUxMksgICAgICAgLSAgICAgICAgMSAg CiAgICAgICB2bm9kZXMgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDI1NgogIHZu b2RlbWFya2VyICAgICAwICAgICAwSyAgICAgICAtICAgMTY3OTY1ICA1MTIKICAgICAgICBt b3VudCAgIDEwNCAgICAgNksgICAgICAgLSAgICAgIDMwNCAgMTYsMzIsNjQsMTI4LDI1Niw1 MTIKICAgICAgICAgIEJQRiAgICAgNyAgICAgOUsgICAgICAgLSAgICAgICAgNyAgMTI4LDUx Miw0MDk2CiAgZXRoZXJfbXVsdGkgICAgMTIgICAgIDFLICAgICAgIC0gICAgICAgMjYgIDE2 LDY0CiAgICAgICBpZmFkZHIgICAgMTQgICAgIDdLICAgICAgIC0gICAgICAgMTUgIDMyLDUx Miw0MDk2CiAgICAgICAgaWZuZXQgICAgIDMgICAgIDVLICAgICAgIC0gICAgICAgIDMgIDEy OCwyMDQ4CiAgICAgICAgY2xvbmUgICAgIDIgICAgIDhLICAgICAgIC0gICAgICAgIDIgIDQw OTYKICAgICAgIGFycGNvbSAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTYKICAg ICAgbGx0YWJsZSAgICAgMyAgICAgMksgICAgICAgLSAgICAgICAzMSAgMjU2LDUxMgogICAg ICAga2JkbXV4ICAgICA2ICAgIDEwSyAgICAgICAtICAgICAgICA2ICAxNiw1MTIsMTAyNCwy MDQ4LDQwOTYKICAgICAgICAgIExFRCAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAg MTI4CiAgICAgICBpc2FkZXYgICAgIDYgICAgIDFLICAgICAgIC0gICAgICAgIDYgIDEyOAog ICAgIHJvdXRldGJsICAgIDE0ICAgICA0SyAgICAgICAtICAgMTI1NTM3ICAzMiw2NCwxMjgs MjU2LDUxMgogICAgICAgICBpZ21wICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAy NTYKICAgICAgc2NzaV9kYSAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAxNiAgMTYKQ0FN IGRldiBxdWV1ZSAgICAgOCAgICAgMUsgICAgICAgLSAgICAgICAgOCAgMTI4CiAgaXBfbW9w dGlvbnMgICAgIDQgICAgIDFLICAgICAgIC0gICAgICAgIDggIDY0LDI1NgogICAgIGluX211 bHRpICAgICAzICAgICAxSyAgICAgICAtICAgICAgICA1ICAyNTYKICAgaW5fbWZpbHRlciAg ICAgMiAgICAgMksgICAgICAgLSAgICAgICAgNCAgMTAyNAogICAgaG9zdGNhY2hlICAgICAx ICAgIDI4SyAgICAgICAtICAgICAgICAxICAKICAgICBzeW5jYWNoZSAgICAgMSAgICA5Nksg ICAgICAgLSAgICAgICAgMSAgCiAgICAgIE5GUyBGSEEgICAgIDEgICAgIDJLICAgICAgIC0g ICAgICAyODUgIDY0LDIwNDgKICAgICAgICAgIHJwYyAgIDI5NCAgIDE1MksgICAgICAgLSAg ICAgIDkyMyAgMzIsNjQsMTI4LDI1Niw1MTIsMjA0OAphdWRpdF9ldmNsYXNzICAgMTcyICAg ICA2SyAgICAgICAtICAgICAgMjExICAzMgogICAgIHNhdmVkaW5vICAgICAwICAgICAwSyAg ICAgICAtICAgIDI3MDc2ICAyNTYKICAgIG5ld2RpcmJsayAgICAgMCAgICAgMEsgICAgICAg LSAgICAgICAgNSAgNjQKICAgICAgIGRpcnJlbSAgICAgMCAgICAgMEsgICAgICAgLSAgIDE0 NjAwOSAgNjQKICAgICAgICBta2RpciAgICAgMSAgICAgMUsgICAgICAgLSAgICAgIDQ2MiAg NjQKICAgICAgIGRpcmFkZCAgICAgMyAgICAgMUsgICAgICAgLSAgIDE0Nzc3NiAgNjQKICAg ICBmcmVlZmlsZSAgICAgMSAgICAgMUsgICAgICAgLSAgICA2OTk4MiAgNjQKICAgICBmcmVl YmxrcyAgICAgMSAgICAgMUsgICAgICAgLSAgICA3MDA3NCAgMjU2CiAgICAgZnJlZWZyYWcg ICAgIDAgICAgIDBLICAgICAgIC0gICAxMzQwNDQgIDY0CiAgIGFsbG9jaW5kaXIgICAgIDAg ICAgIDBLICAgICAgIC0gICAyODY4MDAgIDEyOAogICAgIGluZGlyZGVwICAgICAwICAgICAw SyAgICAgICAtICAgICAzNDgxICA2NAogIGFsbG9jZGlyZWN0ICAgICAzICAgICAxSyAgICAg ICAtICAgMzIxNTI5ICAyNTYKICAgIGJtc2FmZW1hcCAgICAgMiAgICAgMUsgICAgICAgLSAg ICA4MjgyNyAgMTI4CiAgICAgICBuZXdibGsgICAgIDEgICAgIDFLICAgICAgIC0gICA2MDgz MzAgIDY0LDUxMgogICAgIGlub2RlZGVwICAgICA2ICAgNTE0SyAgICAgICAtICAgMTY2NDc5 ICAyNTYKICAgICAgcGFnZWRlcCAgICAgNCAgIDEyOUsgICAgICAgLSAgICAyNTg2MyAgMTI4 CiAgdWZzX2Rpcmhhc2ggICAyMzAgICAxMDVLICAgICAgIC0gICA0MTY4NzQgIDE2LDMyLDY0 LDEyOCwyNTYsNTEyLDEwMjQKICAgIHVmc19tb3VudCAgICAxNSAgIDEyN0sgICAgICAgLSAg ICAgICAxNSAgNTEyLDIwNDgsNDA5NgogICAgICBVTUFIYXNoICAgICAzICAgICA3SyAgICAg ICAtICAgICAgICA5ICA1MTIsMTAyNCwyMDQ4LDQwOTYKICAgIENBTSBxdWV1ZSAgICA0MyAg ICAgM0sgICAgICAgLSAgICAgIDE0OCAgMTYsMzIsNjQsMjU2CiAgICAgIENBTSBTSU0gICAg IDggICAgIDJLICAgICAgIC0gICAgICAgIDggIDI1NgogICAgICAgICBjZGV2ICAgICA4ICAg ICAySyAgICAgICAtICAgICAgICA4ICAyNTYKICAgIHZtX3BnZGF0YSAgICAgMiAgIDEyOUsg ICAgICAgLSAgICAgICAgMiAgMTI4CiAgZGRiX2NhcHR1cmUgICAgIDEgICAgNDhLICAgICAg IC0gICAgICAgIDEgIAogICAgICAgYWNwaWNhICAzNzcwICAgMzg2SyAgICAgICAtICAgIDkw MzM2ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgKICAgICAgICBzaWdpbyAgICAg MSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgNjQKICAgICBmaWxlZGVzYyAgICA2MyAgICA3 OEsgICAgICAgLSAgICA2MzQyOSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQw OTYKICAgICAgICAga2VudiAgICA3NiAgICAxMUsgICAgICAgLSAgICAgICA4MCAgMTYsMzIs NjQsMTI4CiAgICAgIGlvX2FwaWMgICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDEgIDIw NDgKICAgICAgIGtxdWV1ZSAgICAgMiAgICAxM0sgICAgICAgLSAgIDE4NTQwNyAgMjU2LDIw NDgsNDA5NgogICAgICBtZW1kZXNjICAgICAxICAgICA0SyAgICAgICAtICAgICAgICAxICA0 MDk2CiAgICAgIGFjcGlkZXYgICAgNzggICAgIDVLICAgICAgIC0gICAgICAgNzggIDY0CiAg ICBwcm9jLWFyZ3MgICAgMzAgICAgIDJLICAgICAgIC0gICAxMTQ1MDUgIDE2LDMyLDY0LDEy OCwyNTYKICAgICBhdGtiZGRldiAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgNjQK ICAgICAgaXRocmVhZCAgICA3MiAgICAxMksgICAgICAgLSAgICAgICA3MiAgMzIsMTI4LDI1 NgogICAgICBlbnRyb3B5ICAxMDI0ICAgIDY0SyAgICAgICAtICAgICAxMDI0ICA2NAogICAg ICAgICBVQVJUICAgICAzICAgICAySyAgICAgICAtICAgICAgICAzICAxNiw1MTIsMTAyNAog ICAgICAgS1RSQUNFICAgMTAwICAgIDEzSyAgICAgICAtICAgICAgMTAwICAxMjgKICAgICAg IGxpbmtlciAgICA2MyAgICAgN0sgICAgICAgLSAgICAgICA3NSAgMTYsMzIsNjQsMTI4LDUx MgogICAgICAgIGxvY2tmICAgIDUzICAgICA2SyAgICAgICAtICAzNDQ1OTY5ICA2NCwxMjgK ICAgICAgICAgdGVtcCAgICAyMCAgIDQwMUsgICAgICAgLSAgIDM3OTc2NiAgMTYsMzIsNjQs MTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgIGRldmJ1ZiAxOTk5OSAzNDg3N0sg ICAgICAgLSAgICAyMDEwMiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYK ICAgICAgIFVTQmRldiAgICA0NyAgICAxMksgICAgICAgLSAgICAgICA0NyAgNjQsMTI4LDEw MjQKICAgICBuZXh1c2RldiAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgMTYKICAg cmFpZDVfZGF0YSAgICAxNyAgNDA3M0sgICAgICAgLSAxNTk4NjY2NDYgIDE2LDY0LDUxMiw0 MDk2Cjw8PCB2bXN0YXQgLW0KPj4+IG5ldHN0YXQgLW0KMzgwOC82MzAyLzEwMTEwIG1idWZz IGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbCkKMTYwMC82MzgwLzc5ODAvMjA0ODAwIG1i dWYgY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMTUwNC81ODE2 IG1idWYrY2x1c3RlcnMgb3V0IG9mIHBhY2tldCBzZWNvbmRhcnkgem9uZSBpbiB1c2UgKGN1 cnJlbnQvY2FjaGUpCjIvMjY2LzI2OC8xOTIwMDAgNGsgKHBhZ2Ugc2l6ZSkganVtYm8gY2x1 c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMC8wLzAvNjQwMCA5ayBq dW1ibyBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwvbWF4KQowLzAvMC8z MjAwIDE2ayBqdW1ibyBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwvbWF4 KQo0MTYwSy8xNTM5OUsvMTk1NTlLIGJ5dGVzIGFsbG9jYXRlZCB0byBuZXR3b3JrIChjdXJy ZW50L2NhY2hlL3RvdGFsKQowLzAvMCByZXF1ZXN0cyBmb3IgbWJ1ZnMgZGVuaWVkIChtYnVm cy9jbHVzdGVycy9tYnVmK2NsdXN0ZXJzKQowLzAvMCByZXF1ZXN0cyBmb3IganVtYm8gY2x1 c3RlcnMgZGVuaWVkICg0ay85ay8xNmspCjAvMC8wIHNmYnVmcyBpbiB1c2UgKGN1cnJlbnQv cGVhay9tYXgpCjAgcmVxdWVzdHMgZm9yIHNmYnVmcyBkZW5pZWQKMCByZXF1ZXN0cyBmb3Ig c2ZidWZzIGRlbGF5ZWQKMCByZXF1ZXN0cyBmb3IgSS9PIGluaXRpYXRlZCBieSBzZW5kZmls ZQowIGNhbGxzIHRvIHByb3RvY29sIGRyYWluIHJvdXRpbmVzCjw8PCBuZXRzdGF0IC1tCj4+ PiB0b3AgLVNuZCAxCmxhc3QgcGlkOiA0MDY4MTsgIGxvYWQgYXZlcmFnZXM6ICAwLjAyLCAg MC4wMiwgIDAuMDAgIHVwIDUrMTI6NTQ6NDAgICAgMTE6MzA6NDEKMTE0IHByb2Nlc3Nlczog MyBydW5uaW5nLCA5NCBzbGVlcGluZywgMTcgd2FpdGluZwoKTWVtOiA3Mk0gQWN0aXZlLCAx MzA4TSBJbmFjdCwgNDM0TSBXaXJlZCwgOTZNIENhY2hlLCAyMTNNIEJ1ZiwgNjZNIEZyZWUK U3dhcDogNDA5Nk0gVG90YWwsIDI3MksgVXNlZCwgNDA5Nk0gRnJlZQoKCiAgUElEIFVTRVJO QU1FICAgICAgVEhSIFBSSSBOSUNFICAgU0laRSAgICBSRVMgU1RBVEUgICBDICAgVElNRSAg IFdDUFUgQ09NTUFORAogICAxMSByb290ICAgICAgICAgICAgMiAxNzEga2kzMSAgICAgMEsg ICAgMzJLIENQVTAgICAgMCAxODYuNEggMjAwLjAwJSBpZGxlCiAgIDEyIHJvb3QgICAgICAg ICAgIDE3IC02MCAgICAtICAgICAwSyAgIDI3MksgV0FJVCAgICAwIDE0MDowMiAgMS4zNyUg aW50cgozMzk2NyBydG9ycmVudCAgICAgICAgMyAgNDQgICAgMCA3NzU2MEsgNjE0NDhLIHNl bGVjdCAgMCAyOTI6MTQgIDAuMDAlIHRyYW5zbWlzc2lvbi1kYWVtb24KICAgIDAgcm9vdCAg ICAgICAgICAgIDkgLTY4ICAgIDAgICAgIDBLICAgMTI4SyAtICAgICAgIDAgIDM3OjM1ICAw LjAwJSBrZXJuZWwKICAgMTkgcm9vdCAgICAgICAgICAgIDIgIC04ICAgIC0gICAgIDBLICAg IDMySyBncjVkbyAgIDEgIDE5OjAzICAwLjAwJSBnX3JhaWQ1CiAgIDE0IHJvb3QgICAgICAg ICAgIDMzIC00MCAgICAtICAgICAwSyAgIDUyOEsgLSAgICAgICAxICAxNjoxMiAgMC4wMCUg dXNiCiAgICA0IHJvb3QgICAgICAgICAgICAxICAtOCAgICAtICAgICAwSyAgICAxNksgLSAg ICAgICAxICAxNTo0MyAgMC4wMCUgZ19kb3duCiAgICAzIHJvb3QgICAgICAgICAgICAxICAt OCAgICAtICAgICAwSyAgICAxNksgLSAgICAgICAwICAxMjowNSAgMC4wMCUgZ191cAogICAx MyByb290ICAgICAgICAgICAgMSAtMTYgICAgLSAgICAgMEsgICAgMTZLIC0gICAgICAgMCAg IDc6MjQgIDAuMDAlIHlhcnJvdwogICAxNyByb290ICAgICAgICAgICAgMSAgMjAgICAgLSAg ICAgMEsgICAgMTZLIHN5bmNlciAgMSAgIDc6MDAgIDAuMDAlIHN5bmNlcgogICAgNiByb290 ICAgICAgICAgICAgMSAtMTYgICAgLSAgICAgMEsgICAgMTZLIHBzbGVlcCAgMSAgIDM6NTIg IDAuMDAlIHBhZ2VkYWVtb24KICA5MTAgdXVjcCAgICAgICAgICAgIDEgIDQ0ICAgIDAgIDY5 MTZLICAxMzI4SyBzZWxlY3QgIDEgICAwOjM4ICAwLjAwJSBtZWdhdGVjCiAgNzg1IHJvb3Qg ICAgICAgICAgICAxICA0NCAgICAwIDIxMDUySyAgMjc5Mksgc2VsZWN0ICAwICAgMDoxNyAg MC4wMCUgbm1iZAogIDkxMiB1dWNwICAgICAgICAgICAgMSAgNDQgICAgMCAxMDkyOEsgIDIx NjhLIHNlbGVjdCAgMSAgIDA6MTcgIDAuMDAlIHVwc2QKICAgIDIgcm9vdCAgICAgICAgICAg IDEgIC04ICAgIC0gICAgIDBLICAgIDE2SyAtICAgICAgIDAgICAwOjE1ICAwLjAwJSBnX2V2 ZW50CiAgODU3IHJvb3QgICAgICAgICAgICAxICA0NCAgICAwIDExNzg4SyAgMjAyNEsgc2Vs ZWN0ICAxICAgMDoxNCAgMC4wMCUgbnRwZAogICAxNiByb290ICAgICAgICAgICAgMSAgNDQg ICAgLSAgICAgMEsgICAgMTZLIHZscnV3dCAgMCAgIDA6MTMgIDAuMDAlIHZubHJ1CiAxMDI2 IHJvb3QgICAgICAgICAgICAxICA0NCAgICAwIDEyMDE2SyAgMzAyOEsgc2VsZWN0ICAxICAg MDowNiAgMC4wMCUgc2VuZG1haWwKCjw8PCB0b3AgLVNuZCAxCj4+PiBzeXNjdGwgZGV2LmVt LjAKZGV2LmVtLjAuJWRlc2M6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlv biA3LjIuMgpkZXYuZW0uMC4lZHJpdmVyOiBlbQpkZXYuZW0uMC4lbG9jYXRpb246IHNsb3Q9 MjUgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5HQkVDCmRldi5lbS4wLiVwbnBpbmZv OiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDEwYmQgc3VidmVuZG9yPTB4MTA0MyBzdWJkZXZp Y2U9MHg4MjY4IGNsYXNzPTB4MDIwMDAwCmRldi5lbS4wLiVwYXJlbnQ6IHBjaTAKZGV2LmVt LjAubnZtOiAtMQpkZXYuZW0uMC5kZWJ1ZzogLTEKZGV2LmVtLjAucnhfaW50X2RlbGF5OiAw CmRldi5lbS4wLnR4X2ludF9kZWxheTogNjYKZGV2LmVtLjAucnhfYWJzX2ludF9kZWxheTog NjYKZGV2LmVtLjAudHhfYWJzX2ludF9kZWxheTogNjYKZGV2LmVtLjAucnhfcHJvY2Vzc2lu Z19saW1pdDogMTAwCmRldi5lbS4wLmZsb3dfY29udHJvbDogMwpkZXYuZW0uMC5lZWVfY29u dHJvbDogMApkZXYuZW0uMC5saW5rX2lycTogMApkZXYuZW0uMC5tYnVmX2FsbG9jX2ZhaWw6 IDAKZGV2LmVtLjAuY2x1c3Rlcl9hbGxvY19mYWlsOiAwCmRldi5lbS4wLmRyb3BwZWQ6IDAK ZGV2LmVtLjAudHhfZG1hX2ZhaWw6IDAKZGV2LmVtLjAucnhfb3ZlcnJ1bnM6IDAKZGV2LmVt LjAud2F0Y2hkb2dfdGltZW91dHM6IDAKZGV2LmVtLjAuZGV2aWNlX2NvbnRyb2w6IDE0Nzc0 NDQxNjAKZGV2LmVtLjAucnhfY29udHJvbDogNjcxNDE2MzQKZGV2LmVtLjAuZmNfaGlnaF93 YXRlcjogODE5MgpkZXYuZW0uMC5mY19sb3dfd2F0ZXI6IDY2OTIKZGV2LmVtLjAucXVldWUw LnR4ZF9oZWFkOiAyMjcKZGV2LmVtLjAucXVldWUwLnR4ZF90YWlsOiAxOTAKZGV2LmVtLjAu cXVldWUwLnR4X2lycTogMApkZXYuZW0uMC5xdWV1ZTAubm9fZGVzY19hdmFpbDogMApkZXYu ZW0uMC5xdWV1ZTAucnhkX2hlYWQ6IDI4OApkZXYuZW0uMC5xdWV1ZTAucnhkX3RhaWw6IDI4 NwpkZXYuZW0uMC5xdWV1ZTAucnhfaXJxOiAwCmRldi5lbS4wLm1hY19zdGF0cy5leGNlc3Nf Y29sbDogMApkZXYuZW0uMC5tYWNfc3RhdHMuc2luZ2xlX2NvbGw6IDAKZGV2LmVtLjAubWFj X3N0YXRzLm11bHRpcGxlX2NvbGw6IDAKZGV2LmVtLjAubWFjX3N0YXRzLmxhdGVfY29sbDog MApkZXYuZW0uMC5tYWNfc3RhdHMuY29sbGlzaW9uX2NvdW50OiAwCmRldi5lbS4wLm1hY19z dGF0cy5zeW1ib2xfZXJyb3JzOiAwCmRldi5lbS4wLm1hY19zdGF0cy5zZXF1ZW5jZV9lcnJv cnM6IDAKZGV2LmVtLjAubWFjX3N0YXRzLmRlZmVyX2NvdW50OiAxMzExCmRldi5lbS4wLm1h Y19zdGF0cy5taXNzZWRfcGFja2V0czogMjM5NQpkZXYuZW0uMC5tYWNfc3RhdHMucmVjdl9u b19idWZmOiAwCmRldi5lbS4wLm1hY19zdGF0cy5yZWN2X3VuZGVyc2l6ZTogMApkZXYuZW0u MC5tYWNfc3RhdHMucmVjdl9mcmFnbWVudGVkOiA0CmRldi5lbS4wLm1hY19zdGF0cy5yZWN2 X292ZXJzaXplOiAwCmRldi5lbS4wLm1hY19zdGF0cy5yZWN2X2phYmJlcjogMApkZXYuZW0u MC5tYWNfc3RhdHMucmVjdl9lcnJzOiAxNDcKZGV2LmVtLjAubWFjX3N0YXRzLmNyY19lcnJz OiAxNTYKZGV2LmVtLjAubWFjX3N0YXRzLmFsaWdubWVudF9lcnJzOiAwCmRldi5lbS4wLm1h Y19zdGF0cy5jb2xsX2V4dF9lcnJzOiAxCmRldi5lbS4wLm1hY19zdGF0cy54b25fcmVjdmQ6 IDEzNDQKZGV2LmVtLjAubWFjX3N0YXRzLnhvbl90eGQ6IDAKZGV2LmVtLjAubWFjX3N0YXRz LnhvZmZfcmVjdmQ6IDMxNTAKZGV2LmVtLjAubWFjX3N0YXRzLnhvZmZfdHhkOiAwCmRldi5l bS4wLm1hY19zdGF0cy50b3RhbF9wa3RzX3JlY3ZkOiAzNTQ4NDE0ODMKZGV2LmVtLjAubWFj X3N0YXRzLmdvb2RfcGt0c19yZWN2ZDogMzU0ODM0NDI5CmRldi5lbS4wLm1hY19zdGF0cy5i Y2FzdF9wa3RzX3JlY3ZkOiAxMjA3NwpkZXYuZW0uMC5tYWNfc3RhdHMubWNhc3RfcGt0c19y ZWN2ZDogMApkZXYuZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVzXzY0OiAwCmRldi5lbS4wLm1h Y19zdGF0cy5yeF9mcmFtZXNfNjVfMTI3OiAwCmRldi5lbS4wLm1hY19zdGF0cy5yeF9mcmFt ZXNfMTI4XzI1NTogMApkZXYuZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVzXzI1Nl81MTE6IDAK ZGV2LmVtLjAubWFjX3N0YXRzLnJ4X2ZyYW1lc181MTJfMTAyMzogMApkZXYuZW0uMC5tYWNf c3RhdHMucnhfZnJhbWVzXzEwMjRfMTUyMjogMApkZXYuZW0uMC5tYWNfc3RhdHMuZ29vZF9v Y3RldHNfcmVjdmQ6IDMzMDYwNDMxMzA1CmRldi5lbS4wLm1hY19zdGF0cy5nb29kX29jdGV0 c190eGQ6IDg4ODE5NTg4MTgxNQpkZXYuZW0uMC5tYWNfc3RhdHMudG90YWxfcGt0c190eGQ6 IDY3OTkzMjk4OQpkZXYuZW0uMC5tYWNfc3RhdHMuZ29vZF9wa3RzX3R4ZDogNjc5OTMyOTg5 CmRldi5lbS4wLm1hY19zdGF0cy5iY2FzdF9wa3RzX3R4ZDogMjQzMgpkZXYuZW0uMC5tYWNf c3RhdHMubWNhc3RfcGt0c190eGQ6IDE0OTM5CmRldi5lbS4wLm1hY19zdGF0cy50eF9mcmFt ZXNfNjQ6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnR4X2ZyYW1lc182NV8xMjc6IDAKZGV2LmVt LjAubWFjX3N0YXRzLnR4X2ZyYW1lc18xMjhfMjU1OiAwCmRldi5lbS4wLm1hY19zdGF0cy50 eF9mcmFtZXNfMjU2XzUxMTogMApkZXYuZW0uMC5tYWNfc3RhdHMudHhfZnJhbWVzXzUxMl8x MDIzOiAwCmRldi5lbS4wLm1hY19zdGF0cy50eF9mcmFtZXNfMTAyNF8xNTIyOiAwCmRldi5l bS4wLm1hY19zdGF0cy50c29fdHhkOiAyMDgxNzY2OTEKZGV2LmVtLjAubWFjX3N0YXRzLnRz b19jdHhfZmFpbDogMApkZXYuZW0uMC5pbnRlcnJ1cHRzLmFzc2VydHM6IDQ5NTU4NzAzNwpk ZXYuZW0uMC5pbnRlcnJ1cHRzLnJ4X3BrdF90aW1lcjogMApkZXYuZW0uMC5pbnRlcnJ1cHRz LnJ4X2Fic190aW1lcjogMApkZXYuZW0uMC5pbnRlcnJ1cHRzLnR4X3BrdF90aW1lcjogMApk ZXYuZW0uMC5pbnRlcnJ1cHRzLnR4X2Fic190aW1lcjogMApkZXYuZW0uMC5pbnRlcnJ1cHRz LnR4X3F1ZXVlX2VtcHR5OiAwCmRldi5lbS4wLmludGVycnVwdHMudHhfcXVldWVfbWluX3Ro cmVzaDogMApkZXYuZW0uMC5pbnRlcnJ1cHRzLnJ4X2Rlc2NfbWluX3RocmVzaDogMApkZXYu ZW0uMC5pbnRlcnJ1cHRzLnJ4X292ZXJydW46IDAKZGV2LmVtLjAud2FrZTogMAo8PDwgc3lz Y3RsIGRldi5lbS4wCg== ------------51A718D33013DCD Content-Type: application/octet-stream; name="em0.7.2.2.hang2.log" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="em0.7.2.2.hang2.log" Pj4+IGlmY29uZmlnIGVtMAplbTA6IGZsYWdzPThjNDM8VVAsQlJPQURDQVNULFJVTk5JTkcs T0FDVElWRSxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKCW9wdGlvbnM9 MjE5YjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdDU1VN LFRTTzQsV09MX01BR0lDPgoJZXRoZXIgMDA6MWU6OGM6NzU6MDM6MGQKCWluZXQgMTkyLjE2 OC4xMzQuMyBuZXRtYXNrIDB4ZmZmZmZmMDAgYnJvYWRjYXN0IDE5Mi4xNjguMTM0LjI1NQoJ bWVkaWE6IEV0aGVybmV0IDEwMDBiYXNlVCA8ZnVsbC1kdXBsZXg+CglzdGF0dXM6IGFjdGl2 ZQo8PDwgaWZjb25maWcgZW0wCj4+PiB2bXN0YXQgLW0KICAgICAgICAgVHlwZSBJblVzZSBN ZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0cyAgU2l6ZShzKQogICAgICAgbW9kdWxlICAgMTUyICAg IDE5SyAgICAgICAtICAgICAgMTUyICAxMjgKICAgICAgICAgIFVTQiAgICA3NiAgICA2Nksg ICAgICAgLSAgICAgICA4MCAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0LDIwNDgsNDA5NgogICAg IG10eF9wb29sICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICAKICAgICBhY3BpdGFz ayAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMSAgMjA0OAogICBDQU0gcGVyaXBoICAg IDIyICAgICA2SyAgICAgICAtICAgICAgIDQ0ICAxNiwzMiw2NCwyNTYKICAgICAgc3VicHJv YyAgIDQ1OCAgIDM5N0sgICAgICAgLSAgICA1NDc3NyAgNTEyLDQwOTYKICAgICAgICAgcHJv YyAgICAgMiAgICAxNksgICAgICAgLSAgICAgICAgMiAgCiAgICAgIHNlc3Npb24gICAgMjMg ICAgIDNLICAgICAgIC0gICAgIDM2NDAgIDEyOAogICAgICAgICBwZ3JwICAgIDI1ICAgICA0 SyAgICAgICAtICAgICAzNzQ2ICAxMjgKICAgICAgICAgY3JlZCAgICA2MiAgICAxMEsgICAg ICAgLSAgMjU4ODA1OCAgNjQsMjU2CiAgICAgIHVpZGluZm8gICAgIDggICAgIDNLICAgICAg IC0gICA0MjMxNzUgIDEyOCwyMDQ4CiAgICAgICBwbGltaXQgICAgMTIgICAgIDNLICAgICAg IC0gICAgNDY3MjMgIDI1NgogICAgIHBjaV9saW5rICAgIDE2ICAgICAySyAgICAgICAtICAg ICAgIDE2ICA2NCwxMjgKICAgICAgYWNwaXNlbSAgICAxOSAgICAgM0sgICAgICAgLSAgICAg ICAxOSAgMTI4CiAgICAgICBERVZGUzEgICAxNDIgICAgNzFLICAgICAgIC0gICAgICAxNTIg IDUxMgogICAgc3lzY3RsdG1wICAgICAwICAgICAwSyAgICAgICAtICAgICAxMTQ4ICAxNiwz Miw2NCwxMjgKICAgIHN5c2N0bG9pZCAgMzI1MiAgIDE2MUsgICAgICAgLSAgICAgMzM4NiAg MTYsMzIsNjQsMTI4CiAgICAgICBzeXNjdGwgICAgIDAgICAgIDBLICAgICAgIC0gICAgMjA5 MjcgIDE2LDMyLDY0CiAgICAgIGNhbGxvdXQgICAgIDEgICA1MTJLICAgICAgIC0gICAgICAg IDEgIAogICAgICAgICB1bXR4ICAgNDg5ICAgIDYySyAgICAgICAtICAgICAgNDg5ICAxMjgK ICAgICBwMTAwMy4xYiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTYKICAgICAg ICAgU1dBUCAgICAgMiAgIDU0OUsgICAgICAgLSAgICAgICAgMiAgNjQKICAgICAgIERFVkZT MyAgIDE2OCAgICA0MksgICAgICAgLSAgICAgIDE3OSAgMjU2CiAgICAgICBidXMtc2MgICAg NjMgICAzNzNLICAgICAgIC0gICAgIDEyNzEgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDIwNDgs NDA5NgogICAgICAgICAgYnVzICAgNjA5ICAgIDYySyAgICAgICAtICAgICAzNTk5ICAxNiwz Miw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgIGRldnN0YXQgICAgMTQgICAgMjlLICAgICAg IC0gICAgICAgMTQgIDMyLDQwOTYKIGV2ZW50aGFuZGxlciAgICA2NyAgICAgNksgICAgICAg LSAgICAgICA2NyAgNjQsMTI4CiAgICAgICAgIGtvYmogICAgOTMgICAzNzJLICAgICAgIC0g ICAgICAxMjEgIDQwOTYKICAgICAgUGVyLWNwdSAgICAgMSAgICAgMUsgICAgICAgLSAgICAg ICAgMSAgMzIKICAgICAgICBERVZGUyAgICAyMCAgICAgMUsgICAgICAgLSAgICAgICAyMSAg MTYsMTI4CiAgICAgICAgIHJtYW4gICAxNzcgICAgMjJLICAgICAgIC0gICAgICA2MDEgIDE2 LDMyLDEyOAogICAgICAgREVWRlNQICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAyICA2 NAogICAgICAgICBzYnVmICAgICAwICAgICAwSyAgICAgICAtICAgICAxMzQwICAxNiwzMiw2 NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgcGZzX25vZGVzICAgIDIxICAgICA2 SyAgICAgICAtICAgICAgIDIxICAyNTYKICAgICAgQ0FNIFhQVCAgIDI5MiAgIDQyM0sgICAg ICAgLSAgICAgIDQxMyAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0LDIwNDgKICAgICAgICBzdGFj ayAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMiAgMjU2CiAgICB0YXNrcXVldWUgICAg MTUgICAgIDJLICAgICAgIC0gICAgICAgMTUgIDE2LDMyLDEyOAogICAgICAgVW5pdG5vICAg IDEwICAgICAxSyAgICAgICAtICAgICAgIDU4ICAzMiw2NAogICAgICAgICAgaW92ICAgICAw ICAgICAwSyAgICAgICAtICAgMzI5NjM0ICAxNiwzMiw2NCwxMjgsMjU2LDUxMgogICAgICAg c2VsZWN0ICAgMTY4ICAgIDIxSyAgICAgICAtIDEwMTUwNjE1NzMwICAxMjgsNTEyLDEwMjQK ICAgICBpb2N0bG9wcyAgICAgMCAgICAgMEsgICAgICAgLSAyMTQ5Mjk2ODEgIDE2LDMyLDY0 LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgICAgICBtc2cgICAgIDQgICAgMzBL ICAgICAgIC0gICAgICAgIDQgIDIwNDgsNDA5NgogICAgICAgICAgc2VtICAgICA0ICAgIDEx SyAgICAgICAtICAgICAgICA0ICA1MTIsMTAyNAogICAgICAgICAgc2htICAgICAxICAgIDIw SyAgICAgICAtICAgICAgICAxICAKICAgICAgICAgIHR0eSAgICAyMCAgICAyMEsgICAgICAg LSAgICAgICAyNiAgMTAyNCwyMDQ4CiAgICAgICAgICBwdHMgICAgIDAgICAgIDBLICAgICAg IC0gICAgICAgIDQgIDI1NgogICAgIG1idWZfdGFnICAgICAwICAgICAwSyAgICAgICAtICAg ICAgIDU3ICAzMgogICAgICAgIHNobWZkICAgICAxICAgICA4SyAgICAgICAtICAgICAgICAx ICAKICAgICAgICAgR0VPTSAgIDE3NSAgICAzOEsgICAgICAgLSAgICAgIDg3MSAgMTYsMzIs NjQsMTI4LDI1Niw1MTIsMTAyNAogICAgICAgICAgcGNiICAgIDU1ICAgIDE0SyAgICAgICAt ICA2MDg5ODY3ICAxNiwzMiwxMDI0LDIwNDgsNDA5NgogICAgICAgc29uYW1lICAgICA2ICAg ICAxSyAgICAgICAtIDIzMzUzNjU1ICAxNiwzMiwxMjgKICAgICAgICAgIGFjbCAgICAgMCAg ICAgMEsgICAgICAgLSAgICAgMTU4OCAgNDA5NgogICAgICAgYmlvYnVmICAgICAwICAgICAw SyAgICAgICAtICAgICAgMjAzICAyMDQ4CiAgICAgdmZzY2FjaGUgICAgIDEgIDEwMjRLICAg ICAgIC0gICAgICAgIDEgIAogICBjbF9zYXZlYnVmICAgICAwICAgICAwSyAgICAgICAtICAg IDU2NjIyICA2NCwxMjgKICBleHBvcnRfaG9zdCAgICAgMiAgICAgMUsgICAgICAgLSAgICAg ICAgMiAgMjU2CiAgICAgdmZzX2hhc2ggICAgIDEgICA1MTJLICAgICAgIC0gICAgICAgIDEg IAogICAgICAgdm5vZGVzICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAyNTYKICB2 bm9kZW1hcmtlciAgICAgMCAgICAgMEsgICAgICAgLSAgIDIyNzUzNCAgNTEyCiAgICAgICAg bW91bnQgICAxMDQgICAgIDZLICAgICAgIC0gICAgICAzMDQgIDE2LDMyLDY0LDEyOCwyNTYs NTEyCiAgICAgICAgICBCUEYgICAgIDcgICAgIDlLICAgICAgIC0gICAgICAgMTIgIDEyOCw1 MTIsNDA5NgogIGV0aGVyX211bHRpICAgIDEyICAgICAxSyAgICAgICAtICAgICAgIDI2ICAx Niw2NAogICAgICAgaWZhZGRyICAgIDE0ICAgICA3SyAgICAgICAtICAgICAgIDE2ICAzMiw1 MTIsNDA5NgogICAgICAgIGlmbmV0ICAgICAzICAgICA1SyAgICAgICAtICAgICAgICAzICAx MjgsMjA0OAogICAgICAgIGNsb25lICAgICAyICAgICA4SyAgICAgICAtICAgICAgICAyICA0 MDk2CiAgICAgICBhcnBjb20gICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDE2CiAg ICAgIGxsdGFibGUgICAgIDMgICAgIDJLICAgICAgIC0gICAgICAgMzcgIDI1Niw1MTIKICAg ICAgIGtiZG11eCAgICAgNiAgICAxMEsgICAgICAgLSAgICAgICAgNiAgMTYsNTEyLDEwMjQs MjA0OCw0MDk2CiAgICAgICAgICBMRUQgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEg IDEyOAogICAgICAgaXNhZGV2ICAgICA2ICAgICAxSyAgICAgICAtICAgICAgICA2ICAxMjgK ICAgICByb3V0ZXRibCAgICAxNCAgICAgNEsgICAgICAgLSAgIDE1NzYzMyAgMzIsNjQsMTI4 LDI1Niw1MTIKICAgICAgICAgaWdtcCAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAg MjU2CiAgICAgIHNjc2lfZGEgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgMTYgIDE2CkNB TSBkZXYgcXVldWUgICAgIDggICAgIDFLICAgICAgIC0gICAgICAgIDggIDEyOAogIGlwX21v cHRpb25zICAgICA0ICAgICAxSyAgICAgICAtICAgICAgICA4ICA2NCwyNTYKICAgICBpbl9t dWx0aSAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgNSAgMjU2CiAgIGluX21maWx0ZXIg ICAgIDIgICAgIDJLICAgICAgIC0gICAgICAgIDQgIDEwMjQKICAgIGhvc3RjYWNoZSAgICAg MSAgICAyOEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgc3luY2FjaGUgICAgIDEgICAgOTZL ICAgICAgIC0gICAgICAgIDEgIAogICAgICBORlMgRkhBICAgICAxICAgICAySyAgICAgICAt ICAgICAgNDk4ICA2NCwyMDQ4CiAgICAgICAgICBycGMgICA1MDcgICAyNThLICAgICAgIC0g ICAgIDE2MzIgIDMyLDY0LDEyOCwyNTYsNTEyLDIwNDgKYXVkaXRfZXZjbGFzcyAgIDE3MiAg ICAgNksgICAgICAgLSAgICAgIDIxMSAgMzIKICAgICBzYXZlZGlubyAgICAgMCAgICAgMEsg ICAgICAgLSAgICAzNTA1NSAgMjU2CiAgICBuZXdkaXJibGsgICAgIDAgICAgIDBLICAgICAg IC0gICAgICAgIDUgIDY0CiAgICAgICBkaXJyZW0gICAgIDAgICAgIDBLICAgICAgIC0gICAx ODc3MjIgIDY0CiAgICAgICAgbWtkaXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgICA0ODIg IDY0CiAgICAgICBkaXJhZGQgICAgIDMgICAgIDFLICAgICAgIC0gICAxODk1NzYgIDY0CiAg ICAgZnJlZWZpbGUgICAgIDAgICAgIDBLICAgICAgIC0gICAgOTAwMjIgIDY0CiAgICAgZnJl ZWJsa3MgICAgIDAgICAgIDBLICAgICAgIC0gICAgOTAxMTggIDI1NgogICAgIGZyZWVmcmFn ICAgICAwICAgICAwSyAgICAgICAtICAgMTY1MjUzICA2NAogICBhbGxvY2luZGlyICAgICAw ICAgICAwSyAgICAgICAtICAgMzE5OTc5ICAxMjgKICAgICBpbmRpcmRlcCAgICAgMCAgICAg MEsgICAgICAgLSAgICAgMzkxNSAgNjQKICBhbGxvY2RpcmVjdCAgICAgMyAgICAgMUsgICAg ICAgLSAgIDM5Nzk3OSAgMjU2CiAgICBibXNhZmVtYXAgICAgIDEgICAgIDFLICAgICAgIC0g ICAxMDkxNjQgIDEyOAogICAgICAgbmV3YmxrICAgICAxICAgICAxSyAgICAgICAtICAgNzE3 OTU5ICA2NCw1MTIKICAgICBpbm9kZWRlcCAgICAgNSAgIDUxM0sgICAgICAgLSAgIDIxMTMw NSAgMjU2CiAgICAgIHBhZ2VkZXAgICAgIDQgICAxMjlLICAgICAgIC0gICAgMzExMDcgIDEy OAogIHVmc19kaXJoYXNoICAgOTIxICAgNDUySyAgICAgICAtICAgNDQ3OTk5ICAxNiwzMiw2 NCwxMjgsMjU2LDUxMiwxMDI0CiAgICB1ZnNfbW91bnQgICAgMTUgICAxMjdLICAgICAgIC0g ICAgICAgMTUgIDUxMiwyMDQ4LDQwOTYKICAgICAgVU1BSGFzaCAgICAgMyAgICAgN0sgICAg ICAgLSAgICAgICAgOSAgNTEyLDEwMjQsMjA0OCw0MDk2CiAgICBDQU0gcXVldWUgICAgNDMg ICAgIDNLICAgICAgIC0gICAgICAxNDggIDE2LDMyLDY0LDI1NgogICAgICBDQU0gU0lNICAg ICA4ICAgICAySyAgICAgICAtICAgICAgICA4ICAyNTYKICAgICAgICAgY2RldiAgICAgOCAg ICAgMksgICAgICAgLSAgICAgICAgOCAgMjU2CiAgICB2bV9wZ2RhdGEgICAgIDIgICAxMjlL ICAgICAgIC0gICAgICAgIDIgIDEyOAogIGRkYl9jYXB0dXJlICAgICAxICAgIDQ4SyAgICAg ICAtICAgICAgICAxICAKICAgICAgIGFjcGljYSAgMzc3MCAgIDM4NksgICAgICAgLSAgICA5 MDMzNiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4CiAgICAgICAgc2lnaW8gICAg IDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0CiAgICAgZmlsZWRlc2MgICAgNjAgICAg NzdLICAgICAgIC0gICAgODUxMzIgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0 MDk2CiAgICAgICAgIGtlbnYgICAgNzYgICAgMTFLICAgICAgIC0gICAgICAgODAgIDE2LDMy LDY0LDEyOAogICAgICBpb19hcGljICAgICAxICAgICAySyAgICAgICAtICAgICAgICAxICAy MDQ4CiAgICAgICBrcXVldWUgICAgIDIgICAgMTNLICAgICAgIC0gICAyNDc1NTYgIDI1Niwy MDQ4LDQwOTYKICAgICAgbWVtZGVzYyAgICAgMSAgICAgNEsgICAgICAgLSAgICAgICAgMSAg NDA5NgogICAgICBhY3BpZGV2ICAgIDc4ICAgICA1SyAgICAgICAtICAgICAgIDc4ICA2NAog ICAgcHJvYy1hcmdzICAgIDI3ICAgICAySyAgICAgICAtICAgMTU0ODE4ICAxNiwzMiw2NCwx MjgsMjU2CiAgICAgYXRrYmRkZXYgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDY0 CiAgICAgIGl0aHJlYWQgICAgNzIgICAgMTJLICAgICAgIC0gICAgICAgNzIgIDMyLDEyOCwy NTYKICAgICAgZW50cm9weSAgMTAyNCAgICA2NEsgICAgICAgLSAgICAgMTAyNCAgNjQKICAg ICAgICAgVUFSVCAgICAgMyAgICAgMksgICAgICAgLSAgICAgICAgMyAgMTYsNTEyLDEwMjQK ICAgICAgIEtUUkFDRSAgIDEwMCAgICAxM0sgICAgICAgLSAgICAgIDEwMCAgMTI4CiAgICAg ICBsaW5rZXIgICAgNjMgICAgIDdLICAgICAgIC0gICAgICAgNzUgIDE2LDMyLDY0LDEyOCw1 MTIKICAgICAgICBsb2NrZiAgICA1MyAgICAgNksgICAgICAgLSAgNDY1MDA0NyAgNjQsMTI4 CiAgICAgICAgIHRlbXAgICAgMjAgICA0MDFLICAgICAgIC0gICA0OTE1NDMgIDE2LDMyLDY0 LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgICBkZXZidWYgMTk5OTkgMzQ4NzdL ICAgICAgIC0gICAgMjAxMDIgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2 CiAgICAgICBVU0JkZXYgICAgNDcgICAgMTJLICAgICAgIC0gICAgICAgNDcgIDY0LDEyOCwx MDI0CiAgICAgbmV4dXNkZXYgICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDE2CiAg IHJhaWQ1X2RhdGEgICAgIDYgIDUzODlLICAgICAgIC0gMTk4ODIxOTY2ICAxNiw2NCw1MTIs NDA5Ngo8PDwgdm1zdGF0IC1tCj4+PiBuZXRzdGF0IC1tCjM3MDMvMzcyMi83NDI1IG1idWZz IGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbCkKMTI3NS80MDQ3LzUzMjIvMjA0ODAwIG1i dWYgY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMTE1MS8zMDMy IG1idWYrY2x1c3RlcnMgb3V0IG9mIHBhY2tldCBzZWNvbmRhcnkgem9uZSBpbiB1c2UgKGN1 cnJlbnQvY2FjaGUpCjExLzYzOS82NTAvMTkyMDAwIDRrIChwYWdlIHNpemUpIGp1bWJvIGNs dXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgpCjAvMC8wLzY0MDAgOWsg anVtYm8gY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMC8wLzAv MzIwMCAxNmsganVtYm8gY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21h eCkKMzUxOUsvMTE1ODBLLzE1MTAwSyBieXRlcyBhbGxvY2F0ZWQgdG8gbmV0d29yayAoY3Vy cmVudC9jYWNoZS90b3RhbCkKMC8wLzAgcmVxdWVzdHMgZm9yIG1idWZzIGRlbmllZCAobWJ1 ZnMvY2x1c3RlcnMvbWJ1ZitjbHVzdGVycykKMC8wLzAgcmVxdWVzdHMgZm9yIGp1bWJvIGNs dXN0ZXJzIGRlbmllZCAoNGsvOWsvMTZrKQowLzAvMCBzZmJ1ZnMgaW4gdXNlIChjdXJyZW50 L3BlYWsvbWF4KQowIHJlcXVlc3RzIGZvciBzZmJ1ZnMgZGVuaWVkCjAgcmVxdWVzdHMgZm9y IHNmYnVmcyBkZWxheWVkCjAgcmVxdWVzdHMgZm9yIEkvTyBpbml0aWF0ZWQgYnkgc2VuZGZp bGUKMCBjYWxscyB0byBwcm90b2NvbCBkcmFpbiByb3V0aW5lcwo8PDwgbmV0c3RhdCAtbQo+ Pj4gdG9wIC1TbmQgMQpsYXN0IHBpZDogNTQzNjc7ICBsb2FkIGF2ZXJhZ2VzOiAgMC4wMywg IDAuMDEsICAwLjAwICB1cCA3KzEyOjMxOjQzICAgIDExOjA3OjQ0CjExMSBwcm9jZXNzZXM6 IDMgcnVubmluZywgOTEgc2xlZXBpbmcsIDE3IHdhaXRpbmcKCk1lbTogODBNIEFjdGl2ZSwg MTMzOE0gSW5hY3QsIDQzMU0gV2lyZWQsIDUzTSBDYWNoZSwgMjEzTSBCdWYsIDczTSBGcmVl ClN3YXA6IDQwOTZNIFRvdGFsLCAyNDhLIFVzZWQsIDQwOTZNIEZyZWUKCgogIFBJRCBVU0VS TkFNRSAgICAgIFRIUiBQUkkgTklDRSAgIFNJWkUgICAgUkVTIFNUQVRFICAgQyAgIFRJTUUg ICBXQ1BVIENPTU1BTkQKICAgMTEgcm9vdCAgICAgICAgICAgIDIgMTcxIGtpMzEgICAgIDBL ICAgIDMySyBDUFUwICAgIDAgMjczLjlIIDIwMC4wMCUgaWRsZQogICAxMiByb290ICAgICAg ICAgICAxNyAtNjAgICAgLSAgICAgMEsgICAyNzJLIFdBSVQgICAgMCAxODM6MjcgIDEuNDYl IGludHIKMzM5NjcgcnRvcnJlbnQgICAgICAgIDMgIDQ0ICAgIDAgODM3MDRLIDY4MTU2SyBz ZWxlY3QgIDAgNjc1OjA3ICAwLjAwJSB0cmFuc21pc3Npb24tZGFlbW9uCiAgICAwIHJvb3Qg ICAgICAgICAgICA5IC02OCAgICAwICAgICAwSyAgIDEyOEsgLSAgICAgICAwICA0ODo1OCAg MC4wMCUga2VybmVsCiAgIDE5IHJvb3QgICAgICAgICAgICAyICAtOCAgICAtICAgICAwSyAg ICAzMksgZ3I1ZG8gICAxICAyNDowNCAgMC4wMCUgZ19yYWlkNQogICAxNCByb290ICAgICAg ICAgICAzMyAtNDAgICAgLSAgICAgMEsgICA1MjhLIC0gICAgICAgMCAgMjI6MzggIDAuMDAl IHVzYgogICAgNCByb290ICAgICAgICAgICAgMSAgLTggICAgLSAgICAgMEsgICAgMTZLIC0g ICAgICAgMSAgMTk6NDYgIDAuMDAlIGdfZG93bgogICAgMyByb290ICAgICAgICAgICAgMSAg LTggICAgLSAgICAgMEsgICAgMTZLIC0gICAgICAgMCAgMTU6MjUgIDAuMDAlIGdfdXAKICAg MTMgcm9vdCAgICAgICAgICAgIDEgLTE2ICAgIC0gICAgIDBLICAgIDE2SyAtICAgICAgIDAg ICA5OjM3ICAwLjAwJSB5YXJyb3cKICAgMTcgcm9vdCAgICAgICAgICAgIDEgIDIwICAgIC0g ICAgIDBLICAgIDE2SyBzeW5jZXIgIDAgICA5OjM2ICAwLjAwJSBzeW5jZXIKICAgIDYgcm9v dCAgICAgICAgICAgIDEgLTE2ICAgIC0gICAgIDBLICAgIDE2SyBwc2xlZXAgIDAgICA0OjQ3 ICAwLjAwJSBwYWdlZGFlbW9uCiAgNzg1IHJvb3QgICAgICAgICAgICAxICA0NCAgICAwIDIx MDUySyAgMjc2NEsgc2VsZWN0ICAwICAgMDoyNCAgMC4wMCUgbm1iZAogICAgMiByb290ICAg ICAgICAgICAgMSAgLTggICAgLSAgICAgMEsgICAgMTZLIC0gICAgICAgMCAgIDA6MjAgIDAu MDAlIGdfZXZlbnQKICA4NTcgcm9vdCAgICAgICAgICAgIDEgIDQ0ICAgIDAgMTE3ODhLICAx OTkySyBzZWxlY3QgIDEgICAwOjE5ICAwLjAwJSBudHBkCiAgIDE2IHJvb3QgICAgICAgICAg ICAxICA0NCAgICAtICAgICAwSyAgICAxNksgdmxydXd0ICAxICAgMDoxNyAgMC4wMCUgdm5s cnUKNDQwMDkgdXVjcCAgICAgICAgICAgIDEgIDQ0ICAgIDAgIDY5MTZLICAxMzU2SyBzZWxl Y3QgIDEgICAwOjExICAwLjAwJSBtZWdhdGVjCiAxMDI2IHJvb3QgICAgICAgICAgICAxICA0 NCAgICAwIDEyMDE2SyAgMzAyOEsgc2VsZWN0ICAwICAgMDowOCAgMC4wMCUgc2VuZG1haWwK ICAgMTggcm9vdCAgICAgICAgICAgIDEgIDQ0ICAgIC0gICAgIDBLICAgIDE2SyBzZGZsdXMg IDAgICAwOjA4ICAwLjAwJSBzb2Z0ZGVwZmx1c2gKCjw8PCB0b3AgLVNuZCAxCj4+PiBzeXNj dGwgZGV2LmVtLjAKZGV2LmVtLjAuJWRlc2M6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsg Q29ubmVjdGlvbiA3LjIuMgpkZXYuZW0uMC4lZHJpdmVyOiBlbQpkZXYuZW0uMC4lbG9jYXRp b246IHNsb3Q9MjUgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5HQkVDCmRldi5lbS4w LiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDEwYmQgc3VidmVuZG9yPTB4MTA0 MyBzdWJkZXZpY2U9MHg4MjY4IGNsYXNzPTB4MDIwMDAwCmRldi5lbS4wLiVwYXJlbnQ6IHBj aTAKZGV2LmVtLjAubnZtOiAtMQpkZXYuZW0uMC5kZWJ1ZzogLTEKZGV2LmVtLjAucnhfaW50 X2RlbGF5OiAwCmRldi5lbS4wLnR4X2ludF9kZWxheTogNjYKZGV2LmVtLjAucnhfYWJzX2lu dF9kZWxheTogNjYKZGV2LmVtLjAudHhfYWJzX2ludF9kZWxheTogNjYKZGV2LmVtLjAucnhf cHJvY2Vzc2luZ19saW1pdDogMTAwCmRldi5lbS4wLmZsb3dfY29udHJvbDogMwpkZXYuZW0u MC5lZWVfY29udHJvbDogMApkZXYuZW0uMC5saW5rX2lycTogMApkZXYuZW0uMC5tYnVmX2Fs bG9jX2ZhaWw6IDAKZGV2LmVtLjAuY2x1c3Rlcl9hbGxvY19mYWlsOiAwCmRldi5lbS4wLmRy b3BwZWQ6IDAKZGV2LmVtLjAudHhfZG1hX2ZhaWw6IDAKZGV2LmVtLjAucnhfb3ZlcnJ1bnM6 IDAKZGV2LmVtLjAud2F0Y2hkb2dfdGltZW91dHM6IDAKZGV2LmVtLjAuZGV2aWNlX2NvbnRy b2w6IDEwNzQ3OTA5NzYKZGV2LmVtLjAucnhfY29udHJvbDogNjcxNDE2MzQKZGV2LmVtLjAu ZmNfaGlnaF93YXRlcjogODE5MgpkZXYuZW0uMC5mY19sb3dfd2F0ZXI6IDY2OTIKZGV2LmVt LjAucXVldWUwLnR4ZF9oZWFkOiA1ODkKZGV2LmVtLjAucXVldWUwLnR4ZF90YWlsOiA1NTQK ZGV2LmVtLjAucXVldWUwLnR4X2lycTogMApkZXYuZW0uMC5xdWV1ZTAubm9fZGVzY19hdmFp bDogMApkZXYuZW0uMC5xdWV1ZTAucnhkX2hlYWQ6IDc3NgpkZXYuZW0uMC5xdWV1ZTAucnhk X3RhaWw6IDc3NQpkZXYuZW0uMC5xdWV1ZTAucnhfaXJxOiAwCmRldi5lbS4wLm1hY19zdGF0 cy5leGNlc3NfY29sbDogMApkZXYuZW0uMC5tYWNfc3RhdHMuc2luZ2xlX2NvbGw6IDAKZGV2 LmVtLjAubWFjX3N0YXRzLm11bHRpcGxlX2NvbGw6IDAKZGV2LmVtLjAubWFjX3N0YXRzLmxh dGVfY29sbDogMApkZXYuZW0uMC5tYWNfc3RhdHMuY29sbGlzaW9uX2NvdW50OiAwCmRldi5l bS4wLm1hY19zdGF0cy5zeW1ib2xfZXJyb3JzOiAwCmRldi5lbS4wLm1hY19zdGF0cy5zZXF1 ZW5jZV9lcnJvcnM6IDAKZGV2LmVtLjAubWFjX3N0YXRzLmRlZmVyX2NvdW50OiAxMzExCmRl di5lbS4wLm1hY19zdGF0cy5taXNzZWRfcGFja2V0czogNjE2MQpkZXYuZW0uMC5tYWNfc3Rh dHMucmVjdl9ub19idWZmOiAwCmRldi5lbS4wLm1hY19zdGF0cy5yZWN2X3VuZGVyc2l6ZTog MApkZXYuZW0uMC5tYWNfc3RhdHMucmVjdl9mcmFnbWVudGVkOiA1CmRldi5lbS4wLm1hY19z dGF0cy5yZWN2X292ZXJzaXplOiAwCmRldi5lbS4wLm1hY19zdGF0cy5yZWN2X2phYmJlcjog MApkZXYuZW0uMC5tYWNfc3RhdHMucmVjdl9lcnJzOiAxODMKZGV2LmVtLjAubWFjX3N0YXRz LmNyY19lcnJzOiAxOTIKZGV2LmVtLjAubWFjX3N0YXRzLmFsaWdubWVudF9lcnJzOiAwCmRl di5lbS4wLm1hY19zdGF0cy5jb2xsX2V4dF9lcnJzOiAxCmRldi5lbS4wLm1hY19zdGF0cy54 b25fcmVjdmQ6IDEzNDQKZGV2LmVtLjAubWFjX3N0YXRzLnhvbl90eGQ6IDAKZGV2LmVtLjAu bWFjX3N0YXRzLnhvZmZfcmVjdmQ6IDMxNTAKZGV2LmVtLjAubWFjX3N0YXRzLnhvZmZfdHhk OiAwCmRldi5lbS4wLm1hY19zdGF0cy50b3RhbF9wa3RzX3JlY3ZkOiA0NDU2MDQwMTgKZGV2 LmVtLjAubWFjX3N0YXRzLmdvb2RfcGt0c19yZWN2ZDogNDQ1NTkzMTYwCmRldi5lbS4wLm1h Y19zdGF0cy5iY2FzdF9wa3RzX3JlY3ZkOiAxOTMwMwpkZXYuZW0uMC5tYWNfc3RhdHMubWNh c3RfcGt0c19yZWN2ZDogMTUyNgpkZXYuZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVzXzY0OiAw CmRldi5lbS4wLm1hY19zdGF0cy5yeF9mcmFtZXNfNjVfMTI3OiAwCmRldi5lbS4wLm1hY19z dGF0cy5yeF9mcmFtZXNfMTI4XzI1NTogMApkZXYuZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVz XzI1Nl81MTE6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnJ4X2ZyYW1lc181MTJfMTAyMzogMApk ZXYuZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVzXzEwMjRfMTUyMjogMApkZXYuZW0uMC5tYWNf c3RhdHMuZ29vZF9vY3RldHNfcmVjdmQ6IDQwMzIyMzgxNTI3CmRldi5lbS4wLm1hY19zdGF0 cy5nb29kX29jdGV0c190eGQ6IDExMjgxNDY2MDM2NzYKZGV2LmVtLjAubWFjX3N0YXRzLnRv dGFsX3BrdHNfdHhkOiA4NjE0Mjk0NDcKZGV2LmVtLjAubWFjX3N0YXRzLmdvb2RfcGt0c190 eGQ6IDg2MTQyOTQ0NwpkZXYuZW0uMC5tYWNfc3RhdHMuYmNhc3RfcGt0c190eGQ6IDMyNDkK ZGV2LmVtLjAubWFjX3N0YXRzLm1jYXN0X3BrdHNfdHhkOiAxOTU4OQpkZXYuZW0uMC5tYWNf c3RhdHMudHhfZnJhbWVzXzY0OiAwCmRldi5lbS4wLm1hY19zdGF0cy50eF9mcmFtZXNfNjVf MTI3OiAwCmRldi5lbS4wLm1hY19zdGF0cy50eF9mcmFtZXNfMTI4XzI1NTogMApkZXYuZW0u MC5tYWNfc3RhdHMudHhfZnJhbWVzXzI1Nl81MTE6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnR4 X2ZyYW1lc181MTJfMTAyMzogMApkZXYuZW0uMC5tYWNfc3RhdHMudHhfZnJhbWVzXzEwMjRf MTUyMjogMApkZXYuZW0uMC5tYWNfc3RhdHMudHNvX3R4ZDogMjYzNzk1NjU5CmRldi5lbS4w Lm1hY19zdGF0cy50c29fY3R4X2ZhaWw6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy5hc3NlcnRz OiA2MjQ2MDU2MzUKZGV2LmVtLjAuaW50ZXJydXB0cy5yeF9wa3RfdGltZXI6IDAKZGV2LmVt LjAuaW50ZXJydXB0cy5yeF9hYnNfdGltZXI6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy50eF9w a3RfdGltZXI6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy50eF9hYnNfdGltZXI6IDAKZGV2LmVt LjAuaW50ZXJydXB0cy50eF9xdWV1ZV9lbXB0eTogMApkZXYuZW0uMC5pbnRlcnJ1cHRzLnR4 X3F1ZXVlX21pbl90aHJlc2g6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy5yeF9kZXNjX21pbl90 aHJlc2g6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy5yeF9vdmVycnVuOiAwCmRldi5lbS4wLndh a2U6IDAKPDw8IHN5c2N0bCBkZXYuZW0uMAo= ------------51A718D33013DCD-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 12:00:38 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4870D1065673 for ; Thu, 3 Mar 2011 12:00:38 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1D04F8FC1A for ; Thu, 3 Mar 2011 12:00:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p23C0bLJ013302 for ; Thu, 3 Mar 2011 12:00:37 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p23C0b9U013268; Thu, 3 Mar 2011 12:00:37 GMT (envelope-from gnats) Date: Thu, 3 Mar 2011 12:00:37 GMT Message-Id: <201103031200.p23C0b9U013268@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Luiz Otavio O Souza Cc: Subject: Re: kern/155177: [route] [panic] Panic when inject routes in kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Luiz Otavio O Souza List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 12:00:38 -0000 The following reply was made to PR kern/155177; it has been noted by GNATS. From: Luiz Otavio O Souza To: bug-followup@FreeBSD.org, eschoedler@gmail.com Cc: Subject: Re: kern/155177: [route] [panic] Panic when inject routes in kernel Date: Thu, 3 Mar 2011 08:30:55 -0300 Hello, The culprit here is RADIX_MPATH. When the kernel is built with it, it = crashes with the following backtrace (missing on PR): #0 doadump () at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:224 #1 0xffffffff803c8bee in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff803c9021 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:592 #3 0xffffffff8049cc15 in rtfree (rt=3DVariable "rt" is not available. ) at /usr/src/sys/net/route.c:446 #4 0xffffffff804a0856 in route_output (m=3D0xffffff006f14ab00,=20 so=3D0xffffff004dfbd7f8) at /usr/src/sys/net/rtsock.c:863 #5 0xffffffff804321e1 in sosend_generic (so=3D0xffffff004dfbd7f8, = addr=3D0x0,=20 uio=3D0xffffff824413ca90, top=3D0xffffff006f14ab00, control=3D0x0, = flags=3D0,=20 td=3D0xffffff00062a6460) at /usr/src/sys/kern/uipc_socket.c:1260 #6 0xffffffff804126c2 in soo_write (fp=3DVariable "fp" is not = available. ) at /usr/src/sys/kern/sys_socket.c:102 #7 0xffffffff8040b23b in dofilewrite (td=3D0xffffff00062a6460, fd=3D4,=20= fp=3D0xffffff00063fe2d0, auio=3D0xffffff824413ca90, offset=3DVariable = "offset" is not available. ) at file.h:239 #8 0xffffffff8040b550 in kern_writev (td=3D0xffffff00062a6460, fd=3D4,=20= auio=3D0xffffff824413ca90) at /usr/src/sys/kern/sys_generic.c:447 #9 0xffffffff8040b5d5 in write (td=3DVariable "td" is not available. ) at /usr/src/sys/kern/sys_generic.c:363 #10 0xffffffff804077a5 in syscallenter (td=3D0xffffff00062a6460,=20 sa=3D0xffffff824413cba0) at /usr/src/sys/kern/subr_trap.c:315 #11 0xffffffff8064a6ab in syscall (frame=3D0xffffff824413cc40) at /usr/src/sys/amd64/amd64/trap.c:944 #12 0xffffffff80632c52 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:381 #13 0x0000000800bc5b3c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 Looks like it is leaking the 'rt->rt_refcnt' and as result it = crashes/panic at RTFREE() on the end of route_output(). I don't have access to this live system to dig further (i.e. reduce the = test case). Cheers, Luiz= From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 12:20:44 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E2FA106566C for ; Thu, 3 Mar 2011 12:20:44 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA0B8FC17 for ; Thu, 3 Mar 2011 12:20:43 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D31EC25D37C4; Thu, 3 Mar 2011 12:03:26 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 894061599D81; Thu, 3 Mar 2011 12:03:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id u6ev1hN1KcyT; Thu, 3 Mar 2011 12:03:24 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3E9411599D96; Thu, 3 Mar 2011 12:03:24 +0000 (UTC) Date: Thu, 3 Mar 2011 12:03:23 +0000 (UTC) From: "Bjoern A. Zeeb" To: Alex Povolotsky In-Reply-To: <4D6F3581.6010906@webmail.sub.ru> Message-ID: References: <4D4FA3DA.7010004@webmail.sub.ru> <20110302214601.S13400@maildrop.int.zabbadoz.net> <4D6F3581.6010906@webmail.sub.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2061604774-1299153804=:6104" Cc: freebsd-net@FreeBSD.org Subject: Re: jail source address selection doesn't work? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 12:20:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2061604774-1299153804=:6104 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 3 Mar 2011, Alex Povolotsky wrote: Hi, > 03.03.2011 0:48, Bjoern A. Zeeb пишет: >> On Mon, 7 Feb 2011, Alex Povolotsky wrote: >>> >>> Okay, yes? >>> >>> From jail: >>> ... >>> >>> What could I miss?... >> >> Don't use ping to test this. a) for ping inside the jail to work you >> need to enable raw sockets b) a) could give you a hint that ping does >> it's own thing. > Telnet did all the same thing. >> >> Try a telnet to a random port to the destination and verify with >> tcpdump whether things are still not working correctly, of if you >> establish the connection with netstat. > I used telnet to connect to specific ports. > > Ok, let's try again > > 104:tarkhil@box2.u.energodata.local:...local/etc/ezjail # jls > JID IP Address Hostname Path > 1 192.168.82.2 test /usr/jails/test > 107:tarkhil@box2.u.energodata.local:...local/etc/ezjail # jls -j 1 > ip4.saddrsel > true > 108:tarkhil@box2.u.energodata.local:...local/etc/ezjail # jls -j 1 ip4.addr > 192.168.82.2,192.168.75.2 > 114:tarkhil@box2.u.energodata.local:...local/etc/ezjail # tcpdump -l -n -i > bce0 host 192.168.82.2 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on bce0, link-type EN10MB (Ethernet), capture size 96 bytes > 09:27:54.492105 IP 192.168.82.2.50823 > 192.168.72.3.22: Flags [S], seq > 3819433473, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val > 1306232522 ecr 0], length 0 ... > inet 192.168.80.41 netmask 0xffffff00 broadcast 192.168.80.255 > inet 192.168.75.2 netmask 0xffffff00 broadcast 192.168.75.255 > inet 192.168.82.2 netmask 0xffffff00 broadcast 192.168.82.255 .. > In other words, source address is selected as primary IP, and packet runs out > on 100% improper interface. > > No specific routing, no firewall. Not sure what you expect. Your jail has an address out of 192.168.82.2/24 and 192.168.75.2/24 You are trying to connect to neither of those networks but 192.168.72.3. Given the destination network does not match any directly connected network and, based on your previous email, you don't have an route going out a gateway of either of those two networks to 192.168.72.3 it's doing the fallback to the "primary" jail IP, as expected. You would need to add a more specific route to the destination via a gateway of either connected network if you wanted a different source address to be picked; if you just want to limit that to the single jail but not the global system look at setfib for IPv4. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. --0-2061604774-1299153804=:6104-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 12:30:50 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF6591065673 for ; Thu, 3 Mar 2011 12:30:50 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 278508FC12 for ; Thu, 3 Mar 2011 12:30:49 +0000 (UTC) Received: (qmail 54004 invoked from network); 3 Mar 2011 15:30:58 +0300 Received: from gw.kbor.ru (gw.kbor.ru [195.91.189.247]) by mail.sub.ru ([88.212.205.2]) with ESMTP via TCP; 03 Mar 2011 12:30:58 -0000 Message-ID: <4D6F89DD.1070105@webmail.sub.ru> Date: Thu, 03 Mar 2011 15:30:21 +0300 From: Alex Povolotsky User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101103 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4D4FA3DA.7010004@webmail.sub.ru> <20110302214601.S13400@maildrop.int.zabbadoz.net> <4D6F3581.6010906@webmail.sub.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: jail source address selection doesn't work? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 12:30:51 -0000 On 03/03/11 15:03, Bjoern A. Zeeb wrote: > > Not sure what you expect. Your jail has an address out of > 192.168.82.2/24 and > 192.168.75.2/24 > > You are trying to connect to neither of those networks but 192.168.72.3. Now it was a typo. Either I've lost my mind or I can't reproduce a problem. Will check everything again. Alex. From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 14:15:45 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 196D2106566B for ; Thu, 3 Mar 2011 14:15:45 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 990438FC08 for ; Thu, 3 Mar 2011 14:15:44 +0000 (UTC) Received: by wwb31 with SMTP id 31so1453387wwb.31 for ; Thu, 03 Mar 2011 06:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KMdOiYcF1RnWT6QbXrIsakkboC5LmaKIaMDTxjVat18=; b=la8PtpXJBBjcn8zWXhyaPLWTOAJHXLlRjJDPXWvJZoOUPNJPR3nDENTMvkD7vC9o3z 6E4gf4NlZa6mDSC8xxan9B56sCvxyRlGpXhlrEPkUr7kMjBOha2XAKYLYwcNVJ2Upnwp 8gSp4muesBytNPEvYTEQ7zGIsanIQ1GhIADqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=T60p9SBxRL5LpGEpmag6N1PWummb9lJBdYWfd3ur7zCXPRsaWZtRWwgTAZU4YxTyC0 161Z9pmTCAmLkhcbYESM4ozhVp3Ommxrv52JG52IAZYlq9qQXCurd6EzxgAUlHth2N03 pHfUP9AFBMfRX2BgkXw9uF2j5GJVLgG6mRxx8= MIME-Version: 1.0 Received: by 10.216.145.222 with SMTP id p72mr881471wej.65.1299161306479; Thu, 03 Mar 2011 06:08:26 -0800 (PST) Received: by 10.216.25.72 with HTTP; Thu, 3 Mar 2011 06:08:26 -0800 (PST) In-Reply-To: <1627628072.20110303111046@serebryakov.spb.ru> References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> Date: Thu, 3 Mar 2011 08:08:26 -0600 Message-ID: From: Brandon Gooch To: Lev Serebryakov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jan Koum , freebsd-stable@freebsd.org, Jack Vogel , Arnaud Lacombe Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 14:15:45 -0000 On Thu, Mar 3, 2011 at 2:10 AM, Lev Serebryakov wr= ote: > Hello, Arnaud. > You wrote 2 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 9:55:50: > >>>> I have been running with 7.2.2 and so far so good. =C2=A0However, its = hard to >>>> say in my case as the box I would only periodically see the issue. >>> =C2=A0As I wrote to Jack, my NIC hangs today with 7.2.2 >> Do you have any detailed error ? What the output of sysctl "dev.em.X" >> where X is the index of the hung interface ? > =C2=A0One more hang. Two logs are attached. > > -- > // Black Lion AKA Lev Serebryakov I see that you have CRC errors: dev.em.0.mac_stats.crc_errs: 156 and receive errors: dev.em.0.mac_stats.recv_errs: 147 You probably have a hardware problem. Is this the only machine on which you're experiencing the problem? -Brandon From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 21:40:28 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A6A510656A5; Thu, 3 Mar 2011 21:40:28 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id DE6448FC18; Thu, 3 Mar 2011 21:40:27 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 5C61F13DF5F; Fri, 4 Mar 2011 00:40:26 +0300 (MSK) Date: Fri, 4 Mar 2011 00:40:10 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <595446342.20110304004010@serebryakov.spb.ru> To: Brandon Gooch In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jan Koum , freebsd-stable@freebsd.org, Jack Vogel , Arnaud Lacombe Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 21:40:28 -0000 Hello, Brandon. You wrote 3 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 17:08:26: > I see that you have CRC errors: > dev.em.0.mac_stats.crc_errs: 156 > and receive errors: > dev.em.0.mac_stats.recv_errs: 147 > You probably have a hardware problem. Is this the only machine on > which you're experiencing the problem? It is only machine with Intel NIC in my network. I'll try to replace patchcord... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 22:26:12 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B0A7106564A; Thu, 3 Mar 2011 22:26:12 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id A0E528FC16; Thu, 3 Mar 2011 22:26:11 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 8422313DF42; Fri, 4 Mar 2011 01:26:10 +0300 (MSK) Date: Fri, 4 Mar 2011 01:25:54 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1894628540.20110304012554@serebryakov.spb.ru> To: Brandon Gooch In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arnaud Lacombe , freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel , Jan Koum Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 22:26:12 -0000 Hello, Brandon. You wrote 3 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 17:08:26: > I see that you have CRC errors: > dev.em.0.mac_stats.crc_errs: 156 > and receive errors: > dev.em.0.mac_stats.recv_errs: 147 It (almost) doesn't change. And it hangs again. It seems, that 7.2.2 hangs more often than 7.1.9 on my hardware :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 22:31:07 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 645E7106566B; Thu, 3 Mar 2011 22:31:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id E466C8FC23; Thu, 3 Mar 2011 22:31:06 +0000 (UTC) Received: by vxc34 with SMTP id 34so1728606vxc.13 for ; Thu, 03 Mar 2011 14:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=lsgSN7g3YbjNZeCqbmu04D1j1aRqKt8LV4b+4cdiCuU=; b=EUsnwQRrV0CinzU7gEIYMcBR0526N8CxlrkIiCL/wntjKZO+zHX4d4dDckdYeGJM4m 3ntXZtDglveTK8Y2bYLWSMJyo4t1CjOQV75GKnguavUMRIFsH4eTmc04duaBKlU/qPyt 1l5Gb55r7+cpEebi7eOckCVyddUHWt06y4pFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=v5WcErKV6S71VITgKSnV4dM70WmudrPBz3mgzF7sY6u+VoZ4UuVuNS2Cu8hioJRpKJ aPnuTqwlQ06+AtqJfuJkzqWztpkxWyCQDdUsoRfcelnZ6Hc2zaQj7zNT4B2Oz7BkQR6u RL9V79HaTOcGO/JNG266TRhsDplen6nOFQXVo= MIME-Version: 1.0 Received: by 10.220.5.129 with SMTP id 1mr432571vcv.169.1299191465943; Thu, 03 Mar 2011 14:31:05 -0800 (PST) Received: by 10.220.188.132 with HTTP; Thu, 3 Mar 2011 14:31:05 -0800 (PST) Date: Thu, 3 Mar 2011 14:31:05 -0800 Message-ID: From: Adrian Chadd To: freebsd-mobile@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , freebsd-current Subject: please (re) test if_ath in -HEAD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 22:31:07 -0000 Hi all, For those of you who are testing out my if_ath changes, I'd really appreciate it if you'd update to -HEAD and re-test. I've done a variety of changes to the radio setup and found/fixed a few bugs in the TX path. It's quite possible these have introduced regressions. I'd like to make sure that I haven't broken legacy (11abg) support in weird/wonderful ways. I'd also like to make sure that I haven't broken/changed the behaviour or performance of the NICs in any way. Please give things a good thrashing and let me know the results. I'm still working towards debugging and enabling basic 11n support, but I need to first make sure that I haven't broken legacy operation in any way. Thanks, Adrian From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 06:54:42 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DE621065670 for ; Fri, 4 Mar 2011 06:54:42 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 148B58FC08 for ; Fri, 4 Mar 2011 06:54:41 +0000 (UTC) Received: by qwj8 with SMTP id 8so1592800qwj.13 for ; Thu, 03 Mar 2011 22:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=t3SX6EWcZ5IzC5FzYQKrXQmhthYJTY9PIyOrdWVcBh0=; b=rR51e+XynZbzRc6EljaIpRMmrmh1s6fu/uTFbYrLuHx1zXuQx80Nlq8j4DCyZmNDB+ WfPAOhnzKOoDXB+wkoDV3cZYNQyRK7TUap+3azIchGZBGi4hj7H2yYlsdD+d5xYqt8pg 64wjos2aAswX6iYJj5/z0w76ZYkln0xLdph+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hux77gvc9Od2R0MewiUuSr1BZMu7iw5c4iV/SxpWCkPiR9jLhXLAevpgZbDFxzMgr2 m/WVIua6xH7C2b+qmsdQ2wXF9St+kL87RUEJLiBoIlKkl9GFErksg2D564i0hULbYJNM u9228LE78K7Ytq73NSB77rCKxxx8jra1QeJ2Y= MIME-Version: 1.0 Received: by 10.229.77.142 with SMTP id g14mr173404qck.55.1299221681017; Thu, 03 Mar 2011 22:54:41 -0800 (PST) Received: by 10.229.84.129 with HTTP; Thu, 3 Mar 2011 22:54:40 -0800 (PST) Date: Fri, 4 Mar 2011 09:54:40 +0300 Message-ID: From: Sergey Kandaurov To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Subject: arpintr()->in_lltable_lookup() 8.1 bce(4) crash X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 06:54:42 -0000 Hi. That's the second crash on 8.1. A previous one was month ago on another box. They are almost identical. Kernel can't dump core on these disk controllers. Any hints are appreciated. kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff805f30d2 stack pointer = 0x28:0xffffff82b1554890 frame pointer = 0x28:0xffffff82b15548c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 12 (irq256: bce0) db> bt Tracing pid 12 tid 100038 td 0xffffff00029a17c0 propagate_priority() at propagate_priority+0x72 turnstile_wait() at turnstile_wait+0x1aa _rw_wlock_hard() at _rw_wlock_hard+0xfa in_lltable_lookup() at in_lltable_lookup+0x12b arpintr() at arpintr+0x9d6 netisr_dispatch_src() at netisr_dispatch_src+0x7e ether_demux() at ether_demux+0x14d ether_input() at ether_input+0x17b bce_intr() at bce_intr+0x3b0 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff82b1554d30, rbp = 0 --- #################################### kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0xc fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff805f30c2 stack pointer = 0x28:0xffffff82b155d830 frame pointer = 0x28:0xffffff82b155d860 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 12 (irq257: bce1) db> bt Tracing pid 12 tid 100039 td 0xffffff00029a23e0 propagate_priority() at propagate_priority+0x72 turnstile_wait() at turnstile_wait+0x1aa _rw_wlock_hard() at _rw_wlock_hard+0xfa in_lltable_lookup() at in_lltable_lookup+0x12b arpintr() at arpintr+0x9d6 netisr_dispatch_src() at netisr_dispatch_src+0x7e ether_demux() at ether_demux+0x14d ether_input() at ether_input+0x17b ether_demux() at ether_demux+0x6f ether_input() at ether_input+0x17b bce_intr() at bce_intr+0x3b0 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff82b155dd30, rbp = 0 --- That's what was on another CPUs atm, if that matters: db> show proc 12 Process 12 (intr) at 0xffffff00026e7000: state: NORMAL uid: 0 gids: 0 parent: pid 0 at 0xffffffff80c7e3e0 ABI: null threads: 24 100065 I [irq1: atkbd0] 100064 I [swi0: uart uart] 100063 I [irq15: ata1] 100062 I [irq14: ata0] 100045 I [irq22: uhci1 uhci3] 100040 I [irq23: uhci0 uhci2+] 100039 L *lle 0xffffff032af863c0 [irq257: bce1] 100038 I [irq256: bce0] 100036 I [irq17: aac0] 100035 I [irq9: acpi0] 100034 I [swi5: +] 100032 I [swi2: cambio] 100028 I [swi6: task queue] 100027 I [swi6: Giant taskq] 100020 I [swi3: vm] 100019 Run CPU 1 [swi4: clock] 100018 Run CPU 5 [swi4: clock] 100017 Run CPU 6 [swi4: clock] 100016 I [swi4: clock] 100015 Run CPU 3 [swi4: clock] 100014 I [swi4: clock] 100013 CanRun [swi4: clock] 100012 I [swi4: clock] 100011 I [swi1: netisr 0] db> show allpcpu Current CPU: 2 cpuid = 0 dynamic pcpu = 0x2a3f80 curthread = 0xffffff0061aca000: pid 52989 "httpd" curpcb = 0xffffff82b7e2fd40 fpcurthread = none idlethread = 0xffffff00026ea7c0: pid 11 "idle: cpu0" curpmap = 0 tssp = 0xffffffff80cf0080 commontssp = 0xffffffff80cf0080 rsp0 = 0xffffff82b7e2fd40 gs32p = 0xffffffff80ceeeb8 ldt = 0xffffffff80ceeef8 tss = 0xffffffff80ceeee8 cpuid = 1 dynamic pcpu = 0xffffff807f418f80 curthread = 0xffffff00027003e0: pid 12 "swi4: clock" curpcb = 0xffffff80000ecd40 fpcurthread = none idlethread = 0xffffff00026eaba0: pid 11 "idle: cpu1" curpmap = 0 tssp = 0xffffffff80cf00e8 commontssp = 0xffffffff80cf00e8 rsp0 = 0xffffff80000ecd40 gs32p = 0xffffffff80ceef20 ldt = 0xffffffff80ceef60 tss = 0xffffffff80ceef50 cpuid = 2 dynamic pcpu = 0xffffff807f41ff80 curthread = 0xffffff00029a23e0: pid 12 "irq257: bce1" curpcb = 0xffffff82b155dd40 fpcurthread = none idlethread = 0xffffff00026f6000: pid 11 "idle: cpu2" curpmap = 0 tssp = 0xffffffff80cf0150 commontssp = 0xffffffff80cf0150 rsp0 = 0xffffff82b155dd40 gs32p = 0xffffffff80ceef88 ldt = 0xffffffff80ceefc8 tss = 0xffffffff80ceefb8 cpuid = 3 dynamic pcpu = 0xffffff807f426f80 curthread = 0xffffff00026fb7c0: pid 12 "swi4: clock" curpcb = 0xffffff80000d8d40 fpcurthread = none idlethread = 0xffffff00026f63e0: pid 11 "idle: cpu3" curpmap = 0 tssp = 0xffffffff80cf01b8 commontssp = 0xffffffff80cf01b8 rsp0 = 0xffffff80000d8d40 gs32p = 0xffffffff80ceeff0 ldt = 0xffffffff80cef030 tss = 0xffffffff80cef020 cpuid = 4 dynamic pcpu = 0xffffff807f42df80 curthread = 0xffffff014bbbbba0: pid 53746 "head" curpcb = 0xffffff82b92c0d40 fpcurthread = none idlethread = 0xffffff00026f67c0: pid 11 "idle: cpu4" curpmap = 0 tssp = 0xffffffff80cf0220 commontssp = 0xffffffff80cf0220 rsp0 = 0xffffff82b92c0d40 gs32p = 0xffffffff80cef058 ldt = 0xffffffff80cef098 tss = 0xffffffff80cef088 cpuid = 5 dynamic pcpu = 0xffffff807f434f80 curthread = 0xffffff00026f6ba0: pid 12 "swi4: clock" curpcb = 0xffffff80000e7d40 fpcurthread = none idlethread = 0xffffff00026e9000: pid 11 "idle: cpu5" curpmap = 0 tssp = 0xffffffff80cf0288 commontssp = 0xffffffff80cf0288 rsp0 = 0xffffff80000e7d40 gs32p = 0xffffffff80cef0c0 ldt = 0xffffffff80cef100 tss = 0xffffffff80cef0f0 cpuid = 6 dynamic pcpu = 0xffffff807f43bf80 curthread = 0xffffff00026fb000: pid 12 "swi4: clock" curpcb = 0xffffff80000e2d40 fpcurthread = none idlethread = 0xffffff00026e93e0: pid 11 "idle: cpu6" curpmap = 0 tssp = 0xffffffff80cf02f0 commontssp = 0xffffffff80cf02f0 rsp0 = 0xffffff80000e2d40 gs32p = 0xffffffff80cef128 ldt = 0xffffffff80cef168 tss = 0xffffffff80cef158 cpuid = 7 dynamic pcpu = 0xffffff807f442f80 curthread = 0xffffff008976eba0: pid 45168 "httpd" curpcb = 0xffffff82b71b4d40 fpcurthread = 0xffffff008976eba0: pid 45168 "httpd" idlethread = 0xffffff00026e97c0: pid 11 "idle: cpu7" curpmap = 0 tssp = 0xffffffff80cf0358 commontssp = 0xffffffff80cf0358 rsp0 = 0xffffff82b71b4d40 gs32p = 0xffffffff80cef190 ldt = 0xffffffff80cef1d0 tss = 0xffffffff80cef1c0 db> bt 52989 Tracing pid 52989 tid 103210 td 0xffffff0061aca000 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x175 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff808c45c2, rsp = 0xffffffff80cf7e40, rbp = 0xffffff82b7e2f8d0 --- DELAY() at DELAY+0x62 _thread_lock_flags() at _thread_lock_flags+0xb0 sleepq_add() at sleepq_add+0x8c _sleep() at _sleep+0x159 soreceive_generic() at soreceive_generic+0xeba dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x55 ia32_syscall() at ia32_syscall+0x1eb Xint0x80_syscall() at Xint0x80_syscall+0x95 --- syscall (3, FreeBSD ELF32, read), rip = 0x281b834f, rsp = 0xffffb89c, rbp = 0xffffb8b8 --- db> bt 53746 Tracing pid 53746 tid 104263 td 0xffffff014bbbbba0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x175 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff808c45c4, rsp = 0xffffff8000067fe0, rbp = 0xffffff82b92c05e0 --- DELAY() at DELAY+0x64 _thread_lock_flags() at _thread_lock_flags+0xb0 intr_event_schedule_thread() at intr_event_schedule_thread+0x72 callout_tick() at callout_tick+0xf8 hardclock_cpu() at hardclock_cpu+0xd2 lapic_handle_timer() at lapic_handle_timer+0xff Xtimerint() at Xtimerint+0x8c --- interrupt, rip = 0xffffffff808be298, rsp = 0xffffff82b92c07e0, rbp = 0xffffff82b92c0840 --- pmap_remove() at pmap_remove+0x2a8 vm_map_delete() at vm_map_delete+0xf4 vm_map_fixed() at vm_map_fixed+0x78 vm_mmap() at vm_mmap+0x51d mmap() at mmap+0x219 syscall() at syscall+0x1e7 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (477, FreeBSD ELF64, mmap), rip = 0x80050c86c, rsp = 0x7fffffffe278, rbp = 0x7fffffffe370 --- db> bt 45168 Tracing pid 45168 tid 102571 td 0xffffff008976eba0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x175 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff805a3d8d, rsp = 0xffffff800007cfe0, rbp = 0xffffff82b71b4860 --- _mtx_lock_sleep() at _mtx_lock_sleep+0xdd pmap_enter() at pmap_enter+0x2f7 vm_fault() at vm_fault+0x14dc trap_pfault() at trap_pfault+0x132 trap() at trap+0x4dc calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x281b7b96, rsp = 0xfffe2424, rbp = 0xfffe24e8 --- db> bt 11 Tracing pid 11 tid 100010 td 0xffffff00026ea7c0 sched_switch() at sched_switch+0xea mi_switch() at mi_switch+0x16f sched_preempt() at sched_preempt+0xb5 ipi_bitmap_handler() at ipi_bitmap_handler+0x70 Xipi_intr_bitmap_handler() at Xipi_intr_bitmap_handler+0x9b --- interrupt, rip = 0xffffffff805a41f4, rsp = 0xffffff80000bfb60, rbp = 0xffffff80000bfba0 --- _thread_lock_flags() at _thread_lock_flags+0x64 sched_idletd() at sched_idletd+0xde fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff80000bfd30, rbp = 0 --- db> bt 12 Tracing pid 12 tid 100065 td 0xffffff0009001ba0 fork_trampoline() at fork_trampoline -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 12:10:08 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1BB1106566C; Fri, 4 Mar 2011 12:10:07 +0000 (UTC) (envelope-from eschoedler@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 88C1E8FC15; Fri, 4 Mar 2011 12:10:07 +0000 (UTC) Received: by yxl31 with SMTP id 31so836527yxl.13 for ; Fri, 04 Mar 2011 04:10:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=bTroIaG8+vD2zjUDfoLuwXUCI9IQ6FhDjZgQs1+6Yjk=; b=uRLB6k1VsyM8RVhlEB3ma90ldDfS8LDwlMS/eecc3Kbx2HwnoMEFAiTXm3TqY7wByM GVGJUv5ldcRn06BWn5KUGRMrIT6PJlbdY/ERzJorkkEbKm1H8jGbu2idts1hUbC9ffvV mE22dtYJVbgenyb/oWCw81KG8c64zQRfUP8Qw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; b=HKsYyFTgbZCHfsNxZv2sxt0VcKK8SI3+krkAefwAkqvVSW4MC2qPouFmPfxgBcLFLS 7xblAYYRrkOimg1Q64GD7uNsVdQgN6f1x7m2eisvdltpXUS66goXolepG6WGd/kVTspT zuOGtC+QcBLGug4E2ZbiJtm51MLExBR5Gtv3c= Received: by 10.150.91.4 with SMTP id o4mr569533ybb.185.1299240606769; Fri, 04 Mar 2011 04:10:06 -0800 (PST) Received: from VIAREDES01 (gw01-redegazeta.viavale.com.br [200.143.116.14]) by mx.google.com with ESMTPS id r18sm1667850yba.11.2011.03.04.04.10.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2011 04:10:04 -0800 (PST) From: "Eduardo Schoedler" To: Date: Fri, 4 Mar 2011 09:10:00 -0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvZ8gabw3yyebUUSvaHUHWKyfsw5QAcvhxw Content-Language: pt-br Cc: freebsd-net@FreeBSD.org, eschoedler@gmail.com Subject: Re: kern/155177: [route] [panic] Panic when inject routes in kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 12:10:08 -0000 Hello, I've found another (easy) way to reproduce the problem with two scripts: routes-add.sh and routes-remove.sh. First run routes-add.sh for a while; then execute routes-remove.sh. Cancel with CTRL+C and execute routes-remove.sh again. Scripts: ======== # cat routes-add.sh #!/usr/local/bin/bash for a in {11..16}; do for b in {1..255}; do for c in {1..255}; do echo -n Adding route $a.$b.$c.0/24... route -q delete -net $a.$b.$c.0/24 echo OK. done done done # cat routes-remove.sh #!/usr/local/bin/bash for a in {11..16}; do for b in {1..255}; do for c in {1..255}; do echo -n Removing route $a.$b.$c.0/24... route -q delete -net $a.$b.$c.0/24 echo OK. done done done Backtrace: ========== # cat /var/crash/core.txt.1 Unread portion of the kernel message buffer: panic: rtfree 2 cpuid = 4 KDB: stack backtrace: #0 0xffffffff80416e43 at kdb_backtrace+0x5e #1 0xffffffff803e68a8 at panic+0x182 #2 0xffffffff804b2274 at rtalloc1_fib+0 #3 0xffffffff804b5b92 at route_output+0x304 #4 0xffffffff8044b776 at sosend_generic+0x366 #5 0xffffffff8042cd5c at soo_write+0x54 #6 0xffffffff80425bee at dofilewrite+0x7a #7 0xffffffff80425ec1 at kern_writev+0x52 #8 0xffffffff80425f3f at write+0x4e #9 0xffffffff80422408 at syscallenter+0x186 #10 0xffffffff8065b4f7 at syscall+0x40 #11 0xffffffff806449f2 at Xfast_syscall+0xe2 Uptime: 37m16s Physical memory: 4084 MB Dumping 497 MB:VOP_STRATEGY: bp is not locked but should be 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 #0 doadump () at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:224 #1 0xffffffff803e6425 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff803e6892 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:592 #3 0xffffffff804b2274 in rtfree (rt=Variable "rt" is not available. ) at /usr/src/sys/net/route.c:446 #4 0xffffffff804b5b92 in route_output (m=0xffffff0004790700, so=0xffffff00b07ead48) at /usr/src/sys/net/rtsock.c:863 #5 0xffffffff8044b776 in sosend_generic (so=0xffffff00b07ead48, addr=0x0, uio=0xffffff830ff98a90, top=0xffffff0004790700, control=0x0, flags=0, td=0xffffff0004a13000) at /usr/src/sys/kern/uipc_socket.c:1260 #6 0xffffffff8042cd5c in soo_write (fp=Variable "fp" is not available. ) at /usr/src/sys/kern/sys_socket.c:102 #7 0xffffffff80425bee in dofilewrite (td=0xffffff0004a13000, fd=3, fp=0xffffff0004977af0, auio=0xffffff830ff98a90, offset=Variable "offset" is not available. ) at file.h:239 #8 0xffffffff80425ec1 in kern_writev (td=0xffffff0004a13000, fd=3, auio=0xffffff830ff98a90) at /usr/src/sys/kern/sys_generic.c:447 #9 0xffffffff80425f3f in write (td=Variable "td" is not available. ) at /usr/src/sys/kern/sys_generic.c:363 #10 0xffffffff80422408 in syscallenter (td=0xffffff0004a13000, sa=0xffffff830ff98ba0) at /usr/src/sys/kern/subr_trap.c:315 #11 0xffffffff8065b4f7 in syscall (frame=0xffffff830ff98c40) at /usr/src/sys/amd64/amd64/trap.c:944 #12 0xffffffff806449f2 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:381 #13 0x0000000800735afc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Again, removing RADIX_MPATH from kernel, it's working fine. Regards, -- Eduardo Schoedler From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 12:20:11 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DDC81065674 for ; Fri, 4 Mar 2011 12:20:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7DB8FC15 for ; Fri, 4 Mar 2011 12:20:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p24CKB3I046593 for ; Fri, 4 Mar 2011 12:20:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p24CKB6J046592; Fri, 4 Mar 2011 12:20:11 GMT (envelope-from gnats) Date: Fri, 4 Mar 2011 12:20:11 GMT Message-Id: <201103041220.p24CKB6J046592@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Eduardo Schoedler" Cc: Subject: Re: kern/155177: [route] [panic] Panic when inject routes in kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eduardo Schoedler List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 12:20:11 -0000 The following reply was made to PR kern/155177; it has been noted by GNATS. From: "Eduardo Schoedler" To: Cc: , Subject: Re: kern/155177: [route] [panic] Panic when inject routes in kernel Date: Fri, 4 Mar 2011 09:10:00 -0300 Hello, I've found another (easy) way to reproduce the problem with two scripts: routes-add.sh and routes-remove.sh. First run routes-add.sh for a while; then execute routes-remove.sh. Cancel with CTRL+C and execute routes-remove.sh again. Scripts: ======== # cat routes-add.sh #!/usr/local/bin/bash for a in {11..16}; do for b in {1..255}; do for c in {1..255}; do echo -n Adding route $a.$b.$c.0/24... route -q delete -net $a.$b.$c.0/24 echo OK. done done done # cat routes-remove.sh #!/usr/local/bin/bash for a in {11..16}; do for b in {1..255}; do for c in {1..255}; do echo -n Removing route $a.$b.$c.0/24... route -q delete -net $a.$b.$c.0/24 echo OK. done done done Backtrace: ========== # cat /var/crash/core.txt.1 Unread portion of the kernel message buffer: panic: rtfree 2 cpuid = 4 KDB: stack backtrace: #0 0xffffffff80416e43 at kdb_backtrace+0x5e #1 0xffffffff803e68a8 at panic+0x182 #2 0xffffffff804b2274 at rtalloc1_fib+0 #3 0xffffffff804b5b92 at route_output+0x304 #4 0xffffffff8044b776 at sosend_generic+0x366 #5 0xffffffff8042cd5c at soo_write+0x54 #6 0xffffffff80425bee at dofilewrite+0x7a #7 0xffffffff80425ec1 at kern_writev+0x52 #8 0xffffffff80425f3f at write+0x4e #9 0xffffffff80422408 at syscallenter+0x186 #10 0xffffffff8065b4f7 at syscall+0x40 #11 0xffffffff806449f2 at Xfast_syscall+0xe2 Uptime: 37m16s Physical memory: 4084 MB Dumping 497 MB:VOP_STRATEGY: bp is not locked but should be 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 #0 doadump () at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:224 #1 0xffffffff803e6425 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff803e6892 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:592 #3 0xffffffff804b2274 in rtfree (rt=Variable "rt" is not available. ) at /usr/src/sys/net/route.c:446 #4 0xffffffff804b5b92 in route_output (m=0xffffff0004790700, so=0xffffff00b07ead48) at /usr/src/sys/net/rtsock.c:863 #5 0xffffffff8044b776 in sosend_generic (so=0xffffff00b07ead48, addr=0x0, uio=0xffffff830ff98a90, top=0xffffff0004790700, control=0x0, flags=0, td=0xffffff0004a13000) at /usr/src/sys/kern/uipc_socket.c:1260 #6 0xffffffff8042cd5c in soo_write (fp=Variable "fp" is not available. ) at /usr/src/sys/kern/sys_socket.c:102 #7 0xffffffff80425bee in dofilewrite (td=0xffffff0004a13000, fd=3, fp=0xffffff0004977af0, auio=0xffffff830ff98a90, offset=Variable "offset" is not available. ) at file.h:239 #8 0xffffffff80425ec1 in kern_writev (td=0xffffff0004a13000, fd=3, auio=0xffffff830ff98a90) at /usr/src/sys/kern/sys_generic.c:447 #9 0xffffffff80425f3f in write (td=Variable "td" is not available. ) at /usr/src/sys/kern/sys_generic.c:363 #10 0xffffffff80422408 in syscallenter (td=0xffffff0004a13000, sa=0xffffff830ff98ba0) at /usr/src/sys/kern/subr_trap.c:315 #11 0xffffffff8065b4f7 in syscall (frame=0xffffff830ff98c40) at /usr/src/sys/amd64/amd64/trap.c:944 #12 0xffffffff806449f2 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:381 #13 0x0000000800735afc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Again, removing RADIX_MPATH from kernel, it's working fine. Regards, -- Eduardo Schoedler From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 00:17:22 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF0A2106564A; Sat, 5 Mar 2011 00:17:22 +0000 (UTC) (envelope-from prvs=10451ca0e0=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 141298FC0C; Sat, 5 Mar 2011 00:17:21 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 05 Mar 2011 00:06:14 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 05 Mar 2011 00:06:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50012385947.msg; Sat, 05 Mar 2011 00:06:14 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=10451ca0e0=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> From: "Steven Hartland" To: "Lev Serebryakov" , "Brandon Gooch" References: <1975926365.20110223121637@serebryakov.spb.ru><4D64EC8C.2080007@sentex.net><1004451940.20110223143607@serebryakov.spb.ru><4D6D00C1.1040805@sentex.net><1416421652.20110301225215@serebryakov.spb.ru><1627628072.20110303111046@serebryakov.spb.ru> <1894628540.20110304012554@serebryakov.spb.ru> Date: Sat, 5 Mar 2011 00:06:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: freebsd-net@freebsd.org, Jan Koum , freebsd-stable@freebsd.org, Jack Vogel , Arnaud Lacombe Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 00:17:22 -0000 Silly question but have you checked your ram for issues, we had a machine with seemingly unexplained problems and hangs and it turned out to be a duff stick of ram which wasn't being chip killed. ----- Original Message ----- From: "Lev Serebryakov" To: "Brandon Gooch" Cc: "Arnaud Lacombe" ; ; ; "Jack Vogel" ; "Jan Koum" Sent: Thursday, March 03, 2011 10:25 PM Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) Hello, Brandon. You wrote 3 марта 2011 г., 17:08:26: > I see that you have CRC errors: > dev.em.0.mac_stats.crc_errs: 156 > and receive errors: > dev.em.0.mac_stats.recv_errs: 147 It (almost) doesn't change. And it hangs again. It seems, that 7.2.2 hangs more often than 7.1.9 on my hardware :( -- // Black Lion AKA Lev Serebryakov _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 00:22:05 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A6ED1065673; Sat, 5 Mar 2011 00:22:05 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 1A6CC8FC1F; Sat, 5 Mar 2011 00:22:05 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id B432A25D3868; Sat, 5 Mar 2011 00:21:33 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id DA4BD159959E; Sat, 5 Mar 2011 00:21:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id hzUkSGXtMo6F; Sat, 5 Mar 2011 00:21:31 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C813A1599598; Sat, 5 Mar 2011 00:21:30 +0000 (UTC) Date: Sat, 5 Mar 2011 00:21:29 +0000 (UTC) From: "Bjoern A. Zeeb" To: Doug Barton In-Reply-To: <4D6AB636.3030708@FreeBSD.org> Message-ID: References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> <4D437B13.1070405@FreeBSD.org> <4D518FB3.3040503@FreeBSD.org> <4D6AB2BD.50208@gont.com.ar> <4D6AB636.3030708@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: FreeBSD Net , Ivo Vachkov Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 00:22:05 -0000 On Sun, 27 Feb 2011, Doug Barton wrote: > On 02/27/2011 12:23, Fernando Gont wrote: >> On 08/02/2011 03:47 p.m., Doug Barton wrote: >> >> [catching up with e-mail] >> >>> I've been up and running on this patch vs. r218391 for over 24 hours >>> now, using algorithm 4 (as someone said is now the default in Linux) >>> without any problems. >>> >>> I think Bjoern is better qualified than I to comment on the style of the >>> patch, but it applies cleanly, and seems to run fine on both v4 and v6. >> >> Has this been commited to the tree, already? -- If so, what's the >> default algorithm? > > Bjoern was planning to do it, I'm going to do it if he doesn't get around to > it. > > As for default algorithm, is there any reason not to make it 4? Yes, it's expensive both computation time and stack wise. Last I put MD5ctxs on the stack I was told that it was previously avoided do to stack limits. I haven't seen complaints on lists about it but it possibly still true for small embedded. I'd also like to see a proper benchmark before switching the default on both state of the art and a soekris kind class of machine. That said I messed with the patch to avoid the two copies of the algorithms (so it will not be 4 soon). I know it compiles but I have yet to test it. I'd love to hear opinions. The #ifdef INET6/INETs are ugly but we'll see those a lot more and need to figure out differnt ways to our code was written the last 10 years. http://people.freebsd.org/~bz/20110303-01-rfc6056.diff The patch also includes a bugfix for the ipv6 case wrt to "un-binding" on error. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 00:39:38 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 0671F106566B; Sat, 5 Mar 2011 00:39:38 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 22AA41624C8; Sat, 5 Mar 2011 00:39:37 +0000 (UTC) Message-ID: <4D718648.801@FreeBSD.org> Date: Fri, 04 Mar 2011 16:39:36 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.14) Gecko/20110301 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> <4D437B13.1070405@FreeBSD.org> <4D518FB3.3040503@FreeBSD.org> <4D6AB2BD.50208@gont.com.ar> <4D6AB636.3030708@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Ivo Vachkov Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 00:39:38 -0000 On 03/04/2011 16:21, Bjoern A. Zeeb wrote: > On Sun, 27 Feb 2011, Doug Barton wrote: >> As for default algorithm, is there any reason not to make it 4? > > Yes, it's expensive both computation time and stack wise. Last I put > MD5ctxs on the stack I was told that it was previously avoided do to > stack limits. I haven't seen complaints on lists about it but it > possibly still true for small embedded. > > I'd also like to see a proper benchmark before switching the default > on both state of the art and a soekris kind class of machine. We expect people doing embedded work to make all kinds of adjustments, I can't see any reason why this shouldn't be one of them. Modern general-purpose machines have more than enough resources to handle this. That said, maybe we need a knob like EMBEDDED to more easily handle some of these issues. I could see an default of alg 4 but something less computationally intensive ifdef EMBEDDED. > That said I messed with the patch to avoid the two copies of the > algorithms (so it will not be 4 soon). I know it compiles but I have > yet to test it. I'd love to hear opinions. The #ifdef INET6/INETs > are ugly but we'll see those a lot more and need to figure out > differnt ways to our code was written the last 10 years. > > http://people.freebsd.org/~bz/20110303-01-rfc6056.diff > > The patch also includes a bugfix for the ipv6 case wrt to > "un-binding" on error. Cool! I'll try to test this new patch this weekend. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 09:35:42 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E259F1065674; Sat, 5 Mar 2011 09:35:42 +0000 (UTC) (envelope-from murankar@iut-mir-o.ujf-grenoble.fr) Received: from amazone2.ujf-grenoble.fr (amazone2.ujf-grenoble.fr [152.77.2.202]) by mx1.freebsd.org (Postfix) with ESMTP id 6FA658FC15; Sat, 5 Mar 2011 09:35:42 +0000 (UTC) Received: from tana4.ujf-grenoble.fr (tana4.ujf-grenoble.fr [152.77.18.233]) by amazone2.ujf-grenoble.fr (8.13.7/8.13.7/Configured by JE/GB 2010-12-10) with ESMTP id p258jNrC059398; Sat, 5 Mar 2011 09:45:23 +0100 (CET) Received: from tana4.ujf-grenoble.fr (unknown [127.0.0.1]) by tana4.ujf-grenoble.fr (Postfix) with ESMTP id 44AD72E01A; Sat, 5 Mar 2011 09:45:23 +0100 (CET) X-UJF-AV: Scanned on tana4.ujf-grenoble.fr Received: from tibre2.ujf-grenoble.fr (tibre2.ujf-grenoble.fr [152.77.18.251]) by tana4.ujf-grenoble.fr (Postfix) with ESMTP id 2570E2E004; Sat, 5 Mar 2011 09:45:23 +0100 (CET) Received: from iut-mir-o.ujf-grenoble.fr (iut-mir-o.ujf-grenoble.fr [152.77.59.35]) by tibre2.ujf-grenoble.fr (8.14.3/8.14.3/SyS-1.10) with ESMTP id p258jL3w011080; Sat, 5 Mar 2011 09:45:23 +0100 (CET) (envelope-from murankar@iut-mir-o.ujf-grenoble.fr) Received: from iut-mir-o.ujf-grenoble.fr (localhost [127.0.0.1]) by iut-mir-o.ujf-grenoble.fr (8.14.4/8.14.4) with ESMTP id p258jKwu069360; Sat, 5 Mar 2011 09:45:20 +0100 (CET) (envelope-from murankar@iut-mir-o.ujf-grenoble.fr) Received: (from murankar@localhost) by iut-mir-o.ujf-grenoble.fr (8.14.4/8.14.4/Submit) id p258jKLL069359; Sat, 5 Mar 2011 09:45:20 +0100 (CET) (envelope-from murankar) Date: Sat, 5 Mar 2011 09:45:20 +0100 From: Urankar Mikael To: Adrian Chadd Message-ID: <20110305084520.GB2833@iut-mir-o.ujf-grenoble.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , freebsd-current , freebsd-mobile@freebsd.org Subject: Re: please (re) test if_ath in -HEAD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 09:35:43 -0000 On Thu 03 March 2011 at 02:31:05PM -0800, Adrian Chadd wrote: > Hi all, > > For those of you who are testing out my if_ath changes, I'd really > appreciate it if you'd update to -HEAD and re-test. > > I've done a variety of changes to the radio setup and found/fixed a few bugs > in the TX path. It's quite possible these have introduced regressions. I'd > like to make sure that I haven't broken legacy (11abg) support in > weird/wonderful ways. I'd also like to make sure that I haven't > broken/changed the behaviour or performance of the NICs in any way. > > Please give things a good thrashing and let me know the results. > > I'm still working towards debugging and enabling basic 11n support, but I > need to first make sure that I haven't broken legacy operation in any way. > Are you interested by tests on an old atheros card (Atheros 5212, AR2413 mac 7.9 RF2413 phy 4.5) ? From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 10:03:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76E7B1065670; Sat, 5 Mar 2011 10:03:40 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 279C68FC0C; Sat, 5 Mar 2011 10:03:39 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id F222F13DF42; Sat, 5 Mar 2011 13:03:37 +0300 (MSK) Date: Sat, 5 Mar 2011 13:03:20 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <494278763.20110305130320@serebryakov.spb.ru> To: "Steven Hartland" In-Reply-To: <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> References: <1975926365.20110223121637@serebryakov.spb.ru><4D64EC8C.2080007@sentex.net><1004451940.20110223143607@serebryakov.spb.ru><4D6D00C1.1040805@sentex.net><1416421652.20110301225215@serebryakov.spb.ru><1627628072.20110303111046@serebryakov.spb.ru> <1894628540.20110304012554@serebryakov.spb.ru> <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Brandon Gooch , freebsd-net@freebsd.org, Jan Koum , Jack Vogel , Arnaud Lacombe Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 10:03:40 -0000 Hello, Steven. You wrote 5 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2011 =D0=B3., 3:06:32: > Silly question but have you checked your ram for issues, we had a machine > with seemingly unexplained problems and hangs and it turned out to be > a duff stick of ram which wasn't being chip killed. Yes, two full days (48h) of memtest86+ -- no problems... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 11:27:49 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40E811065676; Sat, 5 Mar 2011 11:27:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C58408FC20; Sat, 5 Mar 2011 11:27:48 +0000 (UTC) Received: by vws16 with SMTP id 16so3131530vws.13 for ; Sat, 05 Mar 2011 03:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yLxFyOUbfjP7mHwCG8EweVs68wmLNSrDj+fz7/vA+Aw=; b=AwK5VioqfRnMu4gLlYYpP26HR2Y1bKEnfxeITVN918Jk3CkTM5osGp6ctwrYtUgVyg tk9eh/5lpdoAyh1ixPAtnX8VjrZvVxRYzQwZSSekjOd+4XpXPF+x25CQp52rOKfDOrDo 9uiak1LkmhsQyWbnVpfqe/Ap5oM6fk0sa5L+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kusyuVdpFzsvEs7Lq9PWWcX2Yukr3s7gScWKTZFbodTx4zv7WMOOzcN2KgumllPH++ fhxRzZkpnNKdcLs/3l/pvoLSkC3PfZIn70VQl5w2Nl4JReedrgQ7wIHDAZd/YWSJcXXq 7e2VcRFHnJNja7w5/GWnBmJmgLLHK7NB6deys= MIME-Version: 1.0 Received: by 10.52.0.9 with SMTP id 9mr2484715vda.147.1299324468085; Sat, 05 Mar 2011 03:27:48 -0800 (PST) Received: by 10.52.167.3 with HTTP; Sat, 5 Mar 2011 03:27:48 -0800 (PST) In-Reply-To: <20110305084520.GB2833@iut-mir-o.ujf-grenoble.fr> References: <20110305084520.GB2833@iut-mir-o.ujf-grenoble.fr> Date: Sat, 5 Mar 2011 03:27:48 -0800 Message-ID: From: Adrian Chadd To: Urankar Mikael Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , freebsd-current , freebsd-mobile@freebsd.org Subject: Re: please (re) test if_ath in -HEAD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 11:27:49 -0000 Absolutely! Let me know if I've broken anything! Adrian On 5 March 2011 00:45, Urankar Mikael wrote: > On Thu 03 March 2011 at 02:31:05PM -0800, Adrian Chadd wrote: > > Hi all, > > > > For those of you who are testing out my if_ath changes, I'd really > > appreciate it if you'd update to -HEAD and re-test. > > > > I've done a variety of changes to the radio setup and found/fixed a few > bugs > > in the TX path. It's quite possible these have introduced regressions. > I'd > > like to make sure that I haven't broken legacy (11abg) support in > > weird/wonderful ways. I'd also like to make sure that I haven't > > broken/changed the behaviour or performance of the NICs in any way. > > > > Please give things a good thrashing and let me know the results. > > > > I'm still working towards debugging and enabling basic 11n support, but I > > need to first make sure that I haven't broken legacy operation in any > way. > > > > Are you interested by tests on an old atheros card (Atheros 5212, AR2413 > mac 7.9 RF2413 phy 4.5) ? > From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 13:20:13 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CF13106564A for ; Sat, 5 Mar 2011 13:20:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E5CE38FC0A for ; Sat, 5 Mar 2011 13:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p25DKCbk016431 for ; Sat, 5 Mar 2011 13:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p25DKCcr016429; Sat, 5 Mar 2011 13:20:12 GMT (envelope-from gnats) Date: Sat, 5 Mar 2011 13:20:12 GMT Message-Id: <201103051320.p25DKCcr016429@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Luiz Otavio O Souza Cc: Subject: Re: kern/155177: [route] [panic] Panic when inject routes in kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Luiz Otavio O Souza List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 13:20:13 -0000 The following reply was made to PR kern/155177; it has been noted by GNATS. From: Luiz Otavio O Souza To: Eduardo Schoedler Cc: , freebsd-net@FreeBSD.org Subject: Re: kern/155177: [route] [panic] Panic when inject routes in kernel Date: Sat, 5 Mar 2011 10:18:56 -0300 --Apple-Mail-135-1048872824 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 4, 2011, at 9:10 AM, Eduardo Schoedler wrote: > Hello, >=20 > I've found another (easy) way to reproduce the problem with two = scripts: > routes-add.sh and routes-remove.sh. > First run routes-add.sh for a while; then execute routes-remove.sh. > Cancel with CTRL+C and execute routes-remove.sh again. >=20 Hi Eduardo, I've found another problem while trying something like you'd proposed, = but it can be easily reproduced by just trying to remove a network route = that is not in the table (probably what your script does when you press = ctrl+c and restart it). The problem i've found produces the following backtrace: #0 doadump () at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:244 #1 0xc04d7de9 in db_fncall (dummy1=3D1, dummy2=3D0, dummy3=3D-1056933504,= =20 dummy4=3D0xe69ee798 "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04d81e1 in db_command (last_cmdp=3D0xc0e303dc, cmd_table=3D0x0, = dopager=3D1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04d833a in db_command_loop () at = /usr/src/sys/ddb/db_command.c:498 #4 0xc04da25d in db_trap (type=3D3, code=3D0) at = /usr/src/sys/ddb/db_main.c:229 #5 0xc0902672 in kdb_trap (type=3D3, code=3D0, tf=3D0xe69ee948) at /usr/src/sys/kern/subr_kdb.c:533 #6 0xc0c137bb in trap (frame=3D0xe69ee948) at = /usr/src/sys/i386/i386/trap.c:717 #7 0xc0bfc7ec in calltrap () at /usr/src/sys/i386/i386/exception.s:168 #8 0xc09024fa in kdb_enter (why=3D0xc0ce86fa "panic", msg=3D0xc0ce86fa = "panic") at cpufunc.h:71 #9 0xc08cea24 in panic (fmt=3D0xc0cfedcb "radix node disappeared") at /usr/src/sys/kern/kern_shutdown.c:574 #10 0xc0996900 in rtrequest1_fib (req=3D2, info=3D0xe69eea50, = ret_nrt=3D0xe69eea84,=20 fibnum=3DVariable "fibnum" is not available. ) at /usr/src/sys/net/route.c:968 #11 0xc099abbd in route_output (m=3D0xc43a6b00, so=3D0xc48b0000) at /usr/src/sys/net/rtsock.c:630 #12 0xc09959da in raw_usend (so=3D0xc48b0000, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/net/raw_usrreq.c:228 #13 0xc0999275 in rts_send (so=3D0xc48b0000, flags=3D0, m=3D0xc43a6b00, = nam=3D0x0,=20 control=3D0x0, td=3D0xc49d18a0) at /usr/src/sys/net/rtsock.c:354 #14 0xc093ceed in sosend_generic (so=3D0xc48b0000, addr=3D0x0, = uio=3D0xe69eec28,=20 top=3D0xc43a6b00, control=3D0x0, flags=3D0, td=3D0xc49d18a0) at /usr/src/sys/kern/uipc_socket.c:1301 #15 0xc0938ddf in sosend (so=3D0xc48b0000, addr=3D0x0, uio=3D0xe69eec28, = top=3D0x0,=20 control=3D0x0, flags=3D0, td=3D0xc49d18a0) at /usr/src/sys/kern/uipc_socket.c:1345 #16 0xc0920ae3 in soo_write (fp=3D0xc4690d58, uio=3D0xe69eec28,=20 active_cred=3D0xc47e8e00, flags=3D0, td=3D0xc49d18a0) at /usr/src/sys/kern/sys_socket.c:100 #17 0xc0919a65 in dofilewrite (td=3D0xc49d18a0, fd=3D3, fp=3D0xc4690d58,=20= auio=3D0xe69eec28, offset=3D-1, flags=3D0) at file.h:238 #18 0xc091b208 in kern_writev (td=3D0xc49d18a0, fd=3D3, auio=3D0xe69eec28)= at /usr/src/sys/kern/sys_generic.c:447 #19 0xc091b31f in write (td=3D0xc49d18a0, uap=3D0xe69eecec) at /usr/src/sys/kern/sys_generic.c:363 #20 0xc090fda3 in syscallenter (td=3D0xc49d18a0, sa=3D0xe69eece4) at /usr/src/sys/kern/subr_trap.c:344 #21 0xc0c13064 in syscall (frame=3D0xe69eed28) at /usr/src/sys/i386/i386/trap.c:1080 #22 0xc0bfc851 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 #23 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 Are you sure that your scripts produce the backtrace you'd posted ? I = cannot reproduce that here... Well, about the problem i've found ("radix node disappeared") when = removing a nonexistent route (route delete x.y.w.z/24 - where x.y.w.z/24 = is _not_ in the route table), it was related to the code that check for = a gateway when there are multiple gateways for a route, which clearly = was not the case. After some thought i've crafted the following patch which fix the "radix = node disappeared" problem (for me obviously...), can you try your = scripts with this patch ? Not sure yet if this is related to the first = problem you'd reported. Thanks, Luiz --Apple-Mail-135-1048872824 Content-Disposition: attachment; filename=radix_remove_gateway.diff Content-Type: application/octet-stream; name="radix_remove_gateway.diff" Content-Transfer-Encoding: 7bit Index: sys/net/route.c =================================================================== --- sys/net/route.c (revision 219261) +++ sys/net/route.c (working copy) @@ -946,7 +946,7 @@ RT_LOCK(rto); rto->rt_flags |= RTF_UP; RT_UNLOCK(rto); - } else if (rt->rt_flags & RTF_GATEWAY) { + } else if (gateway && rt->rt_flags & RTF_GATEWAY) { /* * For gateway routes, we need to * make sure that we we are deleting @@ -955,9 +955,8 @@ * check the case when there is only * one route in the chain. */ - if (gateway && - (rt->rt_gateway->sa_len != gateway->sa_len || - memcmp(rt->rt_gateway, gateway, gateway->sa_len))) + if (rt->rt_gateway->sa_len != gateway->sa_len || + memcmp(rt->rt_gateway, gateway, gateway->sa_len)) error = ESRCH; else { /* @@ -1002,7 +1001,6 @@ nondelete: if (req != RTM_DELETE) panic("unrecognized request %d", req); - /* * If the caller wants it, then it can have it, --Apple-Mail-135-1048872824 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > > > Backtrace: > ========== > > # cat /var/crash/core.txt.1 > > Unread portion of the kernel message buffer: > panic: rtfree 2 > cpuid = 4 > KDB: stack backtrace: > #0 0xffffffff80416e43 at kdb_backtrace+0x5e > #1 0xffffffff803e68a8 at panic+0x182 > #2 0xffffffff804b2274 at rtalloc1_fib+0 > #3 0xffffffff804b5b92 at route_output+0x304 > #4 0xffffffff8044b776 at sosend_generic+0x366 > #5 0xffffffff8042cd5c at soo_write+0x54 > #6 0xffffffff80425bee at dofilewrite+0x7a > #7 0xffffffff80425ec1 at kern_writev+0x52 > #8 0xffffffff80425f3f at write+0x4e > #9 0xffffffff80422408 at syscallenter+0x186 > #10 0xffffffff8065b4f7 at syscall+0x40 > #11 0xffffffff806449f2 at Xfast_syscall+0xe2 > Uptime: 37m16s > Physical memory: 4084 MB > Dumping 497 MB:VOP_STRATEGY: bp is not locked but should be > 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 > 178 162 146 130 114 98 82 66 50 34 18 2 > > #0 doadump () at pcpu.h:224 > 224 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:224 > #1 0xffffffff803e6425 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:419 > #2 0xffffffff803e6892 in panic (fmt=Variable "fmt" is not available. > ) > at /usr/src/sys/kern/kern_shutdown.c:592 > #3 0xffffffff804b2274 in rtfree (rt=Variable "rt" is not available. > ) at /usr/src/sys/net/route.c:446 > #4 0xffffffff804b5b92 in route_output (m=0xffffff0004790700, > so=0xffffff00b07ead48) at /usr/src/sys/net/rtsock.c:863 > #5 0xffffffff8044b776 in sosend_generic (so=0xffffff00b07ead48, addr=0x0, > uio=0xffffff830ff98a90, top=0xffffff0004790700, control=0x0, flags=0, > td=0xffffff0004a13000) at /usr/src/sys/kern/uipc_socket.c:1260 > #6 0xffffffff8042cd5c in soo_write (fp=Variable "fp" is not available. > ) > at /usr/src/sys/kern/sys_socket.c:102 > #7 0xffffffff80425bee in dofilewrite (td=0xffffff0004a13000, fd=3, > fp=0xffffff0004977af0, auio=0xffffff830ff98a90, offset=Variable "offset" > is not available. > ) at file.h:239 > #8 0xffffffff80425ec1 in kern_writev (td=0xffffff0004a13000, fd=3, > auio=0xffffff830ff98a90) at /usr/src/sys/kern/sys_generic.c:447 > #9 0xffffffff80425f3f in write (td=Variable "td" is not available. > ) at /usr/src/sys/kern/sys_generic.c:363 > #10 0xffffffff80422408 in syscallenter (td=0xffffff0004a13000, > sa=0xffffff830ff98ba0) at /usr/src/sys/kern/subr_trap.c:315 > #11 0xffffffff8065b4f7 in syscall (frame=0xffffff830ff98c40) > at /usr/src/sys/amd64/amd64/trap.c:944 > #12 0xffffffff806449f2 in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:381 > #13 0x0000000800735afc in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > > Again, removing RADIX_MPATH from kernel, it's working fine. > > > Regards, > > -- > Eduardo Schoedler --Apple-Mail-135-1048872824-- From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 13:31:01 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F089106564A; Sat, 5 Mar 2011 13:31:01 +0000 (UTC) (envelope-from marcelorossi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 930328FC17; Sat, 5 Mar 2011 13:31:00 +0000 (UTC) Received: by wyb32 with SMTP id 32so3432306wyb.13 for ; Sat, 05 Mar 2011 05:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=onDCranKHa0AD9oPIxaumb4odJ9BUevY0QQv8MP2AZY=; b=jBdBTU9hpW+QHySB5jx+E4MO5Gy5q6+xnGTZJtR+9MfGhNZUHyz2Av+pxnAhGGX1NX Sdcv5/YDPaW2R9bpfQbIZzL7POUel/PJoXmdyH4p3fNnMeAp7Z26bFl8pLWy6wbe9BhL VWJPnsv01TEq6zQecwymyAs9DnpkrF7OqevZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=FsuUb9N4+S/YK0XTIl9GxlLhvpv63zFhtaMuOw6KS4GGD+Z2IHnatk9qeWgV3t+8cA FH7WUEThvvKzOAXTNlIROi7gwoHjRasTBZCq/hqxhgGxfupqbq5M9Ky6QUjB00SfOemH u+9QXLgcyjQX0J/5MPHx/UE8j5IDsgf1Q4QhE= Received: by 10.217.2.73 with SMTP id o51mr450836wes.66.1299330229164; Sat, 05 Mar 2011 05:03:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.217.3.12 with HTTP; Sat, 5 Mar 2011 05:03:09 -0800 (PST) In-Reply-To: References: From: "Marcelo/Porks" Date: Sat, 5 Mar 2011 10:03:09 -0300 Message-ID: To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-current , freebsd-mobile@freebsd.org Subject: Re: please (re) test if_ath in -HEAD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 13:31:01 -0000 On Thu, Mar 3, 2011 at 19:31, Adrian Chadd wrote: > Hi all, > > For those of you who are testing out my if_ath changes, I'd really > appreciate it if you'd update to -HEAD and re-test. > > I've done a variety of changes to the radio setup and found/fixed a few bugs > in the TX path. It's quite possible these have introduced regressions. I'd > like to make sure that I haven't broken legacy (11abg) support in > weird/wonderful ways. I'd also like to make sure that I haven't > broken/changed the behaviour or performance of the NICs in any way. > > Please give things a good thrashing and let me know the results. > > I'm still working towards debugging and enabling basic 11n support, but I > need to first make sure that I haven't broken legacy operation in any way. Hi Adrian. I compiled your changes and everything worked. I'm using hostapd with WEP key. My kernel/world is compiled with clang. Is there any kind of test that I can do for you? There is still a annoying message, but it existed before your update: ath0: stuck beacon; resetting (bmiss count 4) ----------------- BARAD-DUR# uname -a FreeBSD BARAD-DUR 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r219303: Sat Mar 5 09:16:19 BRT 2011 root@BARAD-DUR:/usr/clang/obj/mnt/data/system/src/sys/GENERIC amd64 BARAD-DUR# dmesg| grep -i ath ath0: mem 0xfd8f0000-0xfd8fffff irq 16 at device 7.0 on pci1 ath0: AR2413 mac 7.9 RF2413 phy 4.5 ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) BARAD-DUR# ifconfig ath0 ath0: flags=8843 metric 0 mtu 2290 ether 00:19:e0:8a:0a:d6 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running > Thanks, > > > Adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Marcelo Rossi "This e-mail is provided "AS IS" with no warranties, and confers no rights." "I have nothing against God, I just hate His fan club" From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 13:47:02 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1820B106566B for ; Sat, 5 Mar 2011 13:47:02 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id B8D108FC12 for ; Sat, 5 Mar 2011 13:47:01 +0000 (UTC) Received: by ywf9 with SMTP id 9so1232014ywf.13 for ; Sat, 05 Mar 2011 05:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=V7WMOhEURewNj4KhcO/73J+J8C1WWa8s9TikfgY1OIM=; b=hgzx9RTgHsjD93PsdvCK7Mqu88zks7zdPRrYrLtfWtrPzCSqcU7bC/ypqDPIFJsZWc WS9JkEk1Ok3amRumnc2SL431raXemSpbEG9S08jG6ChHAEr+93U27ZADfVPNgUK6m8Iu EvrLP7qfpK6VxuWWDOEoa6fMCxoWD3EG4uar8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=gmLxPWbjUgOAJqc4/fTlPMhl3O08hHjQTDUq5D++IJSW+qR2hXsSHhdyBf8gTppvl2 NjSoo/Wduua3W2jMIht6aiV6drcxuldop5xntgQJF+bAvgIaEbRoXLBAV0wMD4kCSzT3 mAXMu/d2epSGBDfUdwoiSA2Xk9qCDeh8x+gI0= Received: by 10.101.200.18 with SMTP id c18mr319616anq.176.1299331141699; Sat, 05 Mar 2011 05:19:01 -0800 (PST) Received: from [192.168.0.84] ([187.39.27.246]) by mx.google.com with ESMTPS id c28sm771998ana.1.2011.03.05.05.18.59 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Mar 2011 05:19:00 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/mixed; boundary=Apple-Mail-135-1048872824 From: Luiz Otavio O Souza In-Reply-To: Date: Sat, 5 Mar 2011 10:18:56 -0300 Message-Id: References: To: Eduardo Schoedler X-Mailer: Apple Mail (2.1082) Cc: freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/155177: [route] [panic] Panic when inject routes in kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 13:47:02 -0000 --Apple-Mail-135-1048872824 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 4, 2011, at 9:10 AM, Eduardo Schoedler wrote: > Hello, >=20 > I've found another (easy) way to reproduce the problem with two = scripts: > routes-add.sh and routes-remove.sh. > First run routes-add.sh for a while; then execute routes-remove.sh. > Cancel with CTRL+C and execute routes-remove.sh again. >=20 Hi Eduardo, I've found another problem while trying something like you'd proposed, = but it can be easily reproduced by just trying to remove a network route = that is not in the table (probably what your script does when you press = ctrl+c and restart it). The problem i've found produces the following backtrace: #0 doadump () at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:244 #1 0xc04d7de9 in db_fncall (dummy1=3D1, dummy2=3D0, dummy3=3D-1056933504,= =20 dummy4=3D0xe69ee798 "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04d81e1 in db_command (last_cmdp=3D0xc0e303dc, cmd_table=3D0x0, = dopager=3D1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04d833a in db_command_loop () at = /usr/src/sys/ddb/db_command.c:498 #4 0xc04da25d in db_trap (type=3D3, code=3D0) at = /usr/src/sys/ddb/db_main.c:229 #5 0xc0902672 in kdb_trap (type=3D3, code=3D0, tf=3D0xe69ee948) at /usr/src/sys/kern/subr_kdb.c:533 #6 0xc0c137bb in trap (frame=3D0xe69ee948) at = /usr/src/sys/i386/i386/trap.c:717 #7 0xc0bfc7ec in calltrap () at /usr/src/sys/i386/i386/exception.s:168 #8 0xc09024fa in kdb_enter (why=3D0xc0ce86fa "panic", msg=3D0xc0ce86fa = "panic") at cpufunc.h:71 #9 0xc08cea24 in panic (fmt=3D0xc0cfedcb "radix node disappeared") at /usr/src/sys/kern/kern_shutdown.c:574 #10 0xc0996900 in rtrequest1_fib (req=3D2, info=3D0xe69eea50, = ret_nrt=3D0xe69eea84,=20 fibnum=3DVariable "fibnum" is not available. ) at /usr/src/sys/net/route.c:968 #11 0xc099abbd in route_output (m=3D0xc43a6b00, so=3D0xc48b0000) at /usr/src/sys/net/rtsock.c:630 #12 0xc09959da in raw_usend (so=3D0xc48b0000, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/net/raw_usrreq.c:228 #13 0xc0999275 in rts_send (so=3D0xc48b0000, flags=3D0, m=3D0xc43a6b00, = nam=3D0x0,=20 control=3D0x0, td=3D0xc49d18a0) at /usr/src/sys/net/rtsock.c:354 #14 0xc093ceed in sosend_generic (so=3D0xc48b0000, addr=3D0x0, = uio=3D0xe69eec28,=20 top=3D0xc43a6b00, control=3D0x0, flags=3D0, td=3D0xc49d18a0) at /usr/src/sys/kern/uipc_socket.c:1301 #15 0xc0938ddf in sosend (so=3D0xc48b0000, addr=3D0x0, uio=3D0xe69eec28, = top=3D0x0,=20 control=3D0x0, flags=3D0, td=3D0xc49d18a0) at /usr/src/sys/kern/uipc_socket.c:1345 #16 0xc0920ae3 in soo_write (fp=3D0xc4690d58, uio=3D0xe69eec28,=20 active_cred=3D0xc47e8e00, flags=3D0, td=3D0xc49d18a0) at /usr/src/sys/kern/sys_socket.c:100 #17 0xc0919a65 in dofilewrite (td=3D0xc49d18a0, fd=3D3, fp=3D0xc4690d58,=20= auio=3D0xe69eec28, offset=3D-1, flags=3D0) at file.h:238 #18 0xc091b208 in kern_writev (td=3D0xc49d18a0, fd=3D3, auio=3D0xe69eec28)= at /usr/src/sys/kern/sys_generic.c:447 #19 0xc091b31f in write (td=3D0xc49d18a0, uap=3D0xe69eecec) at /usr/src/sys/kern/sys_generic.c:363 #20 0xc090fda3 in syscallenter (td=3D0xc49d18a0, sa=3D0xe69eece4) at /usr/src/sys/kern/subr_trap.c:344 #21 0xc0c13064 in syscall (frame=3D0xe69eed28) at /usr/src/sys/i386/i386/trap.c:1080 #22 0xc0bfc851 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 #23 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 Are you sure that your scripts produce the backtrace you'd posted ? I = cannot reproduce that here... Well, about the problem i've found ("radix node disappeared") when = removing a nonexistent route (route delete x.y.w.z/24 - where x.y.w.z/24 = is _not_ in the route table), it was related to the code that check for = a gateway when there are multiple gateways for a route, which clearly = was not the case. After some thought i've crafted the following patch which fix the "radix = node disappeared" problem (for me obviously...), can you try your = scripts with this patch ? Not sure yet if this is related to the first = problem you'd reported. Thanks, Luiz --Apple-Mail-135-1048872824 Content-Disposition: attachment; filename=radix_remove_gateway.diff Content-Type: application/octet-stream; name="radix_remove_gateway.diff" Content-Transfer-Encoding: 7bit Index: sys/net/route.c =================================================================== --- sys/net/route.c (revision 219261) +++ sys/net/route.c (working copy) @@ -946,7 +946,7 @@ RT_LOCK(rto); rto->rt_flags |= RTF_UP; RT_UNLOCK(rto); - } else if (rt->rt_flags & RTF_GATEWAY) { + } else if (gateway && rt->rt_flags & RTF_GATEWAY) { /* * For gateway routes, we need to * make sure that we we are deleting @@ -955,9 +955,8 @@ * check the case when there is only * one route in the chain. */ - if (gateway && - (rt->rt_gateway->sa_len != gateway->sa_len || - memcmp(rt->rt_gateway, gateway, gateway->sa_len))) + if (rt->rt_gateway->sa_len != gateway->sa_len || + memcmp(rt->rt_gateway, gateway, gateway->sa_len)) error = ESRCH; else { /* @@ -1002,7 +1001,6 @@ nondelete: if (req != RTM_DELETE) panic("unrecognized request %d", req); - /* * If the caller wants it, then it can have it, --Apple-Mail-135-1048872824 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > > > Backtrace: > ========== > > # cat /var/crash/core.txt.1 > > Unread portion of the kernel message buffer: > panic: rtfree 2 > cpuid = 4 > KDB: stack backtrace: > #0 0xffffffff80416e43 at kdb_backtrace+0x5e > #1 0xffffffff803e68a8 at panic+0x182 > #2 0xffffffff804b2274 at rtalloc1_fib+0 > #3 0xffffffff804b5b92 at route_output+0x304 > #4 0xffffffff8044b776 at sosend_generic+0x366 > #5 0xffffffff8042cd5c at soo_write+0x54 > #6 0xffffffff80425bee at dofilewrite+0x7a > #7 0xffffffff80425ec1 at kern_writev+0x52 > #8 0xffffffff80425f3f at write+0x4e > #9 0xffffffff80422408 at syscallenter+0x186 > #10 0xffffffff8065b4f7 at syscall+0x40 > #11 0xffffffff806449f2 at Xfast_syscall+0xe2 > Uptime: 37m16s > Physical memory: 4084 MB > Dumping 497 MB:VOP_STRATEGY: bp is not locked but should be > 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 > 178 162 146 130 114 98 82 66 50 34 18 2 > > #0 doadump () at pcpu.h:224 > 224 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:224 > #1 0xffffffff803e6425 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:419 > #2 0xffffffff803e6892 in panic (fmt=Variable "fmt" is not available. > ) > at /usr/src/sys/kern/kern_shutdown.c:592 > #3 0xffffffff804b2274 in rtfree (rt=Variable "rt" is not available. > ) at /usr/src/sys/net/route.c:446 > #4 0xffffffff804b5b92 in route_output (m=0xffffff0004790700, > so=0xffffff00b07ead48) at /usr/src/sys/net/rtsock.c:863 > #5 0xffffffff8044b776 in sosend_generic (so=0xffffff00b07ead48, addr=0x0, > uio=0xffffff830ff98a90, top=0xffffff0004790700, control=0x0, flags=0, > td=0xffffff0004a13000) at /usr/src/sys/kern/uipc_socket.c:1260 > #6 0xffffffff8042cd5c in soo_write (fp=Variable "fp" is not available. > ) > at /usr/src/sys/kern/sys_socket.c:102 > #7 0xffffffff80425bee in dofilewrite (td=0xffffff0004a13000, fd=3, > fp=0xffffff0004977af0, auio=0xffffff830ff98a90, offset=Variable "offset" > is not available. > ) at file.h:239 > #8 0xffffffff80425ec1 in kern_writev (td=0xffffff0004a13000, fd=3, > auio=0xffffff830ff98a90) at /usr/src/sys/kern/sys_generic.c:447 > #9 0xffffffff80425f3f in write (td=Variable "td" is not available. > ) at /usr/src/sys/kern/sys_generic.c:363 > #10 0xffffffff80422408 in syscallenter (td=0xffffff0004a13000, > sa=0xffffff830ff98ba0) at /usr/src/sys/kern/subr_trap.c:315 > #11 0xffffffff8065b4f7 in syscall (frame=0xffffff830ff98c40) > at /usr/src/sys/amd64/amd64/trap.c:944 > #12 0xffffffff806449f2 in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:381 > #13 0x0000000800735afc in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > > Again, removing RADIX_MPATH from kernel, it's working fine. > > > Regards, > > -- > Eduardo Schoedler --Apple-Mail-135-1048872824-- From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 16:30:39 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 454AC1065673; Sat, 5 Mar 2011 16:30:39 +0000 (UTC) (envelope-from murankar@iut-mir-o.ujf-grenoble.fr) Received: from amazone2.ujf-grenoble.fr (amazone2.ujf-grenoble.fr [152.77.2.202]) by mx1.freebsd.org (Postfix) with ESMTP id AB3D88FC08; Sat, 5 Mar 2011 16:30:38 +0000 (UTC) Received: from tana1.ujf-grenoble.fr (tana1.ujf-grenoble.fr [152.77.24.147]) by amazone2.ujf-grenoble.fr (8.13.7/8.13.7/Configured by JE/GB 2010-12-10) with ESMTP id p25GUbM9069101; Sat, 5 Mar 2011 17:30:37 +0100 (CET) Received: from tana1.ujf-grenoble.fr (unknown [127.0.0.1]) by tana1.ujf-grenoble.fr (Postfix) with ESMTP id 6FDE62E030; Sat, 5 Mar 2011 17:30:37 +0100 (CET) X-UJF-AV: Scanned on tana1.ujf-grenoble.fr Received: from tibre2.ujf-grenoble.fr (tibre2.ujf-grenoble.fr [152.77.18.251]) by tana1.ujf-grenoble.fr (Postfix) with ESMTP id 3DEBB2E002; Sat, 5 Mar 2011 17:30:37 +0100 (CET) Received: from iut-mir-o.ujf-grenoble.fr (iut-mir-o.ujf-grenoble.fr [152.77.59.35]) by tibre2.ujf-grenoble.fr (8.14.3/8.14.3/SyS-1.10) with ESMTP id p25GUZWg014470; Sat, 5 Mar 2011 17:30:37 +0100 (CET) (envelope-from murankar@iut-mir-o.ujf-grenoble.fr) Received: from iut-mir-o.ujf-grenoble.fr (localhost [127.0.0.1]) by iut-mir-o.ujf-grenoble.fr (8.14.4/8.14.4) with ESMTP id p25GUZVs074574; Sat, 5 Mar 2011 17:30:35 +0100 (CET) (envelope-from murankar@iut-mir-o.ujf-grenoble.fr) Received: (from murankar@localhost) by iut-mir-o.ujf-grenoble.fr (8.14.4/8.14.4/Submit) id p25GUYRA074573; Sat, 5 Mar 2011 17:30:34 +0100 (CET) (envelope-from murankar) Date: Sat, 5 Mar 2011 17:30:34 +0100 From: Urankar Mikael To: freebsd-mobile@freebsd.org, FreeBSD Net , freebsd-current Message-ID: <20110305163034.GD2833@iut-mir-o.ujf-grenoble.fr> References: <20110305084520.GB2833@iut-mir-o.ujf-grenoble.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: please (re) test if_ath in -HEAD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 16:30:39 -0000 On Sat 05 March 2011 at 03:27:48AM -0800, Adrian Chadd wrote: > Absolutely! Let me know if I've broken anything! > > Adrian > > On 5 March 2011 00:45, Urankar Mikael wrote: > > > On Thu 03 March 2011 at 02:31:05PM -0800, Adrian Chadd wrote: > > > Hi all, > > > > > > For those of you who are testing out my if_ath changes, I'd really > > > appreciate it if you'd update to -HEAD and re-test. > > > > > > I've done a variety of changes to the radio setup and found/fixed a few > > bugs > > > in the TX path. It's quite possible these have introduced regressions. > > I'd > > > like to make sure that I haven't broken legacy (11abg) support in > > > weird/wonderful ways. I'd also like to make sure that I haven't > > > broken/changed the behaviour or performance of the NICs in any way. > > > > > > Please give things a good thrashing and let me know the results. > > > > > > I'm still working towards debugging and enabling basic 11n support, but I > > > need to first make sure that I haven't broken legacy operation in any > > way. > > > > > > > Are you interested by tests on an old atheros card (Atheros 5212, AR2413 > > mac 7.9 RF2413 phy 4.5) ? > > Everything seems to work fine, performances are as good as before. I'm only doing basic stuff with this card (mostly web surfing), I'm connected to an AP with WPA encryption. If you want me to test other encryption or setup an AP with this card or whatever, feel free to ask. And thanks for you work ! From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 19:18:10 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39749106564A for ; Sat, 5 Mar 2011 19:18:10 +0000 (UTC) (envelope-from fredan@fredan.se) Received: from mail.fredan.se (mail.fredan.se [77.105.235.102]) by mx1.freebsd.org (Postfix) with ESMTP id 00D198FC13 for ; Sat, 5 Mar 2011 19:18:09 +0000 (UTC) Received: from [77.105.232.43] (port=53489 helo=fredan-pc.localnet) by mail.fredan.se with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.71) (envelope-from ) id 1PvwS5-00047P-LR for freebsd-net@freebsd.org; Sat, 05 Mar 2011 19:43:41 +0100 From: fredrik danerklint Organization: fredan To: FreeBSD Net Date: Sat, 5 Mar 2011 19:43:41 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.35-27-generic; KDE/4.6.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201103051943.41917.fredan@fredan.se> Subject: ifconfig lo1 down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 19:18:10 -0000 Hi, I would like to know what is the differents between ip4 and ip6 for this command. First: #ifconfig lo1 lo1: flags=8049 metric 0 mtu 16384 options=3 inet xx.xx.xx.2 netmask 0xffffffff inet6 2a03:xxxx:xxxx::xxxx:xx02 prefixlen 128 nd6 options=3 $ ping xx.xx.xx.2 PING xx.xx.xx.2 (xx.xx.xx.2): 56 data bytes 64 bytes from xx.xx.xx.2: icmp_seq=0 ttl=64 time=0.012 ms 64 bytes from xx.xx.xx.2: icmp_seq=1 ttl=64 time=0.010 ms ^C and $ ping6 2a03:xxxx:xxxx::xxxx:xx02 PING6(56=40+8+8 bytes) 2a03:xxxx:xxxx::xxxx:xx02 --> 2a03:xxxx:xxxx::xxxx:xx02 16 bytes from 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=0 hlim=64 time=0.053 ms 16 bytes from 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=1 hlim=64 time=0.032 ms ^C Now we run this command: # ifconfig lo1 down and trying to ping again: $ ping xx.xx.xx.2 PING xx.xx.xx.2 (xx.xx.xx.2): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ^C --- xx.xx.xx.2 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss works as expected (and this is what I want) but this command, however: $ ping6 2a03:xxxx:xxxx::xxxx:xx02 PING6(56=40+8+8 bytes) 2a03:xxxx:xxxx::xxxx:xx02 --> 2a03:xxxx:xxxx::xxxx:xx02 16 bytes from 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=0 hlim=64 time=0.048 ms 16 bytes from 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=1 hlim=64 time=0.033 ms 16 bytes from 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=2 hlim=64 time=0.032 ms ^C --- 2a03:xxxx:xxxx::xxxx:xx02 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.032/0.038/0.048/0.007 ms My question is why is it not the same behavior of ip6 as of ip4? -- //fredan From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 20:10:21 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2E6C106564A for ; Sat, 5 Mar 2011 20:10:20 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id A8CD48FC24 for ; Sat, 5 Mar 2011 20:10:20 +0000 (UTC) Received: by qwj8 with SMTP id 8so2631751qwj.13 for ; Sat, 05 Mar 2011 12:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aUnqbRBkHAFWZHXtH5KmVAD7L6OUbn7oK/LfYNQ77Xo=; b=cgd+34700Z7qhFXwpvp+lqNwdId9pkEcBOsBmiEUNGqROjuVh9xiu3jajYvNdeLEID cyu6Lj8+j1NoLTwPxGmSWHXMj/gSr+3RkSMTL4f9fzKHPnYJuGdoCVNEC3vjtgPVvL2i P3NO/298/1HCQvHAUrQIbkLzcipPAaoaOjGQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tv53g21ui2VMgixodP1v/7jF7+mtgcmECvbrfyfgsdSuckQ4dV9fCDtMrhVyFbkGIc oUEnONsILVQsDMN+cJks1x7+VlJwXPI/0Wd+2p/K/d2iaIAWHqMORmJlDn6zHe5aQroe IGKa4/DlQjNvHpAaPhZXXoii7LtsjHk3f7yK4= MIME-Version: 1.0 Received: by 10.229.78.230 with SMTP id m38mr1716170qck.17.1299355819606; Sat, 05 Mar 2011 12:10:19 -0800 (PST) Received: by 10.229.84.129 with HTTP; Sat, 5 Mar 2011 12:10:19 -0800 (PST) In-Reply-To: <201103051943.41917.fredan@fredan.se> References: <201103051943.41917.fredan@fredan.se> Date: Sat, 5 Mar 2011 23:10:19 +0300 Message-ID: From: Sergey Kandaurov To: fredrik danerklint Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net Subject: Re: ifconfig lo1 down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 20:10:21 -0000 On 5 March 2011 21:43, fredrik danerklint wrote: > Hi, > > I would like to know what is the differents between ip4 and ip6 for this > command. > > First: > > #ifconfig lo1 > lo1: flags=3D8049 metric 0 mtu 16384 > =A0 =A0 =A0 =A0options=3D3 > =A0 =A0 =A0 =A0inet xx.xx.xx.2 netmask 0xffffffff > =A0 =A0 =A0 =A0inet6 2a03:xxxx:xxxx::xxxx:xx02 prefixlen 128 > =A0 =A0 =A0 =A0nd6 options=3D3 > > $ ping xx.xx.xx.2 > PING xx.xx.xx.2 (xx.xx.xx.2): 56 data bytes > 64 bytes from xx.xx.xx.2: icmp_seq=3D0 ttl=3D64 time=3D0.012 ms > 64 bytes from xx.xx.xx.2: icmp_seq=3D1 ttl=3D64 time=3D0.010 ms > ^C > > and > > $ ping6 2a03:xxxx:xxxx::xxxx:xx02 > PING6(56=3D40+8+8 bytes) 2a03:xxxx:xxxx::xxxx:xx02 --> 2a03:xxxx:xxxx::xx= xx:xx02 > 16 bytes from 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=3D0 hlim=3D64 time=3D0.= 053 ms > 16 bytes from 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=3D1 hlim=3D64 time=3D0.= 032 ms > ^C > > Now we run this command: > > # ifconfig lo1 down > > and trying to ping again: > > $ ping xx.xx.xx.2 > PING xx.xx.xx.2 (xx.xx.xx.2): 56 data bytes > ping: sendto: No route to host > ping: sendto: No route to host > ping: sendto: No route to host > ^C > --- xx.xx.xx.2 ping statistics --- > 3 packets transmitted, 0 packets received, 100.0% packet loss > > works as expected (and this is what I want) but this command, however: > > $ ping6 2a03:xxxx:xxxx::xxxx:xx02 > PING6(56=3D40+8+8 bytes) 2a03:xxxx:xxxx::xxxx:xx02 --> 2a03:xxxx:xxxx::xx= xx:xx02 > 16 bytes from 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=3D0 hlim=3D64 time=3D0.= 048 ms > 16 bytes from 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=3D1 hlim=3D64 time=3D0.= 033 ms > 16 bytes from 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=3D2 hlim=3D64 time=3D0.= 032 ms > ^C > --- 2a03:xxxx:xxxx::xxxx:xx02 ping6 statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev =3D 0.032/0.038/0.048/0.007 ms > > My question is why is it not the same behavior of ip6 as of ip4? > That's how forwarding works/differs for ipv4 and ipv6. You should be able to ping xx.xx.xx.2 again after adding static route. Something like route add xx.xx.xx.2 -iface -lo1. I can only say for the moment that from my observation ipv4 "routes to itse= lf" exist as far as interface is up, and ipv6 routes don't depend on if iface i= s up. You can check this with netstat -r for both addresses with iface up and dow= n. --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 20:48:56 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9BAB3106566B; Sat, 5 Mar 2011 20:48:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 55894152BCC; Sat, 5 Mar 2011 20:48:39 +0000 (UTC) Message-ID: <4D72A1A7.4040402@FreeBSD.org> Date: Sat, 05 Mar 2011 12:48:39 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> <4D437B13.1070405@FreeBSD.org> <4D518FB3.3040503@FreeBSD.org> <4D6AB2BD.50208@gont.com.ar> <4D6AB636.3030708@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Ivo Vachkov Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 20:48:56 -0000 On 03/04/2011 16:21, Bjoern A. Zeeb wrote: > That said I messed with the patch to avoid the two copies of the > algorithms (so it will not be 4 soon). I know it compiles but I have > yet to test it. I'd love to hear opinions. The #ifdef INET6/INETs > are ugly but we'll see those a lot more and need to figure out > differnt ways to our code was written the last 10 years. > > http://people.freebsd.org/~bz/20110303-01-rfc6056.diff > > The patch also includes a bugfix for the ipv6 case wrt to > "un-binding" on error. I'm now using this version of the patch with alg 4 and it's working fine. Thanks! Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 21:02:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF0A9106566C; Sat, 5 Mar 2011 21:02:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3991A8FC0A; Sat, 5 Mar 2011 21:02:40 +0000 (UTC) Received: by vxc34 with SMTP id 34so3389075vxc.13 for ; Sat, 05 Mar 2011 13:02:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OcpBF11qx7CqIdM+P9qSA2hgetzI1unUPn4wTrHTpGg=; b=bufZyJPPvFU2mdfSy96kuhJDLktoFgTKYCJ9J5Z8H/3lCO04ksd3u1rQpYW9SZPdZq USpGEej8Rv9ypcF3evBHWZcUoBh1SAAWub0q8/wQefcMWzmF40rSCwVkpygcwCgJ8QCE DCMXLzj8SdxqUrVCeQ9gWs52fCNxzHMAPvc4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=XCc6biKM4+B3XqUKOuQJ0UwuEHnAzAuWkn+ERAtwBt4kofMIosIYL/mB0ZTO/qv5pg hFNYxwDux086tVntdrFy0Wpc2Kdq7biac542qLxcYf/LyH75EsblsMOVeLIb0eXAMkVy kqQgGK6zkdQScDU2AwDxzo3O0aqhUOywuXYDQ= MIME-Version: 1.0 Received: by 10.52.0.9 with SMTP id 9mr612630vda.147.1299358958764; Sat, 05 Mar 2011 13:02:38 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.167.3 with HTTP; Sat, 5 Mar 2011 13:02:38 -0800 (PST) In-Reply-To: <20110305163034.GD2833@iut-mir-o.ujf-grenoble.fr> References: <20110305084520.GB2833@iut-mir-o.ujf-grenoble.fr> <20110305163034.GD2833@iut-mir-o.ujf-grenoble.fr> Date: Sun, 6 Mar 2011 05:02:38 +0800 X-Google-Sender-Auth: 01xv3f7nmqlm5RnelQnhfu3okm4 Message-ID: From: Adrian Chadd To: Urankar Mikael Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , freebsd-current , freebsd-mobile@freebsd.org Subject: Re: please (re) test if_ath in -HEAD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 21:02:40 -0000 What was the previous performance? And which chipsets? Adrian On 6 March 2011 00:30, Urankar Mikael wrote: > On Sat 05 March 2011 at 03:27:48AM -0800, Adrian Chadd wrote: > > Absolutely! Let me know if I've broken anything! > > > > Adrian > > > > On 5 March 2011 00:45, Urankar Mikael >wrote: > > > > > On Thu 03 March 2011 at 02:31:05PM -0800, Adrian Chadd wrote: > > > > Hi all, > > > > > > > > For those of you who are testing out my if_ath changes, I'd really > > > > appreciate it if you'd update to -HEAD and re-test. > > > > > > > > I've done a variety of changes to the radio setup and found/fixed a > few > > > bugs > > > > in the TX path. It's quite possible these have introduced > regressions. > > > I'd > > > > like to make sure that I haven't broken legacy (11abg) support in > > > > weird/wonderful ways. I'd also like to make sure that I haven't > > > > broken/changed the behaviour or performance of the NICs in any way. > > > > > > > > Please give things a good thrashing and let me know the results. > > > > > > > > I'm still working towards debugging and enabling basic 11n support, > but I > > > > need to first make sure that I haven't broken legacy operation in any > > > way. > > > > > > > > > > Are you interested by tests on an old atheros card (Atheros 5212, > AR2413 > > > mac 7.9 RF2413 phy 4.5) ? > > > > > Everything seems to work fine, performances are as good as before. > I'm only doing basic stuff with this card (mostly web surfing), I'm > connected to an AP with WPA encryption. If you want me to test other > encryption or setup an AP with this card or whatever, feel free to ask. > > And thanks for you work ! > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 22:11:32 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5A21106566C; Sat, 5 Mar 2011 22:11:32 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7D23A8FC13; Sat, 5 Mar 2011 22:11:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p25MBW4C025057; Sat, 5 Mar 2011 22:11:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p25MBWQr025053; Sat, 5 Mar 2011 22:11:32 GMT (envelope-from linimon) Date: Sat, 5 Mar 2011 22:11:32 GMT Message-Id: <201103052211.p25MBWQr025053@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/155142: [vr] vr0 without mac address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 22:11:32 -0000 Old Synopsis: vr0 without mac address New Synopsis: [vr] vr0 without mac address Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 5 22:11:07 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=155142 From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 23:56:57 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 508A6106572D; Sat, 5 Mar 2011 23:56:57 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 40ACD8FC14; Sat, 5 Mar 2011 23:56:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p25NuvDE018170; Sat, 5 Mar 2011 23:56:57 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p25NuupI018166; Sat, 5 Mar 2011 23:56:56 GMT (envelope-from yongari) Date: Sat, 5 Mar 2011 23:56:56 GMT Message-Id: <201103052356.p25NuupI018166@freefall.freebsd.org> To: neerlan@gmail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/155142: [vr] vr0 without mac address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 23:56:57 -0000 Synopsis: [vr] vr0 without mac address State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Sat Mar 5 23:56:00 UTC 2011 State-Changed-Why: Would you show me full dmesg(8) output of your box? vr(4) was not touched for a long time so what is the last known FreeBSD release that used to get correct station address on your vr(4) controller? BTW, the FreeBSD's way to change the station address of controller is to create a file in /etc directory with name start_if.$INTERFACE_NAME. In other words, create a file with /etc/start_if.vr0 and put the following content into the file. # ifconfig vr0 ether 00:01:02:03:04:05 These entries are read by sh(1) and executed before configuring the interface. See rc.conf(5) for more information. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Sat Mar 5 23:56:00 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=155142