From owner-freebsd-net@freebsd.org Sun Sep 13 07:52:19 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D93A09CD57C for ; Sun, 13 Sep 2015 07:52:19 +0000 (UTC) (envelope-from eliezer@ngtech.co.il) Received: from mtaout27.012.net.il (mtaout27.012.net.il [80.179.55.183]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1F31D76 for ; Sun, 13 Sep 2015 07:52:19 +0000 (UTC) (envelope-from eliezer@ngtech.co.il) Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NUL00K00V07VT00@mtaout27.012.net.il> for freebsd-net@freebsd.org; Sun, 13 Sep 2015 10:48:45 +0300 (IDT) Received: from mail.ngtech.co.il ([84.95.212.160]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPSA id <0NUL00D3FV18JA70@mtaout27.012.net.il> for freebsd-net@freebsd.org; Sun, 13 Sep 2015 10:48:45 +0300 (IDT) Received: by mail.ngtech.co.il (Postfix, from userid 5001) id D48C6221AE; Sun, 13 Sep 2015 10:52:10 +0300 (IDT) Received: from [192.168.10.131] (unknown [192.168.10.131]) by mail.ngtech.co.il (Postfix) with ESMTPA id 19CF621E78 for ; Sun, 13 Sep 2015 10:52:10 +0300 (IDT) Date: Sun, 13 Sep 2015 10:52:10 +0300 From: Eliezer Croitoru Subject: BUG 165059, There is a bug in the virtio NIC drivers which was resolved in OpenBSD. X-012-Sender: eliezer-111@012.net.il To: freebsd-net@freebsd.org Message-id: <55F52B2A.4090509@ngtech.co.il> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.ngtech.co.il User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 X-Spam-Status: No, score=-1.0 required=3.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Level: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Sep 2015 07:52:19 -0000 I tested FreeBSD for another subject and found a bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165059#c9 What can be done about it? Eliezer From owner-freebsd-net@freebsd.org Sun Sep 13 10:12:14 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB0BEA027FA for ; Sun, 13 Sep 2015 10:12:14 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4794912C0 for ; Sun, 13 Sep 2015 10:12:14 +0000 (UTC) (envelope-from cochard@gmail.com) Received: by lbpo4 with SMTP id o4so55622141lbp.2 for ; Sun, 13 Sep 2015 03:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=W+sZML+U7kE8UZ1oU7ettWfOgUied61GiWgrMzP3H60=; b=iZHQAuleGIdJpHN7AIk9Jn3fg10K9wVFujCY6LY4DRGP9D56jT0SeSXuqAuE3KjX7Z DdLCiBfI46t/mABiZ4Ykkivdp3kR73D6akwkLZ/k/4JFYcFjgGJN36Jg6EfdvsxwVuCY tPtwBRU0RasQy9vCYTCxRdwbtn42cpJRBU+Ouv8UHqnSU+trGHYFsIRyqfa+3sD8lcpW amQWXkZIKeCRRMbeTEMLht/TqMjxCnSiLLURkR2R84p2BG6Xl+778ZJ9OXGSFZExUFPt s/2+yFFKdRIHJEuFx0bv+8Hq4STcu4U2Gczu9LaL97Fg+43xne7UeQaOxGNSf0tdsG7O ydFQ== X-Received: by 10.112.83.136 with SMTP id q8mr7892394lby.93.1442139130647; Sun, 13 Sep 2015 03:12:10 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.25.197.68 with HTTP; Sun, 13 Sep 2015 03:11:51 -0700 (PDT) From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Sun, 13 Sep 2015 12:11:51 +0200 X-Google-Sender-Auth: JIOImgUx7xo2wkekFEN1E6cNWig Message-ID: Subject: How to disable useless Intel NIC "Warning" message when using heretic SFP To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Sep 2015 10:12:14 -0000 =E2=80=8B=E2=80=8BAs a responsible adult, I've voluntary set this line in m= y boot/loader.conf: hw.ix.unsupported_sfp=3D"1" But my Intel NIC is still considering me as a child by polluting my dmesg with lot's of message like this one: WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause erectile dysfunction, fire, injury or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules. How can I prevent this spam message in my log ? Thanks,=E2=80=8B From owner-freebsd-net@freebsd.org Sun Sep 13 10:25:26 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29A25A02F48 for ; Sun, 13 Sep 2015 10:25:26 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 177761B1D; Sun, 13 Sep 2015 10:25:25 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id C4A83C06BD; Sun, 13 Sep 2015 03:25:24 -0700 (PDT) Date: Sun, 13 Sep 2015 03:25:24 -0700 From: hiren panchasara To: Olivier Cochard-Labb? Cc: "freebsd-net@freebsd.org" , erj@FreeBSD.org Subject: Re: How to disable useless Intel NIC "Warning" message when using heretic SFP Message-ID: <20150913102524.GW64965@strugglingcoder.info> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oIMVlEQ///Q2JYC7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Sep 2015 10:25:26 -0000 --oIMVlEQ///Q2JYC7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 09/13/15 at 12:11P, Olivier Cochard-Labb? wrote: > ??As a responsible adult, I've voluntary set this line in my > boot/loader.conf: > hw.ix.unsupported_sfp=3D"1" >=20 > But my Intel NIC is still considering me as a child by polluting my dmesg > with lot's of message like this one: >=20 > WARNING: Intel (R) Network Connections are quality tested using Intel (R) > Ethernet Optics. Using untested modules is not supported and may cause > erectile dysfunction, fire, injury or damage to the module or the adapter. > Intel Corporation is not responsible for any harm caused by using untested > modules. >=20 > How can I prevent this spam message in my log ? Already reported to Eric (cc'd). https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202071 Cheers, Hiren --oIMVlEQ///Q2JYC7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJV9U8MXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lJfgH/AkVotlwa0snyH9ze2pa/vob R45yUeckPa+l/z7F914YkuOQ/JoRMELloW5oP9q6H+PupyqktOJVFnEK0p+B5uhX bveDR0S1vj07uHsFkDjt2biZ7grKzSPoZgzW/vCvh8qjwKBNaYZ5lL3+GJGYZNw+ OQESByMzYdkG0ZyQC+mWQk4yl3krePFC4ezAgD6bkI4H3sl+cHsa1HVLgUpdWBh8 H2ciV1ua73SJd/kMwIGax9AC5AeGECzlsJxcRpU3GmSTh0jehIeJSc8qfvK7SdWP Rr2MaR25t7upG/569fgiSfINCAzttL42kWizUlFv3KjUcYwatTkMTyQ5gldypIE= =ZYPz -----END PGP SIGNATURE----- --oIMVlEQ///Q2JYC7-- From owner-freebsd-net@freebsd.org Sun Sep 13 11:50:22 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1611CA03BFA for ; Sun, 13 Sep 2015 11:50:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 026DD1EB3 for ; Sun, 13 Sep 2015 11:50:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8DBoLTI011051 for ; Sun, 13 Sep 2015 11:50:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189234] [em] Big lag with Ethernet Connection I217-V Date: Sun, 13 Sep 2015 11:50:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: nixuser1980@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Sep 2015 11:50:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189234 Damien changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nixuser1980@gmail.com --- Comment #3 from Damien --- I second this. I have tested this NIC with pinging and find that it is dropping packets when running in 100M full and half duplex. Variety of em-related settings have been tried to no avail. I will follow up with a lag report for when running with no packet loss (1000M). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Sun Sep 13 12:11:32 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 638649CBD6F for ; Sun, 13 Sep 2015 12:11:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FF3F1EE3 for ; Sun, 13 Sep 2015 12:11:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8DCBW3U025579 for ; Sun, 13 Sep 2015 12:11:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189234] [em] Big lag with Ethernet Connection I217-V Date: Sun, 13 Sep 2015 12:11:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: nixuser1980@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Sep 2015 12:11:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189234 --- Comment #4 from Damien --- (In reply to Damien from comment #3) I can confirm that when the NIC is running at 1000M Full-Duplex, ssh shows no lag unlike that exhibited at 100M. On this exact same machine, Linux runs the NIC at 100M with no degradation in performance/lost packets. Suggest that this is an issue with the em driver itself. I have validated this against FreeBSD 10.2 and 11 (CURRENT). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Sun Sep 13 13:16:33 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 129FAA03127 for ; Sun, 13 Sep 2015 13:16:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F334310B6 for ; Sun, 13 Sep 2015 13:16:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8DDGW9Y093925 for ; Sun, 13 Sep 2015 13:16:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189234] [em] Big lag with Ethernet Connection I217-V Date: Sun, 13 Sep 2015 13:16:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: erj@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Sep 2015 13:16:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189234 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |erj@freebsd.org --- Comment #5 from Eric Joyner --- (In reply to Sean Bruno from comment #2) Sean, there's supposed to be a fix in the i219/Skylake support patch that always disables TSO at non-1G speeds. Would that help in this case? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Sun Sep 13 15:47:34 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4E24A03FA2 for ; Sun, 13 Sep 2015 15:47:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C1EB512F7 for ; Sun, 13 Sep 2015 15:47:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8DFlYXZ014788 for ; Sun, 13 Sep 2015 15:47:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189234] [em] Big lag with Ethernet Connection I217-V Date: Sun, 13 Sep 2015 15:47:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Sep 2015 15:47:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189234 --- Comment #6 from Sean Bruno --- (In reply to Eric Joyner from comment #5) I can totally test this out, however I don't think the original bug report had anything to do with gigabit vs 100mbit. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Sun Sep 13 15:53:16 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED930A03387 for ; Sun, 13 Sep 2015 15:53:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7FF71958 for ; Sun, 13 Sep 2015 15:53:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8DFrGbt026380 for ; Sun, 13 Sep 2015 15:53:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189234] [em] Big lag with Ethernet Connection I217-V Date: Sun, 13 Sep 2015 15:53:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: erj@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Sep 2015 15:53:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189234 --- Comment #7 from Eric Joyner --- (In reply to Sean Bruno from comment #6) Oh yeah, I didn't notice Damien wasn't the OP. It'd be nice to get more info from cg. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Sun Sep 13 21:00:39 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BF8DA03381 for ; Sun, 13 Sep 2015 21:00:39 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EAA2614DC for ; Sun, 13 Sep 2015 21:00:38 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8DL0c1I016129 for ; Sun, 13 Sep 2015 21:00:38 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201509132100.t8DL0c1I016129@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 13 Sep 2015 21:00:38 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Sep 2015 21:00:39 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t 2 problems total for which you should take action. From owner-freebsd-net@freebsd.org Sun Sep 13 21:54:31 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DAD1A04F91 for ; Sun, 13 Sep 2015 21:54:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 298EC13CF for ; Sun, 13 Sep 2015 21:54:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8DLsVIE048776 for ; Sun, 13 Sep 2015 21:54:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 168245] [arp] [regression] Permanent ARP entry not deleted on interface configuration failure Date: Sun, 13 Sep 2015 21:54:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: melifaro@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: melifaro@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Sep 2015 21:54:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168245 Alexander V. Chernikov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |melifaro@FreeBSD.org Assignee|freebsd-net@FreeBSD.org |melifaro@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Sep 14 12:12:19 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E139A9CA050 for ; Mon, 14 Sep 2015 12:12:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE34E133A for ; Mon, 14 Sep 2015 12:12:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8ECCJLQ040887 for ; Mon, 14 Sep 2015 12:12:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189234] [em] Big lag with Ethernet Connection I217-V Date: Mon, 14 Sep 2015 12:12:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: nixuser1980@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 14 Sep 2015 12:12:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189234 --- Comment #8 from Damien --- I will clarify: I had the same ssh login and input lag. I also noticed some NFS lag. I investigated and found some lost packets (around 20%). I connected the FreeBSD box directly to another that supports 1Gbps as opposed to the 100Mbps router that it was connected to. I noticed that there were no dropped packets. I then set the NIC to 100Mbps and began to see packet loss again as it was with the router setup before. I added these comments because my troubleshooting may assist in identifying that there is a problem with the em driver. I have confirmed this by downloading, compiling, and testing the latest em driver from Intel. I am hoping that the networking team can investigate lost packets at 100 Mbps for the I217-V NIC and replicate the above troubleshooting steps, and hopefully get a resolution rather than the workaround that I have presently implemented. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Sep 14 15:05:34 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06DB9A030FE for ; Mon, 14 Sep 2015 15:05:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6F3D1E97 for ; Mon, 14 Sep 2015 15:05:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8EF5Xv7076944 for ; Mon, 14 Sep 2015 15:05:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189234] [em] Big lag with Ethernet Connection I217-V Date: Mon, 14 Sep 2015 15:05:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jeffrey.e.pieper@intel.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 14 Sep 2015 15:05:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189234 Jeff Pieper changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeffrey.e.pieper@intel.com --- Comment #9 from Jeff Pieper --- (In reply to Damien from comment #8) Damien, We are currently investigating this and hope to have a fix soon. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Sep 14 18:53:06 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FE1EA04748 for ; Mon, 14 Sep 2015 18:53:06 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [191.243.120.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACF671892 for ; Mon, 14 Sep 2015 18:53:05 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id AC96430FCAF for ; Mon, 14 Sep 2015 15:51:57 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1442256716; x=1443120717; bh=+nOIH0aQhnyZAjsZUwtSij4IHcRdAuW43aE ZpYFaj7I=; b=LD8uf/hn5TMaPMIgv4qYp4CFmyOvatRb+umM1yI96Ntz7D1C2vt 5qRNbV38GQ3ZMzaYzvAXjDo/sJJWBPiKewhycTff0W7P2JJHL5ve0htDw3T6CgqW CmEtdwegRTzDKb2lrKKexV3PYy6Qf7Y+HIYLTGWtGEB+5TmV38OASGwM= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGHi1IcD9cPx for ; Mon, 14 Sep 2015 15:51:56 -0300 (BRT) Received: from [192.168.88.29] (unknown [10.255.0.12]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 8125030FCB0 for ; Mon, 14 Sep 2015 15:51:56 -0300 (BRT) Message-ID: <55F71710.4010001@bsdinfo.com.br> Date: Mon, 14 Sep 2015 15:50:56 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: FreeBSD Net Subject: Re: Possible LACP problem with FreeBSD 10.2-RELEASE and Juniper MX5 References: <55F1A095.6010001@bsdinfo.com.br> <55F2005A.1020904@bsdinfo.com.br> In-Reply-To: <55F2005A.1020904@bsdinfo.com.br> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 14 Sep 2015 18:53:06 -0000 On 10-09-2015 19:12, Marcelo Gondim wrote: > On 10-09-2015 12:24, Marcelo Gondim wrote: >> Hi All, >> >> We have a router configured with 2 LACP (lagg0 and lagg1): >> >> lagg0: flags=8843 metric 0 >> mtu 1500 >> options=403bb >> >> ether 00:1b:21:7b:ee:98 >> inet6 fe80::21b:21ff:fe7b:ee98%lagg0 prefixlen 64 scopeid 0x12 >> nd6 options=21 >> media: Ethernet autoselect >> status: active >> laggproto lacp lagghash l2,l3,l4 >> laggport: igb6 flags=1c >> laggport: igb7 flags=1c >> >> lagg1: flags=8843 metric 0 >> mtu 1500 >> options=403bb >> >> ether 00:1b:21:7b:ee:6c >> inet 189.xxx.xxx.34 netmask 0xfffffffc broadcast 189.113.78.35 >> inet6 fe80::21b:21ff:fe7b:ee6c%lagg1 prefixlen 64 scopeid 0xf >> inet6 2804:56c:0:8::2 prefixlen 64 >> nd6 options=21 >> media: Ethernet autoselect >> status: active >> laggproto lacp lagghash l2,l3,l4 >> laggport: igb4 flags=1c >> laggport: igb5 flags=1c >> >> When my Internet traffic is high at night, my BGP session in lagg1 is >> giving up and down 4 in 4 minutes. >> After upgraded to FreeBSD 2.10-RELEASE-p2, this problem started. >> Before we were using the FreeBSD 10.1-STABLE r281235 without any >> problem. >> >> The log have the following messages: >> >> /var/log/messages:Sep 9 19:21:43 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 19:21:44 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 19:27:01 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 19:27:01 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 19:29:13 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 19:29:14 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 19:46:10 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 19:46:11 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:01:02 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:01:03 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:02:08 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:02:09 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:03:54 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:03:57 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:07:05 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:07:06 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:20:49 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:20:50 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:25:39 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:25:40 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:28:55 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:28:56 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:31:39 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:31:39 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:33:29 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 20:33:30 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:03:38 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:03:38 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:09:39 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:09:39 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:20:51 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:20:52 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:25:24 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:25:25 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:36:22 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:36:23 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:39:26 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:39:27 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:47:40 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:47:40 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:52:19 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:52:19 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:53:01 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:53:01 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:58:53 rt01 kernel: igb5: Interface >> stopped DISTRIBUTING, possible flapping >> /var/log/messages:Sep 9 21:58:53 rt01 kernel: igb4: Interface >> stopped DISTRIBUTING, possible flapping >> >> Has there been any change in the LACP, during this period, which >> could be causing this problem? >> I'm doing a downgrade in our system to see if this problem happen >> tonight. > Confirmed. I did downgrade the system to 10.1-STABLE r281235 and the > problem stopped happening. > Some change occurred between 10.1-STABLE r281235 and 10.2-RELEASE-p2 > causing this problem in the system. > In about seven days, I will be putting Intel X520-SR2 interfaces on my system and will no longer be necessary to use lagg. Not be able to patch test any more. Below the PR open: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203031 Thanks and best regards, From owner-freebsd-net@freebsd.org Mon Sep 14 19:47:54 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17D33A04502 for ; Mon, 14 Sep 2015 19:47:54 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB4DD1F4D for ; Mon, 14 Sep 2015 19:47:53 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by igbni9 with SMTP id ni9so89879323igb.0 for ; Mon, 14 Sep 2015 12:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Q9sd2T9o7c/XxxTdvmepsHv4lKDYrLRUGoYvMYrBJO4=; b=Q0FFl7OxvwsW641FR6XFvS2UNDe4dlilp8GKIHL/+WkJAO8h2x4dm7JbF48U6Y8jZw yUtWgwoXgwVXVUPxSAfBa1p2xY2hCJfFoHunou8ZuXlcrZnMP4rFn9Ga2yXcR8Wxuu4Y 9bAQNHpb3G7hYfR69WS3FGH8B3DQIT8U08vIeel8P4yHzcu/Pk7z+XsUEOumL36tJJNP cyNuazXhMu2gDakGz8GKg+karN2PnAYsRbkIBKhJzogRiMNizBXkJFusTDtXHS5N//tN OZ8drCWkq3zgm821IIweM9We/r9PEFy9TlzZzher9GStn7ja6j90jVMf4IaS98iSRpqg 7M0A== MIME-Version: 1.0 X-Received: by 10.50.124.4 with SMTP id me4mr21736405igb.34.1442260073171; Mon, 14 Sep 2015 12:47:53 -0700 (PDT) Received: by 10.107.178.67 with HTTP; Mon, 14 Sep 2015 12:47:53 -0700 (PDT) Date: Mon, 14 Sep 2015 15:47:53 -0400 Message-ID: Subject: route command will perform DNS lookup of invalid interface name From: Ryan Stone To: freebsd-net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 14 Sep 2015 19:47:54 -0000 At $WORK, we have observed that if you attempt to add a route with the -iface flag, but you specify an incorrect interface name, the route command will perform a DNS lookup of the interface name. It appears that if the DNS lookup succeeds that it will treat the parameter to -iface as if it were a gateway for the route and not an interface. This appears to be a simple bug. This patch resolves the issue for me, but I'm a bit worried that the fallback to a DNS lookup might actually be desired behaviour in some case. Does anybody have any ideas? diff --git a/sbin/route/route.c b/sbin/route/route.c index 1bce41e..a447a45 100644 --- a/sbin/route/route.c +++ b/sbin/route/route.c @@ -1222,6 +1222,9 @@ getaddr(int idx, char *str, struct hostent **hpp, int nrflags) freeifaddrs(ifap); if (sdl != NULL) return(1); + else + errx(EX_DATAERR, + "inferface '%s' does not exist", str); } break; case RTAX_IFP: From owner-freebsd-net@freebsd.org Mon Sep 14 20:47:00 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CC5EA041FD for ; Mon, 14 Sep 2015 20:47:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39AA91B38 for ; Mon, 14 Sep 2015 20:47:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8EKl0HF072333 for ; Mon, 14 Sep 2015 20:47:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202680] Silent data corruption on em(4) interfaces Date: Mon, 14 Sep 2015 20:46:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: KOT@MATPOCKuH.Ru X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 14 Sep 2015 20:47:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202680 --- Comment #10 from Dmitry Afanasiev --- Also I installed into buggy system with fbsd10.2 old Sun's gigabit ethernet adapter with cas(4) driver and reconfigured lagg to use only this adapter. I transferred huge files several times with system's uptime >10 days via ssh and ftp without any problems. I think problem related to only em(4) network driver, not another system's parts. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Sep 15 04:55:23 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A20CAA0300F for ; Tue, 15 Sep 2015 04:55:23 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 92D3319E0 for ; Tue, 15 Sep 2015 04:55:23 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 2B3BBC0938 for ; Mon, 14 Sep 2015 21:55:17 -0700 (PDT) Date: Mon, 14 Sep 2015 21:55:17 -0700 From: hiren panchasara To: freebsd-net@FreeBSD.org Subject: Blackhole detection mtu clamping Message-ID: <20150915045517.GA61042@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 04:55:23 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm trying to fix a bug and also change behavior of how mtu clamping is done during blackhole detection at https://reviews.freebsd.org/D3434 I'd appreciate any comments on the review. Cheers, Hiren --jI8keyz6grp/JLjh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJV96SxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lWwcH/3/zfdYfmftkYqVzHvJDG8zq Y9SJ0DwWbJTgUVAyhOjZesSMOVlMyVhbWBk95EilAFaLrcPCViUcxjoEAjZm/gg1 1B7Y+nYRKJbRgZPml85x94SzqbZdmK0SzigoSJc/ACxju34px3TY/7i5zJ7L1dUg 3FnQvMus5uoHvHjul2mcKRjvoywsVB/7CdgQpvJ1PSlExQJCyB3FpZf4aeQiaZh6 0SBRbFkXwbP6DkTu4KyMsAiNF0FxgJXqGtd53MeiChbfr/qgmft6bbSAN1mBKCEl hzZCloHykdz+5nrcXtn8lcq1oaLNOsln5HZSvoPofVUd+kbuSiQHtbxaABgGkyc= =mNGK -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-net@freebsd.org Tue Sep 15 07:10:20 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 036FFA04CB5 for ; Tue, 15 Sep 2015 07:10:20 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B723C18E1 for ; Tue, 15 Sep 2015 07:10:19 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-net@freebsd.org with esmtp (envelope-from ) id <1ZbkKY-000sKp-DP>; Tue, 15 Sep 2015 09:07:06 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-net@freebsd.org with esmtpsa (envelope-from ) id <1ZbkKX-000d0A-Ur>; Tue, 15 Sep 2015 09:07:06 +0200 Date: Tue, 15 Sep 2015 09:06:58 +0200 From: "O. Hartmann" To: freebsd-net@freebsd.org Subject: HELP! Mysterious socket 843/tcp listening on CURRENT system Message-ID: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 07:10:20 -0000 Hopefully, I'm right on this list. if not, please forward. Running CURRENT as of FreeBSD 11.0-CURRENT #3 r287780: Mon Sep 14 13:34:16 CEST 2015 amd64, I check via nmap for open sockets since I had trouble protecting a server with IPFW and NAT. I see a service (nmap) Host is up (0.041s latency). Not shown: 998 filtered ports PORT STATE SERVICE 843/tcp open unknown and via sockstat -l -p 843, I get this: ? ? ? ? tcp4 *:843 *:* I double checked all services on the server and i can not figure out what daemon or service is using this port. The port is exposed throught NAT (I use in-kernel NAT on that system). This service is accessible via telnet host-ip 843: Trying 85.179.165.184... Connected to xxx.xxx.xxx.xxx. Escape character is '^]'. Well, I feel pants-down right now since it seems very hard to find out what service is keeping this socket open for communications to the outside world. Anyone any suggestions? Thanks in advance, Oliver From owner-freebsd-net@freebsd.org Tue Sep 15 07:13:38 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7343A04EA1 for ; Tue, 15 Sep 2015 07:13:38 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E9911BCE for ; Tue, 15 Sep 2015 07:13:38 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from Xins-MBP.home.us.delphij.net (unknown [IPv6:2601:646:8f00:8a91:1450:4ad4:ce47:8f80]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id A2198215EE; Tue, 15 Sep 2015 00:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1442301217; x=1442315617; bh=FLd/0DSPJ5E6dEDPX4dmzG30iSs2m2EGeWv8lBTALZ0=; h=Subject:To:References:From:Date:In-Reply-To; b=JvnSr8MHV8wHEg3qjF3uyPoGVWL9T1DKWkg0agQqlAZ0QIOCeAPPdFDzHQSy1LpCb GrLxfC32scrgkOQQmixp7b47LiyPwqykobMkjpK3IT7NynjutC7xUUePL1sNUlMH6P akhZ3f75FBKHrUzNKsvEzf7DkHEhdqDB8/WTkQ9Q= Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system To: "O. Hartmann" , freebsd-net@freebsd.org References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> From: Xin Li Message-ID: <55F7C51D.4030704@delphij.net> Date: Tue, 15 Sep 2015 00:13:33 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8IPNETFb9HcdhmfIv8oNciJbUnI8U1AnK" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 07:13:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8IPNETFb9HcdhmfIv8oNciJbUnI8U1AnK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/15/15 00:06, O. Hartmann wrote: > Hopefully, I'm right on this list. if not, please forward. >=20 > Running CURRENT as of FreeBSD 11.0-CURRENT #3 r287780: Mon Sep 14 13:3= 4:16 > CEST 2015 amd64, I check via nmap for open sockets since I had trouble > protecting a server with IPFW and NAT. >=20 > I see a service (nmap) >=20 > Host is up (0.041s latency). > Not shown: 998 filtered ports > PORT STATE SERVICE > 843/tcp open unknown >=20 > and via sockstat -l -p 843, I get this: > ? ? ? ? tcp4 *:843 *:* Sounds like there is a kernel listener, wild guess -- what does rpcinfo -p say? Cheers, --8IPNETFb9HcdhmfIv8oNciJbUnI8U1AnK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJV98UhAAoJEJW2GBstM+ns050QAKrr7sHf1YEyivcbkiguZegx +P/1j9cyBoL3FDs0iH1IU36kaS2HBzlqwjzOuMqzUXopxsAJJDk1a4IAcxUSoqFk eZe2XIxwLirUxClalAhOFSqKzmxmY9/RRfsk6to+FVdL1pTp+4bUzdzHQz8L4s3Q vGnZG6gQjV83Rzv/IRjLSdzFD+1/UjPD8iBtxfNJ2NnzdYDUgWhtmHx69CnIgmYw hymeqhqU2fsI7caNkCbsc1zNe/gXz8tc0ehxQoiBAFtVuOTDt6OMbJ8c0KemR+rr oHaN4f+Tt396g0gSll8ItdD/E3snrsN1tQ6YehK4sR4O0RFPQPCqkwMUuw7Ztcmv AU2frxeKm++bFNjTCO3iluZeozMjk2USzprwXQGZ8ANDFyCiZmuV7dDiaFCv9FBo fCXToZOF2cRysdMrWn4qEcj3vu7/mSFNUEuFBMHhdfncgy+42VZDtk4MSYdpB+ar ybGg4SHV8h9/w1GPoOnsk0CCJqMJActJOgA/9wglDpSA8APPDDSDtIooXt2RaSHa Pci6XSXwbEB8vi/ppMC5uoqVPU5RLR39WWf4yG4tIsTqfgtU7qp8iU2n+0NM9gCt /2vUxPyh5i5Ih4lRbcddQfX/pY2G10UHYHEDheHAXNCsLJYdzyGQ+rSNcIRbrI+q B+NvTVtf+Nyu1sqWTfYc =0eqA -----END PGP SIGNATURE----- --8IPNETFb9HcdhmfIv8oNciJbUnI8U1AnK-- From owner-freebsd-net@freebsd.org Tue Sep 15 07:21:22 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19C68A023C6 for ; Tue, 15 Sep 2015 07:21:22 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB88E1FA5 for ; Tue, 15 Sep 2015 07:21:21 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: by igbkq10 with SMTP id kq10so9422830igb.0 for ; Tue, 15 Sep 2015 00:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zvBlZd2cGa0hg+rQnedGbAMRlIqsxKn8zHzcuLlJyrg=; b=q90xwAwq7+i8SvHDmfWURScC9/kf7m/KplrC9Z0Tme4qlhYJUvGMRblc0pyyvqJmTr 8JQIdAfbAP0YPyPfsIcqbUEZ+dq/qMOMGNR+7Cf0ILfy5XPVPaqw1Dj310x0eZOxq8X2 N1oa+WAL3UxRKcSdGbO3EBKXIIZ6nO94rABdjiI5EtU7H1erdrY3lS+uHnBNzVja6WEV Ba6rqbexgxb7vthZIxEjLXAa1+t42zrmkl+UMujPbqLlpqBXLpnBEyBSbq2GLnjrefHZ kHIbuxixM2bg0VsnkFWswTiYqiLfzS/AXy6icDU/haXd7qdq+3otIcXWJ+F4wO+09XTp OpWA== MIME-Version: 1.0 X-Received: by 10.50.122.10 with SMTP id lo10mr3192360igb.76.1442301681347; Tue, 15 Sep 2015 00:21:21 -0700 (PDT) Received: by 10.107.200.66 with HTTP; Tue, 15 Sep 2015 00:21:21 -0700 (PDT) In-Reply-To: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> Date: Tue, 15 Sep 2015 10:21:21 +0300 Message-ID: Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system From: Kimmo Paasiala To: "O. Hartmann" Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 07:21:22 -0000 On Tue, Sep 15, 2015 at 10:06 AM, O. Hartmann wrote: > Hopefully, I'm right on this list. if not, please forward. > > Running CURRENT as of FreeBSD 11.0-CURRENT #3 r287780: Mon Sep 14 13:34:16 > CEST 2015 amd64, I check via nmap for open sockets since I had trouble > protecting a server with IPFW and NAT. > > I see a service (nmap) > > Host is up (0.041s latency). > Not shown: 998 filtered ports > PORT STATE SERVICE > 843/tcp open unknown > > and via sockstat -l -p 843, I get this: > ? ? ? ? tcp4 *:843 *:* > > I double checked all services on the server and i can not figure out what > daemon or service is using this port. The port is exposed throught NAT (I use > in-kernel NAT on that system). > This service is accessible via telnet host-ip 843: > > Trying 85.179.165.184... > Connected to xxx.xxx.xxx.xxx. > Escape character is '^]'. > > > Well, I feel pants-down right now since it seems very hard to find out what > service is keeping this socket open for communications to the outside world. > > Anyone any suggestions? > > Thanks in advance, > Oliver As delphij@ noted it's most likely something that uses rpcbind(3). Why are your filter rules allowing unknown ports to be open to the internet? Don't you have a default deny policy in place? From owner-freebsd-net@freebsd.org Tue Sep 15 07:48:00 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F9E5A03676 for ; Tue, 15 Sep 2015 07:48:00 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3131289 for ; Tue, 15 Sep 2015 07:48:00 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1Zbky6-0017A6-8F>; Tue, 15 Sep 2015 09:47:58 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1Zbky6-000glR-0Q>; Tue, 15 Sep 2015 09:47:58 +0200 Date: Tue, 15 Sep 2015 09:47:57 +0200 From: "O. Hartmann" To: Kimmo Paasiala Cc: FreeBSD Net Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system Message-ID: <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 07:48:00 -0000 On Tue, 15 Sep 2015 10:21:21 +0300 Kimmo Paasiala wrote: > On Tue, Sep 15, 2015 at 10:06 AM, O. Hartmann > wrote: > > Hopefully, I'm right on this list. if not, please forward. > > > > Running CURRENT as of FreeBSD 11.0-CURRENT #3 r287780: Mon Sep 14 13:34:16 > > CEST 2015 amd64, I check via nmap for open sockets since I had trouble > > protecting a server with IPFW and NAT. > > > > I see a service (nmap) > > > > Host is up (0.041s latency). > > Not shown: 998 filtered ports > > PORT STATE SERVICE > > 843/tcp open unknown > > > > and via sockstat -l -p 843, I get this: > > ? ? ? ? tcp4 *:843 *:* > > > > I double checked all services on the server and i can not figure out what > > daemon or service is using this port. The port is exposed throught NAT (I > > use in-kernel NAT on that system). > > This service is accessible via telnet host-ip 843: > > > > Trying 85.179.165.184... > > Connected to xxx.xxx.xxx.xxx. > > Escape character is '^]'. > > > > > > Well, I feel pants-down right now since it seems very hard to find out what > > service is keeping this socket open for communications to the outside world. > > > > Anyone any suggestions? > > > > Thanks in advance, > > Oliver > > As delphij@ noted it's most likely something that uses rpcbind(3). Why > are your filter rules allowing unknown ports to be open to the > internet? Don't you have a default deny policy in place? Hello. Many thanks for the fast response. I switched recently from PF to IPFW and utilise in-kernel NAT via libalias. I think the "wooden" concept of rules made me penetrate the IP filter and expose it to the outer world. The mysterious port 843/tcp isn't the only one that is exposed, NFS is also. I have rules that block all incoming trafiic from the exposed-to-the-internet interface and should allow all traffic on the inside and local interfaces. The rulesets I utilised work so far on machines without NAT (department, bureau, etc.). The moment NAT comes into play I do not understand the way IPFW works - it seems to blow a whole into any bunch of filterings walls I create. But that is an other issue and it is most likely due to the outdated documentation (that doc still uses port 37 for NTP purposes and referes to the outdated divert mechanism using natd, see the recent handbook). The internet is also full of ambigous examples. At the moment I have no access to the box since IPFW and it's reload/restart mechanism (etc/rc.d/ipfw) seems to be very instable when restartet too often. I did it serveral times with moderate delays of several seconds or minutes inbetween and now the box is "gone". Checking with nmap, port 22/tcp sometimes is open, then closed again. This is also very weird. IPWF seems not to be right choice, even if it is FreeBSD native. @delphi: I will give an answer as soon I gain access to the box again. Regards and thanks, oh From owner-freebsd-net@freebsd.org Tue Sep 15 07:48:30 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C23AA036AB for ; Tue, 15 Sep 2015 07:48:30 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCEF41318 for ; Tue, 15 Sep 2015 07:48:29 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1ZbkyX-0017QH-Nw>; Tue, 15 Sep 2015 09:48:25 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1ZbkyX-000gpy-Iy>; Tue, 15 Sep 2015 09:48:25 +0200 Date: Tue, 15 Sep 2015 09:48:24 +0200 From: "O. Hartmann" To: Xin Li Cc: freebsd-net@freebsd.org Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system Message-ID: <20150915094824.7021f0b2@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <55F7C51D.4030704@delphij.net> References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> <55F7C51D.4030704@delphij.net> Organization: FU Berlin X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 07:48:30 -0000 On Tue, 15 Sep 2015 00:13:33 -0700 Xin Li wrote: > > > On 9/15/15 00:06, O. Hartmann wrote: > > Hopefully, I'm right on this list. if not, please forward. > > > > Running CURRENT as of FreeBSD 11.0-CURRENT #3 r287780: Mon Sep 14 13:34:16 > > CEST 2015 amd64, I check via nmap for open sockets since I had trouble > > protecting a server with IPFW and NAT. > > > > I see a service (nmap) > > > > Host is up (0.041s latency). > > Not shown: 998 filtered ports > > PORT STATE SERVICE > > 843/tcp open unknown > > > > and via sockstat -l -p 843, I get this: > > ? ? ? ? tcp4 *:843 *:* > > Sounds like there is a kernel listener, wild guess -- what does rpcinfo > -p say? > > Cheers, > ... lost contact to system, will reply as soon as I gain access ... From owner-freebsd-net@freebsd.org Tue Sep 15 09:59:42 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32DB4A04129 for ; Tue, 15 Sep 2015 09:59:42 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward11h.cmail.yandex.net (forward11h.cmail.yandex.net [IPv6:2a02:6b8:0:f35::9c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A640B1E4D for ; Tue, 15 Sep 2015 09:59:41 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from web17h.yandex.ru (web17h.yandex.ru [84.201.186.46]) by forward11h.cmail.yandex.net (Yandex) with ESMTP id CC0F3213B5; Tue, 15 Sep 2015 12:59:16 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web17h.yandex.ru (Yandex) with ESMTP id 01177C216BA; Tue, 15 Sep 2015 12:59:15 +0300 (MSK) Received: by web17h.yandex.ru with HTTP; Tue, 15 Sep 2015 12:59:15 +0300 From: Alexander V. Chernikov Envelope-From: melifaro@ipfw.ru To: O. Hartmann , Kimmo Paasiala Cc: FreeBSD Net In-Reply-To: <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system MIME-Version: 1.0 Message-Id: <1483331442311155@web17h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 15 Sep 2015 12:59:15 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 09:59:42 -0000 15.09.2015, 10:48, "O. Hartmann" : > On Tue, 15 Sep 2015 10:21:21 +0300 > Kimmo Paasiala wrote: > >> šOn Tue, Sep 15, 2015 at 10:06 AM, O. Hartmann >> š wrote: >> š> Hopefully, I'm right on this list. if not, please forward. >> š> >> š> Running CURRENT as of FreeBSD 11.0-CURRENT #3 r287780: Mon Sep 14 13:34:16 >> š> CEST 2015 amd64, I check via nmap for open sockets since I had trouble >> š> protecting a server with IPFW and NAT. >> š> >> š> I see a service (nmap) >> š> >> š> Host is up (0.041s latency). >> š> Not shown: 998 filtered ports >> š> PORT STATE SERVICE >> š> 843/tcp open unknown >> š> >> š> and via sockstat -l -p 843, I get this: >> š> ? ? ? ? tcp4 *:843 *:* >> š> >> š> I double checked all services on the server and i can not figure out what >> š> daemon or service is using this port. The port is exposed throught NAT (I >> š> use in-kernel NAT on that system). >> š> This service is accessible via telnet host-ip 843: >> š> >> š> Trying 85.179.165.184... >> š> Connected to xxx.xxx.xxx.xxx. >> š> Escape character is '^]'. >> š> >> š> >> š> Well, I feel pants-down right now since it seems very hard to find out what >> š> service is keeping this socket open for communications to the outside world. >> š> >> š> Anyone any suggestions? >> š> >> š> Thanks in advance, >> š> Oliver >> >> šAs delphij@ noted it's most likely something that uses rpcbind(3). Why >> šare your filter rules allowing unknown ports to be open to the >> šinternet? Don't you have a default deny policy in place? > > Hello. > Many thanks for the fast response. > > I switched recently from PF to IPFW and utilise in-kernel NAT via libalias. I > think the "wooden" concept of rules made me penetrate the IP filter and expose > it to the outer world. The mysterious port 843/tcp isn't the only one that is > exposed, NFS is also. I have rules that block all incoming trafiic from the > exposed-to-the-internet interface and should allow all traffic on the inside > and local interfaces. The rulesets I utilised work so far on machines without > NAT (department, bureau, etc.). The moment NAT comes into play I do not > understand the way IPFW works - it seems to blow a whole into any bunch of > filterings walls I create. But that is an other issue and it is most likely > due to the outdated documentation (that doc still uses port 37 for NTP > purposes and referes to the outdated divert mechanism using natd, see the > recent handbook). The internet is also full of ambigous examples. > > At the moment I have no access to the box since IPFW and it's reload/restart > mechanism (etc/rc.d/ipfw) seems to be very instable when restartet too often. Well, ipfw(8) rc script might really need some face-lifting, but I wonder what is the source of instability might be. It would be great to hear more details so we can do something to prevent that? > I did it serveral times with moderate delays of several seconds or minutes > inbetween and now the box is "gone". Checking with nmap, port 22/tcp > sometimes is open, then closed again. This is also very weird. > > IPWF seems not to be right choice, even if it is FreeBSD native. > > @delphi: I will give an answer as soon I gain access to the box again. > > Regards and thanks, > > oh > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Tue Sep 15 10:28:08 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AFD0A02138 for ; Tue, 15 Sep 2015 10:28:08 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA5D01EFE; Tue, 15 Sep 2015 10:28:07 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1ZbnT3-000FmQ-VH>; Tue, 15 Sep 2015 12:28:05 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1ZbnT3-000wtK-Jl>; Tue, 15 Sep 2015 12:28:05 +0200 Date: Tue, 15 Sep 2015 12:28:04 +0200 From: "O. Hartmann" To: "Alexander V. Chernikov" Cc: Kimmo Paasiala , FreeBSD Net Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system Message-ID: <20150915122804.60c2f5a6@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <1483331442311155@web17h.yandex.ru> References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> <1483331442311155@web17h.yandex.ru> Organization: FU Berlin X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 10:28:08 -0000 On Tue, 15 Sep 2015 12:59:15 +0300 Alexander V. Chernikov wrote: > > > 15.09.2015, 10:48, "O. Hartmann" : > > On Tue, 15 Sep 2015 10:21:21 +0300 > > Kimmo Paasiala wrote: > > > >> šOn Tue, Sep 15, 2015 at 10:06 AM, O. Hartmann > >> š wrote: > >> š> Hopefully, I'm right on this list. if not, please forward. > >> š> > >> š> Running CURRENT as of FreeBSD 11.0-CURRENT #3 r287780: Mon Sep 14 > >> 13:34:16 > CEST 2015 amd64, I check via nmap for open sockets since I had > >> trouble > protecting a server with IPFW and NAT. > >> š> > >> š> I see a service (nmap) > >> š> > >> š> Host is up (0.041s latency). > >> š> Not shown: 998 filtered ports > >> š> PORT STATE SERVICE > >> š> 843/tcp open unknown > >> š> > >> š> and via sockstat -l -p 843, I get this: > >> š> ? ? ? ? tcp4 *:843 *:* > >> š> > >> š> I double checked all services on the server and i can not figure out > >> what > daemon or service is using this port. The port is exposed throught > >> NAT (I > use in-kernel NAT on that system). > >> š> This service is accessible via telnet host-ip 843: > >> š> > >> š> Trying 85.179.165.184... > >> š> Connected to xxx.xxx.xxx.xxx. > >> š> Escape character is '^]'. > >> š> > >> š> > >> š> Well, I feel pants-down right now since it seems very hard to find out > >> what > service is keeping this socket open for communications to the > >> outside world. > > >> š> Anyone any suggestions? > >> š> > >> š> Thanks in advance, > >> š> Oliver > >> > >> šAs delphij@ noted it's most likely something that uses rpcbind(3). Why > >> šare your filter rules allowing unknown ports to be open to the > >> šinternet? Don't you have a default deny policy in place? > > > > Hello. > > Many thanks for the fast response. > > > > I switched recently from PF to IPFW and utilise in-kernel NAT via libalias. > > I think the "wooden" concept of rules made me penetrate the IP filter and > > expose it to the outer world. The mysterious port 843/tcp isn't the only > > one that is exposed, NFS is also. I have rules that block all incoming > > trafiic from the exposed-to-the-internet interface and should allow all > > traffic on the inside and local interfaces. The rulesets I utilised work so > > far on machines without NAT (department, bureau, etc.). The moment NAT > > comes into play I do not understand the way IPFW works - it seems to blow a > > whole into any bunch of filterings walls I create. But that is an other > > issue and it is most likely due to the outdated documentation (that doc > > still uses port 37 for NTP purposes and referes to the outdated divert > > mechanism using natd, see the recent handbook). The internet is also full > > of ambigous examples. > > > > At the moment I have no access to the box since IPFW and it's reload/restart > > mechanism (etc/rc.d/ipfw) seems to be very instable when restartet too > > often. > Well, ipfw(8) rc script might really need some face-lifting, but I wonder > what is the source of instability might be. It would be great to hear more > details so we can do something to prevent that? The syntax and layout of the rc.firewall rc-script is ambigous and confusing. The script added to firewall_type="XXXXXX" in rc.conf is a direct ipfw script containing non-expanded ipfw commands. There is nothing about variable expanding from rc.conf or rc.conf.local. In the logic of the other firewall type, OPEN, WORKSTATION et cetera, one might think the rc.firewall script is utilising the variables set in rc.conf. But nothing so far! For me, that looked more like a logic break of the concept. The people at FreeBSD usually do a great work by defining default values. I like it to use the default settings done by the original rc.firewall script, especially for the loopback device and IPv6 and IPv4 enbaling/disabling. Using "firewall_type=" in rc.conf leaves you alone with a raw, unexpanded script which doesn't make use of the settings in rc.conf. The problems I face are sometimes related to syntax errors when creating ipfw tables - as this is done by the rc.firewall script preventing non-official IP ranges accessing the intranetwork. Somehow I can "service ipfw restart" the original-left-over service when using only type WORKSTATION or so - the scripts handle gracefully the restart, no established connectiong gets dropped off, no errors occur when creating/flushing tables. Using the "wooden" and clumsy firewall_type="" where the added set of rules is a pure ipfw-command script - the problems arise very quickly. > > > I did it serveral times with moderate delays of several seconds or minutes > > inbetween and now the box is "gone". Checking with nmap, port 22/tcp > > sometimes is open, then closed again. This is also very weird. > > > > > IPWF seems not to be right choice, even if it is FreeBSD native. > > > > @delphi: I will give an answer as soon I gain access to the box again. > > > > Regards and thanks, > > > > oh > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Tue Sep 15 11:25:32 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79F26A048B9 for ; Tue, 15 Sep 2015 11:25:32 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D69F917ED for ; Tue, 15 Sep 2015 11:25:28 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t8FB8peG033050; Tue, 15 Sep 2015 21:08:51 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 15 Sep 2015 21:08:51 +1000 (EST) From: Ian Smith To: "O. Hartmann" cc: Kimmo Paasiala , freebsd-net@freebsd.org Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system In-Reply-To: <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> Message-ID: <20150915201451.L90924@sola.nimnet.asn.au> References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 11:25:32 -0000 On Tue, 15 Sep 2015 09:47:57 +0200, O. Hartmann wrote: > On Tue, 15 Sep 2015 10:21:21 +0300 > Kimmo Paasiala wrote: > > > On Tue, Sep 15, 2015 at 10:06 AM, O. Hartmann > > wrote: > > > Hopefully, I'm right on this list. if not, please forward. > > > > > > Running CURRENT as of FreeBSD 11.0-CURRENT #3 r287780: Mon Sep 14 13:34:16 > > > CEST 2015 amd64, I check via nmap for open sockets since I had trouble > > > protecting a server with IPFW and NAT. > > > > > > I see a service (nmap) > > > > > > Host is up (0.041s latency). > > > Not shown: 998 filtered ports > > > PORT STATE SERVICE > > > 843/tcp open unknown > > > > > > and via sockstat -l -p 843, I get this: > > > ? ? ? ? tcp4 *:843 *:* > > > > > > I double checked all services on the server and i can not figure out what > > > daemon or service is using this port. The port is exposed throught NAT (I > > > use in-kernel NAT on that system). > > > This service is accessible via telnet host-ip 843: > > > > > > Trying 85.179.165.184... > > > Connected to xxx.xxx.xxx.xxx. > > > Escape character is '^]'. > > > > > > > > > Well, I feel pants-down right now since it seems very hard to find out what > > > service is keeping this socket open for communications to the outside world. > > > > > > Anyone any suggestions? > > > > > > Thanks in advance, > > > Oliver > > > > As delphij@ noted it's most likely something that uses rpcbind(3). Why > > are your filter rules allowing unknown ports to be open to the > > internet? Don't you have a default deny policy in place? > > Hello. > Many thanks for the fast response. > > I switched recently from PF to IPFW and utilise in-kernel NAT via libalias. I > think the "wooden" concept of rules made me penetrate the IP filter and expose > it to the outer world. The mysterious port 843/tcp isn't the only one that is > exposed, NFS is also. I have rules that block all incoming trafiic from the > exposed-to-the-internet interface and should allow all traffic on the inside > and local interfaces. The rulesets I utilised work so far on machines without > NAT (department, bureau, etc.). The moment NAT comes into play I do not > understand the way IPFW works - it seems to blow a whole into any bunch of > filterings walls I create. Without seeing the ruleset you've chosen to implement, it's impossible to speculate on what might be wrong with it. Sanitise where necessary. > But that is an other issue and it is most likely > due to the outdated documentation (that doc still uses port 37 for NTP > purposes and referes to the outdated divert mechanism using natd, see the > recent handbook). The internet is also full of ambigous examples. Yes, the handbook IPFW section is still crazy after all these years, despite ongoing attempts to limit the damage. Best just ignore it. ipfw(8) is pretty much your only friend - apart from helpful people on freebsd-ipfw@freebsd.org - but it is comprehensive and almost always correct, in my 17 years using it, and I'm a long way from an expert. > At the moment I have no access to the box since IPFW and it's reload/restart > mechanism (etc/rc.d/ipfw) seems to be very instable when restartet too often. That needs reporting as a bug; if that's true on 11-CURRENT, it's new. > I did it serveral times with moderate delays of several seconds or minutes > inbetween and now the box is "gone". Checking with nmap, port 22/tcp > sometimes is open, then closed again. This is also very weird. > > IPWF seems not to be right choice, even if it is FreeBSD native. It's not the right choice unless you're prepared to study how it needs to be used, to the point where you can follow any flows through the ruleset. It's a compiled virtual machine language, suiting some folks better than others, rather than pf (or ipf) higher-level languages. /etc/rc.firewall shows far more sane ways to begin with a secure firewall than those 'stateful at any cost' handbook examples. True, there are few good published examples of using ipfw with nat, statefully, in an easily understood method. Hopefully ongoing work. Do you have some requirement/s that pf could not provide? > @delphi: I will give an answer as soon I gain access to the box again. > > Regards and thanks, > > oh Good luck, Ian From owner-freebsd-net@freebsd.org Tue Sep 15 13:51:14 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B34E0A04FA8 for ; Tue, 15 Sep 2015 13:51:14 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 733311C68 for ; Tue, 15 Sep 2015 13:51:14 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id t8FDpCZn008637 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Sep 2015 07:51:12 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id t8FDpBbj008634; Tue, 15 Sep 2015 07:51:11 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 15 Sep 2015 07:51:11 -0600 (MDT) From: Warren Block To: Ian Smith cc: "O. Hartmann" , Kimmo Paasiala , freebsd-net@freebsd.org Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system In-Reply-To: <20150915201451.L90924@sola.nimnet.asn.au> Message-ID: References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> <20150915201451.L90924@sola.nimnet.asn.au> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 15 Sep 2015 07:51:12 -0600 (MDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 13:51:14 -0000 On Tue, 15 Sep 2015, Ian Smith wrote: > > But that is an other issue and it is most likely > > due to the outdated documentation (that doc still uses port 37 for NTP > > purposes and referes to the outdated divert mechanism using natd, see the > > recent handbook). The internet is also full of ambigous examples. > > Yes, the handbook IPFW section is still crazy after all these years, > despite ongoing attempts to limit the damage. Best just ignore it. Best overall would be to fix the documentation. Given that there seems to be more interest in IPFW lately, it would be nice if someone well-versed in it would repair or even rewrite the IPFW handbook section. Rewrites are sometimes less work than fixing an old section that no longer fits actual usage. I have not used IPFW in years, but would be willing to help with an edit/rewrite. From owner-freebsd-net@freebsd.org Tue Sep 15 14:07:37 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D99A2A04851 for ; Tue, 15 Sep 2015 14:07:37 +0000 (UTC) (envelope-from sreenathbh@rocketmail.com) Received: from nm22-vm2.access.bullet.mail.gq1.yahoo.com (nm22-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA9B61344 for ; Tue, 15 Sep 2015 14:07:37 +0000 (UTC) (envelope-from sreenathbh@rocketmail.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rocketmail.com; s=s2048; t=1442325893; bh=1ZJjHFdjlXiGupxx7mWU+XaGZhcMkIpgine+rfvE0EQ=; h=Date:From:Subject:To:Cc:In-Reply-To:From:Subject; b=V2dUQzYktusmIjec4qV2+uu8aLX+737ZijIqnnZKielphf9raTSNIGZz5EXuW+VSEmJQ/PAQlf9NV0cXIzOkLr6TKRigpuiPdwhX6Vvgah75bvJ7ynAqqEVlHBnWbqukPBP75fpCpmGJwQEY1PAWY3eYgPtFtGIqg6TXmjuJzvtFkzPfSya1ppPC4P+gKtp0A/qOyq62RqgPLvwl9ZZnu62pPk1hDnMy6muzctFbF2r3lsCkgZI1uDWYj3DVOor7cM0F3N+w9cAHYai2v2SLeQwf5HdITSn2GWpC20S/bDIALPOmMgjVxk8J4AdpPxUG2Pe7DZqJY+i7RoNS31bqNA== Received: from [216.39.60.167] by nm22.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Sep 2015 14:04:53 -0000 Received: from [216.39.60.161] by tm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Sep 2015 14:04:53 -0000 Received: from [127.0.0.1] by omp1027.access.mail.gq1.yahoo.com with NNFMP; 15 Sep 2015 14:04:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 783171.64185.bm@omp1027.access.mail.gq1.yahoo.com Received: (qmail 89010 invoked by uid 60001); 15 Sep 2015 14:04:53 -0000 X-YMail-OSG: yj8dypEVM1mOM104IMDPQm9av6gjz5lF2rR1OCm1eSsc2lM P._C4oytY7invrkwFTGpOZDne2PY.9_3WmISDzNe5YkV9NgouTs.6AvywDsW qo9bpYNOb63OC4hxBfq.8J_ji.Hu6Yr_DR1zbWWk9w7atbd0LH36QHxX.be1 dhyp.SgykQa7sHI.AT8bslchyQUqG7GXRzxPKU6KsvL722v6Cn9VOd22MJK2 h0Q64iB1RxdOMUWopli.3P_bC7HnZdwyOU5U6Zhogvex2CCUwsXWqXwOynuH RkDX1nmnrOQHEevkl3Sb7lRlR3WPZR6jE3QaD1Znt4joRYlnuDXq4zSH7Odw ibvpIQI7BWp2dOih7OxDF1dM.99HbWPwNqRrBybe.RbPS030CyVShj4C1iBt LNO8ztsvf2z9LeQCgLepJgj.3U_bwLlzb7MYdFZj9aCx.mfYNjEMDiMa1PqY ZWzkj.mBMSu14BElKItne6XvcjpeOzZhYI13UETGhtmMwFE_hgT91lBd42mx rMYXOMc3CcDlw7zQpaAI5xyXZMFo2rBoaE7Jj_xQoL8h4sg8AwRS2hekZKEX NfQ2005aX Received: from [61.1.250.155] by web184304.mail.ne1.yahoo.com via HTTP; Tue, 15 Sep 2015 07:04:53 PDT X-Rocket-MIMEInfo: 002.001, SGksDQoNCldpbGwgeW91IGJlIHN1Ym1pdHRpbmcgdGhlIHBhdGNoIHVwc3RyZWFtIHRvIHN1cHBvcnQgdGhlIG5ldyBkZXZpY2UgcmV2aXNpb24_DQoNCnJnZHMsDQpTcmVlbmF0aA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT24gU2F0LCA5LzEyLzE1LCBHYXJ5IFBhbG1lciA8Z3BhbG1lckBmcmVlYnNkLm9yZz4gd3JvdGU6DQoNCiBTdWJqZWN0OiBSZTogcmVhbHRlayBpbnRlcmZhY2Ugbm90IHdvcmtpbmcNCiBUbzogIlNyZWVuYXRoIEJhdHRhbGFoYWxsaSIgPHMBMAEBAQE- X-Mailer: YahooMailBasic/685 YahooMailWebService/0.8.203.813 Message-ID: <1442325893.26688.YahooMailBasic@web184304.mail.ne1.yahoo.com> Date: Tue, 15 Sep 2015 07:04:53 -0700 From: Sreenath Battalahalli Subject: Re: realtek interface not working To: Gary Palmer Cc: Marius Strobl , freebsd-net@freebsd.org In-Reply-To: <20150912104347.GA45080@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 14:07:37 -0000 Hi, Will you be submitting the patch upstream to support the new device revisio= n? rgds, Sreenath -------------------------------------------- On Sat, 9/12/15, Gary Palmer wrote: Subject: Re: realtek interface not working To: "Sreenath Battalahalli" Cc: "Marius Strobl" , freebsd-net@freebsd.org Date: Saturday, September 12, 2015, 10:43 AM =20 On Fri, Sep 11, 2015 at 10:57:36PM -0700, Sreenath Battalahalli wrote: > Hi Marius, >=20 > Thanks for the patch. I manually made changes to the two files, and after building the kernel and installing it, > I can see the re0 interface. I am now sending this email using the new laptop. >=20 > However, I am a bit confused by the dmesg output. I see two sets of lines pertaining to the re0 device. >=20 > $dmesg | grep -i re0 > =20 > re0: port 0x3000-0x30ff mem 0xb0604000-0xb0604fff,0xb0600000-0xb0603fff irq 18 at device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: turning off MSI enable bit. > re0: ASPM disabled > re0: Chip rev. 0x54000000 > re0: MAC rev. 0x00100000 > re0: Unknown H/W revision: 0x54000000 > device_attach: re0 attach returned 6 > re0: port 0x3000-0x30ff mem 0xb0604000-0xb0604fff,0xb0600000-0xb0603fff irq 18 at device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x54000000 > re0: MAC rev. 0x00100000 > miibus0: on re0 > re0: Using defaults for TSO: 65518/35/2048 > re0: Ethernet address: 2c:60:0c:92:0f:c2 >=20 > seems the driver attempted to initialize the device twice? >=20 > Anyway, it is working now. =20 The kernel dmesg buffer can be preserved over a reboot, so it's possible the lines up to and including "device_attach: re0 attach returned 6" are from the reboot before you installed the patch.=A0 Rather than just grep for re0, do "dmesg | less" or "dmesg | more" and check the context of the=20 "device_attach: re0 attach returned 6" error and see if there are any=20 indications of a reboot between that line and the next re0 probe lines, e.g. "Copyright (c) 1992-2015 The FreeBSD Project" =20 Regards, =20 Gary From owner-freebsd-net@freebsd.org Tue Sep 15 17:47:01 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A897DA043A4 for ; Tue, 15 Sep 2015 17:47:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95300180F for ; Tue, 15 Sep 2015 17:47:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8FHl1lI094885 for ; Tue, 15 Sep 2015 17:47:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 150557] [igb] igb0: Watchdog timeout -- resetting Date: Tue, 15 Sep 2015 17:47:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 17:47:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=150557 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Feedback Timeout Status|In Progress |Closed --- Comment #5 from Sean Bruno --- Timing out this issue on 8.1 stable. Please reopen this issue or open a new ticket if this is is happening on supported releases. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Sep 15 18:43:12 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E02FEA0522E for ; Tue, 15 Sep 2015 18:43:11 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C2411038 for ; Tue, 15 Sep 2015 18:43:11 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1ZbvC6-000Ig5-41>; Tue, 15 Sep 2015 20:43:06 +0200 Received: from x5ce1b8da.dyn.telefonica.de ([92.225.184.218] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1ZbvC5-001f1W-Oi>; Tue, 15 Sep 2015 20:43:06 +0200 Date: Tue, 15 Sep 2015 20:40:04 +0200 From: "O. Hartmann" To: Ian Smith Cc: Kimmo Paasiala , freebsd-net@freebsd.org Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system Message-ID: <20150915204004.196bccb0.ohartman@zedat.fu-berlin.de> In-Reply-To: <20150915201451.L90924@sola.nimnet.asn.au> References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> <20150915201451.L90924@sola.nimnet.asn.au> Organization: FU Berlin X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/qbHkjmReRi98Voaow1Ut3Nn"; protocol="application/pgp-signature" X-Originating-IP: 92.225.184.218 X-ZEDAT-Hint: A X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 18:43:12 -0000 --Sig_/qbHkjmReRi98Voaow1Ut3Nn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 15 Sep 2015 21:08:51 +1000 (EST) Ian Smith schrieb: > On Tue, 15 Sep 2015 09:47:57 +0200, O. Hartmann wrote: > > On Tue, 15 Sep 2015 10:21:21 +0300 > > Kimmo Paasiala wrote: > >=20 > > > On Tue, Sep 15, 2015 at 10:06 AM, O. Hartmann > > > wrote: > > > > Hopefully, I'm right on this list. if not, please forward. > > > > > > > > Running CURRENT as of FreeBSD 11.0-CURRENT #3 r287780: Mon Sep 14= 13:34:16 > > > > CEST 2015 amd64, I check via nmap for open sockets since I had tro= uble > > > > protecting a server with IPFW and NAT. > > > > > > > > I see a service (nmap) > > > > > > > > Host is up (0.041s latency). > > > > Not shown: 998 filtered ports > > > > PORT STATE SERVICE > > > > 843/tcp open unknown > > > > > > > > and via sockstat -l -p 843, I get this: > > > > ? ? ? ? tcp4 *:843 *:* > > > > > > > > I double checked all services on the server and i can not figure o= ut what > > > > daemon or service is using this port. The port is exposed throught= NAT (I > > > > use in-kernel NAT on that system). > > > > This service is accessible via telnet host-ip 843: > > > > > > > > Trying 85.179.165.184... > > > > Connected to xxx.xxx.xxx.xxx. > > > > Escape character is '^]'. > > > > > > > > > > > > Well, I feel pants-down right now since it seems very hard to find= out what > > > > service is keeping this socket open for communications to the outs= ide world. > > > > > > > > Anyone any suggestions? > > > > > > > > Thanks in advance, > > > > Oliver > > >=20 > > > As delphij@ noted it's most likely something that uses rpcbind(3). W= hy > > > are your filter rules allowing unknown ports to be open to the > > > internet? Don't you have a default deny policy in place? > >=20 > > Hello. > > Many thanks for the fast response.=20 > >=20 > > I switched recently from PF to IPFW and utilise in-kernel NAT via liba= lias. I > > think the "wooden" concept of rules made me penetrate the IP filter an= d expose > > it to the outer world. The mysterious port 843/tcp isn't the only one = that is > > exposed, NFS is also. I have rules that block all incoming trafiic fro= m the > > exposed-to-the-internet interface and should allow all traffic on the = inside > > and local interfaces. The rulesets I utilised work so far on machines = without > > NAT (department, bureau, etc.). The moment NAT comes into play I do not > > understand the way IPFW works - it seems to blow a whole into any bunc= h of > > filterings walls I create. >=20 > Without seeing the ruleset you've chosen to implement, it's impossible=20 > to speculate on what might be wrong with it. Sanitise where necessary. I'm now with the box in question and I'm close to give up and get back to P= F. I will attach the ruleset at the end of the message. >=20 > > But that is an other issue and it is most likely > > due to the outdated documentation (that doc still uses port 37 for NTP > > purposes and referes to the outdated divert mechanism using natd, see = the > > recent handbook). The internet is also full of ambigous examples. >=20 > Yes, the handbook IPFW section is still crazy after all these years,=20 > despite ongoing attempts to limit the damage. Best just ignore it. "crazy" is some kind of understatement ... For starters or those migrating = from other filters, the handbook might be a good starting point. But reading about por= t 37 when it comes to NTP let me think twice ... :-(=20 >=20 > ipfw(8) is pretty much your only friend - apart from helpful people on=20 > freebsd-ipfw@freebsd.org - but it is comprehensive and almost always=20 > correct, in my 17 years using it, and I'm a long way from an expert. Yes, but there is regarding slightly complex networking (multihomed systems= , systems with NIC and WiFi where WiFi should also serve guests ...). NAT is worse describ= ed and I believe regarding in-kernel NAT, there is something missing, but I will rep= ort my experiences below with the rulesets. >=20 > > At the moment I have no access to the box since IPFW and it's reload/r= estart > > mechanism (etc/rc.d/ipfw) seems to be very instable when restartet too= often. >=20 > That needs reporting as a bug; if that's true on 11-CURRENT, it's new. The box (CURRENT as of r2878XX) was completely wrecked and inaccessible fro= m the outer world. My abilities to investigate are limited and the setup isn't as simpl= e: pppoed on the outbound interface (re0, which gets cloned to tun0 and aquires an IP fr= om the ISP. No clue how to figure out the ${if_isp} in case of restarting ppp, which leave= s me very often with tun1 or tun2 in case the tun-previous doesn't get destroyed fast= enough), a NIC to the server network, inbound, a WiFi (ath0) NIC for WLAN which is sup= posed to deal with two networks, one for the local staff/privileged and one for guests. >=20 > > I did it serveral times with moderate delays of several seconds or min= utes > > inbetween and now the box is "gone". Checking with nmap, port 22/tcp > > sometimes is open, then closed again. This is also very weird. > >=20 > > IPWF seems not to be right choice, even if it is FreeBSD native. >=20 > It's not the right choice unless you're prepared to study how it needs=20 > to be used, to the point where you can follow any flows through the=20 > ruleset. It's a compiled virtual machine language, suiting some folks=20 > better than others, rather than pf (or ipf) higher-level languages. >=20 > /etc/rc.firewall shows far more sane ways to begin with a secure=20 > firewall than those 'stateful at any cost' handbook examples. >=20 > True, there are few good published examples of using ipfw with nat,=20 > statefully, in an easily understood method. Hopefully ongoing work. >=20 > Do you have some requirement/s that pf could not provide? Well, I was now for several years, more than a decade, with pf. pf is OpenB= SD and FreeBSD utilises an older branch. My thinking is that if FreeBSD is getting more sq= ueezed out of developers, the effords invested into foreign firewall code might be reduce= d. On the other hand, some benchmarks showed that ipfw is superior in many scenarios. Dealing in the department with ipfw where the host has a single NIC and is = part of a larger network with gateway, DNS and so on, it seemed easy for me to utilis= e ipfw for my requirements. At home and at a special location with a ISP connection via DSL modem, NAT = came into play and things changed dramatically, but that is maybe something that resulted = from a big misunderstanding of mine. >=20 > > @delphi: I will give an answer as soon I gain access to the box again. > >=20 > > Regards and thanks, > >=20 > > oh =20 >=20 > Good luck, >=20 > Ian So, here I am. First, I use a patched original rc.firewall-script: --- rc.firewall 2015-08-11 23:18:21.673941000 +0200 +++ rc.firewall.local 2015-08-11 23:19:29.827737000 +0200 @@ -543,7 +543,8 @@ ;; *) if [ -r "${firewall_type}" ]; then - ${fwcmd} ${firewall_flags} ${firewall_type} + #${fwcmd} ${firewall_flags} ${firewall_type} + . ${firewall_type} fi ;; esac That makes the original code of rc.firewall being executed, the rc-variable= s sucked in and expanded and the additional script then is a #!/bin/sh shebanged script= , which has the following content, see below. Now some fun parts. The below ruleset seems to be sensitive where the NAT r= ule is placed. On local network, either NAT at the end of the ruleset list or at the begin= ning (as shown) doesn't matter - but for any outgoing connection, placing it very la= te (at the and) is lethal. Years ago I used ipfw before switching to pf and I recall that if a packet = is getting processed by NATD (means it is diverted), it has to be "reinjected" into th= e pipeline for further processing - so any succseeding rule would apply. The only hint I f= ound with the in-kernel NAT was the OIB net.inet.ip.fw.one_pass=3D0|1 Setting this OIB to 0 breaks the ruleset below - no outgoing (real-world IP= addresses) connection is possible. So I stay with 1 and that implies that after the in= coming packet=20 gets processed by NAT and then the ipfw pipe terminates, nothing else then = ... [...] #!/bin/sh # ISP interface, identical with firewall_nat_interface, from rc.conf if_isp=3D${firewall_nat_interface} #(expands to tun0, given by pppoed) if_lan0=3D"em0" # WiFi if_wlan0=3D"wlan0" # WiFi guests if_wlan1=3D"wlan1" net_local=3D"192.168.0.1/24" net_wlan=3D"192.168.2.1/24" net_good=3D"{ 192.168.0.1/24, 192.168.2.1/24 }" net_guest=3D"192.168.254.1/24" server_gate=3D"192.168.0.1" tcp_services=3D"22,80,443,5432,9734" udp_services=3D"" icmp_services=3D"0,8" ################################################################# # Setup in kernel NAT ################################################################# ${fwcmd} nat 1 config if ${if_isp} log reset same_ports \ redirect_port tcp ${server_gate}:22 22 redirect_port tcp ${server_g= ate}:443 443 \ redirect_port tcp ${server_gate}:5432 5432 redirect_port tcp ${serv= er_gate}:9734 9734 ################################################################# # Bad address table ################################################################# BAD_ADDRESS_TBL=3D13 # ${fwcmd} table ${BAD_ADDRESS_TBL} create ${fwcmd} table ${BAD_ADDRESS_TBL} flush # ${fwcmd} table ${BAD_ADDRESS_TBL} add 192.168.0.0/16 #RFC 1918 p= rivate IP ${fwcmd} table ${BAD_ADDRESS_TBL} add 172.16.0.0/12 #RFC 1918 p= rivate IP ${fwcmd} table ${BAD_ADDRESS_TBL} add 10.0.0.0/8 #RFC 1918 p= rivate IP ${fwcmd} table ${BAD_ADDRESS_TBL} add 127.0.0.0/8 #loopback ${fwcmd} table ${BAD_ADDRESS_TBL} add 0.0.0.0/8 #loopback ${fwcmd} table ${BAD_ADDRESS_TBL} add 169.254.0.0/16 #DHCP auto-= config ${fwcmd} table ${BAD_ADDRESS_TBL} add 192.0.2.0/24 #reserved f= or docs ${fwcmd} table ${BAD_ADDRESS_TBL} add 204.152.64.0/23 #Sun cluste= r interconnect ${fwcmd} table ${BAD_ADDRESS_TBL} add 224.0.0.0/3 #Class D & = E multicast # ${fwcmd} add deny all from any to "table(${BAD_ADDRESS_TBL})" via ${if_i= sp} ################################################################# # Antispoof ################################################################# ${fwcmd} add deny log ip from any to any not verrevpath in ################################################################# # NAT ################################################################# #${fwcmd} add nat 1 all from any to any via ${if_isp} ################################################################# # Reassemble ################################################################# ${fwcmd} add reass all from any to any in ################################################################# # NAT ################################################################# ${fwcmd} add nat 1 all from any to any via ${if_isp} ################################################################# # dynamic ruleset ################################################################# ${fwcmd} add check-state ################################################################# # Established/fragmented ################################################################# ${fwcmd} add deny tcp from any to any established ${fwcmd} add deny tcp from any to any frag ################################################################# # Allow ISP's DHCP ################################################################# ${fwcmd} add pass log udp from ${if_isp} to any 67 out via ${if_isp} kee= p-state ${fwcmd} add pass log udp from any to ${if_isp} 67 in via ${if_isp} keep= -state ################################################################# # Local net/guest net ################################################################# #${fwcmd} add pass all from any to any via ${if_lan0} #${fwcmd} add pass all from any to any via ${if_wlan0} #${fwcmd} add pass all from any to any via ${if_wlan1} ################################################################# # Allow outgoing connections ################################################################# ${fwcmd} add pass tcp from ${net_good} to any setup keep-state ${fwcmd} add pass udp from ${net_good} to any keep-state ${fwcmd} add pass icmp from ${net_good} to any keep-state ################################################################# # Allow network guests ################################################################# ${fwcmd} add pass tcp from ${net_guest} to any via ${if_isp} setup keep-= state ${fwcmd} add pass udp from ${net_guest} to any via ${if_isp} keep-state ${fwcmd} add pass icmp from ${net_guest} to any via ${if_isp} icmptypes = 0,8 keep-state ################################################################# # Traffic to local server ################################################################# ${fwcmd} add pass tcp from any to ${server_gate} ${tcp_services} setup k= eep-state ${fwcmd} add pass udp from any to ${server_gate} ${udp_services} keep-st= ate ${fwcmd} add pass icmp from any to ${server_gate} icmptypes ${icmp_servi= ces} keep-state ################################################################# # Deny and log everything else ################################################################# ${fwcmd} add deny log all from any to any --Sig_/qbHkjmReRi98Voaow1Ut3Nn Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV+GYEAAoJEOgBcD7A/5N8hugH/0E4z5+C84vKmRoseY9JTKIP SJ2asWoe/otpqokofmXyIEuetKE5/fzOjf42cDRu9Yr3fgB1lqoHfL6XJy6Gx+v1 bUVqiVDiBYmChYgCt0LmSKC0fTU0wDihqeyaAfiQqMZMTsUvRRU8K8ARfzCQgtYQ MaDPQCryilfPUX4RynC2k3sg8vobTPqwDGU5xYt3tgpcQow0SBwxGh6GabX/FBo2 MkqqxHcvjQ+fC4uTC7Cg93c7r8fXf6metlzLtG9Rsjp3jZGcyxY+opjuYPQaCbuO 9+LtRv+fTsfslVEPlUm4tmAdpTA/sy5sHJ3DESBfAU5KHb60rMcpcBROJfUYiZw= =Y6wF -----END PGP SIGNATURE----- --Sig_/qbHkjmReRi98Voaow1Ut3Nn-- From owner-freebsd-net@freebsd.org Tue Sep 15 18:59:39 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9E25A059E6 for ; Tue, 15 Sep 2015 18:59:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 968F8194E for ; Tue, 15 Sep 2015 18:59:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8FIxdUx075685 for ; Tue, 15 Sep 2015 18:59:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202680] Silent data corruption on em(4) interfaces Date: Tue, 15 Sep 2015 18:59:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 18:59:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202680 --- Comment #11 from Sean Bruno --- (In reply to Dmitry Afanasiev from comment #10) Can you see if this change in head helps with your issue. https://svnweb.freebsd.org/base?view=revision&revision=287330 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Sep 15 19:44:15 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD975A051F1 for ; Tue, 15 Sep 2015 19:44:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA25410F5 for ; Tue, 15 Sep 2015 19:44:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8FJiF9V084374 for ; Tue, 15 Sep 2015 19:44:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202680] Silent data corruption on em(4) interfaces Date: Tue, 15 Sep 2015 19:44:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: KOT@MATPOCKuH.Ru X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 19:44:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202680 --- Comment #12 from Dmitry Afanasiev --- (In reply to Sean Bruno from comment #11) sys/dev/e1000 in head have many differences from stable/10. For example different lem's driver version: < char lem_driver_version[] = "1.0.6"; --- > char lem_driver_version[] = "1.1.0"; Should I use entire sys/dev/e1000 directory from head in my stable/10 system? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Sep 15 20:16:20 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 973729C20C2 for ; Tue, 15 Sep 2015 20:16:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8359C15B3 for ; Tue, 15 Sep 2015 20:16:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8FKGKIs068195 for ; Tue, 15 Sep 2015 20:16:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202680] Silent data corruption on em(4) interfaces Date: Tue, 15 Sep 2015 20:16:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: KOT@MATPOCKuH.Ru X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 20:16:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202680 --- Comment #13 from Dmitry Afanasiev --- (In reply to Dmitry Afanasiev from comment #12) sys/dev/e1000 tree from head is not compatible with stable/10 :( -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Sep 15 21:19:24 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63A019C29DB for ; Tue, 15 Sep 2015 21:19:24 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EE7761E6F; Tue, 15 Sep 2015 21:19:23 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id t8FLJKja046962 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Sep 2015 23:19:20 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id t8FLJKQo046953; Tue, 15 Sep 2015 23:19:20 +0200 (CEST) (envelope-from marius) Date: Tue, 15 Sep 2015 23:19:20 +0200 From: Marius Strobl To: Sreenath Battalahalli Cc: Gary Palmer , freebsd-net@freebsd.org Subject: Re: realtek interface not working Message-ID: <20150915211920.GC18789@alchemy.franken.de> References: <20150912104347.GA45080@in-addr.com> <1442325893.26688.YahooMailBasic@web184304.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442325893.26688.YahooMailBasic@web184304.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Tue, 15 Sep 2015 23:19:20 +0200 (CEST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Sep 2015 21:19:24 -0000 On Tue, Sep 15, 2015 at 07:04:53AM -0700, Sreenath Battalahalli wrote: > Hi, > > Will you be submitting the patch upstream to support the new device revision? > Hi, I committed in r287768 and will MFC it to stable/10 in a week or so. Marius From owner-freebsd-net@freebsd.org Wed Sep 16 10:53:20 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08EB79C2F41 for ; Wed, 16 Sep 2015 10:53:20 +0000 (UTC) (envelope-from nbe@renzel.net) Received: from nijmegen.renzel.net (mx1.renzel.net [195.243.213.130]) by mx1.freebsd.org (Postfix) with ESMTP id 6C0E01C18 for ; Wed, 16 Sep 2015 10:53:18 +0000 (UTC) (envelope-from nbe@renzel.net) Received: from dublin.vkf.isb.de.renzel.net (unknown [10.0.0.80]) by nijmegen.renzel.net (smtpd) with ESMTP id 648B714148AB for ; Wed, 16 Sep 2015 12:52:12 +0200 (CEST) Received: from asbach.renzel.net (unknown [172.18.96.1]) by dublin.vkf.isb.de.renzel.net (Postfix) with ESMTP id 45A03603E2 for ; Wed, 16 Sep 2015 12:52:12 +0200 (CEST) From: Nils Beyer Organization: VKF Renzel GmbH Date: Wed, 16 Sep 2015 12:52:11 +0200 User-Agent: KNode/4.14.3 Subject: Re: Multipath TCP for FreeBSD v0.5 To: freebsd-net@freebsd.org References: <55E54846.4020504@swin.edu.au> Lines: 342 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.98 at nijmegen.renzel.net X-Virus-Status: Clean X-Spam-Status: No, score=4.2 required=7.0 tests=DC_IMAGE_SPAM_HTML, DC_IMAGE_SPAM_TEXT,DC_PNG_UNO_LARGO,DNS_FROM_AHBL_RHSBL,MISSING_MID, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on nijmegen.renzel.net Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 16 Sep 2015 10:53:20 -0000 Hi Nigel, Nigel Williams wrote: > A new mptcp v0.5 patch is available at > http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html. thanks for the new patch. I've tried your provided VirtualBox VM "FB11-test1". Unfortunately, standard TCP-connections aren't working. For instance, after I execute: fetch -o - 'http://www.google.com' I get an incomplete transfer that times out after a while. Sometimes I get a kernel panic (s. attached screenshot). Then I tried the patch on real hardware (built my own kernel as described). Same behaviour. Is it intended that the current implementation is not backwards compatible to non-MPTCP-connections? If you need any more details, feel free to contact me... Regards, Nils From owner-freebsd-net@freebsd.org Wed Sep 16 11:03:13 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 793399CD6FD for ; Wed, 16 Sep 2015 11:03:13 +0000 (UTC) (envelope-from nbe@renzel.net) Received: from nijmegen.renzel.net (mx1.renzel.net [195.243.213.130]) by mx1.freebsd.org (Postfix) with ESMTP id 4191610C0 for ; Wed, 16 Sep 2015 11:03:12 +0000 (UTC) (envelope-from nbe@renzel.net) Received: from dublin.vkf.isb.de.renzel.net (unknown [10.0.0.80]) by nijmegen.renzel.net (smtpd) with ESMTP id A8D8A1414877 for ; Wed, 16 Sep 2015 13:03:10 +0200 (CEST) Received: from asbach.renzel.net (unknown [172.18.96.1]) by dublin.vkf.isb.de.renzel.net (Postfix) with ESMTP id 9F6A36054E for ; Wed, 16 Sep 2015 13:03:10 +0200 (CEST) Content-Type: text/plain; charset="ISO-8859-1" From: Nils Beyer Organization: VKF Renzel GmbH Date: Wed, 16 Sep 2015 13:03:10 +0200 User-Agent: KNode/4.14.3 Content-Transfer-Encoding: 7Bit Subject: Re: Multipath TCP for FreeBSD v0.5 To: freebsd-net@freebsd.org References: <55E54846.4020504@swin.edu.au> <12290.6160344884$1442400817@news.gmane.org> Lines: 11 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.98 at nijmegen.renzel.net X-Virus-Status: Clean X-Spam-Status: No, score=3.2 required=7.0 tests=DNS_FROM_AHBL_RHSBL, MISSING_MID,UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on nijmegen.renzel.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 16 Sep 2015 11:03:13 -0000 I wrote: > [...] Sometimes I get a kernel panic (s. attached screenshot). attachment has been stripped. If you need the screenshot or crash dumps, please let me know then I think about a way to provide them. As these are VMs you should be able to reconstruct the behaviour as well... Regards, Nils From owner-freebsd-net@freebsd.org Wed Sep 16 15:06:01 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A6399CE052; Wed, 16 Sep 2015 15:06:01 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8CFD71E7B; Wed, 16 Sep 2015 15:05:59 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t8GF5obW092775; Thu, 17 Sep 2015 01:05:50 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 17 Sep 2015 01:05:50 +1000 (EST) From: Ian Smith To: Warren Block cc: "O. Hartmann" , Kimmo Paasiala , freebsd-net@freebsd.org, Lev Serebryakov , freebsd-ipfw@freebsd.org Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system In-Reply-To: Message-ID: <20150916235555.F82084@sola.nimnet.asn.au> References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> <20150915201451.L90924@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 16 Sep 2015 15:06:01 -0000 On Tue, 15 Sep 2015 07:51:11 -0600 (MDT), Warren Block wrote: > On Tue, 15 Sep 2015, Ian Smith wrote: > O. Hartmann wrote: > > > But that is an other issue and it is most likely > > > due to the outdated documentation (that doc still uses port 37 for NTP > > > purposes and referes to the outdated divert mechanism using natd, see the > > > recent handbook). The internet is also full of ambigous examples. > > > > Yes, the handbook IPFW section is still crazy after all these years, > > despite ongoing attempts to limit the damage. Best just ignore it. > > Best overall would be to fix the documentation. Oh, absolutely. But it can't be me, for reasons I'll mail you about. I've become reluctant to talk about what I can't fix, but when I see people in trouble due to that section, I'm compelled to so advise. > Given that there seems to be more interest in IPFW lately, it would > be nice if someone well-versed in it would repair or even rewrite the > IPFW handbook section. Rewrites are sometimes less work than fixing > an old section that no longer fits actual usage. Exactly the conclusion I'd come to after an effort last October to correct some of the more egregious errors, including the one Oliver mentions above and quite a lot else. In reviewing that today, I see I got some things wrong myself :) but I'll send it to you anyway. It's nothing more than a start, and only saved-as text, not in doc markup. > I have not used IPFW in years, but would be willing to help with an > edit/rewrite. Well if you're prepared to coordinate efforts, I'll certainly review and contribute as best I can. There was another offer in ipfw@ to assist in a rewrite recently. If you're up for it, I'll shunt that your way too? I've a feeling that the best way to do a lot of this would be by brief sections that mostly just pointed to sections of (online) ipfw(8); e.g. even the basic description is best covered by ipfw(8)'s /DESCRIPTION .. so a good index into that with some extra pointers and tips might work. But we really need some good examples of ipfw + nat with stateful rules that actually work properly. I found one saved good(-looking :) ruleset from 2012 with the sort of multiple interfaces and subnets Oliver needs, by Lev Serebryakov , who's more recently been working on adding new rules to better handle timing/placement of state checking including in NAT scenarios, who I poke occasionally - like now - to provide some worked examples :) I think freebsd-ipfw@ may be a better place to take this now .. cc'd. cheers, Ian From owner-freebsd-net@freebsd.org Wed Sep 16 21:24:59 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 036F49C2A9A for ; Wed, 16 Sep 2015 21:24:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E33D014C7 for ; Wed, 16 Sep 2015 21:24:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8GLOwiQ019133 for ; Wed, 16 Sep 2015 21:24:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 138407] [gre] gre(4) interface does not come up after reboot Date: Wed, 16 Sep 2015 21:24:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 7.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cmb@pfsense.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 16 Sep 2015 21:24:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138407 cmb@pfsense.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cmb@pfsense.org --- Comment #4 from cmb@pfsense.org --- this is a duplicate of 164475, which was recently fixed. Should be safe to close. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Sep 17 01:08:56 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E324B9CEF69 for ; Thu, 17 Sep 2015 01:08:56 +0000 (UTC) (envelope-from njwilliams@swin.edu.au) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 671B01578 for ; Thu, 17 Sep 2015 01:08:55 +0000 (UTC) (envelope-from njwilliams@swin.edu.au) Received: from [136.186.242.223] (vpn242-223.cc.swin.edu.au [136.186.242.223]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id t8H18qp5002099 for ; Thu, 17 Sep 2015 11:08:52 +1000 Subject: Re: Multipath TCP for FreeBSD v0.5 To: freebsd-net@freebsd.org References: <55E54846.4020504@swin.edu.au> <201509161053.t8GArV74012141@gpo2.cc.swin.edu.au> From: Nigel Williams Message-ID: <55FA12A3.2090800@swin.edu.au> Date: Thu, 17 Sep 2015 11:08:51 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <201509161053.t8GArV74012141@gpo2.cc.swin.edu.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Sep 2015 01:08:57 -0000 Hi Nils, On 16/09/15 20:52, Nils Beyer wrote: > Hi Nigel, > > Nigel Williams wrote: >> A new mptcp v0.5 patch is available at >> http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html. > > thanks for the new patch. I've tried your provided VirtualBox VM "FB11-test1". > > Unfortunately, standard TCP-connections aren't working. For instance, after I > execute: > > fetch -o - 'http://www.google.com' > > I get an incomplete transfer that times out after a while. Sometimes I get > a kernel panic (s. attached screenshot). > > Then I tried the patch on real hardware (built my own kernel as described). > Same behaviour. > > Is it intended that the current implementation is not backwards compatible > to non-MPTCP-connections? If you need any more details, feel free to contact > me... > Thanks for taking a look at the patch. The patch should be backwards compatible with TCP, though as you've observed there are still issues with stalls and crashes (I've only so far done limited testing within my testbed). I was able to replicate the stall on one of the VMs - so I'll take a look at what might be happening. Thanks for letting me know. cheers, nigel > > > Regards, > Nils > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Thu Sep 17 12:44:40 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E5A99CF4BF for ; Thu, 17 Sep 2015 12:44:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A69910CA for ; Thu, 17 Sep 2015 12:44:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8HCie5D008810 for ; Thu, 17 Sep 2015 12:44:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 138407] [gre] gre(4) interface does not come up after reboot Date: Thu, 17 Sep 2015 12:44:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 7.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Sep 2015 12:44:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138407 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed CC| |ae@FreeBSD.org Resolution|--- |DUPLICATE --- Comment #5 from Andrey V. Elsukov --- *** This bug has been marked as a duplicate of bug 164475 *** -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Sep 17 16:57:51 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 672E69CF615 for ; Thu, 17 Sep 2015 16:57:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 541A515E7 for ; Thu, 17 Sep 2015 16:57:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8HGvpwk000542 for ; Thu, 17 Sep 2015 16:57:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 172895] [ixgb] [ixgbe] do not properly determine link-state Date: Thu, 17 Sep 2015 16:57:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-PRERELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: asomers@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Sep 2015 16:57:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172895 Alan Somers changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asomers@FreeBSD.org --- Comment #5 from Alan Somers --- I can also reproduce this issue. Anytime that the interface is down or up but without an IP address, the link state is "no carrier". Is there any way to disable "power saving support"? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Sep 17 17:05:56 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D6689CFB45 for ; Thu, 17 Sep 2015 17:05:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A5731EED for ; Thu, 17 Sep 2015 17:05:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8HH5tVi049690 for ; Thu, 17 Sep 2015 17:05:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 172895] [ixgb] [ixgbe] do not properly determine link-state Date: Thu, 17 Sep 2015 17:05:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-PRERELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Sep 2015 17:05:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172895 --- Comment #6 from Sean Bruno --- (In reply to Alan Somers from comment #5) Yeah, I *just* ran into this today. Very confusing. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Sep 17 17:21:57 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C1619CF092 for ; Thu, 17 Sep 2015 17:21:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D4C51AEC for ; Thu, 17 Sep 2015 17:21:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbni9 with SMTP id ni9so193177igb.0 for ; Thu, 17 Sep 2015 10:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JnzQOFY0RlqQrY+5n7Ss6qTP/VjinF9sww2pYYcsk48=; b=tROo7auI1E+ij/0d2gQM3SCcRezhTzJD1UZD79VQ81+aGLd/5oS1agmoPl/DiktZ8m kdSjt6D6ZoIMPGiWlhy9P6JXt4iG6c9EPnbB52bvVAK0K7hHfoeOgKwWfXDhRXcVOv3f aDiyA9RoDL20Z/M+yRJOltBprKQIUP0168iZBlD6s7yTBX/dR2RaOkA8RpgI5o48QVXG pZwQruBhbbJCHK1r9Eq0nczwKGvEUHTMNOKA21x91qoL4D7qn/VybN3LlaLWbJFmG9v7 zDf4FH57KcVbGykhPwU17Xk9WQKkW1TwfI9M791v7ayuhS3e+yP3S15DGbkvEkhLcrPp 1OTQ== MIME-Version: 1.0 X-Received: by 10.50.45.33 with SMTP id j1mr8039380igm.61.1442510516495; Thu, 17 Sep 2015 10:21:56 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Thu, 17 Sep 2015 10:21:56 -0700 (PDT) Date: Thu, 17 Sep 2015 10:21:56 -0700 Message-ID: Subject: time to extend the mbuf From: Adrian Chadd To: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Sep 2015 17:21:57 -0000 Hi, I think it's time to extend the mbuf pkthdr a little. I need a couple of fields for ipv6 header parsing w/ RSS and netisr; hps/mellanox want to use fields for opaque socket / session ids for rate limiting; I'm sure chelsio and such would love to be able to stamp buffers with an opaque id for RX zero-copy offload, etc. So, who's up for it? I'd like to get it extended and in -HEAD sooner rather than later so we can stop squabbling over unused bits and mis-understood fields in the mbuf. Thanks! -adrian From owner-freebsd-net@freebsd.org Thu Sep 17 22:36:08 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6294D9CE720 for ; Thu, 17 Sep 2015 22:36:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F97F1863 for ; Thu, 17 Sep 2015 22:36:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8HMa8FO020564 for ; Thu, 17 Sep 2015 22:36:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203031] LACP problem with FreeBSD 10.2-RELEASE Date: Thu, 17 Sep 2015 22:36:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: gondim@bsdinfo.com.br X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Sep 2015 22:36:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203031 --- Comment #1 from gondim@bsdinfo.com.br --- Today I tried to run my router with the latest 10.2-STABLE and noticed the following problem: When I'm using the 10.1-STABLE r281235 and my OpenBGP starts to open the sessions, the load remains at 4.x and with high traffic, the load increases to 9.x Using the latest 10.2-STABLE, when my OpenBGP start to open the sessions, the load rises to 14.x and with high traffic, the load increases to 40.x, 53.x. Something made very drop system performance with large traffic but I have no idea at what time it happened. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Fri Sep 18 09:12:26 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DB8C9CF6EE for ; Fri, 18 Sep 2015 09:12:26 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from mail.pingpong.net (mail.pingpong.net [79.136.116.202]) by mx1.freebsd.org (Postfix) with ESMTP id 89B3F1033 for ; Fri, 18 Sep 2015 09:12:25 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from [10.0.0.106] (citron2.pingpong.net [195.178.173.68]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pingpong.net (Postfix) with ESMTPSA id A8E11D46C for ; Fri, 18 Sep 2015 11:12:24 +0200 (CEST) From: Palle Girgensohn X-Pgp-Agent: GPGMail 2.5.1 Content-Type: multipart/signed; boundary="Apple-Mail=_01FBA4B0-EF73-4CB8-99C4-F64C62528B2D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Subject: Kernel panics in tcp_twclose Date: Fri, 18 Sep 2015 11:12:23 +0200 Message-Id: <26B0FF93-8AE3-4514-BDA1-B966230AAB65@FreeBSD.org> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 18 Sep 2015 09:12:26 -0000 --Apple-Mail=_01FBA4B0-EF73-4CB8-99C4-F64C62528B2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, We see daily panics on our production systems (web server, apache = running MPM event, openjdk8. Kernel with VIMAGE. Jails using netgraph = interfaces [not epair]). The problem started after the summer. Normal port upgrades seems to be = the only difference. The problem occurs with 10.2-p2 kernel as well as = 10.1-p4 and 10.1-p15. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203175 Any ideas? (kgdb) #0 doadump (textdump=3D) at pcpu.h:219 #1 0xffffffff80949a42 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xffffffff80949e25 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0xffffffff80949cb3 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:687 #4 0xffffffff80d5cf9b in trap_fatal (frame=3D, eva=3D) at /usr/src/sys/amd64/amd64/trap.c:851 #5 0xffffffff80d5d29d in trap_pfault (frame=3D0xfffffe1760bc1840, usermode=3D) at = /usr/src/sys/amd64/amd64/trap.c:674 #6 0xffffffff80d5c93a in trap (frame=3D0xfffffe1760bc1840) at /usr/src/sys/amd64/amd64/trap.c:440 #7 0xffffffff80d42cb2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #8 0xffffffff809984cc in turnstile_broadcast (ts=3D0x0, queue=3D1) at /usr/src/sys/kern/subr_turnstile.c:838 #9 0xffffffff809480c0 in __rw_wunlock_hard (c=3D0xfffff8123b287618, = tid=3D1, file=3D0x1
, line=3D1) at /usr/src/sys/kern/kern_rwlock.c:988 #10 0xffffffff80b066a4 in tcp_twclose (tw=3D, reuse=3D) at = /usr/src/sys/netinet/tcp_timewait.c:540 #11 0xffffffff80b06ceb in tcp_tw_2msl_scan (reuse=3D0) at /usr/src/sys/netinet/tcp_timewait.c:748 #12 0xffffffff80b049be in tcp_slowtimo () at /usr/src/sys/netinet/tcp_timer.c:198 #13 0xffffffff809b78b4 in pfslowtimo (arg=3D0x0) at /usr/src/sys/kern/uipc_domain.c:508 #14 0xffffffff8095f8db in softclock_call_cc (c=3D0xffffffff81620bf0, cc=3D0xffffffff8169dc00, direct=3D0) at = /usr/src/sys/kern/kern_timeout.c:685 #15 0xffffffff8095fd04 in softclock (arg=3D0xffffffff8169dc00) at /usr/src/sys/kern/kern_timeout.c:814 #16 0xffffffff809158eb in intr_event_execute_handlers ( p=3D, ie=3D0xfffff801102e0d00) at /usr/src/sys/kern/kern_intr.c:1264 #17 0xffffffff80915d36 in ithread_loop (arg=3D0xfffff801102adee0) at /usr/src/sys/kern/kern_intr.c:1277 #18 0xffffffff8091343a in fork_exit ( callout=3D0xffffffff80915ca0 , arg=3D0xfffff801102adee0,= frame=3D0xfffffe1760bc1c00) at /usr/src/sys/kern/kern_fork.c:1018 #19 0xffffffff80d431ee in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611 #20 0x0000000000000000 in ?? () --Apple-Mail=_01FBA4B0-EF73-4CB8-99C4-F64C62528B2D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJV+9V4AAoJEIhV+7FrxBJD2rEIAINp8YBskB9qo+Ejc8qL9XM4 8nYbaQE3nvYiKQlw0xOFLkZP2qDEH0a2cZ4slOn37YuaMWIik5LXAT3Dd/AARRdl OMdaXx3jCMhJ+MfAzMP8XeB186j07z7V81KVsnjoAnbQcFgJtFvjET9fM20Nbuvq LXnXXWn/ZQWKXOcPe/k1g3wj+7Psjy6FHS5oskqWg3EkA7qMkXZ3ebGI3NmJgwvj LkJaE2aj2ykRl87nCj0kV0pU/gDNeUEra4POL0tXgQNlYiOFB64CW13leflw5vYh vJTCKQVvnKm0TyXBu1IlUdcgexm1RcKqsBXSh60mPEBEKoQo+3zfVS6WIfaAE7I= =IUS0 -----END PGP SIGNATURE----- --Apple-Mail=_01FBA4B0-EF73-4CB8-99C4-F64C62528B2D-- From owner-freebsd-net@freebsd.org Fri Sep 18 13:56:50 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55BA59CE418 for ; Fri, 18 Sep 2015 13:56:50 +0000 (UTC) (envelope-from julien@jch.io) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E075917E5 for ; Fri, 18 Sep 2015 13:56:49 +0000 (UTC) (envelope-from julien@jch.io) Received: by wicfx3 with SMTP id fx3so65485259wic.1 for ; Fri, 18 Sep 2015 06:56:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=mUzGopqvslYoMXy5dJJ09p4yLg1NfgNHUaa/W/9jAeg=; b=arD0kX25h+Q1ea00UAfdmQHa4zg7mTpCdD0AsCIE27ku5ddeM3g0wXSqbub9eQsyKE EEk9I6DVqcOlI9DSqg166G/eZawiZ5FpFVx0MtnVlFqO5K1tNGurQpwFWs2tWXd/boO8 fNqmSGHqt5rjTGyzVeaRxBfg6RSj9CXKc6MJgikobMHxDXsbCkPnnlaJhGHgX8hAnJv6 b7UOcBwo/nXInkYYzvxTuloVhpCzAHYvpk3v6lzqOpCOLZtsYhf8nKEVDfvTItENkIFk iJMPTqf8SOBBOpBioUxO+7IIeAO/lSH8ykTYxD9KnULnWfZkep1QA9595JNLH5tM4zcg aJoA== X-Gm-Message-State: ALoCoQkkaXycIAnLPu0/O819ACKVYcHEQFPMYb/A7KyYfCUiCJrsV4rWt+ScMONJPRu8tIpIhJm8 X-Received: by 10.194.92.68 with SMTP id ck4mr8036020wjb.141.1442584601841; Fri, 18 Sep 2015 06:56:41 -0700 (PDT) Received: from del2sochahar-l1.vcorp.ad.vrsn.com ([217.30.88.7]) by smtp.googlemail.com with ESMTPSA id j7sm9040905wjz.11.2015.09.18.06.56.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2015 06:56:41 -0700 (PDT) Subject: Re: Kernel panics in tcp_twclose To: Palle Girgensohn , freebsd-net@freebsd.org References: <26B0FF93-8AE3-4514-BDA1-B966230AAB65@FreeBSD.org> From: Julien Charbon X-Enigmail-Draft-Status: N1110 Message-ID: <55FC1809.3070903@freebsd.org> Date: Fri, 18 Sep 2015 15:56:25 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <26B0FF93-8AE3-4514-BDA1-B966230AAB65@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FWnD3UtvklttSg1bb2eNanqOQTxu4rfff" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 18 Sep 2015 13:56:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FWnD3UtvklttSg1bb2eNanqOQTxu4rfff Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Palle, On 18/09/15 11:12, Palle Girgensohn wrote: > We see daily panics on our production systems (web server, apache > running MPM event, openjdk8. Kernel with VIMAGE. Jails using netgraph > interfaces [not epair]). >=20 > The problem started after the summer. Normal port upgrades seems to > be the only difference. The problem occurs with 10.2-p2 kernel as > well as 10.1-p4 and 10.1-p15. >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203175 >=20 > Any ideas? Thanks for you detailed report. I am not aware of any tcp_twclose() related issues (without VIMAGE) since FreeBSD 10.0 (does not mean there are none). Few interesting facts (at least for me): - Your crash happens when unlocking a inp exclusive lock with INP_WUNLOC= K() - Something is already wrong before calling turnstile_broadcast() as it is called with ts =3D NULL: turnstile_broadcast (ts=3D0x0, queue=3D1) at /usr/src/sys/kern/subr_turnstile.c:838 __rw_wunlock_hard () at /usr/src/sys/kern/kern_rwlock.c:988 tcp_twclose () at /usr/src/sys/netinet/tcp_timewait.c:540 tcp_tw_2msl_scan () at /usr/src/sys/netinet/tcp_timewait.c:748 tcp_slowtimo () at /usr/src/sys/netinet/tcp_timer.c:198 I won't go to far here as I am not expert enough in VIMAGE, but one question anyway: - Can you correlate this kernel panic to a particular event? Like for example a VIMAGE/VNET jail destruction. I will test that on my side on a 10.2 machine. -- Julien --FWnD3UtvklttSg1bb2eNanqOQTxu4rfff Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJV/BgXAAoJEKVlQ5Je6dhxf8IH/iko4HYhG6QLHsbJ+5HcSJVk xJz/PWyaLtsFsvOQVszXWU8MtsC1HkWyvv+5yJdMbEDPSj0sxG+DJ0jVqliNSidu 6opF68HjoqOzo+piBDyvxzQOXtDnofjfEDNRdXtRh49LL9QcvxmQHViWvSHJg8iw 82qdfdCrbUr7dJWknjR6EAvRjrFbZe37neFXkSfRKJqrS7sOohV4DXBa5NqPcamw ANJOne7YgYW4T1iSUZP7QQLNtJYQp5PtLt4e7rLNFg1TcTS9l9iGlEdlWtUU+jEd Dgd8jwyrQ3LajHE9CclSNmU29cGi9nYZy5ifH3UpKh/QyhuiqFc5brx73TMBcxY= =QeCn -----END PGP SIGNATURE----- --FWnD3UtvklttSg1bb2eNanqOQTxu4rfff-- From owner-freebsd-net@freebsd.org Fri Sep 18 14:29:06 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85C689CFAA8 for ; Fri, 18 Sep 2015 14:29:06 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from mail.pingpong.net (mail.pingpong.net [79.136.116.202]) by mx1.freebsd.org (Postfix) with ESMTP id 45ACA18DA; Fri, 18 Sep 2015 14:29:05 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from [10.0.0.106] (citron2.pingpong.net [195.178.173.68]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pingpong.net (Postfix) with ESMTPSA id 46967D246; Fri, 18 Sep 2015 16:28:58 +0200 (CEST) Subject: Re: Kernel panics in tcp_twclose using jails + VIMAGE Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0D107C28-45CE-4957-9CD0-8DCB8DFC6727"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.1 From: Palle Girgensohn In-Reply-To: <55FC1809.3070903@freebsd.org> Date: Fri, 18 Sep 2015 16:28:57 +0200 Cc: freebsd-net@freebsd.org Message-Id: References: <26B0FF93-8AE3-4514-BDA1-B966230AAB65@FreeBSD.org> <55FC1809.3070903@freebsd.org> To: Julien Charbon X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 18 Sep 2015 14:29:06 -0000 --Apple-Mail=_0D107C28-45CE-4957-9CD0-8DCB8DFC6727 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > 18 sep 2015 kl. 15:56 skrev Julien Charbon : >=20 > Hi Palle, >=20 > On 18/09/15 11:12, Palle Girgensohn wrote: >> We see daily panics on our production systems (web server, apache >> running MPM event, openjdk8. Kernel with VIMAGE. Jails using netgraph >> interfaces [not epair]). >>=20 >> The problem started after the summer. Normal port upgrades seems to >> be the only difference. The problem occurs with 10.2-p2 kernel as >> well as 10.1-p4 and 10.1-p15. >>=20 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203175 >>=20 >> Any ideas? >=20 > Thanks for you detailed report. I am not aware of any tcp_twclose() > related issues (without VIMAGE) since FreeBSD 10.0 (does not mean = there > are none). Few interesting facts (at least for me): >=20 > - Your crash happens when unlocking a inp exclusive lock with = INP_WUNLOCK() >=20 > - Something is already wrong before calling turnstile_broadcast() as = it > is called with ts =3D NULL: >=20 > turnstile_broadcast (ts=3D0x0, queue=3D1) at > /usr/src/sys/kern/subr_turnstile.c:838 > __rw_wunlock_hard () at /usr/src/sys/kern/kern_rwlock.c:988 > tcp_twclose () at /usr/src/sys/netinet/tcp_timewait.c:540 > tcp_tw_2msl_scan () at /usr/src/sys/netinet/tcp_timewait.c:748 > tcp_slowtimo () at /usr/src/sys/netinet/tcp_timer.c:198 >=20 > I won't go to far here as I am not expert enough in VIMAGE, but one > question anyway: >=20 > - Can you correlate this kernel panic to a particular event? Like for > example a VIMAGE/VNET jail destruction. >=20 > I will test that on my side on a 10.2 machine. >=20 > -- > Julien >=20 Hi, thank for your reply. It is not related to jail destruction. It = *might* be related to apache httpd (MPM event) forking during normal = operation, but we have not found any specific event that triggers the = panic. The system crash during normal operation, no excessive load (but = load is at least partly responsible, a more loaded server is more likely = to crash). Note that we use netgraph, not epair, although I don't believe it makes = a difference. Palle --Apple-Mail=_0D107C28-45CE-4957-9CD0-8DCB8DFC6727 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJV/B+pAAoJEIhV+7FrxBJDBb8H/RXUyYSm2xIRAT0/gIGLbQVh rLyEOPQcbQ4ST319Gtf/Us99qy2zF973m3FMlmeeuN5hmqB9I0KHPxskD7HZKd00 5kzXAvbsot8f96629sc7Vpp62XWXpd5kvO4uNijbyuGUSbI1j3GSurKIxgq1Jc86 MOYNY2h0DDdzkbUjCYUo/4bQ3YQ+DaGrT407tU3bdYbsxSHqrfbhkiLJhJCidiYS 4t5EpVqtu1FypJaMdJCdxbmPMnk3y1HcyKai651zRSePsAXNUb4GzGJ2+RqHF+N6 rqj3mZFg0G36Xx4OQ4qe6t+1+YCMsBRiC6K0I5NKXXJEZlNvFcNguQgJafHUhIU= =C6TS -----END PGP SIGNATURE----- --Apple-Mail=_0D107C28-45CE-4957-9CD0-8DCB8DFC6727-- From owner-freebsd-net@freebsd.org Fri Sep 18 16:06:12 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6056E9CE3D0 for ; Fri, 18 Sep 2015 16:06:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEB501B4E; Fri, 18 Sep 2015 16:06:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t8IG65Gu040171 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 18 Sep 2015 19:06:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t8IG65Gu040171 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t8IG65j4040169; Fri, 18 Sep 2015 19:06:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Sep 2015 19:06:05 +0300 From: Konstantin Belousov To: Julien Charbon Cc: Palle Girgensohn , freebsd-net@freebsd.org Subject: Re: Kernel panics in tcp_twclose Message-ID: <20150918160605.GN67105@kib.kiev.ua> References: <26B0FF93-8AE3-4514-BDA1-B966230AAB65@FreeBSD.org> <55FC1809.3070903@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55FC1809.3070903@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 18 Sep 2015 16:06:12 -0000 On Fri, Sep 18, 2015 at 03:56:25PM +0200, Julien Charbon wrote: > Hi Palle, > > On 18/09/15 11:12, Palle Girgensohn wrote: > > We see daily panics on our production systems (web server, apache > > running MPM event, openjdk8. Kernel with VIMAGE. Jails using netgraph > > interfaces [not epair]). > > > > The problem started after the summer. Normal port upgrades seems to > > be the only difference. The problem occurs with 10.2-p2 kernel as > > well as 10.1-p4 and 10.1-p15. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203175 > > > > Any ideas? > > Thanks for you detailed report. I am not aware of any tcp_twclose() > related issues (without VIMAGE) since FreeBSD 10.0 (does not mean there > are none). Few interesting facts (at least for me): > > - Your crash happens when unlocking a inp exclusive lock with INP_WUNLOCK() > > - Something is already wrong before calling turnstile_broadcast() as it > is called with ts = NULL: In the kernel without witness this is a 99%-sure indication of attempt to unlock not owned lock. > > turnstile_broadcast (ts=0x0, queue=1) at > /usr/src/sys/kern/subr_turnstile.c:838 > __rw_wunlock_hard () at /usr/src/sys/kern/kern_rwlock.c:988 > tcp_twclose () at /usr/src/sys/netinet/tcp_timewait.c:540 > tcp_tw_2msl_scan () at /usr/src/sys/netinet/tcp_timewait.c:748 > tcp_slowtimo () at /usr/src/sys/netinet/tcp_timer.c:198 > > I won't go to far here as I am not expert enough in VIMAGE, but one > question anyway: > > - Can you correlate this kernel panic to a particular event? Like for > example a VIMAGE/VNET jail destruction. > > I will test that on my side on a 10.2 machine. > > -- > Julien > From owner-freebsd-net@freebsd.org Fri Sep 18 18:56:22 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEE239D0333 for ; Fri, 18 Sep 2015 18:56:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB0B81C0E for ; Fri, 18 Sep 2015 18:56:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8IIuMFW029867 for ; Fri, 18 Sep 2015 18:56:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203022] [patch] Can't destroy vlan dev with vtnet parent that is down and doing vlanhwfilter Date: Fri, 18 Sep 2015 18:56:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bryanv@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bryanv@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 18 Sep 2015 18:56:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203022 Bryan Venteicher changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bryanv@FreeBSD.org Assignee|freebsd-net@FreeBSD.org |bryanv@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Fri Sep 18 20:42:31 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED49C9CF572 for ; Fri, 18 Sep 2015 20:42:31 +0000 (UTC) (envelope-from girgen@pingpong.net) Received: from mail.pingpong.net (mail.pingpong.net [79.136.116.202]) by mx1.freebsd.org (Postfix) with ESMTP id B0E171392; Fri, 18 Sep 2015 20:42:31 +0000 (UTC) (envelope-from girgen@pingpong.net) Received: from [10.0.1.13] (h-155-4-74-242.na.cust.bahnhof.se [155.4.74.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pingpong.net (Postfix) with ESMTPSA id 9F182EEE8; Fri, 18 Sep 2015 22:42:30 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Kernel panics in tcp_twclose From: Palle Girgensohn X-Mailer: iPhone Mail (12H321) In-Reply-To: <20150918160605.GN67105@kib.kiev.ua> Date: Fri, 18 Sep 2015 22:42:30 +0200 Cc: Julien Charbon , Palle Girgensohn , "freebsd-net@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9A234106-62EC-49C9-954A-2DA8315E9B4A@pingpong.net> References: <26B0FF93-8AE3-4514-BDA1-B966230AAB65@FreeBSD.org> <55FC1809.3070903@freebsd.org> <20150918160605.GN67105@kib.kiev.ua> To: Konstantin Belousov X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 18 Sep 2015 20:42:32 -0000 > 18 sep 2015 kl. 18:06 skrev Konstantin Belousov : >=20 >> On Fri, Sep 18, 2015 at 03:56:25PM +0200, Julien Charbon wrote: >> Hi Palle, >>=20 >>> On 18/09/15 11:12, Palle Girgensohn wrote: >>> We see daily panics on our production systems (web server, apache >>> running MPM event, openjdk8. Kernel with VIMAGE. Jails using netgraph >>> interfaces [not epair]). >>>=20 >>> The problem started after the summer. Normal port upgrades seems to >>> be the only difference. The problem occurs with 10.2-p2 kernel as >>> well as 10.1-p4 and 10.1-p15. >>>=20 >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203175 >>>=20 >>> Any ideas? >>=20 >> Thanks for you detailed report. I am not aware of any tcp_twclose() >> related issues (without VIMAGE) since FreeBSD 10.0 (does not mean there >> are none). Few interesting facts (at least for me): >>=20 >> - Your crash happens when unlocking a inp exclusive lock with INP_WUNLOCK= () >>=20 >> - Something is already wrong before calling turnstile_broadcast() as it >> is called with ts =3D NULL: > In the kernel without witness this is a 99%-sure indication of attempt to > unlock not owned lock. >=20 >>=20 >> turnstile_broadcast (ts=3D0x0, queue=3D1) at >> /usr/src/sys/kern/subr_turnstile.c:838 >> __rw_wunlock_hard () at /usr/src/sys/kern/kern_rwlock.c:988 >> tcp_twclose () at /usr/src/sys/netinet/tcp_timewait.c:540 >> tcp_tw_2msl_scan () at /usr/src/sys/netinet/tcp_timewait.c:748 >> tcp_slowtimo () at /usr/src/sys/netinet/tcp_timer.c:198 >>=20 >> I won't go to far here as I am not expert enough in VIMAGE, but one >> question anyway: >>=20 >> - Can you correlate this kernel panic to a particular event? Like for >> example a VIMAGE/VNET jail destruction. >>=20 >> I will test that on my side on a 10.2 machine. >>=20 >> -- >> Julien >>=20 >=20 >=20 Hi, I just got a response from adrian@ where he seems to remember that it has al= l been fixed in head.=20 I would really prefer not to run a head kernel in production unless I have t= o, so the question is if it is possible to pin down the specific fixes for t= his problem? Any suggestions? Thanks for all the help so far! Palle= From owner-freebsd-net@freebsd.org Sat Sep 19 13:10:45 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8E98A05DE5 for ; Sat, 19 Sep 2015 13:10:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9DC6310B1 for ; Sat, 19 Sep 2015 13:10:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8JDAjKk002971 for ; Sat, 19 Sep 2015 13:10:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203031] LACP problem with FreeBSD 10.2-RELEASE Date: Sat, 19 Sep 2015 13:10:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: gondim@bsdinfo.com.br X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 19 Sep 2015 13:10:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203031 --- Comment #2 from gondim@bsdinfo.com.br --- Hi all, More information about the problem. When I do: sysctl net.link.lagg.lacp.debug=1 I see many messages in the log: Sep 18 15:15:10 rt01 kernel: igb4: lacpdu transmit Sep 18 15:15:10 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0005) Sep 18 15:15:10 rt01 kernel: actor.state=3d Sep 18 15:15:10 rt01 kernel: partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0005) Sep 18 15:15:10 rt01 kernel: partner.state=3f Sep 18 15:15:10 rt01 kernel: maxdelay=0 Sep 18 15:15:11 rt01 kernel: igb5: lacpdu transmit Sep 18 15:15:11 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0006) Sep 18 15:15:11 rt01 kernel: actor.state=3d Sep 18 15:15:11 rt01 kernel: partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0004) Sep 18 15:15:11 rt01 kernel: partner.state=3f Sep 18 15:15:11 rt01 kernel: maxdelay=0 Sep 18 15:15:11 rt01 kernel: igb4: lacpdu transmit Sep 18 15:15:11 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0005) Sep 18 15:15:11 rt01 kernel: actor.state=3d Sep 18 15:15:11 rt01 kernel: partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0005) Sep 18 15:15:11 rt01 kernel: partner.state=3f Sep 18 15:15:11 rt01 kernel: maxdelay=0 Sep 18 15:15:12 rt01 kernel: igb5: lacpdu transmit Sep 18 15:15:12 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0006) Sep 18 15:15:12 rt01 kernel: actor.state=3d Sep 18 15:15:12 rt01 kernel: partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0004) Sep 18 15:15:12 rt01 kernel: partner.state=3f Sep 18 15:15:12 rt01 kernel: maxdelay=0 Sep 18 15:15:12 rt01 kernel: igb4: lacpdu transmit Sep 18 15:15:12 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0005) Sep 18 15:15:12 rt01 kernel: actor.state=3d Sep 18 15:15:12 rt01 kernel: partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0005) Sep 18 15:15:12 rt01 kernel: partner.state=3f Sep 18 15:15:12 rt01 kernel: maxdelay=0 -- You are receiving this mail because: You are the assignee for the bug.