From owner-freebsd-net@freebsd.org Sun Feb 28 11:13:52 2016 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 1330DAB7136 for ; Sun, 28 Feb 2016 11:13:52 +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 038231C5E for ; Sun, 28 Feb 2016 11:13:52 +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 u1SBDoqf030321 for ; Sun, 28 Feb 2016 11:13:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196944] [bge] [ipmi] regression IPMI access disabled when bge driver is loaded Date: Sun, 28 Feb 2016 11:13:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-BETA2 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: yongari@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: yongari@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 28 Feb 2016 11:13:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196944 --- Comment #9 from Pyun YongHyeon --- (In reply to Andrew Daugherity from comment #8) OK, thank you very much for double checking. Could you try a diff at the following URL? https://people.freebsd.org/~yongari/bge/bge.ipmi.diff I don't have access to IPMI-aware bge(4) H/Ws so it's just compile tested. The diff was generated against HEAD but I guess it will apply to stable/9 or stable/10. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Feb 28 16:57:33 2016 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 BE3B4AB7506 for ; Sun, 28 Feb 2016 16:57: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 AEDFDC3F for ; Sun, 28 Feb 2016 16:57: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 u1SGvXHZ083817 for ; Sun, 28 Feb 2016 16:57:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" Date: Sun, 28 Feb 2016 16:57:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: crash, needs-qa, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 28 Feb 2016 16:57:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D148807 --- Comment #23 from Hiren Panchasara --- This bug still persists in latest stable/10. We are seeing this mainly in c= ase of em(4). Any hints on how to debug this further would be great. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Feb 28 16:58:46 2016 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 D0000AB758D for ; Sun, 28 Feb 2016 16:58:46 +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 C07F9CF6 for ; Sun, 28 Feb 2016 16:58:46 +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 u1SGwkSJ085654 for ; Sun, 28 Feb 2016 16:58:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" Date: Sun, 28 Feb 2016 16:58:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: crash, needs-qa, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: bug_file_loc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 28 Feb 2016 16:58:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D148807 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- URL|https://reviews.freebsd.org | |/D5330 | --- Comment #24 from Hiren Panchasara --- D5330 is not related as far as I can tell. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Feb 29 03:55:11 2016 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 22C74AB6EB5 for ; Mon, 29 Feb 2016 03:55:11 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.rbsd.freebsd.org (unknown [IPv6:2607:fc50:2000:101::1bb:73]) by mx1.freebsd.org (Postfix) with ESMTP id 0CD911C38 for ; Mon, 29 Feb 2016 03:55:11 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.rbsd.freebsd.org (Postfix, from userid 1346) id 099633321060; Mon, 29 Feb 2016 03:55:11 +0000 (UTC) Date: Mon, 29 Feb 2016 03:55:11 +0000 To: freebsd-net@freebsd.org From: Phabricator Reply-to: D5416+325+d90172de5c58ed8c@reviews.freebsd.org Subject: [Differential] [Closed] D5416: buf_ring/drbr: Add buf_ring_peek_clear_sc and use it in drbr_peek Message-ID: <3c8297a7aaed44e6fcaa9931b4842923@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D5416: buf_ring/drbr: Add buf_ring_peek_clear_sc and use it in drbr_peek X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: Mjg4YWY1NmZjMjNkYWVhODFjM2QxMWJiNjA5IFbTwR8= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_3c8297a7aaed44e6fcaa9931b4842923" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 03:55:11 -0000 --b1_3c8297a7aaed44e6fcaa9931b4842923 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit This revision was automatically updated to reflect the committed changes. Closed by commit rS296178: buf_ring/drbr: Add buf_ring_peek_clear_sc and use it in drbr_peek (authored by sephe). CHANGED PRIOR TO COMMIT https://reviews.freebsd.org/D5416?vs=13669&id=13866#toc REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D5416?vs=13669&id=13866 REVISION DETAIL https://reviews.freebsd.org/D5416 AFFECTED FILES head/sys/net/ifq.h head/sys/sys/buf_ring.h CHANGE DETAILS diff --git a/head/sys/sys/buf_ring.h b/head/sys/sys/buf_ring.h --- a/head/sys/sys/buf_ring.h +++ b/head/sys/sys/buf_ring.h @@ -268,6 +268,37 @@ return (br->br_ring[br->br_cons_head]); } +static __inline void * +buf_ring_peek_clear_sc(struct buf_ring *br) +{ +#ifdef DEBUG_BUFRING + void *ret; + + if (!mtx_owned(br->br_lock)) + panic("lock not held on single consumer dequeue"); +#endif + /* + * I believe it is safe to not have a memory barrier + * here because we control cons and tail is worst case + * a lagging indicator so we worst case we might + * return NULL immediately after a buffer has been enqueued + */ + if (br->br_cons_head == br->br_prod_tail) + return (NULL); + +#ifdef DEBUG_BUFRING + /* + * Single consumer, i.e. cons_head will not move while we are + * running, so atomic_swap_ptr() is not necessary here. + */ + ret = br->br_ring[br->br_cons_head]; + br->br_ring[br->br_cons_head] = NULL; + return (ret); +#else + return (br->br_ring[br->br_cons_head]); +#endif +} + static __inline int buf_ring_full(struct buf_ring *br) { diff --git a/head/sys/net/ifq.h b/head/sys/net/ifq.h --- a/head/sys/net/ifq.h +++ b/head/sys/net/ifq.h @@ -369,7 +369,7 @@ return (m); } #endif - return(buf_ring_peek(br)); + return(buf_ring_peek_clear_sc(br)); } static __inline void EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, network, adrian, delphij, rrs, glebius, kmacy, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com Cc: freebsd-net-list --b1_3c8297a7aaed44e6fcaa9931b4842923 Content-Type: text/x-patch; charset=utf-8; name="D5416.13866.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D5416.13866.patch" ZGlmZiAtLWdpdCBhL2hlYWQvc3lzL3N5cy9idWZfcmluZy5oIGIvaGVhZC9zeXMvc3lzL2J1Zl9y aW5nLmgKLS0tIGEvaGVhZC9zeXMvc3lzL2J1Zl9yaW5nLmgKKysrIGIvaGVhZC9zeXMvc3lzL2J1 Zl9yaW5nLmgKQEAgLTI2OCw2ICsyNjgsMzcgQEAKIAlyZXR1cm4gKGJyLT5icl9yaW5nW2JyLT5i cl9jb25zX2hlYWRdKTsKIH0KIAorc3RhdGljIF9faW5saW5lIHZvaWQgKgorYnVmX3JpbmdfcGVl a19jbGVhcl9zYyhzdHJ1Y3QgYnVmX3JpbmcgKmJyKQoreworI2lmZGVmIERFQlVHX0JVRlJJTkcK Kwl2b2lkICpyZXQ7CisKKwlpZiAoIW10eF9vd25lZChici0+YnJfbG9jaykpCisJCXBhbmljKCJs b2NrIG5vdCBoZWxkIG9uIHNpbmdsZSBjb25zdW1lciBkZXF1ZXVlIik7CisjZW5kaWYJCisJLyoK KwkgKiBJIGJlbGlldmUgaXQgaXMgc2FmZSB0byBub3QgaGF2ZSBhIG1lbW9yeSBiYXJyaWVyCisJ ICogaGVyZSBiZWNhdXNlIHdlIGNvbnRyb2wgY29ucyBhbmQgdGFpbCBpcyB3b3JzdCBjYXNlCisJ ICogYSBsYWdnaW5nIGluZGljYXRvciBzbyB3ZSB3b3JzdCBjYXNlIHdlIG1pZ2h0CisJICogcmV0 dXJuIE5VTEwgaW1tZWRpYXRlbHkgYWZ0ZXIgYSBidWZmZXIgaGFzIGJlZW4gZW5xdWV1ZWQKKwkg Ki8KKwlpZiAoYnItPmJyX2NvbnNfaGVhZCA9PSBici0+YnJfcHJvZF90YWlsKQorCQlyZXR1cm4g KE5VTEwpOworCisjaWZkZWYgREVCVUdfQlVGUklORworCS8qCisJICogU2luZ2xlIGNvbnN1bWVy LCBpLmUuIGNvbnNfaGVhZCB3aWxsIG5vdCBtb3ZlIHdoaWxlIHdlIGFyZQorCSAqIHJ1bm5pbmcs IHNvIGF0b21pY19zd2FwX3B0cigpIGlzIG5vdCBuZWNlc3NhcnkgaGVyZS4KKwkgKi8KKwlyZXQg PSBici0+YnJfcmluZ1tici0+YnJfY29uc19oZWFkXTsKKwlici0+YnJfcmluZ1tici0+YnJfY29u c19oZWFkXSA9IE5VTEw7CisJcmV0dXJuIChyZXQpOworI2Vsc2UKKwlyZXR1cm4gKGJyLT5icl9y aW5nW2JyLT5icl9jb25zX2hlYWRdKTsKKyNlbmRpZgorfQorCiBzdGF0aWMgX19pbmxpbmUgaW50 CiBidWZfcmluZ19mdWxsKHN0cnVjdCBidWZfcmluZyAqYnIpCiB7CmRpZmYgLS1naXQgYS9oZWFk L3N5cy9uZXQvaWZxLmggYi9oZWFkL3N5cy9uZXQvaWZxLmgKLS0tIGEvaGVhZC9zeXMvbmV0L2lm cS5oCisrKyBiL2hlYWQvc3lzL25ldC9pZnEuaApAQCAtMzY5LDcgKzM2OSw3IEBACiAJCXJldHVy biAobSk7CiAJfQogI2VuZGlmCi0JcmV0dXJuKGJ1Zl9yaW5nX3BlZWsoYnIpKTsKKwlyZXR1cm4o YnVmX3JpbmdfcGVla19jbGVhcl9zYyhicikpOwogfQogCiBzdGF0aWMgX19pbmxpbmUgdm9pZAoK --b1_3c8297a7aaed44e6fcaa9931b4842923-- From owner-freebsd-net@freebsd.org Mon Feb 29 16:17:55 2016 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 6F6EFAB866D for ; Mon, 29 Feb 2016 16:17:55 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from mango.stankevitz.com (mango.stankevitz.com [208.79.93.194]) by mx1.freebsd.org (Postfix) with ESMTP id 5E3DA1A9C for ; Mon, 29 Feb 2016 16:17:54 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from Chriss-MacBook-Pro.local (209-203-101-124.static.twtelecom.net [209.203.101.124]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mango.stankevitz.com (Postfix) with ESMTPSA id 2BC605C11E for ; Mon, 29 Feb 2016 08:10:01 -0800 (PST) To: "freebsd-net@freebsd.org" From: Chris Stankevitz Subject: sshd TcpRcvBuf Message-ID: <56D46D58.6080708@stankevitz.com> Date: Mon, 29 Feb 2016 08:10:00 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; 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, 29 Feb 2016 16:17:55 -0000 Hello, The ssh TcpRcvBuf option [1] works well when running an ssh client to indicate that the ssh client should have a large TCP receive buffer. This is a good workaround until bug 206716 [2] is fixed for people who want their ssh client to receive a lot of data. I have an ssh server that wants to received a lot of data. Question: how do I set TcpRcvBuf on the ssh server? It's undocumented so I guessed. Neither sshd_config ("TcbRcvBuf=8192") nor sshd_flags ("-oTcpRcvBuf=8192") worked. Thank you, Chris [1] ssh -oTcpRcvBuf=8192 user@host [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206716 From owner-freebsd-net@freebsd.org Mon Feb 29 23:55:14 2016 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 2B69EAB9898 for ; Mon, 29 Feb 2016 23:55:14 +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 1DD5EA40 for ; Mon, 29 Feb 2016 23:55:14 +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 u1TNtDsi012935 for ; Mon, 29 Feb 2016 23:55:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196944] [bge] [ipmi] regression IPMI access disabled when bge driver is loaded Date: Mon, 29 Feb 2016 23:55:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-BETA2 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: andrew.daugherity@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: yongari@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 29 Feb 2016 23:55:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196944 --- Comment #10 from Andrew Daugherity --- (In reply to Pyun YongHyeon from comment #9) Unfortunately, the diff does not fix anything on my hardware. IPMI still w= orks when PXE is enabled and does not work without it. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Mar 1 03:06:21 2016 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 C4E43AB9542 for ; Tue, 1 Mar 2016 03:06:21 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A92181DDD for ; Tue, 1 Mar 2016 03:06:21 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id A2C381E76 for ; Tue, 1 Mar 2016 03:06:21 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 595591CB3D for ; Tue, 1 Mar 2016 03:06:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id WXi1twllL80J for ; Tue, 1 Mar 2016 03:06:19 +0000 (UTC) To: freebsd-net@FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 0D0EB1CB35 From: Bryan Drewery Subject: HEAD r296148 panic: vtnet_txq_mq_start -> drbr_enqueue -> already enqueue Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <56D50725.5040603@FreeBSD.org> Date: Mon, 29 Feb 2016 19:06:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SQVhC8fPnGbPPHxE2qswgJngoA9c1rkSg" 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, 01 Mar 2016 03:06:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SQVhC8fPnGbPPHxE2qswgJngoA9c1rkSg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hit this in bhyve: > panic: buf=3D0xfffff8002df9fd00 already enqueue at 652 prod=3D653 cons=3D= 652 > cpuid =3D 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00b= 5d46150 > vpanic() at vpanic+0x182/frame 0xfffffe00b5d461d0 > panic() at panic+0x43/frame 0xfffffe00b5d46230 > drbr_enqueue() at drbr_enqueue+0x54/frame 0xfffffe00b5d46250 > vtnet_txq_mq_start() at vtnet_txq_mq_start+0x95/frame 0xfffffe00b5d4629= 0 > ether_output() at ether_output+0x56f/frame 0xfffffe00b5d46320 > ip_output() at ip_output+0x1437/frame 0xfffffe00b5d46460 > tcp_output() at tcp_output+0x1b0a/frame 0xfffffe00b5d46630 > tcp_do_segment() at tcp_do_segment+0x27a3/frame 0xfffffe00b5d46730 > tcp_input() at tcp_input+0xdb8/frame 0xfffffe00b5d46880 > ip_input() at ip_input+0x17d/frame 0xfffffe00b5d468e0 > netisr_dispatch_src() at netisr_dispatch_src+0x81/frame 0xfffffe00b5d46= 940 > ether_demux() at ether_demux+0x15e/frame 0xfffffe00b5d46970 > ether_nh_input() at ether_nh_input+0x344/frame 0xfffffe00b5d469b0 > netisr_dispatch_src() at netisr_dispatch_src+0x81/frame 0xfffffe00b5d46= a10 > ether_input() at ether_input+0x4f/frame 0xfffffe00b5d46a40 > vtnet_rxq_eof() at vtnet_rxq_eof+0x823/frame 0xfffffe00b5d46af0 > vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x4e/frame 0xfffffe00b5d46b20 > intr_event_execute_handlers() at intr_event_execute_handlers+0x96/frame= 0xfffffe00b5d46b60 > ithread_loop() at ithread_loop+0xa6/frame 0xfffffe00b5d46bb0 > fork_exit() at fork_exit+0x84/frame 0xfffffe00b5d46bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00b5d46bf0 > --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- > KDB: enter: panic > [ thread pid 12 tid 100025 ] > Stopped at kdb_enter+0x3b: movq $0,kdb_why --=20 Regards, Bryan Drewery --SQVhC8fPnGbPPHxE2qswgJngoA9c1rkSg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJW1QcpAAoJEDXXcbtuRpfP70cIAN2JhF3EQR9t5pKVcXYutmZ+ CBLts9GQbNBz5GhpoJcy9qIUlpNq4YcDcR6t6X0MUOLIeJTGyXz5QYzKbOzjB9IC 7EnFCAS8rYRuFBHGhuwgPgsjj3f2WUDs0HbwIAOaPoOkdqbok2EV1VPohUW+jB/0 TCvXKil0V8F7KXr9XZeJkJm9jMB7wZmBNlVBiHsn5PlL5TrZ6zIeCAxp/k+FBLog 1aVCqIDiFntMnF29WS2CD8GTLfX66YOxK4yxMrUK3k2Xivv37DBEHXkkRbyIMrAp Geq+7HY31LD1rrRf8KTnI33nj4hMGtB4P7WGfgaxUXMtzl5A9v1jOncsojVF+Dc= =G5E2 -----END PGP SIGNATURE----- --SQVhC8fPnGbPPHxE2qswgJngoA9c1rkSg-- From owner-freebsd-net@freebsd.org Tue Mar 1 03:20:12 2016 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 7D8B8AB9AF3 for ; Tue, 1 Mar 2016 03:20:12 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38A651332; Tue, 1 Mar 2016 03:20:12 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by mail-vk0-x22c.google.com with SMTP id c3so154984153vkb.3; Mon, 29 Feb 2016 19:20:12 -0800 (PST) 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; bh=sCLz5zV5B26p3QEmiHUq7T/0E4CM6V33z/RWMRS1OTE=; b=xmAAT7xhMlII/27XYTBjokaEaeMd8f8BCVCfnKz2klHavQ/tbtlLfVuQNJgHT70xvl KLeXu80DPJWIJ8lRboR+m11guf7M5ogyzbXLsXXlVOXiLsa68Hc6306LMrOOTTJrvggD nNVBI2/UQjdJW5XEFM514QTcYGGYHZf5L4KnF2H7mJdrg0/+8m83kVw41UDqbEZ2VSx0 SYIQ3ZN11bg2HikFA2P5NVNAehE7NlmOKuMARb4dGyGhgkGQF1JT4b9jOIFIMq5C/yMI qd4pB92PR4yL1cYvYCJjsTnAP8nTTSLnDoZTN2ZxqwLDlWBrbpFqsKC25OSUTAtLRwBb b1gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sCLz5zV5B26p3QEmiHUq7T/0E4CM6V33z/RWMRS1OTE=; b=AP5q1XjIgpTULjGP/ndK2hawaeoXaGryJYLN4B0FViNw5LozMiHkeugVXXiA9dsnoI bpWdBMQH/3vjDr6xj1j5D4CAEyup1xFngZ3GMCjOS9BBYW89GiPImxpJ2XHxlB9o5Ocv 1GC+EDcPxsvlgZ/kUx8MZ+VLNjXGtMPbSsQw+QKug7Pg5kf9ws+SYIi2tpFCwFBmc5r1 +7oFfbtCIakjyr7S9qdgcFxOZjaapWXAuRtzzrEdPY/xK4UqW43yLRegF9gJYPgUJeAb RC6Z3h7vBjR03EKTlzI6SGTe6hMBfns88t2aeZvjxdfPmjKwnX+jWeA9zJiNELnpDuAZ 6Xcg== X-Gm-Message-State: AD7BkJIwyc9PkkAjIsvVyhVeco+eoMcdADDJ6U+elvHa0rq9TVY6UzrddVddgUcjkfgmR5EJZRwpY23+xpGlHA== MIME-Version: 1.0 X-Received: by 10.31.178.134 with SMTP id b128mr11811029vkf.112.1456802410897; Mon, 29 Feb 2016 19:20:10 -0800 (PST) Received: by 10.159.33.214 with HTTP; Mon, 29 Feb 2016 19:20:10 -0800 (PST) In-Reply-To: <56D50725.5040603@FreeBSD.org> References: <56D50725.5040603@FreeBSD.org> Date: Tue, 1 Mar 2016 11:20:10 +0800 Message-ID: Subject: Re: HEAD r296148 panic: vtnet_txq_mq_start -> drbr_enqueue -> already enqueue From: Sepherosa Ziehau To: Bryan Drewery Cc: "freebsd-net@freebsd.org" 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, 01 Mar 2016 03:20:12 -0000 I believe r296178 fixes this panic. Please try it. Thanks, sephe On Tue, Mar 1, 2016 at 11:06 AM, Bryan Drewery wrote: > Hit this in bhyve: > >> panic: buf=0xfffff8002df9fd00 already enqueue at 652 prod=653 cons=652 >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00b5d46150 >> vpanic() at vpanic+0x182/frame 0xfffffe00b5d461d0 >> panic() at panic+0x43/frame 0xfffffe00b5d46230 >> drbr_enqueue() at drbr_enqueue+0x54/frame 0xfffffe00b5d46250 >> vtnet_txq_mq_start() at vtnet_txq_mq_start+0x95/frame 0xfffffe00b5d46290 >> ether_output() at ether_output+0x56f/frame 0xfffffe00b5d46320 >> ip_output() at ip_output+0x1437/frame 0xfffffe00b5d46460 >> tcp_output() at tcp_output+0x1b0a/frame 0xfffffe00b5d46630 >> tcp_do_segment() at tcp_do_segment+0x27a3/frame 0xfffffe00b5d46730 >> tcp_input() at tcp_input+0xdb8/frame 0xfffffe00b5d46880 >> ip_input() at ip_input+0x17d/frame 0xfffffe00b5d468e0 >> netisr_dispatch_src() at netisr_dispatch_src+0x81/frame 0xfffffe00b5d46940 >> ether_demux() at ether_demux+0x15e/frame 0xfffffe00b5d46970 >> ether_nh_input() at ether_nh_input+0x344/frame 0xfffffe00b5d469b0 >> netisr_dispatch_src() at netisr_dispatch_src+0x81/frame 0xfffffe00b5d46a10 >> ether_input() at ether_input+0x4f/frame 0xfffffe00b5d46a40 >> vtnet_rxq_eof() at vtnet_rxq_eof+0x823/frame 0xfffffe00b5d46af0 >> vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x4e/frame 0xfffffe00b5d46b20 >> intr_event_execute_handlers() at intr_event_execute_handlers+0x96/frame 0xfffffe00b5d46b60 >> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe00b5d46bb0 >> fork_exit() at fork_exit+0x84/frame 0xfffffe00b5d46bf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00b5d46bf0 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >> KDB: enter: panic >> [ thread pid 12 tid 100025 ] >> Stopped at kdb_enter+0x3b: movq $0,kdb_why > > > -- > Regards, > Bryan Drewery > -- Tomorrow Will Never Die From owner-freebsd-net@freebsd.org Tue Mar 1 04:24:57 2016 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 9E12DAB9BEE for ; Tue, 1 Mar 2016 04:24:57 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8159F1B15; Tue, 1 Mar 2016 04:24:57 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 7610610B0; Tue, 1 Mar 2016 04:24:57 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 3557E1CCC2; Tue, 1 Mar 2016 04:24:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id S-8qGIwvJ6Wr; Tue, 1 Mar 2016 04:24:55 +0000 (UTC) Subject: Re: HEAD r296148 panic: vtnet_txq_mq_start -> drbr_enqueue -> already enqueue DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 779681CCBC To: Sepherosa Ziehau References: <56D50725.5040603@FreeBSD.org> Cc: "freebsd-net@freebsd.org" From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <56D51994.8040909@FreeBSD.org> Date: Mon, 29 Feb 2016 20:24:52 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f1nABoK374PDkABPGt2aWT5WONX6x5cVE" 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, 01 Mar 2016 04:24:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f1nABoK374PDkABPGt2aWT5WONX6x5cVE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks! On 2/29/2016 7:20 PM, Sepherosa Ziehau wrote: > I believe r296178 fixes this panic. Please try it. >=20 > Thanks, > sephe >=20 > On Tue, Mar 1, 2016 at 11:06 AM, Bryan Drewery w= rote: >> Hit this in bhyve: >> >>> panic: buf=3D0xfffff8002df9fd00 already enqueue at 652 prod=3D653 con= s=3D652 >>> cpuid =3D 0 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0= 0b5d46150 >>> vpanic() at vpanic+0x182/frame 0xfffffe00b5d461d0 >>> panic() at panic+0x43/frame 0xfffffe00b5d46230 >>> drbr_enqueue() at drbr_enqueue+0x54/frame 0xfffffe00b5d46250 >>> vtnet_txq_mq_start() at vtnet_txq_mq_start+0x95/frame 0xfffffe00b5d46= 290 >>> ether_output() at ether_output+0x56f/frame 0xfffffe00b5d46320 >>> ip_output() at ip_output+0x1437/frame 0xfffffe00b5d46460 >>> tcp_output() at tcp_output+0x1b0a/frame 0xfffffe00b5d46630 >>> tcp_do_segment() at tcp_do_segment+0x27a3/frame 0xfffffe00b5d46730 >>> tcp_input() at tcp_input+0xdb8/frame 0xfffffe00b5d46880 >>> ip_input() at ip_input+0x17d/frame 0xfffffe00b5d468e0 >>> netisr_dispatch_src() at netisr_dispatch_src+0x81/frame 0xfffffe00b5d= 46940 >>> ether_demux() at ether_demux+0x15e/frame 0xfffffe00b5d46970 >>> ether_nh_input() at ether_nh_input+0x344/frame 0xfffffe00b5d469b0 >>> netisr_dispatch_src() at netisr_dispatch_src+0x81/frame 0xfffffe00b5d= 46a10 >>> ether_input() at ether_input+0x4f/frame 0xfffffe00b5d46a40 >>> vtnet_rxq_eof() at vtnet_rxq_eof+0x823/frame 0xfffffe00b5d46af0 >>> vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x4e/frame 0xfffffe00b5d46b20 >>> intr_event_execute_handlers() at intr_event_execute_handlers+0x96/fra= me 0xfffffe00b5d46b60 >>> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe00b5d46bb0 >>> fork_exit() at fork_exit+0x84/frame 0xfffffe00b5d46bf0 >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00b5d46bf0 >>> --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- >>> KDB: enter: panic >>> [ thread pid 12 tid 100025 ] >>> Stopped at kdb_enter+0x3b: movq $0,kdb_why >> >> >> -- >> Regards, >> Bryan Drewery >> >=20 >=20 >=20 --=20 Regards, Bryan Drewery --f1nABoK374PDkABPGt2aWT5WONX6x5cVE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJW1RmUAAoJEDXXcbtuRpfPzGIIAJkLprAYpgHTIrIWQtgIhxcf MmJN2nb2g+ZnitYw0YY0l6Q0SmeYH8Rk/WEbiAVlVtnWfIvN/cqRizW+HThNjW1u 0F4X17D6V8+9XRvB1wreVnVEYuzsKag9BNP4bEqGOeO5Spxie/DjJLjpFZ4cZ/NO zi6WVOB4d23r2w08HQl4B6sj6/0eAmV3inDWxk0fVoVyQpmB83a9J7w35cGlcpna m3sC4p74tNZjhMfd1uytr71PlvvRiRo+hC8lb9QIie4Ql2oI5xT+Sc2ONABYnBJO BXWNNRaqn8d8sZNQpyWGCPuhqQOFDxQBj3UxyxtdK1s+XW6pmYlwoQk5oA9Rr9M= =FA7x -----END PGP SIGNATURE----- --f1nABoK374PDkABPGt2aWT5WONX6x5cVE-- From owner-freebsd-net@freebsd.org Tue Mar 1 06:25:07 2016 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 1610AABA04B for ; Tue, 1 Mar 2016 06:25:07 +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 06FCDD64 for ; Tue, 1 Mar 2016 06:25:07 +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 u216P6IQ026586 for ; Tue, 1 Mar 2016 06:25:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196944] [bge] [ipmi] regression IPMI access disabled when bge driver is loaded Date: Tue, 01 Mar 2016 06:25:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-BETA2 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: yongari@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: yongari@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 01 Mar 2016 06:25:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196944 --- Comment #11 from Pyun YongHyeon --- (In reply to Andrew Daugherity from comment #10) Uploaded updated diff. The URL is the same as before. Could you test it again? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Mar 1 19:59:33 2016 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 464DAABD03F for ; Tue, 1 Mar 2016 19:59: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 373041B19 for ; Tue, 1 Mar 2016 19:59: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 u21JxXUa030790 for ; Tue, 1 Mar 2016 19:59:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196944] [bge] [ipmi] regression IPMI access disabled when bge driver is loaded Date: Tue, 01 Mar 2016 19:59:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-BETA2 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: andrew.daugherity@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: yongari@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 01 Mar 2016 19:59:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196944 --- Comment #12 from Andrew Daugherity --- (In reply to Pyun YongHyeon from comment #11) Is that diff meant to be cumulative with the previous one or replace it entirely? With a kernel built with only the new diff (discarding the previous one), t= here is no change. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Mar 2 07:43:47 2016 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 9D266AC01D1 for ; Wed, 2 Mar 2016 07:43:47 +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 8E8041394 for ; Wed, 2 Mar 2016 07:43:47 +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 u227hjbl011103 for ; Wed, 2 Mar 2016 07:43:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 165174] [patch] [tap] allow tap(4) to keep its address on close Date: Wed, 02 Mar 2016 07:43:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: terehovv@mail.ru X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 02 Mar 2016 07:43:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D165174 terehovv@mail.ru changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |terehovv@mail.ru --- Comment #2 from terehovv@mail.ru --- I have the same problem. This patch helps to work with bhyve when you need a network connection between the virtual machine and the host. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Mar 2 11:41:15 2016 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 385B0ABFE88 for ; Wed, 2 Mar 2016 11:41:15 +0000 (UTC) (envelope-from al4321@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::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 02D25128D for ; Wed, 2 Mar 2016 11:41:15 +0000 (UTC) (envelope-from al4321@gmail.com) Received: by mail-ig0-x22f.google.com with SMTP id z8so40172105ige.0 for ; Wed, 02 Mar 2016 03:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=tFHWHW1NLAQn4IAORCYyF4CK22iTHXFUoRtndDQnmKo=; b=v7XB7v22Qeak0yEGoSW9POpcWH1nv/TyQJOlbHDP36M64HNVNIWoM9ZqXu5uD/7S3T 6kWC0zrdYT5mEVQuaTL7o2Hvm6BNV+eU2ZysnYe/YAHkDRY3h4N/aZ40nnv+pmb9c8zZ LgsRdOK26o/jj8kLhBXwYsC/EfVk4ggjt20qjk/i+vKwdV9LYHcuqEOlfDCsxlyiOlHl rNcYkaDc//t/JVOcVfylZhKcwi4vKkhpQkkv4VVNwsBj9g47CWRkcZHtFZPhM5Ij+/1r dlAsibxHfvjWKDt6Btcdpg4f+eAdYmK4tWr9BH+u2Jl2pB8UwAi0VTP1MOqQ5ERqhqnw NGJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=tFHWHW1NLAQn4IAORCYyF4CK22iTHXFUoRtndDQnmKo=; b=WtCMTnWJOfXlUZRPKaYt7ik74yZ84hBiW7Fv/YgUJyLUIK8BeRMr7WsbhyUKPxXD9G 5akuwabiQrJxGGT6euS4yTQh6+VpIP9bnJfz3gnG15VGrI0KGodV2aaxJJwuuhR9Aia0 o+Fd55ojuu6asDUyJw+NhV35kLFpXG73mEvGDtiX0fk94ioPm1uISkOptHma4LPfZZ/A NSlcFBGuwEQwCUZinGIGVs7H6KZwH1nfX/h8PUeTgZKlZfOGNjD6ffh3Ury/mBpHkAsu AJI8bnAF5pPOj1xSyIwIV3OB+HCLTeXrHURcVTFhjL8GHp3BgPJ3q/NX55lrkhT7Rcsw m9DQ== X-Gm-Message-State: AD7BkJKaCAPl0AL4Y6Y/jhA3U3n4Wa9ZfPGQZa3l4Y2aomL71OU2M9PAtu/E11Pu8sdt61oEhKIZ5iFX93kRXw== X-Received: by 10.50.141.202 with SMTP id rq10mr3268523igb.59.1456918873861; Wed, 02 Mar 2016 03:41:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.136.144 with HTTP; Wed, 2 Mar 2016 03:40:54 -0800 (PST) In-Reply-To: References: From: Alexey Eromenko Date: Wed, 2 Mar 2016 13:40:54 +0200 Message-ID: Subject: Fwd: Development of next-gen Internet Protocol "Five Fields" (IP-FF): Presentation To: freebsd-net@freebsd.org 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: Wed, 02 Mar 2016 11:41:15 -0000 Hello fellow developers, Secretly in the shadows, I have been developing a new Internet Protocol "Five Fields" for quite some time. It is designed to be superior to both IPv4 and IPv6. And even made a nice presentation about IP-FF and it's features: https://docs.google.com/presentation /d/1XbqWOwv0GASmSjYZimfK64QKQQ-0yK9xQ1_spRhlf8Y/edit?usp=sharing IP-FF is about: o Short, human-readable addresses, solves the problem of address exhaustion of IPv4, without the extra complexity and usability nightmare of IPv6 o Modularization and re-factoring of some perceived IPv6 bloat (NDP/IGMP/MLD/IPsec/SLAAC/Flow/...) o New features: IP-VRF and Mobile TCP o TCP on very fast links (over 1 Tbps) o Stronger checksums It now consists of 10 parts: (submitted as IETF drafts) 1. Internet Protocol - Five Fields: https://datatracker.ietf.org/doc/draft-eromenko-ipff/ 2. Internet Protocol - Five Fields: Addressing Architecture https://datatracker.ietf.org/doc/draft-eromenko-ipff-addressing/ 3. Internet Protocol - Five Fields: Address Resolution Protocol https://datatracker.ietf.org/doc/draft-eromenko-ipff-arp/ 4. Internet Protocol - Five Fields: Babysitter (new NAT) https://datatracker.ietf.org/doc/draft-eromenko-ipff-babysitter/ 5. Internet Protocol - Five Fields: DHCP https://datatracker.ietf.org/doc/draft-eromenko-ipff-dhcp/ 6. Internet Protocol - Five Fields: DNS extensions https://datatracker.ietf.org/doc/draft-eromenko-ipff-dns/ 7. Internet Protocol - Five Fields: ICMP https://datatracker.ietf.org/doc/draft-eromenko-ipff-icmp/ 8. Internet Protocol - Five Fields: Mobile TCP (Mobile IP replacement) https://datatracker.ietf.org/doc/draft-eromenko-ipff-mops/ 9. Internet Protocol - Five Fields: TCP.64 extensions https://datatracker.ietf.org/doc/draft-eromenko-ipff-tcp64/ 10. Internet Protocol - Five Fields: UDP https://datatracker.ietf.org/doc/draft-eromenko-ipff-udp/ What do you think of it ? Best wishes, -- -Alexey Eromenko "Technologov" From owner-freebsd-net@freebsd.org Wed Mar 2 13:35:49 2016 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 2568EABF338 for ; Wed, 2 Mar 2016 13:35:49 +0000 (UTC) (envelope-from raitech@gmail.com) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3D861998 for ; Wed, 2 Mar 2016 13:35:48 +0000 (UTC) (envelope-from raitech@gmail.com) Received: by mail-oi0-x229.google.com with SMTP id d205so70169639oia.0 for ; Wed, 02 Mar 2016 05:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=fMXguSPoCM+yLR5ODb5Q1nVKpvtnQUy1KRgGSosembw=; b=i8P92f8flzd7qy34hrF2FBNS3s3f8tg+Fx3CA0coAvpASPeFUK/p1qCd6jw5PSvNHp hcNzoaZ1lmmd5GYASfiCpDm9Die48nvP+U3vFgy8NcsY4F6V5jo1NGBom7iA8HwwctXC RlCE0dPihAusLjzIxW8yCJMZp/BvMcAvStslY6whs+i1nW6B3i8vGORRpRPRho8e2Gqp aTEy/lObI2ttwNOAMBSp3Ii3pTJ/KZgRjbr5/XQo/DDkFHUqYu3D7XBS35EDps3EcTaJ OHeI+kOoANcF8MD3rNrrUnGnI8A3SF8Cp//wWZG2uXngCs0KX5wrbgBEs7stpgmw/53G iFGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fMXguSPoCM+yLR5ODb5Q1nVKpvtnQUy1KRgGSosembw=; b=c92Pw6UJXq3rmPlcCUCrM0EnhvZ6oKZi2n6ChtitXVw6FDEklv/GmwW7SJAzQjmI6O Fy/tzkIkoSnaPWvPmgvN3UZdHFoci8inc4D1T860vv6ldC9g7Opj3FHPu7BN4p+w9jA1 civWsmoEmloCxn3D2hiHe7PvK0FhuO5KwnUHSJOc6qeZ6eia1rHgiJmPHEMT6cT3GeST M3jCL+ZerCH8016GyzZic99ZFu3wcA2HEONk4RDFQuY23mx5kNi/DnOvoVJRsjDHPq4H Bcivp3lZflW47+eMG/v2IEFPm4mlcUf+5hBy68UUGrno+bQ1zqlmOmS7LrO/DgpJckwY H8Rw== X-Gm-Message-State: AD7BkJITo+lN29Oq2uPhBLbSRuUsKtlk/0lYzmtBL1Vklbc2EdkGLkocKVTj9YXmKnuHWCpSfNVkQxkkSyCLcw== X-Received: by 10.202.68.130 with SMTP id r124mr20408283oia.105.1456925748186; Wed, 02 Mar 2016 05:35:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.167.34 with HTTP; Wed, 2 Mar 2016 05:35:28 -0800 (PST) From: Raimundo Santos Date: Wed, 2 Mar 2016 10:35:28 -0300 Message-ID: Subject: How to log NATed addresses with ipfw and in-kernel libalias? To: "freebsd-net@freebsd.org" 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: Wed, 02 Mar 2016 13:35:49 -0000 Hello all! I need to log NATed connections/addresses with ipfw and in-kernel libalias. Have someone done that? I can't find much doc about it, only a wish of ng_netflow doing that for CGNAT, what is very close to my needs. I'm not versed in kernel programming, but having a look at libalias code don't gave me any clues where to know original address and nated address with AliasLog. Maybe an userland code could read this information? If yes, what would be the directions to follow? Thank you for your time, Raimundo Santos From owner-freebsd-net@freebsd.org Wed Mar 2 17:55:21 2016 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 96997AC1909 for ; Wed, 2 Mar 2016 17:55:21 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 514F311A8 for ; Wed, 2 Mar 2016 17:55:21 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 5268A564B5 for ; Wed, 2 Mar 2016 11:55:20 -0600 (CST) To: "freebsd-net@freebsd.org" From: Eric van Gyzen Subject: ixv0: Polling for VF0 mailbox ack timedout X-Enigmail-Draft-Status: N1110 Message-ID: <56D72903.6000906@FreeBSD.org> Date: Wed, 2 Mar 2016 11:55:15 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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, 02 Mar 2016 17:55:21 -0000 I'm having trouble creating a VF on an ix NIC. The NIC is: ix0@pci0:1:0:0: class=0x020000 card=0x1f611028 chip=0x15288086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Controller 10-Gigabit X540-AT2' class = network subclass = ethernet My /etc/iovctl.conf is pretty simple: PF { device : "ix0"; num_vfs : 1; } DEFAULT { passthrough : false; } I'm running this: # iovctl -S -f /etc/iovctl.conf The VF gets created: none160@pci0:1:0:128: class=0x020000 card=0x1f611028 chip=0x15158086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet But the driver fails to attach: ixv0: ixgbe_reset_hw() failed with error -100 device_attach: ixv0 attach returned 5 I rebuilt with DBG=1 in ixgbe_osdep.h. The debug messages are below. The only relevant setting [that I could find] in the BIOS setup was SR-IOV Global Enable, which is enabled. What should I try next? Thanks, Eric ==== Mar 2 19:26:42 fwt kernel: ixgbe_stop_adapter_generic Mar 2 19:26:42 fwt kernel: ixgbe_disable_pcie_master Mar 2 19:26:42 fwt kernel: ixgbe_set_rar_generic Mar 2 19:26:42 fwt kernel: ixgbe_set_vmdq_generic Mar 2 19:26:42 fwt kernel: ixgbe_set_rar_generic Mar 2 19:26:42 fwt kernel: ixgbe_set_vmdq_generic Mar 2 19:26:42 fwt kernel: ixgbe_init_hw_generic Mar 2 19:26:42 fwt kernel: ixgbe_reset_hw_X540 Mar 2 19:26:42 fwt kernel: ixgbe_stop_adapter_generic Mar 2 19:26:42 fwt kernel: ixgbe_disable_pcie_master Mar 2 19:26:42 fwt kernel: ixgbe_get_mac_addr_generic Mar 2 19:26:42 fwt kernel: ixgbe_init_rx_addrs_generic Mar 2 19:26:42 fwt kernel: ixgbe_validate_mac_addr Mar 2 19:26:42 fwt kernel: Overriding MAC Address in RAR[0] Mar 2 19:26:42 fwt kernel: Mar 2 19:26:42 fwt kernel: New MAC Addr =EC F4 BB Mar 2 19:26:42 fwt kernel: D6 B5 10 Mar 2 19:26:42 fwt kernel: Mar 2 19:26:42 fwt kernel: ixgbe_set_rar_generic Mar 2 19:26:42 fwt kernel: ixgbe_set_vmdq_generic Mar 2 19:26:42 fwt kernel: ixgbe_clear_vmdq_generic Mar 2 19:26:42 fwt kernel: Clearing RAR[1-127] Mar 2 19:26:42 fwt kernel: Mar 2 19:26:42 fwt kernel: Clearing MTA Mar 2 19:26:42 fwt kernel: Mar 2 19:26:42 fwt kernel: ixgbe_init_uta_tables_generic Mar 2 19:26:42 fwt kernel: Clearing UTA Mar 2 19:26:42 fwt kernel: Mar 2 19:26:42 fwt kernel: ixgbe_get_san_mac_addr_generic Mar 2 19:26:42 fwt kernel: ixgbe_get_san_mac_addr_offset Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_set_lan_id_multi_port_pcie Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_validate_mac_addr Mar 2 19:26:42 fwt kernel: ixgbe_set_rar_generic Mar 2 19:26:42 fwt kernel: ixgbe_set_vmdq_generic Mar 2 19:26:42 fwt kernel: ixgbe_get_wwn_prefix_generic Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_start_hw_X540 Mar 2 19:26:42 fwt kernel: ixgbe_start_hw_generic Mar 2 19:26:42 fwt kernel: ixgbe_clear_vfta_generic Mar 2 19:26:42 fwt kernel: ixgbe_clear_hw_cntrs_generic Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_setup_fc_generic Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_device_supports_autoneg_fc Mar 2 19:26:42 fwt kernel: ixgbe_write_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: Set up FC; PCS1GLCTL = 0x00000000 Mar 2 19:26:42 fwt kernel: Mar 2 19:26:42 fwt kernel: ixgbe_update_mc_addr_list_generic Mar 2 19:26:42 fwt kernel: Clearing MTA Mar 2 19:26:42 fwt kernel: Mar 2 19:26:42 fwt kernel: ixgbe_update_mc_addr_list_generic Complete Mar 2 19:26:42 fwt kernel: Mar 2 19:26:42 fwt kernel: ixgbe_enable_rx_dma_generic Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_write_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_check_mac_link_generic Mar 2 19:26:42 fwt kernel: ixgbe_get_copper_link_capabilities_generic Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_setup_mac_link_X540 Mar 2 19:26:42 fwt kernel: ixgbe_setup_phy_link_speed_generic Mar 2 19:26:42 fwt kernel: ixgbe_setup_phy_link_generic Mar 2 19:26:42 fwt kernel: ixgbe_get_copper_link_capabilities_generic Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_write_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_write_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_write_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_check_reset_blocked Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_write_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_start_hw_X540 Mar 2 19:26:42 fwt kernel: ixgbe_start_hw_generic Mar 2 19:26:42 fwt kernel: ixgbe_clear_vfta_generic Mar 2 19:26:42 fwt kernel: ixgbe_clear_hw_cntrs_generic Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:43 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:43 fwt kernel: ixgbe_setup_fc_generic Mar 2 19:26:43 fwt kernel: ixgbe_read_phy_reg_generic Mar 2 19:26:43 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:43 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:43 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:43 fwt kernel: ixgbe_device_supports_autoneg_fc Mar 2 19:26:43 fwt kernel: ixgbe_write_phy_reg_generic Mar 2 19:26:43 fwt kernel: ixgbe_acquire_swfw_sync_X540 Mar 2 19:26:43 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_X540 Mar 2 19:26:43 fwt kernel: ixgbe_get_swfw_sync_semaphore Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_semaphore Mar 2 19:26:43 fwt kernel: Set up FC; PCS1GLCTL = 0x00000180 Mar 2 19:26:43 fwt kernel: Mar 2 19:26:43 fwt kernel: ixgbe_check_mac_link_generic Mar 2 19:26:45 fwt kernel: ixgbe_validate_mac_addr Mar 2 19:26:45 fwt kernel: MAC address is all zeros Mar 2 19:26:45 fwt kernel: Mar 2 19:26:45 fwt kernel: ixgbe_write_mbx Mar 2 19:26:45 fwt kernel: ixgbe_write_mbx_pf Mar 2 19:26:45 fwt kernel: ixgbe_obtain_mbx_lock_pf Mar 2 19:26:45 fwt kernel: ixgbe_check_for_msg_pf Mar 2 19:26:45 fwt kernel: ixgbe_check_for_ack_pf Mar 2 19:26:45 fwt kernel: ixv0: at device 0.128 on pci8 Mar 2 19:26:45 fwt kernel: ixgbe_set_mac_type Mar 2 19:26:45 fwt kernel: Mar 2 19:26:45 fwt kernel: ixgbe_set_mac_type found mac: 5, returns: 0 Mar 2 19:26:45 fwt kernel: Mar 2 19:26:45 fwt kernel: ixv0: Using MSIX interrupts with 2 vectors Mar 2 19:26:45 fwt kernel: ixgbe_init_shared_code Mar 2 19:26:45 fwt kernel: ixgbe_set_mac_type Mar 2 19:26:45 fwt kernel: Mar 2 19:26:45 fwt kernel: ixgbe_set_mac_type found mac: 5, returns: 0 Mar 2 19:26:45 fwt kernel: Mar 2 19:26:45 fwt kernel: ixgbevf_reset_hw_vf Mar 2 19:26:45 fwt kernel: Issuing a function level reset to MAC Mar 2 19:26:45 fwt kernel: Mar 2 19:26:45 fwt kernel: ixgbe_check_for_rst_vf Mar 2 19:26:45 fwt kernel: ixgbe_check_for_rst_vf Mar 2 19:26:45 fwt kernel: ixgbe_write_posted_mbx Mar 2 19:26:45 fwt kernel: ixgbe_write_mbx_vf Mar 2 19:26:45 fwt kernel: ixgbe_obtain_mbx_lock_vf Mar 2 19:26:45 fwt kernel: ixgbe_check_for_msg_vf Mar 2 19:26:45 fwt kernel: ixgbe_check_for_ack_vf Mar 2 19:26:45 fwt kernel: ixgbe_poll_for_ack Mar 2 19:26:45 fwt kernel: ixgbe_check_for_ack_vf Mar 2 19:26:45 fwt last message repeated 1999 times Mar 2 19:26:45 fwt kernel: ixv0: Polling for VF0 mailbox ack timedoutixgbe_read_posted_mbx Mar 2 19:26:45 fwt kernel: ixgbe_poll_for_msg Mar 2 19:26:45 fwt kernel: ixgbe_check_for_msg_vf Mar 2 19:26:45 fwt last message repeated 1999 times Mar 2 19:26:45 fwt kernel: ixv0: Polling for VF0 mailbox message timedoutixv0: ixgbe_reset_hw() failed with error -100 Mar 2 19:26:45 fwt kernel: device_attach: ixv0 attach returned 5 Mar 2 19:26:54 fwt devd: Processing event '!system=IFNET subsystem=ix0 type=LINK_UP' Mar 2 19:26:54 fwt kernel: ixgbe_check_mac_link_generic Mar 2 19:26:54 fwt kernel: ixgbe_fc_enable_generic Mar 2 19:26:54 fwt kernel: ixgbe_fc_autoneg Mar 2 19:26:54 fwt kernel: ix0: Flow control autoneg is disabledixgbe_write_mbx Mar 2 19:26:54 fwt kernel: ixgbe_write_mbx_pf Mar 2 19:26:54 fwt kernel: ixgbe_obtain_mbx_lock_pf Mar 2 19:26:54 fwt kernel: ix0: link state changed to UP Mar 2 19:26:54 fwt kernel: ixgbe_check_for_msg_pf Mar 2 19:26:54 fwt kernel: ixgbe_check_for_ack_pf Mar 2 19:26:54 fwt kernel: ixgbe_check_for_rst Mar 2 19:26:54 fwt kernel: ixgbe_check_for_rst_pf Mar 2 19:26:54 fwt kernel: ixgbe_check_for_msg Mar 2 19:26:54 fwt kernel: ixgbe_check_for_msg_pf Mar 2 19:26:54 fwt kernel: ixgbe_check_for_ack Mar 2 19:26:54 fwt kernel: ixgbe_check_for_ack_pf Mar 2 19:26:54 fwt devd: Executing '/etc/rc.d/dhclient quietstart ix0' From owner-freebsd-net@freebsd.org Wed Mar 2 18:10:29 2016 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 2FF2FAC1FE7 for ; Wed, 2 Mar 2016 18:10:29 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF2718E7 for ; Wed, 2 Mar 2016 18:10:29 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from [192.0.2.7] (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 500BA564B5 for ; Wed, 2 Mar 2016 12:10:22 -0600 (CST) Subject: Re: ixv0: Polling for VF0 mailbox ack timedout References: <56D72903.6000906@FreeBSD.org> From: Eric van Gyzen Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (13D15) In-Reply-To: <56D72903.6000906@FreeBSD.org> Message-Id: Date: Wed, 2 Mar 2016 12:10:20 -0600 To: "freebsd-net@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (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, 02 Mar 2016 18:10:29 -0000 I failed to mention, I'm running head from yesterday. Eric > On Mar 2, 2016, at 11:55 AM, Eric van Gyzen wrote: >=20 > I'm having trouble creating a VF on an ix NIC. The NIC is: >=20 > ix0@pci0:1:0:0: class=3D0x020000 card=3D0x1f611028 chip=3D0x15288086= rev=3D0x03 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Ethernet Controller 10-Gigabit X540-AT2' > class =3D network > subclass =3D ethernet >=20 >=20 > My /etc/iovctl.conf is pretty simple: >=20 > PF { > device : "ix0"; > num_vfs : 1; > } >=20 > DEFAULT { > passthrough : false; > } >=20 >=20 > I'm running this: >=20 > # iovctl -S -f /etc/iovctl.conf >=20 >=20 > The VF gets created: >=20 > none160@pci0:1:0:128: class=3D0x020000 card=3D0x1f611028 chip=3D0x15= 158086 > rev=3D0x03 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'X540 Ethernet Controller Virtual Function' > class =3D network > subclass =3D ethernet >=20 >=20 > But the driver fails to attach: >=20 > ixv0: ixgbe_reset_hw() failed with error -100 > device_attach: ixv0 attach returned 5 >=20 >=20 > I rebuilt with DBG=3D1 in ixgbe_osdep.h. The debug messages are below. >=20 > The only relevant setting [that I could find] in the BIOS setup was SR-IOV= > Global Enable, which is enabled. >=20 > What should I try next? >=20 > Thanks, >=20 > Eric >=20 > =3D=3D=3D=3D >=20 > Mar 2 19:26:42 fwt kernel: ixgbe_stop_adapter_generic > Mar 2 19:26:42 fwt kernel: ixgbe_disable_pcie_master > Mar 2 19:26:42 fwt kernel: ixgbe_set_rar_generic > Mar 2 19:26:42 fwt kernel: ixgbe_set_vmdq_generic > Mar 2 19:26:42 fwt kernel: ixgbe_set_rar_generic > Mar 2 19:26:42 fwt kernel: ixgbe_set_vmdq_generic > Mar 2 19:26:42 fwt kernel: ixgbe_init_hw_generic > Mar 2 19:26:42 fwt kernel: ixgbe_reset_hw_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_stop_adapter_generic > Mar 2 19:26:42 fwt kernel: ixgbe_disable_pcie_master > Mar 2 19:26:42 fwt kernel: ixgbe_get_mac_addr_generic > Mar 2 19:26:42 fwt kernel: ixgbe_init_rx_addrs_generic > Mar 2 19:26:42 fwt kernel: ixgbe_validate_mac_addr > Mar 2 19:26:42 fwt kernel: Overriding MAC Address in RAR[0] > Mar 2 19:26:42 fwt kernel: > Mar 2 19:26:42 fwt kernel: New MAC Addr =3DEC F4 BB > Mar 2 19:26:42 fwt kernel: D6 B5 10 > Mar 2 19:26:42 fwt kernel: > Mar 2 19:26:42 fwt kernel: ixgbe_set_rar_generic > Mar 2 19:26:42 fwt kernel: ixgbe_set_vmdq_generic > Mar 2 19:26:42 fwt kernel: ixgbe_clear_vmdq_generic > Mar 2 19:26:42 fwt kernel: Clearing RAR[1-127] > Mar 2 19:26:42 fwt kernel: > Mar 2 19:26:42 fwt kernel: Clearing MTA > Mar 2 19:26:42 fwt kernel: > Mar 2 19:26:42 fwt kernel: ixgbe_init_uta_tables_generic > Mar 2 19:26:42 fwt kernel: Clearing UTA > Mar 2 19:26:42 fwt kernel: > Mar 2 19:26:42 fwt kernel: ixgbe_get_san_mac_addr_generic > Mar 2 19:26:42 fwt kernel: ixgbe_get_san_mac_addr_offset > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic > Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_set_lan_id_multi_port_pcie > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic > Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic > Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic > Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_validate_mac_addr > Mar 2 19:26:42 fwt kernel: ixgbe_set_rar_generic > Mar 2 19:26:42 fwt kernel: ixgbe_set_vmdq_generic > Mar 2 19:26:42 fwt kernel: ixgbe_get_wwn_prefix_generic > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic > Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic > Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic > Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_eerd_buffer_generic > Mar 2 19:26:42 fwt kernel: ixgbe_init_eeprom_params_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_poll_eerd_eewr_done > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_start_hw_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_start_hw_generic > Mar 2 19:26:42 fwt kernel: ixgbe_clear_vfta_generic > Mar 2 19:26:42 fwt kernel: ixgbe_clear_hw_cntrs_generic > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_setup_fc_generic > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_device_supports_autoneg_fc > Mar 2 19:26:42 fwt kernel: ixgbe_write_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: Set up FC; PCS1GLCTL =3D 0x00000000 > Mar 2 19:26:42 fwt kernel: > Mar 2 19:26:42 fwt kernel: ixgbe_update_mc_addr_list_generic > Mar 2 19:26:42 fwt kernel: Clearing MTA > Mar 2 19:26:42 fwt kernel: > Mar 2 19:26:42 fwt kernel: ixgbe_update_mc_addr_list_generic Complete > Mar 2 19:26:42 fwt kernel: > Mar 2 19:26:42 fwt kernel: ixgbe_enable_rx_dma_generic > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_write_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_check_mac_link_generic > Mar 2 19:26:42 fwt kernel: ixgbe_get_copper_link_capabilities_generic > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_setup_mac_link_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_setup_phy_link_speed_generic > Mar 2 19:26:42 fwt kernel: ixgbe_setup_phy_link_generic > Mar 2 19:26:42 fwt kernel: ixgbe_get_copper_link_capabilities_generic > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_write_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_write_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_write_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_check_reset_blocked > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_write_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_start_hw_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_start_hw_generic > Mar 2 19:26:42 fwt kernel: ixgbe_clear_vfta_generic > Mar 2 19:26:42 fwt kernel: ixgbe_clear_hw_cntrs_generic > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:42 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:42 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:42 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:43 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:43 fwt kernel: ixgbe_setup_fc_generic > Mar 2 19:26:43 fwt kernel: ixgbe_read_phy_reg_generic > Mar 2 19:26:43 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:43 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:43 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:43 fwt kernel: ixgbe_device_supports_autoneg_fc > Mar 2 19:26:43 fwt kernel: ixgbe_write_phy_reg_generic > Mar 2 19:26:43 fwt kernel: ixgbe_acquire_swfw_sync_X540 > Mar 2 19:26:43 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_X540 > Mar 2 19:26:43 fwt kernel: ixgbe_get_swfw_sync_semaphore > Mar 2 19:26:43 fwt kernel: ixgbe_release_swfw_sync_semaphore > Mar 2 19:26:43 fwt kernel: Set up FC; PCS1GLCTL =3D 0x00000180 > Mar 2 19:26:43 fwt kernel: > Mar 2 19:26:43 fwt kernel: ixgbe_check_mac_link_generic > Mar 2 19:26:45 fwt kernel: ixgbe_validate_mac_addr > Mar 2 19:26:45 fwt kernel: MAC address is all zeros > Mar 2 19:26:45 fwt kernel: > Mar 2 19:26:45 fwt kernel: ixgbe_write_mbx > Mar 2 19:26:45 fwt kernel: ixgbe_write_mbx_pf > Mar 2 19:26:45 fwt kernel: ixgbe_obtain_mbx_lock_pf > Mar 2 19:26:45 fwt kernel: ixgbe_check_for_msg_pf > Mar 2 19:26:45 fwt kernel: ixgbe_check_for_ack_pf > Mar 2 19:26:45 fwt kernel: ixv0: Driver, Version - 1.4.6-k> at device 0.128 on pci8 > Mar 2 19:26:45 fwt kernel: ixgbe_set_mac_type > Mar 2 19:26:45 fwt kernel: > Mar 2 19:26:45 fwt kernel: ixgbe_set_mac_type found mac: 5, returns: 0 > Mar 2 19:26:45 fwt kernel: > Mar 2 19:26:45 fwt kernel: ixv0: Using MSIX interrupts with 2 vectors > Mar 2 19:26:45 fwt kernel: ixgbe_init_shared_code > Mar 2 19:26:45 fwt kernel: ixgbe_set_mac_type > Mar 2 19:26:45 fwt kernel: > Mar 2 19:26:45 fwt kernel: ixgbe_set_mac_type found mac: 5, returns: 0 > Mar 2 19:26:45 fwt kernel: > Mar 2 19:26:45 fwt kernel: ixgbevf_reset_hw_vf > Mar 2 19:26:45 fwt kernel: Issuing a function level reset to MAC > Mar 2 19:26:45 fwt kernel: > Mar 2 19:26:45 fwt kernel: ixgbe_check_for_rst_vf > Mar 2 19:26:45 fwt kernel: ixgbe_check_for_rst_vf > Mar 2 19:26:45 fwt kernel: ixgbe_write_posted_mbx > Mar 2 19:26:45 fwt kernel: ixgbe_write_mbx_vf > Mar 2 19:26:45 fwt kernel: ixgbe_obtain_mbx_lock_vf > Mar 2 19:26:45 fwt kernel: ixgbe_check_for_msg_vf > Mar 2 19:26:45 fwt kernel: ixgbe_check_for_ack_vf > Mar 2 19:26:45 fwt kernel: ixgbe_poll_for_ack > Mar 2 19:26:45 fwt kernel: ixgbe_check_for_ack_vf > Mar 2 19:26:45 fwt last message repeated 1999 times > Mar 2 19:26:45 fwt kernel: ixv0: Polling for VF0 mailbox ack > timedoutixgbe_read_posted_mbx > Mar 2 19:26:45 fwt kernel: ixgbe_poll_for_msg > Mar 2 19:26:45 fwt kernel: ixgbe_check_for_msg_vf > Mar 2 19:26:45 fwt last message repeated 1999 times > Mar 2 19:26:45 fwt kernel: ixv0: Polling for VF0 mailbox message timedout= ixv0: > ixgbe_reset_hw() failed with error -100 > Mar 2 19:26:45 fwt kernel: device_attach: ixv0 attach returned 5 > Mar 2 19:26:54 fwt devd: Processing event '!system=3DIFNET subsystem=3Dix= 0 > type=3DLINK_UP' > Mar 2 19:26:54 fwt kernel: ixgbe_check_mac_link_generic > Mar 2 19:26:54 fwt kernel: ixgbe_fc_enable_generic > Mar 2 19:26:54 fwt kernel: ixgbe_fc_autoneg > Mar 2 19:26:54 fwt kernel: ix0: Flow control autoneg is disabledixgbe_wri= te_mbx > Mar 2 19:26:54 fwt kernel: ixgbe_write_mbx_pf > Mar 2 19:26:54 fwt kernel: ixgbe_obtain_mbx_lock_pf > Mar 2 19:26:54 fwt kernel: ix0: link state changed to UP > Mar 2 19:26:54 fwt kernel: ixgbe_check_for_msg_pf > Mar 2 19:26:54 fwt kernel: ixgbe_check_for_ack_pf > Mar 2 19:26:54 fwt kernel: ixgbe_check_for_rst > Mar 2 19:26:54 fwt kernel: ixgbe_check_for_rst_pf > Mar 2 19:26:54 fwt kernel: ixgbe_check_for_msg > Mar 2 19:26:54 fwt kernel: ixgbe_check_for_msg_pf > Mar 2 19:26:54 fwt kernel: ixgbe_check_for_ack > Mar 2 19:26:54 fwt kernel: ixgbe_check_for_ack_pf > Mar 2 19:26:54 fwt devd: Executing '/etc/rc.d/dhclient quietstart ix0' >=20 >=20 > _______________________________________________ > 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" >=20 From owner-freebsd-net@freebsd.org Thu Mar 3 05:06:09 2016 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 4397CAC2E0E for ; Thu, 3 Mar 2016 05:06:09 +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 346191CDD for ; Thu, 3 Mar 2016 05:06:09 +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 u235694h093304 for ; Thu, 3 Mar 2016 05:06:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206186] [patch][netgraph] New netgraph node for calculate IP IP6 TCP UDP checksums Date: Thu, 03 Mar 2016 05:06:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: daemon.hammer@ya.ru X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 03 Mar 2016 05:06:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206186 --- Comment #2 from Dmitry Vagin --- Created attachment 167669 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D167669&action= =3Dedit manpage We have to check my bad english --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 3 10:38:30 2016 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 79B08A93ECB for ; Thu, 3 Mar 2016 10:38:30 +0000 (UTC) (envelope-from pg@pakhom.spb.ru) Received: from mail.pakhom.spb.ru (mail.pakhom.spb.ru [5.19.176.65]) (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 410DB21D for ; Thu, 3 Mar 2016 10:38:30 +0000 (UTC) (envelope-from pg@pakhom.spb.ru) Received: from [78.25.122.220] (helo=[10.160.235.239]) by mail.pakhom.spb.ru with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1abQeD-00021Q-Fs for freebsd-net@FreeBSD.org; Thu, 03 Mar 2016 13:38:21 +0300 To: freebsd-net@FreeBSD.org From: Pakhom Golynga Subject: routing issue Message-ID: <56D81418.9020500@pakhom.spb.ru> Date: Thu, 3 Mar 2016 13:38:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 78.25.122.220 X-SA-Exim-Mail-From: pg@pakhom.spb.ru X-SA-Exim-Scanned: No (on mail.pakhom.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 10:38:30 -0000 Hello all! Please help me to investigate this issue. I have problem on 10.2-RELEASE-p12 with multiple network interfaces and PF (rules, NAT) # ifconfig <--cut--> em0: flags=8843 metric 0 mtu 1500 options=4209b ether 00:25:90:64:14:50 inet 172.27.27.254 netmask 0xffffff00 broadcast 172.27.27.255 inet 172.27.27.240 netmask 0xffffffff broadcast 172.27.27.240 inet 172.27.27.252 netmask 0xffffffff broadcast 172.27.27.252 inet 172.27.27.251 netmask 0xffffffff broadcast 172.27.27.251 inet 172.27.27.250 netmask 0xffffffff broadcast 172.27.27.250 inet 172.27.27.249 netmask 0xffffffff broadcast 172.27.27.249 inet 172.27.27.248 netmask 0xffffffff broadcast 172.27.27.248 inet 172.27.27.247 netmask 0xffffffff broadcast 172.27.27.247 inet 172.27.27.246 netmask 0xffffffff broadcast 172.27.27.246 inet 172.27.27.245 netmask 0xffffffff broadcast 172.27.27.245 inet 172.27.27.244 netmask 0xffffffff broadcast 172.27.27.244 inet 172.27.27.243 netmask 0xffffffff broadcast 172.27.27.243 inet 172.27.27.242 netmask 0xffffffff broadcast 172.27.27.242 inet 172.27.27.241 netmask 0xffffffff broadcast 172.27.27.241 inet 172.27.27.239 netmask 0xffffffff broadcast 172.27.27.239 inet 172.27.27.238 netmask 0xffffffff broadcast 172.27.27.238 inet 172.27.27.237 netmask 0xffffffff broadcast 172.27.27.237 inet 172.27.27.236 netmask 0xffffffff broadcast 172.27.27.236 inet 172.27.27.235 netmask 0xffffffff broadcast 172.27.27.235 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8943 metric 0 mtu 1500 options=4209b ether 00:25:90:64:14:51 inet 10.24.44.50 netmask 0xfffffc00 broadcast 10.24.47.255 media: Ethernet autoselect (100baseTX ) status: active <--cut--> em0 - local network. Aliases on em0 for Jail's em1 - connected to ISP This configuration successfully operate a long time but recently (for no apparent reason) suddenly became manifest bug with routing. Regardless from uptime (sometimes 12 hours, and maybe a couple of days) after a certain time the traffic running between jails begins to route via em1 (instead lo0 (net.link.ether.inet.useloopback=1)): # tcpdump -n -e -ttt -i em1 host 172.27.27.252 or host 172.27.27.247 or host 172.27.27.248 00:00:00.054989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161568673 ecr 0], length 0 00:00:00.318036 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.60176: Flags [.], ack 772660872, win 1275, options [nop,nop,TS val 1737287913 ecr 161568991], length 0 00:00:00.036971 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.33080: Flags [.], ack 1, win 1275, options [nop,nop,TS val 1701623130 ecr 161568238], length 0 00:00:00.050001 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.40200: Flags [.], ack 1, win 1275, options [nop,nop,TS val 1477098721 ecr 161568288], length 0 00:00:02.794992 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161571873 ecr 0], length 0 00:00:03.312026 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161575185 ecr 0], length 0 00:00:02.887982 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161578073 ecr 0], length 0 00:00:00.111989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161578185 ecr 0], length 0 00:00:03.471007 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 108: 172.27.27.247.80 > 172.27.27.248.26056: Flags [FP.], seq 1448:1490, ack 1, win 1275, options [nop,nop,TS val 2142270801 ecr 161575507], length 42 In the same time: # route -vn get -host RTA_DST: inet 172.27.27.247; RTA_IFP: link ; RTM_GET: Report Metrics: len 224, pid: 0, seq 1, errno 0, flags: locks: inits: sockaddrs: 172.27.27.247 link#0 route to: 172.27.27.247 destination: 172.27.27.247 fib: 0 interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 locks: inits: sockaddrs: 172.27.27.247 link#4 lo0 127.0.0.1 RTA_DST: inet 172.27.27.250; RTA_IFP: link ; RTM_GET: Report Metrics: len 224, pid: 0, seq 1, errno 0, flags: locks: inits: sockaddrs: 172.27.27.250 link#0 route to: 172.27.27.250 destination: 172.27.27.250 fib: 0 interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 locks: inits: sockaddrs: 172.27.27.250 link#4 lo0 127.0.0.1 RTA_DST: inet 172.27.27.252; RTA_IFP: link ; RTM_GET: Report Metrics: len 224, pid: 0, seq 1, errno 0, flags: locks: inits: sockaddrs: 172.27.27.252 link#0 route to: 172.27.27.252 destination: 172.27.27.252 fib: 0 interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 locks: inits: sockaddrs: 172.27.27.252 link#4 lo0 127.0.0.1 # netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire default 10.24.44.1 UGS em1 10.24.44.0/22 link#5 U em1 10.24.44.50 link#5 UHS lo0 127.0.0.1 link#7 UH lo0 172.27.27.0/24 link#4 U em0 172.27.27.235 link#4 UHS lo0 172.27.27.235/32 link#4 U em0 172.27.27.236 link#4 UHS lo0 172.27.27.236/32 link#4 U em0 172.27.27.237 link#4 UHS lo0 172.27.27.237/32 link#4 U em0 172.27.27.238 link#4 UHS lo0 172.27.27.238/32 link#4 U em0 172.27.27.239 link#4 UHS lo0 172.27.27.239/32 link#4 U em0 172.27.27.240 link#4 UHS lo0 172.27.27.240/32 link#4 U em0 172.27.27.241 link#4 UHS lo0 172.27.27.241/32 link#4 U em0 172.27.27.242 link#4 UHS lo0 172.27.27.242/32 link#4 U em0 172.27.27.243 link#4 UHS lo0 172.27.27.243/32 link#4 U em0 172.27.27.244 link#4 UHS lo0 172.27.27.244/32 link#4 U em0 172.27.27.245 link#4 UHS lo0 172.27.27.245/32 link#4 U em0 172.27.27.246 link#4 UHS lo0 172.27.27.246/32 link#4 U em0 172.27.27.247 link#4 UHS lo0 172.27.27.247/32 link#4 U em0 172.27.27.248 link#4 UHS lo0 172.27.27.248/32 link#4 U em0 172.27.27.249 link#4 UHS lo0 172.27.27.249/32 link#4 U em0 172.27.27.250 link#4 UHS lo0 172.27.27.250/32 link#4 U em0 172.27.27.251 link#4 UHS lo0 172.27.27.251/32 link#4 U em0 172.27.27.252 link#4 UHS lo0 172.27.27.252/32 link#4 U em0 172.27.27.254 link#4 UHS lo0 172.27.28.0/24 link#8 U bridge0 172.27.28.254 link#8 UHS lo0 172.27.30.0/24 172.27.30.2 UGS tun0 172.27.30.1 link#12 UHS lo0 172.27.30.2 link#12 UH tun0 After the reboot everything works well for some time. Thanks! From owner-freebsd-net@freebsd.org Thu Mar 3 15:01:04 2016 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 CD9F7A93649 for ; Thu, 3 Mar 2016 15:01:04 +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 BEE15929 for ; Thu, 3 Mar 2016 15:01:04 +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 u23F14jJ066816 for ; Thu, 3 Mar 2016 15:01:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193802] tso seems broken on RELENG10 for version 7.4.2 of em driver Date: Thu, 03 Mar 2016 15:01:04 +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 Many People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 15:01:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193802 --- Comment #7 from Sean Bruno --- Please retest this issue with the 10.3 BETA version of the em(4) driver. There's a bit of stuff around DMA that got sorted out finally and hopefully= for good that should make this problem a solved one. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 3 14:59:54 2016 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 D9C75A93523 for ; Thu, 3 Mar 2016 14:59:54 +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 CAD9C899 for ; Thu, 3 Mar 2016 14:59:54 +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 u23ExsKm023876 for ; Thu, 3 Mar 2016 14:59:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 173137] [lem] em(4) unable to run at gigabit with 9.1-RC2 Date: Thu, 03 Mar 2016 14:59:55 +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: unspecified X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 14:59:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D173137 --- Comment #2 from Sean Bruno --- This is definitely no longer happening here. Can you retest with 10.2 or 10.3BETA if possible? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 3 12:53:42 2016 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 8BD27A930A0 for ; Thu, 3 Mar 2016 12:53:42 +0000 (UTC) (envelope-from pg@pakhom.spb.ru) Received: from mail.pakhom.spb.ru (mail.pakhom.spb.ru [5.19.176.65]) (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 526CE90F for ; Thu, 3 Mar 2016 12:53:42 +0000 (UTC) (envelope-from pg@pakhom.spb.ru) Received: from [78.25.122.220] (helo=[10.160.235.239]) by mail.pakhom.spb.ru with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1abSl9-0002oI-IY for freebsd-net@FreeBSD.org; Thu, 03 Mar 2016 15:53:39 +0300 From: Pakhom Golynga Subject: routing issue To: freebsd-net@FreeBSD.org Message-ID: <56D833CE.1070800@pakhom.spb.ru> Date: Thu, 3 Mar 2016 15:53:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 78.25.122.220 X-SA-Exim-Mail-From: pg@pakhom.spb.ru X-SA-Exim-Scanned: No (on mail.pakhom.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 12:53:42 -0000 Hello all! Please help me to investigate this issue. I have problem on 10.2-RELEASE-p12 with multiple network interfaces and PF (rules, NAT) # ifconfig <--cut--> em0: flags=8843 metric 0 mtu 1500 options=4209b ether 00:25:90:64:14:50 inet 172.27.27.254 netmask 0xffffff00 broadcast 172.27.27.255 inet 172.27.27.240 netmask 0xffffffff broadcast 172.27.27.240 inet 172.27.27.252 netmask 0xffffffff broadcast 172.27.27.252 inet 172.27.27.251 netmask 0xffffffff broadcast 172.27.27.251 inet 172.27.27.250 netmask 0xffffffff broadcast 172.27.27.250 inet 172.27.27.249 netmask 0xffffffff broadcast 172.27.27.249 inet 172.27.27.248 netmask 0xffffffff broadcast 172.27.27.248 inet 172.27.27.247 netmask 0xffffffff broadcast 172.27.27.247 inet 172.27.27.246 netmask 0xffffffff broadcast 172.27.27.246 inet 172.27.27.245 netmask 0xffffffff broadcast 172.27.27.245 inet 172.27.27.244 netmask 0xffffffff broadcast 172.27.27.244 inet 172.27.27.243 netmask 0xffffffff broadcast 172.27.27.243 inet 172.27.27.242 netmask 0xffffffff broadcast 172.27.27.242 inet 172.27.27.241 netmask 0xffffffff broadcast 172.27.27.241 inet 172.27.27.239 netmask 0xffffffff broadcast 172.27.27.239 inet 172.27.27.238 netmask 0xffffffff broadcast 172.27.27.238 inet 172.27.27.237 netmask 0xffffffff broadcast 172.27.27.237 inet 172.27.27.236 netmask 0xffffffff broadcast 172.27.27.236 inet 172.27.27.235 netmask 0xffffffff broadcast 172.27.27.235 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8943 metric 0 mtu 1500 options=4209b ether 00:25:90:64:14:51 inet 10.24.44.50 netmask 0xfffffc00 broadcast 10.24.47.255 media: Ethernet autoselect (100baseTX ) status: active <--cut--> em0 - local network. Aliases on em0 for Jail's em1 - connected to ISP This configuration successfully operate a long time but recently (for no apparent reason) suddenly became manifest bug with routing. Regardless from uptime (sometimes 12 hours, and maybe a couple of days) after a certain time the traffic running between jails begins to route via em1 (instead lo0 (net.link.ether.inet.useloopback=1)): # tcpdump -n -e -ttt -i em1 host 172.27.27.252 or host 172.27.27.247 or host 172.27.27.248 00:00:00.054989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161568673 ecr 0], length 0 00:00:00.318036 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.60176: Flags [.], ack 772660872, win 1275, options [nop,nop,TS val 1737287913 ecr 161568991], length 0 00:00:00.036971 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.33080: Flags [.], ack 1, win 1275, options [nop,nop,TS val 1701623130 ecr 161568238], length 0 00:00:00.050001 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.40200: Flags [.], ack 1, win 1275, options [nop,nop,TS val 1477098721 ecr 161568288], length 0 00:00:02.794992 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161571873 ecr 0], length 0 00:00:03.312026 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161575185 ecr 0], length 0 00:00:02.887982 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161578073 ecr 0], length 0 00:00:00.111989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161578185 ecr 0], length 0 00:00:03.471007 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 108: 172.27.27.247.80 > 172.27.27.248.26056: Flags [FP.], seq 1448:1490, ack 1, win 1275, options [nop,nop,TS val 2142270801 ecr 161575507], length 42 In the same time: # route -vn get -host RTA_DST: inet 172.27.27.247; RTA_IFP: link ; RTM_GET: Report Metrics: len 224, pid: 0, seq 1, errno 0, flags: locks: inits: sockaddrs: 172.27.27.247 link#0 route to: 172.27.27.247 destination: 172.27.27.247 fib: 0 interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 locks: inits: sockaddrs: 172.27.27.247 link#4 lo0 127.0.0.1 RTA_DST: inet 172.27.27.250; RTA_IFP: link ; RTM_GET: Report Metrics: len 224, pid: 0, seq 1, errno 0, flags: locks: inits: sockaddrs: 172.27.27.250 link#0 route to: 172.27.27.250 destination: 172.27.27.250 fib: 0 interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 locks: inits: sockaddrs: 172.27.27.250 link#4 lo0 127.0.0.1 RTA_DST: inet 172.27.27.252; RTA_IFP: link ; RTM_GET: Report Metrics: len 224, pid: 0, seq 1, errno 0, flags: locks: inits: sockaddrs: 172.27.27.252 link#0 route to: 172.27.27.252 destination: 172.27.27.252 fib: 0 interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 locks: inits: sockaddrs: 172.27.27.252 link#4 lo0 127.0.0.1 # netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire default 10.24.44.1 UGS em1 10.24.44.0/22 link#5 U em1 10.24.44.50 link#5 UHS lo0 127.0.0.1 link#7 UH lo0 172.27.27.0/24 link#4 U em0 172.27.27.235 link#4 UHS lo0 172.27.27.235/32 link#4 U em0 172.27.27.236 link#4 UHS lo0 172.27.27.236/32 link#4 U em0 172.27.27.237 link#4 UHS lo0 172.27.27.237/32 link#4 U em0 172.27.27.238 link#4 UHS lo0 172.27.27.238/32 link#4 U em0 172.27.27.239 link#4 UHS lo0 172.27.27.239/32 link#4 U em0 172.27.27.240 link#4 UHS lo0 172.27.27.240/32 link#4 U em0 172.27.27.241 link#4 UHS lo0 172.27.27.241/32 link#4 U em0 172.27.27.242 link#4 UHS lo0 172.27.27.242/32 link#4 U em0 172.27.27.243 link#4 UHS lo0 172.27.27.243/32 link#4 U em0 172.27.27.244 link#4 UHS lo0 172.27.27.244/32 link#4 U em0 172.27.27.245 link#4 UHS lo0 172.27.27.245/32 link#4 U em0 172.27.27.246 link#4 UHS lo0 172.27.27.246/32 link#4 U em0 172.27.27.247 link#4 UHS lo0 172.27.27.247/32 link#4 U em0 172.27.27.248 link#4 UHS lo0 172.27.27.248/32 link#4 U em0 172.27.27.249 link#4 UHS lo0 172.27.27.249/32 link#4 U em0 172.27.27.250 link#4 UHS lo0 172.27.27.250/32 link#4 U em0 172.27.27.251 link#4 UHS lo0 172.27.27.251/32 link#4 U em0 172.27.27.252 link#4 UHS lo0 172.27.27.252/32 link#4 U em0 172.27.27.254 link#4 UHS lo0 172.27.28.0/24 link#8 U bridge0 172.27.28.254 link#8 UHS lo0 172.27.30.0/24 172.27.30.2 UGS tun0 172.27.30.1 link#12 UHS lo0 172.27.30.2 link#12 UH tun0 After the reboot everything works well for some time. Thanks! From owner-freebsd-net@freebsd.org Thu Mar 3 15:07:56 2016 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 64A4BA937A5 for ; Thu, 3 Mar 2016 15:07: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 55BD7BCB for ; Thu, 3 Mar 2016 15:07: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 u23F7uTL010870 for ; Thu, 3 Mar 2016 15:07:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193802] tso seems broken on RELENG10 for version 7.4.2 of em driver Date: Thu, 03 Mar 2016 15:07: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: 10.0-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: mike@sentex.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 15:07:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193802 --- Comment #8 from mike@sentex.net --- Thanks, I was working with marius@ to test on certain hardware and media configs and it seems to have resolved this issue. See the discussion in the thread https://lists.freebsd.org/pipermail/freebsd-stable/2016-January/084028.html --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 3 22:49:47 2016 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 7DDDDA949C2 for ; Thu, 3 Mar 2016 22:49:47 +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 6F0C78F6 for ; Thu, 3 Mar 2016 22:49:47 +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 u23Mnl7H037713 for ; Thu, 3 Mar 2016 22:49:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197351] [ip6] panic when lagg(4) removes IPv6 addresses from member interface Date: Thu, 03 Mar 2016 22:49:47 +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: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 22:49:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197351 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |araujo@FreeBSD.org --- Comment #1 from Hiren Panchasara --- Is this still a problem? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 3 20:00:30 2016 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 44783A93C74 for ; Thu, 3 Mar 2016 20:00:30 +0000 (UTC) (envelope-from pakhom706@gmail.com) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4C7038A for ; Thu, 3 Mar 2016 20:00:29 +0000 (UTC) (envelope-from pakhom706@gmail.com) Received: by mail-lb0-x231.google.com with SMTP id cf7so20591796lbb.1 for ; Thu, 03 Mar 2016 12:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=/vn6xBKeMfU0G8xz9a/UtrlTB939xcoCt5Qvjyno2u8=; b=q1g0NJYPEMfdgX+qRMPwfxoBMQO4WuJZkJ6baykOr7uP7o8NAtfhBanquThzsGYYht 5tQ/vDOwtk2liAPZwQQyrekABmx2T+0JAxuiU65rVQ1C+AtsxSJndTlmE6wYoSOnycaX llrWRYjMkr81lQpS1I0IvUSG1paSFUrZyfPa2j8IufpNb/OUxBch974NfkF7UU8r5wll 8PRxmb6Dmsps3r0SCQm7A09YDVh5RnJLyB0p5DBOo/Wn7jCZN4T5st+pidTQCmzIFjs3 hQBhWy1imO9pgl/0dK+h3/o7W6gUwj1nXmwi2NPk2+TA1doA5bKJHxKlcUNpZdZeKY79 /OBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=/vn6xBKeMfU0G8xz9a/UtrlTB939xcoCt5Qvjyno2u8=; b=DWdEqMhn5t/B/dh5K2tC516oNUrB8+5PcceCNlGIflHcFdgxG3DAC6+d8koU6Izbsh UILMLcZPxRm5MWtu20ai77cWpiT13A0AF8KytTUMp0M99Cv6KnVKSHE1fgYz8EIjTjgd deJ4ApAEEVNQvD/K0RjjTfk4h9YqY3gBr5VFi0qsZkIeUSPJXzV+Bp8T7fcqKPUGlPcm 0M9hkHXUyJZsJGMrJ9AVMqu0DCum68kSLt2eFNO4AGYRU2DQZXFTNBiYcgOShKj1qdkQ WTl/sBhwksh/R8/KD5bK8oq1MOVD8oe++v6Fz04I/UhgQ2HlITahAWG9qVGa04ChSUMs xeXw== X-Gm-Message-State: AD7BkJJtcB/S9St0JC6ZhUCCiPXKBaete+5Hdf7eOiXyw1Og2sP+Ebuw3dQiE72/3VRq5Q== X-Received: by 10.25.160.140 with SMTP id j134mr1840950lfe.1.1457035227819; Thu, 03 Mar 2016 12:00:27 -0800 (PST) Received: from [172.27.27.11] (mail.pakhom.spb.ru. [5.19.176.65]) by smtp.googlemail.com with ESMTPSA id ke9sm8868lbc.28.2016.03.03.12.00.26 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Mar 2016 12:00:26 -0800 (PST) From: Pakhom Golynga Subject: routing issue To: freebsd-net@FreeBSD.org Message-ID: <56D897D9.2040502@gmail.com> Date: Thu, 3 Mar 2016 23:00:25 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 20:00:30 -0000 Hello all! Please help me to investigate this issue. I have problem on 10.2-RELEASE-p12 with multiple network interfaces and PF (rules, NAT) # ifconfig <--cut--> em0: flags=8843 metric 0 mtu 1500 options=4209b ether 00:25:90:64:14:50 inet 172.27.27.254 netmask 0xffffff00 broadcast 172.27.27.255 inet 172.27.27.240 netmask 0xffffffff broadcast 172.27.27.240 inet 172.27.27.252 netmask 0xffffffff broadcast 172.27.27.252 inet 172.27.27.251 netmask 0xffffffff broadcast 172.27.27.251 inet 172.27.27.250 netmask 0xffffffff broadcast 172.27.27.250 inet 172.27.27.249 netmask 0xffffffff broadcast 172.27.27.249 inet 172.27.27.248 netmask 0xffffffff broadcast 172.27.27.248 inet 172.27.27.247 netmask 0xffffffff broadcast 172.27.27.247 inet 172.27.27.246 netmask 0xffffffff broadcast 172.27.27.246 inet 172.27.27.245 netmask 0xffffffff broadcast 172.27.27.245 inet 172.27.27.244 netmask 0xffffffff broadcast 172.27.27.244 inet 172.27.27.243 netmask 0xffffffff broadcast 172.27.27.243 inet 172.27.27.242 netmask 0xffffffff broadcast 172.27.27.242 inet 172.27.27.241 netmask 0xffffffff broadcast 172.27.27.241 inet 172.27.27.239 netmask 0xffffffff broadcast 172.27.27.239 inet 172.27.27.238 netmask 0xffffffff broadcast 172.27.27.238 inet 172.27.27.237 netmask 0xffffffff broadcast 172.27.27.237 inet 172.27.27.236 netmask 0xffffffff broadcast 172.27.27.236 inet 172.27.27.235 netmask 0xffffffff broadcast 172.27.27.235 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8943 metric 0 mtu 1500 options=4209b ether 00:25:90:64:14:51 inet 10.24.44.50 netmask 0xfffffc00 broadcast 10.24.47.255 media: Ethernet autoselect (100baseTX ) status: active <--cut--> em0 - local network. Aliases on em0 for Jail's em1 - connected to ISP This configuration successfully operate a long time but recently (for no apparent reason) suddenly became manifest bug with routing. Regardless from uptime (sometimes 12 hours, and maybe a couple of days) after a certain time the traffic running between jails begins to route via em1 (instead lo0 (net.link.ether.inet.useloopback=1)): # tcpdump -n -e -ttt -i em1 host 172.27.27.252 or host 172.27.27.247 or host 172.27.27.248 00:00:00.054989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161568673 ecr 0], length 0 00:00:00.318036 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.60176: Flags [.], ack 772660872, win 1275, options [nop,nop,TS val 1737287913 ecr 161568991], length 0 00:00:00.036971 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.33080: Flags [.], ack 1, win 1275, options [nop,nop,TS val 1701623130 ecr 161568238], length 0 00:00:00.050001 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.40200: Flags [.], ack 1, win 1275, options [nop,nop,TS val 1477098721 ecr 161568288], length 0 00:00:02.794992 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161571873 ecr 0], length 0 00:00:03.312026 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161575185 ecr 0], length 0 00:00:02.887982 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161578073 ecr 0], length 0 00:00:00.111989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 161578185 ecr 0], length 0 00:00:03.471007 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 (0x0800), length 108: 172.27.27.247.80 > 172.27.27.248.26056: Flags [FP.], seq 1448:1490, ack 1, win 1275, options [nop,nop,TS val 2142270801 ecr 161575507], length 42 In the same time: # route -vn get -host RTA_DST: inet 172.27.27.247; RTA_IFP: link ; RTM_GET: Report Metrics: len 224, pid: 0, seq 1, errno 0, flags: locks: inits: sockaddrs: 172.27.27.247 link#0 route to: 172.27.27.247 destination: 172.27.27.247 fib: 0 interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 locks: inits: sockaddrs: 172.27.27.247 link#4 lo0 127.0.0.1 RTA_DST: inet 172.27.27.250; RTA_IFP: link ; RTM_GET: Report Metrics: len 224, pid: 0, seq 1, errno 0, flags: locks: inits: sockaddrs: 172.27.27.250 link#0 route to: 172.27.27.250 destination: 172.27.27.250 fib: 0 interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 locks: inits: sockaddrs: 172.27.27.250 link#4 lo0 127.0.0.1 RTA_DST: inet 172.27.27.252; RTA_IFP: link ; RTM_GET: Report Metrics: len 224, pid: 0, seq 1, errno 0, flags: locks: inits: sockaddrs: 172.27.27.252 link#0 route to: 172.27.27.252 destination: 172.27.27.252 fib: 0 interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 locks: inits: sockaddrs: 172.27.27.252 link#4 lo0 127.0.0.1 # netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire default 10.24.44.1 UGS em1 10.24.44.0/22 link#5 U em1 10.24.44.50 link#5 UHS lo0 127.0.0.1 link#7 UH lo0 172.27.27.0/24 link#4 U em0 172.27.27.235 link#4 UHS lo0 172.27.27.235/32 link#4 U em0 172.27.27.236 link#4 UHS lo0 172.27.27.236/32 link#4 U em0 172.27.27.237 link#4 UHS lo0 172.27.27.237/32 link#4 U em0 172.27.27.238 link#4 UHS lo0 172.27.27.238/32 link#4 U em0 172.27.27.239 link#4 UHS lo0 172.27.27.239/32 link#4 U em0 172.27.27.240 link#4 UHS lo0 172.27.27.240/32 link#4 U em0 172.27.27.241 link#4 UHS lo0 172.27.27.241/32 link#4 U em0 172.27.27.242 link#4 UHS lo0 172.27.27.242/32 link#4 U em0 172.27.27.243 link#4 UHS lo0 172.27.27.243/32 link#4 U em0 172.27.27.244 link#4 UHS lo0 172.27.27.244/32 link#4 U em0 172.27.27.245 link#4 UHS lo0 172.27.27.245/32 link#4 U em0 172.27.27.246 link#4 UHS lo0 172.27.27.246/32 link#4 U em0 172.27.27.247 link#4 UHS lo0 172.27.27.247/32 link#4 U em0 172.27.27.248 link#4 UHS lo0 172.27.27.248/32 link#4 U em0 172.27.27.249 link#4 UHS lo0 172.27.27.249/32 link#4 U em0 172.27.27.250 link#4 UHS lo0 172.27.27.250/32 link#4 U em0 172.27.27.251 link#4 UHS lo0 172.27.27.251/32 link#4 U em0 172.27.27.252 link#4 UHS lo0 172.27.27.252/32 link#4 U em0 172.27.27.254 link#4 UHS lo0 172.27.28.0/24 link#8 U bridge0 172.27.28.254 link#8 UHS lo0 172.27.30.0/24 172.27.30.2 UGS tun0 172.27.30.1 link#12 UHS lo0 172.27.30.2 link#12 UH tun0 After the reboot everything works well for some time. Thanks! From owner-freebsd-net@freebsd.org Fri Mar 4 01:20:19 2016 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 4294BA934BB for ; Fri, 4 Mar 2016 01:20:19 +0000 (UTC) (envelope-from lonuestrocom@vm.intilabs.net) Received: from vm.intilabs.net (ns1.intilabs.net [108.178.49.83]) (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 2725B5E3 for ; Fri, 4 Mar 2016 01:20:18 +0000 (UTC) (envelope-from lonuestrocom@vm.intilabs.net) Received: from lonuestrocom by vm.intilabs.net with local (Exim 4.86_1) (envelope-from ) id 1abePi-0006WO-4a for freebsd-net@freebsd.org; Thu, 03 Mar 2016 20:20:18 -0500 To: freebsd-net@freebsd.org Subject: Attn: Payment Agent Needed!!! From: Victor Choi Reply-To: Victor Choi Message-Id: Date: Thu, 03 Mar 2016 20:20:18 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vm.intilabs.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [525 525] / [47 12] X-AntiAbuse: Sender Address Domain - vm.intilabs.net X-Get-Message-Sender-Via: vm.intilabs.net: authenticated_id: lonuestrocom/only user confirmed/virtual account not confirmed X-Authenticated-Sender: vm.intilabs.net: lonuestrocom MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 01:20:19 -0000 From owner-freebsd-net@freebsd.org Fri Mar 4 03:43:25 2016 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 C7F29A93E6D for ; Fri, 4 Mar 2016 03:43:25 +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 B8948986 for ; Fri, 4 Mar 2016 03:43:25 +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 u243hPkE046311 for ; Fri, 4 Mar 2016 03:43:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197351] [ip6] panic when lagg(4) removes IPv6 addresses from member interface Date: Fri, 04 Mar 2016 03:43:25 +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: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: araujo@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: araujo@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 03:43:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197351 Marcelo Araujo changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |araujo@FreeBSD.org --- Comment #2 from Marcelo Araujo --- Let take a look on this! I had a very similar problem when I use vtnet(4), not sure yet if there is = any relation specific with this PR. Thanks to Cc me! Best, --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 4 15:10:24 2016 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 4357E9DB202 for ; Fri, 4 Mar 2016 15:10:24 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 E670DFE1 for ; Fri, 4 Mar 2016 15:10:23 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id p65so32938628wmp.0 for ; Fri, 04 Mar 2016 07:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=12gCECmkBZGZ1ZQ9phh4LY7sgpySLwSS1feltRQa6XA=; b=xocgDwLmYQs7LLsNkGUco5T4f7FQeJt2hmq2DCQPgaOv5nm3yyybx8LdHm86ujKERT oxzgGab5BMMjP3sQstKhwffBgHLHI+K3jElNdGfJj9v3oF5MqzIS1/vITZq2qzGEnAqW N52MkFY6XdAPEa3Q7ifZpJpVxNKpkYtDDfKB6tOB/LXzEfy46YTfpUnUdSYmJdtAWz8b fRkez46fWup8yS4O1XRXi71cVvTiMUJAB072rEuwSZOIPOaEXi3SX5x3YXO2PgLxTIqg egKBLLZJWXTPM5E5QFseGgjdyBGDXfrJJ8jqhhzBzDUJIWBtuO0Yx09+Y4Ut2YPqtxAK fsEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=12gCECmkBZGZ1ZQ9phh4LY7sgpySLwSS1feltRQa6XA=; b=Uas8RXphl4cdg3V9QBYCKr/v8D4W67KXhW2ZV5PhbyRCnx7zb0TSTI1y28GPKAH3hP MkUvfnsjIZ9wqHv9vxam59RCy6Nr50UWQ2em6Mz/Is6XZnTPqS/zij+pr8pg6kKcxMzU Ym4vxnDnlT2ELYbqfHOo9CW/5nvmPcESvY68W8hWCM/hiOA+/BSIrxiHpc9/gn87Szem rZaK2WMUHJvmJwxYTBZwtmtaBH0vJPKodz2VcT59rhlqhRLlP+GwH6oFWFUgMvJEsY5u zU8iVYfmdTaXXPSwPNF81JmN+39gP/GBUX1GQm343Pgqd51nEQvzgkKuThEebssstZ7c ahKw== X-Gm-Message-State: AD7BkJIIvipTKaaVuND6jyIbyisEAC+jGXWwfpzZIb0Fd6po4GnbOAplLXS5ocI6A2GKCUTz2a24o9q/7p03OA== X-Received: by 10.194.78.199 with SMTP id d7mr9700678wjx.106.1457104221939; Fri, 04 Mar 2016 07:10:21 -0800 (PST) MIME-Version: 1.0 From: Marie Helene Kvello-Aune Date: Fri, 04 Mar 2016 15:10:12 +0000 Message-ID: Subject: libifconfig: A C API for ifconfig To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:10:24 -0000 Hey! I'm currently working on a library called 'libifconfig' which will provide a C API to do the actual work that /sbin/ifconfig currently does, except that of lib80211. What sparked this project was a wish to simplify maintenance of the ifconfig program by making it primarily focus on the user's command line interaction, and not so much on the specifics of how those things are done behind the scenes. One advantage to having such a library is to reduce code duplication and thus improve maintainability, and another is that it would make it easier for third party programs to query the network stack without having to spawn ifconfig and parse its output. I'm sure there's more, but those were the ones at the top of my head when writing this e-mail. Currently, the API is implemented so that the application provides an interface name, required value if any (say, to set description or name), or a reference to a value if retrieving information, such as an interfaces description or MTU. The calling application won't have to provide a socket, as this is part of the 'behind the scenes' things that the library takes care of. The API will ask only for the information that is required to do what it's supposed to do, nothing more and nothing less. Each API call will return a value of either "0" for success or "-1" for failure and there will be an instance (libifconfig_errstate) of a struct containing all information relevant to the error. I found this was the most sensible way of properly communicating exactly what went wrong with a call, as some API methods do several system calls behind the scenes. I found it necessary for the API to be this communicative as /sbin/ifconfig is rather detailed in its error messages, and I don't want /sbin/ifconfig's behaviour to be altered in any way as a result of this libification. The implementation of libifconfig currently exist only on my machine, but I will submit a patch to reviews.freebsd.org to solicit feedback once I've cleaned up the code some and implemented & verified the error feedback mechanism. Copy-pasting some of the simple stuff from the header file to give a feel for how I envision the API: int libifconfig_get_description(const char *name, char **description); int libifconfig_set_description(const char *name, const char *newdescription); int libifconfig_unset_description(const char *name); int libifconfig_set_mtu(const char *name, const int mtu); int libifconfig_get_mtu(const char *name, int *mtu); Your feedback is quite welcome. :) Regards, Marie Helene Kvello-Aune From owner-freebsd-net@freebsd.org Fri Mar 4 15:20:21 2016 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 F3B0F9DB57B for ; Fri, 4 Mar 2016 15:20:20 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9A27846 for ; Fri, 4 Mar 2016 15:20:20 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ob0-x235.google.com with SMTP id rt7so52358345obb.3 for ; Fri, 04 Mar 2016 07:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=+qIuQDSb9m+ewehnyOzPhL6dkfYAmnAzDyX3u8/nmGQ=; b=PFhAo22cNFUixSWKwgw4GH1EQdB3VwP3YGj0O0Pn+Hni0R5gVWqZuEoAkYca17QlKc gr21uT08FJk0+F7R7JEMBJMSCaM1IlTC4Emi0qRW8ghVqEQMTAopglpX8nSUOvv7kTJd OvEADM9VWXOGA/scBd+Z4IH6rMPJG90SyocQPgeF/CT8jKAkJ8wbXHr5Qpsg5Q3O5lOy z4Ww0Sgi+scyzjmmaFkOyfOTcATPlIDAPv78lZtj2/e4ZqGdkxTHSpaJBU5D2Y7JwXfi ibPoCpdO//48JBI9ijbMQSmT/51SKpoURIaOe446364lqT1s+g5auLhXlluhVDz363qS oTPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+qIuQDSb9m+ewehnyOzPhL6dkfYAmnAzDyX3u8/nmGQ=; b=VDLbAVhtzxa+ivZC28r/30lV7YBG1rqcUcix0Xyn/n3bLjk7dIy27dvBesQTWbUJlq ZRcMKtOmLlCn38Pk58W3G8tgI/7DnCHj2vMvSJq/5lYrVuI8F8lZXuUjnBkP2thyrlwm ILGW21gNK6o9yWNZdp7qDhMwU3maBOyVeYq7IonAMjc77n8GioDkaLDu9P9fpPK0u4wY MNgKKxvn3J0Rub1Kb2MJJqo6iLO+HVmUNjezpB83vDNRfXS7LjP53IIVbfKFOkWosGpF HvoiKxjWDQQDUcuxbK/3psmSvW5MOfslF/hVPTErPqXGjelkInni9j32w3d5OHDNn7Ur Ks6w== X-Gm-Message-State: AD7BkJJCVkTTJGM5m52BCWix234r1mgUUnsb6YXXv/CCiXBJxNb5s/hrPU/ydG3mNunB1Lm6YWZPcb1NBIj7vA== MIME-Version: 1.0 X-Received: by 10.182.200.196 with SMTP id ju4mr6773865obc.49.1457104819994; Fri, 04 Mar 2016 07:20:19 -0800 (PST) Sender: asomers@gmail.com Received: by 10.202.64.138 with HTTP; Fri, 4 Mar 2016 07:20:19 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Mar 2016 08:20:19 -0700 X-Google-Sender-Auth: qQnzIWVQrzKQk2t2Rr_1xRPnyPI Message-ID: Subject: Re: libifconfig: A C API for ifconfig From: Alan Somers To: Marie Helene Kvello-Aune Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:20:21 -0000 On Fri, Mar 4, 2016 at 8:10 AM, Marie Helene Kvello-Aune < marieheleneka@gmail.com> wrote: > Hey! > > I'm currently working on a library called 'libifconfig' which will provide > a C API to do the actual work that /sbin/ifconfig currently does, except > that of lib80211. What sparked this project was a wish to simplify > maintenance of the ifconfig program by making it primarily focus on the > user's command line interaction, and not so much on the specifics of how > those things are done behind the scenes. > > One advantage to having such a library is to reduce code duplication and > thus improve maintainability, and another is that it would make it easier > for third party programs to query the network stack without having to spawn > ifconfig and parse its output. I'm sure there's more, but those were the > ones at the top of my head when writing this e-mail. > > Currently, the API is implemented so that the application provides an > interface name, required value if any (say, to set description or name), or > a reference to a value if retrieving information, such as an interfaces > description or MTU. > > The calling application won't have to provide a socket, as this is part of > the 'behind the scenes' things that the library takes care of. The API will > ask only for the information that is required to do what it's supposed to > do, nothing more and nothing less. > > Each API call will return a value of either "0" for success or "-1" for > failure and there will be an instance (libifconfig_errstate) of a struct > containing all information relevant to the error. I found this was the most > sensible way of properly communicating exactly what went wrong with a call, > as some API methods do several system calls behind the scenes. I found it > necessary for the API to be this communicative as /sbin/ifconfig is rather > detailed in its error messages, and I don't want /sbin/ifconfig's > behaviour to be altered in any way as a result of this libification. > > The implementation of libifconfig currently exist only on my machine, but I > will submit a patch to reviews.freebsd.org to solicit feedback once I've > cleaned up the code some and implemented & verified the error feedback > mechanism. > > Copy-pasting some of the simple stuff from the header file to give a feel > for how I envision the API: > > int libifconfig_get_description(const char *name, char **description); > int libifconfig_set_description(const char *name, const char > *newdescription); > int libifconfig_unset_description(const char *name); > > int libifconfig_set_mtu(const char *name, const int mtu); > int libifconfig_get_mtu(const char *name, int *mtu); > > > Your feedback is quite welcome. :) > > Regards, > Marie Helene Kvello-Aune > This sounds like an awesome idea. ifconfig is my least favorite program to parse. BTW, are you aware of the ongoing libxo work? That effort fixes the problem of parsing the output of utilities like ifconfig, though it doesn't do anything to simplify their maintenance. -Alan From owner-freebsd-net@freebsd.org Fri Mar 4 15:25:25 2016 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 E585E9DB7B1 for ; Fri, 4 Mar 2016 15:25:24 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 91A85BB3; Fri, 4 Mar 2016 15:25:24 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id p65so24850153wmp.1; Fri, 04 Mar 2016 07:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UN9ZLz9SuM+znnOTBeGpEKT/VOy6F2iSIrZqFwy0zPI=; b=ltHTr2lBjkfZAsVrFoxrliO7Uxt/K4HYJmtkFM19nzLEo25G5kFcUIOg+PQnVhvdoL 3cmsXRnxJjfcHrSwKP+pf6wHHZ9YfHLntzpr05x8xdWXb5Rc20wAHJLKYwaDxZP+QZk1 QrFTMgAZSYJIXfd7/xb8C1tN/oOqDlRH6cjuN2//Sh/DevuMnsVIaOh7bKpUY9/r2oa3 2hilkOTw6156jgEF0oY/ILYaXfM+jnZjNAA8UNbyVl4QFVcS/iZ3XA9PLR8WAqiDBAHR bRWYaI0bOaHa5v7aIvXE0Ees8NnZtZZYzIF0sntGVZAbo/ebBxP5Ids3kjpJI1JeIlzs xZ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UN9ZLz9SuM+znnOTBeGpEKT/VOy6F2iSIrZqFwy0zPI=; b=ZrvenJY283taigFF2x3nSDot37xA0SKWkCqoJlv8iz5hlz1okeyJ0neWl4je+Q//So S9GyWybjX0dAa7dgW/qKU3nZzXevxq87h+aHi5he7iSLcP/SPYBKXF/uO9ZWeizxq0J1 dCdA0rIUYLC2DCC6LsgkwJB7Mj3hAt/C8CzcbxvKMeaUmFuAghX/oO4CXwiuBX4FiBLG pKYcP+pCczf/qx66iTanwKzeKBNSw0NmLzwfsFzRAVjMRIjhn6X2wTmjHSENK+kp7nxK Ycmc++CGknzOEv+tqwh2IiUMLjCWzX9tQSqqJIdAxHuanimUMnPu/kct4Qm5ikb1KZHU rSVw== X-Gm-Message-State: AD7BkJLHogR+GKrALCfBkQv6bIodobYRrd2c6iqVV8nXPHylTYTDpD+g/Pgf77oLW49ejgz5FVTOwRBsJjudGQ== X-Received: by 10.28.90.68 with SMTP id o65mr5566724wmb.70.1457105123100; Fri, 04 Mar 2016 07:25:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Marie Helene Kvello-Aune Date: Fri, 04 Mar 2016 15:25:13 +0000 Message-ID: Subject: Re: libifconfig: A C API for ifconfig To: Alan Somers Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:25:25 -0000 Hey! Yes, I am aware of libxo, and I hope that libxo-ification of /sbin/ifconfig will be easier to do once the 'hairy' bits aren't a part of /sbin/ifconfig any more. :) - Marie Helene On Fri, Mar 4, 2016 at 4:20 PM Alan Somers wrote: > On Fri, Mar 4, 2016 at 8:10 AM, Marie Helene Kvello-Aune < > marieheleneka@gmail.com> wrote: > >> Hey! >> >> I'm currently working on a library called 'libifconfig' which will provide >> a C API to do the actual work that /sbin/ifconfig currently does, except >> that of lib80211. What sparked this project was a wish to simplify >> maintenance of the ifconfig program by making it primarily focus on the >> user's command line interaction, and not so much on the specifics of how >> those things are done behind the scenes. >> >> One advantage to having such a library is to reduce code duplication and >> thus improve maintainability, and another is that it would make it easier >> for third party programs to query the network stack without having to >> spawn >> ifconfig and parse its output. I'm sure there's more, but those were the >> ones at the top of my head when writing this e-mail. >> >> Currently, the API is implemented so that the application provides an >> interface name, required value if any (say, to set description or name), >> or >> a reference to a value if retrieving information, such as an interfaces >> description or MTU. >> >> The calling application won't have to provide a socket, as this is part of >> the 'behind the scenes' things that the library takes care of. The API >> will >> ask only for the information that is required to do what it's supposed to >> do, nothing more and nothing less. >> >> Each API call will return a value of either "0" for success or "-1" for >> failure and there will be an instance (libifconfig_errstate) of a struct >> containing all information relevant to the error. I found this was the >> most >> sensible way of properly communicating exactly what went wrong with a >> call, >> as some API methods do several system calls behind the scenes. I found it >> necessary for the API to be this communicative as /sbin/ifconfig is rather >> detailed in its error messages, and I don't want /sbin/ifconfig's >> behaviour to be altered in any way as a result of this libification. >> >> The implementation of libifconfig currently exist only on my machine, but >> I >> will submit a patch to reviews.freebsd.org to solicit feedback once I've >> cleaned up the code some and implemented & verified the error feedback >> mechanism. >> >> Copy-pasting some of the simple stuff from the header file to give a feel >> for how I envision the API: >> >> int libifconfig_get_description(const char *name, char **description); >> int libifconfig_set_description(const char *name, const char >> *newdescription); >> int libifconfig_unset_description(const char *name); >> >> int libifconfig_set_mtu(const char *name, const int mtu); >> int libifconfig_get_mtu(const char *name, int *mtu); >> >> >> Your feedback is quite welcome. :) >> >> Regards, >> Marie Helene Kvello-Aune >> > > This sounds like an awesome idea. ifconfig is my least favorite program > to parse. BTW, are you aware of the ongoing libxo work? That effort fixes > the problem of parsing the output of utilities like ifconfig, though it > doesn't do anything to simplify their maintenance. > > -Alan > > From owner-freebsd-net@freebsd.org Fri Mar 4 15:30:26 2016 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 0B0F79DB978 for ; Fri, 4 Mar 2016 15:30:26 +0000 (UTC) (envelope-from pavel.odintsov@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 CC2DFD97; Fri, 4 Mar 2016 15:30:25 +0000 (UTC) (envelope-from pavel.odintsov@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id n190so65828507iof.0; Fri, 04 Mar 2016 07:30:25 -0800 (PST) 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; bh=y3hYgIzbvuMTfVZdf7QrbWvP7uzY6TBY/nf9bsUpD58=; b=vSdXJud/VmEwyjtPwJ2MasFiCqkm4kXsyxgmGJwHlWoCf05I7nAZ8YhZFf4bcyJ9fv Ao8o3N1kVGm0h/ZLcSQPxyY3egGhNueWB4ufPWnHYjrC4Rk7pE58Q71ARloqMeV9/1Jg tmwIuj92zY17hhnqfULfltflJj3uLuyme+qGDkadxeSc6ohC20BdYZR72wzKFr900XQY Q4gCWdITI4ECL54mFJpDuvtsC17OSg0dZ5gTtNLJBISPrSX9+Ty0Np3Jayry+vXPY5jn Ux+qQj+rY/R0sM3rNEKpJ2NwCkNee3DH/ehoEPbGCrq/35wf0IM/FnxclBW6qtLlv/3g V44A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=y3hYgIzbvuMTfVZdf7QrbWvP7uzY6TBY/nf9bsUpD58=; b=c2pXPteqUz641cTHEjAFOeCqBZD/rkR+o8op3xuWHq3xU8o3o4kstC37z9eLJRY1wz 8Vo3GJE8QCtHrrIbSRd7Eog4bTm4LLHT2yd1VlwcvIvzg1keDh9Uf41xO70BomWiLNzF tJYungdjau/7mziwZt3sicYTVfymmmqw45X5YkCkN2hYBTA1iVSWbpfjINGhuW8ZYLzj w3kLoTjGQWzymRRbQ9XM+gEKchkuWwZvAEf43iSV6BXbD336487avxDlNpo+BNg3WarW ZRnearL2Px4uY0kbqQ2zlLa70jeoQM/ol7m5W/lI11J8vSwBX8l4SKSRYimkrbNxDGrr rbAg== X-Gm-Message-State: AD7BkJJwVIT9EjzAZKxCTPojUlyewAFIXVg2ZzpnmcLBqleG6xcYBzYTwms2GeyFLOiCE+IKcT44nnvS9pQaLg== MIME-Version: 1.0 X-Received: by 10.107.1.2 with SMTP id 2mr9893523iob.194.1457105425211; Fri, 04 Mar 2016 07:30:25 -0800 (PST) Received: by 10.79.36.134 with HTTP; Fri, 4 Mar 2016 07:30:25 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Mar 2016 18:30:25 +0300 Message-ID: Subject: Re: libifconfig: A C API for ifconfig From: Pavel Odintsov To: Marie Helene Kvello-Aune Cc: Alan Somers , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:30:26 -0000 Hello! Great idea! Amazing! :) On Fri, Mar 4, 2016 at 6:25 PM, Marie Helene Kvello-Aune wrote: > Hey! > > Yes, I am aware of libxo, and I hope that libxo-ification of /sbin/ifconfig > will be easier to do once the 'hairy' bits aren't a part of /sbin/ifconfig > any more. :) > > - Marie Helene > > On Fri, Mar 4, 2016 at 4:20 PM Alan Somers wrote: > >> On Fri, Mar 4, 2016 at 8:10 AM, Marie Helene Kvello-Aune < >> marieheleneka@gmail.com> wrote: >> >>> Hey! >>> >>> I'm currently working on a library called 'libifconfig' which will provide >>> a C API to do the actual work that /sbin/ifconfig currently does, except >>> that of lib80211. What sparked this project was a wish to simplify >>> maintenance of the ifconfig program by making it primarily focus on the >>> user's command line interaction, and not so much on the specifics of how >>> those things are done behind the scenes. >>> >>> One advantage to having such a library is to reduce code duplication and >>> thus improve maintainability, and another is that it would make it easier >>> for third party programs to query the network stack without having to >>> spawn >>> ifconfig and parse its output. I'm sure there's more, but those were the >>> ones at the top of my head when writing this e-mail. >>> >>> Currently, the API is implemented so that the application provides an >>> interface name, required value if any (say, to set description or name), >>> or >>> a reference to a value if retrieving information, such as an interfaces >>> description or MTU. >>> >>> The calling application won't have to provide a socket, as this is part of >>> the 'behind the scenes' things that the library takes care of. The API >>> will >>> ask only for the information that is required to do what it's supposed to >>> do, nothing more and nothing less. >>> >>> Each API call will return a value of either "0" for success or "-1" for >>> failure and there will be an instance (libifconfig_errstate) of a struct >>> containing all information relevant to the error. I found this was the >>> most >>> sensible way of properly communicating exactly what went wrong with a >>> call, >>> as some API methods do several system calls behind the scenes. I found it >>> necessary for the API to be this communicative as /sbin/ifconfig is rather >>> detailed in its error messages, and I don't want /sbin/ifconfig's >>> behaviour to be altered in any way as a result of this libification. >>> >>> The implementation of libifconfig currently exist only on my machine, but >>> I >>> will submit a patch to reviews.freebsd.org to solicit feedback once I've >>> cleaned up the code some and implemented & verified the error feedback >>> mechanism. >>> >>> Copy-pasting some of the simple stuff from the header file to give a feel >>> for how I envision the API: >>> >>> int libifconfig_get_description(const char *name, char **description); >>> int libifconfig_set_description(const char *name, const char >>> *newdescription); >>> int libifconfig_unset_description(const char *name); >>> >>> int libifconfig_set_mtu(const char *name, const int mtu); >>> int libifconfig_get_mtu(const char *name, int *mtu); >>> >>> >>> Your feedback is quite welcome. :) >>> >>> Regards, >>> Marie Helene Kvello-Aune >>> >> >> This sounds like an awesome idea. ifconfig is my least favorite program >> to parse. BTW, are you aware of the ongoing libxo work? That effort fixes >> the problem of parsing the output of utilities like ifconfig, though it >> doesn't do anything to simplify their maintenance. >> >> -Alan >> >> > _______________________________________________ > 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" -- Sincerely yours, Pavel Odintsov From owner-freebsd-net@freebsd.org Fri Mar 4 16:06:25 2016 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 6B50C9DA84D for ; Fri, 4 Mar 2016 16:06:25 +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 5CD31916 for ; Fri, 4 Mar 2016 16:06:25 +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 u24G6O8n085475 for ; Fri, 4 Mar 2016 16:06:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207701] vlan interface over failover lagg has empty/00:00:00:00:00:00 mac/ether address Date: Fri, 04 Mar 2016 16:06:24 +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.3-BETA2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org 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: quoted-printable 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.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 16:06:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207701 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |araujo@FreeBSD.org Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 4 18:16:55 2016 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 B2FFAA09354 for ; Fri, 4 Mar 2016 18:16:55 +0000 (UTC) (envelope-from bogorodskiy@gmail.com) Received: from mail-lb0-x242.google.com (mail-lb0-x242.google.com [IPv6:2a00:1450:4010:c04::242]) (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 502129E6 for ; Fri, 4 Mar 2016 18:16:55 +0000 (UTC) (envelope-from bogorodskiy@gmail.com) Received: by mail-lb0-x242.google.com with SMTP id vk4so5658972lbb.1 for ; Fri, 04 Mar 2016 10:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:sender:date:from:to:cc:subject:references:mime-version :content-disposition:in-reply-to:user-agent; bh=4jdFzX+3xgvG0YbCZ16rhZx9LzaaoabFYU0aHBMFsxk=; b=IBQFLWgC+bXEA4O2d6DBppHFbBMPyNYhRzyQOY9JUsyt4XFBuJ3jaHcRnZOAr9YcdI eVCzfX05dBDsMzQLmgdl+ahtBlNzg4CkqFOBZ9T8WS6Ly3koseyuhGPgY+Imwdunipk4 hFuMdcjAcEm78pHGECe0F1jeDuO/jIx5d/uxXT3zb08sf6YILTTFxAVeD+PC+5W6RhbS HqgGjFrhdgCWDoRHVWDYWzPZITdcVC3tbGrqnr6UJsZAzi1HeWScJoMqTflAk3QnnwOW ttMfJKTT02SIs92njYXdICABXjYAwkpoaXWGEpCZJcH3vyHmT/+070Ac4Siw4ECsx8cy tmbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:sender:date:from:to:cc:subject :references:mime-version:content-disposition:in-reply-to:user-agent; bh=4jdFzX+3xgvG0YbCZ16rhZx9LzaaoabFYU0aHBMFsxk=; b=Gx7zrmdAraUhXe6qYXi+5O4nW8j8PHpDiqT055SInIogbRSXnCNf+E0SvShjcoYwbU B8NiV+mAo02bBzd6F86P5n03GUmnGAZjufGGEMtYmkJ0R34AagE7NSs9Q38mU21K+5Md /EaH5EIQnLx9g5ytsR+GsyUrVnEKTg0uHLsiMAASQlPLQpd1tcZpMHKvDxkZ2/n9Om6V IlErAKE4FqtszmzzeSHdALqoH14QTLnOUkBzdg8jvI+gU5vXkQR3xDPkW7vKsMJDgQvP 5YIPiYnCwQYXOt+zHjzFQsFqpiAxccna9eIDENXMVqitoZotakGK2upRWBYJm1fpwCPK R0Zg== X-Gm-Message-State: AD7BkJLaed/0OJsOSM6Z+dC3loBKYEF6oVD3pJOuOCRgogk1JC7cKp1nui9DEzfJBYBqVg== X-Received: by 10.25.153.12 with SMTP id b12mr3647705lfe.117.1457115412581; Fri, 04 Mar 2016 10:16:52 -0800 (PST) Received: from kloomba.lvv.mirantis.netpoz.mirantis.netsjc.mirantis.netsnv.mirantis.netinfra.mirantis.netdevops.mirantis.netmosi.mirantis.netbud.mirantis.netscc.mirantis.netvm.mirantis.netssl.mirantis.netmsk.mirantis.netsrt.mirantis.netkha.mirantis.netmnv.mirantis.net ([217.65.211.164]) by smtp.gmail.com with ESMTPSA id h134sm784345lfh.3.2016.03.04.10.16.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Mar 2016 10:16:51 -0800 (PST) Message-ID: <56d9d113.8c21190a.dfb98.397d@mx.google.com> X-Google-Original-Message-ID: <20160304181642.GA10040@kloomba.lvv.mirantis.netpoz.mirantis.netsjc.mirantis.netsnv.mirantis.netinfra.mirantis.netdevops.mirant Sender: Roman Bogorodskiy Date: Fri, 4 Mar 2016 21:16:44 +0300 From: Roman Bogorodskiy To: Marie Helene Kvello-Aune Cc: freebsd-net@freebsd.org Subject: Re: libifconfig: A C API for ifconfig References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 18:16:55 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Marie Helene Kvello-Aune wrote: > Hey! >=20 > I'm currently working on a library called 'libifconfig' which will provide > a C API to do the actual work that /sbin/ifconfig currently does, except > that of lib80211. What sparked this project was a wish to simplify > maintenance of the ifconfig program by making it primarily focus on the > user's command line interaction, and not so much on the specifics of how > those things are done behind the scenes. >=20 > One advantage to having such a library is to reduce code duplication and > thus improve maintainability, and another is that it would make it easier > for third party programs to query the network stack without having to spa= wn > ifconfig and parse its output. I'm sure there's more, but those were the > ones at the top of my head when writing this e-mail. Hi, This is a great idea. It's a bit disappointing to re-implement common stuff like getting a list of interfaces or obtaining MAC address or IP address of the interface over and over again in third party apps. One question that's interesting to me though: is it planned to provide support for this lib outside of the base? I mean, if the lib will be added in, say, 11.x, and I want to use it from my third-party application, will it be possible to e.g. install it from ports for 9.x or 10.x so I don't have to support 2 version of the code, one that uses libifconfig and one that e.g. parses ifconfig(8) output? Roman Bogorodskiy --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJW2dEKAAoJEMltX/4IwiJq3osH/iq16jxrVT1rcfoBxwD9aopw XRwrErtH5lpxOEAUkhmlmc7rljhpATsehunDP4m34sYTe3C0bqHKUhAJnaFWaSUQ +MqqYBySeokgpeC4xm4queFa6/Knw0mXzsUcKKATrOhR7uEvnEs6yZOXPmwwG3iu g371hUD2sVwT9gwTOb5AKLixk51BbbG3CAEQoODDQyNL8tFmW13SsM38yIHWFrjN Tlz0iE3z8eqQ8wOFRiRUBxtbLuifv7U3anUoJMSdMiBA+BOuJ5qnB0Z2PHvhFEMq aGQjNzZQTT2kgz6JILxxakAYgbifQETal7UXh6FFesCBb+Bxd1KjwAkWCJVmV1M= =kdkR -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-net@freebsd.org Fri Mar 4 19:17:04 2016 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 50C759DAACF for ; Fri, 4 Mar 2016 19:17:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 38A9CFAC for ; Fri, 4 Mar 2016 19:17:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u24JGtkn058161 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Mar 2016 11:16:56 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: routing issue To: freebsd-net@freebsd.org, Pakhom Golynga References: <56D81418.9020500@pakhom.spb.ru> From: Julian Elischer Message-ID: <56D9DF22.2080504@freebsd.org> Date: Fri, 4 Mar 2016 11:16:50 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D81418.9020500@pakhom.spb.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:17:04 -0000 On 3/03/2016 2:38 AM, Pakhom Golynga wrote: > Hello all! > > Please help me to investigate this issue. > I have problem on 10.2-RELEASE-p12 with multiple network interfaces > and PF (rules, NAT) > # ifconfig > <--cut--> > em0: flags=8843 metric 0 mtu > 1500 > options=4209b > > ether 00:25:90:64:14:50 > inet 172.27.27.254 netmask 0xffffff00 broadcast 172.27.27.255 > inet 172.27.27.240 netmask 0xffffffff broadcast 172.27.27.240 > inet 172.27.27.252 netmask 0xffffffff broadcast 172.27.27.252 > inet 172.27.27.251 netmask 0xffffffff broadcast 172.27.27.251 > inet 172.27.27.250 netmask 0xffffffff broadcast 172.27.27.250 > inet 172.27.27.249 netmask 0xffffffff broadcast 172.27.27.249 > inet 172.27.27.248 netmask 0xffffffff broadcast 172.27.27.248 > inet 172.27.27.247 netmask 0xffffffff broadcast 172.27.27.247 > inet 172.27.27.246 netmask 0xffffffff broadcast 172.27.27.246 > inet 172.27.27.245 netmask 0xffffffff broadcast 172.27.27.245 > inet 172.27.27.244 netmask 0xffffffff broadcast 172.27.27.244 > inet 172.27.27.243 netmask 0xffffffff broadcast 172.27.27.243 > inet 172.27.27.242 netmask 0xffffffff broadcast 172.27.27.242 > inet 172.27.27.241 netmask 0xffffffff broadcast 172.27.27.241 > inet 172.27.27.239 netmask 0xffffffff broadcast 172.27.27.239 > inet 172.27.27.238 netmask 0xffffffff broadcast 172.27.27.238 > inet 172.27.27.237 netmask 0xffffffff broadcast 172.27.27.237 > inet 172.27.27.236 netmask 0xffffffff broadcast 172.27.27.236 > inet 172.27.27.235 netmask 0xffffffff broadcast 172.27.27.235 > media: Ethernet autoselect (1000baseT ) > status: active > em1: flags=8943 > metric 0 mtu 1500 > options=4209b > > ether 00:25:90:64:14:51 > inet 10.24.44.50 netmask 0xfffffc00 broadcast 10.24.47.255 > media: Ethernet autoselect (100baseTX ) > status: active > <--cut--> > > em0 - local network. Aliases on em0 for Jail's > em1 - connected to ISP > > This configuration successfully operate a long time but recently > (for no apparent reason) suddenly became manifest bug with routing. > Regardless from uptime (sometimes 12 hours, and maybe a couple of > days) after a certain time the traffic running between jails begins > to route via em1 (instead lo0 (net.link.ether.inet.useloopback=1)): this sounds much like another report we have seen. you may be able to fix it by re-adding your routes.. The report I have seen suggested that some routes seem to stop being effective after some period. It's still not understood. > # tcpdump -n -e -ttt -i em1 host 172.27.27.252 or host 172.27.27.247 > or host 172.27.27.248 > 00:00:00.054989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype > IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: > Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale > 6,sackOK,TS val 161568673 ecr 0], length 0 > 00:00:00.318036 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype > IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.60176: > Flags [.], ack 772660872, win 1275, options [nop,nop,TS val > 1737287913 ecr 161568991], length 0 > 00:00:00.036971 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype > IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.33080: > Flags [.], ack 1, win 1275, options [nop,nop,TS val 1701623130 ecr > 161568238], length 0 > 00:00:00.050001 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype > IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.40200: > Flags [.], ack 1, win 1275, options [nop,nop,TS val 1477098721 ecr > 161568288], length 0 > 00:00:02.794992 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype > IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: > Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale > 6,sackOK,TS val 161571873 ecr 0], length 0 > 00:00:03.312026 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype > IPv4 (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: > Flags [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale > 6,sackOK,TS val 161575185 ecr 0], length 0 > 00:00:02.887982 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype > IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: > Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale > 6,sackOK,TS val 161578073 ecr 0], length 0 > 00:00:00.111989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype > IPv4 (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: > Flags [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale > 6,sackOK,TS val 161578185 ecr 0], length 0 > 00:00:03.471007 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype > IPv4 (0x0800), length 108: 172.27.27.247.80 > 172.27.27.248.26056: > Flags [FP.], seq 1448:1490, ack 1, win 1275, options [nop,nop,TS val > 2142270801 ecr 161575507], length 42 > > In the same time: > # route -vn get -host > RTA_DST: inet 172.27.27.247; RTA_IFP: link ; RTM_GET: Report > Metrics: len 224, pid: 0, seq 1, errno 0, > flags: > locks: inits: > sockaddrs: > 172.27.27.247 link#0 > route to: 172.27.27.247 > destination: 172.27.27.247 > fib: 0 > interface: lo0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 16384 1 0 > > locks: inits: > sockaddrs: > 172.27.27.247 link#4 lo0 127.0.0.1 > RTA_DST: inet 172.27.27.250; RTA_IFP: link ; RTM_GET: Report > Metrics: len 224, pid: 0, seq 1, errno 0, > flags: > locks: inits: > sockaddrs: > 172.27.27.250 link#0 > route to: 172.27.27.250 > destination: 172.27.27.250 > fib: 0 > interface: lo0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 16384 1 0 > > locks: inits: > sockaddrs: > 172.27.27.250 link#4 lo0 127.0.0.1 > RTA_DST: inet 172.27.27.252; RTA_IFP: link ; RTM_GET: Report > Metrics: len 224, pid: 0, seq 1, errno 0, > flags: > locks: inits: > sockaddrs: > 172.27.27.252 link#0 > route to: 172.27.27.252 > destination: 172.27.27.252 > fib: 0 > interface: lo0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 16384 1 0 > > locks: inits: > sockaddrs: > 172.27.27.252 link#4 lo0 127.0.0.1 > > > # netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > default 10.24.44.1 UGS em1 > 10.24.44.0/22 link#5 U em1 > 10.24.44.50 link#5 UHS lo0 > 127.0.0.1 link#7 UH lo0 > 172.27.27.0/24 link#4 U em0 > 172.27.27.235 link#4 UHS lo0 > 172.27.27.235/32 link#4 U em0 > 172.27.27.236 link#4 UHS lo0 > 172.27.27.236/32 link#4 U em0 > 172.27.27.237 link#4 UHS lo0 > 172.27.27.237/32 link#4 U em0 > 172.27.27.238 link#4 UHS lo0 > 172.27.27.238/32 link#4 U em0 > 172.27.27.239 link#4 UHS lo0 > 172.27.27.239/32 link#4 U em0 > 172.27.27.240 link#4 UHS lo0 > 172.27.27.240/32 link#4 U em0 > 172.27.27.241 link#4 UHS lo0 > 172.27.27.241/32 link#4 U em0 > 172.27.27.242 link#4 UHS lo0 > 172.27.27.242/32 link#4 U em0 > 172.27.27.243 link#4 UHS lo0 > 172.27.27.243/32 link#4 U em0 > 172.27.27.244 link#4 UHS lo0 > 172.27.27.244/32 link#4 U em0 > 172.27.27.245 link#4 UHS lo0 > 172.27.27.245/32 link#4 U em0 > 172.27.27.246 link#4 UHS lo0 > 172.27.27.246/32 link#4 U em0 > 172.27.27.247 link#4 UHS lo0 > 172.27.27.247/32 link#4 U em0 > 172.27.27.248 link#4 UHS lo0 > 172.27.27.248/32 link#4 U em0 > 172.27.27.249 link#4 UHS lo0 > 172.27.27.249/32 link#4 U em0 > 172.27.27.250 link#4 UHS lo0 > 172.27.27.250/32 link#4 U em0 > 172.27.27.251 link#4 UHS lo0 > 172.27.27.251/32 link#4 U em0 > 172.27.27.252 link#4 UHS lo0 > 172.27.27.252/32 link#4 U em0 > 172.27.27.254 link#4 UHS lo0 > 172.27.28.0/24 link#8 U bridge0 > 172.27.28.254 link#8 UHS lo0 > 172.27.30.0/24 172.27.30.2 UGS tun0 > 172.27.30.1 link#12 UHS lo0 > 172.27.30.2 link#12 UH tun0 > > After the reboot everything works well for some time. > > Thanks! > _______________________________________________ > 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 Fri Mar 4 20:57:35 2016 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 E45DDA09F45 for ; Fri, 4 Mar 2016 20:57:35 +0000 (UTC) (envelope-from pg@pakhom.spb.ru) Received: from mail.pakhom.spb.ru (mail.pakhom.spb.ru [5.19.176.65]) (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 AA15E300; Fri, 4 Mar 2016 20:57:35 +0000 (UTC) (envelope-from pg@pakhom.spb.ru) Received: from [172.27.27.11] by mail.pakhom.spb.ru with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1abwmz-000EEr-VM; Fri, 04 Mar 2016 23:57:33 +0300 Subject: Re: routing issue To: Julian Elischer , freebsd-net@freebsd.org References: <56D81418.9020500@pakhom.spb.ru> <56D9DF22.2080504@freebsd.org> From: Pakhom Golynga Message-ID: <56D9F6BC.8070202@pakhom.spb.ru> Date: Fri, 4 Mar 2016 23:57:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56D9DF22.2080504@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 172.27.27.11 X-SA-Exim-Mail-From: pg@pakhom.spb.ru X-SA-Exim-Scanned: No (on mail.pakhom.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 20:57:36 -0000 04.03.2016 22:16, Julian Elischer пишет: > On 3/03/2016 2:38 AM, Pakhom Golynga wrote: >> Hello all! >> >> Please help me to investigate this issue. >> I have problem on 10.2-RELEASE-p12 with multiple network interfaces >> and PF (rules, NAT) >> # ifconfig >> <--cut--> >> em0: flags=8843 metric 0 mtu >> 1500 >> options=4209b >> >> ether 00:25:90:64:14:50 >> inet 172.27.27.254 netmask 0xffffff00 broadcast 172.27.27.255 >> inet 172.27.27.240 netmask 0xffffffff broadcast 172.27.27.240 >> inet 172.27.27.252 netmask 0xffffffff broadcast 172.27.27.252 >> inet 172.27.27.251 netmask 0xffffffff broadcast 172.27.27.251 >> inet 172.27.27.250 netmask 0xffffffff broadcast 172.27.27.250 >> inet 172.27.27.249 netmask 0xffffffff broadcast 172.27.27.249 >> inet 172.27.27.248 netmask 0xffffffff broadcast 172.27.27.248 >> inet 172.27.27.247 netmask 0xffffffff broadcast 172.27.27.247 >> inet 172.27.27.246 netmask 0xffffffff broadcast 172.27.27.246 >> inet 172.27.27.245 netmask 0xffffffff broadcast 172.27.27.245 >> inet 172.27.27.244 netmask 0xffffffff broadcast 172.27.27.244 >> inet 172.27.27.243 netmask 0xffffffff broadcast 172.27.27.243 >> inet 172.27.27.242 netmask 0xffffffff broadcast 172.27.27.242 >> inet 172.27.27.241 netmask 0xffffffff broadcast 172.27.27.241 >> inet 172.27.27.239 netmask 0xffffffff broadcast 172.27.27.239 >> inet 172.27.27.238 netmask 0xffffffff broadcast 172.27.27.238 >> inet 172.27.27.237 netmask 0xffffffff broadcast 172.27.27.237 >> inet 172.27.27.236 netmask 0xffffffff broadcast 172.27.27.236 >> inet 172.27.27.235 netmask 0xffffffff broadcast 172.27.27.235 >> media: Ethernet autoselect (1000baseT ) >> status: active >> em1: flags=8943 >> metric 0 mtu 1500 >> options=4209b >> >> ether 00:25:90:64:14:51 >> inet 10.24.44.50 netmask 0xfffffc00 broadcast 10.24.47.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> <--cut--> >> >> em0 - local network. Aliases on em0 for Jail's >> em1 - connected to ISP >> >> This configuration successfully operate a long time but recently (for >> no apparent reason) suddenly became manifest bug with routing. >> Regardless from uptime (sometimes 12 hours, and maybe a couple of >> days) after a certain time the traffic running between jails begins >> to route via em1 (instead lo0 (net.link.ether.inet.useloopback=1)): > > this sounds much like another report we have seen. > you may be able to fix it by re-adding your routes.. > > The report I have seen suggested that some routes seem to stop being > effective after some period. > It's still not understood. > Can I help with it? The issue is often reproduce on my system. > >> # tcpdump -n -e -ttt -i em1 host 172.27.27.252 or host 172.27.27.247 >> or host 172.27.27.248 >> 00:00:00.054989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 >> (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags >> [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale >> 6,sackOK,TS val 161568673 ecr 0], length 0 >> 00:00:00.318036 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 >> (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.60176: Flags >> [.], ack 772660872, win 1275, options [nop,nop,TS val 1737287913 ecr >> 161568991], length 0 >> 00:00:00.036971 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 >> (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.33080: Flags >> [.], ack 1, win 1275, options [nop,nop,TS val 1701623130 ecr >> 161568238], length 0 >> 00:00:00.050001 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 >> (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.40200: Flags >> [.], ack 1, win 1275, options [nop,nop,TS val 1477098721 ecr >> 161568288], length 0 >> 00:00:02.794992 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 >> (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags >> [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale >> 6,sackOK,TS val 161571873 ecr 0], length 0 >> 00:00:03.312026 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 >> (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags >> [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale >> 6,sackOK,TS val 161575185 ecr 0], length 0 >> 00:00:02.887982 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 >> (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags >> [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale >> 6,sackOK,TS val 161578073 ecr 0], length 0 >> 00:00:00.111989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 >> (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags >> [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale >> 6,sackOK,TS val 161578185 ecr 0], length 0 >> 00:00:03.471007 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 >> (0x0800), length 108: 172.27.27.247.80 > 172.27.27.248.26056: Flags >> [FP.], seq 1448:1490, ack 1, win 1275, options [nop,nop,TS val >> 2142270801 ecr 161575507], length 42 >> >> In the same time: >> # route -vn get -host >> RTA_DST: inet 172.27.27.247; RTA_IFP: link ; RTM_GET: Report Metrics: >> len 224, pid: 0, seq 1, errno 0, flags: >> locks: inits: >> sockaddrs: >> 172.27.27.247 link#0 >> route to: 172.27.27.247 >> destination: 172.27.27.247 >> fib: 0 >> interface: lo0 >> flags: >> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >> 0 0 0 0 16384 1 0 >> >> locks: inits: >> sockaddrs: >> 172.27.27.247 link#4 lo0 127.0.0.1 >> RTA_DST: inet 172.27.27.250; RTA_IFP: link ; RTM_GET: Report Metrics: >> len 224, pid: 0, seq 1, errno 0, flags: >> locks: inits: >> sockaddrs: >> 172.27.27.250 link#0 >> route to: 172.27.27.250 >> destination: 172.27.27.250 >> fib: 0 >> interface: lo0 >> flags: >> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >> 0 0 0 0 16384 1 0 >> >> locks: inits: >> sockaddrs: >> 172.27.27.250 link#4 lo0 127.0.0.1 >> RTA_DST: inet 172.27.27.252; RTA_IFP: link ; RTM_GET: Report Metrics: >> len 224, pid: 0, seq 1, errno 0, flags: >> locks: inits: >> sockaddrs: >> 172.27.27.252 link#0 >> route to: 172.27.27.252 >> destination: 172.27.27.252 >> fib: 0 >> interface: lo0 >> flags: >> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >> 0 0 0 0 16384 1 0 >> >> locks: inits: >> sockaddrs: >> 172.27.27.252 link#4 lo0 127.0.0.1 >> >> >> # netstat -rn >> Routing tables >> >> Internet: >> Destination Gateway Flags Netif Expire >> default 10.24.44.1 UGS em1 >> 10.24.44.0/22 link#5 U em1 >> 10.24.44.50 link#5 UHS lo0 >> 127.0.0.1 link#7 UH lo0 >> 172.27.27.0/24 link#4 U em0 >> 172.27.27.235 link#4 UHS lo0 >> 172.27.27.235/32 link#4 U em0 >> 172.27.27.236 link#4 UHS lo0 >> 172.27.27.236/32 link#4 U em0 >> 172.27.27.237 link#4 UHS lo0 >> 172.27.27.237/32 link#4 U em0 >> 172.27.27.238 link#4 UHS lo0 >> 172.27.27.238/32 link#4 U em0 >> 172.27.27.239 link#4 UHS lo0 >> 172.27.27.239/32 link#4 U em0 >> 172.27.27.240 link#4 UHS lo0 >> 172.27.27.240/32 link#4 U em0 >> 172.27.27.241 link#4 UHS lo0 >> 172.27.27.241/32 link#4 U em0 >> 172.27.27.242 link#4 UHS lo0 >> 172.27.27.242/32 link#4 U em0 >> 172.27.27.243 link#4 UHS lo0 >> 172.27.27.243/32 link#4 U em0 >> 172.27.27.244 link#4 UHS lo0 >> 172.27.27.244/32 link#4 U em0 >> 172.27.27.245 link#4 UHS lo0 >> 172.27.27.245/32 link#4 U em0 >> 172.27.27.246 link#4 UHS lo0 >> 172.27.27.246/32 link#4 U em0 >> 172.27.27.247 link#4 UHS lo0 >> 172.27.27.247/32 link#4 U em0 >> 172.27.27.248 link#4 UHS lo0 >> 172.27.27.248/32 link#4 U em0 >> 172.27.27.249 link#4 UHS lo0 >> 172.27.27.249/32 link#4 U em0 >> 172.27.27.250 link#4 UHS lo0 >> 172.27.27.250/32 link#4 U em0 >> 172.27.27.251 link#4 UHS lo0 >> 172.27.27.251/32 link#4 U em0 >> 172.27.27.252 link#4 UHS lo0 >> 172.27.27.252/32 link#4 U em0 >> 172.27.27.254 link#4 UHS lo0 >> 172.27.28.0/24 link#8 U bridge0 >> 172.27.28.254 link#8 UHS lo0 >> 172.27.30.0/24 172.27.30.2 UGS tun0 >> 172.27.30.1 link#12 UHS lo0 >> 172.27.30.2 link#12 UH tun0 >> >> After the reboot everything works well for some time. >> >> Thanks! >> _______________________________________________ >> 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" >> > > _______________________________________________ > 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 Sat Mar 5 10:55:21 2016 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 103119DBA67 for ; Sat, 5 Mar 2016 10:55:21 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2919C01; Sat, 5 Mar 2016 10:55:20 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id p65so19293323wmp.0; Sat, 05 Mar 2016 02:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F0aCREzglxuakAN1ZM3s6rAwCJhLlz+4ZDSDxinZCVM=; b=PLI93+/tS1xamj4B+UC0wb/qitVIOBvqc5DrGlkqKv06cdu3P+wzC4bKlILg6OTLKj gBbpz6s+9sfdqhgvupT0Z0/JuaisMu1L9hNBz1C6O5sybCyHjGA5b2QkcOb37XuyPJaZ t/zBMNNivqLEjmtwUIm1tcZdsvbXVmMQE12vXB/62XL/CTjLe8i9/21t4ubReuOF/kGE b0HJWbdinV8a6kCu5LAaiSwXu3O57/0gNxiU4+qC5Q2Y6Upq8Lj7lP+dV5xkwR+qQsf/ VIZnDZxO5sH44Sn+O90y+h6A1gI21l0qCUZ5wD8Hm0wvjhI4hqQA8O0elA+fV1wJroNd IA1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F0aCREzglxuakAN1ZM3s6rAwCJhLlz+4ZDSDxinZCVM=; b=jj6C8sZvvAKE7VLZdglxK+VZvI0PtqK7ckVBA7Ply1fL9VBnRNyTzxMv6OAlavhLQX ncE/T/KJpSWQkutQRpY+Dh9tXZ8FNOq91FFXlO+HEJlGgjC4TQ8rRAb3ieTc/m85iJIP 2CCN8lK8B+zEL2uOV9mxBhPb5tBiVdEAyPCmmn7zvyFy1jnAdR0lY0VPoSIcuBWi1SWX WNdDAUoycmqUKMbY20IkwfwtSkNeW/8ZENz3SzE+YGf+WV2KYm4PC1N25mp3qODYWMO9 mM7SgnshKCX9x/qbU9hxQItrzVijOyc8F2bEHBWlxH5udQLSAFY3xalEspvYCI8twVol d21w== X-Gm-Message-State: AD7BkJK7U+a6KZy0kzEc+sCZKGSb8ToXjmKSz9e2BNNLhD0bgQDG82lSQV48ECJkNjJPOY1cVjFGdTmkpbVm7g== X-Received: by 10.28.147.206 with SMTP id v197mr3143304wmd.70.1457175318338; Sat, 05 Mar 2016 02:55:18 -0800 (PST) MIME-Version: 1.0 References: <56d9d113.8c21190a.dfb98.397d@mx.google.com> In-Reply-To: <56d9d113.8c21190a.dfb98.397d@mx.google.com> From: Marie Helene Kvello-Aune Date: Sat, 05 Mar 2016 10:55:08 +0000 Message-ID: Subject: Re: libifconfig: A C API for ifconfig To: Roman Bogorodskiy Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 10:55:21 -0000 Hey. I agree it would be useful to make libifconfig available for previous versions through ports. This is not something I'm focusing on right now, but I don't think there will be any trouble building the library outside of base. There's one potential problem I can think of right now: Kernel ABI may have changed between versions in a way that affects libifconfig, but if this is the case it should be relatively easy to deal with. I've added this concern to the list of things to consider when closer to completion. :) - Marie Helene On Fri, Mar 4, 2016 at 7:16 PM Roman Bogorodskiy wrote: > Marie Helene Kvello-Aune wrote: > > > Hey! > > > > I'm currently working on a library called 'libifconfig' which will > provide > > a C API to do the actual work that /sbin/ifconfig currently does, except > > that of lib80211. What sparked this project was a wish to simplify > > maintenance of the ifconfig program by making it primarily focus on the > > user's command line interaction, and not so much on the specifics of how > > those things are done behind the scenes. > > > > One advantage to having such a library is to reduce code duplication and > > thus improve maintainability, and another is that it would make it easier > > for third party programs to query the network stack without having to > spawn > > ifconfig and parse its output. I'm sure there's more, but those were the > > ones at the top of my head when writing this e-mail. > > Hi, > > This is a great idea. It's a bit disappointing to re-implement common > stuff like getting a list of interfaces or obtaining MAC address or IP > address of the interface over and over again in third party apps. > > One question that's interesting to me though: is it planned to provide > support for this lib outside of the base? I mean, if the lib will be > added in, say, 11.x, and I want to use it from my third-party > application, will it be possible to e.g. install it from ports for 9.x or > 10.x so I don't have to support 2 version of the code, one that uses > libifconfig and one that e.g. parses ifconfig(8) output? > > Roman Bogorodskiy > From owner-freebsd-net@freebsd.org Sat Mar 5 11:31:02 2016 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 EE3FB9DA15B for ; Sat, 5 Mar 2016 11:31:01 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE141A0; Sat, 5 Mar 2016 11:31:01 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 8516A117BF; Sat, 5 Mar 2016 13:20:53 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Sat, 05 Mar 2016 13:21:02 +0200 From: dan_partelly To: Marie Helene Kvello-Aune Cc: Roman Bogorodskiy , Subject: Re: libifconfig: A C API for ifconfig In-Reply-To: References: <56d9d113.8c21190a.dfb98.397d@mx.google.com> Message-ID: X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 11:31:02 -0000 On Sat, 05 Mar 2016 10:55:08 +0000, Marie Helene Kvello-Aune wrote: > Hey. > > I agree it would be useful to make libifconfig available for previous > versions through ports. > > This is not something I'm focusing on right now, but I don't think there > will be any trouble building the library outside of base. There's one > potential problem I can think of right now: Kernel ABI may have changed > between versions in a way that affects libifconfig, but if this is the case > it should be relatively easy to deal with. > > I've added this concern to the list of things to consider when closer to > completion. :) You should apply for a grant from FreeBSD foundation. It is my opinion that they should pay money to ensure by any means necessary (including paying for it) that a big part of what are today monolithic utilities in base OS is factored into libraries. IMO, This is one of the most important projects FreeBSD could execute to allow moving forward and meet the demands of the extremely dynamic computing world which we already have today. This would solve one of the biggest issues FreeBSD has today, namely, very poor binary code reuse (problem some tried to solve with what is IMO a technically poor and distasteful solution , namely libxo-fication of base) I wish you good luck with this. It is a truly important project. > > - Marie Helene > > On Fri, Mar 4, 2016 at 7:16 PM Roman Bogorodskiy wrote: > >> Marie Helene Kvello-Aune wrote: >> >> > Hey! >> > >> > I'm currently working on a library called 'libifconfig' which will >> provide >> > a C API to do the actual work that /sbin/ifconfig currently does, >> > except >> > that of lib80211. What sparked this project was a wish to simplify >> > maintenance of the ifconfig program by making it primarily focus on the >> > user's command line interaction, and not so much on the specifics of >> > how >> > those things are done behind the scenes. >> > >> > One advantage to having such a library is to reduce code duplication >> > and >> > thus improve maintainability, and another is that it would make it >> > easier >> > for third party programs to query the network stack without having to >> spawn >> > ifconfig and parse its output. I'm sure there's more, but those were >> > the >> > ones at the top of my head when writing this e-mail. >> >> Hi, >> >> This is a great idea. It's a bit disappointing to re-implement common >> stuff like getting a list of interfaces or obtaining MAC address or IP >> address of the interface over and over again in third party apps. >> >> One question that's interesting to me though: is it planned to provide >> support for this lib outside of the base? I mean, if the lib will be >> added in, say, 11.x, and I want to use it from my third-party >> application, will it be possible to e.g. install it from ports for 9.x or >> 10.x so I don't have to support 2 version of the code, one that uses >> libifconfig and one that e.g. parses ifconfig(8) output? >> >> Roman Bogorodskiy >> > _______________________________________________ > 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"